2. 中央计算平台概述
中央计算平台（Central Computing Platform，CCP）是智能汽车电子电气架构从“分布式”走向“集中式”的核心载体。它把原本分散在几十个 ECU 中的计算、通信、存储与供电资源，按功能域或整车级进行整合，形成以高性能计算单元（HPC）为中心、区域控制器（ZCU）为边缘节点、软件可升级的分层架构。其本质不是“把盒子做大”，而是把整车电子系统从“硬件定义、功能叠加”重构为“算力集中、软硬解耦、服务化调度”。
一、定义与核心原理
中央计算平台通常由三层构成：中央计算层承载座舱、智驾、车控等高性能计算；区域接入层负责就近采集传感器、执行器信号并完成供电与通信汇聚；软件平台层提供 SOA 服务、OTA、诊断、安全与资源调度。其核心原理可概括为“集中算力、分布接入、软件定义、服务通信”。
与传统 ECU 各自为战不同，中央计算平台强调资源池化：CPU、GPU、NPU、内存、存储被统一编排，不同业务以容器、虚拟机或实时任务形式共享算力。通信上，车内主干从 CAN/LIN 转向车载以太网，配合 SOME/IP、DDS 等中间件，实现跨域数据低时延流转。
二、演进历程：从分布式到中央集中
整车电子电气架构的演进大致经历四个阶段。第一阶段是分布式架构，每个功能一个 ECU，线束长、重量大、升级困难。第二阶段是域集中架构，按动力、底盘、座舱、智驾划分域控制器，域内集成、域间通过网关通信。第三阶段是跨域融合架构，座舱与智驾开始共用算力，区域控制器逐步替代大量小 ECU。第四阶段是中央计算+区域接入架构，即当前量产主攻方向：中央 HPC 统一算力，ZCU 负责边缘 IO，软件全车统一 OTA。
这一演进背后有两条主线：一是算力需求爆炸，智能驾驶与智能座舱对 AI 算力、带宽、内存的要求远超传统 MCU；二是软件价值提升，车企希望通过 OTA 持续迭代功能，而分布式架构下每个 ECU 独立升级，成本高、协同难。
三、与传统分布式架构的对比
| 对比维度 | 传统分布式架构 | 中央计算平台架构 |
|---|---|---|
| 计算资源 | 分散在 50～100 个 ECU，算力碎片化 | 集中到 1～3 个 HPC，算力池化共享 |
| 通信方式 | CAN/LIN 为主，带宽低、时延不确定 | 车载以太网为主，高带宽、低时延 |
| 线束复杂度 | 线束长、连接器多、重量大 | 区域接入缩短线束，减少连接器 |
| 软件升级 | 各 ECU 独立刷写，协同困难 | 整车统一 OTA，服务化升级 |
| 功能扩展 | 新增功能需新增 ECU 与线束 | 软件定义，算力复用，扩展灵活 |
| 成本结构 | 硬件成本高、软件价值低 | 前期投入高、规模化后边际成本低 |
四、典型应用场景
- 智能座舱：多屏互动、语音助手、舱内感知、AR-HUD 共用一颗座舱 HPC，通过虚拟化隔离不同安全等级业务。
- 智能驾驶：多摄像头、激光雷达、毫米波雷达数据汇聚到智驾 HPC，完成感知、融合、规划、控制闭环。
- 整车控制：车身、动力、底盘功能通过 ZCU 就近接入，中央平台统一调度，实现如迎宾、露营、宠物模式等场景化功能。
- 车云协同：中央平台作为车端数据出口，支持影子模式、数据回传、远程诊断与 OTA。
五、量产挑战与常见误区
量产挑战：中央计算平台从样车到量产，难点不在“能不能跑”，而在“能不能稳定、安全、低成本地跑”。主要挑战包括：功能安全与信息安全隔离、实时性与确定性调度、散热与功耗、供应链与芯片选型、软件团队组织重构、OTA 失败回滚、诊断与售后体系适配。
常见误区：一是把“中央计算”简单理解为“把 ECU 合并”，忽视软件架构重构；二是只关注算力峰值，忽视内存带宽、时延与安全隔离；三是低估区域控制器线束与供电设计难度；四是认为 OTA 只是升级车机，实际涉及全车 ECU 协同与法规合规。
量产集成检查清单（示例）：
1. HPC 算力余量 ≥ 30%，内存带宽满足多路视频并发
2. 关键业务满足 ASIL-B/D 隔离要求，非安全业务不得干扰
3. 以太网主干时延 < 10ms，丢包率 < 1e-6
4. ZCU 供电与诊断覆盖所有末端负载
5. OTA 支持 A/B 分区、断点续传、失败回滚
6. 整车网络唤醒与休眠电流满足静态功耗目标
7. 诊断协议 UDS over IP 全链路打通
8. 热设计满足 -40℃～85℃ 环境与持续高负载工况总体来看，中央计算平台是智能汽车从“硬件堆叠”走向“软件定义”的必经之路。理解其定义、演进、对比、场景与量产挑战，是后续开展架构设计、软硬件集成与量产验证的基础。