自动驾驶域控制器开发和量产的挑战

什么是域控制器

过去十多年的汽车智能化和信息化发展产生了一个显著结果就是ECU芯片使用量越来越多。从传统的引擎控制系统、安全气囊、防抱死系统、电动助力转向、车身电子稳定系统；再到智能仪表、娱乐影音系统、辅助驾驶系统；还有电动汽车上的电驱控制、电池管理系统、车载充电系统，以及蓬勃发展的车载网关、T-BOX和自动驾驶系统等等。

传统的汽车电子电气架构都是分布式的，汽车里的各个ECU都是通过CAN和LIN总线连接在一起，现代汽车里的ECU总数已经迅速增加到了几十个甚至上百个之多，整个系统复杂度越来越大，几近上限。在今天软件定义汽车和汽车智能化、网联化的发展趋势下，这种基于ECU的分布式EEA也日益暴露诸多问题和挑战。

汽车分布式EEA

为了解决分布式EEA的这些问题，人们开始逐渐把很多功能相似、分离的ECU功能集成整合到一个比ECU性能更强的处理器硬件平台上，这就是汽车“域控制器（Domain Control Unit，DCU）”。域控制器的出现是汽车EE架构从ECU分布式EE架构演进到域集中式EE架构的一个重要标志。

域集中式EE架构

域控制器是汽车每一个功能域的核心，它主要由域主控处理器、操作系统和应用软件及算法等三部分组成。平台化、高集成度、高性能和良好的兼容性是域控制器的主要核心设计思想。依托高性能的域主控处理器、丰富的硬件接口资源以及强大的软件功能特性，域控制器能将原本需要很多颗ECU实现的核心功能集成到一起来，极大提高系统功能集成度，再加上数据交互的标准化接口，因此能极大降低这部分的开发和制造成本。

对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如BOSCH划分为5个域：动力域（Power Train）、底盘域（Chassis）、车身域（Body）、座舱域（Cockpit/Infotainment）、自动驾驶域（ADAS）。

ADAS/AD系统方案演变进程梳理

（一） L0-L2级别的ADAS方案

早期大多数L0-L2级别的ADAS系统都是基于分布式控制器架构，整个ADAS系统由4-5个ADAS子系统组成，每个子系统通常是个一体机整体方案（可以被看作是一个smart sensor），子系统独占所配置的传感器，通常相互之间是独立的。

以智能前视摄像头模块（Intelligent Front Camera Module，FCM）为例，整个子系统ECU主板上包含2颗芯片：一颗是安全核（Safety Core）；另一个颗是性能核（Performance Core）。安全核一般由英飞凌TC297/397之类的MCU充当，承载控制任务，因此需要较高的功能安全等级需求；性能核通常是具有更高性能算力的多核异构MPU，会承载大量的计算任务。

下面是一个对L0-L2级别方案的总结：

L0级别方案：实现各种ADAS报警功能，比如：FCW、LDW、BSW、LCA等。分布式架构，通常由FCM、FCR、SRRs、AVS、APA等几大硬件模块组成。

L1级别方案：完成各种ADAS单纵向核单横向控制功能，比如：ACC、AEB、LKA等。也是分布式架构，硬件模块组成与L0级别方案大致相同。

L2级别方案：完成ADAS纵向+横向组合控制功能。比如：基于FCM+FCR融合系统，融合前向视觉感知和前雷达目标感知信息，实现TJA/ICA等功能；或者基于AVS+APA的融合系统，实现自动泊车功能。

（二）L2+以上级别的ADAS方案

分布式架构的ADAS系统存在两个致命缺点：1）各个子系统互相独立，无法做多传感器之间的深度融合。2）各子系统独占所配置的传感器，因此无法实现跨多个不同子系统传感器的复杂功能。

当整车EE架构演进到域集中式EEA之后，ADAS域控制器中配置了集成度更高、算力性能更高的计算处理器平台，进而可以支撑更复杂的传感器数据融合算法，以实现更高级级别的ADAS功能，比如：HWP、AVP等。

集中式ADAS域控制器方案从最早的四芯片方案，过渡到三芯片方案，再到当前业界主流的两芯片方案，如下图所示：

主机厂对于域控的诉求

由于不同类型的域控制器市场定位不同，因此针对于不同类型的智能驾驶域控制器，主机厂在与Tier1合作过程中的诉求也是不一样的。

中低算力域控制器：主机厂若是在前期没有做好自研准备，现在多半是不会再去搞自研或者联合开发。对主机厂来讲，做好自己的需求定义，比如在控制器里面，主控芯片选什么，需要有什么样的功能，然后直接交给供应商去做就好，这样效率会更高。对他们而言，现在最需要的是能够快速交付，尽快地把新功能推向市场，以保证产品在市场上的竞争力。因此，对于中低算力域控制器，主机厂大多会选择让供应商提供“交钥匙”的方案。

对于中低算力的轻量级域控制器，行业内有基于TDA4平台的方案，也有基于TDA4 +地平线J3的方案。不管是哪种方案，产品定位基本相同——主要用于实现L1~L2+级别的辅助驾驶功能。此功能应用场景相对简单，对功能安全要求也相对较低。对于此类域控制器，主机厂比较看重供应商的成本管控和落地效率，其竞争力在于是否能够提供一款高性价比的产品。

德赛西威副总裁李乐乐举例说：“对于中低算力的行泊一体域控制器，比如低速场景只是实现APA和HPA功能 ，不需要人在车外，功能安全等级要求较低。高速场景上做L1到L2+，方向盘不脱手，人可以随时介入，这种轻量级域控上所集成的功能就需要重点打磨。开发这类域控制器的主要挑战是如何在算力和成本有限的情况下，把性能做到极致。因为其上层应用算法、中间件和底层软件要联合优化，耦合度高，软硬难以解耦。“

大算力域控制器：在量产时间上还有一个缓冲期，主机厂还有时间和精力与Tier1一起去搞联合开发。更何况头部的主机厂大都希望能够全栈自研，即使自己现在搞不定全栈，也希望在与Tier1的合作中能够更多地参与进去，从而在双方的合作过程中去不断地去补足自己的短板。

大算力域控制器用于配置在中高端车型，是作为技术高点和品牌宣传的亮点。 因此从受重视程度上来讲，是中低算力的轻量级域控所不能比的，这是能够体现品牌力和影响力的重要因素。

德赛西威李乐乐解释道：“中低算力域控需要不断打磨和优化策略来弥补算力的不足，在有限成本下把性能做到最好，也就是追求性能和成本的平衡。但是大算力域控目前不用担心算力不足的问题，由于算力本身就非常强大，即使不用对算法做特别的压缩和模型简化，大网络也能运行的非常流畅，体现出极强的性能。

“从这一层面来看，可以理解成大算力域控的硬件与算法功能的耦合性相对会低一些，主机厂和Tier1之间的协同性要求比轻量级域控开发低很多。因此，大算力域控制器适合Tier1和主机厂进行协同开发，主机厂可以专心做上层软件去打造差异化，不用因为担心算力不够用而把双方大量的资源和精力投入到裁剪优化上。”

灵活多样的合作模式

由于各家主机厂实力水平参差不齐，并且各自的战略规划也不同，因此对于域控制器的需求也是多样化的。Tier1要保证自己的产品能够尽快量产落地，快速地实现自己的数据闭环，能够不断地去迭代自己的产品，就需要尽量地去满足客户差异化的需求。

因此，域控制器Tier1在与主机厂合作的过程中，产生了多样化的合作模式。主要有以下几种形式：

硬件+底层软件

硬件+底层软件+中间件

硬件+底层软件+中间件+部分应用算法（行车 or 泊车 or DMS）

硬件+底层软件+中间件+全部应用算法 （全栈交付）

当然，提供多样化的合作模式也给供应商带了一定的压力和考验。毕竟开发需求越多 ，资源投入就会越大。反过来讲，能够经受住这些挑战，并充分利用自身有限的资源去满足主机厂的需求，也有利于Tier1提升其自身竞争力。

德赛西威李乐乐告诉九章智驾：“ 对于智能驾驶域控制器，客户在软硬件层面均会存在一些差异化的需求。”

“在软件层面，有的客户希望短平快，选择Linux操作系统，因为Linux的生态系统比较完善，可以满足功能快速实现。但是选择Linux，功能安全就没办法实现，这种情况我们会尽量增加一些冗余设计，包括芯片内部的出错诊断，做一些能做的安全相关的设计。当然，也有些客户基于功能安全层面的考虑会选择QNX实时操作系统。同样，除了需要提供底层软件外，有的客户希望我们提供中间件，也有客户需要我们提供全栈工程的交付。这就需要我们基于客户的不同需求去做好边界的划分和接口的定义。

“在硬件层面，基于算力需求的不同，客户会选择不同类型的芯片或不同的组合形式。有的客户选择单Orin 110TOPS，也有选择单Orin X的254 TOPS，更有选择双Orin X的508 TOPS，甚至有客户要求两个双Orin X的板子背靠背集成到一起达到1016TOPS算力。

“另外，从整车架构集成角度来看，不同的OEM也有不同的规划，有一些客户希望在大算力自动驾驶域控平台上集成网关、VCU，也有一些客户希望能集成IMU、GPS定位模块，甚至也有一些希望能集成V2X模块。这些都可以配合客户去提供差异化定制开发的支持。”

总之，主机厂需求不同，域控制器供应商Tier1在服务客户的方式上也会存在差异。无论双方选择哪种合作模式，最终都是以硬件为载体，并以产品的形态给到主机厂，只是在分工上会有差别。

对Tier1的挑战在于前期做系统需求设计的时候，需要能够结合客户的差异化需求，提供一个完整的平台化设计，并且能够在平台基础上可进行差异化定制的更改，确保能提供一个最适合客户需求的设计方案。

域控制器设计开发和量产落地面临的挑战

1） 硬件层面

传统分布式ECU对接口、功耗或者算力相对来说要求不高，而现在的域控制器集成了更多的功能，需要处理的数据越来越多，所要求的的算力越来越大。因此，域控制器变得更加复杂，需要的电子元器件非常多 。做好内部所有硬件功能安全上的Fail-safe设计是比较有挑战性的工作。同时，在电磁抗干扰能力、信号完整性层面也面临很大的难题。

另外，大算力的芯片会产生新的功耗，产生较大的热量，需要做好尺寸和散热之间的平衡。

德赛西威副总裁李乐乐告诉九章智驾：“大算力域控制器用到的元器件物料数量要远超于过去任何车上ECU内的元器件数量。在功能安全方面，需要做好WCCA（最坏情况电路）分析和失效概率分析以及对应的备份设计，在元器件非常多且系统复杂的前提下，要做好它的功能安全设计是非常有挑战的。

“其次，由于整车本身布置空间比较有限，在充分满足可靠性、电磁兼容和环境试验要求的情况下把域控制器的外形设计控制在较小的尺寸范围内也比较具备挑战性。

“对于大算力域控制器往往发热也比较高，目前的主流解决方案都是通过水冷的设计来解决散热问题。这要求有很强的热仿真能力，才能做好很精巧的水冷散热管道方案，同时又能通过软件监控主要芯片内温度，并根据这些芯片内温度来控制水冷系统入水温度和流速。做好这样一套温度监控、入水温度和流速的控制闭环系统，需要建立一套模型，并做好仿真和测试，避免水冷液过冷或过热导致控制器内部凝水或无法及时散热的问题。”

2）软件层面

如何做好SOA服务化？多个核或者是多个SoC之间如何做好协同通讯、高速计算、算力的部署、实时调度等？如何保证软件架构的灵活性以及软件的功能安全和预期功能安全？这些都是域控制器设计开发在软件层面面临的挑战。

东软睿驰刘威博士提到：“从整个软件的功能上来看，现在大家都在做SOA。实际上SOA服务化对算力是有影响的。虽然大家都说自己在做SOA，但差异还是挺大的。比如，哪些信号能够服务化，哪些信号不能服务化，到目前为止尚无统一的定论。因为，第一，它要依赖于整个的应用需求；第二，需要依赖于整车架构；第三，还需要依赖于整个硬件的算力性能。”

从整个软件的实现角度来看，除了硬件考虑功能安全，软件的功能安全也是必须要考虑的，并且工作量非常大。从底层的驱动到基础软件，再到上层一些中间件，一直到最上层的应用，所有的这些软件都要考虑功能安全。并且，对于高阶自动驾驶功能，还要考虑软硬件的预期功能安全。

3）技术工程化层面

智能驾驶域控制器系统相对来说比较新，对系统化的设计能力要求很高。如果系统在开发的过程中出现问题，需要有能够透过问题的表象，看到问题本质的能力，能够把产生的问题逐层分解下去，最后把它解决掉。这对于整个团队的技术工程化理解能力的要求还是很高的。

福瑞泰克喻清舟认为：当出现功能和体验问题的时候，团队是否能够从应用算法端一直挖到最底层的传感器。问题的根源有可能是芯片驱动导致，或者感知导致，能不能在这个链条里面从前到后把所有链路都打通，对团的能力是最直接的挑战。”

4）开发周期层面

在软件定义汽车的时代，明显可以看到，产品迭代速度都在加快。为了将其快速地推向市场，主机厂在拼命地想办法压缩新车的开发周期，因此Tier1不得不去改变其传统的开发模式，借鉴互联网科技公司的开发理念去形成自己新的开发模式，来进行快速响应。

智能驾驶域控制器作为一个比较新的软硬件一体的产品，牵涉的合作方也比较多。当问题出现的时候，需要有人能够把问题定位出来，然后再进行拆解分配给不同的责任方去解决。尤其是一些深层次的问题，定位问题本身就比较消耗时间，同时对于新系统，后期出现的问题也会很多。这在一定程度上也耗费了很多开发周期上的时间。

宏景智驾蔡文利讲到：“由于主机厂都有严格的量产时间节点，所以很多ADAS项目都对工期要求特别紧张，这对ADAS服务商是一把双刃剑。我们需要具有为客户定制化开发的服务意识和技术能力，又要有资源调配的灵活性，愿意配合自己的客户，共同打磨出一款能够量产并且让客户满意的产品。这里面的挑战主要还是在于如何协调好企业内部的资源，有条不紊、把握节奏按时保质保量地交付产品。这是对整个企业系统设计经验、项目管理、资金投入等全方位的挑战。”

知行科技硬件研发总监认为：“在短开发周期的压力下，Tier1的工程基础能力是否足以来应付开发过程中出现的问题，并快速地解决。同样也考验Tier1的生态，你的合作伙伴能不能快速地来支撑你，以及是否有资源来支持你去解决这些问题。”

5）供应链保障层面

较大的市场需求导致半导体供应链和产能紧缺，包括疫情在内的各种“天灾人祸”不断扰乱半导体的正常生产节奏，而需求与产能之间的矛盾在短期内难以解决。在全球芯片供应链如此紧张的背景下，对于域控制器供应商而言，供应链的保障也是十分的具有挑战性。整车厂在选择域控制器供应商的时候，其合作伙伴芯片厂商的供货能力也是重要的考量指标。

总结：工作需要，梳理了自动驾驶域控制器的发展历程、行业分类、量产落地挑战等信息。梳理完，思路清晰多了。真的是站在前辈的肩膀上，才能看得更远！

- End -

审核编辑 ：李倩