第二章 车载域控制器架构：中央计算平台、智驾域控、座舱域控的硬件划分与通信机制
好，咱们直接进入正题。
上一章聊了海思芯片的整体布局，这一章我们聚焦在车载域控制器上。说白了，就是车里的“大脑”到底怎么分工，怎么协作。
我个人习惯把现在的车载电子架构比作一个公司。以前是每个部门各干各的（分布式ECU），现在是把几个核心部门合并成事业部（域控制器），再往上设一个CEO办公室（中央计算平台）。
2.1 为什么需要域控制器？
你想想看，传统车上几十个ECU，每个管一摊事。车窗控制器只管车窗，雨刮器只管雨刮。这种架构在功能少的时候还行，但到了智能驾驶和智能座舱时代，数据量爆炸了。
我在项目中遇到过一台测试车，光CAN总线上的报文就超过2000条。调试一个功能，要翻遍十几个ECU的日志。嗯，那感觉就像在垃圾堆里找针。
所以行业里开始做减法。把功能相近的ECU合并到一个域控制器里。目前主流的分法就是三个域：
- 智驾域控：管感知、决策、控制。说白了就是让车自己开。
- 座舱域控：管仪表、中控、HUD、后排娱乐。让车里的人舒服。
- 中央计算平台：管车身控制、网关、OTA、以及跨域协调。相当于大管家。
核心观点：硬件划分不是拍脑袋定的，而是由数据流和实时性要求决定的。
2.2 硬件划分的底层逻辑
做硬件划分时，我一般会问三个问题：
- 这个功能对实时性要求多高？ 比如AEB（自动紧急制动），要求毫秒级响应。这种必须放在离传感器和执行器最近的域控里，不能绕到中央平台去。
- 这个功能需要多少算力？ 智驾需要几百TOPS，座舱需要几十TOPS，车身控制可能只需要几K MIPS。算力需求不同，芯片选型就不同。
- 这个功能的数据量有多大？ 摄像头数据是Gbps级别的，车身传感器数据是Kbps级别的。数据量大的，尽量本地处理，别到处传。
2.3 智驾域控的硬件构成
智驾域控是三个域里最“吃”硬件的。我见过最夸张的方案，一块板子上塞了四颗海思昇腾芯片。
典型的智驾域控硬件划分如下：
| 模块 | 典型芯片 | 职责 |
|---|---|---|
| 主控SoC | 海思昇腾610/910 | 运行感知算法、决策规划 |
| MCU | Infineon TC397 / NXP S32K | 执行安全控制、ASIL-D功能安全 |
| ISP | 海思自研ISP | 图像信号处理，去噪、宽动态 |
| 存储 | LPDDR5 + eMMC/UFS | 算法模型、数据缓存 |
| 网络 | TSN交换机 | 连接激光雷达、摄像头、毫米波雷达 |
避坑指南：我曾经在一个项目里，把智驾算法全跑在MCU上，结果帧率只有5fps。后来老老实实把感知挪到SoC上，MCU只做安全监控。记住：MCU不是用来跑神经网络的。
2.4 座舱域控的硬件构成
座舱域控更看重多媒体能力和人机交互。海思这边常用的是麒麟系列芯片。
座舱域控的硬件划分有几个特点：
- 多屏异显：一块SoC要同时驱动仪表屏、中控屏、副驾屏、HUD。每个屏的分辨率和刷新率可能都不一样。
- 音频处理：主动降噪、语音唤醒、多音区控制。这些都需要专门的DSP或者NPU。
- 虚拟化：一个硬件上要跑多个操作系统（仪表用QNX，中控用Android）。这需要硬件支持虚拟化扩展。
我记得有一次调试座舱域控，发现中控屏滑动卡顿。查了半天，原来是GPU的带宽被仪表屏的3D渲染抢走了。最后靠硬件分区才解决。嗯，这就是硬件划分没做好的典型后果。
2.5 中央计算平台的定位
中央计算平台不是用来跑大算力应用的。它的核心职责是：
- 跨域通信：智驾域要告诉座舱域“前面有危险”，中央平台负责转发。
- 车身控制：车窗、门锁、灯光这些低算力但高可靠性的功能。
- OTA管理：统一管理所有域控的固件升级。
- 诊断与日志：收集全车故障信息，上传云端。
中央计算平台的硬件通常采用“多核MCU + 低功耗SoC”的组合。MCU负责实时控制，SoC负责网络和协议处理。
2.6 通信机制：数据怎么在域之间跑？
硬件划分好了，接下来就是通信。这是最容易出问题的地方。
目前主流的车载通信机制有几种：
2.6.1 以太网 + SOME/IP
这是智驾和座舱域之间的主力通信方式。SOME/IP是一种面向服务的通信协议，说白了就是“你需要什么服务，我就提供什么服务”。
举个例子，座舱域需要知道当前车速。它不会去轮询CAN总线，而是向智驾域订阅“车速服务”。智驾域每100ms推送一次车速数据。这样既省带宽，又实时。
// SOME/IP服务订阅伪代码
// 座舱域订阅车速服务
subscribe(ServiceID = 0x1234, EventID = 0x01, CycleTime = 100ms);
// 智驾域发布车速数据
publish(ServiceID = 0x1234, EventID = 0x01, Data = {speed: 60.5});2.6.2 CAN FD / CAN XL
车身控制和底盘控制还是离不开CAN。CAN FD比传统CAN快了不少，但跟以太网比还是慢。不过它胜在简单、可靠、成本低。
我建议：控制类信号走CAN，数据类信号走以太网。别混着用，否则调试起来想哭。
2.6.3 PCIe
智驾域控内部，SoC和AI加速器之间通常用PCIe。因为数据量太大了，摄像头原始数据动不动就是几十Gbps。PCIe 4.0 x16可以提供约32GB/s的带宽，够用。
注意：PCIe的功耗和散热是个大问题。我见过一块智驾板子，PCIe走线没做好，信号完整性出问题，导致AI芯片间歇性掉线。最后查出来是PCB的阻抗控制没达标。所以做硬件设计时，PCIe的layout一定要找有经验的工程师把关。
2.7 跨域通信的实时性保障
这是整个架构里最头疼的问题。智驾域要求端到端延迟小于10ms，座舱域要求小于50ms，车身控制可以放宽到100ms。
怎么保证？我一般用这几个手段：
- 优先级调度：在以太网交换机里，给智驾域的数据打最高优先级标签（VLAN PCP=7）。
- 时间同步：所有域控必须同步到同一个时钟源（IEEE 802.1AS或gPTP）。否则你都不知道数据是哪个时刻产生的。
- 预留带宽：给关键数据流预留固定的带宽，避免被其他数据挤占。
我曾经在一个项目里，智驾域和座舱域之间用普通交换机，结果智驾的感知数据把带宽占满了，座舱的仪表显示卡成PPT。后来换了支持TSN的交换机，问题才解决。所以，别在交换机上省钱。
2.8 总结一下
车载域控制器的硬件划分，核心就是一句话：把对实时性要求高的、算力需求大的、数据量大的功能，放在离源头最近的地方处理。
通信机制的选择，取决于你要传什么数据：
- 控制信号 → CAN FD
- 大带宽数据 → 以太网 + SOME/IP
- 芯片间高速互联 → PCIe
下一章我们会深入聊海思芯片在智驾域控里的具体应用，包括昇腾芯片的硬件设计要点。到时候我会分享一些流片回来的踩坑经历，嗯，那才是真正的干货。