写在前面：
这篇文章是对岸一位汽车电子工程师"冷酷的冬瓜"写的文章的其中一篇，不想
看对岸用语的、不想看对岸人写的文章的，自己左转离开。
这篇文章主要是整理了VW 下一代的重要电动车平台 - MEB 到底跟以往有何不
同，跟之前的MQB 等各种燃油车平台不只是硬件上电池排放位置上的差别，更
重要的是汽车的软件架构的不同。
另外若是觉得他有写错或是有疑问的地方，按我以前的经验直接留言他是会回
覆的。
==============================以下正文==============================
来源：
https://www.weibo.com/ttarticle/p/show?id=2309404455994921975927
大众“MEB平台”与“软件驱动的企业”：缓慢拉开的巨幕？
╭────────────────────────────────╮
│大众“MEB平台”到底要做一个什么事情以及“软件驱动的企业”背后到 │
│底意味着什么呢？ │
╰────────────────────────────────╯
提起大众汽车，近年来的新闻报导不可谓不多，我们先来看下大众官方的说法：
╭────────────────────────────────╮
│...大众集团在11月17日公布了其调整后的长期和短期计划...经过调整 │
│的短期计划显示，大众集团在2024年之前将会在电动出行、混动车型等领│
│域投资600亿欧元。而其长期计划则要求该集团在2029年前推出75款电动 │
│汽车和60款混动车型。 │
╰────────────────────────────────╯
╭────────────────────────────────╮
│大众计划在2029年之前售出2600万辆纯电动汽车，以及600万辆混动汽车 │
│。其中，这2600万辆纯电动汽车中有2000万辆将基于大众MEB平台打造， │
│剩下的600万辆将基于高性能平台PPE打造。 │
╰────────────────────────────────╯
针对其转型电动化之举，媒体也各有说法；有说“大象转身”的、有疑问“胜
算有几成的”、有认为“转型之路任重道远”的...不一而足；但是我们今天呢，
主要是想站在一个汽车电子工程师的角度、根据网络公开的信息以及手头的部
分资料、谈谈对大众的“MEB平台”以及Diess所说的“软件驱动的企业”的理
解。
其中，关于MEB平台（M odularer E -Antriebs- B aukasten/Modular
Electrification Toolkit，模块化电气化工具套件[1]），我前不久有整理一
篇“ 关于大众MEB，你不得不知道的10件事！ ”，是官方的一手信息，大家可
以参考。
此外，我还想做下舖垫的是大众此类决策的内在驱动力。
大众掌舵人、CEO赫伯特·迪斯（Herbert Diess）：
https://i.imgur.com/rb0Agai.jpg
图1.车载软件的变化
╭─────────────────────────────────╮
│当前：每辆车100 million行代码，例如：导航系统大约在20 million行代 │
│ 码。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│未来：整车代码量有望超过200~300 million行、L5自动驾驶车辆代码量将 │
│ 达到1 billion行[2] │
╰─────────────────────────────────╯
https://i.imgur.com/i96hi8V.jpg
图2.汽车将成为最复杂的联网设备
╭─────────────────────────────────╮
│当前：功能分散、整车需要大约70个ECU、没有自己的代码 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│未来：3~5个高性能的计算单元+安全相关的ECU、开发大众自己的软件（包 │
│ 括基础软件：操作系统以及其他的应用软件） │
╰─────────────────────────────────╯
迪斯还在后续的一个采访中具体谈到：
╭─────────────────────────────────╮
│为什么要“接管过去为我们提供软件的供应商”？ │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│当前的车辆软件代码量是智能手机的10倍，一辆具备自动驾驶能力的车辆甚│
│至会是1000倍，各类ECU之间的通信交互太过复杂...在将来，软件将占到创│
│新的90%、并且在未来的汽车中扮演重要的角色。它在汽车价值中所占的比 │
│例越来越大。 │
╰─────────────────────────────────╯
而在谈到大众的vw.os部门时，迪斯则直接表示，
╭─────────────────────────────────╮
│大众未来的商业模式将更像一家手机公司。 │
╰─────────────────────────────────╯
大众汽车品牌董事会成员、vw os操刀者克里斯蒂安·森格(Christian Senger)：
https://i.imgur.com/7k3IJSp.jpg
图3.遵循IT行业并在集团层面进行平台部署
https://i.imgur.com/WJy0NK3.jpg
图4.敏捷型组织架构/5个产品集群和4个横向功能构成的Car.SW Org
此外，森格在今年9月份的媒体采访时也进一步提到，
╭─────────────────────────────────╮
│...未来1,100 多万台车要基于同一个电子架构，也就是说将来对某一款产 │
│品推出新功能就可以为所有产品所用。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│未来我们将把车辆搭载集团内部开发软件的占比提升到60%...会减少供应商│
│数量...内部软ﾥ騥}发部门有1 万人团队。 │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│将来的一个软件架构上能支持至少1500 万辆车，这在整个汽车行业内都将 │
│创造一个最优的成本结构...时机成熟时，把这些软件开放给集团外的其他 │
│品牌使用会是个合乎逻辑的决定。 │
╰─────────────────────────────────╯
提炼下迪斯和森格的内容，软件、成本、整车架构平台、IT，或许能对其内在
驱动有个大概的了解。
...
好了，下面让我们进入正文部分，尝试下抽丝剥茧的过程。
一、MEB平台整车电气&软件架构
https://i.imgur.com/Awk2qGV.jpg
图5.一种实现可更新性和可升级性的新方法
╭─────────────────────────────────╮
│应用软件和I/O功能解耦的、功能中心化的架构： │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│减少整个系统的复杂性和应用之间的依赖性； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│高效、快速地开发用户功能； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│提供一些用户功能所需的基本服务； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│采用面向服务的通信。 │
╰─────────────────────────────────╯
先解释下：
“I/O功能”可以简单理解为硬件Input/Output，即Local ECU；
“面向服务”的通信即车载以太网。
https://i.imgur.com/vguyMHS.jpg
图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“穿针引线”的功劳。
https://i.imgur.com/24ZNLmo.jpg
图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的软件架构，即“通用软件框架”。
https://i.imgur.com/ZtIsiem.png
图9.数字化的关键：面向服务的架构（SOA）
╭─────────────────────────────────╮
│使用服务发现和发布/订阅的动态绑定； │
╰─────────────────────────────────╯
╭─────────────────────────────────╮
│数据表示主要基于REST（表述性状态传递）