整车 E/E 架构（Electrical/Electronic Architecture）

读完本页后，你应该能够：

• 画出 E/E 架构从分布式→域→区域 Zonal+HPC 三代的演化路径及驱动力。
• 区分 Domain Controller（域控）和 Zonal Controller（区控）的设计逻辑。
• 说出 AUTOSAR Classic 与 Adaptive 的分工及各自的典型任务。
• 列出 SOA（Service-Oriented Architecture）的 3 要素（服务 / 通信 / 中间件）。
• 给出主流车厂（大众 ICAS / Stellantis STLA / Tesla HW4 / 华为 CCA / 丰田 Arene）各自的架构方案要点。
• 解释 SDV（Software-Defined Vehicle）对硬件工程师意味着什么。
• 把主驱逆变器控制器（MCU + 驱动 + 模块）放进 EEA 里找到它的接口与责任边界。

整车 E/E 架构 30 年里经历三代演进——每一代都是上一代成本和复杂度撞墙后的应对。Gen 1 分布式每个功能一颗 MCU,L3+ 时 ECU 数飙到 100 颗、线束 1500m,撞墙;Gen 2 按功能聚合到 5~7 个域控降到 50 颗 ECU,但跨域协作仍受总线限制;Gen 3 区域 + 中央算力把功能从硬件解耦成软件,实现真正的"软件定义汽车"。

1.1 Gen 1 → Gen 2：按功能聚合

Gen 1 → Gen 2 的转变核心是把"按硬件分"改成"按功能域分"——不再是每个零件一颗 MCU,而是把一类功能(动力 / 底盘 / 车身 / 信息娱乐 / ADAS)聚合到一颗大 MCU 里。这一步降了 ECU 数量,但没解决跨域协作的总线瓶颈——为下一步 Gen 2 → Gen 3 的中央算力埋下伏笔。

• 驱动：ECU 数量爆炸（2020 年 L3 车已超 100 颗）；诊断 / 更新无法管理
• 手法：按业务域把功能合进大 MCU（400 MHz / 双核 lockstep）
• 5 大域：
  • VDCM（车辆动力域） — EMS / TCU / BMS / EV 主驱逆变器
  • Chassis — EPS / EBS / 悬架
  • Body — BCM / 空调 / 门窗
  • Infotainment — 仪表 / 中控 / 导航
  • ADAS — 感知 / 融合 / 决策

1.2 Gen 2 → Gen 3：按位置聚合 + 中央算力

Gen 2 → Gen 3 是两个独立但同时发生的转变——空间维度上 ECU 按位置聚合(Zonal,4-8 个区域控制器替代 5-7 个域控),算力维度上把"决策性算力"集中到 1-2 颗 HPC。这两个转变缺一不可:只做 Zonal 没 HPC 还是分布式控制,只有 HPC 没 Zonal 线束仍长。Tesla Model 3/Y 是这一架构的工业标杆。

• 驱动：
  • 域控之间跨域功能（如 ADAS 调动底盘）需要更高协作 → 中央 HPC
  • 线束仍过长（域控在各自位置，I/O 仍绕整车）
  • 算力共享（GPU/NPU 需要大量内存，散热集中更经济）
  • OTA / SDV 要求软件架构统一
• 手法：
  • 中央 HPC：1–2 颗高算力 SoC（Qualcomm 8775 / Nvidia Orin / TI TDA4VH / 芯驰 X9HP）跑主业务
  • 区域 ZCU：4–8 个 ZCU 按车身区域（前/后/左/右）布置，聚合本区 I/O 到以太网骨干
  • 骨干：车规以太网（100BASE-T1 / 1000BASE-T1 / 10GBASE-T1）+ TSN
  • 跨区服务化通信：SOME/IP、DDS
• 代表：
  • Tesla HW3（2019 首发集中算力）/ HW4（2023）— 最彻底的 Zonal 先驱
  • 大众 E³ 1.2（SSP 平台）— 1 个 ICAS 主 HPC + 3 个 ZCU
  • 小鹏 X-Brain（天玑系统）、蔚来 NT3、理想 AD MAX / AD Pro

Domain 与 Zonal 是 Gen 2 与 Gen 3 的代表架构,核心区别在功能聚合维度——Domain 按"做什么"(动力 / 底盘 / 车身)聚合,Zonal 按"在哪里"(前舱 / 后舱 / 左侧 / 右侧)聚合。这条切分维度的差别带来线束长度、HPC 必要性、软件架构的全套连锁差异。

什么时候 Domain 仍合理：

• 商用车 / 成本敏感车型
• 既有平台延寿
• 功能安全边界清晰不想打乱

什么时候必须 Zonal：

• 800 V + SDV 同时上马
• L2+ ADAS / L3 的跨域协作
• 全车 OTA 与年度软件升级

3.1 HPC（High-Performance Computing）

HPC 把整车的**"决策性算力"集中到 1-2 颗大芯片**——典型构成是 SoC + GPU + NPU + 大内存。SoC 跑 Adaptive AUTOSAR 的实时 OS,GPU 跑 ADAS 感知融合,NPU 跑神经网络推理,大内存让多个任务共享数据避免 ECU 间通信延迟。下图给出 HPC 的内部块。

算力典型（2026）：

• 200–500 TOPS（Nvidia Orin）到 2000+ TOPS（Thor）
• 用于 ADAS 感知融合、AI 驾驶员监控、大模型对话、云端数据预处理
• 多核异构：CPU（8–16 Core A78AE）+ GPU + NPU + ISP + 安全岛 MCU（Cortex-R52 lockstep）
• 功能安全岛：即使主 SoC 挂掉，安全岛仍跑 ASIL D 降级功能（如 EPB、低速 STO 协商）

代表 SoC：

• Nvidia Orin / Thor（ADAS）
• Qualcomm 8775（Cockpit + ADAS 一体）
• TI TDA4VH / VM
• 华为 MDC 810 / 610
• 黑芝麻 A1000 / A2000
• 地平线 J5 / J6

3.2 ZCU（Zonal Control Unit）

任务：

• 本区 I/O 聚合（传感器 / 执行器 / 低压电源分配）
• 网关 / 协议转换（CAN / LIN → Ethernet）
• 故障隔离（一个 ZCU 故障不影响别区）
• 某些区的简单本地闭环控制（如车门）

典型 MCU：Infineon AURIX TC38x / TC4x、NXP S32G、Renesas RH850/U2A；中端 MCU 就够，不需要 HPC

数量：通常 4 个（左前 / 右前 / 左后 / 右后）或 8 个（大车）

4.1 两套的分工

AUTOSAR 不是单一框架,Classic 和 Adaptive 分别服务两类需求——Classic 给小 MCU(MMU 都没有的实时控制器,如主驱)、Adaptive 给大 SoC(有 MMU + 多核 OS,如 HPC)。两者API 完全不同,代码不通用,但工程师在一辆车里都要打交道(主驱用 Classic、HPC 用 Adaptive)。

共存：现代车上两者都有；Classic 跑 ASIL C/D 硬实时，Adaptive 跑 ASIL B 智能功能。跨平台用 SOME/IP 或 DDS 通信。

4.2 Classic 的关键模块

Classic 的核心是 RTE 屏蔽硬件差异——SWC(软件组件)只看 RTE 接口,RTE 把它映射到 BSW(基础软件)和具体硬件。这条架构让同一份 SWC 可以跑在 Infineon AURIX 或 NXP S32K 上,只需重新生成 RTE 配置。

• RTE（Runtime Environment）：SWC 之间解耦
• BSW（Basic Software）：驱动 / 通信栈 / OS
• MCAL（MCU Abstraction Layer）：芯片相关层
• Com / PduR / SecOC：总线通信 + 安全通信

4.3 Adaptive 的关键模块

Adaptive 的核心是 ara::com 服务化通信——不再是 Classic 的"信号"而是"服务",和 SOA(Service-Oriented Architecture)对齐。这一架构让大 SoC 上不同进程之间通信像微服务,可以动态发现 / 上线 / 下线,匹配 OTA 与 SDV 的需求。

• ara::com：服务化通信 API
• ara::exec：动态部署（容器化 OTA）
• ara::per / diag：诊断 / 持久化
• ara::log：日志 / 回放

5.1 三要素

SOA 的三要素对应"功能 / 接口 / 通信"三个独立维度——服务定义"做什么",接口定义"怎么调用",通信定义"怎么传输"。这条三层抽象让 SOA 比传统信号通信更灵活——一个服务可以变更实现而不破坏接口。

• 服务（Service）：一个功能（如"请求扭矩"、"查询 SOC"）暴露成 RPC / event
• 通信（Communication）：SOME/IP / DDS / gRPC-Car 承载服务调用
• 中间件（Middleware）：ara::com、DDS、FastDDS、eProsima 等

5.2 为什么从信号发展到服务

通信范式 30 年里从"信号"演进到"服务"——根本驱动是软件复杂度爆炸。信号通信(CAN/CAN FD)中每条信号要预先在 DBC/ARXML 里硬定义,改一条信号要全车 ECU 重新固化;服务通信(SOME/IP/DDS)中服务可以动态发现/上线,新增功能不破坏现有部署。

典型 SOA 场景：

• "车辆状态服务"：HPC 订阅 ZCU 的车门 / 车窗 / 灯光
• "扭矩请求服务"：ADAS 向主驱请求特定扭矩曲线
• "电量服务"：BMS 将 SOC / SOH / 温度暴露给 HMI

5.3 SOME/IP vs DDS

SOME/IP 与 DDS 是两个 SOA 实现的代表协议——SOME/IP 来自 BMW(2013) 偏向请求/响应模式,DDS 来自国防工业偏向发布/订阅模式。关键判别:确定性高的实时控制选 DDS(支持 QoS),通用业务选 SOME/IP。一辆车里通常两者并用。

6.1 Tesla HW3 / HW4（Zonal 标杆）

Tesla 是当代 Zonal + 中央算力的标杆——HW3 (2019) 首次量产 Zonal 架构,HW4 (2023) 升级到 5nm + 更高算力 NPU。Tesla 的核心创新不是芯片本身,而是把"硬件预装 + 软件 OTA 解锁"做成商业模式。

• HW3（2019）：自研 FSD 芯片（14 nm）+ 1 GW/h 算力；全车 5 个 ZCU（模糊定义，更像 3 大控制域 + 2 区域）
• HW4（2023）：FSD chip 2.0（7 nm）+ 50 % 算力提升；硬件冗余；主驱驱动 IC 用 onsemi
• 软件栈全自研；没用 AUTOSAR

6.2 大众 ICAS / E³ 1.2（SSP）

大众 ICAS / E³ 1.2 是传统 OEM 向 Zonal 迁移的过渡架构——保留部分 Domain 痕迹(ADAS 单独 ICAS 1)同时引入中央 HPC(ICAS 2)。这种"半迁移"架构反映传统 OEM 软件能力跟不上 Tesla 的现实。

• ICAS 1：ADAS 域控（Nvidia Orin + 安全岛）
• ICAS 2：车辆控制 + 底盘（主驱、制动、转向）
• ICAS 3：座舱
• 3 个 ZCU：FZM（前）、MZM（中）、HZM（后）
• CARIAD（VW 软件子公司）独立开发软件栈
• 2026 量产 ID.7 / ID.8 首发

6.3 华为 CCA（Computing Communication Architecture）

华为 CCA 是中国 Tier-1 推出的整车架构方案——3 域 1 VDC,主打"软件定义汽车 + 鸿蒙座舱"。代表客户问界、阿维塔。CCA 的核心特点是 VDC 单独抽出来,把车辆动力控制从 ADAS / 座舱解耦。

• 3 个域 + 1 个 VDC（Vehicle Domain Controller）
• HarmonyOS Next for Automotive
• 代表产品：问界 M9、智界 S7、尊界 S800

6.4 Stellantis STLA Brain + SmartCockpit

Stellantis STLA 是14 个品牌共用的统一软件平台——核心理念是把整车软件平台化,各品牌在 Brain 之上做差异化。这是传统 OEM 应对 Tesla 的另一种打法:用规模优势降低单车开发成本。

• Central HPC（Qualcomm）
• 2024 DS 首发

6.5 丰田 Arene

丰田 Arene 是日系 OEM 应对 SDV 的代表方案——基于 Woven Planet 的软件平台,2025+ 量产。Arene 的特点是把 Tier-1 软件深度内化,与博世、电装等的合作模式与欧美差别明显。

• 基于 Woven City / Woven Planet 开发
• AUTOSAR Adaptive + 自主 OS
• Lexus / bZ4X 量产

6.6 小鹏 / 蔚来 / 理想

中国新势力普遍走 Zonal + 自研芯片路线——小鹏 X-EEA、蔚来 Banyan、理想 LEEA,各自迭代节奏不同但架构理念相近。新势力的优势是"轻装上阵"(无历史包袱),劣势是软件团队规模和供应链谈判力都比不上欧美 OEM。

• 小鹏 X-EEA 3.0 + Xmart OS 4
• 蔚来 NT 3.0 + NIO Day 2025 首发
• 理想 AD Max + AD Pro

7.1 Domain 架构下

主驱工程师在 Domain 架构下的主要工作面是与 VDCM 域控的接口——通过 CAN/CAN FD 接收扭矩请求并上报实际状态。这条接口比较 stable(信号定义在 DBC 文件锁死),工程师可以聚焦控制算法本身。

• 主驱逆变器控制器直接挂 VDCM 域控下
• CAN-FD 通信；扭矩请求、故障、温度、SOC 通过报文
• FuSa 边界：逆变器控制器内 ASIL D；与 VDCM 之间 E2E CRC

7.2 Zonal + HPC 下

Zonal 架构下主驱工程师的工作面发生质变——不再是与一个域控对接,而是与 ZCU + HPC 两层都要交互。控制策略从 ECU 内部移到 HPC,主驱降级成"智能执行器",这意味着主驱工程师要懂的领域从控制扩到通信(SOA/SOME-IP)。

• 主驱控制器可能降级为 ZCU 管辖的智能执行器
• HPC 通过 SOME/IP 发服务请求；ZCU 转发到主驱
• FuSa 变复杂：ADAS 的扭矩请求要经过 HPC → ZCU → 主驱；链路跨 3 个硬件域 → DFA 必须验每一跳独立性
• 部分车厂选择保留主驱独立 ASIL D，不参与 SOA

7.3 主驱工程师需要懂的接口

主驱在新架构下要懂的接口按"层级 + 协议"二维分——信号层(扭矩 / 位置 / 电流的具体物理量)、协议层(CAN/CAN FD/Ethernet/SOME-IP/DDS)、安全层(E2E CRC / SecOC)。每层都不能省,层间组合定义了完整接口规范。

• 信号层：扭矩请求、实际扭矩、位置、电流、$V_{DC}$、温度、故障码
• 协议层：CAN-FD、SOME/IP（如适用）、E2E CRC profile 4/11
• 安全协商：启动握手、STO 命令、Active Discharge 命令、HVIL 状态
• 诊断层：UDS over CAN / DoIP；DTC 上报

Software-Defined Vehicle 的三个含义：

1. 功能靠软件定义：同一套硬件通过 OTA 升级能力（如 Tesla 解锁续航、加速）
2. 硬件预埋余量：算力 / I/O / 传感器按 10 年后需求预埋
3. 统一软件栈：所有车型共用一套软件基座

对硬件工程师的影响：

• 硬件要"过度设计"：算力 / I/O / 内存要留 30–50 % 余量给 OTA
• 版本追溯更严：硬件 BOM + 软件版本一一对应；QDL（Qualification Data List）多一列
• FMEDA 需要覆盖软件失效：FMEA-MSR（见 功能安全 §8）
• 跨域协作：主驱工程师要懂 ADAS 请求的语义，否则 SOA 接口对不上

E/E 架构演进最容易被误读的几条概念——把 Zonal 当 Domain 的升级版、把 HPC 当大 MCU、把 SOA 当 CAN 的简单替代。下表把这些误读纠正,核心是要理解"架构差异不是渐进而是范式转换"。

• EEA 三代演化：分布式（100+ ECU）→ 域控（5-7 DCU）→ 区域+中央（4-8 ZCU + 1-2 HPC）；驱动力是 SDV / 线束 / 算力集中。
• Domain vs Zonal：Domain 按功能聚合，Zonal 按位置 + 中央算力；800 V + SDV 同步推进时 Zonal 几乎是必然。
• HPC + ZCU 分工：HPC 算力（200–2000 TOPS）跑 ADAS / 座舱；ZCU 中端 MCU 跑 I/O 聚合 + 区域本地控制。
• AUTOSAR Classic + Adaptive 共存：Classic 跑 ASIL C/D 硬实时 MCU；Adaptive 跑 POSIX + C++14 在 HPC 上的软实时。
• SOA 三要素：服务 / 通信（SOME/IP、DDS）/ 中间件；从 Signal 过渡到 Service 是跨域扩展的前提。
• 主流车厂路径：Tesla 最激进自研；大众 E³ 1.2（ICAS + 3 ZCU）；华为 CCA；丰田 Arene；中国造车新势力各有方案。
• SDV 要求硬件 30–50 % 余量预埋，版本追溯 + FMEDA 覆盖软件失效都是新工作量。
• 主驱在 Zonal 里的三个接口：信号层（扭矩/电流/温度）、协议层（CAN-FD/SOME/IP/E2E）、安全协商（STO/ASC/HVIL）。

• ← 索引
• 汽车电子
• 汽车微控制器 — Classic 载体
• CAN 总线 — 信号层传统主力
• 汽车网络 — CAN-FD / CAN-XL / Ethernet / SOME/IP 深入
• 功能安全 — ASIL 分配在 EEA 里的展开
• 扭矩安全 — SOA 下主驱的 FSC
• 功率电子行业趋势 — 800 V + SDV 的联合推动
• 电机控制
• OBC 与 DCDC