2019年11月12日 | 新一轮汽车开发变革，由汽车信息化开始 | 特约评论

作者介绍：

朱玉龙，资深电动汽车三电系统和汽车电子工程师，目前从事新能源汽车电子化工作，10年以上的新能源汽车专业从业经验，在电池系统、充电系统和电子电气架构方面有较深的认识和实践，著有《汽车电子硬件设计》，开设《汽车电子设计》公众号。

从大众的MEB汽车架构和汽车电子电气架构为起点，欧洲的几家汽车企业（大众、宝马、奔驰和沃尔沃）就开始了在汽车EE架构和新的基于车载高性能计算平台上的开发工作，这种改变一方面是由于特斯拉在很多领域跳跃式的开发方式引起，另一方面欧洲的主流及豪华车企敏锐的感受到消费者对于消费电子特别是手机的使用，对未来心目中炫酷和豪华汽车的认知，从现有基于动力总成、内饰等等比较传统的开发模式，到电子化+网络化+智能进化是有相似的期待的。

在目前已经公开的表态中，大众集团推进得最为迅速，也是让人感受到其非常雄心勃勃的战略。

如下图所示，从传统的一辆MQB车辆架构有近70个ECU，数量削减到3-5个核心的高性能车载计算平台（HPC），在这几个核心的HPC里面，主要的应用层软件都需要从传统的外包模式转向内部开发——在传统的开发中，是以ECU为形式划分，由200个供应商来负责实现，这将使得依托于大众体系的供应链中的许多环节变得多余而慢慢消亡。我们通俗的说法是汽车现在越来越由软件定义，从本质的看法来说，实现功能的软件的形式、作用、质量有效地决定了驾驶于拥有车辆的体验。如果大众集团的做法行得通，那么这样的做法将会迅速在欧洲和美国的汽车企业里面流行起来，所有有雄心的车企都希望牢牢控制决定产品个性化的核心技术。

图1 大众的转化是分为两个主要的点——车内的VW.os和大众的车辆云【1】

如下图所示，不同整车企业都围绕这个思路进行自上而下的开发，而不是之前交给Tier 1或Tier 2担当一个ECU的开发牵头者，原有的Tier1如博世、大陆、Aptiv等都作为主要的板级开发商和基础软件提供商，而车企则构建了相应的软件开发组织。

这里涉及到一个发展拐点的问题，网络架构的演化之前比较慢，主要的原因一方面是集中域控制的进展牵涉到很多的资源，并且迭代需要根据车型的更迭一步步进行，而电动汽车动力总成的迭代速度，使得“游戏规则”出现了一些变化，仅仅提供一定的续航和动力性并不够，还需要足够快的体验的支撑，才能在面向智能化的这波浪潮里面，足够快的打出牌来。

图2 BMW给出的未来EEA架构下车辆的主要技术要点【2】

● 计算平台：车载计算平台是软件和硬件高度集成的一部分。

■ 软件主要是操作系统的导入和虚拟化，对于高性能计算能力系统需要POSIX OS，支持如GPU的计算。同时需要集成满足车载通讯要求的网络通信协议栈，UDPNM, DOIP, SOME/IP以及支持时间同步的802.1AS。汽车电子的虚拟化也已经到来，hypervisor虚拟化能够直接从硬件层面分割硬件资源，保持片上多软件系统独立。从整体上来说，未来各家OEM在整车主干网上的主节点（域控制器）将会虚拟出多个封闭软件系统。传统汽车基础软件供应商正在加快开发hypervisor适配域控制器内那些多核汽车微控制器。

图3 HCP的软件架构

■ 硬件上，会采用混合架构，传统主控制器主要还是基于32位Tricore，PowerPC以及850等架构的微处理器, 主要作为冗余和兼容的部分。对于AI和计算力消耗较多的自动驾驶及交互应用, 需提供GPP通用处理器、硬件加速器（HWA）和嵌入式的可编程逻辑阵列（eFPGA），域控制器最大的提升还是在芯片算力的提升，这也使得芯片厂家和车企的直接沟通，也在这个层级需要和软件联合考虑。

图4 硬件的混合架构【2】

● 面向服务的数据架构：

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

● 面向Zone的网络架构：

围绕着计算平台，在整车里面重新整合划分网络架构体系。从目前的各家规划来看，并不是从70个ECU变为3个ECU，而是需要开发新的软件功能的主要节点变为3-5个，其余的基于原有信号通信的ECU进化结束了。

图5 Zone架构下原有的ECU的功能被极大的削减了【3】

● 网络车载支持后台：

这块使用IT技术应对车辆面向服务的功能支持。

● 网络通信：

 100BaseT1与1000BaseT1的标准化使得以太网已作为主干网络的首选，而且整车需要增加冗余设计；2. 基于AVB/TSN以太网通信规范将成为网络核心底层协议；确定性网络数据调度设计，保证控制系统时延要求；

● 信息安全和功能安全设计：

功能安全与网络信息安全在欧洲OEM是与功能开发相同步的流程。为了让不同Safety/Security级别的功能能够合理有效的实现，需要对系统的底层硬件与软件做技术升级。

因此这种过渡状态，是逐步拉升的，随着软件开发的完成，越来越多的功能被整合进去，如仪表和娱乐系统就第一个整合到娱乐系统的车载计算平台里面去。目前车企比较一致的想法是分为三块：

1. 自动驾驶HCP AD：根据L3-L4的不同的需求来确定到底需要几个HCP AD

2. 基础HCP：这个就是我们能想象到的原有车身控制、热管理控制、通信控制等等一系列原有分散在各个基础ECU的总控制，通过交互的来实现对于整个车辆功能的总控制

3. 信息和通信CP：这个则是面向于车主和乘员交互的那部分，还承担着非常重要的信息安全的工作

备注：有关于2和3之间的功能分配，每家车企有差异，也有把这两个直接放在一起，整合成一个完整的HCP的企业。

图6 HCP的演化也在域控制器上面有很大的空间

全新开发模式对我们的影响

我觉得最重要的影响，是从车企开始的，这有点像从诺基亚时代过渡到iPhone时代，我们能看到随着车辆平台的差异化从结构件、动力总成件，转化成软件的变化，意味着原有的整车开发模式就变得更为简化和缩短，车企自身的人力资源从项目管理、供应商管理和系统开发管理，往软件开发过渡。

传统的供应商与OEM的合作模式已经发生变化，Tier1不再是大包大揽，车企通过自身的人力资源和周边受控的第三方软件供应商会更多参与进来，OEM在系统开发中会担当越来越重要的角色，未来的成功将来自于全产业链的核心技术整合。同时，软件的开发计划与硬件的开发计划相互独立，软件将会是全生命周期内迭代持续，且软件可能横跨更多不同硬件设备。而以往的开发都是以零件SOP节点作为软件开发计划的参考时间，同时硬件方案是同步确定的。

对我们来说，在没有出现一个成熟、可用的全套方案以前：

● 中国车企很难短期内跟上这种节奏的变化，这需要大量资源投入和工程资源储备，也需要试错。传统的Tier1能给你的东西变得比较有限，而且非常贵，因为很多的成本没办法通过均摊降低。

● 在整个供应链条上，原有的就业会受到很大的冲击。这次借着汽车周期的下行，各个领先的企业都开始调整自己的业务重点和人力资源，都是看到了这个趋势的变化。而且这种淘汰是永久性的，也很难再利用自己熟悉的汽车和零部件的行业找到应用之地，这是汽车行业的腾笼换鸟。

● 这样的变化，会在豪华车上面首先发生，并迅速扩展到新车上面，我觉得这种变化可能会来得很快，因为一旦熟门熟路了以后，消费者适应起来调整也会很迅速。

但是从另一角度来说，对于国外的谷歌、苹果，国内的腾讯、阿里和华为这样的从其他领域渗透到汽车行业的企业来说，在未来汽车附加值最大的这块，可以跟着欧美车企试验，找到自己的位置——由于迭代速度的原因，能占据高地可能性还是很大的。

小结：

我最近有空的时候就在看HCP的资料，就在想我们熟悉之前的东西如何过渡到新的东西上去，这个筹划的过程可能在3年内看到端倪，在5年内看到对市场的影响，留给我们从业人员适应的时间并不长。

参考文件：

1）VW Christian Senger Digital Car & Services

2）BMW High Performance Computing Architectures For Automotive

3）Vector Architectures of High Performance Computing