软件定义汽车：如何通过IVI芯片异构计算实现信息型ADAS功能升级 1. 项目概述当信息娱乐系统“兼职”做安全卫士十年前当我们谈论车载中控大屏时想的还只是导航和听歌。但今天这块屏幕正在被赋予一项更重要的使命成为驾驶员的“第三只眼”。这背后是一场静悄悄的技术融合——将原本分立的高级驾驶辅助系统ADAS功能以纯软件升级的方式集成到我们每天都在使用的车载信息娱乐系统IVI里。这不是天方夜谭而是像德州仪器TI在2014年就前瞻性布局的DRA75x “Jacinto 6 Ex”处理器所描绘的路线图。它揭示了一个核心思路与其为每项新功能堆叠昂贵的专用硬件不如深度挖掘现有IVI主芯片的潜力通过软件定义让娱乐中枢变身安全助手。这种“信息型ADAS”的构想其价值在于极高的性价比和可扩展性。对于车企和一级供应商Tier 1而言最大的痛点在于研发成本与产品迭代速度的平衡。传统的ADAS系统如自动紧急制动AEB、自适应巡航ACC因其涉及车辆控制对功能安全ISO 26262 ASIL等级要求极高通常需要独立的安全域控制器。然而还有大量不直接控制车辆仅用于提供信息、增强感知的功能例如360度全景泊车辅助、基于摄像头的驾驶员疲劳监测、增强现实导航指引等。这些功能的核心是图像处理和数据分析而非车辆控制。如果能为现有的、已通过车规认证的IVI主芯片注入更强的视觉处理能力那么这些“信息型ADAS”功能就能像手机安装新APP一样通过软件升级甚至后期OTA空中下载的方式提供给用户。这不仅仅是节省一块芯片的成本更是对整个电子电气架构的简化。它避免了复杂的跨域通信、额外的线束和传感器接口复用问题。TI的Jacinto 6 Ex处理器正是这一理念的硬件载体。它在成熟的Jacinto 6 IVI处理器基础上通过增加专用的嵌入式视觉引擎EVE和额外的数字信号处理器DSP为这种“软升级”提供了坚实的算力基础。接下来我们将深入拆解这一融合方案的设计思路、技术实现细节以及在实际开发中需要关注的要点与陷阱。2. 核心思路拆解为什么是“软件升级”而非“硬件堆叠”2.1 功能安全与成本驱动的分野要理解“信息型ADAS”的定位首先要厘清ADAS的功能安全等级。根据ISO 26262标准汽车电子系统的功能安全等级从低到高分为QM、ASIL A、B、C、D。直接涉及车辆纵向或横向控制的系统如AEB、车道保持通常要求ASIL B或更高等级。这意味着从芯片设计、系统架构到软件流程都需要遵循严格的安全开发流程成本高昂。而“信息型ADAS”功能如环视泊车辅助、交通标志识别仅提示、驾驶员状态监控等其失效后果通常不会直接导致车辆失控可能仅定义为ASIL A或QM等级。这种安全等级的要求使得其软件可以运行在非安全岛Non-Safety Island的算力单元上例如IVI主芯片中的高性能应用处理器如ARM Cortex-A15或专用的视觉加速器。从成本角度看为IVI系统增加一个ASIL B/D等级的独立ADAS域控制器意味着双倍的硬件成本处理器、内存、电源、外壳、更复杂的布线以及更高的集成与测试费用。而如果通过升级现有IVI主芯片的软件来获得新功能边际成本几乎为零研发投入可以集中用于算法优化和软件集成能极大加速功能上市时间。2.2 硬件平台的演进从通用计算到异构集成传统的IVI处理器设计重点在于“信息娱乐”强大的CPU用于运行复杂的车载操作系统如QNX、Linux、Android Automotive高性能GPU用于渲染炫酷的UI和导航界面多媒体加速器用于解码高清视频。这些单元虽然算力强大但对于计算机视觉这类需要高并行、低精度定点运算的任务能效比并不高。这就是Jacinto 6 Ex设计的关键所在异构计算。它没有简单粗暴地提升CPU主频或增加CPU核心而是引入了两种针对性的加速器第二颗C66x DSPDSP擅长流式信号处理和复杂的数学运算如FFT、滤波。在IVI中它原本用于软件定义无线电解调HD Radio、DAB和高级音频处理如主动降噪。其空闲算力或新增的这颗DSP可以完美处理环视泊车中的图像拼接、畸变校正等几何变换任务。嵌入式视觉引擎EVE这是真正的“秘密武器”。EVE是一个为视觉算法量身定制的向量协处理器专门针对8位或16位定点数据的大规模矩阵/向量运算进行优化。像物体检测、特征点提取、光流计算等算法内核在EVE上运行的能效比每瓦特性能远超通用CPU。TI的数据显示其性能可达ARM Cortex-A15带NEON单元的8倍以上。这种设计实现了“专芯专用”CPU和GPU继续无忧无虑地负责流畅的UI交互和娱乐功能DSP和EVE则默默地在后台处理多路摄像头数据流进行图像分析和增强。两者通过高速片上互联共享内存数据互不干扰真正实现了信息娱乐与ADAS感知的并发执行。2.3 软件兼容性与投资保护对于车企和Tier 1更换硬件平台意味着巨大的沉没成本BSP板级支持包、中间件、应用框架、测试认证都需要推倒重来。Jacinto 6 Ex的聪明之处在于其与Jacinto 6系列的引脚兼容性和软件兼容性。引脚兼容意味着在设计初期硬件工程师可以设计一个兼容Jacinto 6和Jacinto 6 Ex的PCB底板。如果项目初期只需要基础IVI功能就使用Jacinto 6如果后期需要增加高级环视或驾驶员监控可以升级为Jacinto 6 Ex而无需改动主板布局只需在软件层面启用新的加速器驱动和算法。软件兼容性则更深一层。操作系统、设备驱动、上层应用服务框架都可以复用。开发者的任务从“移植整个系统”变成了“集成新的视觉算法库”和“开发新的ADAS应用服务”。这极大地降低了开发风险和时间保护了已有的软件投资使得“软件升级”之路真正可行。3. 技术实现深度解析芯片内部的协同作战3.1 处理器架构全景与数据流要理解软件如何升级必须先看清硬件提供了什么舞台。Jacinto 6 Ex是一个复杂的片上系统SoC我们可以将其核心单元分为三大阵营阵营一通用计算与图形处理继承自Jacinto 6双核ARM Cortex-A15主应用处理器运行车载操作系统如Linux或QNX和所有上层应用导航、音乐、设置等。它是系统的“大脑”和总调度员。双核PowerVR SGX544 GPU负责所有3D图形渲染包括仪表盘、中控动画、3D地图等确保视觉流畅。IVA-HD视频加速器硬件编解码器处理视频播放、录制等任务。多个ARM Cortex-M4核心负责实时性要求高的中断处理和外设控制如CAN总线通信、电源管理等。阵营二信号与视觉加速Jacinto 6 Ex新增/增强的核心双C66x DSP这是高精度浮点和定点运算的能手。DSP-1可能被分配给传统的音频处理流水线收音机解码、多区音频、主动降噪。DSP-2则被解放出来专门处理视觉预处理任务。例如从四个鱼眼摄像头采集来的畸变图像需要经过复杂的“去鱼眼”畸变校正和视角变换才能拼接成一幅完整的360度顶视图。这个过程中的大量像素坐标换和插值运算正是DSP的强项。双嵌入式视觉引擎EVE这是算法加速的“涡轮”。每个EVE包含一个优化的向量协处理器和一个32位RISC核。视觉算法中的核心操作如卷积运算用于特征提取、池化、非线性激活等可以被编译成高效的微码在向量协处理器上并行执行。例如一个轻量级的卷积神经网络CNN模型用于识别交通标志或检测驾驶员是否闭眼其前向推理过程可以大部分卸载到EVE上执行速度极快且功耗极低。阵营三数据高速公路与后勤共享资源高速片上互联网络确保CPU、DSP、EVE、GPU等所有主设备能够高效、低延迟地访问共享内存中的数据如图像帧缓冲区。丰富的外设接口包括多路CSI-2摄像头串行接口用于连接环视、驾驶员监控摄像头、视频输入端口、显示输出端口等这是连接物理传感器和屏幕的桥梁。数据流示例以360度环视功能为例采集四个鱼眼摄像头通过CSI-2接口将原始图像数据写入DDR内存中的指定缓冲区。预处理DSP主导DSP-2读取原始图像运行畸变校正和视角变换算法将四幅畸变图像“拉直”并投影到统一的鸟瞰图坐标系中。处理后的子图像写回内存。拼接与合成CPU或DSP主导A15 CPU或DSP根据校准参数将四幅子图像无缝拼接成一幅完整的360度顶视图。同时CPU可以调用GPU渲染虚拟车辆模型和动态引导线叠加到顶视图上。显示最终合成的画面通过显示子系统输出到中控大屏。并发保障在整个过程中A15 CPU和GPU仍然有充足的资源来响应用户的触控操作、播放背景音乐、更新导航信息实现真正的功能并发。3.2 软件栈的关键分层与职责在硬件之上软件栈的设计是功能能否稳定、高效运行的关键。一个典型的信息型ADAS软件栈可分为以下几层1. 硬件抽象层HAL与驱动程序这是最底层直接操作硬件。TI会提供完善的芯片支持包SDK包含摄像头驱动配置CSI-2接口管理图像传感器的启动、参数设置曝光、增益和图像数据捕获。DSP/EVE驱动提供加载代码、启动/停止加速器、管理内存访问的接口。对于EVE通常会提供一套精心优化的内核库Lib里面包含了常用视觉算子如Sobel滤波、积分图计算、卷积等的微码实现。内存管理驱动确保不同处理单元CPU、DSP、EVE、GPU能够安全、高效地共享图像缓冲区避免数据竞争和内存碎片。2. 中间件与框架层这是承上启下的核心负责资源管理、任务调度和数据流编排。视觉处理管道框架例如基于GStreamer或自定义的媒体框架可以构建一个可视化的处理管道。每个节点Node代表一个处理环节如“捕获”-“畸变校正”-“拼接”-“叠加UI”-“显示”。框架负责将每个节点绑定到合适的计算单元CPU、DSP、EVE上执行并管理节点间的数据传递。这种设计使得算法替换和流程调整变得非常灵活。计算库除了EVE内核库还可能包含针对C66x DSP优化的数学库如TI的DSPLIB和针对ARM CPU优化的计算机视觉库如OpenCV的NEON加速版本。IPC进程间通信机制由于视觉处理可能运行在独立的实时进程或DSP/EVE上需要高效的IPC如TI的IPC框架来与运行在A15上的主应用进行通信传递处理结果如“检测到行人”事件。3. 应用与服务层这是最终功能的体现。ADAS功能服务以后台服务或守护进程的形式运行持续调用中间件提供的视觉管道处理摄像头数据并生成结构化信息如车辆周边障碍物距离、驾驶员头部姿态。HMI应用这是用户直接交互的界面。它订阅ADAS服务发布的信息并以直观的方式呈现。例如环视应用负责显示拼接后的全景画面驾驶员监控应用可能在检测到疲劳时在仪表盘上显示一个咖啡杯图标并发出声音警告。系统管理负责功能的启动、停止、模式切换如挂入R挡自动启动环视以及与其他车辆系统如车身控制器的通信。3.3 性能评估与资源划分实战纸上谈兵终觉浅资源规划必须落实到具体的数字上。以Jacinto 6 Ex为例我们需要对关键计算资源进行预算。DSP算力分配示例假设一颗C66x DSP核心运行在1GHz。TI提供的用例估算如图3所示给了我们一个很好的参考用例A基础信息娱乐运行HD Radio多天线接收分集算法MRC和DAB链接等可能占用约600 MHz的DSP算力。用例B增强音频在用例A基础上增加全车主动降噪ANC和复杂的多声道音频后处理如虚拟环绕声总占用可能达到约1000 MHz。剩余算力在用例B的情况下单颗DSP已接近满负荷。此时第二颗DSPDSP-2的价值就凸显出来了。它可以完全用于视觉任务例如360度环视的图像预处理这可能需要300-500 MHz的算力。两颗DSP分工明确互不抢占资源。EVE算力评估EVE的性能通常用每秒可执行的百万次操作MOPS或针对特定算法的帧率FPS来衡量。例如一个用于前向车辆检测的经典HOGSVM算法经过优化后部署在EVE上处理一幅VGA图像可能仅需几毫秒。两个EVE并行工作可以同时处理多路摄像头数据或者运行更复杂的算法如语义分割。内存带宽考量视觉处理是数据密集型任务。四路720p30fps的摄像头原始数据流其带宽需求是巨大的。必须仔细规划DDR内存的访问使用Tiled分块内存布局这种布局能提高2D图像数据的缓存命中率对GPU和EVE这类访问具有空间局部性的处理器尤其友好。零拷贝Zero-copy架构尽可能让不同处理单元通过物理地址共享同一块图像缓冲区避免在CPU、DSP、EVE之间来回拷贝数据这是降低延迟和节省带宽的关键。缓存一致性管理当CPU和加速器都需要访问同一数据时需要硬件或软件来维护缓存一致性否则会导致数据错误。Jacinto平台通常有对应的硬件支持但需要在软件中正确配置。注意性能评估的黄金法则永远不要只看峰值算力TOPS/GFL OPS。必须基于具体的算法、实际的输入数据尺寸和期望的帧率在目标硬件上进行原型实测。早期进行性能剖析Profiling找出热点函数并针对DSP/EVE进行优化是项目成功的关键。4. 典型功能实现与软件升级路径4.1 功能一360度全景泊车辅助Surround View这是信息型ADAS中最经典、最直观的功能也是展示软硬件协同能力的绝佳例子。硬件前提车辆前后左右需安装四个广角通常为190度鱼眼摄像头。这些摄像头通过同轴电缆或以太网将视频流传输至IVI主机的视频采集接口。软件升级包内容新的像头驱动与校准工具升级包需要包含支持新增摄像头型号的驱动。更重要的是一个用于产线或4S店的标定工具软件。车辆需要在特定场地如棋盘格标定布上运行该工具自动计算每个摄像头的内参畸变系数、焦距和外参安装位置和角度并生成一个唯一的校准文件烧录到车机中。图像处理算法库鱼眼畸变校正模块基于相机标定参数将弯曲的图像还原为直线视角。这个模块通常高度优化运行在DSP上。视角变换与图像拼接模块将校正后的四幅图像根据预设的鸟瞰图模型进行透视变换然后寻找重叠区域的特征点进行对齐和融合生成无缝的全景顶视图。拼接的核心算法如特征提取、配准可以部分放在EVE上加速。虚拟车辆模型与动态引导线渲染由GPU负责将3D车辆模型和根据方向盘转角动态计算的轨迹线实时叠加到全景画面上。新的应用程序与UI一个全新的“全景泊车”应用提供2D/3D视图切换、视角选择如单侧视图等功能。升级流程对于已出厂车辆车主可通过OTA或到店升级的方式下载一个包含上述所有新软件组件的升级包。升级过程由IVI系统自身的刷新机制完成。升级后系统检测到新增的摄像头硬件或激活了之前未使用的摄像头接口并加载新的驱动和应用程序。当用户挂入R挡或手动激活时新的处理流水线启动功能即可使用。4.2 功能二驾驶员状态监控Driver Monitoring System, DMSDMS是提升主动安全的重要功能通过面向驾驶员的内置红外摄像头实时分析驾驶员的面部特征。核心算法流程人脸检测与跟踪从视频流中快速定位驾驶员人脸。可使用基于EVE优化的轻量级目标检测算法如MobileNet-SSD。关键点定位精确定位眼睛、嘴巴、头部姿态的关键点。这同样是一个计算密集型任务适合在EVE上运行专用算法。状态分析疲劳检测基于PERCLOS单位时间内眼睛闭合时间所占比例等指标结合打哈欠频率。分心检测通过头部姿态估计判断驾驶员视线是否长时间偏离前方道路。身份识别通过面部特征进行快速驾驶员身份识别用于个性化座椅、空调等设置。预警与交互分析结果通过IPC传递给主应用触发视觉图标、声音提示音或触觉方向盘震动预警。软件升级挑战DMS对实时性要求比环视更高通常需要30fps以上的处理速度且算法更为复杂。升级包需要包含高度优化的、针对EVE平台的人脸分析算法库。此外由于涉及生物特征信息软件设计必须考虑数据安全和隐私保护确保图像数据在本地处理不上传云端。4.3 功能三增强现实导航AR Navigation将导航指引线、POI信息直接叠加在实景道路画面上大幅提升指引直观性。实现原理前视摄像头视频流获取道路实景。车辆定位与姿态感知结合GPS、IMU惯性测量单元和车辆CAN总线数据车速、转向角精确计算车辆在三维世界中的位置和朝向。空间映射与渲染根据定位信息计算出导航箭头、车道线等虚拟元素在摄像头画面中的准确3D位置。然后由强大的GPU如SGX544进行实时3D渲染将虚拟元素与实景视频帧进行Alpha混合。EVE的辅助角色EVE可以用于辅助车道线检测为定位提供额外的视觉约束提高在隧道、城市峡谷等GPS信号弱区域的定位精度。升级考量AR导航需要非常精确的摄像头与车辆坐标系的标定外参并且对GPU的3D渲染性能有较高要求。升级前需评估现有Jacinto 6平台的GPU是否足以在运行复杂UI的同时再负担AR的实时渲染。Jacinto 6 Ex更强的图形性能为此提供了保障。5. 开发实战从芯片评估到功能集成5.1 开发板选型与初期评估对于想要尝试此方案的车企或Tier 1第一步是获取合适的开发套件。TI官方评估板EVM这是最佳起点。TI会为Jacinto 6 Ex提供功能完整的评估模块包含所有必要的外设接口多路CSI-2、LVDS显示输出、车载以太网等、参考设计原理图和完整的软件开发套件SDK。核心任务在EVM上快速搭建基础软件环境Linux或QNX BSP并运行TI提供的演示程序Demo。例如一个多路摄像头采集和显示的Demo可以验证硬件接口是否正常。一个在EVE上运行简单目标检测的Demo可以直观感受其加速性能。评估要点算力基准测试使用TI提供的或自编的基准测试程序实测DSP和EVE在处理典型算法如图像畸变校正、SIFT特征提取、小规模CNN推理时的实际帧率和CPU占用率。内存带宽测试使用内存压力测试工具模拟多路视频流同时读写的情景评估系统带宽是否成为瓶颈。热设计评估在满负荷运行信息娱乐和ADAS演示程序时测量芯片关键点的温度。这关系到最终的散热方案设计。5.2 软件环境搭建与SDK剖析TI的SDK通常基于Yocto Project构建提供完整的交叉编译工具链、文件系统镜像和内核。关键组件处理器SDKProcessor SDK包含Linux内核、U-Boot、文件系统、所有外设的驱动。视觉分析SDKVision SDK这是重头戏。它提供了针对DSP和EVE优化的计算机视觉库、算法示例和一套用于构建视觉应用的数据流框架。深入理解其框架如TIAP的任务调度、内存管理和IPC机制是进行二次开发的基础。图形SDK包含GPU的驱动、OpenGL ES/OpenCL的实现用于UI和AR渲染。开发环境通常在Ubuntu主机上搭建交叉编译环境通过JTAG或网络进行调试和部署。5.3 算法移植与优化实战这是最具挑战性的环节。假设我们有一个用C和OpenCV编写的原型算法需要移植到Jacinto 6 Ex上并高效运行。步骤一性能剖析与热点定位在x86 PC上使用性能分析工具如gprof, VTune运行原型算法找出最耗时的函数热点。通常是图像金字塔构建、特征提取、分类器计算等环节。步骤二任务拆分与异构映射根据硬件特性将算法流水线拆分成多个阶段并分配到合适的计算单元图像预处理缩放、色彩空间转换数据并行度高适合在DSP上使用DSPLIB进行优化或利用EVE的向量化能力。特征计算如HOG、LBP包含大量循环和矩阵运算是EVE的绝佳目标。需要将OpenCV函数调用重写为调用EVE内核库的代码。分类/推理如SVM、小规模CNN同样适合EVE或DSP。对于CNN可能需要使用工具如TI的MMALib或第三方AI编译工具将训练好的模型转换为在EVE上运行的微码。后处理与逻辑控制适合在ARM CPU上运行。步骤三针对EVE/DSP的深度优化数据对齐EVE和DSP对内存访问对齐有严格要求必须确保输入/输出缓冲区按指定字节对齐如128字节否则性能会急剧下降。内存布局使用Tiled布局存储图像可以极大提升EVE访问数据的效率。内核调用尽量减少主机CPU与加速器之间的通信开销。一次传输大量数据启动一次EVE任务处理而不是频繁启动小任务。流水线并行利用多个EVE核心和DSP核心将不同的处理阶段流水线化实现更高的吞吐量。步骤四系统集成与调试将优化后的各个模块集成到Vision SDK的框架中。使用框架提供的日志、性能计数器和调试工具确保数据流正确资源无冲突。特别注意多线程/多核环境下的同步问题。5.4 系统集成与测试验证当各个ADAS功能模块开发完成后需要将其集成到完整的IVI系统中。资源冲突测试模拟最极端的使用场景——同时进行高清视频播放、复杂导航渲染、四路环视处理、驾驶员监控和语音识别。使用性能监控工具观察CPU、GPU、DSP、EVE的负载以及内存带宽占用确保无资源枯竭导致的卡顿。功能安全如果适用即使信息型ADAS不要求ASIL-B/D也应进行基本的失效模式与影响分析FMEA。例如摄像头被遮挡或污损时系统应能检测并提示用户而不是输出错误信息导致误导。用户体验测试功能启动速度、画面延迟从事件发生到屏幕显示的端到端延迟、提示的准确性和及时性都需要在实车环境下进行大量测试。6. 挑战、陷阱与未来展望6.1 主要挑战与应对策略实时性保证信息娱乐系统运行的是非实时操作系统如Linux而视觉处理有严格的帧率要求。策略将高实时性的视觉处理任务放在由RTOS如TI的SYS/BIOS管理的DSP或EVE上运行或者为Linux内核打上实时补丁PREEMPT_RT。使用高优先级的线程和实时调度策略。内存管理复杂性多个主设备共享DDR improper management leads to corruption or performance collapse.策略严格使用SoC厂商提供的缓存维护API和内存分配器如CMEM。在设计初期就规划好各模块的内存池避免动态分配碎片。散热与功耗满负荷运行时芯片发热量可观。策略在硬件设计阶段就做好热仿真预留足够的散热空间。在软件层面实现动态电压频率调整DVFS和温度监控在过热时主动降频或关闭非核心功能。软件复杂度与可靠性异构编程模型CPU, DSP, EVE大大增加了软件开发和调试的难度。策略充分利用厂商提供的框架和工具链遵循其最佳实践。建立严格的代码审查和模块测试流程。考虑使用更高级的编程模型如OpenCL来提高可移植性但需评估其对性能的影响。6.2 常见陷阱速查表陷阱描述后果规避方法忽视缓存一致性加速器处理后的数据CPU读到的仍是旧值导致算法错误。在CPU访问由加速器修改的内存区域前必须执行缓存无效化Cache Invalidate操作。内存未对齐访问EVE/DSP访问未对齐数据时触发异常或性能暴跌。使用malloc时用posix_memalign替代确保分配的内存地址按硬件要求对齐。DSP/EVE代码中调用标准库DSP/EVE运行环境通常是裸机或轻量级RTOS不支持完整的C库。仅使用TI运行时支持库RTS或手动实现所需函数。避免printf,malloc等。低估中断延迟摄像头数据就绪中断得不到及时响应导致帧丢失。优化中断服务程序ISR仅做必要操作如置标志将繁重任务交给工作队列。为中断分配高优先级。未做热设计评估产品在高温环境下长时间运行死机或重启。在原型阶段进行热成像测试确保散热方案满足最坏工况下的热功耗。6.3 未来演进方向Jacinto 6 Ex的理念在今天的汽车芯片领域已成为主流。其后续演进方向非常清晰更强的AI算力后续平台如Jacinto 7集成了更强大的AI加速器如矩阵乘法加速器专门用于运行更复杂的神经网络模型实现更精准的目标检测、语义分割甚至场景理解。更高程度的融合随着芯片算力的提升和软件虚拟化技术的成熟未来一个高性能SoC可能通过硬件虚拟化同时运行信息娱乐域Linux/QNX、仪表域AUTOSAR和低等级ADAS域AUTOSAR Adaptive的软件真正实现“一芯多域”进一步降低成本与复杂度。云-端协同本地芯片处理实时性要求高的感知任务而复杂的模型训练、高精地图更新、长尾场景处理则交由云端。通过OTA本地算法模型可以持续迭代优化。通过软件升级将信息型ADAS集成到现有信息娱乐系统绝非简单的功能堆砌而是一场对系统架构、软硬件协同设计能力的深度考验。它要求开发者从传统的分层开发思维转向以数据流和算力调度为中心的异构计算思维。成功的关键在于吃透硬件特性精心设计软件架构并在性能、功耗和成本之间找到最佳平衡点。这条路虽然充满挑战但它为汽车功能的快速迭代和个性化升级打开了一扇全新的大门让我们的座驾在出厂后依然能不断“成长”变得更安全、更智能。