大众“MEB平台”与“软件驱动的企业”：缓慢拉开的巨幕？

提起大众汽车，近年来的新闻报道不可谓不多，我们先来看下大众官方的说法，

...大众集团在11月17日公布了其调整后的长期和短期计划...经过调整的短期计划显示，大众集团在2024年之前将会在电动出行、混动车型等领域投资600亿欧元。而其长期计划则要求该集团在2029年前推出75款电动汽车和60款混动车型。

大众计划在2029年之前售出2600万辆纯电动汽车，以及600万辆混动汽车。其中，这2600万辆纯电动汽车中有2000万辆将基于大众MEB平台打造，剩下的600万辆将基于高性能平台PPE打造。

针对其转型电动化之举，媒体也各有说法；有说“大象转身”的、有疑问“胜算有几成的”、有认为“转型之路任重道远”的...不一而足；但是我们今天呢，主要是想站在一个汽车电子工程师的角度、根据网络公开的信息以及手头的部分资料、谈谈对大众的“MEB平台”以及Diess所说的“软件驱动的企业”的理解。

其中，关于MEB平台（Modularer E-Antriebs-Baukasten/Modular Electrification Toolkit，模块化电气化工具套件[1]），我前不久有整理一篇“关于大众MEB，你不得不知道的10件事！”，是官方的一手信息，大家可以参考。

此外，我还想做下铺垫的是大众此类决策的内在驱动力。

大众掌舵人、CEO赫伯特·迪斯（Herbert Diess）。

图1.车载软件的变化

当前：每辆车100 million行代码，例如：导航系统大约在20 million行代码

未来：整车代码量有望超过200~300 million行、L5自动驾驶车辆代码量将达到1 billion行[2]

图2.汽车将成为最复杂的联网设备

当前：功能分散、整车需要大约70个ECU、没有自己的代码

未来：3~5个高性能的计算单元+安全相关的ECU、开发大众自己的软件（包括基础软件：操作系统以及其他的应用软件）

迪斯还在后续的一个采访中具体谈到，

为什么要“接管过去为我们提供软件的供应商”？

当前的车辆软件代码量是智能手机的10倍，一辆具备自动驾驶能力的车辆甚至会是1000倍，各类ECU之间的通信交互太过复杂...在将来，软件将占到创新的90%、并且在未来的汽车中扮演重要的角色。它在汽车价值中所占的比例越来越大。

而在谈到大众的vw.os部门时，迪斯则直接表示，

大众未来的商业模式将更像一家手机公司。

大众汽车品牌董事会成员、vw.os操刀者克里斯蒂安·森格（Christian Senger）。

图3.遵循IT行业并在集团层面进行平台部署

图4.敏捷型组织架构/5个产品集群和4个横向功能构成的Car.SW Org

此外，森格在今年9月份的媒体采访时也进一步提到，

...未来1,100 多万台车要基于同一个电子架构，也就是说将来对某一款产品推出新功能就可以为所有产品所用。

未来我们将把车辆搭载集团内部开发软件的占比提升到60%...会减少供应商数量...内部软件开发部门有 1 万人团队。

将来的一个软件架构上能支持至少1500 万辆车，这在整个汽车行业内都将创造一个最优的成本结构...时机成熟时，把这些软件开放给集团外的其他品牌使用会是个合乎逻辑的决定。

提炼下迪斯和森格的内容，软件、成本、整车架构平台、IT，或许能对其内在驱动有个大概的了解。

...

好了，下面让我们进入正文部分，尝试下抽丝剥茧的过程。

一、MEB平台整车电气&软件架构

图5.一种实现可更新性和可升级性的新方法

应用软件和I/O功能解耦的、功能中心化的架构：

减少整个系统的复杂性和应用之间的依赖性；

高效、快速地开发用户功能；

提供一些用户功能所需的基本服务；

采用面向服务的通信。

先解释下：

“I/O功能”可以简单理解为硬件Input/Output，即Local ECU；

“面向服务”的通信即车载以太网。

图6.基础概念/功能集成化

车辆功能集中在几个强大的ECU中，即ICAS（In-Car Application-Server）；

传感器与执行器通过强大的网络，比如车载以太网、CAN-FD，连接到ICAS；

在ICAS中使用虚拟化技术整合许多不同的功能。

那么这两张图说了个什么事情呢？我认为主要有三点，

1、分层架构的思想，包括对整车ECU的重新分类、ICAS内部的软件架构（ICAS下一小节说）；

2、功能的集中化；

3、虚拟化技术。

可能有人要说，还有“更先进的总线技术（CAN-FD/Ethernet）呢”？资瓷当然是资瓷的，但是现阶段作为主干网络投入产出比低（传感器raw data之类的刚需除外）。

看完这两幅图，有没有一种似曾相识的感觉呢？

我们曾经在今年10月份翻译过一篇文章未来的汽车架构以及IT的发展趋势影响（我太喜欢这篇文章了...）——事实上这篇文章[3]由宝马工程师于2017年4月在IEEE Software 发表，考虑到MEB平台先期研发启动于2015年——欧洲人的想法还是蛮同步的，当然也少不了VECTOR“穿针引线”的功劳。

图7.BMW为下一代车型创建了一个分层的E/E架构

强大的集成平台实现了汽车领域的无缝分层的E/E架构

可以看出宝马相比大众进行了更细的划分，虽然没看到大众对Sensor/Actuator Level以及Computer Level的详细描述，可以参考下宝马的，分别对应Class 4和Class 1：

中央计算平台（class 1 - 图7的顶层）承担主要的软件功能，这部分主要由内部进行开发。这些平台能够提供较高的性能并且能够满足最高级别的安全需求。

集成控制器（class 2）衔接中央计算平台和商品控制器（class 3） - 例如，实时性需求高的功能要求能够直接访问传感器或者执行器。

对于简单的、OEM无特定需求的功能，由商品控制器和传感器或者执行器（class 4）直接实现是可接受的。理想情况下，这些控制器和传感器或者执行器是基于共同的OEM开发或者Tire 1的零部件。

PS，“商品控制器”（commodity ECU）这个词有点内味了、是不是很有感觉~

那么这么做有什么好处呢？我们这里列举几条，有官方说法、有个人理解。

1、与分布式功能相比，集中式实现的复杂性更低；

2、传感器/执行器ECU之间没有功能依赖；

3、传感器/执行器和高级车辆功能的分离增加了添加新功能的灵活性(功能更新)；

4、统一的开发方式（ICAS）取代本地（分布式的、数量巨大的ECU）开发方式；

5、集中化及虚拟化降低网络和软件的复杂性；

6、虚拟化则通过共享硬件资源节约成本。

详细的MEB平台架构拓扑（概念）我们下次找机会再详细探讨。

二、MEB平台ICAS架构

首先我们同步下认识，ICAS（In-Car Application-Server，车载应用服务）我个人更倾向于认为它是一个虚拟的概念，它的硬件载体即迪斯口中所说的“3~5个高性能计算单元（High Performance Computer）”，这个高性能计算单元根据车型可配置，但是搭载相同的ICAS的软件架构，即“通用软件框架”。

图9.数字化的关键：面向服务的架构（SOA）

使用服务发现和发布/订阅的动态绑定；

数据表示主要基于REST（表述性状态传递）-->统一接口、无状态、关注点分离...

接口的前后兼容性。

通过提高可更新、可升级、可复用和可移植的特性，能够轻松地通过即插即用的方式部署新功能。

图10.基于AP（Adaptive Autosar，Adaptive Platform）的通用软件框架

一个通用的软件框架能够带来：

用户功能/基础服务能够独立于ICAS和操作系统并行开发；

统一的方法论以及数据交换格式；

统一的更新以及通信协议。

图11.MEB平台ICAS架构

ICAS：In-Car Application-Server，车载应用服务

...

我给大家提炼下关键词：面向服务的架构（SOA）、CP（Classic AUTOSAR）、AP（Adaptive AUTOSAR）、通用软件框架...

我们先来看下ICAS的三层：通信服务层、基础服务层、应用服务层。没错，我又要祭出宝马下一代的E/E规划了。

图12.BMW在下一代E/E架构中引入的中央通信服务以及SOA的解决方案

为了方便大家理解，我做了一个对比表格。

下面我们再来依次看下，

1、面向服务的架构（Service Oriented Architecture，SOA）

直接贴上之前整理的材料吧，主要参考了伟哥的“汽车上为什么非要用SOA？”。

2、Classic AUTOSAR/Adaptive AUTOSAR

...做软件工程师时有翻译过AUTOSAR的标准（但是理解不深笑cry），现在想想、距离上一次敲代码7年过去了...市场急需一个强有力的推手啊。

...

那么，大众“MEB平台”到底要做一个什么事情以及“软件驱动的企业”背后到底意味着什么呢？答案也就逐渐明朗：一个全新的、足够先进（可升级性、可扩展性、可复用性以及可移植性）的汽车电气架构，基于CP/AP的通用软件框架、采用SOA的软件设计方法论并开发完整的软件开发工具链；按照集中式的原则重新进行功能分配、逐步接管供应商软件并开发大众自己的软件——包括操作系统及其他应用软件；出于成本考量在合适时机向竞争对手兜售该软件套件。

我的眼前仿佛浮现了一个庞然大物、趴在桌子上伸出了触角，吆喝着周围的玩家跟进。

...

与此同时，就在我们整理这篇文章的期间，关于大众MEB也接收到了各种不同的声音，

一种是“大众大肆宣扬电气化改革就是个幌子、一切都是为了股价”；

一种是“大众内部阻力重重、软件人才匮乏、转型之路任重道远”；

当然，当然看到媒体报道说大众正在解决大量软件问题时、第一时间查证了德国Manager Magazin的源报道并进行了翻译Manager Magazin：大众汽车正在努力解决ID.3的大量软件问题...老实讲如果此次手动升级之后就能够OTA，那进度还是可以的。谨慎乐观。

...

诚然，庞然如大众缓慢推开了电动化转型的巨幕，而对于传统车企来说，“软件定义汽车”的征程，一切都才刚刚开始。

最后，特斯拉牛逼！

[1]Wikipedia.Volkswagen Group MEB platform.Wikipedia,2019.11.13

[2]Volkswagen .Volkswagen.com.

[3]MTraub.Future Automotive Architecture and the Impact of IT Trends.IEEE Software,2017,34 (3) :4