模型驱动的自动驾驶AI系统全生命周期安全保障

摘要

近年来，许多自动驾驶公司宣布缩减甚至关闭业务。尽管在过去十年中，数十亿美元被投入到自动驾驶领域，但至今仍没有一款具备商业可行性、能够在公共道路上行驶的自动驾驶汽车。

阻碍人工智能系统实现其目标功能的最大障碍之一是缺乏可证明的安全性。这种缺乏源于开发自动驾驶系统所使用的方法。这些方法大多是敏捷的，在大多数情况下没有清晰的流程描述。结果是，没有创建完整的系统描述。这反过来又使得安全分析和结构化安全论证的创建变得不可能。

在本文中，我们分析了确保交通领域人工智能系统安全性的模型和方法。我们根据 SAE J3016 标准，定义了适用于任何驾驶自动化级别的安全性确保任务。本文的目标之一是描述安全生命周期随自动化级别变化的特征。

一、引言

最近，许多自动驾驶公司（如 Argo AI、Motional、Embark Trucks）宣布缩减甚至关闭业务。根据各种分析报告，在美国和中国，对自主智能运输车辆开发的投资在 2017-2019 年达到顶峰。与此同时，关于这一主题的科学出版物也有所增加。然而，自 2018 年以来，全球范围内人们对自动驾驶汽车的信任度开始下降。自动驾驶行业的投资也在减少，甚至出现了比前几年下降的情况，中国的情况就是如此。

起初，自动驾驶汽车的创造者认为其相对人类驾驶的汽车具有更高的安全性，这是一个显著的优势。然而，到目前为止，这一目标尚未实现，自动驾驶汽车也没有得到广泛应用。人们对无人驾驶车辆信任度的降低与其实安全性不足直接相关。

自动驾驶系统通常分为不同的驾驶自动化级别。全球公认的分类标准是 SAE J3016。该标准根据自动驾驶控制系统（ACS）和人类操作员之间驾驶过程的分配，定义了 6 个级别的驾驶自动化（“驾驶员” 一词不适用于自动驾驶车辆）。L0-L3 级被认为是非自主的，因此应对紧急情况的责任在于人类操作员。对于自主级别（L4-L5），自动驾驶控制系统能够在任何道路条件下完全运行车辆，包括识别道路上的物体和事件、对其做出反应以及在紧急情况下确保安全。

因此，在更高的自动化级别上，安全方面变得至关重要。如果没有安全证明，这些系统就无法得到信任，也无法在公共道路上使用。

ISO 26262 标准对安全档案的定义如下：“证明项目（3.84）或元素（3.41）实现了功能安全（3.67），并由开发过程中活动的工作成果（3.185）所编制的证据来支持的论证”。

目前，有几个国际标准描述了道路车辆安全各个方面的安全流程。这些文件包括：

1. ISO 26262《道路车辆 - 功能安全》

2. ISO 21448《道路车辆 - 预期功能安全》

3. ISO 21434《道路车辆网络安全》

这些标准表明，系统安全可以通过在整个系统生命周期中执行某些工作包来实现。尽管方法相似，但各个标准中的工作包本身及其要求却有所不同。

应用这些标准的主要问题之一是，对于属于不同驾驶自动化级别的系统，无法采用相同的安全档案流程。因此，开发车辆自动驾驶控制系统的复杂性比开发具有类似复杂性的通用系统（即没有特定安全需求的系统）高出 3-5 倍。此外，一套固定的工作包和产品与当前的敏捷开发方法不太匹配。在本文中，我们建议解决这个问题的方法是，首先，将系统工程和生命周期（LC）方法的原则应用于自主系统的创建，特别是关于安全档案。其次，我们建议修改系统的生命周期模型，以便根据系统的自主级别创建安全档案。

二、安全与现代工程系统

A. 作为系统特性的安全

安全被定义为不存在不合理的风险。这个定义包含了需要单独定义的部分。

风险被定义为伤害发生的可能性和伤害严重程度的组合。不合理的风险是指根据有效的社会道德观念，在特定环境中被判断为不可接受的风险。

对上述定义列表可以这样理解：人类的任何作为（和不作为）都与某种风险相关。我们对此习以为常，并倾向于接受日常生活中的风险。然而，安全工程的任务是帮助设计出不会带来不可接受风险的系统，也就是说，与使用这些系统相关的风险不超过可接受的风险水平。

现在我们可以制定安全工程研究的任务。我们的目标是创建一个系统，对于该系统，我们可以证明，在任何相关的用例中（包括正确使用以及有意和无意的误用，见下文 2.3 节），与该系统相关的风险都不超过可接受的水平。在这项工作中，我们开发了一种系统工程方法来实现上述目标。

B. 现代系统的动态方面

现代工程系统通常不被视为技术制品，而是被视为影响人类社会进程的复杂社会技术系统。此外，这种影响可以出现在工程系统生命周期的所有阶段，从概念创建的早期阶段到退役阶段。这种系统的复杂性不仅来自技术难题（包括结构和行为复杂性），还来自人为因素的特殊性以及该系统所参与的复杂组织过程。工程系统的一个基本特征是，这些系统的条件和配置，如其元素、特征和相互联系，并不总是明确规定的，而且是易变的。因此，系统的这一方面是动态的。例如，考虑车辆在道路上行驶时如何根据交通情况调整，电力和通信网络的使用如何根据当时用户的数量和需求而变化等等。

由于现代系统复杂且融入社会活动，其开发不仅要追求旨在提高系统自身有效性和效率的功能参数，还要实现非功能特性，即所谓的 “ilities”，如可移植性、可靠性、可用性、可维护性等。在 20 世纪初，人们对系统的理解发生了转变：在此之前，技术被理解为一组独立的制品，而后来的理解则强调技术系统的复杂性和相互关联性。以前这些 “ilities” 只有几个，现在已经有几十个了。不同类型的系统有不同的基本 “ilities”。与任何高风险系统一样，安全性是自动驾驶系统的基本特征，它通常与其他三个 “ilities” 相结合：可靠性、可用性、可维护性（统称为 RAMS）。

C. 安全方面

在工程中，根据潜在的危害源对安全问题进行分组是很方便的。例如，安全工程包括专注于消防安全、电气安全、核安全的分支。为了确保系统安全，每个分支都有自己的标准。对于可能不是由于特定来源而是由于纯粹的失效而带来风险的复杂系统，现代标准定义了三种安全类型：功能安全、网络安全和预期功能安全（见图 1）。

图 1. 安全方法：用例

自治系统级别的提高导致系统的操作和维护难度增加。确保安全的过程也变得更加复杂。此外，某些类型的系统和组件没有普遍接受的安全档案方法。例如，这包括基于统计分析的机器视觉系统，如神经网络、贝叶斯网络等。因此，由于安全、可靠性和稳定性问题，此类系统难以在广泛使用的项目中轻松实施。

D. 自动驾驶车辆安全能力衡量

接管。除了自动化级别描述外，SAE J3016还试图描述 “自主的”、“自动驾驶的”、“无人驾驶的”、“无人的”、“机器人的” 等术语，这些术语在专业界通常被视为行话。同时，明确定义 “自主的” 这一术语的共同理解很重要，因为定义的不精确会极大地影响我们描述车辆功能能力的尝试，进而影响系统的安全需求。

SAE 指南强调 “自主的” 这一术语既流行又模糊，并建议不要用它来描述驾驶自动化。文献概述了当前在描述技术系统时使用该术语的一些变体。

在 L0-L2 级系统中，人类驾驶员完全负责控制汽车轨迹，检测并对道路上的重要物体做出反应。因此，系统在预防安全问题方面的作用仅限于在发生失效时降低风险。在这种情况下，安全分析只关注选定的不利场景。在 L3 级系统中，人类驾驶员仅负责在紧急情况下采取行动（“后备运行”）。在 L4-L5 级系统中，人类驾驶员不应该进行任何干预，因为系统应该能够自主保证安全。这导致可能的道路情景数量增加，并且需要对系统进行精确描述，这不可避免地导致使用统计分析方法。确保安全的任务逐渐从人类驾驶员转移到系统。

然而，即使对于同一自主级别内的系统，人类驾驶员的情境意识（即驾驶员对道路情况的感知必须与实际道路情况一致）在其确保安全驾驶过程的能力中仍然起着重要作用。例如，我们比较两个 1 级高级驾驶辅助系统功能：自动紧急制动（AEB）和自适应巡航控制（ACC）。使用自动紧急制动时，人类驾驶员始终保持对车辆纵向和横向运动的情境意识，系统仅在驾驶员未能处理的紧急情况下进行干预。驾驶员控制道路条件，包括道路上的静态和动态物体、交通中其他车辆的可能轨迹以及车辆自身的预期轨迹。在这种情况下，最重要的安全特征是自主系统的干预次数，因为只有当系统检测到超过估计安全需求的参数时（对于自动紧急制动，这是与前方物体的估计碰撞时间），才会发生干预。使用自适应巡航控制时，驾驶员会失去情境意识，因为车辆会自动保持稳定的速度和与前方车辆的距离。当自适应巡航控制关闭时，驾驶员需要一些时间来评估当前速度以及自己的车辆与道路上其他车辆的位置，然后才能安全操作。在这种情况下，我们可以使用接管请求的数量（即驾驶员请求从自适应巡航控制接管转向的次数）作为安全特征。

为 L3 级及以下的自动驾驶车辆证明安全性还需要评估接管场景，因为这些场景会影响自动驾驶车辆的安全性。在过渡期间，系统必须在合理程度上支持有效的接管能力，以支持人类在接管后对车辆的可控性。此外，长期使用自动驾驶系统可能会降低驾驶员的情境意识。

行为复杂性。安全方面的另一个问题是，我们需要分析的可能道路场景数量增加，导致分析更加复杂。因此，L3-L4 级系统的输入参数的不同组合数量大大超过 L0-L2 级系统。由于不同的系统操作模式（例如，自动驾驶模式和高级驾驶辅助系统）需要不同的数据，我们可以得出结论，不同的系统配置对应不同的场景集。必须对每个系统模式进行安全评估。

此外，我们必须考虑全新的、我们以前从未遇到和研究过的场景。这些场景可能是由于周围环境的变化而出现的，例如新的道路标志或新的交通模式，或者是由于道路使用者与自动驾驶车辆之间新的交互场景，例如尾随（配备高级驾驶辅助系统的自动驾驶汽车跟随另一辆自动驾驶汽车，因此两辆车的安全都取决于其自动驾驶控制系统）。所有这些场景也必须包含在安全档案（验证与确认）中。

一些自动驾驶车辆的元素可以通过机器学习算法来实现。这将需要新的安全档案方法，因为机器学习算法的行为具有非确定性。此外，基于机器学习的组件和系统不能被分解，必须作为黑盒进行测试，这需要对场景分析采用统计方法。

三、人工智能系统的安全流程

A. 安全系统工程

系统工程（SE）和生命周期方法（LCA）属于系统工程方法论。它为成功的人工系统提供了方法论基础，将所有利益相关者的利益平衡作为成功的主要标准。

有超过二十种系统工程过程或方法，每种方法都包含构建系统所需的几个重复动作。在系统生命周期（LC）的每个阶段迭代应用系统工程过程，可以降低整个生命周期的成本，缩短系统创建时间，并获得其他竞争优势。

在运用系统工程的原理和方法创建系统时，其功能和非功能参数以及数值指标都是根据需求和系统架构来开发的。在需求中，它们以操作能力的形式出现，并传递到整个系统级别、逻辑架构级别和物理架构级别。在此过程中，需求被分解，新的需求被定义并分配给系统的架构组件。然后通过权衡分析选择最合适的架构组件。目前，上述算法可以使用面向模型的系统工程工具来实现，例如 ARCADIA 方法和 Capella 软件。

谈到在考虑实现安全性的情况下创建系统，首先要制定的是从安全角度管理系统生命周期的策略。这包括确定表明安全目标已实现的安全参数，并定义管理系统生命周期以确保安全的任务。一个常见的例子是基于 V 模型的生命周期模型，它可以方便地描述系统分析和组装过程。

目标函数安全档案的基本方法是进行高度迭代的功能分析和系统开发，包括验证和确认过程，以证明目标函数达到了所需的安全性（图 2）。这种方法意味着我们可以定义系统安全运行的已确认场景区域，以及系统可能造成伤害的未知场景区域。

当今普遍认可的方法既需要对开发的组件进行测试，也需要对开发过程进行质量审计。

B. 根据 ISO 26262 的安全流程

安全档案过程通常采用系统生命周期管理方法。这包括 ISO 26262 标准。

根据该标准，整个生命周期包括五个阶段：概念阶段、系统级产品开发、硬件级产品开发、软件级产品开发、生产和运营。对于每个阶段，该标准都规定了确保所开发系统在其运行过程中的安全性的操作流程（见图 2）。此外，每个过程都提供安全论据（证明系统可被认为是安全的信息）。这些安全论据结合起来就构成了安全档案。

图 2. 根据 ISO 26262 的 V 模型安全生命周期

ISO 26262 标准适用于开发 L0-L2 级的安全系统，但对于更高的自主级别来说是不够的。ISO 26262 仅涵盖由失效引起的危害。它不涵盖由系统设计不足引起的危害，换句话说，就是系统规范未完全覆盖运行设计域（ODD）的情况。

C. 根据 ISO 21448 的安全流程

ISO 21448 标准描述了确保目标功能安全的过程。换句话说，它回答了 “规范与运行设计域（ODD）之间的不一致如何影响特定系统功能（通常是智能功能）使用的安全性” 这一问题。ISO 21448 描述了该过程的三个阶段：

· 识别和评估触发事件，即系统外部可能导致危害事件的特定条件；

· 评估已知危害场景的风险；

· 评估未知危害场景的风险。

ISO 21448 标准的最终版本于 2022 年发布。它可以应用于任何自主级别的系统，并定义了验证、道路情景规范、确保具有非确定算法的系统安全等主题。尽管最新版本（与 2019 年发布的早期 ISO PAS 21448 相比）增加了额外的章节，但对 L3 和 L4 级自主系统的安全保障过程的描述仍然不完整。

总而言之，我们可以得出结论，不同自动化级别的系统的安全需求差异很大。因此，目前对于 “我们应该采取哪些措施和使用哪些方法来确保每个自主级别的车辆安全？” 这个问题，还没有完整的答案。

四、不同自主级别的安全生命周期模型

系统安全过程中的一个重要步骤是验证和确认系统解决方案是否满足系统安全能力所定义的要求。安全档案需要基于统计估计的验证，以确保对所有已知和未知场景的安全性有足够的信心。用于这种验证的场景既可以在物理环境中直接创建并允许进行受控测试程序，也可以在系统使用过程中自然发生。

另一个有前景的选择是使用面向模型的系统工程方法，在虚拟环境（为先前创建和分析的系统生成）中分析这些场景（见图 3）。

图 3. ARCADIA 方法和安全生命周期 V 模型

根据生命周期 V 模型，第一步是分解系统解决方案，开发功能并定义系统的非功能特征，包括安全性。模型中的右分支展示了已开发系统解决方案的集成，以及对其功能和非功能特性完整性的验证。面向模型的系统工程 ARCADIA 方法能够在每个生命周期阶段将需求嵌入到任何系统解决方案中。这使我们能够使用模型进行安全档案工作，这是一种更高效的方法。

使用 ARCADIA 方法，我们在五个架构级别上开发系统解决方案：操作分析、系统需求分析、逻辑架构、物理架构、EPBS（电子、电气和可编程电子系统）。对于每个级别，我们根据所选的视角指定系统功能参数和其他相关特征。例如，从安全视角检查安全参数。

举个例子，让我们考察以下任务（M）：“避免车辆与其他道路使用者发生任何碰撞”。

运行能力（OC）包括：

· 识别接近的物体；

· 根据与物体的距离确保适当的减速。

该级别的安全需求可能包括：

· 确保对检测到的物体进行准确分类；

· 确保根据距离、天气条件、一天中的时间准确确定物体；

· 确保有效的减速。

同一级别用于建模操作过程和场景。例如，车道内行驶的运行过程由几个运行活动（OA）组成：

· OA1. 保持车辆行驶；

· OA2. 监视附近的道路使用者；