引言
电子电气架构简称EEA（Electronic and Electrical Architecture），以功能实现为主导并且满足法规、设计要求等特定约束的系统性技术解决方案。EEA包括了整车上所有的电子控制单元、线束、供电、网络通信等，也就是说电子电气架构并不单单只是零部件，也包括它们之间的通信及线束链路。这是一种从上而下的正向开发设计思路，以平台车型的需求为基础，兼顾成本、质量、性能等因素，综合平衡、优化的结果。其目标是使得整车EE系统性能最优，成本最低。EEA架构就是为了“平台化”，一个EEA平台可以以此孵化出多个车型，可以有效减少开发周期并且缩减成本。
第一部分
1.1.EEA的发展趋势
- 原始阶段：十几年前，车上几乎每个零部件都有自己的ECU，采用的是分布式的网络，通过一个网关进行网络链接，这就会导致车上的线束复杂度极高。
- 现阶段：前几年，出现了“域融合”的概念，即出现了中央域控，如座舱域控、智驾域控、车身域控、底盘域控，它们其实就是将原本大量的ECU进行了简化和融合，将其计算分析能力上升至域控内，域控再通过一些以太网的网关进行信息的中转。
- 未来阶段：现小米、特斯拉、蔚来等车企都在做中央集中&车云一体，即将现在所有的域控制的算力继续往上升到中央算力平台。将整车ECU进一步简化，只留下一些执行器和传感器，关键的节点则通过区域控制器来执行i/o和区域配电的操作，将大量的逻辑运算和数据处理都放到中央算力平台。例如蔚来、小鹏以及尝试将座舱、智驾、车身、tbox功能放到中央算力平台。
图1 不同阶段架构示意图
1.2.为什么要进行中央集中？
分布式架构其实以经存在很久了，代替了早期的硬线连接的方式，它其实解决了不少问题，但随着车辆功能复杂度的增加，越来越多的ECU和线束也造成了设计困难，会增加开发时间，增加成本。而现在的域控制架构则是将功能逻辑抽象上移至功能域控制器中。每个域控制器有对应的集成的S2S（signal to Services)，即出现了面向服务的架构（SOA）。其优势在于简化了软件迭代的复杂度和周期，可以直接通过OTA进行软件迭代升级，而不需要再去找供应商做软硬件的整合。很多功能逻辑的设计和实现可以直接在域控制里进行。并且域控制直接可以建立高带宽的骨干网络，传输速度也大大增加，提升用户体验。车云一体也就是EEA3.0，现在其实还处于探讨阶段，其主要分布为云端、中央网关、高性能计算中心（HPC）、区域控制器（ZCU）。该架构不同的ZCU分布在车辆不同的位置上，通过高速环形以太网和中央计算单元进行连接。ZCU可以直接控制驱动、连接、供电、I/O和一些ECU的功能，这样将硬件部分全部设置完成后，以后的一些功能迭代就可以集中在中央计算单元内，并且ZCU可以就近连接执行器和传感器，这样就能大大降低线束的设计复杂度，减轻了整车的重量，降低了成本。1.3.中央集中控制实例
![]()
如图所示该中央计算单元包括了自动驾驶、智能座舱、通信单元（T-BOX）三个功能，并且有如动力与底盘和车身控制器的其他辅助控制器。
1.4.面向服务的架构设计
![]()
图4 SOA架构示意图
面向服务的架构（SOA），运用了IT行业的一些概念，将很多功能抽象服务化，又定义了许多原子服务，在上层进行各种服务的整合，这样就可以做到灵活组合。目前的语言娱乐和车身控制等方面可以看到SOA的一些运用了。这其中会运用到一些通信的中间件，如SOME/IP和DDS。
1.5.ZCU的作用
ZCU即区域控制器，主要充当网关、交换机和智能接线盒的角色，提供并分配数据和电力，区域内I/O控制"承上启下":上接车辆计算机，下接执行器&传感器，类似于Autosar CP中RTE的角色(SWC与BSW之间通过RTE传输数据)。它可以做到数据的分发，将中央计算单元的数据传导过来，然后在各个网段进行交互，缩短了信息通路，提高通信效率和安全性。它还能进行智能配电，传统车只有一个保险盒进行配电，而多个区域控制器则有多个保险盒，可以将配电的风险分散，有一级、二级配电和智能电网管理模块。同时它还具有I/O控制功能，可以驱动不同的传感器和执行器。
1.6.ZCU的发展趋势
第一阶段，可能是相对通用化的ZCU，采用标准化软件模块，兼容现有ECU网络（CAN/LIN/FlaxRay）；作为数据转发设备，将区内的功能在服务层面就行抽象；第二阶段，会以降低区内ECU数量为目的，整合其他ECU功能，并将控制I/O虚拟化。![]()
图5 区域控制器的“扩张”和功能的集中化趋势
1.7.ZCU方案实例
不同级别的车型会适配不同的ZCU数量，越高级的车，ZCU数量越多。ZCU对于总线及硬线的要求较高，虽然它不需要过高的算力，但其所需的安全等级还是较高的。1.8.EEA的表现形式
把每个分立元件的功能与和它相关的传感器及执行器组合成一个整体。每一个系统都需要中央电脑及其相关的传感/执行器。按区域控制全车的所有功能。每个区域主ECU控制相关的从功能，主ECU之间用网络系统连接。① 功能分配均匀，主ECU计算能力要求不高，所需空间小;从功能的软件/硬件相对简单将一个确定功能的电子设备视为一个功能模块。电子元件组合成一个模块。② 模块内部传感/执行器控制电路可集中在一起，通过总线接收外部数据，模块中央组件可同时给传感/执行器供电，模块间敷线成本低。1.9.EEA设计的综合考虑
严格按照上述四种架构形式进行网络设计是很困难的。综合四种架构设计方法，把功能组分成各个域，架构各种形式可能部分地应用在各个域中。典型的架构如图所示：各个域通过中央网关连接在一起。EEA的开发不仅仅是电子电气一个部门的工作，还有DRE（产品设计工程师），Tier1（一级供应商）等业务部门进行上下游资源整合的工作。
第二部分
EEA的开发流程也是按照V流程来执行的，主要在V型的左侧：![]()
图1 V流程示意图图2 EEA的PREEvision开发流程和具体工作示意图EEA的开发流程是基于PREEvision的，在DOORS中进行需求开发，在PREEvision中进行方案设计和比较，最后输出文件。![]()
图3 EEA开发分层示意图从分层的角度来分分析，EEA开发流程即先有需求，然后定义功能及逻辑，再有硬件和它们之间的通信方式和线束连接方式，最后整车的拓扑形成。需求分析分为三部分，第一部分为客户特征（Customer Feature）的分析，由“车型企划部”等类似部门开展，会首先明确要开发车型的等定位，如该车是L1还是L5等级的车。随后导出EE系统的feature特性，如功能特性、性能特性等，该步骤由“架构部门”开展。最后整理EE系统与子系统电子电气需求由“系统部门”开展。完成特性设计后还需进行用例（Use Case）设计，全面深入地细化feature，深入分析参与者、使用场景等内容，如ACC等ADAS的功能，需要去设计一些状态机来明确其什么条件下开启、终止和用户介入；第二部分为法规要求如中国新车评价规程（C-NCAP）和欧盟新车安全评鉴协会（E-NCAP）等强制性要求分析。第三部分为竞标车型的功能，系统，架构的详细对比分析。根据需求，产品经理输出PRD文件，其中包括如整车功能文件，需要进一步细化到子系统的功能文件，子系统功能文件又需进一步细化到ECU级别的功能文件，这就涉及到了功能的分配，所有信号的输入输出和控制策略规划。如图所示，玻璃升降的开关，可以直接由升降电机控制，或者用车身控制器BCM控制，再或者用门控制器控制。在功能逻辑层面不需要关心具体的实现方式，只需要划分功能和实体间的连接方式，即输入输出。但在软件架构中需遵循Classic/Adaptive AUTOSAR，需要确定哪些模块或ECU去承接哪些功能和接口，实现将功能与软硬件的映射。该架构有专门的网络工程师去设计网络架构，包括总线类型、总线数量、总线参数和ECU节点。还会进行网关路由配置，需要用到一些工具，如CANoe去测试如总线负载等，其中会用到一些数据库，如*.DBC针对CAN，*.ARXML则针对以太网或LIN。诊断：诊断和通信是强相关的，通信确定后随即就需要考虑诊断相关的功能，不同的ECU需要制定不同的诊断功能。设计诊断功能需要先完成诊断协议规划，再具体设计诊断服务和功能设计，还需在线配置参数规划和谁急诊断数据库。诊断是贯穿整个开发流程的内容，前期的一些故障降级处理到刷写和EOL和后续售后都需考虑诊断的功能。电源分配：根据不同的负载，进行电源分配并且需要有一定的冗余，电源分配设计包括整车供电网络，电平衡规划电源分配，接地分配保险丝，继电器规划，电器盒规划。硬件工程师根据功能和网络拓扑图来设计电气原理图，包括子系统和整车。![]()
图8 电气原理示意图线束工程师再将其转化为线束设计图，进行线束拓扑规划，线束搭铁点布置，线径、端子、连接器、护套规划。![]()
图9 线束设计示意图电气布置则需要进行整车电气件布置规划，设定环境条件、电磁兼容，设计最大线束长度等。架构评估的因素有：架构成本，拓展性，灵活性，安全性，可靠性，整车能源管理等。
![]()
图11 架构评估表示意图
前文所述是传统架构的设计流程，对于中央集成或域融合的新架构就需要考虑SOA的服务设计。
SOA服务设计最下层是设备端的抽象，将底层的执行器传感器API进行抽象，形成原子服务和应用层服务。
![]()
图12 SOA服务示意图
EEA开发过程是庞大且复杂的，某些传统的OEM可能会使用传统的工具链如Office，但这种方式是“零碎式”和“文本式”的，存在文档管理困难，设计可追踪性低，难以优化全局，数据源不一致、设计语言二义性，难以进行变形管理等缺点。所以需要引入MBSE（Model Based System Engineering）这种工具链，其基于模型可以改善沟通成本；拥有设计集成，数据一致性，设计可追溯性的优点去改善品质；并且可以多人协作，设计模块复用，自动生成报告改善生产力；设计成本预估，早期方案评估比较并降低风险。架构工作从需求到架构开发，依托PREEvision工具，可以实现正向设计。(1)需求管理：功能/非功能需求，设计规范/需求，法律法规，etc。(2)功能定义：功能逻辑架构设计，系统边界定义，etc；AUTOSAR软件架构设计，SOA设计。(3)硬件&网络设计：网络拓扑定义，总线/硬线/供电/接地拓扑；整车电气原理，部件架构设计。(4)通信设计：CAN/CANFD/LIN/Flexray/MOST/Ethernet总线通信设计。(6)几何拓扑规划：整车电器件布置，线束几何走向规划。从系统、到车型、到平台的架构数据管理，变形管理，架构评估，etc一条链路全部包含到了这一个工具内。![]()
图13 PREEvision工具示意图同时PREEvision还有一些上下游设计内容的电子化交互，如和DOORS交换一些需求文档，和MATLAB/SIMULINK交互技术软件建模。![]()
图14 FREEvision上下游交互示意图PREEvision还可以设置不同人员的权限来进行多人协同开发，包括版本管理、生命周期管理。SystemWeaver吉利系用的比较多，和PREEvision相比会有一些简化，但也是按照从需求到功能到通信到软件最后到硬件的设计流程。![]()
图16 SystemweaverCapital E/E Insight支持对电气系统设计进行实时“假设”架构研究。可以直观地开发这些研究项目，以比较评估成本和重量等关键设计指标，从而更快、更好地让工程师团队做出设计决策。其功能与PREEvision相比要少一些。![]()
图17 Capital设计流程示意图首先需要定义Customer Feature，用文字描述需要实现哪些功能。然后就可以在逻辑层定义功能具有哪些输入输出，如路面信息的输入和控制单元控制灯的输出，流程即输入→功能处理→输出，小到ECU大到域都是这个原理。到了软件层面就需要将功能映射到软件模块，比如进一步的分解是左侧的灯还是右侧灯的信息输入和左侧的执行器或右侧的执行器输出。![]()
图20 软件设计逻辑图在软件层面功能是一个模块，但到了网络层面，它就变成了两个ECU，BCM去获取左右路测的信息，再将信息传递给大灯控制单元（LCS）去控制左右两个灯。![]()
图21 网络拓扑示意图形成电气原理图，如图所示黑色的连接线即为硬线，绿色的即为双绞线（CAN线）。最终进行几何布置，将电控单元放到对应的位置上并进行走线。![]()
图23 几何布置示意图
第三部分
在了解完EEA开发的整体流程和方法后，我们来参考一下现在主流的OEM和Tier1他们的EEA发展现状吧。
3.1.Tesla
Model3车型跳过了域融合阶段，直接采用了区域集中架构。中央控制模块通过CAN通讯来与其他控制器传输数据，而内部高速的通讯都集中在中央网关中。
整车采用了中央计算模块（CCM）、左车身控制模块（BCM LH）、右车身控制模块（BCM RH）三大域控制器。
3.2.小鹏
• 分层域控——功能域控制器（智驾域控制器、车身域控制器、动力域控制器等模块）与中央域控制器并存• 跨域整合——域控制器覆盖多重功能，保留局部的传统 ECU• 混合设计——传统的信号交互和服务交互成为并存设计采用中央超算（C-DCU）+区域控制（Z-DCU）的硬件架构，中央超算包含车控、智驾、座舱3个域控制器，区域控制器为左右域控制器，将更多控制件分区，根据就近配置的原则，分区接管相应功能，大幅缩减线束。3.3.理想
• 理想 One采用LEEA1.0传统分布式架构；L9采用 LEEA2.0域控制器架构，2023年新车型为 LEEA3.0 中央计算平台架构• LEEA2.0 域控制器架构在1.0 的基础上将功能进一步集成为三大域控制器：中央域 控制器 XCU、自动驾驶域控制器FSD 和智能座舱域控制器 HU。其中 XCU 全自研，集成了VCU、EGW、BCM、BMS 等传统功能，已有中央计算平台雏形，便于进一步迭代。FSD 采用 Orin 芯片，供应商为德赛西威。• 下一代中央计算平台架构则将车控、智驾、座舱三大功能融合，CCU 通过 PCIe Switch 和 TSN Swith 实现各 SoC的互联以及与四个区域控制器之间的连接。3.4.蔚来
• 蔚来最早的车内架构为底盘域+车身域+信息娱乐域+动力域+自动驾驶域的五大功能域架构。• 后续架构进行了改进升级，如 ES8 的互联中央网关 CGW+中央显示控制单元 CDC+自动驾驶域控制器 ADC• 新一代平台的 ET7、ET5 和ES7，蔚来应用了自主研发的智能底盘域控制器ICC(Intelligent Chassis Controller)，仍为功能域集中控制器架构。3.5.大众
大众的MEB平台（首款车ID3）的E3架构，即由3个车辆应用服务器（ICAS，即In-Car Application Server）组成的域集中式EEA，具体包括：车辆控制服务器ICAS1、智能驾驶服务器ICAS2和信息娱乐服务器ICAS3。3.6.宝马
宝马的架构，在金字塔的底层是传感器与执行器，向上一层是标准化的ECU，是通用化的控制单元，可以直接实现一些标准化的功能；再向上一层是集成的ECU，车企在这一层会将自己独有的功能集成到ECU之中，会有定制化的软件代码和功能。![]()
图6 宝马架构示意图
3.7.沃尔沃
SPA: Scaleable Platform Architecture• SPA1.0: 经典域集中架构，该域控架构2015 年投产，共有信息娱乐域、车身控制域、 主动安全域和底盘动力域四个域；主干网 FlexRay 和以太网，其中以太网主要用于诊断功能，此外还应用有 CAN、LIN、MOST 等总线.整车 ECU 数量仍高达一百多个，复杂度和线束成本仍然较高。• SPA2.0(当前架构):与安波福联合开发,以太网替换 FlexRay 作为主干网，以中央计算平台 VCU 为核心，将域控制器和大量需要计算的 ECU 集成到中央计算平台， 网关、配电、机电控制 ECU等集成到区控制器，大大减少 ECU 数目。3.8.华为
• 在底盘等机械硬件之上，华为将整车分为几个层次，从下往上依次为硬件平台、软件平台、应用生态以及车云。• 华为已经开发了符合中汽协SDV标准的300+个设备抽象API。设备抽象服务涵盖了车身域、热管理域、动力域、底盘域等，而可以提供抽象服务的设备包括了电机、按钮开关、继电器、车灯、温度传感器等各类执行器和传感器。• 华为已经开发了符合中汽协SDV标准的400+个原子服务API，服务涵盖了车身控制、交互域、运动控制、能量管理、智能驾驶域等各个方面，包括了车门服务、雾灯服务、通风服务、座舱温控等各类服务，方便工程师在开发软件时调用。 图9 SDV设备抽象示意图 图10 SDV原子服务示意图3.9.零束
• 全栈1.0电子电气架构搭载在目前上汽旗下高端纯电智能车品牌智己、飞凡车型上，全栈1.0架构共有三个域控制器，即中央计算（车控及数据融合）、智能驾驶、智能座舱，同时还保留了较多的分布式模块。• 2021年零束启动全栈3.0架构的研发，进行进一步的集中化，其两个高性能计算单元，即 HPC1和 HPC2来实现智能驾驶、智能座舱、智能计算、智能驾驶备份功能，再加 4个区域控制器， 实现各自不同区域的相关功能。3.10.博世
博世的渐进式路线从域的集中化开始演进，终极目标一样是车载中央计算机。
![]()
图12 博世E/E架构进化示意图
3.11.安波福
根据安波福的规划，这种转变是分阶段进行的。2022年将会推出一个混合构架，把PDC（电源数据中心）整合到传统的车载E/E构架中。到2025年，将实现开放式中央计算机的构架。
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。
