3. 中央计算平台总体架构
中央计算平台的本质，是把过去分散在几十个 ECU 中的算力、软件与数据，收敛到少数高性能计算单元上，并通过分层解耦的方式重新组织。理解这套分层模型，是后续做平台选型、软件部署、通信设计与 OTA 升级的前提。业界通常把它划分为五层：硬件层、系统软件层、功能软件层、应用软件层、云端协同层。分层不是简单的堆叠，而是"下层为上层提供稳定抽象、上层通过标准接口调用下层能力"的契约关系。
一、五层模型的职责与边界
硬件层是物理底座，包含 SoC/计算芯片、MCU 安全岛、内存与存储、车载以太网交换、PCIe/CAN/LIN 接口、电源管理与散热。它决定平台的算力上限、功能安全等级与接口带宽。系统软件层负责把异构硬件抽象成统一资源，包括 Hypervisor、BSP/驱动、实时操作系统（RTOS）与通用操作系统（如 Linux/Android）、中间件通信栈（SOME/IP、DDS、共享内存）、时间同步与资源隔离。功能软件层是"可复用的服务能力"，例如感知融合、定位、诊断、标定、日志、健康管理、SOA 服务框架，它不直接面向用户，而是被多个应用共享。应用软件层承载具体业务，如智能座舱、智驾行车、车身控制、能量管理。云端协同层则提供 OTA、数据回传、影子模式、数字孪生与远程诊断，让车端与云形成闭环。
二、层间接口：分层能否落地的关键
分层模型最容易失败的地方，不是层没画出来，而是层与层之间没有稳定接口。硬件层向上通过 HAL（硬件抽象层） 暴露统一设备访问；系统软件层向上通过 POSIX 与中间件 API 提供进程、通信、时间能力；功能软件层向上通过 SOA 服务接口与 IDL 暴露可调用服务；应用软件层通过 车云 API 与云端交互。接口一旦标准化，同一应用就能在不同 SoC 平台上迁移，同一功能服务也能被多个应用复用。
# 典型 SOA 服务接口定义（IDL 片段）
service PerceptionFusion {
method GetObstacleList(InputZone) returns (ObstacleList);
method GetFreespace(InputZone) returns (FreespaceGrid);
event ObstacleUpdated(ObstacleList);
}
# 车云协同接口
topic vehicle/ota/status # 升级状态上报
topic vehicle/shadow/data # 影子模式数据回传
rpc cloud/diagnose/query # 远程诊断请求三、典型场景：一次 OTA 升级如何贯穿五层
以智驾功能 OTA 为例：云端协同层生成升级包并下发策略；应用软件层接收新版本智驾应用；功能软件层同步更新感知融合服务；系统软件层校验签名、切换 A/B 分区、重启对应容器；硬件层完成存储写入与安全启动校验。整个过程要求版本一致性、回滚能力与安全启动三者同时满足。若只升级应用而忽略功能软件层接口变更，就会出现"应用能启动、服务调不通"的典型故障。
| 层级 | 核心职责 | 关键接口/技术 | 常见风险 |
|---|---|---|---|
| 云端协同层 | OTA、数据闭环、远程诊断 | MQTT、HTTPS、车云 API | 断点续传失败、版本错配 |
| 应用软件层 | 业务功能实现与迭代 | SOA 服务调用、容器化部署 | 接口不兼容、资源抢占 |
| 功能软件层 | 可复用服务与公共能力 | IDL、服务框架、诊断栈 | 服务粒度不合理、耦合过重 |
| 系统软件层 | 资源抽象、隔离与通信 | Hypervisor、RTOS、中间件 | 实时性不足、隔离失效 |
| 硬件层 | 算力、接口与安全底座 | SoC、MCU、以太网、PCIe | 算力瓶颈、散热与功耗 |
四、误区与复盘
复盘一个真实项目：某车型将座舱与智驾合并到同一 SoC，初期把两者都放在同一 Linux 域，结果智驾实时任务被座舱图形任务抢占，出现偶发延迟。整改方案是在系统软件层引入 Hypervisor，把智驾 RTOS 域与座舱 Android 域隔离，并通过共享内存做跨域数据交换。这说明分层模型必须配合资源隔离与优先级设计，否则只是纸面架构。
掌握五层模型后，后续的算力分配、通信设计、软件部署与 OTA 策略，都可以落到具体层级上讨论，而不是笼统地说"平台要升级"。