我觉得电动汽车带来了重大的历史机遇，很多地方都会带来改变，这里既有传统动力总成转向电动汽车独特的东西，而随着电动汽车本身发展对原有的电子架构产生了深刻的影响。

而在这块也正是我们对于底盘、动力总成和网联，这几个Domain重构，我们在通往这条路上该怎么看待、怎么选择和怎么执行和操作，都需要跨领域的探讨。

这次我和我的几位少壮派好友，仔细做了一个探讨，在采访和汇总的基础上，做了篇习作，请大家参考。

本文的话题是“MEB新一代的汽车电子架构展望”，主要包括：

1.架构需求

2.架构准则

3.软件架构

1）虚拟化

2）操作系统

3）Adaptive AUTOSAR

4）服务为导向的软件架构

5）网络通信

6）功能分配

7）开发模式

4.控制器硬件

早一些的时间，我在整理有关大众电气化的发展，特别是有关MEB还有后续豪华车电动平台的信息，在整车平台，特别是电动汽车的布置、核心电池和驱动系统上做了很大动作的勾画。

而我的友人也谈及，在MEB的电子电器方面，德国人也做了很多的内容。

一直以来VW对于电子部分公开的信息比较有限，通过几份介绍资料以及以往对于一些技术发展的研究，可以一探MEB有关电子/软件架构的动向；

对于未来MEB的电子架构还是明显感觉汽车电子的技术发展真的非常快，应用速度不断加快。

传统整车企业的领导层都感受到了技术的发展对于自身开发的压力，特别是受到以快打慢，讲究体验和迭代的IT，互联网巨头竞争的压力。

顺应消费者的诉求，整个汽车行业也不得不快速与数字世界融合中，不管从研发，制造到服务都处于数字化的演变中。

这个制高点，我们来看看德国大众是怎么做的。

以下这些是摘录的部分大众有关MEB新闻稿，从中可以看出，在战略上大众造车理念表达出来有了很大的延伸和变化。

Analog zur „Apple ID“ benötige auch Volkswagen eine entsprechende persönliche ID, die er in seinen Folien „Group ID Mobility“ nennt, „damit unser Kunder an all unsere Produkte gebunden wird und sich immer wieder zurechtfindet – und das funktioniert schon recht gut.“ All das müsse „natürlich über Fahrzeug-Generationen hinweg funktionieren“. Und das ist sehr wichtig: „Wer das richtig macht, der bekommt die Kunden, denn sie sind froh, wenn sie datentechnisch vernünftig aufgehoben sind und die Funktionen bekommen, die sie auch haben möchten.“

by Ralf Milke, Leiter E/E-Entwicklung Karosserieelektronik und Bordnetz bei der Volkswagen AG

MEB从用户体验出发设计整车功能（Feature)，试图把数字化生活拓展到车上，使得车辆成为数字化生活的一部分，并且借鉴Apple模式来开发整车。

Apple有自己的用户体验/UX设计，以及封闭成熟的iOS，性能领先的64位处理芯片。

如果要对标Apple，需要从这些维度去构建MEB的技术优势。

1、架构需求

电子电器架构开发之初需要定义技术开发需求，大众MEB电子电器架构的需求慢慢朝个人数字生活需求转变，“MaaS”的理念应该会在这代MEB的电子架构平台上展现。

从以下这张图上可以看出MEB的功能需求定义已经更为拓宽。

大众两代架构平台对比 摘自 Vector Congress 2016

•Auto. Driving这个不用说，这两年炒得火热，基于它可以衍生出很多功能应用与消费场景；

•Digitalization可以跟“ID”更紧密地联系起来。

这些需求下开发的技术功能会迭代以及更新并且新的功能会在消费者手中时发布，APP Store概念也会从手机/电视端往车辆发展。

传统OEM的“功能手机”时代应该会加速切换。

2、架构准则

在Bosch发布的关于电子电器架构发展趋势报告中，就把“域”控制器以及整车级”计算平台“的需求描绘出来，当下各大OEM也都在加紧部署”域“DCU。

Bosch 电子电器架构趋势报告

不管是”域“也好，”大脑“也好，核心是需要设计开发准则Criteria

•哪些功能应该放在一起？

•哪些需要独立分布？

•哪些需要频繁升级更新？

这些开发准则可以相互借鉴，但各家有各家的实际情况，车型种类/产量/市场定位都不一样。

当然如果采用跟随战略通常做法，但是看下现今的手机市场，如果汽车市场未来的集中度越来越高，那么各家OEM就得寻找差异化的竞争力，架构策略会有不同。

MEB走个人数字方向，那么个性化的需求要求下，软件差异性化，升级迭代, 软件功能订购是必须。

现在很多车上都已经宣传个人的信息帐号系统已经建立了，软件也在更新换代，OTA已经实现。

我想这只是部分功能（Infotainment为主）的帐号关联，如上文提到的把车作为MaaS的话，需要关联的功能还有许多。

3、软件架构

虚拟化

功能开发就不得不提功能安全与网络信息安全，这两块在欧洲OEM是与功能开发相同步的流程。

为了让不同Safety/Security级别的功能能够合理有效的实现，需要对系统的底层硬件与软件做技术升级。

汽车电子的虚拟化也已经到来，hypervisor虚拟化能够直接从硬件层面分割硬件资源保持片上多软件系统独立。

对多核处理芯片进行硬件资源隔离降低信息安全/功能安全的隐患

备注：最近爆出的intel/arm Spectre与Meltdown漏洞是对汽车芯片也有影响的，至今没有看到有效修补方案，硬件层面的漏洞需要在内核设计中优化，不能短期完成

大众Adaptive AUTOSAR框架 摘自 Vector Congress 2016

从整体上未来各家OEM在整车主干网上的主节点（域控制器）将会虚拟出多个封闭软件系统。

•传统汽车基础软件供应商正在加快开发hypervisor适配域控制器内那些多核汽车微控制器

•传统消费电子类芯片巨头INTEL/Nvidia也在加快进入汽车电子领域，他们除了提供芯片技术以外虚拟化解决方案也一起打包

随着未来数据计算力要求越来越高，消费电子类巨头抢占汽车核心处理芯片的趋势越发明显，而传统的汽车电子供应商的芯片则更多的在安全领域，终端执行，感知层面出现。

为了适应数字生活，在娱乐域控制器引入互联网的解决方案能够有效解决车与外界的数据交互，同时也能有效解决信息安全。

操作系统

除了硬件虚拟化外，基础软件/操作系统也在进行改变。

当今的汽车软件操作系统，除了娱乐系统，

•动力/底盘/车身系统大部分都采用实时操作OSEK/AUTOSAR OS，

•VW在MEB上的域控制器已经切换成POSIX OS与Adaptive AUTOSAR，

•当然classic AUTOSAR还会继续存在，Safety相关的还需要依赖与Classic（safety） AUTOSAR。

很快就可以看到在一块芯片上既能跑Linux，QNX又能跑传统AUTOSAR OS的控制器。

对于高性能计算能力系统需要POSIX OS, 支持如GPU的计算。

同时需要集成满足车载通讯要求的网络通信协议栈，UDPNM, DOIP, SOME/IP以及支持时间同步的802.1AS。

而这些在当前的OS基础软件中没有提供，需要陆续部署。

对于POSIX OS本身，大家普遍青睐于Linux，开源可以带来自由定制，但是开发之初未涉及到汽车控制领域，对于任务调度/抢占机制还在优化过程中。

虽然也有Tier1与OEM在使用QNX，但是一旦涉及到深度软件定制开发，那么QNX本身的开放程度将会决定未来可以应用范围。

Adaptive AUTOSAR

Adaptive AUTOSAR也是必须底层软件涉及的部分，虽然像Linux也有很多现成的驱动底层，对于汽车行业的控制软件涉及车辆安全所以不得不提出自己本身的软件要求；

同时为了满足统一的接口要求，才会对现有POSIX软件生态体系提出Adaptive AUTOSAR。

从2017年开始Adaptive AUTOSAR释放第一版规范，但是Adaptive AUTOSAR还处于开发模式阶段，会每６个月更新版本；

2018/10将释放第一个完整版本，后续将会与Classic AUTOSAR R4.4.0同步。

虽然要到18年10月才能冻结，且第三方软件供应商会较标准滞后；

但像VW这样的业内巨头，完全会提前获得对应版本的软件（Autosar的白金会员名单，这些OEM，Tier1是定义标准规范的主力）

服务为导向的软件构架

为了面对个性化的需求，功能软件开发需要更敏捷，而基于此Service oriented Architecture (SOA)是完成这项任务的关键，它能够建立动态的实时网络通信关系，把车内各个IP节点根据功能要求进行应用层服务的数据建立交互。

SOA 架构与服务分布

在AUTOSAR中基于TCP/UDP之上定义了SOME/IP通信模块能够支持SOA架构通信的需要，当然在AUTOSAR标准中SOME/IP也是逐步部署的。

可参考http://some-ip.com 对SOME/IP的roadmap的介绍

•AUTOSAR 4.0 – basic support for SOME/IP messages already existing.

•AUTOSAR 4.1 – support for SOME/IP-SD and Publish/Subscribe was added.

•AUTOSAR 4.2 –the transformer was added for serialization as well as other optimizations.

•AUTOSAR 4.3 – fixing some transformer bugs, adding support for large UDP messages with SOME/IP-TP as well as SOME/IP-SD optimizations.

在自动驾驶领域内，尤其是在高阶自动驾驶场景中，数据交互量要求巨大，未来基于SOME/IP构建大数据传输还有待验证。

至少从Audi zFAS上看到并未采用SOME/IP作为其中间件，在确定性网络内需要动态组网应用场景还比较少，但是考虑未来功能升级需求，还是需要研究实现大规模数据传输的组网协议。

网络通信

车内网络指的是IVN （In Vehicle Network）

V2X/V2V需要与国家，地区通信基础设施规划同步，且DSRC非国内主流，暂时没有太多关注

国内的5G部署速度会很快，所以考虑V2X的场景还是结合中国自身情况

对于MEB这样的真正的网络开发需要包含更多的实际设计要求：

•100BaseT1与1000BaseT1的标准化使得以太网已作为主干网络的首选，而且整车需要增加冗余设计；

•基于AVB/TSN以太网通信规范将成为网络核心底层协议；

•确定性网络数据调度设计，保证控制系统时延要求；

CAN到现在还是车辆内部主要网络通信技术的主要原因就是能够满足控制功能的时间延迟，信号优先级抢占等要求；

在现有整车电子架构框架下的网络信号路由需求也可以由通信核心的网关实现，当然在一些中高档车上已经有MOST/FlexRay子网，Ethernet主要应用于DoIP与AVB。

备注：FlexRay这个东西能坚持多久，渗透多大范围不乐观。

不久的将来TSN能够把传统以太网改造成与CAN类似的具有优先级抢占功能网络总线技术，同时基于控制功能信号流需求，实现硬件级的网络调度设计。

硬件层面参考如下图所示，软件层面AUTOSAR也在逐步发布，但是核心的信号基于时间触发的调度设计需要由软件协议栈确保Worst Case场景下的时延满足功能（应用）软件需求，在现有以太网案例中都有TTTech的身影，后续从OEM核心利益出发这块的设计包括软件开发应该会由自己来掌握。

以下这张是NXP以太网网关芯片选项表，可以看到大的车企对芯片供应商的要求有哪些。

当然业界还有一家在车载以太网加速布局, 可以看到TSN基本协议在MAC/PHY中已经部分实现。

在某些材料上，未来在某些应用中规划10G带宽传输。

按照现在的车载以太网标准时间表，很难在2020年实现车规级的规范发布，而且底层的线束需要从UTP/STP切换成光纤。

另外随着带宽提高对于主芯片的缓存/内存读写能力要求将大大提高，看到Intel Go平台已经把PCIe总线也加入进来，汽车电子发展真的是太快了！！！

Intel自动驾驶平台系统结构图(包含主要总线技术）

功能分配

域控制器因为有强大的硬件计算能力与丰富的软件接口支持，使得更多核心功能模块集中于域控制器内，系统功能集成度大大提高，这样对于功能的感知与执行的硬件要求降低，加之数据交互的接口标准化/网络化，会让这些零部件变成标准零件，从而降低这部分零部件开发/制造成本。

简而言之，外围零件只关注本身基本功能，而中央（域）控制器关注系统级功能实现。

大众MEB ICAS软件功能规划策略 摘自 Vector Congress 2016

由于大众一向是分布式系统模块化的倡导者，以后哪些ECU合并，算法合并还有哪些功能简化降级，在接下来的信息发布过程中非常值得关注

开发模式

上层应用程序可能来自不同的供应商，那么软件开发流程以及后期的集成测试验证也会带来更大的挑战，传统的供应商与OEM的合作模式已经发生变化，Tier1不再是大包大揽，OEM以及第三方软件供应商会更多参与进来。

如果硬件开发由另外的合作方负责，那么后续的软件/系统集成将是一个非常复杂的工作。

作为最终的负责方，OEM在系统开发中会担当越来越重要的角色，未来的成功将来自于全产业链的核心技术整合

软件的开发计划与硬件的开发计划相互独立，软件将会是全生命周期内迭代持续，且软件可能横跨更多不同硬件设备。

而以往的开发都是以零件SOP节点作为软件开发计划的参考时间，同时硬件方案是同步确定的。

未来隐藏在这个电动平台下面的软件整合工作，值得期待。

4、控制器硬件

传统主控制器主要还是基于32位Tricore,PowerPC以及850等架构的微处理器, 而对于海量计算,高速数据传输，传统架构体系已经无法满足上述应用需求，这也是为什么新架构内核芯片在积极进入汽车电子行业。

可以看看这两家最新的车载芯片都从已有的芯片平台往ARM上转移

对于Machine Learning, Deep Learning等技术在自动驾驶的场景的应用，需要提供额外的软硬件支持。

这也是为什么AI芯片，GPU等非汽车行业的计算硬件在汽车行业内受到重视。

未来对于域控制器内部的硬件必定要根据功能安全等级划分为Performance，Safety等不同类型的功能,根据不同类型的功能分配进入不同功能安全支持的芯片内。

从现有控制器硬件架构看多颗/多核芯片以及冗余架构是域控制器设计主流设计， 虽然MEB还没有提供官方硬件控制器信息，但是借鉴Audi zFAS自动驾驶控制器ZFAS，未来域控制器只会在此基础上增加更多高性能，可靠性的设计。

5、结束语

数字生活在国内已经由"互联网+"，"共享经济"的风口下比欧美发到国家领先了许多，但是汽车行业也正乘着这股热潮借由各种题材来展现美好的前景。

围绕个人的数字化应用入口已经由几家互联网巨头所把控，新的公司想成为其中一极越发困难。

而在个人数字生活中由一件硬件与两个账号是至关重要的，手机+微信/支付宝。

国内大部分人的数字生活有这3样东西构建，剩下的服务或者工具都可以在3样东西下授权与操控。

所以不知道MEB来到国内如何定位自己的数字生活中的角色。

对于手机行业，下面是2007年与2017年全球销量前5排行榜，在智能化以及中国品牌崛起的10年间原来4位领跑者已经退出了。

那么汽车行业的洗牌是否也在这股电动化，智能化风潮中已经到来？