第2章多域控制器硬件架构

第2章多域控制器硬件架构：中央计算单元(CCU)、智能座舱域(ICD)、自动驾驶域(AD)、车身域(BCM)的硬件组成

好，咱们进入正题。上一章聊了OTA升级的整体框架，这一章得把硬件底子摸清楚。

为什么我坚持要先讲硬件？因为OTA升级说白了，就是给这些硬件“喂”新软件。硬件长什么样、用什么芯片、怎么连的，直接决定了你的升级策略怎么设计。我在项目里见过太多人，上来就写升级逻辑，结果发现某个域控的Flash分区根本不够用——那叫一个尴尬。

2.1 中央计算单元(CCU)的硬件构成

CCU是整个车的“大脑”。我个人习惯把它比作一个超级路由器加服务器的混合体。

2.1.1 核心处理器

CCU通常采用高性能SoC，比如高通SA8295、英伟达Orin或者瑞萨R-Car H3。嗯，这里要注意，选型时不能只看算力，还得看它的安全岛( Safety Island )是否独立。我踩过坑，有一次选了一款没有独立安全核的芯片，结果做功能安全认证时，OTA升级过程中的回滚逻辑怎么都过不了审核。

关键参数表：

芯片型号	算力(TOPS)	安全岛	典型应用
高通SA8295	30	有	座舱+中央网关
英伟达Orin	254	有	自动驾驶+中央计算
瑞萨R-Car H3	2.5	无(需外挂)	入门级中央网关

2.1.2 存储与分区

CCU的存储设计，直接决定了OTA能不能“双区备份”。我建议至少分三个区：

Bootloader区：只读，负责启动校验。我曾经见过有人把Bootloader也OTA了，结果升级失败直接变砖——血的教训。
Active区：当前运行的系统。
Standby区：升级目标区。升级时写入这里，成功后切换启动指针。

我的经验：Standby区的大小至少是Active区的1.2倍。为什么？因为压缩包解压后可能比原系统大。别问我怎么知道的，问就是吃过亏。

2.2 智能座舱域(ICD)的硬件组成

ICD是用户直接打交道的域。你想想看，如果座舱升级失败，中控黑屏了，车主第一个骂的就是你。

2.2.1 显示与交互硬件

ICD通常包含：

主控SoC（如高通SA8155）
GPU模块（负责渲染）
音频DSP（处理语音交互）
多路显示输出（仪表、中控、HUD）

这里有个坑：多路显示输出意味着升级时不能同时刷新所有屏幕。我做过一个项目，OTA升级仪表固件时，中控还在播放视频，结果仪表黑屏了3秒——用户投诉说“车坏了”。后来我们加了升级时序控制，先冻结中控，再升级仪表。

2.2.2 通信接口

ICD与CCU之间通常走PCIe或千兆以太网。为什么？因为要传输高清地图数据。我记得有一次调试，发现座舱升级包下载速度只有2MB/s，查了半天，原来是CCU和ICD之间的以太网协商成了百兆模式。嗯，硬件工程师把网线压错了。

注意：ICD的OTA升级必须保留“降级通道”。因为座舱软件更新频繁，万一新版本有bug，用户能一键回滚。我见过某车企，座舱升级后空调界面不见了，就是因为没留降级接口。

2.3 自动驾驶域(AD)的硬件架构

AD域是安全等级最高的。说白了，升级失败可能导致车辆失控，所以硬件设计上极其保守。

2.3.1 主控与冗余

AD域通常采用“主-从”或“双主”架构：

主SoC：如英伟达Orin、华为昇腾310，负责感知和规划。
安全MCU：如Infineon TC397，负责监控和降级控制。
冗余存储：两个独立的Flash芯片，分别存A/B系统。

我个人习惯在AD域上做“三区备份”：A区、B区、以及一个“黄金恢复区”。黄金恢复区只存最稳定的基础版本，平时不更新。为什么？因为有一次OTA升级把A/B区都写坏了，要不是有黄金区，那批车就得拖回工厂了。

2.3.2 传感器接口

AD域需要连接摄像头、激光雷达、毫米波雷达。这些传感器的固件升级，必须通过AD域控转发。你想想看，如果升级激光雷达时，车辆还在路上跑——那画面太美我不敢看。所以，AD域的OTA升级必须做“状态机”：

// 伪代码示例：AD域升级状态机
enum UpgradeState {
    IDLE,           // 空闲
    PRE_CHECK,      // 预检（车速、电源、温度）
    DOWNLOADING,    // 下载中
    INSTALLING,     // 安装中（车辆必须静止）
    VERIFYING,      // 校验中
    ROLLBACK        // 回滚
};

if (vehicle_speed > 0) {
    // 车速不为0，禁止进入INSTALLING状态
    state = IDLE;
    log("安全限制：车辆未静止");
}

关键点：AD域的升级包必须带数字签名，且签名算法要用ECC（椭圆曲线）。RSA太慢了，升级包动辄几个GB，RSA验签能卡死你。

2.4 车身域(BCM)的硬件组成

BCM管的是门锁、车窗、灯光、雨刮这些“小东西”。但别小看它，BCM升级失败，车可能锁不上或者打不着火。

2.4.1 微控制器选型

BCM通常用MCU而不是SoC，比如NXP S32K、瑞萨RH850。为什么？因为成本敏感，而且不需要高算力。我建议选带双Bank Flash的MCU，这样OTA时可以一边运行一边写另一个Bank。

MCU型号	Flash大小	双Bank	CAN接口
NXP S32K144	512KB	支持	3路
瑞萨 RH850/F1L	1MB	支持	4路
TI TMS570	2MB	支持	2路

2.4.2 网络拓扑

BCM通常挂在CAN或CAN FD总线上。升级时，CCU通过网关把升级包转发到CAN总线。这里有个问题：CAN总线带宽只有1Mbps（CAN FD能到8Mbps），升级一个512KB的固件需要好几秒。我做过一个优化：先把升级包压缩，然后在BCM端解压。压缩率大概能到60%，时间缩短了一半。

避坑指南：我曾经遇到过BCM升级时，CAN总线被其他报文塞满，导致升级包丢帧。解决方案是：升级期间，让BCM发送“总线负载请求”，通知其他节点降低发送频率。

2.5 域间通信与OTA协同

四个域控不是孤立的。CCU作为OTA主控，需要协调ICD、AD、BCM的升级顺序。

2.5.1 通信链路

CCU ↔ ICD：PCIe或千兆以太网，用于传输大文件（如地图、UI资源）。
CCU ↔ AD：以太网+冗余CAN，用于传输算法模型和传感器固件。
CCU ↔ BCM：CAN FD，用于传输车身控制固件。

2.5.2 升级时序

我建议的升级顺序是：BCM → ICD → AD → CCU。为什么？因为BCM最基础，先升级它确保车辆基本功能正常；ICD次之，因为用户能直观看到进度；AD和CCU最后，因为它们涉及安全核心。

警告：绝对不要同时升级两个域。我见过一个项目，同时升级ICD和AD，结果两个域都卡在“等待重启”状态，CCU也死机了——整车变砖。后来我们加了“域间互锁”机制：一个域升级完成并确认后，才能开始下一个。

好了，硬件架构就聊到这儿。下一章咱们会深入每个域的软件分区设计，那才是OTA升级的真正战场。记住一句话：硬件决定了OTA的下限，软件决定了上限。

📚 课程目录