第1章域控概述

一、域控概述：从分布式到集中式的进化之路

大家好，我是这次课程的主讲人。做了十多年的嵌入式开发，从最早的8位单片机一路干到现在的多核域控，说实话，这个行业的变迁速度，有时候连我自己都觉得有点跟不上。

今天咱们先聊聊域控制器。嗯，这可能是整个课程里最基础、但也最重要的一章。基础打不牢，后面那些复杂的软硬件协同设计，你理解起来会很吃力。

先问大家一个问题：你想想看，一辆传统汽车里有多少个ECU？

我2015年参与过一个项目，拆开一辆中端车型的线束图，数了数，大大小小70多个ECU。每个ECU管自己的那点事——车窗的只管车窗，车灯的只管车灯，雨刮的只管雨刮。它们之间通过CAN总线、LIN总线互相喊话，但说白了，就是各干各的。

这种架构有什么问题？我举个例子。有一次我在现场调试，发现车窗升降和门锁控制之间有0.5秒的延迟。查了两天才找到原因：两个ECU之间的CAN消息优先级冲突了。你说头疼不头疼？

域控制器（Domain Controller）就是来解决这个问题的。

它的核心思路很简单：把功能相近的ECU合并成一个高性能的计算单元。比如，把发动机、变速箱、刹车这些跟动力相关的，合并成一个「动力域控制器」；把仪表、中控、HUD这些跟人机交互相关的，合并成一个「座舱域控制器」。

域控制器的本质： 一个高性能的嵌入式计算平台，通过虚拟化或操作系统隔离技术，在一个硬件上运行多个功能域，替代原来分散的多个ECU。

我个人习惯把域控理解成「超级ECU」。它不再是那个只有几百KB Flash、几十KB RAM的小家伙了。现在的域控，动不动就是4核、8核的ARM Cortex-A系列处理器，配上几GB的DDR，跑着Linux或者QNX。

咱们来看一张图，这是我手绘的汽车电子电气架构演进图。

从这张图你能看到，域控制器处于中间那个位置。它既不是过去那种「一个螺丝一个帽」的分布式ECU，也不是未来那个「大一统」的中央计算平台。

我2018年参与过一个量产项目，用的就是域集中架构。当时我们做了三个域控：动力域、车身域、座舱域。说实话，光是把原来20多个ECU的功能合并到3个域控里，就花了整整8个月。为什么？因为每个ECU的供应商不同，软件接口千奇百怪，有的用CAN，有的用LIN，有的甚至还在用K线。

我的经验： 做域控架构设计时，千万别想着一步到位。先做功能聚类，把耦合度高的功能放在同一个域里。比如车窗和门锁，它们经常需要联动，放在同一个域控里，延迟问题自然就解决了。

这个问题我经常被问到。很多刚入行的朋友会混淆这两个概念。我简单说说我的理解。

说白了，域控是「分而治之」的思路。每个域控管好自己的那一亩三分地，域与域之间通过以太网通信。而中央计算平台是「集中管理」的思路，所有传感器数据都汇总到一个超级大脑里处理。

我记得有一次跟一个主机厂的架构师聊天，他说了句话让我印象很深：「域控是过渡方案，但也是必经之路。」为什么？因为从分布式直接跳到中央计算，技术跨度太大了。你想想看，一个做雨刮控制的工程师，突然让他去写多核异构的虚拟化代码，这不现实。

避坑指南： 我曾经见过一个项目，团队一上来就想做中央计算平台，结果搞了两年连原型都没跑通。后来老老实实退回域控架构，半年就量产了。我的建议是：如果你的团队没有超过50人的底层软件团队，别碰中央计算平台，先做好域控再说。

聊完了概念，咱们说说实际干活会遇到哪些坑。我总结了三个最核心的挑战：

这些问题，咱们后面的章节会一个一个展开讲。今天先把概念理清楚。

本章核心要点：

好了，第一章就到这里。内容不多，但都是干货。下一章咱们聊聊域控的硬件架构设计，我会拿一个实际量产项目的板级设计图来拆解。到时候见。

公众号:蓝海资料掘金营，微信deep3321