2. 中央计算平台概述
中央计算平台的本质，是把原本散落在几十甚至上百个 ECU 中的算力、存储与通信资源，按“集中—分层—服务化”的思路重新组织。理解它，需要同时看清三条主线：架构形态从分布式走向集中式，控制器角色从域控制器演进到区域控制器，软硬件从“一功能一盒子”走向“硬件分层 + 软件分层”。
一、核心原理：分布式与集中式的资源组织差异
分布式架构下，每个功能（车窗、座椅、空调、制动）都有独立 ECU，通过 CAN/LIN 总线互联。它的优点是故障隔离好、开发解耦；缺点是线束长、重量大、算力碎片化、跨域协同困难。集中式架构则把计算资源收敛为少数高性能计算单元，用高速以太网骨干连接，功能以软件形式部署在统一平台上。
集中化的关键收益不是“少几个盒子”，而是算力可复用、数据可共享、软件可迭代。例如自动泊车需要摄像头、雷达、转向、制动协同，分布式下需多 ECU 反复协商；集中式下这些信号进入同一计算平台，时延和一致性显著改善。
二、域控制器与区域控制器的演进逻辑
域控制器（Domain Controller）按功能域划分：动力域、底盘域、座舱域、智驾域、车身域。它解决了“同域功能集中”，但跨域通信仍需网关转发，且不同域控制器可能重复配置算力与接口。
区域控制器（Zonal Controller）按物理位置划分：前、后、左、右区域。它把该区域内的传感器、执行器、灯光、门锁等就近接入，再通过以太网骨干上联中央计算单元。这样线束大幅缩短，I/O 接口标准化，新增功能只需在中央计算单元部署软件，无需改动区域控制器硬件。
| 对比维度 | 分布式 | 域控制器 | 区域控制器 + 中央计算 |
|---|---|---|---|
| 划分依据 | 单功能 | 功能域 | 物理区域 |
| 线束长度 | 最长 | 中等 | 最短 |
| 算力利用率 | 低 | 中 | 高 |
| 跨域协同 | 困难 | 网关转发 | 平台内直接通信 |
| 软件迭代 | 逐 ECU 刷写 | 按域 OTA | 整车级 OTA |
| 典型通信 | CAN/LIN | CAN FD + 以太网 | 千兆以太网 + TSN |
三、典型硬件形态与软件栈分层
硬件形态上，中央计算平台通常由中央计算单元（CCU）、区域控制器（ZCU）和高速通信骨干组成。CCU 内常见 SoC + MCU 异构：SoC 跑座舱与智驾，MCU 负责实时安全控制；ZCU 以 MCU 为主，承担 I/O 采集与执行驱动。
软件栈自下而上分为：硬件层、驱动/BSP 层、操作系统与 Hypervisor 层、中间件层、服务与应用层。中间件是通信与中间件工程的核心，负责服务发现、序列化、SOME/IP、DDS、TSN 时间同步等。
应用层 │ 座舱应用 · 智驾应用 · 车身服务
服务层 │ SOA 服务注册 / 发现 / 编排
中间件层 │ SOME/IP · DDS · TSN · 时间同步
系统层 │ Hypervisor · RTOS · Linux · AUTOSAR AP
驱动层 │ BSP · 传感器驱动 · 网络驱动
硬件层 │ SoC · MCU · 交换机 · 区域 I/O
四、案例与常见误区复盘
某车型将车身、座舱、智驾三个域合并为中央计算 + 四个区域控制器。改造后线束减少约 30%，OTA 从“逐 ECU 刷写”变为整车级升级。但初期也出现两个问题：一是区域控制器 I/O 标准化不足，导致新传感器接入仍需改硬件；二是 SOME/IP 服务发现配置错误，跨区域通信时延抖动。
1. 认为“集中式就是把所有功能塞进一个盒子”，忽略安全隔离与实时性分级；
2. 区域控制器只做线束汇聚，未预留标准化 I/O 与算力余量；
3. 软件栈分层不清，应用直接调用硬件驱动，导致无法跨平台复用；
4. 忽视 TSN 时间同步与网络冗余，跨域控制出现时序错乱。
复盘结论：中央计算平台的落地，硬件收敛只是第一步，真正的难点在于通信中间件的服务化能力与软硬件解耦的分层设计。只有把区域控制器做成标准化 I/O 节点，把中央计算单元做成服务运行平台，才能支撑后续功能持续迭代。