虽然电子电气架构的概念在过去的20年间才逐渐发展起来，电子电气系统却已经有了超过40年的历史。在电子电气架构这个概念尚未出现的年代里，汽车电子电气系统一直在持续的发展中。

　　分布式架构（Distributed Architecture，DA）是最早被命名的电子电气架构。它的主要特点是整车中的各种功能分散在多个ECU中，各个ECU基本独立地进行本领域的功能逻辑控制。分布式架构从历史发展的历程来看，可以被分为四代，如图1所示。

　　这个阶段的各个部件之间没有总线进行连接，所有的信号都是通过硬线信号（电压、电流、PWM等）进行传递。ECU之间无功能的交互，所有ECU都独立完成自己的功能。电源供给和控制多采用大电流直接控制。

　　ECU之间已经有了总线的连接，但是因为整车的总线数量较少，信息量也很少，无需网关进行不同网段之间的信息转换、转发工作，不同网段基本上保持独立状态。ECU之间功能的交互较少，基本上还是处于独立工作状态。电源供给和对执行器的控制已经开始采用小电流间接控制。

　　网络总线数量增加，可以多达三四个网段、数十个节点。一般由BCM来作为全车的网络中枢并承担网关的职责，负责进行网络数据转发等工作。每个ECU的功能在不断地增加，ECU之间的交互和功能逻辑的协调变得越来越多越来越复杂。整车的电子电气系统逐渐开始进行架构级的总体设计。

　　为了有效优化整个电子电气系统的设计，功能架构设计成为了整车设计中最重要的环节，各个ECU之间的功能不再是独立的，而是从整车的层级出发，进行协调一致的设计，ECU间功能的耦合不断增加。网络拓扑结构变得越来越复杂，LIN、K-Line、CAN、MOST等总线相继应用，不同总线之间的信息互相转发成了基本要求，网络管理也成了重要的技术。为了对整车的电能消耗进行有效管控，电气架构的设计逐渐变得重要起来。

　　随着ECU的增加和ECU之间数据量的持续增加，BCM所包含的几个网络总线已经无法支撑整车的网络通信，于是可以支持更多网段的独立网关逐渐开始普及。独立网关具有独立的MCU，可以处理更多的数据，并且存储空间也更大，因此可以承担更多的任务。除了可以提供多达十几条总线接口外，还可以承担OTA、信息安全防护、临时数据存储等任务。在车载以太网、FlexRay等技术开始应用后，网关也随之升级以支撑这些新的总线形式，成本也随之大幅度增加。

　　在分布式架构的发展周期内，各种控制器的整合也在不断地进行。例如将车窗控制和驱动的功能集成到BCM中，将360环视的功能从独立的控制器整合到多媒体主机中等等。整合的目的多出于成本的考量，但背后的支撑还是芯片和软件技术的发展。

　　随着电子电气系统中的ECU数量进一步增加，并且更新迭代速度更快，分布式架构的缺点也逐渐暴露出来，ECU数量众多且相互之间功能逻辑耦合较多。一方面导致BOM成本和管理成本的不断攀升，另外一方面整个电子电气系统的复杂度逐渐接近难以管理的极限。

　　由于ECU功能之间的协调全部都依赖总线数据的传递，导致功能架构、软件架构和网络架构的设计都越来越复杂，ECU之间的功能逻辑耦合也越来越严重。这让每一个新功能的加入或变更都可能要同时更改多个ECU的软件，哪怕只是一个ECU的软件逻辑变更也可能要导致一条或多条总线上通信矩阵的变更，从而导致该总线上的ECU的软件变更。

　　尤其是在OTA技术得到广泛应用以后，在量产之后更新任何一个功能都可能导致多个ECU需要被同时更新，这大大增加了OTA的复杂度和成本。具体体现在以下几个方面：

　　数据流量的成本。整车制造商要为每一字节的数据流量支付流量费用，多个ECU升级意味着数据流量和费用的大幅度增加。

　　ECU软件更新的研发成本。更新多个ECU意味着要让每个ECU的供应商在量产之后还要继续维护这个ECU的软件，这就意味着车企不但要花费人力来协调相关的供应商对ECU进行更新，还要被迫支付供应商提出的不一定合理的软件变更费用。

　　因为对于大多数供应商来说，如果不是为了保持与车企的良好关系，没人愿意去花精力来做这种SOP后的软件更新，他们更愿意把精力投入到新项目的开发中。

　　而且，在SOP后进行的这些更新所投入的人力必定要从他们正在进行的其他项目中抽调出来，这也意味着对其他项目进度的影响和管理成本的增加。因此，供应商往往会对这种更新报出很高的费用和不一定合理的周期。

　　验证成本。多个ECU的变更意味着电子电气系统的较大变化，为了保证OTA后的质量，相关的各种测试都在所难免。而且，车企的管理成本也会增加。

　　由于燃油车在发动机停止后只能使用12V铅酸蓄电池作为整车低压电网的能量来源，而蓄电池的容量有限，很难支撑整车电子电气系统的长时间工作，所以如果OTA的耗时较长，将可能出现以下三种结果：

　　①蓄电池馈电（即蓄电池的电量大幅度低于理想值）导致车辆无法启动，甚至在蓄电池电量用光的时候OTA还没有完成，从而导致ECU功能的彻底丧失。

　　基于以上原因，汽车工程师开始寻求一种能够大幅度降低电子电气系统复杂度、BOM成本和OTA的成本与难度，并且可以简化功能架构与软件架构设计的新电子电气架构形式。

　　软硬分离是每个车企都希望能够实现的目标。这样就可以真正将软件的迭代和硬件的迭代分开，从而减少对供应商的依赖程度，并因此减少开发成本和缩短整个电子电气系统的开发周期。

　　虽然AUTOSAR架构已经实现了应用层软件的部分重用，但只是减少了应用软件从一个ECU迁移到另外一个ECU的成本，无法实现整车层级应用层软件的全部重用。

　　而且，不同的ECU一般都由单不同的供应商来设计实现，如果一个SWC需要被另外的供应商来编码实现，则软件开发工作量减少得并不明显。

　　最理想的状态是车企能把这些软件都掌握在自己手中并且这些软件都集中在一个或几个控制器中，这样就可以减少付给外部供应商的软件开发费用，并且可以自己掌控开发节奏。

　　但是车企毕竟不可能自己掌控所有的ECU的开发和生产制造，原有的供应链体系也要继续维持，否则那些已经在量产或开发状态中的产品就可能出现风险。

　　最好的方式就是逐渐转型，将以前由供应商负责的部分工作逐渐转移到自己的手中，从而给双方都有一个过渡的时间。

　　工作的转移有两个阶段：首先进行软件功能的集中化，即大部分软件转移到少数控制器中。然后，车企再逐渐接过软件的开发工作。通过这种方式，既解决了OTA更新中遇到的困难，也能让车企有更多的话语权并让软件开发的成本得到控制。

　　对于以上的问题，域控制式架构（Domain Control Architecture，DCA）是一种比较理想的解决方案。如果将每个功能域的功能逻辑上移到一个逻辑处理功能更强大的控制器中，下游的ECU仅承担接受域控制器的指令，并执行输入、输出的处理工作或者实时性要求非常高的工作，就可以部分解决分布式架构在更新功能逻辑时所遇到的问题，并使车企有了更多的掌控权。

　　这里需要再解释一下“域”这个概念，以免出现混淆。中文中的“域”在英语中可以对应两个词：Domain和Zone。

　　Domain指的是功能域，即一类功能的集合，例如底盘域、动力域、车身域、信息娱乐域等。Zone指的是区域。Domain架构和Zone架构的理念不同，一个是按照功能来划分，一个是按照物理位置来划分。域控制式架构指的是按照功能域来进行划分的架构。

　　一般来说，域内的功能逻辑之间交互很多，域控制式架构因为大部分功能交互都在域控制器内部进行，从而减少了域内总线数据传递的延时，性能可以更好。同时，OTA的难度也降低了（大多数时候只需要更新域控制器即可）。

　　域控制式架构一般有两种结构如图2所示，虽然两种结构都有中央网关，但是域控制器之间的连接形式有所不同。

　　拓扑A的结构可以被称为星型域控制式架构（Star DCA）。其中的每一个域控制器（D1、D2、D3和D4）分别单独连接到网关上，它们之间的信息交换通过网关来进行转发。

　　域控制器与网关之间比较适合采用以太网等点到点的网络介质，能够传输的数据量较大。此种结构可以被称为星型域控制式架构。

　　拓扑B的结构可以被称为树形域控制式架构（Tree DCA）。其中的每一个域控制器（D1、D2、D3和D4）均连接在一条骨干网总线上，并连接到网关。它们之间可以直接进行信息交换而无需通过网关来进行转发。这种形式比较适合采用FlexRay等高速总线形式，网络延迟较少，实时性更好。

　　网关可以作为车与外界的接口进行数据的传输，另外，由于有一些功能需要非常高的实时性和大量的数据传输要求，所以网关一般还需要提供一些CAN、LIN或以太网等接口。

　　例如：从云端下载的大量音视频和OTA的数据就不适合从骨干网中进行传输，因为这会占用大量的骨干网的带宽，并且速率也不如以太网（100M甚至1000M）高，因此，此类数据还是使用以太网等点到点的网络介质更为合适。

　　当域控制式架构实现之后，下一步就可以进行域控制器之间的整合，以及下游ECU之间的整合。

　　得益于芯片技术的飞速发展，尤其是SoC的成本下降和逐渐普及，域控制器之间的整合在理论上已经没有特别大的障碍，最大的门槛是对技术的掌握程度。

　　虽然软件移植和开发的工作量非常大，但是这个困难是可以通过资金和人员的投入可以解决的。而真正的困难是那些用钱解决不了的问题。

　　对于那些从来没有进行过控制器内部详细设计的车企而言，进行域控制开发的最大难题是对控制器内部各种详细知识的掌握，而这种能力并非短时间可以迅速增长，需要通过长时间在相应专业领域的浸淫所获得的经验与知识积累的支撑。

　　在集中控制式架构（Centralized Control Architecture，CCA）的结构中，HPC是架构的核心，可以看作整车网络中的中央服务器，负责所有的逻辑功能控制和数据处理工作。车企心目中最理想的情况是由一个强大的HPC来处理车上的所有计算任务，如图3中的拓扑D。

　　然而由于当前芯片的限制，只使用一个HPC还有很多的困难，例如算力和通信端口的数量等，因此很多车企目前所采用的方案还是采用至少两到三个HPC来处理不同域的任务：如车身域、信息娱乐域和智驾域，如图3中的拓扑C。由于三个域处理的任务特点不同，相应SoC的能力不同、资源奇亿代理注册也不同。

　　理论上，由于集中式的架构已经将所有的逻辑和数据处理都集中到HPC中，因此下游的传统ECU仅需要承担输入和输出的处理，所以将不同功能域的硬件按照所在区域进行重新整合成为可能。

　　通过将传感器和执行器按照所在区域就近接入ECU，ECU再通过高速总线接入HPC，就可以实现区域控制。这种负责每个区域控制的ECU通常被称为区域控制器（Zonal Controller，ZC）或区域控制模块（Zonal Control Module，ZCM）。

　　如果再将各个用电器的电源通过区域控制器进行就近供给，就可以将整车线束的长度、重量和回路数大幅度减少。

　　据测算，在实现同等功能的条件下，回路数可以减少20%以上，长度可以减少30%以上。区域控制的最大收益在于线束的减少，因为线束是整车中第三重的部件，可以达到50kg甚至更重，综合成本也可以在整车的电子电气部件中排到前三位，豪华车中线元。

　　首先是成本变化不明显。虽然节省了一部分线束的成本，但是由于区域控制器一般不会再采用传统的保险丝方案，而使用大功率半导体器件或eFuse来实现智能配电，而由于这些大功率半导体器件的价格仍然较高，所以整车的综合成本仍然可能高于传统的基于保险丝方案的成本。

　　其次是配置的灵活性与梯度差。由于每个区域控制器都集成了多个功能并替代了一部分传统ECU，那么，当车辆需要进行不同的配置梯度时就只能采用两种方式：

　　①不同的配置采用不同的区域控制器。这会大大增加区域控制器的软硬件开发、验证费用。如果总销量不高，则研发成本会大幅度增加。

　　②高低配采用同样的区域控制器，通过相应的软件进行配置。这样虽然减少了研发成本，但是单车的BOM成本却必然增加。

　　无论如何，成本是任何一种方案都永远无法回避的问题。集成度与灵活性是相互矛盾的两个变量，只有综合考虑了整个架构周期内所有产品的综合成本与收益后做出来的决策才是明智的决策。

　　由于5G技术、V2X的发展，使得通过包括路端V2X设备和云端对车辆进行高实时性控制成为可能。这在理论上提供了一种新架构形式的可能性，即将大量运算能力要求高的工作放到云端（包括路端V2X设备）的服务器进行处理，车端负责本地数据采集的和执行。这种理想中的架构可以被称为车云一体式架构（Vehicle Cloud Architecture，VCA）。

　　然而，由于高速移动网络的普及程度尚未达到很高的覆盖度，云端处理能力也无法支撑上亿辆汽车的并发实时性控制，从而无法满足任意车辆在任意时刻和任意位置的控制需求。

　　而且由于移动网络的可靠性还达不到对车辆进行可靠控制的程度，因此，VCA在目前阶段仅能实现部分的功能，如语言、图像、用户账户信息等实时性、可靠性要求不高的数据的云端同步处理。

　　如果我们足够乐观，在不远的将来，在满足至少如下几个条件之后，车端的架构将可能又重新变成去中心化。

　　信息安全和相关的技术已经足够成熟，相应的法规和标准已经完备并被普遍遵守。

　　将大量的计算能力放在云端，可以充分利用云端能力可以共享的特点，从而不必让每台车都需要具备满足高等级自动驾驶的超强算力，充分利用V2X以及边缘计算技术也可以大幅度减低车辆对车端传感器的配置需求。同时，各种自动驾驶的算法模型都可以实现实时的迭代更新。从理论上来说可以大幅度降低整个系统的成本，并降低车辆实现自动驾驶的门槛。

　　汽车最终会发展成什么样子？电子电气架构最终会发展成什么样子？这个问题我们永远只能进行畅想，因为这取决于很多无法回答的问题的答案。

　　本文节选自广汽集团电子电气架构总师侯旭光的新作《智能汽车：电子电气架构详解》。

　　5本！请转发文章《八大亮点再出圈！谈思第七届中国汽车网络安全周强势来袭》

　　集赞数量达到28个后，请在「谈思汽车」公众号后台发送完整的集赞截图，「谈思汽车」公众号小编将根据完成集赞的先后顺序确定获赠用户。广汽集团电子电气架构总师：一文厘清电子电气架构的演变