请添加微信号进入传感器组/滑板底盘组:xsh041388
请添加微信号进入域控制器组/操作系统组:ckc1087
注：传感器/滑板底盘/域控制器 真实姓名、公司、职位
1.智能驾驶域控制硬件方案的演讲趋势
2.目前主流的智能驾驶域控硬件方案是N*SoC MCU，那么MCU能去掉吗？
3.随着芯片集成度的不断提高，智能驾驶域控硬件方案最终会演变成单一吗？SoC芯片方案？
1.奥迪的zFAS(2015年4月开发完成)是智能驾驶域控制器最早的架构形式，采用3颗SoC MCU该方案几乎将当时各应用领域性能最好的芯片组合在一起。zFAS模块包含：SoC-1（Mobileye-EyeQ3） SoC-2（英伟达-Tegra K1VCM） SoC-3（Altera-CycloneV） MCU（英飞凌—Aurix-TC297T）
Mobileye - EyeQ3：负责前置摄像头图像处理；
NVIDIA - Tegra K1VCM： 负责环视摄像头图像处理和驾驶员状态监控；
Altera - CycloneV：负责超声信号处理；多源传感器数据集成，如摄像头、毫米波雷达和激光雷达；内部通信作为内部网关；
Infineon - Aurix TC297T ：用于监控系统的运行状态，并进行外部通信。
受整个行业能够提供的计算平台计算能力水平的限制（EyeQ3的AI算力为0.256TOPS，Tegra K1 VCM单浮点运算性能为350GFLOPS，Cyclone V的CPU算力为5250DMIPS），导致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 Adam4个域控平台Orin X芯片。
3.随着SoC芯片集成度不断提高，越来越多SoC芯片将在内部集成ASIL D等级的MCU核心功能安全岛。然后，插件MCU的角色有被SoC取代内部功能安全岛的趋势将逐渐出现在市场上SoC芯片域控解决方案。比如知行科技 IDC MID通过单个版本 TDA4VM芯片实现行泊一体化方案，预计今年下半年量产应用。
用于智能驾驶域控制SOC大部分都不能满足高功能安全等级的要求。因此，智能驾驶域控主板电路需要独立匹配ASILD等级的MCU像英飞凌这样的芯片TC用于满足安全监控、安全停车等高功能安全全停车等高功能安全297/397等。
通过在SoC内部内置MCU核心，通过锁步提升SoC芯片本身的功能安全等级，外设界面会更丰富，通常会有单独的CAN接口，作为车辆底盘和毫米波雷达的数据通信接口，在紧急情况下实现车辆的安全停车。
一、
现在L2 以上智能驾驶域控硬件方案主要以：N*SoC MCU。其中，SoC一般主要负责感知、全局路径规划等，MCU则负责实时性要求很高的整车控制任务。为什么域控制器电路板上要布置一颗独立的MCU芯片，它的作用是什么，可以去掉吗？
在整个智能驾驶解决方案中，插件MCU 功能安全需要满足 ASIL D要求，多路CAN总线接口和高速以太网接口可与车身传感器连接，接收和发送车身CAN总线和以太网信息，实现域控平台与车辆其他节点的交互。MCU支持的主要功能如下：
1)车辆底盘控制功能:作为最后一道关口，检查车辆的执行命令，并连接底盘控制功能；
2）状态监控 ：监控供电模块状态、通信状态和交互节点状态；
3)实施最小安全风险策略:当监控自动驾驶系统故障时，插件MCU及时进入最小安全风险条件，发挥功能降级、司机接管提醒、安全停车的作用。
假如打算去掉MCU，那么原先MCU谁来接替工作？只能是SOC嗯，现在SOC有没有能力把这个能力放在一起？MCU的活全干了呢？可以合理地说，因为现在有很多SOC内部开始集成MCU核心功能安全岛，性能越来越接近插件MCU，比如TDA4VM 可以实现内部功能安全岛ASILD在某些情况下，外挂可以完全替代MCU。
但为什么主流方案仍然采用呢？SOC 外挂MCU呢？在寻找行业相关专家进行研究和咨询后，从技术和商业化的角度进行简单的分析和总结：
尽管越来越多的芯片制造商开始考虑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。
主机厂或者Tier1已经习惯于将控车等功能放在外挂上MCU上去实现，在上面跑传统的AUTOSAR CP操作系统Tier如果你打算插件MCU功能迁移到内部不但需要投入人力和时间成本，同时也需要满足一些客观条件：第一个是SoC芯片内置MCU核心的可靠性和功能安全等级达到了规定要求；第二个是整个软件平台也要有对应的方案。从长期来看，这是一个趋势，但过渡肯定需要时间，需要投入研发成本。
寒武纪行歌产品副总裁刘道福提到，对于现在的车型平台，主机厂考虑到研发周期的紧迫性，一般不太愿意去尝试和更换新的架构方案，主机厂已经习惯使用老的架构方案，比如控车用TC297/397等，并且这些方案已经很成熟。对于下一代新的平台，主机厂有更多时间去做研发，会从更高的集成度、更低的量产成本去考虑这件事，可能愿意投入一定的资源去做。在行歌的未来产品中，会考虑将MCU功能集成到SoC中，从而提高域控制器集成度，降低域控制器的整体BOM成本。
“目前国内车厂项目的平台化相对来讲没有海外体系成熟，部分车型项目比较碎片化一些。从Tier1的角度来讲，如果仅仅是拿到了一个车型或者一个项目，量级可能较小，相应的开发费有限。外挂MCU拿掉，虽然硬件上的成本省了一点，但把所有的综合成本算下来，包括重新匹配AUTOSAR、以及在AUTOSAR CP上部署一些其它软件等工作算进去，相比沿用已成熟量产的现成方案，估计不太合算。所以它不仅仅是技术层面的可行性问题，更多还需要从商业的角度考虑。”黑芝麻智能产品副总裁丁丁讲道。
外挂的MCU已经形成了完整的产业生态和明确的产业分工。英飞凌，NXP以及瑞萨等传统MCU厂商，MCU已经做了很多代，各方面都已经比较成熟，在生态链上已经有很多合作伙伴。有的合作伙伴负责MCU上AUTOSAR的适配，有的负责上层应用的开发，已经形成了一个完整的产业链条，对于Tier1或者车厂来讲，只要花钱就能够找到合作伙伴帮助他们完成。
安霸软件研发高级总监孙鲁毅认为，外挂MCU的独立性更强，Tier1在它上面开发的一些软件，做一些基础性工作，比如AUTOSAR CP的适配或基于毫米波雷达的一些功能。基于一颗MCU开发的软硬件可以反复重用，而不用顾虑主控的SoC芯片究竟选择的是哪家，进而可以减少Tier1的工程量，缩短开发时间、降低开发成本。
二、
当前的智驾域控的主流方案依然是 N*SOC+MCU的形式，但是，去掉外挂MCU在未来是不可忽视的技术趋势。如果方案中去掉外挂MCU，并且行车和泊车功能都整合到一个SOC里，那么就是理想型的单SOC芯片方案了。
N*SoC+MCU的方案不管是片间的通讯，还是硬件的设计，都比较复杂。软件架构也很难做得很灵活，会存在一些兼容性和适配性的问题。片间虽然可以通过以太网或者PCIe进行通讯，但依然存在一定的通讯延迟。而单soc芯片方案无所考虑片间之间的通讯连接，主计算的性能核与内置的功能安全岛之间共享内存，通信效率比较高，时延要低很多。
单SoC芯片方案，会使得整个系统相对简单，不仅BOM成本能够有一定程度的节省，同时还可以更好的控制域控制器的设计尺寸，便于整车的空间布置。
即使是单SoC芯片方案，内部也存在多个分区，但加载一套OTA系统即可。孙鲁毅举例说：智能驾驶域控制器若是采用单SoC芯片方案，那么，跟手机升级流程是类似的——手机里面也是有很多软件，但他们的OTA标准流程是一样的，所有东西都是通过一个软件仓库下载，下载完了进行核对，该升级哪个就升级哪个，这样流程就会比较简单。如果是有两个SoC，可能有的版本需要考虑均衡性，还得考虑先升级哪一个。并且，升级顺序出错了，就会出问题。如果考虑两边一起升级，还需要考虑能不能支持。
刘道福认为：“单SoC芯片方案的域控制器的功耗表现要好一些。首先，单SoC芯片方案能够避免片间通讯带来的一些能耗；其次，单SoC芯片的域控制器集成度更高，该SoC芯片的溢价较高，芯片厂商就有动力去用更先进的工艺，用更先进的工艺便会带来功耗的减少。”
功耗实际上是跟驱动电平相关的，芯片一般都是采用3.3V、1.5V或者5V供电。如果是采用双芯片的方案，有可能供电电压不同，就需要匹配两种不同的电平。即使都是TTL电平，有低电压的TTL电平，也有高电压的TTL电平。通常情况下，如果是单芯片方案的话，TTL电平可以做得更低一些。因此整个系统产生的功耗就可以有一定程度的降低。彭能岭从另外一个更细节的技术角度解释道。
去掉外挂MCU，采用单SoC方案的另外一个最大的推动力源自英飞凌等MCU大厂的缺货。比如，有很多车厂或域控Tier1都碰到了英飞凌AURIX全系列芯片的缺货。缺货最直接的后果就是涨价，甚至是涨价都买不到。这种情况下，他们只能无奈“被迫”地去选择去开发和应用带有内置MCU核心的单SoC芯片方案了。
对于智能驾驶域控制器单SoC芯片方案，主计算的部分和其它部分需要做好功能安全上的隔离，因为一个核心的计算模块不希望被其它非核心的计算模块影响到。一般情况下，会按功能安全需求的不同进行划分，对功能安全有要求的区域与对功能安全没有要求的要分开，对功能安全要求特别高和对功能安全要求一般的也要分开。
刘道福说：“单SoC芯片方案在安全上的挑战增加了，需要做更严格的隔离。首先，SoC中MCU区域的功能安全等级比其他区域要求更高，并且，相比于原来的安全岛也会有更多的功能安全设计要求——采用实时核锁步是最基本的，在一些通路的关键电路，甚至会采用TMR（Triple modular redundancy）电路，在极端情况下，某一个通路出现错误时，能通过投票恢复。其次，MCU区域也需要做更严格的隔离，包括时钟、电源都需要完全独立，和SoC的其他区域进行隔离，避免SoC其它区域的故障影响到MCU区域。”
彭能岭也基本认可这一观点：“对于单SoC芯片内部的隔离，不同的公司有不同的做法，比如说内置功能安全岛和主计算单元部分要做解耦隔离：电源部分要隔离，计算单元的部分要做隔离。目前常见的隔离手段是光耦器件，但是采用这种手段，在单颗SoC上怎么把集成度提升又是一个难题。”
据某Tier1智驾域控产品经理透露：“单SoC域控方案在未来主要适用于中低端车型，因此主机厂在进行SoC芯片选型的时候，对成本会比较敏感。这就要求芯片厂商在做芯片设计的时候需要能够对市场需求充分了解，既不能遗漏需求，也不能过度设计。性能要好、功耗要低，并且价格还要有优势，从目前来看，能够满足市场需求的、高性价比的SoC芯片几乎没有。”
如果智能驾驶域控要通过1颗SoC芯片来实现所有的功能，那么需要满足：
—— ：通常是GPU或NPU等，承担大规模浮点数并行计算需求，用于摄像头、激光雷达等传感器信息的识别、融合、分类等；
—— ：由多个车规级多核 CPU 芯片组成，主要负责一些逻辑运算任务，用于管理软硬件资源、完成任务调度，同时整合多源数据完成路径规划等功能。
—— 内部应集成ASIL-D等级的MCU核心，用于替代之前外挂MCU，实现车辆动力学的横纵向控制。
—— ：随着图像分辨率的不断提高，增加了摄像头散热处理的难度，再加上摄像头尺寸小型化的发展趋势，图像处理单元已经不适合内置在摄像头，开始逐渐集成到域控制器的SOC芯片内部。
传感器接口要丰富，支持多路摄像头视频数据接入，多路以太网设备接入（4D毫米波雷达的主要接口是百兆以太网，激光雷达的主要接口是千兆以太网），多路 CAN 接口设备接入（毫米波雷达）等；
对于低端车型，至少需要5个高清摄像头（泊车至少需要4个，行车至少需要1个）。而中高端车型配置的行车和泊车摄像头加起来在10个以上，甚至不少车型还同时配置有4D毫米波雷达和激光雷达。多源传感器的接入意味着不仅需要配置相应的接口，同时也需要有足够大的内存带宽和充足的算力来保证算法模型的正常运行。
三、从中短期来看，单SOC芯片方案是趋势，但不能Cover所有场景
基于芯片技术的发展和不同等级自动驾驶对域控方案的需求，笔者认为，在中短期内，智能驾驶的硬件架构方案未来会出现两种路线方向：轻量级域控偏向于采用单SoC方案；大算力域控支持更高阶的智能驾驶功能，对功能安全等级的要求较高，并且需要做系统冗余，所以至少需要另外一个SoC用于备份功能，因此，会采用 主SoC +备份SoC的方案，甚至是主域控+副域控制器方案。
轻量级智能驾驶域控制器因受产品定位以及成本的限制，所以对算力的要求（一般在十几~几十TOPS左右）、传感器的接入能力以及对功能安全的要求，相比大算力域控制器要低不少。据业内人士透露，即将量产的国产芯片中就有几款可以通过单SoC芯片支持L2+级行泊一体方案。比如行歌SD5223 、黑芝麻的A1000 等。
轻量级域控率先采用单SoC芯片方案，主要跟其产品定义和应用场景有关。因为它的定位是用于实现L1~L2+级的驾驶辅助功能。彭能岭提到 ：“L2级自动驾驶场景一定需要把功能安全等级做那么高么？从合规性的角度，以及产品性能边界的角度来讲，不一定需要。对于L2级，国家法规要求驾驶员对安全负责。系统只是在帮助人开车，不需要进入一种最小风险状态。”
目前已经量产落地的行泊一体域控制器中基本没有采用单SoC芯片方案。但是，从长期的发展趋势来看，芯片的集成化会越来越高，采用单SoC芯片的域控方案将会是未来的发展趋势。因为它能够使得系统的集成度变得更高，不仅能够降低系统硬件成本，还有利于系统的OTA升级。
为了满足更高级别自动驾驶功能而设计的大算力域控制器，需要做好域控制器的冗余方案，目前主流的方案有两种：
在一个板子上做主SoC芯片和备份SoC/MCU芯片（L2+）
采用主域控+副域控制器方案（L3及以上）
据某主机厂的自动驾驶系统专家介绍：“从目前来看，采用单颗SoC芯片方案实现系统安全的冗余设计，还没有比较成熟的方案，最稳妥的做法还是采用主SoC+备份SoC/MCU的方案：一个是主计算单元，做一些常态化的计算，另外一个用于安全监控和应急处理的备份计算单元，当主计算单元出问题了，备份的计算单元用于控车。这是目前比较主流的一种设计方案。”
A.：主板采用双FSD芯片冗余设计，两颗芯片的供电和数据通道都是独立且互为备份，减少了功能区故障隐患。两颗芯片对同样的数据进行分析，相互验证、比对分析，再得出最终结论，提高了数据处理的安全性和准确性。
B.该智能驾驶域控平台采用4颗Orin-X芯片，包括2颗主控芯片+1颗冗余备份芯片+1颗群体智能与个性训练专用芯片。2主控芯片用于实现NAD算法的全栈运算，包含多方案相互校验感知、多源的高精度定位、多模态的预测与决策；1冗余备份芯片用于在主控芯片失效的时候，确保车辆的安全。
2）
如果是用于支持L3及以上更高级的自动驾驶功能，则需要考虑采用主域控+副域控制器设计方案。因为双芯片方案也会存在一些问题，毕竟是在一块板子上，两颗芯片的位置不会离得特别远，假如遇到一个强磁场，或者高温的影响，两颗芯片很有可能会同时失效。
如果是两个域控，布置的位置会远一些，在极端的情况下，他们受到的影响也是独立的，整个系统的安全性会提高很多。如果是设计两个两个完全相同的域控，则成本便会高很多，一般不会采用这样的设计。为了兼顾成本，一般会选择另外一个干其它工作的域控“兼职”做智驾域控的“副手”，在主域控出问题的时候，能够代替主域控实施控车的职责，把车靠边停下来即可。
GEEP4.0架构：该架构的硬件平台由中央计算平台（CCU）、智能座舱模块（HUT）、智能驾驶模块（IDC），以及3个区域控制器（VIU_L 、VIU_R以及VIU_F）组成。其中IDC是智能驾驶的主控制单元，在高阶自动驾驶配置下，CCU可以作为ICU域控制器的备份，实现最低风险条件。
银河全栈3.0架构方案：该架构的硬件由两个高性能计算单元HPC1和HPC2以及四个区域控制器（ZONE）构成。两个高性能计算单元中的一个是用于智能座舱和智能驾驶功能，另外一个主要做网关和车控以及BCM等功能，另外还承担智能驾驶的备份功能。
如果希望与文章作者直接交流，可以直接扫描右方二维码，添加作者本人微信。
注：加微信时务必备注您的真实姓名、公司、岗位等信息，谢谢！
如果您有兴趣给《九章智驾》投稿（“知识积累整理”类型文章），请扫描右方二维码，添加工作人员微信。
注：加微信时务必备注您的真实姓名、公司、岗位
以及投稿意向等信息，谢谢！
A：信息密度高于绝大多数券商的绝大多数报告，不低于《九章智驾》的平均水平；
B：信息要高度稀缺，需要80%以上的信息是在其他媒体上看不到的，如果基于公开信息，需要有特别牛逼的独家观点才行。多谢理解与支持。
◆九章 - 2021年度文章大合集
◆当候选人说“看好自动驾驶产业的前景”时，我会心存警惕——九章智驾创业一周年回顾（上）
◆数据收集得不够多、算法迭代得不够快，就“没人喜欢我”————九章智驾创业一周年回顾（下）
◆一文读懂BEV空间内的特征级融合
◆2万字长文说清自动驾驶功能架构的演进
◆行泊一体 - 打通智能驾驶的“任督二脉”