📚 课程目录第2章系统架构设计

第二章系统架构设计：中央计算平台、区域控制器与SOA

好，咱们进入第二章。这一章是整门课的骨架，说白了就是回答一个问题：车上的电脑到底该怎么摆？

我入行那会儿，车上还是分布式架构——一个功能一个ECU，车窗一个、雨刷一个、门锁又一个。线束多得吓人，整车线束长度能绕地球好几圈。后来大家发现这路子走不通了，于是就有了今天要聊的中央计算平台、区域控制器和域控。

先看一张对比表，你就明白为什么行业要推倒重来。

你看，分布式架构最大的问题就是僵化。加个自动泊车？好，再加一个ECU。加个DMS？再挂一个盒子。最后整车电子电气架构变成了"意大利面条"，谁都不敢动。

核心趋势： 从"一个功能一个盒子"走向"一个大脑管所有功能"。中央计算平台就是那个大脑，区域控制器是它的手脚和神经末梢。

中央计算平台（Central Computing Platform，CCP）是舱驾融合的核心。它通常由1~2颗高性能SoC（比如高通Snapdragon Ride、英伟达Orin、地平线征程系列）加上一颗MCU构成。

它的职责很明确：

我参与过一个项目，早期方案是座舱和智驾各用一块板子，中间走以太网通信。后来发现延时和带宽都不够——智驾要实时显示感知结果到中控屏，中间经过两次协议转换，画面延迟肉眼可见。最后我们硬是把两块板子合到了一块底板上，共用内存和电源，延时从50ms降到了5ms以内。

我的建议： 做中央计算平台选型时，别只看算力TOPS。要关注片间互联带宽和内存共享能力。这两个指标决定了舱驾融合的"亲密程度"。

很多人搞不清ZCU和DCU的区别。我简单说：DCU管功能，ZCU管位置。

域控制器（Domain Controller）是按功能域划分的——座舱域、智驾域、底盘域、动力域。每个域控制器负责该域内的所有逻辑和算力。

区域控制器（Zone Controller）是按物理位置划分的——左前区域、右前区域、左后区域、右后区域。它负责该区域内所有I/O的采集和执行，然后把数据打包发给中央计算平台。

看这张图就清楚了：

你看，ZCU不做什么复杂计算，它就是个智能网关+IO集线器。把传感器信号转成网络数据，把网络指令转成执行器动作。DCU则负责逻辑判断和算法运算。

注意： 有些厂商把ZCU和DCU合并了，比如"区域域控一体机"。这种方案省成本但牺牲了灵活性。我个人倾向于物理分离——ZCU靠近执行器，DCU靠近中央计算平台，这样线束最短、延迟最低。

硬件架构定下来之后，软件怎么组织？答案是SOA（面向服务架构）。

SOA不是什么新概念，IT行业用了十几年了。但在汽车上大规模铺开，也就是最近三五年的事。为什么？因为以前车上的软件都是"铁板一块"——一个功能一个进程，互相之间紧耦合，改一个地方可能崩一片。

SOA的核心思想就一句话：把功能拆成独立的服务，服务之间通过标准接口通信。

举个例子，车窗控制：

传统做法：车窗升降逻辑写在BCM里，别的模块想控制车窗？直接调用BCM的内部函数。耦合度高，换BCM就得重写。
SOA做法：车窗控制暴露为一个服务，提供open()、close()、stop()接口。任何模块——座舱域控、手机APP、语音助手——都可以通过SOME/IP或DDS调用这个服务。底层硬件换了？只要接口不变，上层不用改一行代码。

SOA在车上的典型分层：

我曾经在一个项目里踩过坑——服务粒度没控制好。一开始把"车窗控制"拆成了"左前窗升"、"左前窗降"、"右前窗升"……十几个服务。结果服务间通信开销比实际控制逻辑还大。后来合并成WindowControl一个服务，内部用参数区分，性能立马好了。

经验之谈： 服务粒度以"一个功能场景"为单位。比如"一键关窗"是一个服务，而不是"关左前窗"+"关右前窗"两个服务。场景内的高频操作用内部API，场景间用服务接口。

舱驾融合对SOA提出了新要求。以前座舱和智驾各玩各的，现在要打通。

举个典型场景：驾驶员疲劳监测触发自动泊车。

你看，整个过程涉及三个域控、四个服务、两次事件订阅和两次服务调用。没有SOA，这种跨域协作根本没法做——每个接口都得定制，每改一次功能都得重新联调。

关键点： 舱驾融合的SOA设计，核心是服务契约——接口定义、数据格式、QoS要求、超时策略。这些必须在项目启动时就定好，不然后面全是坑。

第二章 系统架构设计：中央计算平台、区域控制器与SOA