【软件定义汽车】-【架构篇】-全面讲解整车电子电气架构演进

前言： 

前段时间，陆陆续续写了一些电子电气架构相关的文章。这里打算再写最后一篇作为收尾，为整个系列画上句号，把坑填上，这个话题就算过去了。后续一段时间，尽量把之前文章中挖的“坑”填一下。行文逻辑将借鉴5W2H进行。

另外，本文作为一篇整合性的文章，为保证逻辑的完整性，主要是将大量过去自己文章中的内容进行梳理整合，也存在很多行业内专家的公开文章的内容，请见谅。

WHAT1：什么是汽车电子电气架构？

电子电气架构：EEA，Electrical/Electronic Architecture

根据百度百科的解释：“汽车电子电气架构是集合了汽车的电子电气系统原理设计、中央电器盒设计、连接器设计、电子电气分配系统等设计为一体的整车电子电气解决方案”的概念，由德尔福(DELPHI)首先提出。具体就是在功能需求、法规和设计要求等特定约束下，通过对功能、性能、成本和装配等各方面进行分析，将动力总成、传动系统、信息娱乐系统等信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、电源管理等电子电气解决方案（如图1所示）。

图1 整车电子电气架构与功能域

EEA不仅在汽车中经常使用，也在航电系统、工业自动化以及国防系统等其他控制系统中有广泛应用。

EEA的开发包括需求定义、逻辑功能架构设计、软件/服务架构设计、硬件架构设计、线束设计等不同层面的开发活动，如图2和图3。

图2 基于PREEvision的EEA开发模式

图3 基于PREEvision的EEA设计

2.WHY：电子电气架构演进的根本驱动力（Motviation）是什么？

答案：人类生产生活重心的转移与客户预期的改变

随着移动互联网在消费者生活领域的广泛渗透，人们的生活习惯和价值取向开始转移。伴随互联网尤其是移动互联网的飞速发展，人类的生产生活重心逐步转移至虚拟的赛博空间(Cyberspace)中。尤其是2007年苹果创造出智能手机这种便携化的智能终端后，不论是网上购物、网上娱乐、网络社交、移动支付、网络咨询，还是在线政务、线上办公、在线教育等生产生活活动，都在逐步地向赛博空间转移。未来还将有更多的老百姓被转化为网民，并更多地“生活”在赛博空间中。

人类生产生活逐步向赛博空间转移的过程中，也会对PC、平板电脑、手机或其他智能终端等消费电子产品的使用习惯和喜好向其他人类生产生活工具上转移。一旦其他工具具备了PC、平板或手机相应特征，就会形成市场需求，因为人类又多了一种智能终端能够与赛博空间进行连接，熟悉的、便利的互联网应用又可以在新工具和设备上运行，方便了生活，提高了生产效率。

汽车的驾驶自动化(Drving Automatization)趋势在很久很久以前就已经产生了。了解下Global OEM的Demo项目，甚至上知网搜索下相关论文，就会发现ADAS是多么古老的一种技术了，远远早于近几年的人工智能热潮。但是，随着特斯拉Model S、Model X等一系列车型的推出，使人们对汽车智能化(Intelligence)有了新的期待。仔细品一下Automatization和Intelligence这两个单词的含义，个人认为还是Intelligence含义更丰富。因此，汽车智能化，不仅包括了驾驶自动化，也包括智能网联、智能交互（以及后续的智能座舱）等数字化和信息化趋势。

也因为特斯拉等新玩家的创新性车型的推出，人们开始对汽车有了以下这种强烈的预期（图4），即智能汽车。所谓的智能汽车，基本是要对标着手机、PC这种数字化/信息化的半导体设备去了。

图4 智能汽车：拥有四个轮子的大型智能手机

既然老百姓的需求是“智能汽车”，那么具备“智能汽车”特征的车型就会有更多市场需求，客户也更加愿意买单。那么表征智能汽车的核心智能化功能都有哪些呢？按照汽车智能化的趋势（即CASE，Connected互联、Autonomous自动、Sharing共享、Electric电动），智能驾驶、智能座舱、智能网联应该就是终端用户期待的功能。以上的这些功能，相对于曾经汽车电子的功能，复杂度有很大提升。为了实现以上复杂功能，我们需要软件的SOA架构，我们需要基于服务的通信，我们需要满足车规的RTOS（实时操作系统），我们需要FOTA（固件空中升级），总之，我们需要一台软硬件解耦的、能够用软件来定义功能的汽车。这就需要一个大大的前提——集中化的EEA。这又是为什么呢？

先进行粗略分析。首先，看看当前的整车EEA现状：a) 电子单元：众多分散的运算&控制单元；b) 电气单元：发动机、伺服电机、电磁阀等; c) 执行机构：机械、液压、气门机构... 也就是说，当前的汽车只是一台相对精密的机电一体化设备（Mechatronics，隶属于控制工程范畴，还需进一步电气化），而非数字化/信息化的半导体设备（ICT范畴），距离智能手机有些遥远。但是消费者目前想要的是一台像手机一样的车（智能终端、电子设备）。究竟如何才能使汽车朝向一台大型的“电子”设备转型呢？答案是继续提高电气化程度，即电子电气架构从分布式向集中式发展，直到形成真正的车载中央计算机。接下来，分为两个具体维度进行分析：

2.2.1 整车设计/制造维度

从整车的设计/制造维度讲，若汽车继续按照当前的分布式架构发展，且不说算力是否满足，单就车辆物理安装空间上讲就有问题。可能会导致难以布置更多ECU和更多线束；更多的ECU和更多的线束，势必导致组装困难，只能继续依靠人工。伊隆马斯克也曾为过度依赖自动化产线而焦头烂额，之后也曾发誓要对汽车进行“线束革命”，说明过多复杂线束和过多ECU的安装会严重影响产线的高度自动化。而集中式电子电气架构，能够逐步平抑ECU和线束的增长趋势，甚至到达某个时间节点之后，能够促进大幅减少ECU和线束用量，降低EEA网络拓的扑复杂度。倘若确实能够减少ECU数量和线束用量，也就能够降低电子电气系统的重量，对整车的轻量化设计目标也有帮助。

电子电气架构的集中化，就意味着单个ECU的“扩容”，以及多个ECU的“合并”。换句话说，ECU要越来越大型化，算力要高，功耗/成本还都需要进行控制。结论是什么？需要大型的、高算力的、制程小的（意味着低功耗）车载SOC芯片。为什么要用SOC芯片？因为通过堆大量算力低的芯片做控制器不可行；芯片多，集成度低，PCB板以及域控制器太大不好布置（想象一下Demo车的后备箱塞满工控机的场景），功耗和成本也高。总之，集成化程度高是刚需，SOC芯片又能够较好的解决这个问题。各个芯片玩家疯狂扩大SOC规模（从英伟达Xavier和ORIN，到特斯拉FSD芯片，甚至Mobileye提供EyeQ5的开放方案），也是为了解决这个痛点。所谓“规模”，实质是指算力，DMIPS/TFLOPS/TOPS都要足够高。

有了强大而“趁手”的芯片，就能“攒”出来满足集中化要求的ECU了。不管是叫DCU（域控制器），还是HPC（高性能计算机），甚至是VCC（车载中央计算机），也不过是表征一下ECU有多大规模。

综上论述，从整车维度讲，大型SOC芯片（以及基于大型SOC芯片构建的大型域控制器/高性能计算机）和先进线束都是集中化EEA的关键基础技术。

2.2.2 价格/成本维度

不管是什么产品，到了只拼价格/成本的竞赛，基本意味着没有太大创新了。因为创新是有代价的，创新是很“贵”的一件事，因此我相信集中化EEA也会遵循发展的常识。最开始是功能导向，为了实现某些关键功能的落地而不惜代价，价格/因素会较少考虑；然后是性价比导向，关键功能实现了，为了体现性价比，就会把手伸到“别人的地盘”，即几个大型ECU通过吸收其他专用小型ECU的功能（把小型ECU从车上干掉，平抑整个系统的成本），通过集成更多功能来保持“虽然贵，但是功能也强大”的性价比优势；最后是成本导向，大型ECU的功能scope确定了、“扩张边界”也确定了，就得比价格/成本了。然后不停的往复循环以上逻辑。

当前的智能驾驶域，在L0-L2已经相对成熟，因为该级别的各个ADAS功能相对确定，因此边界已经清晰了，那么开始打“性价比”牌和赤裸裸的“价格”牌也就不奇怪了。而L2+到L3还在比拼功能落地，那么价格因素就可以适当妥协（当然不能无限妥协，毕竟做产品归根结底是做生意，钱永远是最重要的）。

总之，若把智能驾驶、智能座舱的复杂功能作为必定要实现的“既定事实”看的话，集中化EEA还是“省钱”的。因为，即便假设分布式EEA从技术角度能够实现复杂功能，成本也会非常高。

以上，也可以回答作者作为一个做量产ADAS/AD的技术人员，为什么要关注整车电子电气架构演进的原因。因为关注EEA的进化，实质是关注前装量产高级别自动驾驶功能的落地节奏，以及汽车数字化、软件化的推进节奏！

3 HOW：通过何种方式达到集中化EEA，如何发展（Roadmap）？

根据下图的描述，一般EEA从分布式到中央集中式需要经历三个阶段，即分布式-域集中-中央集中。

图5 电子电气架构演进的三个阶段

4 WHAT2：什么算是集中式的EEA？有哪些常见类型？

4.1 三域EEA（域集中式EEA）

三域，顾名思义，是指车辆控制域、智能驾驶域和智能座舱域。其中，车辆控制域基本将原动力域、底盘域和车身域等传统车辆域进行了整合（整合更多是系统层面的概念，并不一定是硬件层面合并，因此并不是说这个域中其他ECU就不存在，或者就减少了）；智能驾驶域和智能座舱域则专注实现汽车的智能化和网联化。涉及的零部件主要有4类，车控域控制器（VDC，Vehicle Domain Controller）、智能驾驶域控制器（ADC，ADAS\AD Domain Controller）、智能座舱域控制器（CDC，Cockpit Domain Controller）以及若干高性能网关，其中：

• VDC作为Private DCU，负责整车控制，实时性安全性要求高；

• ADC作为Public DCU，负责自动驾驶相关感知、规划、决策相关功能的实现；

• CDC作为Public DCU，负责HMI交互和智能座舱相关（甚至整合T-Box）功能的实现；

三域EEA算是非常彻底的域集中式EEA。

三域EEA常见的实践包括：

4.1.1 大众MEB平台的E3架构

大众的MEB平台（首款车ID3）的E3架构，即由3个车辆应用服务器（ICAS，即In-Car Application Server）组成的域集中式EEA，具体包括：车辆控制服务器ICAS1、智能驾驶服务器ICAS2和信息娱乐服务器ICAS3（如图6所示）。通过ICAS这种大型域控制器，逐步得将本域的其他ECU的软件功能（如智能传感器Smart Sensor的一些功能Applications，以及基础软件Basic Services）逐步向ICAS中转移，直到其他ECU（本域的传感器和执行系统）慢慢被合并。

图6 大众MEB平台的E3架构示意图

E3的骨干网采用车载以太网实现，如下图所示。由图可知，车控域控制器需要更多DMIPS算力，因此除了提供MCU（Micro Controller Unit）外，还有一个多核ARM作为MPU（Micro Processor Unit）。ICAS1作为Conti提供的方案，不知道这颗MPU会采用谁家的芯片。

图7 E3架构中车控域控制器（ICAS1）与智能座舱域控制器（ICAS3）的连接示意图

4.1.2 宝马iNEXT车型的三域架构

宝马iNEXT车型的EEA也包括3个域控制器，分别是BDC（body Domain Controller，对应VDC），SAS（即ADC）以及MGU（Media Graphics Unit，对应CDC）。

宝马ADC的hPAD版本，主要由 1xMCU（TC397）+ 2xCPU（Intel Denveton）+ 2xSOC（Mobileye EyeQ5，1个软硬件一体，1个开放）。

宝马ADC的uPAD版本，主要由 1xMCU + 1xCPU（Intel Xeon）+ 3xSOC（Mobileye EyeQ5，1个软硬件一体，2个开放）。

4.1.3 华为的CC架构

华为的“计算+通信”架构（CC架构）比较特殊，把智能网联也囊括了，应该是IOT视角的中心计算（云）+通信（管）+边缘计算（端）这种思路。从华为的视角，所有业务都分为“云”、“管”、“端”；把端做多做大了，就像往悬崖对面拉了更多的锁链，桥梁（华为的“管”，一端是5G基站、路测单元等设备，另一端是类似T-Box等设备）就更结实稳固了。手机、汽车、智能家居（华为的智慧屏），都属于各种“端”。而华为的汽车三域架构，也属于“端”（车端）的范畴。因此车端的EE架构算是CC架构包含的一个“小架构”，也是VDC、ADC、CDC和网关等部件组成，而且把T-box也作为。另外，华为将ADC叫做MDC（大名鼎鼎的“移动数据中心”，Mobile Data Center）。

图8 华为CC架构

4.1.4 伟世通的三域EEA方案

伟世通的三域EEA方案（概念），也是三个域控制器，Body Super Core即为VDC，ADAS Super Core即为ADC，Cockpit Super Core即为CDC。

图9 伟世通的三域EEA方案

4.2 Zonal EEA（中央集中式EEA）

Zonal EEA有几个关键组成，即车载中央计算机（VCC，Vehicle Central Computer）、区控制器（ZCU，Zonal ECU）、环形链接的以太网TSN组成的主干网及CAN/LIN/10BaseT1s区内网、双电源冗余供电及区域内智能分级供电。

图10 Zonal EEA示意图

简单讲，分布式架构就是“计算的分布式，供电的集中式”；而Zonal EEA就是“供电的分布式，计算的集中式”，正好反过来。Zonal EEA不仅能将计算资源集中，便于软硬件分离；也给整车各个控制器的电源管理带来很多想象力。

4.2.1 车载中央计算机（VCC）

定位：VCC在车辆中的定位是中央计算机，核心定位是实现智能驾驶和智能座舱相关的业务逻辑；并且具备网联功能，连接车端（边缘侧）和云端。VCC的操作系统的可能实现形式，比如会是Classic AUTOSAR、Adaptive AUTOSAR（POSIX OS）和Linux（如图11所示）。Classic AUTOSAR覆盖安全性和高实时性需求，Adaptive AUTOSAR覆盖灵活的安全性需求，Linux只需要QM。

图11 博世对于车载中央计算机OS的一些见解

架构：VCC这种中央计算机的软件架构，可能会是基于Adaptive AUTOSAR的SOA（面向服务的架构）；硬件架构，可能会是多颗大型SOC芯片，甚至会有专用SOC搭配（例如纯粹的AI加速核）；芯片间通信，可能会是以太网或PCIe。

算力：DMIPS算力至少250k，可能需要500k；TOPS(int8)算力至少600；若车路协同落地，TOPS算力可能会往云端转移，例如车端至少300+云端AI算力。

接口支持：支持Automotive Ethernet，以及Fast Ethernet (OBD)。

VCC整体特点的总结：可扩展的计算能力，可升级的软件能力。

4.2.2 区控制器（ZCU）

定位：ZCU主要充当网关、交换机和智能接线盒的角色；提供并分配数据和电力，并实现车辆特定区域的feature，如图12所示。

图12 区控制器的一种设计方案

具体来讲：

• 关于数据分发：1.支持任何类型的传感器、执行器和Display（显示器）的接口；2.区域内，区控制器与低阶的ECU通信时，有可能会用10BaseT1s（无屏蔽双绞线以太网1）代替其他的通信方式，比如CAN、FlexRay等；因此，也会充当IP-based设备（以太网通信设备）与骨干网（车载中央计算机与区控制器级之间的以太网通信）之间的交换机角色；当然，如果区域内的通信不完全被10BaseT1s以太网替代时（有CAN、LIN等通信存在），还会充当传统设备的网关；3.关于TSN主干网（以太网），要具备高带宽和实时通信，同时保证可靠性和fail-operational特性；4.eSwitch/eFuse功能；

• 关于分级配电（供电）：1.一级配电网络，双电源（冗余）将电力输送到区控制器；2.二级配电网络，区控制器负责将电力继续向下输送到底层控制器，因此区控制器需要具备eFuse/高边power distribution功能；

• 关于车辆特定区域的feature实现：区控制器会配置ASIL等级高的MCU来实现车辆区域的各种基本功能。同时保证系统功能安全。

接口支持：

• 车载以太网：10BaseT1s/100BaseT1/1000BaseT1；

• I2C/I3C/CSI/DSI/I2S；

• PCIe/GMSL/FPDLink

• LIN/CAN/CANFD/PSI5/UART/SPI

ZCU除了以上基本特性外，可能也会涉及到一些变迁，比如逐步“吸收”区内其他ECU的功能。第一阶段，可能是相对通用化的ZCU，采用标准化软件模块，兼容现有ECU网络（CAN/LIN/FlaxRay）；作为数据转发设备，将区内的功能在服务层面就行抽象；第二个阶段，会以降低区内ECU数量为目的，整合其他ECU功能，并将控制I/O虚拟化。可能带来的影响：ZCU的对于计算需求增大，MCU难以满足算力需求，可能还需要增加MPU（增加纯DMIPS算力的SOC，比如Denverton甚至Xeon）来满足算力需求。

图13 ZCU与区内其他传感器与执行器之间的配合关系（区内架构图）

具体的变迁方式，如下图所示。

图14 区控制器的“扩张”和功能的集中化趋势

4.2.3 基于Zonal EEA的通信架构

Zonal EEA的通信主要包括主干网（1000BaseT1）和区内网（10BaseT1s/100BaseT1/CAN/ CANFD/FlexRay）。

其中，主干网主要采用千兆车载以太网，用于连接VCC和ZCU，实现面向服务的通信（Service-Oriented Communication）；要实现的通信协议有：SOME/IP（IP中间件）、DoIP（IP诊断）、UDPNM（基于UDP的网络管理）、TSN（802.1Qbv/CB/Qbu /Qch/Qci...，即车载时间敏感网络）、XCP（标定测量）等。另外，针对信息娱乐和网联服务，还需要实现HTTP。

区内网则主要是实现面向信号&PDU的通信（Signal-Oriented Communication），带宽在500k（CAN）、2M（CANFD）、10M（10BaseT1s）和100M（100BaseT1）不等。未来的趋势，可能会逐步被10BaseT1s取代（伴随着上文提到的功能集中化趋势）。

实现SOA需要面向服务的通信。基于HTTP及SOME/IP(车载)的以太网通信，能够提供更高的带宽及灵活性；同时可以尽最大可能地使用下图（图15）的通信栈中的协议和标准，简化车载通信类型。

图15 面向服务的通信常见协议

4.2.4 基于Zonal EEA的SOA软件架构

SOA架构，具备什么优点呢？根据大众软件定义汽车材料的描述，有以下优点：

• 基于服务发现&订阅发布模式的动态绑定特性

• 基于REST的数据表征（统一接口，无状态stateless，关注点分离separation of concerns）

• 接口的前后兼容性

• 软件可更新性（Updateability）、软件可移植性（Portability）、组件可重用性（Reusability）、硬件可升级性（Upgradeability）

图16 在VCC和ZCU上实现SOA

具体地，车载中央计算机（VCC）中基于多芯片的软件部署架构，也将会是SOA架构，如图17所示。

图17 SOA在VCC中的实现

4.2.5 Zonal EEA的一些优势

伊隆马斯克曾高调宣称：Model Y线束长度减少到100米。想要达到这个目标的实际难度是很大的，但是这种提法的理论依据确实还是很充分的。

图18是博世建立的一个理论模型，对不设置区控制器（左边）和设置了区控制器（右边）的线束长度对比。很明显，所有外围ECU直连车载中央计算机，线束只多不少，线束拓扑非常不合理；只有设置了相应的区控制器，线束拓扑才得以简化，线束密度也大大降低。因此，Zonal EEA说能够降低线束长度，减少线束质量，是有理论支撑的。线束复杂度和长度减少了，装配就简化了，也能大大提高产线的自动化水平，提高制造能力。当然，这就需要开发出更为先进的整车线束链接。可能德尔福拆分时，把动力部分作为SpliCo拆出去，ADAS和德尔福派克（线束工厂）作为RemainCo留下来，改名为APTIV，也是为了开发SVA架构更方便吧。控制器和线束的设计制造能力都在，可以更好的形成系统方案。

图18 Zonal EEA如何减少线束

图19是博世用PREEvision搭的线束拓扑（转成PPT展示），模拟Zonal架构layout出来的线束拓扑。线束复杂度和长度降低幅度不小。

图19 基于PREEvison模拟的线束拓扑

图20，基于Zonal EEA的通信方式，会从Signal-Oriented通信（CAN/CANFD）切换到 Service-Oriented通信（以太网，和以太网TSN），便于SOA（基于服务的软件架构）在车辆上的实现。

图20 基于服务的通信

4.2.6 Zonal EEA的常见实施案例

• 特斯拉的Zonal EEA：特斯拉的CCM（Central Computing Module），其实是伪“中央计算机”，主要是由Autopilot ECU和MCU（Media Control Unit，即IVI车机）以及网联模块组成的，封装在一个控制器中（液冷系统冷却）；

图21 朱玉龙总结的Model3 Zonal EEA

• 丰田的Zonal EEA：丰田的EEA属于典型的Zonal-EEA。首先，在硬件上，通过ECU的集成来降低控制器成本；软件上，使用基于Adaptive AUTOSAR和Classic AUTOSAR的SOA架构，实现便捷的软件迭代和功能的可扩展性；线束上，最大程度减少线束长度，降低线束设计复杂度，减重降本，提高产线自动化；安装空间上，集中化的架构减少了ECU数量和线束长度，腾出更多空间，为后续迭代预留空间。

图22 丰田的Zonal EEA概念

图23 丰田认为Zonal EEA几个较有优势的点

图24 如何从分布式EEA逐步过渡到Zonal EEA

• 沃尔沃的Zonal EEA：沃尔沃的Zonal EEA包括Core System和Mechatronic Rim，不过将ZCU划入了中央计算集群中；同时还定义了与核心计算系统相对应的概念：机电一体化区域，其实如果以VIU为节点看的话，也可以分出几个区来。VCU对应车载中央计算机，冗余设计；VIU对应区控制器。

图25 沃尔沃的Zonal EEA概念

• 安波福的Zonal EEA：即SVA架构；供应商层面的Zonal EEA。中央计算群对应冗余的车载中央计算机，PDC即为区控制器。

图26 APTIV的SVA 架构

SVA架构的落地节奏。也可参考下，真正高级别前装自动驾驶落地，时间要比该时间更晚。

图27 安波福的SVA架构部署时间表

• 博世的Zonal EEA概念：

图28 博世的Zonal EEA概念

图29 减少线束是主要目的之一

• 伟世通的Zonal EEA概念

图30 伟世通对Zonal EEA的设计概念

5 电子电气架构演进背景下的ADAS/AD ECU零部件形态

典型的分布式ADAS零部件形态，正好对应L1至L2级别自动驾驶。这些零部件分别为：

• FCM：Front Camera Module，前视摄像头模块(一体机)

• FCR：Front Central Radar，前雷达模块(一体机)

• SRRs：Side-Rear Radar，侧后雷达模块（左、右）

• AV-ECU：Around-View ECU，全景环视控制器

• PA-ECU：Parking Assist ECU，泊车辅助控制器

• DMS-ECU：Driver Monitoring System ECU，驾驶员监控系统控制器

• MAP ECU：地图控制器（ADAS或高精度）

典型的集中式ADAS/AD零部件形态，正好对应L2+至L4级别自动驾驶。这些零部件分别为：

• ADAS DCU（低阶ADC）：驾驶辅助域控制器，chipset除了MCU外，可能会包含0-1个MPU；

• ADAS/AD DCU（高阶ADC）：chipset除了MCU外，可能会包含1-3个MPU；

• AD HPC：除了MCU，可能会包含1-4个MPU；

• VCC：目前想象不出来会是哪种chipset；甚至起初的VCC大概率不会是单个PCB板，而是像特斯拉CCM一样的多板叠加形成的车载中央计算机。

后记

在智能驾驶和智能座舱争相落地的大背景下，在软件定义汽车的呐喊声中，抽时间关注下电子电气架构的演进，或许能帮助我们“荡涤心灵”，看清楚汽车真实的智能化进展。