精品译文 | 重新定义自动驾驶车辆的安全性

译文

重新定义自动驾驶车辆的安全性

原文：Redefining Safety for Autonomous Vehicles

翻译：季池、卢雪梨

审核：王叶、陈丽

基于计算机的系统安全的现有定义和相关概念框架应根据部署自主车辆的实际经验进行重新审查。行业安全标准使用的当前术语强调减轻特定危险的风险，并基于人类监督的车辆操作进行假设。没有人类驾驶员的操作极大地增加了安全问题的范围，特别是由于在开放世界环境中的运行、自我执行运行限制的要求、参与系统的特定社会技术系统以及遵守法律和道德约束的要求。现有的标准和术语只能部分解决这些新的挑战。我们建议更新核心系统安全概念的定义，包括这些额外的考虑因素，作为演化安全方法的起点，以解决这些额外的安全挑战。这些结果还可以为其他自动系统应用的安全术语框架提供信息。

01  引言

机器学习技术的广泛应用要求我们重新审视计算机系统“安全”一词的含义。是时候问一问，我们当前的安全定义是否适用于这样的系统。现有的定义框架可以进一步延伸，但已显示出显著的老化迹象。此外，由这些传统定义所塑造的思维模式和流程本身也在这种新技术的冲击下逐渐失效。

更新安全和相关术语的定义可以促进更稳健的安全观点。我们在现实世界中的自动驾驶汽车（AV）部署中，从已经看到的一些事件中找到了支撑我们提出的更新的基础，并识别出了更广泛的潜在主题。我们根据当前相关行业共识标准（ISO 26262、ISO 21448和UL 4600）中使用术语的发展需要，提出了一组更新的定义。

作为正在出现的问题类型的第一个例子，有许多关于旧金山自动驾驶出租车干扰应急响应操作的报告。这通常不涉及明显危险的车辆运动，例如碰撞，而是涉及车辆为了减轻碰撞风险而使自己停滞在无法安全处理的情况下。然而，这种出于安全动机的行为可能会阻碍应急响应车辆的进展，从而增加社会风险。这不是当前安全标准的用户通常预期的损失事件类型。

我们使用最近的自动车辆事故的例子来确定当前安全概念和术语的缺点。然后，我们提出了核心安全术语的调整定义。虽然我们在本文中关注的是术语和自动驾驶车辆，但这只是关于自治系统安全性的更广泛讨论的开始。技术的本质要求安全视角本身进行重大转变和扩展，以应对这些挑战。

本文的第2节使用与自动驾驶车辆安全相关的国际标准，总结了当前安全和相关概念的示例定义。在随后的部分中，我们讨论了这些定义为何在自动系统的要求下显得力不从心，并通过现实世界的事件识别核心差距。然后，我们提出了更新的关键定义，以解决差距，同时不打破现有的安全工程实践。

至于范围，本文不涉及关于组织安全理念的讨论，也不涉及如何最好地实现定义的安全目标，或如何将工程术语纳入法规中。这些重要话题如安全改进方法和安全管理系统留待其他讨论。同样，危险识别和分析技术依然适用，但超出了我们的讨论范围。我们也承认，在法规领域有大量关于安全和风险的工作。这为我们的工作提供了信息，但我们并不寻求提出法规术语的重新定义——这将是另一篇论文的主题。

02  现有安全定义

从本质上讲，我们的工作是探究在开发基于计算机的安全关键系统时，改变“安全”的本质——特别是必须在超越传统功能安全和人类监督系统安全的社会技术框架内运行的系统。

这项工作建立在初步工作发现的基础上，即可接受的自动驾驶车辆安全需要的不仅仅是“优于人类驾驶员”的净风险方法。在这项工作中，我们确定了复杂的因素，包括：风险补贴，风险转移，疏忽，响应者角色安全，指责的适当角色，标准一致性，监管要求，道德问题，公平问题，以及风险的行为监管问题而不是净风险评估。但该工作未考虑是否应重新审视风险和安全语言本身以帮助解决所提出的问题。

首先，我们从自动驾驶车辆功能和系统安全标准的关键安全定义开始。汽车领域现有定义的首要概念是，汽车功能安全通常被认为是指不存在不合理风险（AUR），这通常在ISO 26262的一系列定义中有所描述。

2.1  ISO 26262

ISO 26262:2018是适用于道路车辆的功能安全标准，无论是否是自动驾驶。该标准第1部分的安全定义基于风险、危害和伤害的层次。核心定义概述如下，省略了交叉引用和支持注释：

• 安全：不存在不合理的风险；

• 不合理风险：根据有效的社会道德观念，在某种情况下被判定为不可接受的风险；

• 风险：伤害发生的可能性和伤害的严重程度的组合；

• 严重性：估计在潜在危险事件中可能对一个或多个人造成的伤害程度；

• 危险事件：危险和运行情况的组合；

• 危险：相关项故障行为造成的潜在危害来源；

• 伤害：人身伤害或人身损害；

• 故障行为：与其设计意图有关的相关项故障或意外行为；

• 运行情况：车辆寿命期间可能发生的情况；

• 安全档案：论证相关项或要素实现了功能安全，并通过从开发期间活动的工作产品中编译的证据得到满足。

在此我们停止进一步深入其他定义术语。就我们的目的而言，“相关项”是包括其运行时支持基础设施的自动驾驶车辆，尽管根据标准它可以以其他方式解释。故障与异常情况有关，包括由组件故障、软件缺陷和任何其他来源引起的随机故障和系统性故障。

作为一个功能安全标准，其重点是避免因故障行为而对人造成伤害。该方法隐含地假设，完美实现其设计意图（包括风险缓解措施）的系统将是安全的。

在实践中，汽车行业倾向于识别危险，分析每个危险的风险，并执行缓解措施，以确保没有个别危险导致不合理的风险。如果满足该标准，则认为系统是安全的。

虽然在实践中可能会发生这种情况，但没有明确要求检查多个不相关危险所带来的风险之间的关系，量化整个系统所带来的净风险，也没有要求考虑除违反设计意图的故障行为以外的其他来源所带来的风险。实际上，当车辆进入批量生产时被确定为安全，任何在发布后发现的安全缺陷本质上是由于有缺陷的开发或制造过程，可能导致监管召回或制造商补救。标准中没有在系统行为级别纳入明确的数值故障率目标。然而，汽车安全完整性等级（ASIL）方法考虑了严重程度、暴露程度和可控性，以确定每个识别出的危险所需的缓解措施。对于没有人类驾驶员来行使控制的车辆，解决可控性方面可能存在问题。

2.2  ISO 21448

ISO 21448:2022涵盖了预期功能的安全性（SOTIF），扩展了ISO 26262的安全性定义，同时作为补充标准，范围包括自动驾驶车辆的驾驶行为。

ISO 21448没有改变风险和安全的定义，而是采用了ISO 26262的定义。然而，它确实增加了一个涵盖SOTIF的新术语。同样，列出的定义省略了支持材料：

• 预期功能的安全性（SOTIF）：不存在因预期功能或其实施的功能不足而导致的不合理风险；

• 危险：车辆级别的危险行为造成的潜在危害来源；

• 功能不足：规范不足或性能不足；

• 性能不足：导致危险行为的技术能力的限制，或在一个或多个触发条件激活时，无法防止或检测和缓解合理可预见的间接误用；

• 运行设计域（ODD）：系统设计运行的特定条件。

SOTIF总体上处理两种类型的功能不足，这通常超出了ISO 26262的范围：（1）不完整的要求，以及（2）系统的技术局限性。功能不足可能在特定情况下产生危险行为，这被称为触发条件。

不完整需求方面旨在处理公共道路是复杂的运行环境这一事实。SOTIF方法基于减少“未知危险”场景类别，直到达到AUR（ISO 21448:2022图8和图10）。通过参考规范的潜在不足，确认需求差距的可能性。虽然本标准考虑了危险分析和场景识别所需的迭代实验方法，但它假定可以制定足够完整的规范，以在部署前实现AUR。它对危险的定义从ISO 26262中的定义进行了修改，以强调危险车辆级别的行为。

任何具有外部传感器的系统的技术局限性将不可避免地需要基于有限的、不完整的、有噪声的信息来建立外部世界的内部模型。并不是每个雷达脉冲都会产生回波。传感器的范围不是无限的。从任何特定传感器的角度来看，一些对象被遮挡。并且各种类型的噪声将把不确定性引入到外部世界的任何模型中。该标准认识到，尽管存在这些潜在的性能不足，但自动驾驶系统必须针对AUR进行设计。

同样，重点是车辆的行为，一般假设损失事件主要是由于传感器局限性、车辆行为缺陷或规范不足造成的碰撞。定义的运行设计域（ODD）概念的纳入，在考虑安全的范围限制方面提出了一个重要问题。在经典术语中，安全往往被限制在某个定义的ODD范围内。例如，DEFSTAN 00-56中安全档案的定义仅限于“给定的运行环境”[DEFSTAN00-56]。然而，关于如何将运行限制在该限定范围内的考虑通常没有得到解决，并且通常遵从一些人类操作员的判断，例如应该避免在极端天气条件下飞行的飞行员。对于自动系统，将安全性限制在定义的条件下是不够的，因为某些参与者（默认情况下为自动系统）还必须通过避免在ODD之外操作来确保安全性。这可能包括拒绝在OOD之外开始任务，但也可能需要一些可接受的安全反应，以应对由于不可预见的情况或事件而在没有足够通知的情况下被强制弹出 ODD。因此，ODD 的执行必须在安全范围内。

2.3  ANSI/UL 4600

UL 4600是专门针对自动驾驶车辆的系统级安全标准[UL4600]。其术语旨在与ISO 26262和ISO 21448兼容，同时解决更广泛的系统级范围。定义与其他领域的安全标准进行了系统的协调，总结如下：

• 安全：在安全档案定义的相关项级别具有可接受的缓解后风险；

• 可接受：足以达到安全档案中确定的整体相关项风险；

• 风险：损失事件发生的可能性与损失事件严重程度的组合；

• 损失：实质性的不利后果，包括财产或环境损害、动物伤害或死亡、人员伤害或死亡；

• 安全档案：由大量证据支持的结构化论证，提供令人信服的、可理解的和有效的案例，证明系统对于给定环境中的给定应用是安全的。

与前面讨论的标准一样，风险与特定损失事件的可能性和严重性有关。然而，风险可接受性的概念与整体相关项风险有关，而不是单个风险，例如高度推荐的相关项总风险求和方法（UL 4600提示要素6.1.1.3.）。此外，损失的定义超出了对人类的伤害，包含其他类型的负面结果。安全档案的范围扩大了，但其与术语“安全”定义的相互作用为安全档案的作者提供了自由度。安全档案的创建者有责任定义“安全”的含义，并确保安全档案提供适当的论据，表明安全目标已经实现。安全档案的定义来源为DEF Stan 00-56，将安全档案的范围限制到给定环境中的预定应用，如前所述。然而，UL 4600 提供了广泛的提示要素列表，以鼓励对 ODD 的潜在特殊方面进行稳健的考虑。

2.4  其他安全定义

我们所知道的其他汽车安全标准，除了上面讨论的那些之外，还采用了ISO 26262和可能的ISO 21448术语。

另一个在汽车行业被广泛引用的安全定义是正风险平衡（PRB）。这是BMVI报告中提出的一个安全考虑因素。该报告还提出了其他对道德安全的限制，例如避免在无胜算的碰撞场景中使用个人特征来选择受害者。但在更广泛的汽车行业安全讨论中，PRB通常被单独挑出作为标准。

使用PRB作为唯一标准在很大程度上是有问题的，因为很难为人类驾驶车辆和自动驾驶车辆建立可比较的基线。尽管如此，它仍然是Waymo【Waymo23】和Cruise【Cruise23】在传达安全信息时提出的主要标准。

在这样的讨论中，PRB通常被假定为产生AUR，尽管下一节中讨论的AV安全问题的例子表明情况不一定如此。

AUR概念的一个重要监管用户是美国国家公路交通安全管理局（NHTSA）。当“该机构发现不合规或缺陷对安全造成不合理的风险”时，NHTSA会采取执法行动。他们的方法往往有两个要素。首先是符合联邦机动车辆安全标准（FMVSS），该标准形成了一套主要适用于传统车辆安全而不是自动驾驶车辆功能的特定安全功能的离散测试。

美国国家公路交通安全管理局（NHTSA）的第二个标准是，他们认为安全缺陷是一种特定的行为、设计缺陷或其他与损失事件模式相关的问题。美国国家公路交通安全管理局（NHTSA）可以展开调查并要求安全召回。美国国家公路交通安全管理局（NHTSA）的典型召回和调查涉及不符合美国联邦汽车安全标准（FMVSS），或者较少涉及更难与特定技术缺陷联系起来的事故和事件模式。美国国家公路交通安全管理局（NHTSA）的决定在历史上没有考虑车辆级别的净PRB。

03  AV安全问题示例

在本节中，我们抽取了一些自动驾驶出租车在现实世界中遭受的事故和不幸事件，以便为识别当前安全术语的缺陷提供依据。这些例子来自自动驾驶出租车以及高度自动化的车辆。安全监督员（人类驾驶员）是否在场对事故并无影响——在安全监督员在场时发生的问题同样可能在无人监督时发生。

行人拖拽，一名行人被另一辆车撞倒，并被抛到一辆自动驾驶出租车的车道上。自动驾驶出租车急刹车但仍撞到了行人。可以说，自动驾驶出租车本可以更具防御性地驾驶，以避免最初的撞击。无论如何，在停下来之后，自动驾驶出租车失去了对行人的跟踪。决定把车停在路边，把行人拖到车下，结果行人几乎完全被压在车后。涉案的自动驾驶出租车公司试图将此描述为一个不可预见的反常事件。尽管如此，在没有首先确定刚刚被同一车辆撞击的受伤行人的位置的情况下移动车辆是非常有问题的。

与消防车相撞，一辆自动驾驶出租车按照绿灯进入十字路口，但随后与一辆消防车相撞，导致一名乘客受伤。消防车的紧急信号器（警笛、警灯、喇叭）处于活动状态，并在响应紧急呼叫时通过交叉路口的红灯。自动驾驶出租车没有按照道路规则的要求向紧急车辆让行。

撞上一辆公共汽车，一辆自动驾驶出租车在跟随一辆带有中体关节枢轴的长途公共汽车时发生了混乱。自动驾驶出租车跟踪了巴士的前半部分，忽略了后半部分。然后它撞上了巴士的后半部分，因为跟踪系统决定忽略检测到的后半部分，而选择前半部分。

干扰应急响应人员，旧金山市应急响应人员报告了至少55起自动驾驶出租车干扰其运营的事件，后来消防部门报告的事件增加到74。虽然没有明确显示任何事件会对人造成伤害，但这些事件存在风险，因为它们会延误应急响应人员的工作，并需要应急响应人员的关注，而这些人员最好花在处理实际紧急情况上。

侵占封闭道路，已发生多起侵占封闭道路和紧急现场的事件，对车辆、车内人员和其他道路使用者构成潜在危险。例子包括：沿着街道拖着倒塌的电线和紧急现场黄色隔离带，以及开车穿过施工区，结果却陷入未干的混凝土中。

大规模搁浅，在各种情况下，发生了许多大规模车辆搁浅事件。其中一个引起特别关注的原因是，尽管该事件并不涉及发生搁浅的街道，但由于邻近地理区域的音乐会活动导致移动电话系统过载，导致通信中断。这引发了关于在由诸如地震或其他常见原因的基础设施故障之类的自然灾害引起的通信中断或交通控制设备断电中会发生什么的疑问。

儿童从校车上下来，一辆自动驾驶启动的车辆撞伤了一名从校车上下来的儿童。

未在停车标志处停车（滚动停车），美国国家公路交通安全管理局（NHTSA）对驾驶自动化系统实施了安全缺陷召回，该系统被编程为以高达5.6英里/小时的速度通过停车，违反了交通法规。

应急响应人员受伤和死亡，对与应急响应车辆的碰撞模式进行了调查和初步召回，随着时间的推移，至少发生了14起碰撞、15起受伤和1起死亡事故。最终的召回不是因为特定的可重现的行为缺陷，而是因为一种常见的损失模式，与缺乏 ODD（操作设计领域）执法以及人类驾驶员在路上对道路注意力不足的执法有关。

与停止和穿越的车辆发生碰撞，与应急响应人员碰撞调查相关的是，有许多关于特定驾驶自动化系统与静止车辆碰撞的报告。这包括在涉及穿越重型卡车下方的场景中发生的多起死亡事故。尽管制造商表示设计意图是让驾驶员手动避免此类驾驶情况和碰撞，但碰撞事故仍然不断积累。与紧急救援车辆碰撞调查相关的是，报告了多起与停驶车辆的碰撞，包括涉及多起在穿越重型卡车时发生的致命碰撞。虽然制造商表示其设计意图是让驾驶员手动避免此类驾驶情况和碰撞，但碰撞仍在继续发生。

在弱势群体中，碰撞事故升级，旧金山消防局报告称，在面积狭小的田德隆区附近，发生了74起无人驾驶出租车事故，其中11起涉及与消防车的碰撞。该地区以弱势群体和历史风险社区而闻名。由于可能的相关原因，该地区是美国最活跃的紧急响应地点之一。尽管如此，无人驾驶出租车公司认为继续在该地区进行测试是合适的，这可能是因为该地区位于旧金山市中心。

吸引乘客远离公共交通，即使无人驾驶出租车和人类驾驶的车辆一样安全，人类驾驶的车辆也比公共交通危险得多 。无人驾驶出租车的广泛采用可能会通过将公共交通乘客里程转移到自动驾驶出租车乘客里程来降低安全性 。失去公共交通乘客可能会进一步削弱更安全交通方式的资金和可行性，增加所有交通方式的净死亡人数。

我们发现，人类驾驶员可能并且确实会犯上述所有类型的错误。但我们有兴趣了解安全的真正范围，这应该同时适用于人类驾驶员和自动驾驶汽车。

这些情况中，许多并不涉及对人的实际伤害。但由于存在直接或间接伤害的可能性，所有这些都被至少一些相关利益攸关方视为安全问题。在上述许多情况下，很容易将责任归咎于自动驾驶能力以外的某些参与者。但是，为了避免改变现状而进行归咎，不太可能防止未来的事故。

04 安全定义中缺少什么

基于这些观察到的和对自动驾驶汽车安全要求的总体理解，我们确定了自动驾驶汽车的四个一般特征，这些特征对安全工程产生了深远的影响：在开放的世界环境中运行，自主改善的操作限制，投放在特设社会技术体系中，以及如法律限制等外部约束的表达等。历史上，处理这所有四个领域的工作都分配给了人类驾驶员。然而，拥有自动驾驶汽车的重点是不再需要人类驾驶员，这样就对这些技术系统提出了额外的要求。（作为一项临时措施，远程操作团队可能会协助解决其中一些问题。但是，可扩展的投放要求最大限度地减少了对这种远程人工操作干预的需求。）

4.1 开放的世界环境

自动驾驶汽车作为在公共道路上大规模运行的工程系统，针对将遇到的所有物体和事件，是在不确定的和不完整训练的框架内运行的。

ISO21448的SOTIF方法主要是为了解决这个问题。然而，该标准的方法以及许多开发人员的实用方法一样，是假设在投放之前已经识别并缓解了足够多的可能场景、对象和事件，从而产生净AUR。如果遇到危害的分布频率是重尾分布的，涉及大量单独来看发生频率很低的危害，那么上一点在实际系统中可能无法实现。尽管在重尾分布危害情况下，可能有技术措施确保可接受的安全性，但在部署技术措施后这些危害依旧带来大量风险的可能性是不容忽视的。

ISO21448在面对未解决的危害时，采用迭代改进方法，但仍假定风险在初始投放时是合理的。UL 4600具有更全面的机制，可以识别在初始投放时可能存在的不确定性，这意味着可以预期的合理的风险，但这种预期本身也存在一定程度的不确定性。UL 4600要求使用安全绩效指标（SPI）和现场工程反馈来管理持续改进过程，以识别和减轻由于不断变化、开放的世界环境以及遇到不可预见的重尾事件而导致的风险。

对安全的全面定义应考虑两个问题，这两个问题在可预见的未来将成为自动驾驶汽车的现实：（1）即使在投放时，也要对不可避免的需求差距进行主动管理，以及（2）支持在车辆生命周期内持续更新，以减轻因环境和其他变化而产生的紧急危害和风险。

4.2 运行限制的自主改善

达到自动驾驶汽车运行限制范围之外某种情况的一种常见方法是安全关闭（或类似的操作）。对于自动驾驶汽车来说，这可能意味着将其拉到一个安全的停车位置，甚至在有利条件下将其停在行驶车道的中间。虽然执行合理的安全停车可能很复杂，但认识到自动驾驶汽车已经超出其运行限制才更具挑战性。

基于机器学习的技术面临着一个根本性的挑战，即我们需要认知到它遇到了一个与安全相关的有意义的，但在训练过程中没有被捕捉到某种数据特征的数据维度。例如，如果训练数据集中穿着黄色衣服的人太少，那么一个穿着黄色服装的建筑工人可能不会被识别为指挥交通的建筑工人，甚至可能根本不会被识别为一个人。或者，紧急情况下黑黄色胶带可能不被识别为禁止警告，而被当成一种不会造成碰撞威胁的不重要的塑料，导致一些无人驾驶出租车不仅拖着紧急胶带还有电线在街上行驶。

安全的核心要素是需要识别和应对超出系统预期标称运行环境的情况。这些可能是不可预见的情况，如新对象和事件。但也可能是已预见的ODD以外的情况意外出现，如晴天预报下突然下起倾盆大雨，因此设计团队并没有加以考虑。这一点与前面的开放环境问题相结合，使得系统固有的运行限制的自主改善具有挑战性，目前的定义往往将安全限制在已知的特定环境中。然而，无人驾驶系统在非特定环境中运行时也必须确保安全，并且必须能够以某种合理的方式对意外发现自己处于设计运行环境之外的情况做出反应。

4.3 特设系统体系

自动驾驶系统必须作为社会系统的一个组成部分来运行，社会系统往往不够具体，而且在很大程度上超出了自动驾驶系统设计团队的控制能力。从当前安全定义的角度来看，除非建立系统运行限制的自主改善，在某些情况下设计团队无法控制它将处理哪些场景。

一些利益相关者安全问题的共同主题是，自动驾驶汽车以一种狭义的安全方式行事，即使不撞到东西，但却给其他道路使用者造成了负面的外部条件。例如，当自动驾驶汽车不确定下一步该做什么时，在看似开放的但是无人驾驶出租车不应使用的驾驶车道（供工程车辆使用）内停车，或者在特殊情况下打破一些正常的道路使用惯例为过往的紧急车辆提供空间，以及由于所谓的幻影制动导致撞车风险增加等。

一些安全问题具有更微妙的背景敏感性。例如，人类驾驶员可能会因为看到前方几个街区发生巨大的建筑火灾而改变路线，以避免陷入可能的现场交通混乱。自动驾驶汽车如果不识别这种情况，可能会阻碍应急响应活动。虽然人们可能会尝试在系统体系层面分析所有存在的危险，但这通常超出了自动驾驶汽车安全工程工作的范围和资源。我们认为，更实际的是将负面外部条件的缓解表达为对允许行为的约束。例如，当一辆带有主动报警器的消防车在附近时，无论车载软件如何估计碰撞风险，都要驶出行车道。另一个例子是，避免使用另一辆自动驾驶汽车被困的道路，以避免一群被困的自动驾驶汽车堵塞道路。

4.4 法律和伦理限制

可允许的系统行为存在许多限制，这些限制不仅难以表达为危害，而且可能会降低系统的理论净收益（甚至可能是净安全性）。以风险为中心的方法将难以应对这些限制。

例如，考虑一种假设情况，其中驾驶自动化系统减少了总死亡人数，但增加了路边碰撞现场应急响应人员的死亡率。或者考虑一种更极端的假设情况，其中道路总死亡人数减少了50%，但行人死亡人数绝对值增加了一倍（成为降低的净死亡率中更大的比例）。即使净伤害减少，这两种结果对某些利益相关者来说也是有问题的。

如果技术系统不能满足对单个车辆行为和行为模式的限制，例如在这种情况下也适用于人类驾驶员，那么社会利益相关者就不应该认为它是可接受的安全的。考虑一辆在确定十字路口畅通时，会闯过停车标志的车辆。也许有一项可能的研究表明，这可以减少追尾碰撞，从而提高安全性。但是这样的系统仍然可能被视为存在不合理风险，因为它自动化了违反交通法规的行为。如果一辆自动驾驶汽车无视在停车标志前完全停车的要求，撞上了一个未被发现的行人，那么它也会造成严重的疏忽驾驶问题。

如前所述，这里的目标是评估SM与ML分类器一起工作时对SUT的影响程度。如第3节所述，对于新颖性类作为OOD数据，如果SM正确检测到OOD数据，它将始终被解释为真阳性，因为SM总是正确地取消ML分类，独立于基本事实。另一方面，如果SM没有检测到OOD数据，它将始终被认为是假阴性，并且ML将始终给出错误的分类。因此，在这里测量OOD检测并不有趣，因为ML将具有0%的准确性。同样地，测量整个数据流并不能提供足够的信息，因为当OOD数据量趋于无穷大时，ML的精度会变为0。出于这个原因，表5显示了当使用GTSRB或CIFAR-10作为ID数据集时，SUT中的总体SM影响。

还有一些伦理、公平和法律的考量，这些考量与车辆方向控制失灵没有明显联系，例如过度关注对弱势社区中进行不成熟技术的公共道路测试。

05  更具鲁棒性的安全定义的建议

5.1 需要解决什么问题？

我们提出了一套重新定义的核心安全定义，以解决根据车辆自动化事故的例子和标准中已经存在的概念以及前面章节中提到的其他来源所发现的问题。

回顾上述第3节和第4节中的示例事件和差距领域分析，我们认为需要在定义层面更直接地解决以下安全方面的问题。我们使用第2节中调查的定义中的关键词和短语作为每个概念的标签。

• 安全的/安全性Safe/Safety：

系统不仅要减轻危害，还要满足外部施加的约束。约束可能涉及禁止基于道德和公平的工程优化（否则可能会改善安全的特定方面），并禁止不可接受的风险模式。我们更喜欢“可接受的安全性”而不是“安全的”。

• 运行设计域/给定的环境ODD/Given environment：

不能假设环境具有完全的特征，也不能假设环境随时间而变化。相反，无论环境如何，都必须确保可接受的安全性，即使系统由于超出其运行限制而必须自行执行安全响应。

• 给定的应用Given application：

系统需要强制执行潜在的滥用，例如操作员在有交叉的道路上使用自动驾驶，这违反了系统的设计意图限制。

• 风险Risk：

风险作为发生概率和严重度的组合的陈旧公式可能适用于净损害的单维优化，特别是在货币补偿在道德上是可接受的缓解计划的情况下。但对于社会和其他约束（如损害模式或违反约束）而言，这是一个过于狭隘的观点，不容易简化为经典的风险值。

• 危害事件Hazardous event：

在危害事件层面评估一些风险和约束具有挑战性，因为它们涉及系统体系层面的安全权衡。期望车辆设计人员完全评估这些风险是不合理的，更不用说减轻这些风险了。还有一些风险模式，如风险转移到弱势群体身上，这些群体与个人损失事件相去甚远。

• 严重度Severity：

任何特定损失事件造成的伤害都很重要，但如果该事件是不道德或不公平结果模式的一部分，则任何单一事件的严重性可能无法反映该事件的重要性，即使从功利主义个人伤害的角度来看，严重性较低。

• 危害Harm：

损害必须被视为超出人身伤害或死亡（正如其他一些定义和领域的情况一样）。即使间接造成财产损害，也可能被合理地视为某些领域的安全问题。

• 故障Malfunctioning：

事故的发生不仅是因为车辆显示了危险的运动，还可以是为了提高战术上的安全性而导致在系统的系统层面造成了潜在的损害。安全关闭后，被瘫痪的无人驾驶出租车阻挡了应急车辆，这是该问题的典型例子。

5.2 建议的安全相关定义的建议

我们在图1中提出了核心安全术语的一套新定义。虽然对每个标准的特定术语使用的具体建议超出了本文的范围，但我们相信，如果这些术语被UL 4600采用，对文件其余部分所做的更改将引导符合该标准的安全案例覆盖范围的有益演变。其他标准，如ISO26262，可能仍希望使用更具限制性的术语，但应统一术语，以便在使用这些更广泛的定义时，不排除一致性。

图1 拟提议的定义

从高层次来看，这种方法不是将“安全”概念视为降低风险的优化过程，而是将其视为满足一系列安全约束。其中的一种约束通常足以降低风险，也更符合传统的安全工程方法。然而，其他约束以及损失概念的范围扩大可以解决法律和道德问题。通过在安全工程定义中明确包括生命周期因素，并要求安全工程与安全案例相结合，来解决开放世界环境问题。通过删除“给定环境”一词，并避免在安全案例定义中提及ODD，来解决操作限制的自主改善问题。通过在风险和安全约束的定义中包括除系统设计者以外的利益相关者的概念，来解决特设系统问题。

06  结论

虽然在安全工程领域的发展过程中，不断出现大量新的安全考虑因素，但我们认为，自动驾驶系统的诞生是一个分水岭时刻。此外，推动拟议改革的担忧不仅是理论上的，而且已经在美国的公共道路上出现了。这只是一个开始。现在是时候让安全界重新审视安全的真正含义了。

有人可能会考虑通过积极重新解释现有术语来解决我们提出的担忧。我们认为这种方法有两个问题。第一个问题是，任何以合规为中心的标准使用者都被强烈鼓励以最有利于低成本合规的方式解释定义，从而降低了任何促进重新解释的潜在教育性努力。第二个问题是，标准应该说明它的含义，而不是依赖于非规范性的、独立的解释性指导。虽然本文中提到的标准都是本着诚信的原则编写的，并且已经很好地发挥了作用，但现在是时候更新它们对安全的定义，以解决自动驾驶技术的现实经验所提出的担忧。需要明确的是，我们认为这些拟议的定义是安全界讨论的开始，而不是一个最终结论性的结果。

虽然我们使用自动驾驶汽车作为一个激动人心的例子，但类似的问题将在广泛的安全相关系统中出现，这些定义的建议可能会更广泛地表明自动驾驶系统的安全性。变化点比如是，不使用需要密切进行关注的人类驾驶员来解决诸如执行操作限制之类的问题，或者可能将他作为一个道德缓冲区，以保护系统免受设备故障的指责。另一个需要考虑的因素是用于安全的定义与用于网络安全的术语之间的关系，尤其是在信息安全故障可能危及安全的情况下。

扩大安全范围将改善所有系统，而且随着技术不断渗透到日常社会的结构中会变得越来越重要。我们的自动驾驶程度越高，越超出人类有效监督的实际能力，这些问题就越紧迫。