Benchmarks

软件定义汽车——箭在弦上的产业变革 | 3. 现状与未来的差距

图三：主流汽车制造商电子电气架构升级路径对比

数据来源:东吴证券、德勤研究

根据车企的公开规划,我们总结出了三种升级类型:第一类“一步到位型”,即跳过域集中阶段,直接走向车载中央计算,典型代表是特斯拉。以特斯拉为例,Model3采用了区控制器 (Zone Controller) 配合车载中央计算处理器 (CCM, Central Control Module) 的模式,CCM整合了驾驶辅助系统 (ADAS) 和信息娱乐系统 (IVI) 两大模块,剩余的域功能则根据物理位置就近布置(由左右两个车身控制模块负责),大幅减少车辆的线束成本。区控制器,在实现计算集中化需求的同时,还实现了整车物料成本平衡。第二类“激进型”,具体表现为不满足于tier-1给出的渐进式升级路线,根据主机厂认为的最优方案布置控制器,例如大众。第三类“按部就班型”,这类车企相对保守,基本沿袭tier-1企业给定的路线进行升级。

汽车将遵循IT行业规律,软硬件解耦整车电子电气架构升级的另一个驱动因素来自于软件层面。目前,无论是离散式的电子电气架构,还是汽车软件开发模式(ECU控制器采用嵌入式系统,即软硬件高度耦合,多以“黑盒模式”由供应商交付给主机厂),都很大程度限制了整车OTA功能的实现、应用生态的拓展以及未来未来主机厂掌握更高程度的软件开发主导权。具体而言:

首先,汽车软件的模块化、平台化程度低,导致软件资源无法集中调度、协作性差。 主机厂的ECU通常来自于不同的零部件供应商,事实上控制器上许多底层软件的重复性很高,这些代码主要保障控制器的正常运行,例如CAN总线信号的收发、

任务进程的调度、Flash数据的读写等等。但碍于每一家供应商的软件编程语言不同、接口标准不同,而且软件又和硬件高度依赖,使得这些底层代码无法被复制和移植,从而造成ECU软件开发的大量重复和资源利用的低效。

其次,软硬件高度嵌套、主机厂无法执行大规模、深层次的更新和升级或定制化开发工作。 分布式软件架构是一种面向信号的架构,控制器之间通过信号来传递信息,但整个系统是封闭、静态的,在编译阶段就被定义死,因此当发生例如主机厂要修改或增加某个控制器的功能定义,同时该指令还必须调用另一个控制器上的功能时,就不得不把所有需要的控制器都升级,大大延长开发周期、增加开发成本。

*软件定义汽车——箭在弦上的产业变革是一本德勤独立出版物,并未获得特斯拉、宝马、奔驰、大众等公司的授权,赞助或官方认证。

8