自动驾驶系统设计的那些底层软件开发中的重点解读

众所周知，随着自动驾驶和智能网联技术的飞速发展，传统的汽车开放系统架构CP Autosar已经无法满足日益复杂的汽车电子系统的功能需求。尤其底层软件中，针对面向服务架构SOA开发需要使用高性能的处理器，自适应汽车开放系统架构AP Autosar有着不可比拟的优势。

而应用软件中，自动驾驶整体架构主要涉及感知、规划、决策、控制等节点。通过数据或信息的存储、传递及有效及时处理，可以完成感知算法、决策算法、控制算法的整体递进式集成。数据在采集单元与算法单元之间、每两个算法节点之间进行传递时，都需要经过“数据缓存”和“数据发布”两个步骤。这一过程就涉及多项自动驾驶底层软件技术，如内存动态分配、芯片运算能力、芯片实时监控策略。本文将针对这三方面内容进行详细说明。

1.功能安全拦路虎：内存分配与访问

在汽车电子系统的软件开发标准中，强调需要保证软件架构要素之间的独立性，相互之间不能存在干扰。而这类干扰软件要素的可能原因分为三部分：运算、内存、通信。其中，运算能力涉及运算时序和执行策略。这对开发符合功能安全要求的软件提出了具体的要求，而这一分析过程无论从难度系数还是工作量上都很大，而“内存分配”和“内存访问”是非常重要的一个原因。

1）内存分配

内存分配主要存在于自动驾驶底层软件领域。通常的做法是，数据发布单元向底层操作系统申请适当的内存，数据发布之后释放内存。在申请内存和释放内存的过程中，主要有如下三种内存分配方式存在：

如上图所示，“静态内存分配”和“堆上内存分配”两种方式中，其相关技术需要在分配内存空间时，都需要搜索连续且空闲的最小内存分配单元，导致存在时间开销大、内存碎片化严重等问题。这对于在灵活且受限的内存资源（SRAM、LDDR、FLash）中，将可能由于频繁的进行动态内存分配产生的内存碎片，可能影响自动驾驶系统运行性能。

从对于系统功能安全设计上讲这类内存分配所带来的影响将是不能被容忍的。所以在不同的自动驾驶底层软件系统中，对于当前先进的自动驾驶系统程序不管是应用程序，还是平台模块，都是直接调用可移植操作系统接口或编程语言c++的接口进行内存的动态申请/释放。然而，汽车电子系统的软件开发标准ISO26262要求尽可能不要动态申请/释放内存，甚至在某些高等级的自动驾驶安全等级，如ASIL D中考虑到动态申请/释放内存，频繁的动态申请/释放，会产生大量的内存碎片，不但会增加申请结果和时间的不确定性，甚至还会影响性能，通常又是禁止动态申请/释放内存的，实际上这两类需求却又是相互矛盾的。

因此，对于动态内存管理，需要开发许多不同种类的算法。不同的操作系统有不同的实现方式，为了程序的可移植性，一般在开发语言的库中都提供了统一接口。在系统真正需要内存时，才通过操作系统调用接口API来获取实际的物理内存。

此外，很多适配底软开发的供应商当前在进行自适应汽车开放系统架构设计中，还重点倾注更多精力用于内存保护和提高内存利用率。例如，设置可用内存池，在有需求时获取内存大小需求，从目标交换模块对应的内存集合中确定目标内存，在有需要时，申请合适大小的目标尺寸，通过以上方法，可以有效减小运行时的资源瓶颈，减少内存碎片化。

2）内存访问

随着汽车电子系统复杂性的不断提高、越来越多的软件和机电设备的应用，来自电子系统失效和随机硬件失效的风险日益增加。在功能安全中，相关失效分析是一项非常重要的工作。在ISO26262中要求，如果嵌入式软件包含不同ASIL等级的软件组件设计SWC，要么整个软件工程都需要基于最高安全等级的要求进行开发，这就需要保证拥有更高安全等级的SWC的操作不会受到其他SWC的干扰。

总结起来，SWC相关的内存故障主要包含如下几方面：

在基于面向服务的架构中需要基于更低安全等级要求开发的SWC，可能会出现错误地访问到更高安全等级SWC的内存区域，产生干扰。为此，SWC需要运行在不同的内存区域，或者不同的内存分区，来防止类似的内存访问违例。

由于每个可编程核心(总线主机)都有一个内存保护单元MPU（如果没有MPU，则可以通过DMA守卫来控制总线主设备的访问），它定义了软件访问保护措施，当MPU嵌入很多异构芯中时也同时具有内存保护功能，可以保护当前执行的代码不被一些“无关联”的数据所侵害，防止对内存数据的错误访问，并控制外围模块的寄存器。这类保护措施主要是限制相关内存地址权限，这类权限限制将确保其程序访问内存地址的范围与其无关，组织关键数据不被破坏，整个系统更加健壮、安全。

2.自动驾驶异构计算能力提升：

超异构计算芯片集成

高阶自动驾驶系统需要在AI单元的选型上采用了并行计算架构的AI芯片进行硬件加速、资源分配、调度、图像识别、深度学习等。使用多核车规级CPU配置进行任务调度、执行自动驾驶相关的大部分核心算法，同时整合多源数据完成路径规划、决策控制等逻辑运算处理。

AI芯片处理功能包含如下：

a)图像感知：对摄像头输出的数字图像进行包含ISP处理、编解码、视频图像分割、目标识别、跟踪处理等，同时，生成BEV鸟瞰图、视觉定位建图等；

b)激光点云处理：对激光雷达输出的点云进行聚类、目标识别、跟踪处理等；

c)融合处理：包括基于图像识别得前融合，图像、毫米波/激光雷达、高精定位目标后融合等；

d)轨迹规划：利用检测到的图像目标信息，规划自车行驶轨迹。

对于诸如如上各种功能的整体融合，当前的架构策略通常是采用多芯片融合技术进行相应的分片分模块处理。但是，从整体执行效率、执行效果、开发周期上看，这种多芯片异构方式都不见得是最佳选择。首先，为了集中达到对不同运算能力的需求，通常需要从不同芯片厂家拿货进行接口及软件适配，这将是一个比较长期且大量的开发工作。另外，各芯片适配过程中是否能够完全兼容也并非能够在开发初期能够完全解释清楚。因此，如果能够搭建一种“超异构计算芯片”融合包含xPU的所有功能子项，那将是智驾系统架构的福音。

这里我们将对这类新型芯片进行详细介绍。

“超异构处理器”，顾名思义可以认为是由CPU、GPU、各类DSA以及其他各类处理器引擎共同组成的，CPU、GPU和DPU整合重构的一种全系统功能融合的单芯片解决方案。

那么这类超异构处理器到底能对自动驾驶系统底层软件带来哪些好处呢？

首先，超异构处理器的融合策略有利于计算资源的充分整合，进一步提升数据计算效率。因为相比于需要三芯片实现异构计算的方案，这种超异构融合系统，将内部功能划分和交互统一构建，可以显著降低彼此功能和交互的各种掣肘。

其次，对于自动驾驶系统来说，其计算过程中的大部分场景（80%-90%）都是相对轻量级场景，通过超异构实现的单个芯片计算策略通过Chiplet加持以及多DIE单芯片的方式，实现重量级场景的覆盖，完全可以cover住几乎全部的通用场景。因此，在其复杂度和系统规模中均实现较好的反馈。

最后，超异构计算单元实际是一个整合多类芯片的大的芯片集合，同时在电路设计中最大程度的简化其外围边缘件设计，实际是最大程度的减少了BOM表的数量。因此，对于芯片成本可以得到大幅降低。

实际上，当前已有部分芯片供应商已经在这类芯片设计中，实现了类超异构芯片的设计能力。这家供应商就是TI的TDA4 系列芯片。

如下图所示表示了当前被各家自动驾驶玩家钟爱的TDA4 VM芯片，实际的内部架构可以看出，其设计上，已经将包含CPU（A72、R5F）、DPU（C7x）、GPU、主MCU等。这种杂糅式集成实际可看成简单的超异构芯片。里面既能实现高实时性运算的R核（外置接摄像头I/O连接模块，直接控制摄像头的开闭及数据实时传输），也有可提升运算量的A核（实现深度学习、卷及计算、MAC计算等大量感知端需要的运算能力）。最后还有为了满足功能安全要求，设置了双核MCU实现功能安全岛需要的锁步校验功能。这样一个高集成度低成本的芯片怎能不受各玩家的钟爱呢？

3.自动车辆有效执行的重中之重：实时性设计

在自动驾驶技术中，对功能模块的实时性要求非常高，尤其是自动驾驶算法的复杂性造成数据分发节点非常多，内存操作的时间开销更大，影响到在突发事件的场景下(例如，有行人突然闯入)自动驾驶系统对实时响应性的要求，很可能会影响自动驾驶系统的安全。

由于高阶自动驾驶系统一般都采用异构芯片进行不同数据信息源信息处理。需要严格限定硬件ECU在规定的时间内完成任务，否则就可能导致系统功能的失效。例如对于线控转向，如果驾驶员发出转向操作后100ms内车轮没有执行转向，则可能导致碰撞事故，严重的甚至造成车毁人亡。横纵向执行域的系统（ESP、EPS）往往属于这一领域。当然，如果硬件达标而软件执行期间出现一定的时间偏差，在设定的线性范围之内也是被允许的，例如有的应用要求系统在90%的情况下能够确保在规定时间内完成任务即可。车辆信息娱乐域（IVI）或动力域（VCU）的系统大多都属于这类系统。

那么这种实时性到底指的是哪块呢？这方面实时性又需要重点关注哪些要素呢？

总体而言，影响系统实时性的因素从软件架构上可以分为通信、调度和代码三个层面。从系统架构上，实时性实际又需要从整个传感端、控制端到执行端进行区分。

1、系统架构实时性解读

1）传感端：

对于集中式方案来说，传感端的实时性处理有两种情况需要区分。其一，如果传感器能够作为单独小的ECU，那么整个环境数据采集工作则可以认为是由传感自身自行控制和执行的。如摄像头曝光时间、雷达微波发生频率、激光扫描频率等。对于输入域控的数据而言，域控只需要给出传感器对应的同步时间戳即可。其二，如果传感器不存在单独控制的ECU端，那么整个传感采集过程都将受制于域控制器。这个过程可以看成域控制器需要通过一定的控制线（如摄像头的IIC线）对传感器的采集速率、采集频率、控制电压、采集输入时间点都要进行控制。那么整个实时性控制将完全交由域控来进行控制。

当前很多情况下，域控对传感数据的控制只是部分实时性控制。如只对摄像头数据采集的实时性进行直接控制，如控制曝光、传输速率等。而对于毫米波、激光雷达等则是分布式方式，其实时性控制只是简单地全局时间注入及打时间戳等方式。

另外，如果是域控底层驱动传感器I/O口的方式，还包括域控能够实时的将传感器原始数据进行实时性处理，如底层ISP/白平衡、中间层AI深度学习感知聚类、顶层与其他传感器数据的后融合等。

2）控制端：

对于控制端来讲，其实时性则是相对复杂些，他包括底层软件驱动的实时性，中间件资源整合调用的实时性以及顶层应用软件的实时性。实际应用中，不同系统对于实时性的满足程度并不相同。比如AEB这一对系统处理实时性要求极高的功能就需要系统能够在异常场景中能够将数据及时的采集到，并在内部进行有效处理。这一处理过程实际是要求系统是一种处理实时性极高的系统。

以实时性满足的不同需求可以分为实时性计算任务和实时性监控任务。实时性计算任务主要是指规定时间内完成的不同敏感性任务，如“硬实时系统”和“软实时系统”。实时监控任务则是针对运行的软硬实时系统实施包含运行效率、运行安全度、执行结果反馈等方面的信息监控。以AUTOSAR标准为例，CP通常用于硬实时系统中，而AP多用于对实时性要求较低、但又比用于车机的Android实时性要求高的系统。

总之，自动驾驶车内的各种系统对实时性有不同的要求。实时性是一个相对的概念，针对不同功能安全、信息安全，需要设计不同等级的实时运算和监控系统，以满足系统的功能要求，综合平衡系统升级的灵活性、成本等不同因素，设计满足需求的实时性系统。

3）执行端：

执行端的实时性很容易理解，即是域控发送的执行信息能够得到执行器的及时处理和反馈。这块在当前也是简单地通过对执行器的接口需求进行规范。比如纵向执行加速度会规范加速响应延迟、加速稳态时间、稳态波动最大最小值等。横向执行转向角会规范转角响应延迟、最大最小响应转角、最大最小手力矩等。

从整车功能域角度出发，自动驾驶是收集外部传感器数据量最大的模块，为了持续探测到车身四周各种复杂环境信息，需要毫米波、摄像头和激光雷达配合以达到360度无死角感知。并且为了保证安全，所有数据都需要接近实时的速度处理，为了保证大量数据的实时处理，较低的数据延迟需要由高性能的计算单元和高带宽的网络通信，数据可轻易在不同内核中共享。

2、软件架构实时性解读

这里主要是指运行于硬件SOC、MCU上的软件架构平台。从底之上主要包括底层驱动软件实时性（I/O代码驱动层面），涉及I/O函数层级、基本代码块、机器指令码、操作状态码等。中间层软件实时性（中间件调度）包括SOC层级、CPU层级、GPU层级、MCU层级的系统管理、算法接口、AI处理等。顶层通信层面则是针对环域控的整个车内外网络、云端服务等。

除开如上运算单元外，配置软件实时性监控、检测和删除错误的互连事务也是必不可少的环节。如总线监控器、内存访问结果监控、虚拟控制台实时性监测、系统CPU入侵检测等。

5.总结

本文对自动驾驶系统中的内存分配、多异构芯片、实时性进行全面较准确地分析，这将有助于大家更准确地理解车辆控制系统中的各项性能指标进行完整的解读，并能够对肯恩存在问题进行系统、全面的分析。其目的是使得开发出的智能驾驶产品功能更可靠，性能表现更优，真正降低交通事故的概率和产生的危害。

审核编辑 ：李倩