Coursera自动驾驶课程第4讲：Safety Assurance for Autonomous Vehicles

在上一讲《Coursera自动驾驶课程第3讲：Self-Driving Hardware and Software Architectures》中我们了解了自动驾驶汽车常用的传感器和硬件组件、软件系统。

本讲我们将学习新的模块，也是自动驾驶汽车最重要的模块之一：安全模块。

B站视频链接：https://www.bilibili.com/video/BV1WE411D74g?p=1

---

1. Safety Assurance for Self Driving

在本课程中，我们将讨论一些自动驾驶汽车安全事故。然后，我们将定义一些基本安全概念并列出一些导致自动驾驶汽车危险的常见原因。

1.1 Autonomous driving crashes

这里我们简单介绍2018年Uber自动驾驶汽车的一起安全事故。

事故发生在夜间，在一条宽阔的多车道分开的道路上。行人在一个没有标记的区域内骑着自行车穿过马路。受害人Elaine Herzberg是坦佩市的一名49岁妇女。从鸟瞰图描绘的汽车和场景，可以从图像底部看到行人从左侧进入，而车辆沿着道路行驶。

初步调查显示，有多个因素导致此事件：

• 首先，没有对安全驱动程序进行实时检查。在这种情况下，安全驾驶员注意力不集中，据说当时正在Hulu上观看视频。安全驾驶员可以做任何事情，而Uber却没有任何方法来评估驾驶员的注意力。由于自动驾驶系统的运行是一项艰巨的任务，因此，拥有一个安全的驾驶员监控系统非常重要。
• 其次，软件检测系统存在明显的混乱。在六秒钟内初步检测到撞击时，受害​​者首先被检测为未知物体，然后被错误分类为车辆，然后被错误分类为自行车。
• 最终，在撞车发生前1.3秒，沃尔沃紧急制动系统确实检测到行人，并会迅速制动以降低撞击速度，从而有可能挽救Elaine Herzberg的生命。但是，Uber在自主模式下已禁用了沃尔沃系统。

感知系统无法正确识别行人，自行车以及规划系统无法避免侦探对象（即使其类别不确定）的结合，导致自主性故障以及缺乏人为或紧急制动最终导致了死亡。从这一系列事件中我们可以看到自动驾驶系统的各个方面。感知，规划和控制都可能导致失败和崩溃，并且往往多个系统或多个决策的交互作用可能导致无法预料的后果。

---

1.2 Formal definitions

现在让我们认识一些基本的安全术语。

• Harm一词来指代对生物的物理伤害。
• Risk一词来描述事件发生的可能性以及事件可能造成的伤害的严重性。
• Safety描述为避免对生物造成不合理伤害的过程。 例如，在交通信号灯为红色时驶入交叉路口是不安全的，这会导致不合理的危险，从而损害车辆乘员以及通过交叉路口的其他车辆。
• Hazard是造成不合理伤害风险或威胁安全的潜在来源。

---

1.3 Major hazard sources

现在，我们来了解一些自动驾驶汽车中常见的危险源，大致可以分为8种：

• 机械原因，例如制动系统的错误组装导致的故障。
• 电气原因，例如汽车内部总线错误引起的故障。
• 自动驾驶的计算硬件的故障。
• 软件故障。
• 不良或嘈杂的传感器数据或不正确的感知引起的故障。
• 还有可能由于错误的规划，对危险行为选择忽视而引起的故障。
• 或者自动驾驶汽车被某些恶意实体入侵，被黑客控制。

以上就是常见的8种危险源：机械，电气，计算硬件，软件，感知，规划，驾驶任务反馈和网络安全。我们在评估整体系统安全性时，每种危害都需要使用不同的方法来评估。

---

1.4 NHTSA

美国NHTSA定义了包含十二个方面的安全框架，以构建自动驾驶的安全评估。该框架是作为建议性而非强制性框架于2017年发布的。该框架本身包含12个领域或要素。大致可以分为三方面：

• Systems engineering approach to safety
• Autonomy Design
• Testing & Crash Mitigation

1）Autonomy Design
Autonomy Design包含6个方面：

2）Testing & Crash Mitigation
Testing & Crash Mitigation包含5个方面：

NHTSA的主要目标是在不过度限制创新的情况下指导公司制造自动驾驶汽车。

---

2. Industry Methods for Safety Assurance & Testing

在本课程中，我们将讨论有关安全和测试的各种行业观点。具体来说，我们将首先分析行业中两个知名企业的安全性观点：Waymo和GM。然后，我们将讨论两种不同的评估安全性的方法：分析性与经验性。

2.1 Waymo Safety Perspective

1) Safety Levels

Waymo涵盖了NHTSA的全部12个方面，但将它们组织成五级安全。

• 首先，Waymo系统旨在在行为层面执行安全驾驶。这包括遵循交通规则的决策，可以处理ODD内的各种情况，并通过它维护车辆安全。
• 其次，Waymo确保系统具有备份和冗余。这样一来，即使发生故障，汽车也可以切换到辅助组件，以最大程度地减少故障的严重性并使车辆返回安全状态，并尽可能继续行驶。这称为功能安全。
• 接下来，Waymo强调NHTSA推荐的碰撞安全性。系统可确保在发生事故时对车内人员造成的伤害最小。
• 接下来，操作安全。这意味着其界面既实用又方便且直观。这里的重点是允许乘客对车辆进行某种程度的控制，但只能以保持系统安全的方式进行。
• 最后，Waymo促进了非碰撞安全性。这是指将对可能以某种方式与系统进行交互的人员（急救人员，机械师，硬件工程师等）的危险降至最低的系统设计。
  

---

2) Safety Processes

现在介绍安全过程。

• 首先，Waymo团队会尽可能多的识别危险情况，并针对每种情况分析可能的缓解策略，即，如何确保发生危险时车辆仍能达到安全状态。
• 然后，他们使用危害评估方法来确定更具体的安全要求。 他们使用的各种方法是对可能的安全风险进行初步分析，从动态驾驶任务的角度对自上而下进行故障树危害评估，以及从下至上评估影响的一些设计失效模式和影响分析。
• 最后，他们进行了扩展测试以确保满足安全需求。
  

---

3) Levels of testing to ensure safety

让我们来介绍一下Waymo常进行的测试，大致可以分为三类：仿真测试，闭路测试，实车测试。

• 首先，他们以每天1000万英里的里程进行仿真测试。Waymo会在挑战性场景中挖掘所有驾驶经验，并进行系统的场景模糊测试，这会随机更改其他车辆和行人的位置和速度参数，因此他们可以测试自车在所有情况下是否安全运行。
• 然后，他们进行闭路测试。涵盖了加州大学伯克利分校的一项研究确定的28种核心场景，以及Waymo添加的19种其他场景。这些情况的组织是为了避免发生四种最常见的事故情况，即追尾，交叉路口，道路偏离和变道。这些类别中的每种类别显然都有很多变体，但它们合起来占所有交通事故的84％以上。
• 最后，他们进行实车测试，这些测试经常在美国许多不同城市的街道上进行，包括在Google主校区附近的加利福尼亚山景城。在测试过程中让人们监视自动驾驶软件。

---

2.2 General Motors Safety Perspective

1) Safety

通用汽车于2016年收购了Cruise Automation，并因此在自动驾驶开发中处于领先地位。 GM非常严格地遵循NHTSA安全框架，并分别涉及12个主要领域。

通用汽车的安全策略不是试图重组或简化NHTSA指南，而是专注于其实施策略以实现所需的安全评估。通用汽车首先强调其迭代设计模型。

• 该模型首先分析场景，然后构建软件，然后模拟场景并测试其软件。最后，将他们的软件部署在现实世界的汽车上，他们不断地对需求和自动驾驶系统进行迭代改进和。
• 其次，Waymo依靠OEM来设计车辆，并且只讨论与其自动驾驶硬件有关的机械和电气危害，而GM则完全自己制造汽车，因此可以在整个自动驾驶硬件中实施具有一致质量标准的更具集成性的设计。
• 接下来，通用汽车通过全面的风险管理确保安全。他们识别并解决风险，并试图完全消除风险，而不仅仅是减轻风险。
• 最后，它们的所有系统都遵循内部定义明确的安全性，可靠性等标准。他们在汽车行业开发车辆方面拥有多年的经验，因此开发了广泛的安全流程。

---

2) Safety Processes

·安全过程·涉及三种类型的分析。

• 首先，他们通过故障树方法进行演绎分析，并找出可能存在故障的组件并加以解决。
• 接下来，他们通过·FMEA设计·进行归纳分析。因此，他们会对设计方案进行故障模式和效果分析，并尝试从下至上确保安全性。
• 最后，他们使用危害和可操作性研究进行探索性分析，并找出系统何时可能无法按预期工作。
  

让我们谈谈安全阈。所有通用汽车都必须至少遵守两个关键的安全阈值。

• 首先，GM为不同组件定义了一套清晰的故障保险柜，备份系统和冗余，以使系统即使在发生故障后仍可以继续工作。
• 其次，组件必须通过SOTIF评估。通过此评估，我们确保在已知和未知场景中都评估所有关键功能。

最后，通用汽车遵循严格的测试机制，包括性能测试，需求验证，故障注入，侵入式测试，耐久性测试以及基于仿真的测试。

---

3) Data driven safety

让我们讨论可用于评估自动驾驶系统安全性的各种方法。我们有两种可能的方法：分析或数据驱动的安全评估。下面是二者的定义：

---

3. Safety Frameworks for Self Driving

本课中，首先我们将讨论一些流行的安全框架。包括故障树，故障模式和影响分析（FMEA），以及危害和可操作性分析（HAZOP）。 然后，我们将讨论功能安全以及预期功能安全（SOTIF）。

3.1 Generic Safety Frameworks

1）Fault Trees

故障树是自上而下的流程。故障树中的最高节点是根事件或最高事件。故障树中的中间节点是逻辑门，它们定义了根事件的可能原因。通过使用布尔逻辑来分析故障树。

让我们分析一个简单的示例，车祸为根本事件。发生车祸的原因可以分为软件故障或硬件故障。粗略地讲，硬件故障可能是由于制造缺陷或材料缺陷造成的。同样，软件故障可能是由于代码故障或某些网络安全问题所致。我们还可以继续进行软件子系统和这些子系统内的特定计算，从而在每个连续分支处加深故障树深度。最终，得出特定的故障率，我们可以为这些故障率分配每小时或每英里运行的发生概率。

现在，我们到达了故障树的叶子节点。通过使用逻辑门结构，我们可以在评估各个叶节点故障率的情况下显式计算总体故障率的统计数据。当事件遵循集合论时，用于向上传播这些概率的操作将与概率规则相同。例如，对于独立事件，OR和AND概率将是子节点概率的总和或乘积。

---

2）FMEA

现在让我们看一下FMEA，它代表故障模式和影响分析。FMEA是一个自下而上的过程，它查看各个原因并确定发生的所有可能的影响。故障模式是整个系统的特定组件可能导致系统故障的模式。效果分析是指分析这些模式故障可能导致的所有效果。

我们来谈谈FMEA背后的构想。按优先级对故障模式进行分类。因此，我们提出这些问题：影响有多严重，这些故障多久发生一次，检测这些故障有多容易？然后，我们使用优先级值对所有故障进行量化，然后首先开始处理具有最高优先级的故障。

---

FMEA步骤如下：

• 首先与现场专家进行讨论，创建FMEA表。
• 然后，列出所有故障可能性。
• 然后，针对每种失败可能性，确定可能的后果，并将每种后果的严重性等级指定为1到10，其中10为最严重。
• 对于每种结果，确定可能的根本原因，对于每种路线原因，我们在1到10之间分配另一个数字，以表示此原因发生的频率。
• 然后，我们评估整体模式检测的可能性。
• 最后，计算出一个称为风险优先级数字的最终数字，该数字是严重性，发生概率和检测概率的乘积。该值越高，优先级越高。
• 

---

3）HAZOP

与FMEA相比，HAZOP更像是一个定性过程，在FMEA中，我们试图定量地定义风险。 在HAZOP中，主要目的是针对可能发生的一系列潜在危险进行有效的头脑风暴。

---

3.2 Automotive Safety Frameworks

1）Functional Safety

现在，让我们讨论用于汽车发的现有安全框架，这些框架通常用于评估自动驾驶汽车的硬件和软件故障。特别地，让我们讨论ISO 26262中描述的功能安全方法以及在ISO/PAR 21448.1中定义的预期功能安全。

功能安全（FUSA）指的是不存在因汽车硬件和软件故障而导致的故障行为，或因其预期设计而引起的意外行为带来的不合理风险。ISO26262标准定义了四个汽车安全完整性等级（ASIL）。 ASIL-D最严格，ASIL-A最低。每个级别都有与之相关的特定开发要求，认证必须遵守这些要求。

功能安全过程遵循V形流程。从需求规范的左上角开始，然后分析危害和风险，并进行功能实施。然后，我们爬到正确的分支以确认已达到设计目标。我们从低层验证开始，例如软件单元测试，然后通过仿真，测试跟踪，操作和道路测试进行子系统和完整系统验证。

---

2）Safety of Intended Functionality

最后，我们简要地探讨一下在ISO/PAS 21448.1文档中正式定义的预期功能安全（SOTIF）。 SOTIF关注与系统性能限制和可预见的系统误用相关的故障原因。

当前的SOTIF标准将自动化级别定为零，一和二。它还指出，其方法可以应用于三级，四级和五级，但是可能需要其他措施。

SOTIF可以看作是功能安全流程的扩展，专门针对自动驾驶功能的挑战而设计。因此，它遵循几乎相同的V形开发理念，但具有增强的组件。 SOTIF还使用HARA来识别由于性能限制和滥用引起的危害。然后执行类似的设计，单元测试以及验证和确认序列，以确认已满足安全要求。

总结，让我们总结本讲学到的知识：

• 我们首先讨论了为什么安全性很重要，特别是广泛的不同故障如何导致自动驾驶事故。
• 然后，我们正式定义了安全概念，并讨论了NHTSA对自动驾驶汽车的安全建议。
• 然后，我们讨论了Waymo和GM如何考虑自动驾驶安全性。 然后我们描述了分析和数据驱动的方法来演示安全性。
• 最后，我们讨论了常见的安全评估框架。 包括故障树，故障模式和影响分析，功能安全性和预期功能的安全。