整车 E/E 架构（Electrical/Electronic Architecture）
本质与导读
本质 E/E 架构的演进路径是从 100+ 个分散 ECU 的"联邦制"→ 按域聚合的"邦联制"→ 按区域布线的"中央集权"，驱动力是三件事：软件定义汽车（SDV）需要算力集中、线束成本 + 重量要压缩、OTA / 服务化部署需要统一软件栈。2026 年业界正在从 Domain（域集中，如大众 E³ 1.1）向 Zonal（区域+中央计算，Tesla / 大众 E³ 1.2 / 华为）过渡；这场迁移不是拓扑改动，而是汽车变成带轮子的数据中心的工程表达。逆变器硬件工程师需要懂 EEA，因为主驱控制器在不同架构里会被整合 / 分离，直接影响你的接口、功能边界、安全协商。
主线坐标:横轨 · 诊断 / 通信(跨站) · ↑ 全景主线
1. 三代架构演化
整车 E/E 架构 30 年里经历三代演进——每一代都是上一代成本和复杂度撞墙后的应对。Gen 1 分布式每个功能一颗 MCU,L3+ 时 ECU 数飙到 100 颗、线束 1500m,撞墙;Gen 2 按功能聚合到 5~7 个域控降到 50 颗 ECU,但跨域协作仍受总线限制;Gen 3 区域 + 中央算力把功能从硬件解耦成软件,实现真正的"软件定义汽车"。
| 代 | 特征 | 驱动力 | 代表量产 |
|---|---|---|---|
| Gen 1 分布式 | 每个功能一个 ECU；CAN 总线主导；少量 LIN | 功能扩展需要；80 年代起 | 大多数 2020 前燃油车 |
| Gen 2 域控 | 5 大域（动力 / 底盘 / 车身 / 信息娱乐 / ADAS）各一个强 MCU | 软件集中；减少 ECU 数 | 大众 E³ 1.1（MEB）、特斯拉 Model S（2012） |
| Gen 3 区域+中央 | 2–4 个 HPC（高性能计算）+ 4–8 个 ZCU（区域 I/O 聚合） | SDV / OTA / 线束 / 算力共享 | Tesla HW3/HW4、大众 E³ 1.2（SSP）、小鹏 Xmart OS 4、蔚来 NT3 |
1.1 Gen 1 → Gen 2：按功能聚合
Gen 1 → Gen 2 的转变核心是把"按硬件分"改成"按功能域分"——不再是每个零件一颗 MCU,而是把一类功能(动力 / 底盘 / 车身 / 信息娱乐 / ADAS)聚合到一颗大 MCU 里。这一步降了 ECU 数量,但没解决跨域协作的总线瓶颈——为下一步 Gen 2 → Gen 3 的中央算力埋下伏笔。
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
2. Domain vs Zonal 对比
Domain 与 Zonal 是 Gen 2 与 Gen 3 的代表架构,核心区别在功能聚合维度——Domain 按"做什么"(动力 / 底盘 / 车身)聚合,Zonal 按"在哪里"(前舱 / 后舱 / 左侧 / 右侧)聚合。这条切分维度的差别带来线束长度、HPC 必要性、软件架构的全套连锁差异。
| 维度 | Domain（域控） | Zonal（区域+中央） |
|---|---|---|
| 聚合逻辑 | 按功能 | 按物理位置 |
| 骨干网 | 多 CAN / FlexRay / 少量 Ethernet | 车载 Ethernet 为主（100M / 1G / 10G） |
| 线束长度 | 中等（域控可能离 I/O 远） | 最短（ZCU 就在 I/O 附近） |
| 算力分布 | 分散（每域一颗大 MCU） | 集中（HPC 承担主要算力） |
| OTA 便利性 | 中 | 高 |
| 功能安全 | 域内 ASIL 独立 | 跨 HPC / ZCU 的 ASIL 分解复杂 |
| 典型 ECU 数 | 30–50 | 10–20 |
什么时候 Domain 仍合理：
- 商用车 / 成本敏感车型
- 既有平台延寿
- 功能安全边界清晰不想打乱
什么时候必须 Zonal：
- 800 V + SDV 同时上马
- L2+ ADAS / L3 的跨域协作
- 全车 OTA 与年度软件升级
3. HPC 与 ZCU 分工
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
4. AUTOSAR Classic vs Adaptive
4.1 两套的分工
AUTOSAR 不是单一框架,Classic 和 Adaptive 分别服务两类需求——Classic 给小 MCU(MMU 都没有的实时控制器,如主驱)、Adaptive 给大 SoC(有 MMU + 多核 OS,如 HPC)。两者API 完全不同,代码不通用,但工程师在一辆车里都要打交道(主驱用 Classic、HPC 用 Adaptive)。
| 平台 | 运行载体 | OS | 语言 | 典型任务 |
|---|---|---|---|---|
| Classic | 经典 MCU（ARM R / TriCore） | OSEK | C | EMS、TCU、BMS、主驱逆变器、刹车、转向 |
| Adaptive | 高性能 SoC | POSIX (Linux QNX) | C++14+ | ADAS、融合、算法、OTA |
共存：现代车上两者都有；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. SOA（Service-Oriented Architecture）
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)中服务可以动态发现/上线,新增功能不破坏现有部署。
| 范式 | 特点 | 缺点 |
|---|---|---|
| 信号（Signal） | CAN 报文 + DBC；发送者广播；接收者按需解析 | 跨域扩展困难；版本兼容靠约定 |
| 服务（Service） | 客户/服务端；请求/应答；发现协议 | 需要中间件开销 |
典型 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。一辆车里通常两者并用。
| 协议 | 来源 | 特点 | 适用 |
|---|---|---|---|
| SOME/IP | AUTOSAR 车规 | 轻量 / 无 broker / UDP/TCP | AUTOSAR Classic/Adaptive 互通；主驱-整车服务 |
| DDS | OMG 工业 | 实时 pub-sub / QoS 丰富 / 有 discovery | ADAS、机器人、eVTOL |
| gRPC | HTTP/2 + protobuf | Cloud 端；车规少用 |
6. 主流车厂架构方案
6.1 Tesla HW3 / HW4（Zonal 标杆）
Tesla 是当代 Zonal + 中央算力的标杆——HW3 (2019) 首次量产 Zonal 架构,HW4 (2023) 升级到 5nm + 更高算力 NPU。Tesla 的核心创新不是芯片本身,而是把"硬件预装 + 软件 OTA 解锁"做成商业模式。
- HW3（2019）：自研 FSD 芯片（14 nm）+ 144 TOPS 算力（双芯片冗余，单芯片 72 TOPS）；全车 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. 主驱逆变器在 EEA 中的位置
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
8. SDV 对硬件工程师的影响
Software-Defined Vehicle 的三个含义：
- 功能靠软件定义：同一套硬件通过 OTA 升级能力（如 Tesla 解锁续航、加速）
- 硬件预埋余量：算力 / I/O / 传感器按 10 年后需求预埋
- 统一软件栈：所有车型共用一套软件基座
对硬件工程师的影响：
- 硬件要"过度设计"：算力 / I/O / 内存要留 30–50 % 余量给 OTA
- 版本追溯更严：硬件 BOM + 软件版本一一对应；QDL（Qualification Data List）多一列
- FMEDA 需要覆盖软件失效：FMEA-MSR（见 功能安全 §8）
- 跨域协作：主驱工程师要懂 ADAS 请求的语义，否则 SOA 接口对不上
9. 工程陷阱（Gotcha G1-G7）
E/E 架构迁移集中了认知层与工程层的双重陷阱——认知层是把 Zonal 理解为总线替换、把 HPC 当堆料；工程层是 AUTOSAR 双轨未打通、ZCU 故障链割裂 ASIL 分解。以下七条来自量产项目复盘。
G1: Zonal = "4 颗 MCU 换以太网" Zonal 的本质是中央算力 + I/O 按位置聚合双重转变；仅把域控之间总线从 CAN 换成以太网而不引入 HPC，线束仍绕整车布线，算力仍分散在各域控，等于什么都没变。Tesla Model 3 的工程创新不在 PHY 替换，而在把"决策"从 5 颗域控收到 FSD 芯片，同时把每区 I/O 聚合到附近 ZCU——两步缺一不可。
G2: 以太网取代 CAN，CAN 已死 CAN-FD / CAN-XL 在硬实时控制域（主驱 FOC 50 µs 周期、制动压力闭环、EPS 电流环）仍是工程主力，原因不是带宽而是确定性：CAN 最坏延迟 = (N-1) × 帧时间，精确可计算；TSN Ethernet 须所有节点都支持 802.1Qbv shaping 才能保证端到端延迟上界，任一不支持节点即破坏保证。2026 年量产中，主驱内部走 SPI，主驱↔ZCU 走 CAN-FD，ZCU↔HPC 才走以太网——三段媒介各司其职。
G3: AUTOSAR 只有 Classic，主驱工程师不用懂 Adaptive 主驱控制器跑 Classic AUTOSAR（OSEK、C 语言、确定性调度），HPC 跑 Adaptive AUTOSAR（POSIX QNX/Linux、C++14+、动态服务），两套代码完全不通用。典型事故：工程师把 HPC 上的 ara::com 服务接口直接当 Classic RTE 端口看待，遗漏了 ZCU 里的 SOME/IP→CAN-FD 协议桥以及桥两侧的 E2E Profile 降级声明，导致 Classic 侧 CRC 解帧错误直接崩溃——E2E Profile 必须全链对齐，桥接处须显式声明转换规则。
G4: HPC 越强越安全，把 ASIL D 扭矩环移到 HPC Adaptive AUTOSAR 的 POSIX 调度抖动通常 200 µs~2 ms，主驱 ASIL D 电流环要求 <5 µs 抖动（50 µs 周期 × 10%）——即使 Orin / SA8775P 的 Cortex-R52 安全岛算力足够，OS 调度路径也不满足硬实时。量产教训：某项目把 d-q 电流环迁到 HPC 安全岛，实测 FOC 周期从 50 µs 变 1 ms，相电流纹波超 IEC 61800-3 Class C，最终全量回退到 TC397。正确分工：高层策略（扭矩曲线、热保护、SOH 估算）在 Adaptive HPC，电流环 + PWM + 故障中断在 Classic TC397。
G5: SOA 接口 = 把 CAN 信号名改成服务名 SOME/IP 服务不是 DBC 信号的打包，而是完整 middleware 契约：ara::com 建模 + ARXML RTE 生成 + SOME/IP SD 广播-订阅握手 + E2E Profile adapter。典型漏项：ZCU 在 SOME/IP→CAN-FD 桥中把 E2E 从 Profile 7（CRC32P4，ASIL D）降为 Profile 5（CRC16，ASIL B），ZCU 侧认为"ASIL B 分解链够了"，但 TC397 侧依赖 P7 CRC 做 ASIL D 校验，反序列化直接报错帧——E2E 降级必须经 FuSa 评审并在 SSOT 中显式标注。
G6: ZCU 不是安全组件，ZCU 故障不影响主驱 ASIL D 在 Zonal 架构下，主驱 ASIL D 完整性实际上依赖 ZCU 的可用性——扭矩请求经 HPC→ZCU→MCU 三跳，若 S32G ZCU 掉电，TC397 在 30 ms heartbeat timeout 后才进入 ramp-down/STO。高频漏项：ZCU 与 MCU 共用同一块板上的 12 V PMIC，Cranking 瞬间 12 V 跌至 9 V，PMIC 同时关断 S32G + TC397，CCF 直接击穿 ASIL 分解。解法：ZCU 供电与主驱 MCU 供电物理独立，或至少通过独立 LDO 隔离，DFA 报告中明确标注。
G7: OTA 更新是纯软件行为，不影响主驱安全 HPC 的 Adaptive AUTOSAR ExecutionManager 在 apply OTA 包时会重启 ara::exec 进程，扭矩请求服务（TORREQ）中断 200-800 ms；若此时 ADAS 处于 L2+ 激活态，TC397 侧 30 ms 超时触发 ramp-down/STO，驾驶员感知到意外接管。正确设计：OTA apply 前，HPC 必须发送 ADAS_DEACTIVATE 命令并等待 TC397 ACK（≤100 ms 超时），TC397 确认退出控制环后才允许 OTA 进入 apply 窗口；ISO 14229-1（UDS）OTA 会话管理与 ADAS 功能状态机的握手接口是量产最高频漏项，ODD 定义中须明确"行驶中禁止强制 OTA apply"。
10. Worked Design: 400 V/100 kW BEV Zonal 扭矩服务全链时序核
系统: Qualcomm SA8775P（HPC）+ NXP S32G399A（ZCU）+ Infineon TC397（主驱 MCU） 目标: 验证 SOME/IP→CAN-FD 全链满足 FTTI = 200 ms（HARA H3/E4/C3 = ASIL D）
Step 1 — 服务帧规划
扭矩请求 SOME/IP 帧（HPC 侧）:
| 字段 | 字节数 | 说明 |
|---|---|---|
| SOME/IP header | 16 | Service 0x0810, Method 0x0102, Protocol ver |
| E2E Profile 7 wrapper | 12 | Data ID(2B) + Counter(4B) + CRC32P4(4B) + Length(2B) |
| Payload | 6 | TorqueReq INT16 + TorqLimPos/Neg UINT16 × 2 |
| 合计 | 34 | + UDP/IP/ETH → ~84 B on 1000BASE-T1 |
CAN-FD 转发帧（S32G→TC397）:
| 字段 | 值 | 说明 |
|---|---|---|
| ID / DLC | 0x300 / DLC=12 | 5 Mbps data / 1 Mbps nominal |
| E2E Profile 5 | 4 B | CRC16 HD=5，ASIL B(D) link |
| Payload | 6 B | 同上三参数 |
| 帧时间 | ≈60 µs | 仲裁段 ~24 µs + 数据段 ~26 µs + ACK/EOF ~10 µs |
Step 2 — 端到端时序核算
| 节点 | 环节 | 最坏延迟 |
|---|---|---|
| SA8775P | ADAS 控制周期（100 Hz） | 10 ms |
| SA8775P | ara::com 序列化 + SOME/IP 栈 | ≤0.5 ms |
| 1000BASE-T1 | 帧传输（84 B @ 100 Mbps） | ≤7 µs |
| S32G399A | SOME/IP 解析 + CAN-FD 入队 | ≤1 ms |
| CAN-FD | 帧传输（DLC=12, 5 Mbps 数据） | ≤60 µs |
| TC397 | CAN-FD ISR + FOC 任务等待 | ≤60 µs |
| TC397 | FOC 执行 → PWM 输出 | ≤30 µs |
| 合计 | ≤11.66 ms |
FTTI 裕量: 200 ms / 11.66 ms = 17.2× ✓
主导项为 HPC 应用周期（10 ms = 86% 预算）——提速须从 ADAS 控制率 100 Hz→200 Hz 入手，而非优化通信层。
Step 3 — E2E 残余容错核
| 链路 | E2E Profile | 残余（per frame） | 链路 ASIL 要求 | 结论 |
|---|---|---|---|---|
| HPC→ZCU（Ethernet） | P7 CRC32P4 HD=6 | ASIL D | ✓（见 汽车网络 §12.4） | |
| ZCU→MCU（CAN-FD） | P5 CRC16 HD=5 | ASIL B(D) 分解链 | ✓ |
Step 4 — ASIL 分解链完整性核
ASIL D = B(D) ⊕ B(D):
| 节点 | 角色 | ASIL 等级 | 依据 |
|---|---|---|---|
| TC397 | 主驱 MCU（电流环 / PWM / FI） | ASIL D | Infineon TÜV SÜD ASIL D 产品认证 |
| S32G399A Safety domain | ZCU 安全功能 | ASIL B(D) | NXP SEooC，ISO 26262-11 半导体 |
| SA8775P Cortex-R52 安全岛 | HPC 安全岛 | ASIL B(D) | Qualcomm ISO 26262 Part 11 |
| 系统 | B(D) + B(D) = D，TC397 独立 ASIL D 守底 | ASIL D 满足 | ✓ |
DFA 独立性关键要求（欠 OEM 完整 DFA 报告——结构性欠账）:
- S32G399A 与 TC397 供电须通过独立 LDO（共用 PMIC 是 CCF 路径，见 G6）
- 两者以太网 PHY 物理隔离，不共享接地回路
Step 5 — ZCU 故障 STO 链时序核
ZCU 掉线（S32G 复位）→ TC397 侧 heartbeat timeout:
| 事件 | 时间 |
|---|---|
| ZCU 停发 TORREQ | 0 ms |
| TC397 检测超时（3 周期 × 10 ms） | 30 ms |
| 扭矩 ramp-down（−1 500 Nm/s × ΔT） | 80 ms |
| STO 执行（TC397 内部 WDT 触发） | <5 ms |
| 合计 FTT（故障到安全态） | 115 ms |
FTT 裕量: 200 ms − 115 ms = 85 ms ✓，满足 FTTI 约束。
11. 边界工况（Corner C1-C3）
E/E 架构的真正压力在三个极角：低温冷启服务就绪性、新旧架构混用的时序叠加、OTA 窗口与 ADAS 激活态冲突。
C1: −40°C 冷启 — SOME/IP 服务就绪推迟 SA8775P 在 −40°C 时 Cortex-A78AE 频率降额约 15%，LPDDR5 访问延迟从 10 ns 升至 14 ns，SOME/IP 栈处理时间从 0.5 ms 扩大至 0.7 ms；1000BASE-T1 PHY 的 PCS 训练时间从常温 50 ms 延长至 200-300 ms。整车上电到扭矩服务可用（SOME/IP SD subscription complete）的 cold-start latency 从 500 ms 增加到约 700-800 ms。FTTI 本身不受影响（瞬态延迟 11.66 ms 仍远 < 200 ms），但服务可用性时间窗口需在 −40°C 下单独规定；ADAS 功能状态机须等 TORREQ 服务 SD 应答后才能发出第一个扭矩命令，否则首帧丢失触发不必要的 STO。
C2: Domain + Zonal 并存过渡期 — 网关叠加延迟超 FDTI 整车架构从 Domain 迁 Zonal 通常跨 2-3 个平台，过渡期旧 Domain ECU 仍用 CAN 广播信号，ZCU 须做 Signal→Service 网关。延迟叠加：Domain ECU CAN 帧（100-400 µs）+ ZCU Signal-to-SOME/IP 转换（1-2 ms）+ SOME/IP→CAN-FD 再转（1-2 ms）= 总计 2.1-4.4 ms。原 Domain 架构下 100-400 µs 的报文变成 4 ms——若该信号参与 ASIL 安全机制（如 BMS SOC 对功率限制），4 ms 延迟可能超出 FDTI 预算，引发误触发保护。过渡期须全链实测，而非两段延迟算术叠加。
C3: OTA Apply 窗口与 L2+ 激活态冲突 HPC 的 Adaptive AUTOSAR ExecutionManager 在 apply OTA 包时重启 ara::exec，TORREQ 服务中断 200-800 ms。若此时 ADAS 处于 L2+ 激活态，TC397 侧 30 ms 超时触发 ramp-down/STO，驾驶员感知到意外接管。正确设计：OTA apply 前，HPC 发送 ADAS_DEACTIVATE 命令并等待 TC397 ACK（≤100 ms 超时），确认退出控制环后才进入 OTA 窗口；ISO 14229-1（UDS）OTA 会话管理与 ADAS 状态机的握手接口是量产最高频漏项，ODD 须明确"行驶中禁止强制 OTA apply"。
核心要点
- 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）。