大众汽车要大幅削减ECU的数量

最近大众CEO的一些想法很激进，通过媒体透露，未来是和现在完全不一样的，在迈向电动汽车的过程中，汽车电子和车内线束的变化可能真是翻天覆地（城门失火，殃及池鱼）。      

在德国沃尔夫斯堡大众集团12日的总部年度媒体会上，大众汽车CEO Herbert Diess表示，大众的汽车电子系统正在从分布式向集中式处理方式转换，计划将ECU（车载控制单元）功能集成起来，最终实现系统模块数量级的减少，核心架构从当前数十个甚至上百个控制单元减少到三到五个车载中央处理器。 以新高尔夫为例，需要用到200多个供应商提供的70个控制单元，如果减少到3到5个中央处理器，如果面向自动驾驶开发，原有的架构系统根本无法满足要求。

Volkswagen plans to improve its software’s robustness by reducing its cars’ 70 electronic control units “to three or four central on-board computers”. Herbert Diess announced restructure its software operations achieved by “taking over suppliers that in the past have delivered software to us”

Automotive 《VW Cutting ECUs From 70 to “3 or 4”》

Diss有关软件方面的介绍有下面三页：

这一页，我们也可以思考下，为什么汽车里面代码这么多？如果把70个ECU的底层代码、应用层软件进行统计，如果合并整合成为10个ECU，大量的通信消失了，大量的底层代码可以被share了。

这一页，是对比从之前的MQB平台往MEB平台的结构化的转换。说白了之前的功能软件的附加值对于车企来说比较低，而随着VW.OS提出，使得软件的事情随着ICAS车内服务控制器的导入，让供应商的工作回到了大众的手里。

备注：这一页是非常抽象的，在MEB的架构里面还有大量基于CANFD的从MQB演进过来的ECU，但是未来的MEB+呢，未来MEB架构推进到原有燃油车和插电的架构呢，这个变化就持续减少了

按照下面的说法，软件化的过程是逐步进行的，合作、收购、招人，开发In-house的软件能力和知识产权。

在这个里面，我们核心聚焦到大众所探讨的ICAS的软件开发过程

从大的划分来说，In-Car Application Server（ICAS）里面

是否包含原有安全的功能？有关电机的控制、电池的管理，还有底盘原有涉及安全的功能是否会拉进去

应用层的软件，是否完全自己开发？

基于ICAS里面原有Autosar Classic的部分和Autosar Adaptive的部分，是否都是自己In-house来操刀？

从目前的基于Autosar经典平台开发的汽车控制器来说，大量的软件工作都是供应商完成的，它的特点也是很清楚的，是面向特定实时性功能（硬实时，MCU根据软件任务来选、系统对RAM或Flash等资源具有较低的占用率），供应商会开发一个全的版本软件，基于功能固化之后，动态变更跟不上车企的要求。如果大众确定要把这块也全面接盘的话，确实只有少数的供应商能够存在自身长期发展的价值。

基于Adapative Autosar方面，一个是供应商没法完全提供足够的东西给大众，相信做VW API里面也要涉及大量的工作。

备注：我估计这事也是分阶段的，项目管理先上，最终这部分除了面向第三方软件的应用，其他都是内部体系独立开发。这里大众和Vector的工作分工，还有后者对外能输出的内容尚不得而知。

小结：大众比福特提出的软件定义汽车，因为有着MEB的投入，还有MEB的架构开发，VW OS的导入，我们能看到这些东西影响着我们。甚至我们对比通用的Global B的开发还有一系列对应的动作，这些都是对等的都是迈开步子去做出改变，切切实实让我们看到了这个行业未来的变化。