HUIXI TECH

一、为什么可以域控

汽车电子电控，无论什么类型，究其本质都可以表达一个简单的控制系统模型：“传感获取输入 => 处理计算 => 驱动执行器输出”。

在以往汽车电子的MCU嵌入式环境中，输入、处理计算和输出是一体的，同一块ECU板子既做信号采集，又做逻辑运算，最后再驱动执行，如此形成闭环。

大多数情况下，ECU与被驱动的零件在物理上就被包在同一个壳体里，供货时的零件状态既包括了例如齿轮结构这些机电结构部分，也包括了芯片和PCB这些承载着软件算法的部分，软硬件二者一体同型，不可分割。

而装到车上后，整车厂负责的是整个系统接口集成和功能打通，彼此之间的接口配合关系在开发过程中就已经相对固化（例如CAN信号矩阵）。此状态下，各ECU以管好自己的零件为主要任务目的，彼此是否能在整车层面灵活协同在功能上玩出花样来，倒在其次。或者说即便有此心，实践起来的变更难度也很大。整车的电子电气框架，在项目开发到中期基本就处于焊死的状态，任何变更都可能劳师动众。

上述是传统状态，车作为一个复杂的大工业品，首要的是精密配合长期稳定工作，在理念上就没有把能灵活变更放在首要考虑上，包括电子电控部分。

域控的概念，或者再进一步中央计算平台的概念，实质上都是在做一件事，就是把前述的三个过程切割开，把其中逻辑处理计算的部分分离开并集中。

要做到能够把逻辑分离并且集中，需要以下几个前提条件：

1. 核心处理芯片升级，由MCU/MPU/SoC，计算能力大幅提升；

2. 车载以太网应用支持了高速实时和大数据量的信息传输能力；

3. 大数据量的传输能力，进一步支撑了面向服务的中间件软件架构。

处理器能力攀升

以动力域为主线来举例，动力域的控制系统其逻辑复杂度在传统汽车电子中属于比较高了，目前都是32位浮点处理器。此外车上其它应用还存在着不少8位、16位的单片机芯片。

大概七八年前，做动力系统的MCU常用型号，以英飞凌的TC178x、NXP的MPC574x为例，都在200MHz以下，性能大约在1.x~2.xDMIPS/MHz水平，因此可以估计算力~400DMIPS。大量动力域和底盘域的控制器已经可以基于这个档位算力实施，例如EMS、VCU、BMS、EPS、ESP等，都有应用上述MCU型号的实例。

以英飞凌为例，后来逐步升级到TC2xx。按照1.7~2.4DMIPS/MHz，200MHz，三核计算，大约算力达到了~1200DMIPS量级。数倍于此前的状态。

近几年又升级到TC3xx，例如TC39x已经达到了4kDMIPS量级，又翻了数倍。

而英飞凌最新出的MPU TC4Dx达到了8kDMIPS量级。

此外，目前行业内应用广泛的MPU S32G，处理器部分有4xA53+3xM7，分别按照2.3DMIPS/MHz @ 1GHz和2.14DMIPS/MHz @ 400MHz计算，其总处理算力达到了11k+DMIPS。

目前行业内应用广泛的TDA4VM，处理器部分包括了2xA72和6xR5F，分别按照7.3DMIPS/MHz @ 2GHz和2.45DMIPS/MHz @ 1GHz计算，其总处理算力达到了40k+DMIPS。

再进一步到SoC，以Qualcomm为例，其后的SA85xx系列算力直奔100~200kDMIPS而去。

从MCU到SoC，CPU算力的跨度足足达到了200倍之多。

当然，MPU和SoC处理的内容也不仅仅是嵌入式系统中纯粹的逻辑系统，还包括运行复杂操作系统如Linux，以及配合其它协处理系统DSP、GPU、NPU等共同完成复杂的图像感知和数据计算密集型算法的处理，单纯去比算力对MCU有点不公平。但总的来说，只是想表达一个观点，就是随着处理器能力的增强，过去的多个控制单元从算力上完全有机会放进同一个芯片中运行；换个角度，用新一代的MCU去处理传统的汽车电子控制系统场景，即便刨除控制策略本身复杂度提升的因素，可能依然会浪费很多计算处理资源。

车载以太网的应用

车载以太网是能实现域控分离的另一个重要的因素。车载应用中，能够实时的交换数据是几乎一切控制功能的基本要求。提到实时性，首先会想到AVB/TSN协议族。但这里我们先不谈AVB/TSN，先算一笔基本账。

以500kbps的CAN网络为例，传递一帧8字节的报文需要大约130us（理论值，实际值会略高~300us），理论传输效率 16us/Byte。类似地，按照百兆以太网100Mbps带宽，一帧报文~1500Bytes大约需要花费120us传输（理论值，实际取决于网络状态和帧间延时等），理论传输效率为0.08us/Byte。二者相比，一来一回相差了足足200倍。

正是这200倍的裕量，进一步为AVB/TSN等协议族提供了足够施展的空间。

面向服务的通讯中间件设计

正是CAN到以太网这种基于物理通讯手段的量级提升，使得信息的传递具备更灵活的可能性。面向服务只是一种工程思考方式，严格来说并不是汽车里的新物种。传统的诊断服务协议UDS就是一种面向服务的思维，但即使用多帧，实时传输的数据量也仅限于数十个字节。但是基于以太网带来的通讯效率的量级提升，使得通讯中间件有了新的可能性。

灵活和效率是一对相互制衡的属性，采用面向服务的架构具备灵活易插拔的能力，但同时会产生额外的协议开销（Overhead），例如包括服务发现、握手、QoS信息的额外传递，本质上是信息熵的编码效率降低。

面向服务化后，可能会出现同样的信号被打包在不同服务报文里多次发送，或同样的报文被不同消费者多次消费，相比例如基于CAN信号的传输都属于冗余。好在物理通讯效率的提升为信息的冗余提供了足够宽阔的空间。当进一步升级到千兆以太网，传统汽车通信网络里的有效负载信息量需要占用的带宽几乎可以忽略，反而是冗余和协议开销占据了主要部分。

正因信息服务化提供了灵活的服务配置，以及节点热插拔、功能动态配置等能力，使得整车内不同控制节点间功能的协同和组合变成可能，进而开发出多种多样的整车功能，并且随着时间变化易于调整和升级。

HUIXI TECH

二、什么样的功能可以域控

车辆控制功能的五域模型

按车辆的功能划分域，考虑可以把域内的功能集中在一起。例如，底盘域、动力域、车身域，以及随着近年来汽车智能化而逐步成型的座舱域、智驾域。上述五域模型是目前比较通用的域控架构概念。

那么接下来，在往域控迈进以至进一步向中央计算平台迈进的过程中，是不是所有的功能都可以被上移到高性能芯片中，答案似乎也不尽然。换言之哪些功能是可以被挪进去，哪些不能，需要进行考量。

车辆控制的时间尺度

用一张图来整理思路，沿横轴方向是时间尺度，上面罗列出了一些汽车电子控制器所处于的位置。

首先，从大的思路上，我认为应该建立全时间尺度的概念。车辆作为一个系统，具备各种各样不同时间尺度的功能要素，跨度很大。其中，就每个时间尺度上分别举例说明：

100us量级：属于超快速计算的场景。例如发动机管理系统中的喷油点火正时，必须严格根据曲轴齿的位置判断，在6000rpm高速旋转时，齿齿间的时间不过100us量级；再如电机矢量控制，高转速可达到15000rpm，此时留给每次旋变位置解码和矢量控制的计算窗口只有50~100us量级。这种情况受物理因素限制，做不到系统无法被有效控制。

1ms量级：快速计算场景。这在嵌入式系统中也算比较快的计算步长了。典型的场景，例如底盘电子中ESC的电磁阀控制，变速箱系统中的电磁阀控制，发动机管理系统中的节气门控制，基本也都是受被控对象的物理特性要求，必须以快速响应才能获得好的控制效果。

10ms量级：大量控制系统会工作在这个时间尺度下，典型的例如VCU、BMS、BCM等等。另外包括EMS、MCU、ESP等控制器中的逻辑控制部分，也会放在这个时间步长下工作。

100ms量级：对实时性低一点的嵌入式控制系统可以放在此时间步长下工作，例如BCM中的座椅、天窗、灯光等，以及空调和热管理系统等。另外，ADAS中的感知规划目前也会工作在这个时间尺度下，但这某种程度上也是不得已而为之，因为即便在高算力SoC上，要完整处理完一套感知融合算法，也需要这么长的时间。

1s/10s量级：对于传统汽车电子系统，这个时间偏慢了。仍有一些功能可以在这个步长下运行，例如BMS中计算健康状态或一些滞回特性，或者混动系统中计算一些能量平衡状态等，都是变化较缓慢的行为，并不需要用很快的频率去计算更新状态。

Minutes/Hours量级：在传统汽车电子系统中用这个步长进行运算的场景就不多了，在这个时间尺度下，信息开始逐步依赖于车云之间的远程通讯链路来获取信息。

基于时间尺度的功能集中

重新审视上面的图，有以下几点想法：

1. 在时间尺度上落在两根红线中间部分的功能，即控制步长在5ms~100s的功能，都可以域控集中化。这部分软件可以从原有的控制器中拿出来，重新放进一个集中的域控制器或者车载中央计算平台中。

2. 而与被控对象驱动密切相关，需要快速运算的，则仍与被控对象的物理硬件绑定；此外，某些传感器信号对长距离传输的噪声敏感，也不能远离物理硬件。

3. 当计算时间尺度增加需要缓存记录较长时间的数据才能计算出有效信息，而对实时性要求不高的，则可以考虑挪到云端去执行。

重点谈一下第1点：

车身域和座舱娱乐域相关的功能，因为对实时性和安全性相对敏感性低一些，把它们域控化似乎已经比较能够被接受。

但这里想说的是，包括一般认为需要强实时性和安全性保证的动力域和底盘域的大部分功能，同样可以如此。对动力和底盘域控制功能域控，最担心的风险是实时性可能不够，无法及时完成控制闭环，尤其当功能与安全相关时尤其显得不可靠。

实时控制的拆解分析

我们这样来考虑这个问题，假设某个动力域或底盘域里的控制闭环以5ms为步长，且不依赖于外部的通讯例如CAN（即不会因为通讯链路引入额外的延迟）。在5ms内，它需要完成A-获取传感器信息；B-逻辑处理运算；C-驱动被控对象三个步骤，如上图左。

然后，当把控制功能上移之后，其核心逻辑处理运算功能转移到了域控或中央控制器中。相应地，增加了B1和B2两项通信开销。即变成了A-获取传感器信息；B0-边缘处理；B1-发送信息；B-逻辑处理运算；B2-接收信息；C-驱动被控对象五个步骤，如上图右。

不仅仅多了B1和B2两个通信步骤，以及相应网络拥塞产生的延时风险，另一方面由于域控制器上可能跑的是Linux这种复杂操作系统，步骤B的任务调度也可能产生延时。实事求是地说这些可能性都存在，但我们继续求证量化分析一下。

1. 以太网通信过程B1/B2：对于结构简单Hop数不超过3的车载以太网，在TSN加持下可以做到延迟最差数百us量级。加上本身的发送时间120us，一来一回总共可以估算为1ms。

2. 逻辑计算任务B：

（1）任务调度：对于加了PREEMPT_RT实时性补丁的Real-Time Linux来说，通常延迟在100us量级，最差情况可以控制在1ms量级。

（2）计算时间：原本MCU的5ms不可能用满，算4ms，在高性能处理器加持下可以减半估为2ms。

3. 负责收发代理的区域/边缘的简化处理器B0，不再承担逻辑计算任务，可以设为1ms运行。

加起来，上述过程一共用了4ms，而且留了余量，实际情况会比这个更短。

必须说明的是，实际场景中会有中断响应、调度、阻塞、资源锁、优先级等等实际问题要妥善解决，以上采用第一性的简化模型进行讨论。

此外，电子控制逻辑中本身也具备相当多的进一步宽容时间限制的可能性。

退一步讲，任务本身对偶尔的时间延时也具备容忍能力，5ms为基准上下抖动几个ms也是原本的设计就要考虑的因素，再说做故障诊断时也需要多个周期确认。

再退一步讲，大部分控制器需要的步长可能在10ms乃至100ms都能够接受，在这种时间裕度下，将更加轻松。

再再退一步讲，如果是多个控制器形成的控制闭环，原本除了本身的计算步长也还要额外加上例如CAN收发的通讯延时，这又提供了时间裕度。

因此，对于车上的大多数控制功能来说，搬移到一个集中的域控/中央运算环境中，是完全可行的。

车云一体视角

从上面时间尺度的分析还有另一点需要特别指出，就是对其中单个的控制系统而言，它的时间尺度也可以具备很大的跨度，这一点是在无线通信和云端数据存储处理技术成熟并且成本足够低的情况下，在汽车上面催生的智能网联新需求。

传统汽车上基本没有连接的概念，每个控制器是自己处理自己系统的事情。可以说铁盒一关，不知今夕是何年，亦不知世界为何。只要上电，就在自己的封闭系统里传感-逻辑-执行，如此往复数十年。

在传统嵌入式系统里，运算资源和存储资源都非常有限，几乎不可能做长时间尺度的事情（这可能需要缓存很多的中间数据处理）；另外，也看不到其它的同款车型的平均状态，所以即使本车的某些特征已经明显出现离群的异常，在本车也没有任何手段可以辨别。但这种需求是并非不存在，只是在传统嵌入式系统中没有条件实现，就被接受为常态了。

随着无线通信技术的进步和云端数据存储处理技术进步，汽车智能网联化已经来到近前。在这种情况下，换一个视角，车辆的很多控制系统都可以拓展到云端，只有将车端和云端合在一起，才构成一个真正完整的控制系统，能够覆盖到这个系统中不同时间尺度的控制需求。

需要说明的是，这种视角跟目前一些车企建立一个云端平台，其中进行一些数据存储、统计和可视化不是一个概念（如下图左）。这里更强调的是从单个控制系统的角度，把本地的控制单元与云端的控制逻辑视同成一个系统，前者分别负责实时控制和数据处理，后者则负责慢时间尺度但时间空间大数据量处理的任务（如下图右）。

对车云一体需求特别强烈的系统，包括电池管理系统BMS（电池状态辨识）、座舱系统（驾驶员习惯风格辨识）、动力系统（驾驶风格，混动能量平衡等）。

HUIXI TECH

三、未来可能的路

应用进程化

在集中化的状态下，基于复杂操作系统来运行，不管是宏内核（例如Linux）还是微内核（例如QNX），原有嵌入式环境中的逻辑控制程序，可以变化为一个或多个进程来，依靠操作系统的实时性调度来运行。如前所述，这种设计对大部分控制场景是有可行性的。

逐步过渡向集中

从实际行业趋势上来说，可能会由座舱娱乐、车身类的功能，逐渐过渡到底盘、动力类的功能。这是由其性质决定，毕竟对于高风险同时又性能要求高的应用，工程师会基于风险厌恶的本能先从容易的部分着手。

但自动驾驶域可能有点特殊，作为一个跟动力和底盘线控密切配合且安全相关的系统，理想情况它的整体计算逻辑流能像VCU一样10ms更新一次（跟着系统中最快的IMU频率跑）最好。但这个速度不是不为也，而是不能也，目前的算力满足不了这个要求（这也是辉羲要解决的目标）。感知、融合、定位、规划等算法模块都可能是“数据密集”+“计算密集”的状态，计算强度的要求相对传统逻辑控制为主的算法飙升，10ms算不完。实际的计算流由摄像头的帧率触发，30FPS就是33ms算一帧，而要完成一个从感知到控制的完整闭环，整个链路要达到100ms以上。所以自动驾驶除规控外的主体部分，从诞生之日起就没在MCU上跑过，虽然从实时性需求角度它更可比拟一个MCU上的应用。

此外，还有很多历史的包袱，例如ESP等底盘件，它的软件成熟不仅仅依靠工程师的专业know-how和开发能力，更依赖于专业试验环境、大量产品验证甚至事故教训才逐步打磨出来。除非能整体移植，否则似乎很难具备量产级的质量说服力。

所以总体上，饭是一口口的吃，由局部到整体逐渐纳入更多的车辆控制功能，逐步由局部的域控走向整体的车载中央计算单元。而更宏观地把车云一体纳入来看，在车上的“车载中央计算单元”，在整体上也可以定位成“边缘计算服务器”，而云端的超强算力和数据存储能力则成为“计算中心”。

车+云二位一体的状态，覆盖到从实时性到长周期各种时间尺度的特征，构成完整的控制系统。

虚拟化

破局之道可能在于虚拟化能力的不断提升。按目前的认知把虚拟化分几个段位，纯软件的虚拟化 >> 硬件支持的CPU虚拟化 >> GPU/NPU/...的虚拟化 >> 硬件支持下的多容器虚拟化。

一个控制功能要起作用，会用到多方面的资源，包括CPU、RAM、IO、Ethernet/CAN等通讯、SD/eMMC/UFS存储，以及可能更复杂一点的NPU、GPU、Display、PCIe、MIPI-CSI、ISP等等资源。

虚拟化程度提升的过程，实际上就是根据不同的场景要求，实现不同层级的资源共享与隔离的过程。可以考虑到的是，从Baremetal开始，到Hypervisor，再到操作系统的内核、cgroup、进程、线程、协程，结合硬件的虚拟化支持，每一层具备不同能力的资源分配和隔离以及相应的性能开销，从而适合不同的场景。