华玉通软：智能驾驶系统软件在量产中的挑战与实践

近年来，随着智能驾驶的兴起，传统的汽车电子开发模式已不再适用于智驾的系统开发场景，基于智能驾驶中间件的开发模式成为突破口。2023年9月21日，在2023第三届智能汽车域控制器与中央计算平台创新峰会上，华玉通软联合创始人兼CTO李坚表示，通过面向智能驾驶芯片以及上层软件需求开发的基础软件/中间件，可以让智能驾驶的系统开发成本得到极大的降低，同时缩短开发周期，提高软件的可靠性。

李坚 ｜华玉通软联合创始人兼CTO

以下为演讲内容整理：

在传统的汽车电子控制开发的模式中，使用基于AUTOSAR CP的中间件进行开发已经成为行业中主流的开发模式。随着智能驾驶的兴起，虽然其在应用的需求以及应用所使用的技术和传统的汽车电子控制是截然不同的两个领域，但它的系统规模更加复杂。因此在智能驾驶的场景中，基于基础软件或者基于中间件的开发模式仍然是非常必要的。通过基础软件，我们可以让智能驾驶的系统开发成本得到极大的降低，缩短开发周期，提高软件的可靠性。

面向智能驾驶的基础软件/中间件行业目前仍处于发展期，技术壁垒很高。不论是ADAS辅助智能驾驶的应用，还是高阶自动驾驶，系统软件都是整个软件体系架构的重要组成，高度关乎系统的可靠性和安全性。

图源：演讲嘉宾素材

正是基于此，华玉通软致力于面向智能驾驶的基础软件研发，目前已经推出了完整的面向智能驾驶的基础软件系列产品。在和多个主机厂、Tier1进行量产合作的过程中，我们也发现了基础软件在量产过程中出现的一系列挑战，并逐一进行了解决。下面将和大家分享我们遇到了怎样的问题，以及在华玉产品中的解决策略。

DDS量产案例

在量产过程中，从通信、执行管理到确定性调度以及工具链是我们在搭建智能驾驶系统时绕不开的话题。用开源的DDS或开源的ROS去搭建demo级别的自动驾驶软件平台所能达到的系统可靠性以及稳定性，与基于华玉基础软件去构建满足严苛量产需求的系统化软件架构所能实现的是截然不同的。

通信层面，例如在ARM A核上，量产过程中通常会遇到的问题是多个应用、算法带来的通信场景复杂、数据收发节点多、通信频次高，数据量非常大等挑战。用成本很高的大算力芯片去解决这些问题是目前常用的方式。但随着智能驾驶系统普及的需求越来越高，车企都希望能使用低成本的芯片构建自动驾驶系统，将CPU的性能尽可能充分利用，以将CPU用满为目标来做资源分配。那么如何在高系统负载下保证通信的低延迟抖动就成为了非常重要的问题。同时，在这样一个复杂的通信场景下，不同节点对于通信性能和通信场景的需求是不同的。华玉通信中间件可以通过非常简单的QoS配置，来满足客户复杂多变的通信场景需求。此外，SoC的资源非常丰富，有多种底层通信channel，如何根据不同应用需求（进程内/进程间/核间/芯片间/域间）选择效率最高的channel，也是华玉通信中间件能够帮客户解决的实际问题。在通信过程中，华玉通信中间件可以提供完整的通信诊断支持，帮助用户快速定位与通信相关的故障所在。

下面是我们在和某Tier1量产项目中的实际通信场景。在TDA4和J5之间，TDA4的A核和R核之间要做大量的数据交互。

图源：演讲嘉宾素材

TDA4的A核上要发布的topic数量为56个，要接收来自A核数据的节点的数量为105个，接收来自R核数据的节点为8个。通信的频次是为25赫兹、50赫兹、100赫兹。通信数据包的平均大小从30字节到3M字节不等，平均每秒要收发的数据包数量是6000个，每秒钟吞吐量为500M字节。这种复杂的场景如果不依赖通信中间件，要从底层直接实现一个车规级通信的框架是很困难的，并且需要消耗大量的人力、物力和时间成本。

在这个复杂通信场景下，我们使用华玉SWIFT DDS实现了数据互通。在J5及TDA4的A核/R核上都部署了SWIFT DDS，所有的通信都通过SWIFT DDS完成，并且可以根据应用的部署位置及需求来选择最优的通讯方式。

图源：演讲嘉宾素材

另一个案例是一个双Orin加双TC397的架构。在所有的芯片上同样是通过SWIFT DDS来打通所有的通信链路。这里面有一颗Orin还会运行一些车云的相关应用，可以用扩展的DDS协议，包括DDS-SECURITY、DDS-RPC和DDS-WEB，帮助客户方便快捷的直接打通车端和云端的连接并且满足车端和云端通信的特定需求。在这样的场景下，使用同一华玉的通信中间件就可以把车内通信、车间通信以及车云通信全部统一起来。

在这个案例中，为何客户选择了SWIFT DDS而不是其他方案？首先，SWIFT DDS可以实现对复杂场景的支持。通过其他方式也可以将通信场景搭建起来，但通信过程中，其他的搭建方式无法满足除通信本身之外的功能以及性能的需求。而SWIFT DDS则可以通过DDS的配置工具轻松实现复杂场景下的通信功能及性能需求。

其次，SWIFT DDS有多种高性能通信的支持。例如在TDA4 A核R核通信中，SWIFT DDS会自动切换底层channel使用效率更高的RPMessage进行通信。

第三是对于通信延迟抖动的控制。量产过程中，A核需要运行数十个甚至上百个进程，这些进程都有自己的周期。一旦通信发生抖动，这个抖动是不可控制的。比如用Some/IP，普通抖动的平均值可能是5毫秒，但如果它在一段时间内抖动的最大值能达到几百毫秒甚至秒的量级，对于时序要求非常严格的上层应用来说，是没有办法使用的。因此SWIFT DDS提供支持确定性调度的接口，针对前面所提到的抖动问题做了深度的优化。

最后是对于诊断和多种通信QoS的支持。SWIFT DDS针对智能驾驶汽车的场景或做了非常多的优化和改进，而其他几种方案是没有这些功能的。

图源：演讲嘉宾素材

量产过程中的执行和状态管理

SoC上运行了非常多的进程，这些进程之间有各自的依赖关系。大部分公司是按模块开发，最后将模块放在一起拼成一个系统。在这个过程中，程序以怎样的形式部署到硬件上？怎样开始运行和结束？这当中并没有统一的框架进行规定。

对于状态管理而言，在量产过程中必须要有一个统一的框架，比如相关的二进制文件。对于依赖库，对于运行的参数进行统一的管理和配置。同时，对于应用要进行统一的部署，进行OTA的升级等，也都必须在一个独立的统一框架下完成才能以最高的效率实现。

另外，我们的执行和状态管理要做到进程和资源的隔离，保证A核上运行的多个进程一旦有崩溃的，不会影响其他进程。

针对这些挑战，我们开发了“云雀”执行管理中间件，在量产过程中使用我们的中间件可以将应用程序的配置、开发、部署、运行，以及OTA统一到一个框架下来进行。

从应用程序的生命周期管理和状态管理而言，通过“云雀”执行管理中间件，可以和上层业务进行解耦。用户在只有system design（所有模块节点的框图以及节点之间数据流图），还没有实际的业务代码之前，就可以根据这些信息把程序生命周期管理和状态管理全部实现，而不依赖于实际的算法实现。而如果在应用里把这些功能实践出来，造成的结果就是状态管理、执行管理本身会和上层业务有严重的耦合，会非常难以调试，以及后续扩展困难。

对于部署和OTA来说，“云雀”执行管理中间件把程序的部署和OTA一并放到执行管理框架下，只要用同样一个框架就可以实现程序开发、部署、执行、OTA，所有相关的东西都在同一个框架下实现，高度保证其连续性和一致性。

图源：演讲嘉宾素材

我们在量产中面临的另一挑战是确定性执行。Linux的调度机制是尽最大的能力去做调度，但不会保证程序在确定的时间内执行完毕，而目前在A核上运行的很多智能驾驶算法是有明确的截止时间和周期要求的。一旦某个程序的执行时间不确定，就会造成整个系统状态陷入混乱。这个过程中整个系统不仅在节点上进行计算、处理业务逻辑，节点和节点之间还要做通信，通信本身也会带来不确定性。

有人提出用TSN解决这个问题，TSN解决的是硬件层面确定性的数据传输，但如果用户不愿意在数据链路层使用TSN做传输，而在传输层使用UDP做数据传输，从链路层到传输层的数据处理过程中，kernel会带来新的不确定性。因此，确定性的执行必须解决通信过程中数据从用户进程发送到用户进程接收的端到端确定性通信问题。针对这一挑战，我们对用户空间到内核空间数据全链路的收发流程做了细致的研究、分析以及优化，推出了华玉确定性版本的全链路通信。

通过华玉确定性执行模块，用户只需要把任务相关信息输入到确定性调度generator里，产生确定性调度的方案之后，再通过确定性调度的runtime，把确定性调度方案实现出来，就可以实现跨芯片的全局确定性调度。

图源：演讲嘉宾素材

量产过程中的工具链需求

对于传统的MCU或者AUTOSAR CP的开发，相应的中间件厂商都提供了一套完整的工具链。但我们在A核上开发智能驾驶应用的时候，相应的工具链是非常少的。在Linux上做开发一般都是通过API接口调用，需要一定量的程序开发工作把应用和底层的中间件使用glue code黏合到一起。另外，上层业务的数据流是抽象的算法层面的东西，如何把算法层面比如发送数据的类型映射到中间件数据类型上也需要一定的工作量。

通常开发过程中的V字模型全流程的闭环，包括分析，设计，开发，测试，部署和维护，V字型的流程对于现在汽车电子面向智能驾驶的系统软件是非常缺失的。

而针对V字模型开发中的每一个环节，华玉都有对应的工具来帮大家完成这些任务。比如我们的System Configurator和Code Generator针对用户可以使用配置的方式来实现它想要的DDS的通信场景。Monitor可以让用户在做DDS测试和调试时直接获取DDS实时通信状态。DDS-Recorder、DDS-Replayer可以让用户在实验室环境回放录制的DDS数据，方便用户进行通信调试。

Green Engine是华玉推出的自动化集成工具。通过Green Engine，用户仅需提供上层算法就可以完成整个智能驾驶应用的集成。Green Engine替代了用户手动去集成核心系统软件模块的工作。用户只需要提供系统节点之间的框图以及数据流的关系图和拟采用的算法，再使用Green Engine SDK进行处理，就可以生成能直接运行的、基于车规级中间件搭建的智能驾驶应用。这样一来，用户可以只专注于智能驾驶应用程序的业务本身，而底层的数据通信、计算调度、执行管理等均由Green Engine做综合和集成，从而实现智能驾驶系统的快速构建及部署。

图源：演讲嘉宾素材

中间件与SOA架构密不可分，目前SOA的底层基础架构功能基本全部通过中间件进行搭建。虽然SOA可以降低应用、节点之间的耦合，但是其中还带来了不小的开发集成工作。比如直接使用第三方的中间件会有较高的配置复杂度。一个量产项目中车企可能会用到多个中间件供应商，需要协调多个供应商进行沟通和对接，过程中会花费大量的时间/人力成本，导致最后的集成变得非常复杂且不可控。

使用华玉Green Engine进行开发集成，因为所有中间件都是华玉自研，并且可以涵盖用户上层应用的全部底层需求，所以用户只需要提供算法，就可以方便快捷地实现量产级别的智能驾驶软件系统。

（以上内容来自华玉通软联合创始人兼CTO李坚于2023年9月21日-22日在2023第三届智能汽车域控制器与中央计算平台创新峰会发表的《全场景车规芯片助力跨域融合》主题演讲。）