2. 汽车E/E架构基础

汽车电子电气架构（E/E Architecture）是整车功能实现、软件部署与通信协同的骨架。它并非单一部件，而是由电子控制单元（ECU）、传感器/执行器、通信网络、电源与接地、线束、软件平台与诊断接口共同构成的系统级结构。在MBSE工程中，E/E架构是需求、功能、逻辑与物理视图之间的关键桥梁：功能需求最终要落到ECU、信号、报文、服务与算力资源上。

一、E/E架构的基本组成

从物理与逻辑两个视角看，E/E架构可拆解为以下层次：

• 感知与执行层：摄像头、雷达、超声波、温度/压力传感器，以及电机、继电器、阀门等执行器。
• 控制层：ECU，负责采集信号、执行控制逻辑、驱动执行器，并通过总线交互。
• 通信层：CAN/CAN FD、LIN、FlexRay、Automotive Ethernet、SOME/IP、DDS等协议与拓扑。
• 供电与线束层：蓄电池、配电盒、保险丝、继电器、接地策略与线束走向。
• 软件与诊断层：AUTOSAR CP/AP、OTA、UDS诊断、标定、日志与安全机制。

在MBSE中，这些层次通常映射为逻辑架构中的功能块、接口与信号流，再分配到物理架构中的ECU与网络节点。若映射关系不清晰，后续变更会直接引发线束、通信矩阵与软件配置的连锁修改。

二、域控制器与中央计算平台

传统分布式架构中，一个功能往往对应一个ECU，导致节点数量多、线束复杂、软件升级困难。域控制器（Domain Controller）按功能域集中：动力域、底盘域、车身域、座舱域、智驾域。它把同一域内多个ECU的功能整合到更高算力控制器中，减少节点与线束，并支持更复杂的软件逻辑。

中央计算平台（Central Computing Platform）则进一步集中：用少数高性能计算单元承担跨域功能，配合区域控制器（Zonal Controller）就近接入传感器与执行器。其典型形态是“中央计算 + 区域控制 + 以太网骨干”。这种架构下，软件从“面向ECU”转向“面向服务”，算力与通信成为可调度资源。

三、网络拓扑与信号/数据流

网络拓扑决定报文路径、时延与冗余能力。常见拓扑包括总线型、星型、环型与混合型。CAN适合低带宽控制信号，LIN用于低速车身附件，FlexRay用于高实时底盘，车载以太网用于高带宽感知与软件更新。在MBSE中，拓扑不仅是连线图，还要表达信号流、服务调用与时间约束。

图中展示了三个阶段：分布式ECU以CAN/LIN总线连接大量节点；域集中按功能域整合为少数域控制器；中央计算+区域控制则以以太网骨干连接中央平台与区域控制器，传感器与执行器就近接入。MBSE建模时，应把每个阶段的节点、接口、协议与信号流分别建模，并保持需求到架构的可追溯性。

四、典型演进趋势与工程误区

演进趋势可归纳为五条主线：

1. 功能集中化：从单功能ECU走向域控，再走向中央计算。
2. 通信以太网化：CAN FD用于控制，以太网用于高带宽与SOA服务。
3. 软硬解耦：硬件平台化，软件通过AUTOSAR AP、SOA与容器化部署。
4. 区域化布线：按物理区域就近接入，降低线束长度与重量。
5. 全生命周期可升级：OTA、诊断、日志与安全启动成为标配。

在MBSE工程中，建议用以下参数化清单检查架构方案：

架构检查清单（示例）
- 节点数量与分布：中央/区域/末端节点是否清晰
- 通信矩阵：报文ID、周期、超时、信号映射是否完整
- 算力预算：CPU/GPU/NPU占用率与余量
- 供电与接地：域控/中央平台功耗、冗余与故障降级
- 诊断与OTA：UDS服务、刷写通道、回滚策略
- 功能安全：ASIL分解、安全机制、监控路径
- 信息安全：SecOC、防火墙、密钥管理、入侵检测

案例场景：某车型从分布式升级为“中央计算+区域控制”。原方案有90个ECU、6条CAN总线；新方案保留12个区域控制器与1个中央计算平台，骨干采用千兆以太网。改造后线束长度下降约30%，但需要重新定义跨域服务接口、时间同步与故障降级策略。若在MBSE中未建立“功能—逻辑—物理”三层映射，变更影响分析将非常困难。

复盘要点：架构演进不是简单的“节点越少越好”，而是在算力、带宽、成本、安全、可升级性之间做权衡。MBSE的价值在于把这种权衡显式化：用模型表达需求、功能、逻辑与物理的对应关系，用参数图约束算力与带宽，用状态机描述降级与恢复，用追溯关系保证变更可控。