基于健康指标的自动驾驶全系统运行时安全分析方法

摘要

实现全自动驾驶汽车面临的一大问题是如何确保车辆安全以及所有交通参与者的安全。ISO 26262 和 ISO/PAS 21448 等标准从不同角度出发，通过定义安全措施和机制来解决这些问题。其中，ISO 26262 聚焦于电子电气（E/E）系统故障引发的安全隐患，而 ISO/PAS 21448 则强调由技术局限性导致的安全风险。然而，如何在运行时对全系统范围的安全性进行监测和验证，仍是一个尚未解决的难题。为补充这些安全规范，我们提出了一种全系统运行时安全分析方法。我们的系统健康管理理念基于所谓的健康指标（HIs），通过健康指标传递已检测到的错误信息，并触发相应的错误应对措施。我们分析了在自动驾驶环境下定义有意义健康指标的潜在信息来源，并研究了 ISO 26262 和 ISO/PAS 21448 这两项标准的影响因素。我们将该方法应用于一个案例研究，以证明其在自动驾驶场景中的适用性。

1、引言

为对不同自动化等级进行分类，国际自动机工程师学会（SAE International）发布了 J3016 标准，该标准定义了 “驾驶自动化等级”。目前，汽车实现了从 0 级到 2 级的自动化，这些等级的汽车具备驾驶员辅助功能。例如，2 级自动化功能可实现车辆自动加速和减速。但驾驶员必须始终保持监控，并在出现紧急情况时接管车辆，也就是说，驾驶员是车辆的安全备用状态。

从 2 级自动化向 3 级自动化过渡，会大幅增加系统复杂性。因为 3 级自动化车辆能在特定的运行设计域（ODDs）内自主运行，无需驾驶员监控。只有在收到通知后，驾驶员才需在规定时间内接管车辆。4 级自动化车辆能在运行设计域内完成所有驾驶任务；而 5 级自动化车辆的自动驾驶系统则可应对各种环境条件。

ISO 26262标准提供了实现功能安全所需的流程和机制，包括避免设计缺陷、提供错误检测与处理机制等。尽管如此，这些机制并不能自动解决功能不足的问题。为填补这一空白，ISO/PAS 21448 标准定义了 “预期功能安全性（SOTIF）” 这一术语，即不存在因预期行为的性能限制或用户合理误用而引发的不合理风险。

然而，这些安全标准仅能支持自动化等级 up to 2 级的车辆开发，因为仍存在许多未解决的问题，例如如何验证和确认功能安全性。随机硬件故障、软件设计缺陷等多种错误来源，也从侧面说明了设计 3 级自动化系统的难度之大。此外，安全因果链已成为全系统层面的属性，因为某一个元件的失效会影响系统其他部分。例如，传感器的局限性可能导致对环境的错误感知，进而引发危险的驾驶操作。这些安全违规行为必须在运行时被识别，以便触发相应的缓解措施。为解决这一问题，我们提出了一种全系统运行时安全监测方法。

本文结构如下：第 2 节详细阐述所提出的理念；第 3 节通过实例说明该理念在自动驾驶环境中的应用方式；第 4 节将我们的理念与相关研究进行对比；最后给出结论与展望。

2、提出的方法

引入健康指标的概念，旨在通过启用系统降级和服务质量（QoS）机制来提高系统安全性。系统级别的健康指标可实现全系统的恢复与降级。特别是自动驾驶系统，依赖冗余和多样性机制来提升系统安全性。因此，必须定义一种标准化的、非局部的、而是基于系统级别的降级方法。当发生故障时，该方法可实现向热备用实例的切换。

此外，服务质量的核心理念也被应用到安全领域。附加包含健康指标的服务质量值，可让服务接收方立即判断对所接收服务的信任程度，以及如何处理这些数据。当前的车辆架构整合了多种平台，如 AUTOSAR（汽车开放系统架构）和 Genivi（汽车级 Linux 开源项目），这些平台符合不同的安全和关键性等级。服务质量方法有助于协调跨单个平台和标准的安全机制。

2.1 元模型

我们引入系统健康管理理念，以实现全系统运行时安全分析。图 1 展示了所研究系统的元模型。该元模型的目标是形式化地表达用于运行时健康分析的车辆抽象层次和系统属性。通过该模型，可将车辆划分为不同的域，每个域对相互依赖的功能进行分组。

图1、所研究车辆的元模型

根据为 ISO 26262 和 ISO/PAS 21448 所做的安全分析，所有功能特征和域都必须具有明确定义的安全属性。这些安全属性可包括冗余和配置信息，用于分析有效的配置和可能的降级策略。在域级别，这些要求转化为一套功能降级规则集。根据可用的功能，该规则集允许系统在出现故障时，通过减少活跃功能的数量来继续运行（即平稳降级）。

为确定终止哪些功能，需为每个功能特征分配优先级。当发生失效时，功能可实施适配策略，通过性能降级来节省资源。功能特征由不同的子系统构成，子系统则由硬件、软件、冗余和能力属性定义。性能降级规则基于子系统的可用性和性能。

我们的理念将元模型的上述属性作为基础，为运行时健康指标定义约束条件和模型。因此，运行时监控器会在子系统、功能特征和域级别对这些属性进行检查。这些监控器是根据其底层系统定制的。例如，子系统的监控器负责监控关键的硬件和软件资源；域或功能特征的监控器则可能检查平台的降级和可用性属性。运行时健康指标应能支持运行时系统降级策略。第 3 节将定义健康模型的可能结构。

2.2 健康指标

在我们的理念中，健康指标被定义为性能（Per）、可靠性（Rel）和降级（Deg）的三元组，即 HI = (Per, Rel, Deg)。这三个参数分别对应不同安全标准所需的不同方面。

降级参数是一组特定于系统的降级级别，基于可用性要求确定。ISO 26262 标准要求具备监控功能，以评估电子电气系统在随机错误或系统错误方面的健康状态，这一标准相关的安全考量所涉及的健康状态由性能参数体现。可靠性参数用于评估因不确定性导致的系统可信任程度，因此，它涵盖了与预期功能安全性相关的安全考量，包括车辆与环境、用户及其他车辆的交互，以捕捉这些交互所带来的不确定性。

健康指标的主要目的是在运行时监控全系统的安全属性，从而触发相应的缓解措施。缓解安全违规可通过降低系统功能或性能来实现。我们提出的健康指标三元组对这两种降级策略均能提供支持：降级参数概述了用于功能降级的可用系统资源；功能特征或域的性能和可靠性参数则是触发性能降级策略的重要信息来源。

2.3 运行时系统健康管理

系统健康管理（SHM）的自适配策略通过 MAPE-K 循环实现。MAPE-K 循环涉及五项活动，分别是监控（Monitoring）环境和 / 或系统、分析（Analyzing）数据以发现差异、规划（Planning）可能的适配策略、基于建模知识（Knowledge）执行（Executing）适配操作。

图 2 展示了规划的 MAPE-K 适配架构。每个被管理的子系统都包含一个本地 MAPE-K 循环。子系统可以是单个软件平台、电子控制单元（ECUs）或传感器等。在分析阶段，本地会收集相关的健康信息，并将其共享给一个全局分析单元，即系统健康管理器（SHM）。

图2、适配机制结构

系统健康管理器接收来自一个或多个本地分析单元的信息，有时也接收来自其他系统健康管理器的信息。基于这些信息，确定子系统、功能特征或域级别的健康指标，然后再将这些健康指标共享给被管理的子系统。

为实现清晰的架构结构，该理念需遵循 “关注点分离” 原则。因此，适配逻辑和执行交由本地状态管理器负责，因为只有本地状态管理器掌握详细信息（如正在运行的进程）。系统健康管理器则专注于抽象的全局健康分析，并通过健康指标将这些分析信息提供给本地管理器。

要确保本地适配能使系统达到全局一致的状态，需要进行全面的系统分析，例如文献中所提出的分析方法。为实现安全的全局恢复，相互依赖的子系统可能需要交换当前状态。

需要注意的是，我们的理念作为一种独立解决方案，无法保证系统行为的安全性，它更多是通过让系统了解自身健康状态，为系统降级策略提供支持的一种措施。例如，单一的系统健康管理器可能成为故障点，进而违反安全要求。为解决这一问题，可部署两个冗余的全局系统健康管理器，其中第二个作为热备用实例，在第一个出现故障时接管其工作。因此，要符合安全要求，需结合针对具体问题定制的安全机制。

3、自动驾驶环境中的健康指标

3.1 用例

本节通过实例说明如何确定子系统级别的健康指标。图3展示了一个简化的自动驾驶域逻辑架构。该系统支持 3 级自动化功能（如 “高速公路领航”），能使车辆在有结构化分隔道路的高速公路上以最高 130 公里 / 小时的速度自主行驶。

当发生严重系统故障时，车辆有三种应对方式：一是以 60 公里 / 小时的降低速度继续行驶；二是要求驾驶员在规定时间内接管车辆；三是将车辆停靠在应急车道。为定义健康指标，需对所提出的电子电气系统架构进行分析，并将其划分为多个子系统。下文以正常集成平台作为计算健康指标的示例子系统。

图3、自动驾驶域的示例逻辑架构

正常集成系统负责轨迹计算。计算机视觉平台向主 ASIL 通道（PAC）和次 ASIL 通道（SAC）的电子控制单元提供信息。两个通道分别生成独立的环境模型。基于该环境模型，PAC 应用计算无碰撞的车辆轨迹；同时，SAC 也利用计算机视觉信息计算最小风险轨迹。之后，PAC 验证器和 SAC 验证器分别对两条轨迹进行碰撞检查。根据多项性能和安全要求，为每条轨迹分配一个分数。选择器根据这些分数选择最优轨迹。

3.2 自动驾驶系统的健康指标

降级参数代表基于硬件和软件资源的可用性及因果依赖关系的不同级别。PAC 和 SAC 具有不同的用途：PAC 需持续运行并计算轨迹，而 SAC 仅在 PAC 发生故障时接管工作，不用于持续运行。一旦 SAC 被激活，系统会启动驾驶员接管流程。这些差异应体现在不同的降级状态中，正常集成系统的降级状态定义如下：

对于性能参数的确定，我们提出一种基于软件监控结果的规则式方法。正常集成系统属于安全关键系统，需通过不同的软件监控器来监控传感器信息的及时到达情况，以及逻辑和截止时间约束的满足情况。对于存活监控（Alive Supervisions），可配置故障参考周期的容错率。例如，将所有监控结果汇总为一个监控状态，该状态可分为以下四种：

· 正常（OK）：无监控项故障。

· 故障（FAILED）：存活监控项故障，但错误计数器低于配置的容错率。

· 过期（EXPIRED）：截止时间或逻辑监控项故障，或错误计数器达到或超过配置的容错率。

· 停用（DEACTIVATED）：模式切换导致被监控实体停用。

这些监控状态可按照公式（2）映射为性能级别。“正常” 和 “停用” 状态表明应用性能良好，对应性能级别 0；传感器输入延迟可能会降低高速公路领航功能在行驶平稳性方面的整体性能，但不被视为安全风险，因此 “故障” 状态在这种情况下映射为中等性能级别 1；“过期” 状态表明存在严重错误甚至功能丢失，映射为较差性能级别 2。

在可靠性参数方面，正常集成系统是体现预期功能安全性所带来不确定性的典型例子。在计算机视觉和网格融合中使用机器学习算法会带来较大的不确定性，因为不熟悉的环境可能会被误判。两种机器学习算法的概率值可作为环境模型可靠性的指标。此外，两条轨迹的交叉验证结果可用于评估计算出的轨迹的可信任程度。

验证器对轨迹分数的一致性以及分数本身的数值，都会影响可靠性：验证器意见不一致会降低可靠性，意见一致则会提高可靠性。公式（1）涵盖了上述影响因素。

3.3 健康指标模型

下文将概述在子系统、功能特征和域级别确定健康指标的一般方法。对于降级和性能，规则式健康模型被证明是有效的。这类模型可包含已安装的、针对安全相关软件和硬件组件的监控机制所产生的监控结果，如软件监控结果或传感器测量数据。通过分析故障树，可纳入子系统可能存在的故障依赖关系。

可靠性所反映的不确定性无法归类为具体的状态，因此我们建议采用 0-100 的数值范围进行评估。这样，不同的影响因素可被赋予权重，并相互关联。总体而言，不确定性主要有两个来源：随机不确定性（aleatoric uncertainty）和认知不确定性（epistemic uncertainty）。认知不确定性涉及未知情况的不确定性，无法保证人工智能系统会做出安全反应；随机不确定性由传感器测量不准确导致，会使实际环境被错误呈现。

要捕捉随机不确定性，需获取当前环境状态以及不同传感器的能力和可用性；而要测量认知不确定性，则需使用并比较多样化且冗余的信息，如前文 PAC 和 SAC 的示例所示。因此，可对不同验证器和合理性检查器的结果进行加权，以衡量可靠性。

人为操作者也是一个不确定性因素。因此，驾驶员监控系统的结果可作为获取当前驾驶员状态的良好信息来源，并可纳入可靠性分析。

4、相关研究

工业界和学术界的大多数自适配策略都聚焦于应用级或组件级分析。下文将我们的理念与三种系统级解决方案进行对比。

在航空电子领域，文献提出了一种软件健康管理的两级方法。作者建议将组件级健康管理器与高级别的系统级健康管理器相结合。与我们的方法类似，组件级健康管理器负责监控子系统，并向系统级健康管理器报告异常；系统级健康管理器则对异常进行系统级分析，并执行缓解措施。

但与我们基于健康指标的运行时缓解策略不同，该研究通过全系统诊断确定根本原因，并选择相应的应对策略，然后将该策略告知组件级健康管理器，由其执行缓解措施。此外，该研究未像我们这样，将系统健康划分为子系统、功能特征和域等抽象级别。

在汽车领域，“SafeAdapt—— 全电动汽车安全适配软件” 项目提出了一种用于安全运行时重配置的分布式理念。所有核心节点会周期性地交换正在运行的应用程序的健康状态，并利用这些健康状态信息进行协调的全局适配。

我们则建议收集健康信息，在一个集中式实例中确定功能特征和域级别的健康指标。我们的系统健康管理器仅向执行适配操作的本地实例提供相关的健康指标。

弗图尼奇（Frtunikj）在文献中提出了一个分布式故障管理层，用于处理系统故障。每个本地节点收集健康信息，以确定多个系统功能的健康状态，并周期性地交换这些健康状态。结合健康状态以及子系统的冗余类型等附加信息，计算子系统的降级级别和系统功能的降级级别，系统重配置管理器再据此选择合适的适配方案。

该研究中提出的系统功能与我们理念中的功能特征类似，但我们进一步考虑了域级别的健康指标。此外，我们的健康指标不仅能指示当前的降级状态，还包含了性能和可靠性状态的信息。

5、结论与展望

为补充现有标准，我们建立了一种基于健康指标的通用系统健康管理理念，用于运行时安全分析。此外，健康指标还有助于解决自动驾驶汽车面临的其他未决难题。

要在不违背安全要求的前提下将自动驾驶付诸实践，需要完善的验证和确认方法。但如何生成能涵盖所有相关风险的测试场景和测试数据，仍是一个未解决的问题。虚拟仿真环境是一种很有前景的策略，可进一步用于在无风险环境中验证我们的理念，但这只是解决方案的一部分。将验证和测试延伸到运行时，似乎是补充车辆安全论证的有效方法，而健康指标可被视为迈向运行时验证的第一步。

目前，我们的理念尚未考虑安全问题。后端服务器、其他车辆、基础设施或应用程序等信息源的信息损坏，可能会引发严重风险。因此，运行时安全评估与运行时安全评估同等重要。未来的研究可扩展现有的健康指标，增加用于指示外部入侵的安全参数。