标签: 域控制器

什么是域控制器？ 过去十多年的汽车智能化和信息化发展产生了一个显著结果就是 ECU 芯片使用量越来越多。从传统的引擎控制系统、安全气囊、防抱死系统、电动助力转向、车身电子稳定系统；再到智能仪表、娱乐影音系统、辅助驾驶系统；还有电动汽车上的电驱控制、电池管理系统、车载充电系统，以及蓬勃发展的车载网关、 T-BOX 和自动驾驶系统等等。 传统的汽车电子电气架构都是分布式的（如下图 2-1 ），汽车里的各个 ECU 都是通过 CAN 和 LIN 总线连接在一起，现代汽车里的 ECU 总数已经迅速增加到了几十个甚至上百个之多，整个系统复杂度越来越大，几近上限。在今天软件定义汽车和汽车智能化、网联化的发展趋势下，这种基于 ECU 的分布式 EEA 也日益暴露诸多问题和挑战。 图 2-1 汽车分布式 EEA 为了解决分布式 EEA 的这些问题，人们开始逐渐把很多功能相似、分离的 ECU 功能集成整合到一个比 ECU 性能更强的处理器硬件平台上，这就是汽车“域控制器（ Domain Control Unit ， DCU ）”。域控制器的出现是汽车 EE 架构从 ECU 分布式 EE 架构演进到域集中式 EE 架构（如图 2-2 所示）的一个重要标志。 域控制器是汽车每一个功能域的核心，它主要由域主控处理器、操作系统和应用软件及算法等三部分组成。平台化、高集成度、高性能和良好的兼容性是域控制器的主要核心设计思想。依托高性能的域主控处理器、丰富的硬件接口资源以及强大的软件功能特性，域控制器能将原本需要很多颗 ECU 实现的核心功能集成到进来，极大提高系统功能集成度，再加上数据交互的标准化接口，因此能极大降低这部分的开发和制造成本。 对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如 BOSCH 划分为 5 个域：动力域（ Power Train ）、底盘域（ Chassis ）、车身域（ Body/Comfort ）、座舱域（ Cockpit/Infotainment ）、自动驾驶域（ ADAS ）。这也就是最经典的五域集中式 EEA ，如下图 2-2 所示。也有的厂家则在五域集中式架构基础上进一步融合，把原本的动力域、底盘域和车身域融合为整车控制域，从而形成了三域集中式 EEA ，也即：车控域控制器（ VDC ， Vehicle Domain Controller ）、智能驾驶域控制器（ ADC ， ADAS\AD Domain Controller ）、智能座舱域控制器（ CDC ， Cockpit Domain Controller ）。大众的 MEB 平台以及华为的 CC 架构都属于这种三域集中式 EEA 。 图 2-2 域集中式 EE 架构 域控制器市场概述 2018 年，基于德尔福提供的域控制器技术，奥地利 TTTech 公司开发的 zFAS 控制器率先应用在奥迪 A8 当中。伟世通公司则推出了 SmartCore 域控制器，集成信息娱乐、仪表板、信息显示、 HUD 、 ADAS 等功能。这些产品开创了商用功能域控制器产品之先河，全球各大 Tier 1 供应商纷纷跟进，整个域控制器市场逐渐发展起来。 在国内市场，华为、德赛西威、航盛电子、东软等企业也推出了 DCU 解决方案，并得到了国内车企的采用。比如， 2020 年小鹏汽车推出的智能轿跑 P7 就采用了德赛西威基于英伟达 Xavier 打造的自动驾驶域控制器产品—— IPU03 。 当前，整个业界对 DCU 市场都有非常乐观的预期。据佐思产研的预测， 2025 年全球汽车 DCU （座舱 + 自动驾驶）出货量将超过 1400 万套， 2019-2025 期间年平均增长高达 50.7% 。 图 2-3 全球域控制器市场预测 整个汽车行业普遍认为，域控制器是汽车电子行业未来竞争门槛最高的部分，因此利润也最高，芯片厂商和核心算法供应商将会受益。 ( 一 ) 域控制器市场快速增长背后的驱动因素 更多更好的 ADAS 功能和智能座舱与信息娱乐功能一直是推动域控制器市场快速增长的主要因素，这些新功能能明显提高整车的科技感和用户体验，因此也是主机厂开发新车型时的投入重点。 L1 到 L2+ 级别之间的 ADAS 应用是这几年发展非常快，很多功能都正在快速普及，比如：停车辅助、车道偏离预警、自适应巡航、碰撞避免、盲点侦测、驾驶员疲劳探测等。 域控制器需要一颗性能更强、集成度越高的主控处理器来作为其大脑，更多原本通过分离 ECU 实现的功能现在可以放到域主控处理器上来实现，也因此就能更加节省功能域里所需的 ECU 用量和其它硬件资源。更高的集成度可以更主机厂供应链管理实现 ADAS 域控和相关零部件平台化和标准化的要求。 ( 二 ) 对域控制器供应链的影响 汽车 E/E 架构的演进和发展，也深刻影响了主机厂和汽车电子供应商的供应关系。主机厂的核心竞争力从以前的机械制造为主，全面转向软件和算法为重点。预计未来整车厂与 Tier 1 供应商之间将可能有两种合作模式： 其一， Tier 1 负责域控制器硬件设计和生产，以及中间层 Middleware 软件部分。整车厂负责自动驾驶软件部分。 Tier 1 的优势在于以合理的成本将产品生产出来并且加速产品落地，因此整车厂和 Tier 1 进行合作生产方式是必然，前者负责自动驾驶软件部分，后者负责硬件生产、中间层以及芯片方案整合。这种模式下，在项目立项时，整车厂又可能跨过 Tier 1 直接与芯片厂商确定方案的芯片选型。 其二， Tier 1 自己与芯片商合作，做方案整合后研发中央域控制器并向整车厂销售，例如大陆 ADCU 、采埃孚 ProAI 、麦格纳 MAX4 等。 2.1 智能座舱域控制器 座舱智能化的实质是基于汽车驾驶舱中的人机交互场景，将驾驶信息与娱乐信息两个模块进行集成，为用户提供高效的、直观的、充满未来科技感的驾驶体验。智能座舱的设计诉求主要是用于提升用户的驾乘体验，同时还要保证用户驾乘的安全性和舒适性，最终实现汽车作为人们工作和家庭场景以外的第三生活空间这一终极目标。 智能座舱域包括 HUD 、仪表盘（ Cockpit ）和车载娱乐信息系统（ In-Vehicle Infotainment ，简称 IVI ）三个最主要的组成部分。 HUD 是非常实用的功能，将 ADAS 和部分导航功能投射到挡风玻璃上，诸如 ACC 、行人识别、 LDW 、路线提示、路口转弯提示、变道提示、剩余电量、可行驶里程等。 HUD 将很快会演变为 AR HUD ，在 L3 和 L4 时代成为标配。 进入 L3 时代，驾驶员状态监测（ Driver Status Monitor ， DMS ）将成为必备的功能，包括：面部识别、眼球追踪、眨眼次数跟踪等将引入机器视觉和深度学习算法。而 L4 时代则必备 V2X （ Vehicle to everything ）。 另外，多模态交互技术的蓬勃发展将会极大改变用户与汽车的交互模式。基于语音识别功能的语音交互技术越来越普及，常用于跟 IVI 系统的交互操作。进一步还能通过语音来对驾驶员进行情绪状态分析。当 DMS 系统检测到驾驶员昏昏欲睡时，系统可以通过播放音乐或者释放香味来唤醒驾驶员；基于多场景下的汽车座舱多模态交互技术未来一定会重新定义人机交互技术的发展。 所有这些智能座舱新技术的发展，都将推动对座舱域计算资源需求的暴增。 智能座舱域控制器领域，全球 Tier 1 厂商主要包括：博世、大陆汽车、哈曼、伟世通和 Aptiv （安波福）等。中国本土企业主要有德赛西威、航盛和东软睿驰等。 表 2-1 全球主要座舱域控制器厂商信息 2.2 ADAS 域控制器 ADAS 域控制器通常需要连接多个摄像头、毫米波雷达、激光雷达等传感器设备，要具备多传感器融合、定位、路径规划、决策控制、无线通讯、高速通讯的能力，要完成包含图像识别、传感器数据处理等诸多功能，因此要完成大量运算，域控制器一般都要匹配一个核心运算力强的处理器，能够提供自动驾驶不同级别算力的支持，目前业内有 NVIDIA 、华为、瑞萨、 NXP 、 TI 、 Mobileye 、赛灵思、地平线等多个方案。 自动驾驶技术目前是全球科技行业最前沿的方向。 L1 到 L2+ 级别的辅助驾驶技术和功能已经日趋成熟，搭载 ADAS 功能和应用的很多车型开始进入大规模量产。可以遇见 L1/L2 级别 ADAS 功能的市场渗透率将快速提升，而 L3/L4 级别自动驾驶系统仍处于小规模原型测试阶段。 当今的自动驾驶行业，中国市场绝对是主力。今年中国 L2 的搭载量预计突破 80 万，中国品牌占据绝大部分份额。未来中国市场 ADAS 功能的渗透率还将持续快速提高，中低端汽车所配置的 ADAS 功能将逐步增多。根据艾瑞咨询研究报告显示，预计 2025 年 ADAS 功能在乘用车市场可以达到 65% 左右的渗透率。 L3 级别的高速自动领航 HWP 功能和 L4 级别的 AVP 自动泊车功能，目前车型渗透率较低，未来提升空间较大。 图 2-4 中国 ADAS 功能市场渗透率预测 ADAS 域控制器正在从过去的分布式系统架构演变到域集中式架构。过去一套 ADAS 系统，要有好几个独立的 ECU 才能实现，比如车道偏移和交通识别 ECU 、前向碰撞预警 ECU 、泊车辅助 ECU 等。现在有了功能强大的集中式 ADAS 域控制器后，一个域控制器就实现了所有功能。系统的软硬件复杂度大大降低，可靠性也得到了提高。 目前业内提供 ADAS 域控芯片平台的有 NVIDIA 、华为、瑞萨、 NXP 、 TI 、 Mobileye ，以及国内本土的地平线和黑芝麻等多个方案。下表 2-2 总结了全球主要 ADAS 域控制器厂商及其客户和伙伴信息。 表 2-2 全球主要 ADAS 域控制器厂商信息 域控制器发展趋势 域控制器的兴起对传统的汽车 MCU 厂商造成了极大的挑战，“因为 MCU 使用量将大大减少，传统的 MCU 产品其演进路线将不复存在”。 在分布式 ECU 时代，计算和控制的核心是 MCU 芯片，传输的基础核心是基于传统的 CAN 、 LIN 和 FlexRay 等低速总线。但在域控制器时代，高性能、高集成度的异构 SoC 芯片作为域的主控处理器，将成为域控制器的计算与控制的核心芯片。而汽车 TSN （ Time-Sensitive Network ）以太网因为具有高带宽、实时和可靠的数据通信能力等特点，必将成为整车通信的核心基础设施，尤其是域主控处理器之间的通信主干网。 下面我们来简单分析一下域控制器以及核心的主控处理器的一些关键技术和趋势。 3.1 高性能 总的来说，对算力的需求提升一直是域控制器核心芯片发展的主要推动力。一方面原本由多个 ECU 完成的功能，现在需要依靠单一的域主控处理器来完成，并且还需要管理和控制所连接的各种传感器与执行器等。比如：底盘、动力传动系统和车身舒适电子系统的域主控处理器，其算力需求大约在 10000DMIPS-15000DMIPS 左右。 图 2-5 汽车域控制器对 CPU DMIPS 算力的需求预测 新的智能汽车，除了要更多的与人交互外，更需要大量的对环境进行感知，这就需要计算和处理海量的非结构化数据，因此座舱域和自动驾驶域都要求高性能的 CPU ，比如就座舱仪表的 CPU 算力而言，它其实跟一部高端智能手机的 CPU 算力差不多，约为 50000DMIPS 左右。此外，为了支持 L2 辅助驾驶功能或者更高级别的自动驾驶功能，需要运行很多视觉 DNN 模型算法，这就又额外需要上百 TOPS 的 AI 算力。 所以，各芯片厂商总是会尽量使用更先进的制程工艺、更先进的 CPU 核于与 NPU 核来尽量提高域主控芯片的 CPU 核心性能与 NPU 性能。 3.2 高异构性 伴随着 AI 技术在视觉领域的应用，基于视觉的自动驾驶方案逐渐兴起，这就需要在 CPU 的基础上加装擅长视觉算法的 GPU 芯片，从而形成“ CPU+GPU ”的解决方案。不过，“ CPU+GPU ”组合也并非最优解决方案，因为 GPU 虽然具备较强的计算能力，但成本高、功耗大，由此又逐步引入了 FPGA 和 ASIC 芯片。 总体来看，单一类型的微处理器，无论是 CPU 、 GPU 、 FPGA 还是 ASIC ，都无法满足更高阶的自动驾驶需求，域控制器中的主控芯片会走向集成“ CPU+xPU ”的异构式 SoC （ xPU 包括 GPU/FPGA/ASIC 等），从而能较好的支撑各种场景的硬件加速需求。 3.3 高集成度 从功能层面上，域控制器会整合集成越来越多的功能。比如动力系统域可能把发动机的控制、电机控制、 BMS 、车载充电机的控制组合在一起。有些主机厂甚至直接一步到位，将底盘、动力传动以及车身三大功能域直接整合成一个“整车控制域（ Vehicle Domain Controller ， VDC ）”。 要支持这些功能的整合，作为域控制器的大脑，域主控处理器 SoC 就需要集成尽可能多的接口类型，比如： USB 、 Ethernet 、 I2C 、 SPI 、 CAN 、 LIN 以及 FlexRay 等等，从而能连接和管理各种各样的 ECU 、传感器和执行器。 3.4 硬件虚拟化 对硬件虚拟化技术的需要主要来自两方面：（ 1 ）硬件资源的分区与隔离；（ 2 ）支持混合安全等级。 原本需要多个 ECU 实现的多个功能都整合到域控制器上后，势必会导致域控制器的软件更为复杂，这势必会导致整个软件系统的出错概率增加、可靠性下降。而且多个应用混合运行在同一个操作系统上，经常会出现故障传播（ Failure Propagation ），也就是一个应用出现问题后，会使得整个系统底层软件和硬件都处于紊乱状态，从而导致其它原本正常的应用也会开始出现故障。因此通过硬件虚拟化技术对硬件资源进行分区（ Partition ），使得各个功能对应的软硬件之间互相隔离（ Isolation ），以此保证整个系统的可靠性。 另一方面，在汽车电子系统中，通常不同的应用其对实时性要求和功能安全等级要求都不同。例如，根据 ISO 26262 标准，汽车仪表系统与娱乐信息系统属于不同的安全等级，具有不同的处理优先级。汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，要求运行在底层实时操作系统上（比如 QNX ）。而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，以 Linux 和 Android 为主。为了实现混合安全等级的应用，实现不同的操作系统运行在同一个系统上，这就需要虚拟化技术的支持。 车载硬件虚拟化技术的核心是 Hypervisor ，它是一种运行在物理服务器和操作系统之间的中间层软件，可以允许多个不同虚机上的操作系统和应用共享一套基础物理硬件。当系统启动时，首先运行 Hypervisor ，由它来负责给每一台虚拟机分配适量的内存、 CPU 、网络、存储以及其它硬件资源等等（也就是对硬件资源进行分区），最后加载并启动所有虚拟机的客户操作系统。 一句话总结一下基于 Hypervisor 的优点：它提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制 , 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。 3.5 ISO 26262 功能安全 功能安全是汽车研发流程中非常关键的要素之一。随着系统复杂性的提高，来自系统失效和随机硬件失效的风险日益增加。 ISO 26262 标准制定的目的就是更好的规范和标准化汽车全生命周期中的功能安全管理和要求，包括：概念阶段、系统研发、硬件研发、软件研发、生产和操作过程、售后等环节，尤其重点在产品设计阶段如何定义和实现功能安全的目标。 载汽车功能安全标准 ISO26262-5 2018 “产品开发：硬件层面附录 D ”中对处理器单元的诊断覆盖率推荐的安全技术措施中，双核锁步 (dual-core lockstep) 、非对称冗余和编码计算是三种典型的硬件冗余技术措施。除此之外，硬件 BIST 、软硬件 Self-Test 技术、 ECC 等也是常见的提高处理器安全特性的设计措施。 图 2-6 ISO26262 标准中的功能安全芯片设计技术 双核锁步 CPU 是一种 CPU 冗余技术，在一个芯片中包含两个相同的处理器，一个作为 master core ，一个作为 slave core ，它们执行相同的代码并严格同步， master 可以访问系统内存并输出指令，而 slave 不断执行在总线上的指令（即由主处理器获取的指令）。 slave 产生的输出，包括地址位和数据位，发送到比较逻辑模块，由 master 和 slave 总线接口的比较器电路组成，检查它们之间的数据、地址和控制线的一致性。检测到任何总线的值不一致时，就会发现其中一个 CPU 上存在故障，但不会确定是哪个 CPU 故障。 这种 CPU 架构使得 CPU 自检独立于应用软件，不需要执行专门的指令集自检，实际运行的软件指令在每个时钟都进行比较，只需要测试软件用到的 CPU 资源，但这种架构不会对内存和总线进行检测，需要增加单独的检测方法以避免两个 CPU 的共模故障。 3.7 网络卸载引擎 汽车网络会存在多种通信总线。骨干网未来势必会基于 TSN 以太网来构建，但是从域主控处理器到 ECU 或者传感器之间的通信则仍然是基于传统的车载低速总线，比如： CAN 、 FlexRay 等。域主控处理器作为域控制器的核心，是所有 ECU 和传感器通信的汇聚中心。因此如果要依靠 CPU 的算力来完成不同总线间的协议转换，以及跨域通信的网络包处理的话，势必会占用宝贵的 CPU 算力资源。 因此基于硬件来实现网络协议转换处理的网络卸载引擎，对于各个域（包括中央网关）的域主控处理器是非常重要的技术。 3.7 Security 引擎 连接性（ Connectivity ）是汽车智能化发展的一个很重要的趋势，未来的汽车一定会像今天的手机一样随时保持连接到互联网中。因此如何阻止未经授权的网络访问，以保护汽车免于受到黑客的攻击，对未来的智能汽车而言就会变得极为重要。下一代硬件安全模块（ Hardware Security Module ， HSM ）正在成为下一代车载网络通信的重要基础设施之一。 HSM 对于完全的安全车载通信（ Secure Onboard Communication ， SecOC ）是必不可少的。 HSM 能确保所接收到的数据的真实性，防止攻击者绕过相关的安全接口，入侵车载网络。 基于硬件的安全模块主要解决两个问题： 密钥泄漏问题：如果密钥存储在应用程序的代码或数据中，很容易被泄漏。所以有必要增加一个硬件模块，专门存储密钥。 Crypto 算法加速：通过内核来直接进行加密或解密运算会占用大量 CPU 算力资源。因此，有必要通过硬件模块来进行加密解密算法的加速。 SHE （ Secure Hardware Extension ）标准是由奥迪和宝马公司合作制定的、针对硬件安全模块 HSM 的规范，它主要包括密码模块的硬件、硬件软件接口。这个规范已被广泛接受，很多针对汽车行业的微处理器都支持这个规范。 3.8 面向服务的软件架构 SOA ECU 原先运行的软件大多数是按照 Classic AutoSAR 规范开发的软件系统，其中的应用软件一般都是静态调度（ Static Scheduling ）模式的，也即在系统运行时，程序中不同功能的函数按照事先定义好的排序文件依次调用、逐个运行。静态调度的优点是资源分配问题都是事先安排好的，车辆量产后就不会再改变，每个功能对应的函数代码具体运行时间也被提前锁定，是确定性的。因此这种设计对于汽车上很多对功能安全要求苛刻的场景是非常适合的。比如：决定安全气囊是否打开的功能函数就是固定地每隔几毫秒运行一次，以便紧急情况下可以及时打开。 承载计算和控制的底层硬件从分散的多个 ECU 集中到多核、异构的高性能域主控处理器后，相应的软件也会从分散向集中、从简单向复杂、从静态向动态进化。下图 2-7 显示了以后汽车域控制器上的典型软件架构： 图 2-7 域控制器上基于空分虚拟化技术的典型软件架构 操作系统层：最底层利用 Hypervisor 虚拟化技术对硬件资源进行分区 (partition) ，从而可以在每个虚机运行不同的操作系统。比如在上图中，虚机 VM1 中运行兼容 POSIX 实时操作系统标准（比如 PSE 52 ）的 RTOS ， RTOS 上通常要承载功能安全相关的应用和服务；虚机 VM2 中运行 Linux 这种完全 POSIX 标准的分时操作系统，上面通常运行管理相关的功能和服务；虚机 VM3 中运行的可能是原来在 ECU 上运行的 Legacy 应用。 中间件层：操作系统是不做任何与 “车”特定相关工作的。为了让域主控处理器在汽车场景下使用，需要有很多软件或者中间件用于让域控制器满足汽车的电源管理标准、网络管理标准以及诊断标准等；车载域控制器需要比一般工业嵌入式系统有更高的可靠性要求，这样就需要在计算机 OS 基础上再附加对存储和通讯等各方面的安全保护和容错机制；同时，位了让车载域控制器能够在整车 EE 架构下运行，还需要提供时钟同步、日志跟踪以及服务管理和发现等功能。 Adaptive AutoSAR 规范定义了运行在 Linux 或者完全兼容 POSIX 1003.1 标准 RTOS 上的这一层与“车”相关的中间件标准；而传统运行在 POSIX 子集的 RTOS 或者 BareMetal 模式的中间件规范则由 Classic AutoSAR 标准定义。 应用层：上层应用基于 AutoSAR 标准的中间件来进行开发。随着汽车智能化和网联化相关的功能越来多，上层应用软件也越来越复杂。位了降低单个应用的整体复杂性，我们可以借鉴互联网的面向服务架构（ SOA ）的软件设计思想，将一个复杂应用拆分多个服务。每个服务实现得尽可能小，尽量实现成无状态方式的服务，以利于整个系统的开发、测试和软件重用。服务与服务之间通过事件或者消息总线（发布 / 订阅工作模式）来进行通信，并降低互相之间的耦合度。通过服务配置来管理服务之间的依赖性、服务的部署和启动，以及服务的健康状态检测等。 汽车以太网给车载系统通信带来一个革命性的变化，在中央计算式汽车 EE 架构下，整个车载系统可以被看作是一个分布式网络系统：中央计算平台是一个小型服务器集群，区域计算平台是边缘计算节点。在互联网或者大型分布式系统中， SOA 架构设计理念已经被广泛使用了。因此当 IP 网络技术被广泛应用于汽车后，很多在互联网或者分布式计算中已经很成熟的软件技术，自然会被借鉴到新的汽车软件架构设计中来，比如： RPC 技术、事件 / 消息总线、 RESTful API 设计等。 大型互联网数据中心中的服务器集群动辄几百、上千台服务器，每秒百万、千万级别的并发。车载系统尽管可以被看作是一个分布式网络系统，但是它却没有互联网大型服务器系统的高并发特征，相反，它更注重通信的实时性和可靠性。 车载系统在物理上是向集中式发展的，也就是原来通过多个分散 ECU 来实现的功能，渐渐集中到几个主要的高性能域控制器上。因此，尽管在软件设计上，我们会尽量按照 SOA 的思路拆分成一个一个小的服务，但是这些服务在部署上其实是集中式的。鉴于这种物理部署上的“集中”与运行时的“分布式”并存的特点，因此我们可以通过一系列技术手段来优化服务与服务之间的通信延迟（比如：通过共享内存技术）。这是车载分布式系统与互联网强调高并发特性的分布式系统之间另一个显著的差别。 小结 域集中式 EE 架构会是未来相当长一段时间占主要地位的汽车 EE 架构，域控制器作为域集中式 EE 架构的核心，会在整个汽车产业链中占据越来越重要的地位。其相应的芯片和硬件方案、操作系统和算法等将会成为整个产业链各上下游厂家的争夺焦点。 关注公众号“优特美尔商城”，获取更多电子元器件知识、电路讲解、型号资料、电子资讯，欢迎留言讨论。

产业概述 行泊一体域控制器主要包含计算芯片、底层操作系统；在此基础上增加操作系统、功能软件便形成行泊一体解决方案。 行泊一体化三大阶段：硬件集成→硬件复用（初阶）→软硬件复用（高阶），硬件复用已经可实现降本效果，且技术难度低，是当前的主流应用，也是未来经济型车型的首选；软硬件复用可有效提升车辆行泊性能并可进一步降低成本。 驱动因素：①高阶行泊一体方案需要更优秀的算法、更大的算力处理大量的感知数据并布控更复杂的决策控制逻辑，大算力芯片量产、算法的增长有效支持高阶行泊一体技术落地；②硬件复用是行泊一体化的基础，软件算法复用是升华，其中多传感器融合技术必不可少；③高阶软硬件复用行泊一体化技术，需要软硬件分层解耦，中间件技术成熟化与标准化可提供有力支持；④目前部分车型已经实现行泊一体量产应用，其所积累的行车、泊车数据经过AI驱动的数据闭环技术，可快速高效训练新的算法。 行泊一体化是EE架构发展的必然产物，舱驾融合、中央集中架构是必然趋势，更高程度的集中化可在软件方面融合舱驾领域所有应用数据，更易实现SOA目标。 市场应用及趋势 2023年1-2月行泊一体域控制器累计配套量13.5万套，总渗透率5.4%；预计2025年行泊一体域控制器渗透率将达到30%以上，市场规模可达550亿元。 根据2023年1-2月行泊一体域控制产品应用情况，主机厂自研自用产品合计占比约60%，已成为主流。其中特斯拉、蔚来头部新势力主机厂已经实现软硬件全栈自研，传统主机厂长城、吉利已经在芯片、软件算法、整体域控制器产品进行了全面布局。 德赛西威、经纬恒润等国内传统供应商产品采用国际一线芯片品牌，以其自身丰富的整体域控制器集成制造经验加持，受到自研软件算法的主机厂的青睐，市占率约30%。 国内初创公司产品多选用小算力经济型芯片，且可提供软硬件一体解决方案，比较适合尚无自研成果且追求经济效益的主机厂。 L4自动驾驶解决方案公司开始降维布局L2/L3市场，推出多款软硬集成行泊一体解决方案，多数计划在2023年内实现量。 因主机厂担心失去主动权且议价空间小，较少采纳科技巨头公司的解决方案；外企因对国内市场响应较慢且价格偏高，也应用甚少。 典型供应商产品介绍 德赛西威IPU系列行泊一体域控制器产品累计出货量约14万件，在第三方供应商中销量居第一，量产车型有于小鹏P系列、理想L系列、飞凡R7、高合HIPHI Z。 知行科技的行泊一体域控制器已经累计交付超10万套，其中与Mobileye 合作开发的SuperVision已量产于极氪001、009；IDC MID定点奇瑞星途揽月、东风风行M6，将于年内交付；可支持城市NOA的IDC HIGH将于2024年实现量产。 福瑞泰克行泊一体域控制器ADC20搭载于吉利博越、领克09上，ADC30 定位于 L3 级别中央计算平台，将于2024年量产。福瑞泰克基于自有行泊一体域控制研发的解决方案，软件方面使用软件中间件、应用标准算法接口实现软硬件解耦、上层应用与系统软件解耦，为主机厂提供良好的差异化开发空间与自由度。 大疆车载主打高性价比产品，自研行泊一体域控制器并推出相应解决方案，整套软硬件产品总成本可控制在15000元内。 百度Apollo行泊一体域控制器有四喜、三鲜两个版本，但目前已经量产于威马W6的四喜仅应用了泊车功能，未来有可能使用百度的行泊一体方案。 华为基于其自研的昇腾系列芯片发布了MDC系列行泊一体域控制器产品，其中MDC610已经量产于哪吒S，MDC810量产于极狐阿尔法S、广汽埃安AION LX。 行泊一体域控制器核心硬件为计算芯片，计算芯片集成底层操作系统组成行泊一体域控制器；在此基础上增加操作系统、功能软件便形成行泊一体解决方案。行泊一体化大约分为三个阶段：仅将两套硬件集成但不复用→硬件复用（初阶）→软硬件高度复用（高阶），硬件复用已经可实现降本效果，且技术难度低，是当前的主流应用；软硬件复用的高阶行泊一体技术可高度复用车辆感知传感器的同时搭载解耦后的软件系统，实现软硬件可移植复用、更好的支持OTA，大幅降低工作量，节约成本。 智能化领域的多方技术发展，均在无形中支持着行泊一体化：①高阶行泊一体技术方案需要更优秀的算法、更大的算力处理大量的感知数据并布控更复杂的决策控制逻辑，随着大算力芯片的域控制器量产交付，同时也支持着行泊一体落地；②多传感器融合技术在不断发展，从传统的目标级融合，逐渐过渡到特征级和原始数据级融合，同时也将融入更多的传感器、地图、V2X 等智慧交通信息，为行泊一体复用硬件、软件算法提供有力支撑；③成熟且标准的的中间件技术帮助行泊一体域控制器软硬件解耦，方便进行个性化的上层应用软件开发和迭代升级，并缩短开发周期，提升开发效率；④AI驱动数据闭环技术可代替人工进行数据采集、分析、标注、模型训练、验证等步骤的绝大部分工作，提升基于数据的算法模拟训练效率。 随着中央集中式E/E架构的发展，行泊一体化是必然产物，舱驾融合、中央集中架构是必然趋势，两种高度集中的E/E架构均可在软件方面融合舱驾领域所有应用数据，更实现SOA目标并可进一步降低成本。 在市场应用方面，2023年1-2月行泊一体域控制器累计配套量13.5万套，总渗透率5.4%，再结合EE架构的域融合发展、大算力芯片的上车规划、传感器融合的应用等多方面技术的推进，我们预计2025年行泊一体域控制器渗透率将达到30%以上，行泊一体软硬件整体市场规模可达550亿元。 从行泊一体域控制器供应商来看，主机厂自研自用产品合计占比约60%，已成为主流。其中以特斯拉、蔚来头部新势力主机厂为主，且已经实现软硬件全栈自研，传统主机厂长城、吉利已经在芯片、软件算法、整体域控制器产品进行了全面布局。 德赛西威、经纬恒润等国内传统供应商产品采用国际一线芯片品牌，以其自身丰富的整体域控制器集成制造经验加持，受到自研软件算法的主机厂的青睐，市占率约30%。国内初创公司产品多选用小算力经济型芯片，且可提供软硬件一体解决方案，比较适合尚无自研成果且追求经济效益的主机厂。另外有L4自动驾驶解决方案公司开始降维布局L2/L3市场，推出多款软硬集成行泊一体解决方案，多数计划在2023年内实现量。因主机厂担心失去主动权且议价空间小，较少采纳科技巨头公司的解决方案；外企因对国内市场响应较慢且价格偏高，也应用甚少。 典型行泊一体域控制器及解决方案： 德赛西威2019年开始研发泊车域控制产品，2020年升级到行泊一体域控制器，目前其行泊一体IPU系列产品累计出货量约14万件，在第三方供应商中排名第一。量产车型有小鹏P系列、理想L系列、飞凡R7、高合HIPHI Z等。 知行科技的行泊一体域控制器已经累计交付超10万套，获得吉利极氪、奇瑞星途、东风风行、上通五菱、长城、极星等14家主机厂的定点，其中与Mobileye 合作开发的SuperVision已量产于极氪001、009。福瑞泰克ADC20定位于L2+的软硬件一体可迭代可演进的行泊一体域控制器产品，已搭载于吉利博越、领克09。新产品ADC30定位于L3级中央计算平台，可提供L3-L4的智能驾驶功能，将于2024年量产。另外还基于自有域控制器研发了解决方案，采用软硬解耦、系统与应用解耦的设计，为主机厂提供良好的差异化开发空间与自由度。 大疆车载主打高性价比产品，其自研行泊一体域控制器并推出相应解决方案，整套软硬件产品总成本可控制在15000元内，定位经济型市场。 百度Apollo行泊一体域控制器拥有四喜、三鲜两个版本，但目前已经量产于威马W6的四喜仅应用了泊车功能，未来有可能使用百度的行泊一体方案。同时其点对点领航方案ANP 2.0使用采用百度自有的域控制器四喜。华为行泊一体域控制器MDC系列中MDC610已经量产于哪吒S，MDC810量产于极狐阿尔法S、广汽埃安AION LX。

背景 车型 /ECU 开发周期缩短、功能复杂度的提高对测试提出更 高的要求 ，尤其为适应下一代架构发展而出现的 ECU 新形态“域控制器“，针对其测试 ，无论 从 测试经验 、知识能力 ，还是 测试实现方法 都提出了 更大的挑战 ： 挑战一： 功能 /服务 集成度更高 从 单一 功能点的 维度 开展测试，其测试深度无法保证，必须考虑各种功能应用场景的 有效 耦合， 这就需要具备 系统 整车 级 和用户角度 的功能测试实践经验 ； 同时介于域控制器的 潜在多核 多系统共存的 特点 ，还需 从任务分布实现的角度考虑和设计对应的测试场景。 挑战二： 功能安全等级 要求更高 单向 /正向的基于需求 的 测试用例 开发 ，其覆盖度有限 ，无法满足功能安全对测试的要求 （具体参见 ISO26262 中定义） ， 需要更多的采用 测试设计 理论方法 予以 支撑 测试实现 。 如何应对？ 对于一 ， 更需要经验积累和新知识能力储备 对于二， 可通过选择合适的工具 ，这是本文的重点 补充一点，面向服务和传统基于信号的功能实现，对于搭建 测试 仿真环境也提出了新的要求，后续针对此 做专题 讨论。 vTEST studio 简介 测试自动化广为接受，自动化测试的 H i L 硬件是载体，自动化测试设计软件为 其 落地的关键，要高效好用（图形化）、便于积累复用（模块 化 和抽象分离），具有高覆盖度（支持 不同类型的测试设计方法 ）。市面上，可以实现自动化测试设计的软件不少，各有特点，适合的才是最好的。 vTEST studio 是V ECTOR 公司推出 的 一款 图形化 测试 设计 开发环境， 核心的特点如下： 支持多种 测试设计 语言编写测试用例 包括 Test Table Editor 、 Test Sequence Diagram Editor 、 State Diagram Editor 、 CAPL Editor&C# Editor ， 应用了多种测试理论设计方法 以提高测试 的 覆盖度 。 变体 和参数化 概念 平台化设计理念的引入， 用例主体和参数抽象分离，用例更容易通过更新参数集适配 不同的变体 ，达到用例的积累复用 。 需求追踪 支持与REQM/TDM 的结合应用， vTESTstudio 可将 REQM/TDM导出标准xml格式的需求 矩阵 与测试用例建立映射关系，并将映射关系体现在测试报告中，如图 1所示。 图 1 REQM/TDM-system、vTEST studio 与CAN oe 结合应用 图片来源：vTEST studio 4.0 help文档 vTESTstudio.chm vTEST studio 对于 测试理论的应用 vTEST studio 作为一款设计开发工具，其融合了经典的测试设计技术方法以及新颖的测试设计技术方法， 并且引入变体的概念，对于平台化设计的应用具备重要作用。 以下简单介绍vTESTstudio应用的其中几种测试设计方法 以及变体 的 应用 （可从v TE ST studio demo 获取） 。 流程分析法 的应用 -路径覆盖设计 图2 路径覆盖法设计用例 正交试验设计法 的应用 -分类树设计 图3 分类树 状态迁移法 的应用 -状态机设计 图4 状态机设计 平台 的 概念-变体 的应用 vTE ST studio中可以根据变体类型 配置 不同 的 测试用例，对于平台化设计及 后续 测试范围选择的应用具备重要作用， 变体的类型具体 如不同地域/法规、不同配置/车型/平台、不同覆盖度 等 ，在CAN oe 中选择目标变体 并运行 ， 即可 测试 相应变体 适用的 用例。 图5 变体属性 添加 图6 变体属性的分配 图 7 CAN oe 中 根据 变体选择 后适用的用例 vTEST studio 用例 设计 开发及 案例验证 前面已经提到 几种 vTESTstudio 应用测试理论设计用例的方法， 现介绍 vTESTstudio在验证测试阶段 的具体应用示例 ， 摘选 自 北汇 为 某客户 开发的 第一代车身域控制器 （D CU ） 部分功能 点 的自动化测试序列 及验证 。 C ase 1： 针对雨刮间歇模式功能 点 的测试 设计 验证 Step1：分类树 图创建 图 8 前雨刮间歇功能的因子因素 分类树图 Step2： 图表编辑器（T est Table Editor ） 中 设计 带参数 接口 的标准 测试用例 库 图 9 图表编辑器中编写标准用例库 Step3： 图表编辑器 中调用设计好的 标准测试 用例 ，并将通过分类树 已 创建的参数插入到用例的参数接口中，如下图 图 10 插入参数后的用例 Step4：CANoe中加载 vTESTstudio中编译后的文件并执行测试 图 1 1 CAN oe 中加载 vTESTstudio中编译后的 雨刮 间隙 自动化测试序列 Step5：测试报告 图 1 2 雨刮间歇功能报告概览 C ase 2：针对 制动灯 功 能的测试验证 Step1： 图形化编辑器( Test Sequence Diagram Editor) 中设计 测试用例 并编译 图 1 3 vTESTstudio 图形化编辑器设计测试用例 Step2：CANoe中加载 vTEST studio 中编译后的文件 并 执行 测试 图 1 4 CAN oe 中加载 vTESTstudio中编译后 的制动灯 测试 序列 Step3：测试报告 图 1 5 制动灯功能 报告概览 Case 3 ：针对防盗系统不同状态跳转功能的测试验证 Step1：状态机图形编辑器( State Diagram Editor) 中设计测试用例 图1 6 状态机用例设计 Step2：CANoe中加载并执行 图1 7 C ANoe中加载vTESTstudio编译后 的防盗状态测试序列 Step3：测试报告 图 1 8 Disarmed&Remind状态 切换 报告概览 自动化测试 应如何高效 应用 所谓 “ 尽 信 书不如无书 ” ，盲目追求自动化测试则会背离测试的本质， 自动化测试仅仅是手段，利用手段而不是依赖手段。 自动化测试实现的目的 是 高效 快速 的完成测试的验证。 时间、成本和效益是企业 发展 永恒的主题，那到底应该如何高效应用自动化测试来提高投资回报率？ 具体哪 种 情况适合自动化测试呢？ 笔者 结合众多测试开发人员的经验及个人实践综合认为 ， 适合自动化测试项目 的 特点： 1. 重复性强 2. 测试频率高 3. 平台化型 产品（ 需求变动不频繁 ） 4. 增量式开发、持续性集成开发 5. 回归测试 6. 耦合复杂 ，具有时间特性要求的功能 关于如何高效应用自动化测试，各位看官可以踊跃发言哦。 总结 vTEST studio 具备需求覆盖度高、设计简单易懂、易于维护以及复用性高等优点，得益于 图形化及软硬件抽象 分 离特点 ，对 开发 人员的基础编程能力要求不高。 北汇 信息可提供 基于VT S ystem I /O 板卡 、 vTESTstudio 与CAN oe 组成了完整的H i L 测试平台，已为多家OEM /Tier 1 定制 部件级功能 测试 系统 （ 包括 车身域控制器，及传统分布式控制器 功能测试 开发 ） ，提供系统级及实车级测试验证服务 ，期待交流 分享和 合作的机会 。 工欲善其事，必先利其器。工具是效率的保障，选择适合的工具是很重要的一步，“进阶之路“需要人的经验积累、迭代，不断复盘和总结。与君共勉！ 参考文献： 【1】 vTEST studio_Factsheet_EN . pdf 【 2 】 vTESTstudio_ConceptManual_EN.pdf 【 3 】 Vector_Model-based E/E System Development with PREEvision .pdf 【 4】https://www.vector.com/int/en/products/products-a-z/software/vteststudio/#c22759 附： vTE ST studio 支持的主流REQM /TDM 一览： 【1】 Vector PREEvision TDM ，如图 19 所示 为vector提供的测试数据管理系统 vTESTcenter 概览 。 【2】 IBM Rational DOORS (from version 8.1) 【3】 IBM Rational DOORS NG, IBM Rational Quality Manager (from version 6.0.0) 【4】 PTC Integrity (from version 10.2) 【5】 Siemens Polarion ALM (from version 2016) 图 19 vTESTcenter Overview 图片来源： Vector_Model-based E/E System Development with PREEvision . pdf

前言 传统的汽车ECU通过诊断刷写来实现软件更新，数据量较小，一般在几十KB到几十MB；随着汽车的新四化进程持续推进，汽车上的域控制器或中央计算器的架构已经演变为MPU/SOC+MCU的方案，而针对MPU/SOC软件升级的数据量往往是几百MB甚至几GB，使用DoIP加诊断服务（0x34、0x36）来传输升级包数据，过程比较繁琐，并且带宽利用率较低。通过DoIP发送36服务，需等待传输层的应答即TCP ACK，再等待DoIP的0x8002报文（简化版不使用0x8002），最后必须等待控制器的诊断肯定响应才能继续发送数据。因此，针对数据量较大的升级包，各厂商纷纷采用多种新的方法来实现域控制器软件升级。 上海北汇信息根据既有的经验，为大家介绍其中一种抛弃了传统方案，一种新型软件升级技术及测试方案，该方案基于“一种支持SOA的协议 + 传统IT的传输协议”组合实现。以下简称“SOA协议”和“IT协议”。 域控制器升级流程简介 图 1 升级流程示意图 如上图所示，实现从节点域控升级，是由主节点来发起升级任务，此流程主要在车内进行。主节点首先通过“SOA协议”给从节点建立升级任务，再将升级包通过”IT协议”发送给从节点，同时通过”SOA协议”控制升级流程；相比使用诊断服务实现升级，此流程简洁高效，能快速实现升级软件的目的。 测试用例的构成 针对从节点的升级测试，主要分为以下几个部分： 1.正向流程测试；2.状态跳转测试；3.故障码测试；4.场景测试 图2 部分测试用例 域控制器升级测试的主要环境 北汇主要使用Vector的CANoe+VN56xx来开发测试用例与执行测试，加上基本外设，如程控电源等，可以快速搭建好测试环境，示意图如下所示： 图3 测试环境示意图 在测试脚本中，使用CANoe仿真主节点，主要实现的是”SOA协议”与”IT协议”两个模块功能；1.仿真CANoe作为主节点，发送”SOA协议”请求给DUT，来控制升级流程；2.仿真CANoe作为”IT协议” Server，收到DUT的”IT协议”请求后，将升级包通过”IT协议”发送给DUT。 图4 测试脚本框图 域控制器升级测试实例 数据传输过程 CANoe仿真主节点给从节点建立升级任务后，从节点便发送”IT协议” 请求升级包路径，仿真主节点响应升级包路径，从节点则发送”IT协议” 获取升级包。仿真主节点使用”IT协议”发送升级包，在传输过程中可以使用SOA协议周期读取传输进度，等待传输完成后，仿真主节点发送安装请求，在安装过程中周期读取安装进度。以下是测试报告和测试数据的示例。 图5 建立任务与传输过程测试报告 图6 安装升级包测试报告 总结 本文介绍实现域控制器升级的一种新兴技术方案，其在汽车电子领域已广为接受并采用。此方案相比使用诊断服务实现升级，主要有以下两个优点： 1. 升级流程简洁高效 2. 传输升级包效率更高 北汇信息紧跟技术发展的脉搏，在此领域已经积累了测试规范开发、测试脚本开发、测试执行的经验，同时根据北汇在汽车电子丰富的测试经验，开发具有深度的用例覆盖不同场景，为客户的汽车电子产品软件升级质量保驾护航，加快车型研发进度！