3. 车端电子电气架构演进
车端电子电气架构（E/E Architecture）的演进，本质上不是“把盒子做大”或“把线束变短”这么简单，而是围绕算力集中度、通信带宽、软件可迭代性、供电与数据分区四条主线不断重构。理解这条演进路径，是理解 SDV 车端应用框架与服务治理为何必须存在的前提。
一、核心原理：三次架构跃迁的驱动力
早期分布式 ECU 架构的逻辑是“一个功能一个控制器”。车窗、座椅、空调、ABS、仪表各自独立，通过 CAN/LIN 总线交换少量信号。它的优点是开发边界清晰、供应商责任明确；缺点是算力碎片化、线束爆炸、跨功能协同困难，且 OTA 升级几乎无法覆盖全车。
随着智能座舱、辅助驾驶、车联网功能增加，域集中式架构出现：按功能域划分，如动力域、底盘域、座舱域、智驾域、车身域。每个域控制器承担该域内多个 ECU 的整合与决策，域内可用 CAN FD、以太网，域间通过网关或中央网关交互。它解决了“功能域内协同”和“部分算力集中”，但域与域之间仍存在数据孤岛，跨域服务调用链路长。
中央计算 + 区域控制架构则进一步把计算与供电/数据接入解耦：中央计算单元负责高算力任务与整车级软件平台，区域控制器（ZCU）按物理位置就近接入传感器、执行器与低压负载，通过车载以太网骨干与中央计算互联。其核心思想是“算力上移、接入下沉、区域就近、服务化通信”。
二、方法流程：从功能分解到区域划分
架构演进不是一次性替换，而是分阶段推进。典型流程如下：
- 功能清单与算力画像：梳理全车功能，标注实时性、算力、安全等级、数据量。
- 域划分或区域划分：域集中按功能聚类；中央+区域按物理位置聚类，兼顾线束长度与供电半径。
- 通信矩阵设计：确定以太网骨干、CAN FD 子网、LIN 低速节点，定义服务接口与信号映射。
- 供电与冗余设计：区域控制器就近配电，关键负载双路供电，中央计算与区域控制之间做链路冗余。
- 软件平台化：中央计算承载 SOA 框架、OTA 主控、数据闭环；区域控制器承载 IO 抽象与实时控制。
- 灰度迁移：新车型先保留部分域控，逐步将功能迁移到中央计算，避免一次性重构风险。
三、案例/场景：区域控制器如何改变装配与升级
以某智能电动车为例，传统车门模块需要单独 ECU 和长线束连接到车身域控。改为区域控制后，左前区域控制器就近接入车门锁、车窗、后视镜、氛围灯，仅通过一条以太网链路与中央计算通信。装配时线束长度显著缩短，车门功能升级只需在中央计算侧更新服务逻辑，区域控制器执行 IO 抽象层不变。
在 OTA 场景中，中央计算统一管理升级包，区域控制器作为执行代理完成本地刷写与回滚。服务治理框架需要感知区域控制器的在线状态、版本、供电模式，并在升级失败时自动降级到安全策略。
四、对比与误区复盘
| 维度 | 分布式 ECU | 域集中式 | 中央计算+区域控制 |
|---|---|---|---|
| 算力分布 | 极度碎片化 | 按域集中 | 中央集中+区域轻量 |
| 通信主干 | CAN/LIN | CAN FD+以太网 | 车载以太网骨干 |
| 线束复杂度 | 高 | 中 | 低（区域就近） |
| OTA 覆盖 | 单 ECU 为主 | 域内可批量 | 整车级统一 |
| 服务治理难度 | 低但封闭 | 跨域调用复杂 | 需强服务框架支撑 |
复盘来看，架构演进的成功关键不在硬件形态，而在于是否建立了与架构匹配的服务治理能力：服务注册发现、生命周期管理、版本兼容、故障隔离与降级策略。只有这些能力到位，中央计算与区域控制才能真正支撑 SDV 的持续迭代。