实现自动驾驶软件系统的功能安全ASIL合规性

实现自动驾驶软件系统的功能安全ASIL合规性

自动驾驶汽车的安全性是其能否普及的关键因素。本文从传感器冗余、硬件和软件架构、免干扰（FFI）以及运行时监控四个方面，深入探讨了实现自动驾驶汽车功能安全的技术方案，为理解自动驾驶汽车的安全性提供了全面的视角。

随着汽车在道路上自动驾驶，功能安全变得至关重要，以避免对车内和道路上的人员造成危害。ISO 26262根据缺陷的严重程度和对人身造成伤害的概率，将汽车安全完整性等级(ASIL)定义为QM（最低）至ASIL-D（最高）。本文从四个方面探讨了自动驾驶汽车软件系统的功能安全要求和解决方案。第一个方面涵盖了不同级别的冗余使用，以确保一个系统的失效不会影响汽车的整体运行。它探讨了通过多个传感器和不同的数据处理来使用冗余，以获得功能安全的结果。基于冗余要求，在第二个方面，提出了一种可以帮助满足这些要求的硬件（SoC）和软件架构。它探讨了软件框架的定义、任务调度和工具使用，以确保在开发阶段防止系统故障。自动驾驶系统将非常复杂，期望所有软件模块都符合最高功能安全级别可能不可行。第三个方面探讨了通过防火墙、MMU等硬件和软件机制实现免干扰(FFI)的使用，以允许安全和非安全子系统共存并按照其规范运行。最后一个方面涵盖了使用软件和硬件诊断来监控、检测和纠正硬件模块在运行时发现的随机故障。它探讨了使用ECC、CRC和BIST等诊断功能来帮助检测和避免运行时失效。

通过多传感器融合实现系统冗余

为了让汽车自主行驶，首先它必须感知外部环境/周围环境；处理数据并做出有意义的决策。在这个意义上，处理和行动链中，外部环境的感知部分由摄像头、雷达、激光雷达等传感器负责，在本文的其余部分中称为环绕传感器。除了环绕传感器外，其他传感器（如车辆里程计传感器和执行器）对于将信息提供给决策模块也很重要。例如，方向盘角度和车轮速度是汽车做出正确决策的重要数据以及周围环境信息。因此，我们将传感器大致分为以下三类

• 环绕传感器：这些传感器安装在汽车的外部/内部表面上，可用于提供周围环境信息。例如：摄像头、雷达、激光雷达、超声波、红外摄像头、IMU、GPS和数字地图等。

• 车辆里程计传感器：这些传感器捕获有关车辆运动的信息。例如：车轮速度、加速度、偏航率、方向盘角度等。

• 执行器：这些是转换人机动作的传感器。例如：制动扭矩、发动机扭矩、约束执行器、车轮弹簧等。

在本文中，我们将更多地讨论环视传感器以及多传感器融合对自动驾驶汽车的重要性。汽车制造商一直在使用不同的传感器，主要是激光雷达、雷达、摄像头和超声波，用于ACC（自适应巡航）、LKA（车道保持辅助）、盲点检测、前方碰撞警告等安全功能，最近还用于AEB（自动紧急制动）等主动安全功能。最近，业界已经看到更多传感器/信息的使用，如卫星信息、车辆和基础设施（V2V和V2x）和激光雷达，以提高这些安全功能的稳健性。这些传感器提供的信息有很大的重叠。同时，它们的可靠性程度各不相同。例如，雷达和摄像头都可以识别物体的距离，但雷达传感器的信息可靠性高于摄像头。自动驾驶系统需要提供最高程度的可靠性，并且需要来自不同传感器的信息良好重叠才能做出自信的决策。

表1列出了这些传感器的优缺点以及它们对自动驾驶至关重要的不同ADAS功能的适用性，对这些传感器进行了很好的比较。在传感器缺乏的领域，方括号[ ]中提到了替代传感器名称。例如，视觉传感器不适合速度检测，而雷达/激光雷达可以提供帮助。

表1.不同环绕传感器的优缺点

从该表中可以明显看出，没有一个传感器可以处理所有情况。因此，对于自动驾驶系统，传感器融合是必须的。该领域的大多数现有工作都强调了这一事实。DARPA的首次城市自动驾驶汽车演示有18个传感器（9个激光雷达、5个雷达、2个视觉和2个GPS/IMU），它们为车辆路径规划提供了冗余信息。Puthon, A.S.等人强调了视觉和GPS传感器融合对速度标志识别的重要性。冗余信息可以提高测量精度，此外，整个系统的容错能力也会提高，因为一个传感器的失效并不一定导致整个系统失效。

考虑这样一种情况，ACC检测到与前方车辆的距离太小。此时，ACC决定降低速度。但是，如果驾驶员打算超车，则此决定无效。事实上，减速的决定会增加追尾碰撞的可能性。因此，这种情况需要使用多个传感器来更全面地了解环境。

图1以图形方式展示了多个传感器如何帮助覆盖不同的视野和自动驾驶的基本功能。

图1.环绕传感器、覆盖范围和应用

下图2描述了多传感器融合架构。从安全角度来看，高级融合架构似乎更实用，因为它可以避免单点失效，并且随着越来越多的新传感器添加到现有系统，它变得更加可行。

图2.融合系统的不同架构

无论传感器融合架构如何，多个传感器具有冗余度的重要性仍然很高，以便从融合算法中做出更好的决策。

硬件和软件架构

基于图2，不同的硬件架构是可能的。低级融合，图2(a)，意味着基于更集中的硬件处理的系统。图2(b)、图2(c)，意味着基于分布式硬件处理的系统。

从安全角度来看，图3和图4中所示的融合SoC代表单点失效，并且融合SoC的冗余度对于功能安全是必需的。对于集中式硬件架构，融合SoC中完成的处理量将很大，并且在这种情况下，融合SoC的冗余度将非常昂贵。在分布式硬件架构中，处理分布在多个SoC上，因此融合SoC上的处理要求将适中，因此实现冗余度将相对便宜。

图3：集中式硬件架构

图4：分布式硬件架构

无论是使用集中式还是分布式硬件架构，SoC内的处理或计算元素通常都是异构的。这种异构处理元素SoC的一个例子是图5所示的TDA2x SoC。它包括

• 以750MHz运行的双核ARM® Cortex®-A15

• 最多两个以212MHz运行的双核ARM® Cortex®-M4子系统

• 两个最新一代固定/浮动C66x DSP内核，运行频率高达750MHz

• 最多四个用于矢量处理的嵌入式视觉引擎(EVE)内核。

图5：TDA2x SoC框图

它还集成了用于摄像头捕捉和显示子系统的硬件，从而以更低的功耗实现更好的视频质量。TDA2x SoC还包括TI的IVA-HD技术，该技术可实现全高清视频编码和解码，以及能够以500 MHz的速度渲染170 Mpoly/s的双SGX544 3D图形核心。它包含大型片上RAM、用于连接的丰富输入/输出(I/O)外设以及汽车市场的安全机制，并提供更低的系统成本。

从SW架构的角度来看，可能存在两种数据流。图6显示了集中式SW数据处理。在这里，“主”CPU将工作提交给相同或不同CPU上的工作“线程”。这种方法的特点包括对主CPU上数据流的更精细控制、更动态的数据流、主CPU上更复杂的SW逻辑。这种SW架构适用于融合类处理，其中通常不遵循固定的数据流，并且CPU之间的交互可能因给定时刻的不同传感器输入和结果而不同。

图6：集中式SW数据处理

图7显示了分布式SW数据处理。在这里，不同CPU上的不同线程直接相互通信以形成数据流。这种方法的特点是，给定核心的SW开销较低、延迟减少、SW设计简化、数据流相对静态或固定。这适用于单个传感器处理数据流，其中步骤顺序通常是给定传感器模态所熟知的（图4）。下面的HWA指的是SoC上的硬件加速器或类似模块。

图7：分布式SW数据处理

在自动驾驶中，SW架构将涉及集中式和分布式数据流。在本文中，我们建议使用OpenVX框架来实现系统级SW数据流。OpenVX提供了基于图形的数据流定义。分布式SW数据流可以表示为具有多个节点的图形。节点通过数据对象相互连接。可以通过让主CPU将工作作为单节点图提交给“工作”CPU来实现集中式数据流。

此外，OpenVX允许用户通过隐藏较低级别的SoC细节在更高的抽象级别上操作，这将允许SW扩展到不同的SoC类型和系统配置。从安全角度来看，软件架构需要满足其他要求。从安全角度来看，静态可预测系统是理想的，例如，没有动态资源分配，可预测的控制流。在OpenVX中，可以在系统初始化期间预先指定数据流图和所需资源。任何系统级参数验证、调度选择都可以在图形验证阶段完成。这允许针对给定的SoC进行优化。同时，它使资源分配在给定的SoC上静态化，执行可预测。OpenVX的未来规范将支持图形“导入”、“导出”功能，这将允许此验证步骤离线完成，而不是在最终系统的系统初始化期间完成。单元级SW测试和验证是实现安全SW系统的一个重要方面。可以围绕OpenVX的图形API开发测试工具，以便在单元级测试OpenVX节点，然后再将它们集成到系统级。可以使用SW/HW循环机制来确保数据处理节点的正确性。

不受干扰

汽车软件需要符合ISO 26262“道路车辆 - 功能安全”标准。该标准提供了识别和评估系统中的安全隐患以及建立、管理和跟踪安全要求，以将风险降低到可接受水平的流程。ISO 26262定义了汽车安全完整性等级(ASIL) - 一种风险分类系统。它定义了四个ASIL - ASIL A到ASIL D - 按安全要求的递增顺序排列。它还为安全要求不高的模块提供了一个称为QM（质量管理）的分类级别。在当代解决方案中，单个ECU负责各种操作。系统中共存着多种软件模块（其中少数是安全关键模块）。大多数模块将被归类为QM。这种共存是安全关键系统中的主要风险。一个简单的解决方案是让所有软件都符合系统所需的最高安全标准。然而，由于复杂性非常高且开发成本高昂，这并不切实际。为了解决这个问题，ISO 26262允许具有混合关键性的系统，只要它确保不同软件模块之间的“免干扰(FFI)”，以便一个模块中的错误不会传播到其他模块。ISO-26262要求系统解决三种类型的干扰：

• 内存使用

• 时间和执行顺序

• 信息交换

解决时间和执行顺序干扰的典型解决方案涉及使用任务监视器和看门狗定时器。信息交换干扰通常在软件中处理，方法是使用消息传递中的冗余并使用校验和等功能来确保通信通道的完整性。然而，确保内存使用不受干扰的问题在异构多核SoC上没有简单的解决方案。市场上可用的解决方案主要依赖于MMU和CPU模式，并且不解决系统中不同内核之间的干扰。在本节中，我们将使用图5中显示的TDAx作为案例研究，展示如何实现FFI。

考虑一个由QM和ASIL任务混合组成的系统。这些任务可以存在于一个或多个内核上。它们共享公共内存。内存空间可以分为两个区域 - QM和ASIL。ASIL任务通常对所有内存具有读写权限。QM任务将仅对QM内存具有写入权限。QM任务将对ASIL内存具有只读权限。因此，通过提供定义只读和读写内存部分组合的方法，可以解决跨任务防止干扰的问题。

图8：典型的TDAx SoC

图9：TDAx中FFI的硬件模块摘要

图10：用于FFI的CPU和硬件模块

TDAx平台提供三类硬件模块来控制内存访问：

• MMU（内存管理单元）和XMC（扩展内存控制器），用于从CPU子系统访问外部内存

• MPU（内存保护单元），用于CPU子系统内的内部内存访问

•防火墙将内存访问限制为指定的启动器列表。

MMU和MPU

Cortex A15和Cortex A8提供专为高级操作系统(HLOS)设计的强大MMU。通过提供定义只读内存部分的能力，这为FFI提供了直接的解决方案。它还提供了一项称为地址空间标识符(ASID)的功能，允许不同的任务使用不同的内存映射，从而实现无缝任务切换。

DSP MPU可以为基于内部内存的CPU模式（用户与管理员）提供QM和ASIL任务之间的隔离。DSP XMC为外部内存访问提供相同的保护机制。

M4子系统可以使用CPU模式（用户与管理员）结合MMU和防火墙来启用FFI。

防火墙

防火墙是在异构多核系统上支持FFI的关键手段。它们能够根据主标识限制对内存区域的访问。这是SoC中可能不使用MMU的非计算硬件单元（如DMA、视频捕获和以太网）的常见用例。

EVE内核不通过CPU模式（用户与管理员）提供任务标识。因此，使用防火墙在EVE内核上启用FFI。

运行时应用程序监控

ISO 26262功能安全标准定义了试图避免或降低安全系统故障风险的要求。随着SW复杂程度的增加，该标准强调在整个产品生命周期内（包括现场部署）对应用程序SW组件进行测试和验证。已经提出了多种技术来在开发过程中捕获系统性SW故障。但是，如果没有一种机制来监控和报告应用程序的状态，即使应用程序崩溃或出现故障，也不可能保证系统万无一失。

在本节中，我们将介绍一种使用异构多核复杂SoC的自动驾驶应用程序的SW框架，旨在提供：

• 集中式应用程序SW监控框架。

• 一种故障安全机制，用于将来自不同CPU的监控结果传达到中央监视器。

• 通过扩展CPU特定库的范围来综合查看整个系统工作负载和数据带宽，这些库提供特定于给定处理核心的本地信息。

• 支持多个不同的监视器，以提高对SW和硬件故障检测的信心。

• 来自多个CPU和HWA的应用程序状态，如处理时间、延迟、处理/丢失的帧数、CPU低功耗时间等。

图11：监控不同系统统计数据的框架支持和流程

多处理器ADAS SoC的集中监控

为了描述集中监控方案，我们考虑一个多处理器片上系统(MPSoC)，它由充当应用程序主控的主处理器、通用处理器(GPP)和信号处理(SP)核心以及相关的视觉/雷达/计算加速器组成。图11突出显示了用于监控系统和CPU级别统计数据、关键组件、在多个CPU上执行的不同监控任务和功能之间的数据和控制流的整体SW基础架构。测量包括线程级别统计数据、CPU工作负载百分比、内存和堆状态、DRAM带宽、CPU利用率和低功耗时间、硬件错误（如CRC、ECC失效）。

在主处理器上创建集中统计监控任务(MCentral)。在CPUx上本地运行的单个统计监控探测器Mxi已向MCentral注册。根据所进行的测量类型，Mxi根据应用程序定义的采样间隔（例如CPU工作量、带宽测量）或事件发生（例如堆分配/取消分配、收到新帧）更新其本地缓冲区中的数据。为了限制本地监控任务和MCentral之间传输的数据量，各个Mxi通过执行平均值、最大值、方差等统计操作对捕获的数据进行预处理。根据应用程序定义的记录间隔，从不同的Mxi源收集数据，并在主机处理器MCentral任务上进行整理，以通过CAN将数据转发到控制台输出记录器或MCU端的诊断框架进行进一步分析。

监控结果的故障安全通信

由于对自主应用程序施加了实时限制，通常使用硬件辅助的最低延迟中断的处理器间通信(IPC)建立CPU间通信。应用程序崩溃和挂起通常会导致此低延迟通信通道停止服务，无法发送状态信息进行失效分析。我们建议使用非锁定共享内存区域队列在不同的监控任务之间传输命令和数据。

这种方法的优点是，即使应用程序运行缓慢或死机，监控任务之间的通信（检测和报告错误）仍保持活动状态。通信的非锁定特性确保MCentral在尝试从崩溃或挂起的CPU上运行的监控器中提取数据时不会挂起。基于共享内存区域的IPC还可确保最小的CPU开销。共享内存的分配方式应使其不与应用程序数据内存共享相同的互连访问路径。例如，开发人员可以将监控IPC共享内存放在内部SRAM中，而应用程序使用DRAM。这样，即使在发生灾难性的硬件互连挂起的情况下，也可以将监控统计信息报告给MCU。

结论

自动驾驶汽车需要安全，才能让这项技术得到广泛接受。没有一种解决方案可以让自动驾驶汽车安全。多传感器融合和分布式硬件架构可以确保不会出现单点失效，从而避免对人类造成危害情况。使用OpenVX等框架的软件架构可以帮助在分布式硬件架构上实现多传感器融合。由于不可能让所有软件系统都符合最高ASIL级别，因此需要使用MMU、防火墙等硬件单元的抗干扰技术来实现混合ASIL系统。最后，需要部署实时硬件/软件监控和诊断，以确保系统按照规范运行。