智能驾驶域控制器硬件方案演进趋势分析

划重点

1. 智能驾驶域控制硬件方案的演讲趋势

2. 当前主流的智驾域控硬件方案是N*SoC+ MCU，那么MCU是否可以去掉？

3. 随着芯片集成度不断提升，在理想的情况下，智能驾驶域控硬件方案最终是否会演变成单SoC芯片方案么？

前言：

1.早期：奥迪的zFAS（2015年4月开发完成）是智能驾驶域控制器最早期的架构形态，采用3颗SoC+MCU方案，该方案几乎是把当时在各个应用领域性能最优的芯片组合在了一起。zFAS模块包含：SoC-1（Mobileye-EyeQ3 ）+ SoC-2（英伟达-Tegra K1 VCM ）+SoC-3（Altera-Cyclone V）+MCU（英飞凌—Aurix-TC297T）

• Mobileye - EyeQ3 ：负责前置摄像头图像处理；

• NVIDIA - Tegra K1 VCM  ： 负责环视摄像头图像处理以及驾驶员的状态监控；

• Altera - Cyclone V  ： 负责超声波信号处理；摄像头、毫米波雷达和激光雷达等多源传感器数据融合；作为内部网关实现内部通信；

• Infineon - Aurix TC297T ：用于监控系统的运行状态，并对外进行通信。

受限于整个行业能提供的计算平台算力水平（EyeQ3的AI算力为0.256TOPS，Tegra K1 VCM单浮点运算性能为350GFLOPS，Cyclone V的CPU算力为5250DMIPS），导致zFAS的整体性能水平受到了很大的限制。

两个不同时间段芯片性能的定性比较（信息来源：公开资料整理）

zFAS的电路主板示意图（图片来源 - 硬核汽车电子）

备注：该域控制器由Mobieye提供EyeQ3芯片及对应的软件方案，TTTech提供中间件，奥迪自研一些上层应用算法，安波福进行系统集成。

2.现状：随着芯片厂商开放度提升，SoC芯片集成的异构资源不断丰富，以及CPU算力和AI算力的大幅提高，行车和泊车传感器的数据处理、数据融合等软件算法开始逐渐地集成到一个功能更强大的异构SoC里面去完成。因此，智驾域控硬件方案中选用SoC芯片的种类在减少，但仍然需要ASIL D级别的MCU作为辅助支持，比如德赛西威的IPU03：英伟达-Xavier + 英飞凌Safety MCU；华为的MDC610：昇腾610芯片+英飞凌Safety MCU。虽然有一些域控方案里依然会使用2~4颗SoC，但大都是选择同一种型号的SoC，比如特斯拉的 Autopilot HW3.0平台采用2颗FSD芯片；蔚来的NIO Adam域控平台采用4颗Orin X芯片。

信息来源：公开资料整理

3.未来：随着SoC芯片集成化程度不断提高，越来越多的SoC芯片将会在内部集成ASIL D等级的MCU核心-功能安全岛。那么，外挂的MCU的角色有被SoC内部的功能安全岛所取代的趋势，市场上将会逐渐出现越来越多的单SoC芯片域控解决方案。比如，知行科技的 IDC MID版本，通过单颗 TDA4VM芯片实现行泊一体方案，预计在今年下半年量产应用。

备注 ：

外挂MCU：用于智能驾驶域控制上的SOC大多尚不能满足高功能安全等级的要求，因此，在智驾域控的主板电路上还需要搭配一颗独立的、达到ASILD等级的MCU芯片，比如英飞凌TC297/397等，用于满足安全监控、安全停车等高功能安全需求的应用场景。

内置MCU核心/功能安全岛：通过在SoC内部内置MCU核心，利用锁步的方式提升SoC芯片自身的功能安全等级，同时外设接口也会更丰富，一般会设有单独的CAN接口，作为和整车底盘和毫米波雷达的数据通讯接口，在紧急工况下实现车辆的安全停车。

一、SOC+ MCU硬件方案引发的思考

现在L2+及以上的智能驾驶域控硬件方案的形式主要是：N*SoC+MCU。其中，SoC一般主要负责感知、全局路径规划等，MCU则负责实时性要求很高的整车控制任务。为什么域控制器电路板上要布置一颗独立的MCU芯片,它的作用是什么，去掉它到底行不行？

当前已量产应用的主流智驾域控硬件方案（信息来源：公开资料整理）

1.1 外挂MCU的作用是什么？

在整个智能驾驶解决方案中，外挂MCU 需满足功能安全 ASIL D要求，有多路CAN总线接口和高速以太网接口，能与车身传感器连接，并接收和发送车身CAN总线和以太网信息，从而实现域控平台与整车其它节点进行交互。MCU主要支持的功能如下：

1）整车底盘控制功能：作为最后一道关口，对车辆的执行命令进行校验处理，并对接底盘的控制功能；

2）状态监控 ：供电模块状态、通信状态、以及交互节点状态的监控等；

3）执行最小安全风险策略：当监测到自动驾驶系统发生故障时，外挂MCU会及时进入最小安全风险条件，担负起功能降级、驾驶员接管提醒、安全停车的作用。

1.2 去掉外挂MCU，到底行不行

如果打算去掉MCU，那么原先MCU干的“活”谁来接替呢？只能是SOC了，那么，现在SOC到底有没有这个能力把MCU的活全干了呢？按理说是可以的，因为现在很多的SOC内部开始集成MCU核心-功能安全岛，性能也越来越接近外挂的MCU，比如TDA4VM 内部的功能安全岛，已经可以达到ASILD等级，在一些情况下是完全可以替代外挂MCU。

但是为什么现在主流方案依然还是采用SOC+外挂MCU呢？经过找业界相关专家调研咨询，下面从技术和商业化角度来进行简单地进行分析总结：

1）技术上不是很成熟

虽然越来越多的芯片厂商开始考虑在SoC芯片内部内置MCU核心，但与传统成熟工艺的MCU相比，内置的MCU核心在功能安全、实时性和可靠性方面尚存在一些差距，毕竟任何新技术和新产品都需要一定的时间验证。

安全性不足，内存有限

英飞凌大中华区智能驾驶市场经理余辰杰曾在一次公开演讲中提到：现在的 AI SoC 算力丰富，有 Cortex-A 核、NPU、GPU等。更有一些SoC内部集成一个MCU级别的实时锁步核，称之为safety island。它似乎在灌输一个概念，SoC里面加了一对锁步核就是功能安全ASIL-D了。其实一对锁步的实时核跟ECU系统，甚至仅仅是芯片自身达到 ASIL – D等级都不是一个概念。而且受制于die size，成本等原因，目前一些safety island上只集成了非常有限的RAM。以一个Lockstep R5F附加1M SRAM为例，如果希望程序都运行在RAM中，程序的体积受到明显制约。

《2万字长文说清自动驾驶功能架构的演进》一文中也表达了类似的观点：“未来单SoC的价格会比SoC+MCU便宜，即使单SoC也能符合功能安全ASIL D的要求（目前行业内的大算力SoC只能做到ASIL B），也可以满足网络安全要求，但是对于完全自动驾驶安全而言做到‘相对安全’还远远不够，需要做到‘本质安全’，因此笔者认为外挂MCU还是非常有必要。”

软件移植存在风险

单SoC芯片方案尚未经过充分的市场验证，用内置的MCU核心去取代外挂MCU这种革新式的设计，会有一些风险。

前宇通客车智能网联副院长彭能岭认为，之所以现在主流方案还是SoC +MCU，我觉得大家还是出于一种谨慎的态度，毕竟不同厂家的MCU里面的硬件资源以及硬件性能都不会完全一样。如果把外挂MCU的功能移植到内置功能安全岛，在软件的移植过程中会带来一些风险，比如软件漏洞、软件缺陷等。倒不如沿用现在的SoC+MCU方案更稳妥。毕竟现在的软件比以前更复杂，并且国家对产品的安全性、合规性等要求也越来越高。因此，任何车企都不太愿意贸然去冒风险去掉外挂MCU。

2）商业上不是很合算

现阶段投资回报率低

主机厂或者Tier1已经习惯于把控车等功能放到外挂的MCU上去实现，并在上面跑传统的AUTOSAR CP操作系统。现在Tier1如果打算把外挂MCU的功能迁移到内部不但需要投入人力和时间成本，同时也需要满足一些客观条件：第一个是SoC芯片内置MCU核心的可靠性和功能安全等级达到了规定要求；第二个是整个软件平台也要有对应的方案。从长期来看，这是一个趋势，但过渡肯定需要时间，需要投入研发成本。

寒武纪行歌产品副总裁刘道福提到，对于现在的车型平台，主机厂考虑到研发周期的紧迫性，一般不太愿意去尝试和更换新的架构方案，主机厂已经习惯使用老的架构方案，比如控车用TC297/397等，并且这些方案已经很成熟。对于下一代新的平台，主机厂有更多时间去做研发，会从更高的集成度、更低的量产成本去考虑这件事，可能愿意投入一定的资源去做。在行歌的未来产品中，会考虑将MCU功能集成到SoC中，从而提高域控制器集成度，降低域控制器的整体BOM成本。

“目前国内车厂项目的平台化相对来讲没有海外体系成熟，部分车型项目比较碎片化一些。从Tier1的角度来讲，如果仅仅是拿到了一个车型或者一个项目，量级可能较小，相应的开发费有限。外挂MCU拿掉，虽然硬件上的成本省了一点，但把所有的综合成本算下来，包括重新匹配AUTOSAR、以及在AUTOSAR CP上部署一些其它软件等工作算进去，相比沿用已成熟量产的现成方案，估计不太合算。所以它不仅仅是技术层面的可行性问题，更多还需要从商业的角度考虑。”黑芝麻智能产品副总裁丁丁讲道。

现阶段，外挂MCU方案作为成熟方案，具有实现上的便利性和成本上的优势

外挂的MCU已经形成了完整的产业生态和明确的产业分工。英飞凌，NXP以及瑞萨等传统MCU厂商，MCU已经做了很多代，各方面都已经比较成熟，在生态链上已经有很多合作伙伴。有的合作伙伴负责MCU上AUTOSAR的适配，有的负责上层应用的开发，已经形成了一个完整的产业链条，对于Tier1或者车厂来讲，只要花钱就能够找到合作伙伴帮助他们完成。

安霸软件研发高级总监孙鲁毅认为，外挂MCU的独立性更强，Tier1在它上面开发的一些软件，做一些基础性工作，比如AUTOSAR CP的适配或基于毫米波雷达的一些功能。基于一颗MCU开发的软硬件可以反复重用，而不用顾虑主控的SoC芯片究竟选择的是哪家，进而可以减少Tier1的工程量，缩短开发时间、降低开发成本。

二、单SOC芯片方案的优势以及挑战

当前的智驾域控的主流方案依然是 N*SOC+MCU的形式，但是，去掉外挂MCU在未来是不可忽视的技术趋势。如果方案中去掉外挂MCU，并且行车和泊车功能都整合到一个SOC里，那么就是理想型的单SOC芯片方案了。

2.1 单SOC芯片方案的优势

1）降低系统复杂度，缩短通讯时延

N*SoC+MCU的方案不管是片间的通讯，还是硬件的设计，都比较复杂。软件架构也很难做得很灵活，会存在一些兼容性和适配性的问题。片间虽然可以通过以太网或者PCIe进行通讯，但依然存在一定的通讯延迟。而单soc芯片方案无所考虑片间之间的通讯连接，主计算的性能核与内置的功能安全岛之间共享内存，通信效率比较高，时延要低很多。

2）有利于整车布置和系统硬件成本的降低

单SoC芯片方案，会使得整个系统相对简单，不仅BOM成本能够有一定程度的节省，同时还可以更好的控制域控制器的设计尺寸，便于整车的空间布置。

3）有利于整个系统的OTA升级

即使是单SoC芯片方案，内部也存在多个分区，但加载一套OTA系统即可。孙鲁毅举例说：“智能驾驶域控制器若是采用单SoC芯片方案，那么，跟手机升级流程是类似的——手机里面也是有很多软件，但他们的OTA标准流程是一样的，所有东西都是通过一个软件仓库下载，下载完了进行核对，该升级哪个就升级哪个，这样流程就会比较简单。如果是有两个SoC，可能有的版本需要考虑均衡性，还得考虑先升级哪一个。并且，升级顺序出错了，就会出问题。如果考虑两边一起升级，还需要考虑能不能支持。”

4）功耗会有一定程度的降低

刘道福认为：“单SoC芯片方案的域控制器的功耗表现要好一些。首先，单SoC芯片方案能够避免片间通讯带来的一些能耗；其次，单SoC芯片的域控制器集成度更高，该SoC芯片的溢价较高，芯片厂商就有动力去用更先进的工艺，用更先进的工艺便会带来功耗的减少。”

“功耗实际上是跟驱动电平相关的，芯片一般都是采用3.3V、1.5V或者5V供电。如果是采用双芯片的方案，有可能供电电压不同，就需要匹配两种不同的电平。即使都是TTL电平，有低电压的TTL电平，也有高电压的TTL电平。通常情况下，如果是单芯片方案的话，TTL电平可以做得更低一些。因此整个系统产生的功耗就可以有一定程度的降低。”彭能岭从另外一个更细节的技术角度解释道。

5）应对外挂MCU缺货带来的影响

去掉外挂MCU，采用单SoC方案的另外一个最大的推动力源自英飞凌等MCU大厂的缺货。比如，有很多车厂或域控Tier1都碰到了英飞凌AURIX全系列芯片的缺货。缺货最直接的后果就是涨价，甚至是涨价都买不到。这种情况下，他们只能无奈“被迫”地去选择去开发和应用带有内置MCU核心的单SoC芯片方案了。

2.2 单SOC芯片方案的挑战

1）内部基于功能安全上的隔离

对于智能驾驶域控制器单SoC芯片方案，主计算的部分和其它部分需要做好功能安全上的隔离，因为一个核心的计算模块不希望被其它非核心的计算模块影响到。一般情况下，会按功能安全需求的不同进行划分，对功能安全有要求的区域与对功能安全没有要求的要分开，对功能安全要求特别高和对功能安全要求一般的也要分开。

刘道福说：“单SoC芯片方案在安全上的挑战增加了，需要做更严格的隔离。首先，SoC中MCU区域的功能安全等级比其他区域要求更高，并且，相比于原来的安全岛也会有更多的功能安全设计要求——采用实时核锁步是最基本的，在一些通路的关键电路，甚至会采用TMR（Triple modular redundancy）电路，在极端情况下，某一个通路出现错误时，能通过投票恢复。其次，MCU区域也需要做更严格的隔离，包括时钟、电源都需要完全独立，和SoC的其他区域进行隔离，避免SoC其它区域的故障影响到MCU区域。”

彭能岭也基本认可这一观点：“对于单SoC芯片内部的隔离，不同的公司有不同的做法，比如说内置功能安全岛和主计算单元部分要做解耦隔离：电源部分要隔离，计算单元的部分要做隔离。目前常见的隔离手段是光耦器件，但是采用这种手段，在单颗SoC上怎么把集成度提升又是一个难题。”

2）符合要求的理想型SoC芯片比较少

据某Tier1智驾域控产品经理透露：“单SoC域控方案在未来主要适用于中低端车型，因此主机厂在进行SoC芯片选型的时候，对成本会比较敏感。这就要求芯片厂商在做芯片设计的时候需要能够对市场需求充分了解，既不能遗漏需求，也不能过度设计。性能要好、功耗要低，并且价格还要有优势，从目前来看，能够满足市场需求的、高性价比的SoC芯片几乎没有。”

如果智能驾驶域控要通过1颗SoC芯片来实现所有的功能，那么需要满足：

A. SoC芯片内部的异构类型要丰富

—— AI加速单元：通常是GPU或NPU等，承担大规模浮点数并行计算需求，用于摄像头、激光雷达等传感器信息的识别、融合、分类等；

—— 通用计算单元：由多个车规级多核 CPU 芯片组成，主要负责一些逻辑运算任务，用于管理软硬件资源、完成任务调度，同时整合多源数据完成路径规划等功能。

—— 控制单元：内部应集成ASIL-D等级的MCU核心，用于替代之前外挂MCU，实现车辆动力学的横纵向控制。

—— 图像信号处理单元（ISP）：随着图像分辨率的不断提高，增加了摄像头散热处理的难度，再加上摄像头尺寸小型化的发展趋势，图像处理单元已经不适合内置在摄像头，开始逐渐集成到域控制器的SOC芯片内部。

B. 支持足够多的传感器接入，并能够提供充足的CPU算力和AI算力

传感器接口要丰富，支持多路摄像头视频数据接入，多路以太网设备接入（4D毫米波雷达的主要接口是百兆以太网，激光雷达的主要接口是千兆以太网），多路 CAN 接口设备接入（毫米波雷达）等；

对于低端车型，至少需要5个高清摄像头（泊车至少需要4个，行车至少需要1个）。而中高端车型配置的行车和泊车摄像头加起来在10个以上，甚至不少车型还同时配置有4D毫米波雷达和激光雷达。多源传感器的接入意味着不仅需要配置相应的接口，同时也需要有足够大的内存带宽和充足的算力来保证算法模型的正常运行。

三、从中短期来看，单SOC芯片方案是趋势，但不能Cover所有场景

基于芯片技术的发展和不同等级自动驾驶对域控方案的需求，笔者认为，在中短期内，智能驾驶的硬件架构方案未来会出现两种路线方向：轻量级域控偏向于采用单SoC方案；大算力域控支持更高阶的智能驾驶功能，对功能安全等级的要求较高，并且需要做系统冗余，所以至少需要另外一个SoC用于备份功能，因此，会采用 主SoC +备份SoC的方案，甚至是主域控+副域控制器方案。

3.1 轻量级域控制器 —  单SoC芯片方案  

轻量级智能驾驶域控制器因受产品定位以及成本的限制，所以对算力的要求（一般在十几~几十TOPS左右）、传感器的接入能力以及对功能安全的要求，相比大算力域控制器要低不少。据业内人士透露，即将量产的国产芯片中就有几款可以通过单SoC芯片支持L2+级行泊一体方案。比如行歌SD5223 、黑芝麻的A1000 等。

轻量级域控率先采用单SoC芯片方案，主要跟其产品定义和应用场景有关。因为它的定位是用于实现L1~L2+级的驾驶辅助功能。彭能岭提到 ：“L2级自动驾驶场景一定需要把功能安全等级做那么高么？从合规性的角度，以及产品性能边界的角度来讲，不一定需要。对于L2级，国家法规要求驾驶员对安全负责。系统只是在帮助人开车，不需要进入一种最小风险状态。”

目前已经量产落地的行泊一体域控制器中基本没有采用单SoC芯片方案。但是，从长期的发展趋势来看，芯片的集成化会越来越高，采用单SoC芯片的域控方案将会是未来的发展趋势。因为它能够使得系统的集成度变得更高，不仅能够降低系统硬件成本，还有利于系统的OTA升级。

3.2 大算力域控制器 — 主SoC + 备份SoC/MCU 或者 主域控+副域控方案

为了满足更高级别自动驾驶功能而设计的大算力域控制器，需要做好域控制器的冗余方案，目前主流的方案有两种：

• 在一个板子上做主SoC芯片和备份SoC/MCU芯片（L2+）

• 采用主域控+副域控制器方案（L3及以上）

据某主机厂的自动驾驶系统专家介绍：“从目前来看，采用单颗SoC芯片方案实现系统安全的冗余设计，还没有比较成熟的方案，最稳妥的做法还是采用主SoC+备份SoC/MCU的方案：一个是主计算单元，做一些常态化的计算，另外一个用于安全监控和应急处理的备份计算单元，当主计算单元出问题了，备份的计算单元用于控车。这是目前比较主流的一种设计方案。”

1）主SoC+备份SoC

A.特斯拉 - Autopilot HW3.0 （144TOPS）：主板采用双FSD芯片冗余设计，两颗芯片的供电和数据通道都是独立且互为备份，减少了功能区故障隐患。两颗芯片对同样的数据进行分析，相互验证、比对分析，再得出最终结论，提高了数据处理的安全性和准确性。

AutoPilot HW3.0 硬件主板（图片来源 - 特斯拉AI Day 演讲材料）

B.蔚来 - 超算平台NIO Adam（1016TOPS）：该智能驾驶域控平台采用4颗Orin-X芯片，包括2颗主控芯片+1颗冗余备份芯片+1颗群体智能与个性训练专用芯片。2主控芯片用于实现NAD算法的全栈运算，包含多方案相互校验感知、多源的高精度定位、多模态的预测与决策；1冗余备份芯片用于在主控芯片失效的时候，确保车辆的安全。

蔚来超算平台-NIO Adam（图片来源：蔚来官网）

2）主域控 + 副域控制器

如果是用于支持L3及以上更高级的自动驾驶功能，则需要考虑采用主域控+副域控制器设计方案。因为双芯片方案也会存在一些问题，毕竟是在一块板子上，两颗芯片的位置不会离得特别远，假如遇到一个强磁场，或者高温的影响，两颗芯片很有可能会同时失效。

如果是两个域控，布置的位置会远一些，在极端的情况下，他们受到的影响也是独立的，整个系统的安全性会提高很多。如果是设计两个两个完全相同的域控，则成本便会高很多，一般不会采用这样的设计。为了兼顾成本，一般会选择另外一个干其它工作的域控“兼职”做智驾域控的“副手”，在主域控出问题的时候，能够代替主域控实施控车的职责，把车靠边停下来即可。

主域控+副域控方案示意图（图片来源：《2万字长文说清自动驾驶功能架构的演进》）

A.长城汽车 - GEEP4.0架构：该架构的硬件平台由中央计算平台（CCU）、智能座舱模块（HUT）、智能驾驶模块（IDC），以及3个区域控制器（VIU_L 、VIU_R以及VIU_F）组成。其中IDC是智能驾驶的主控制单元，在高阶自动驾驶配置下，CCU可以作为ICU域控制器的备份，实现最低风险条件。

B.上汽零束 - 银河全栈3.0架构方案：该架构的硬件由两个高性能计算单元HPC1和HPC2以及四个区域控制器（ZONE）构成。两个高性能计算单元中的一个是用于智能座舱和智能驾驶功能，另外一个主要做网关和车控以及BCM等功能，另外还承担智能驾驶的备份功能。

（汽车电子与软件）

声明：本网站所收集的部分公开资料来源于互联网，转载的目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。本站部分作品是由网友自主投稿和发布、编辑整理上传，对此类作品本站仅提供交流平台，不为其版权负责。如果您发现网站上所用视频、图片、文字如涉及作品版权问题，请第一时间告知，我们将根据您提供的证明材料确认版权并按国家标准支付稿酬或立即删除内容，以保证您的权益！联系电话：010-58612588 或 Email:editor@mmsonline.com.cn。