Self-Driving Cars 专项课程-Safety for Self-Driving Cars

Lesson 1: Safety Assurance for Self-Driving Vehicles

欢迎来到本课程的第三周。 本周, 我们将深入探讨基础知识关于将安全性融入自动驾驶汽车设计的。本单元中，我们将讨论最近的一些自动驾驶车的碰撞报告，然后我们会正式定义自动驾驶车的安全概念, 并讨论最常见的危险源。 我们将讨论一些行业对安全性的看法，最后， 我们将通过讨论安全系统设计中使用的一些常见框架来总结。 

在本课中, 我们将讨论 2017年和2018年首次发生的自动驾驶车碰撞事件。 然后，我们将定义一些基本的安全概念并 列出一些自动驾驶车危险的最常见原因， 并讨论低水平和高水平的安全要求。 应该指出，本单元中的材料 大多取公布的指南, 由国际标准组织ISO发布的。 您可以在网上找到这些框架的更全面版本。 

 

让我们首先讨论一些迄今为止更为突出的自动驾驶汽车故障。2016年3月，一辆自动驾驶的谷歌车Waymo，撞上了一辆公共汽车的一侧, 当它试图从后面的障碍物中撤出时。一辆公共汽车正从后面驶来, 目的是将谷歌车停在车道上，这是在其车道的右侧准备转弯。谷歌汽车软件认为, 这辆公交车不会试图通过它, 因为它与下一车道的汽车之间的差距太窄。 事实证明， 公交车经常会在较小的缝隙中行驶 比谷歌预期小的缝隙，这也导致了这次的碰撞。当谷歌汽车可能会对公交车位置的新测量做出反应时，但为时已晚。这只是一个例子, 说明它是多么困难在事情发生之前预测所有其他车辆行动。 

 一年后，一辆优步自动驾驶车在另一辆车造成轻微碰撞时反应过度，最终翻车。 由于车辆的动态模型不承担来自其他车辆的显着干扰力， 因此控制器可能没有针对这种情况进行测试并且反应过度。 此次碰撞突显了集成 到控制系统中的稳健性以及涵盖尽可能多的可预见事件的探索性测试的需求。 

 2017年底,一辆GMCruise雪佛兰Bolt撞倒了一名摩托车手，在中止车道变换后。 在Bolt启动机动之后， 它希望进入进去的间隙迅速关闭， 由于相邻车道中的制动引导车辆。那个正打算变道的摩托车手，在Bolt旁边向前移动，并阻挡了回程机动。Bolt 陷入了进退两难的境地;与摩托车相撞或撞上两辆车在相邻的车道上。目前尚不清楚在这里作出具体决定选择一个或另一个结果，诉讼也掩盖了案件的细节。然而，由于其他agent也会预测自动驾驶车的动作，因此在许多情况下评估正确的行动是非常具有挑战性的。在可能的情况下，并道可能是一种更激进的驾驶风格或者稍有延迟的中指可能就有足够时间来避免撞击到摩托车手。这种紧密的决策互动仍然是自动驾驶车的一大挑战。 

最后, 我们应该谈谈 Uber 事故, 那场2018年初导致行人死亡的事故。 在亚利桑那州坦佩市， 优步当时有一个广泛的测试计划， 与安全司机在监控着自动软件。 事故发生在一条宽阔的多车道分道路上， 当晚一名行人在一个没有标记的地区骑自行车穿过马路。 受害者Elaine Herzberg 是一名来自坦佩的49岁女子。 

这是从鸟瞰图描绘的汽车和场景。 可以看到从图像左侧进入的行人 和从图像底部沿着道路行驶的车辆。 初步调查显示, 是由于多个失灵导致这次的事故。 

让我们来看看促成的不同的因素。首先，安全司机没有实时进行查看。那个时候，安驶员不专心，据称当时正在观看Hulu。 安全员在车上可能什么都可以做，优步在车辆上没有任何方法来评估安全员的注意力。因为观看自动驾驶系统操作是一项难以集中精力的任务，所以拥有安全驾驶员监控系统非常重要。 其次, 软件检测系统存在明显的混乱。在最初检测到6秒撞击时，受害者首先被识别为未知物体，然后被误识别为车辆，然后被误识别为自行车。最后，无人驾驶软件做出的决定是忽略检测，可能是因为认为检测太不可靠。感知并不完美, 切换分类不应当导致车辆完全忽略这样的物体。最后，在发生碰撞前1.3秒， 沃尔沃紧急制动系统确实可以检测到行人，并且会迅速施加制动以降低撞击速度，从而可能挽救Elaine Herzberg的生命。然而, 那是不安全的, 在测试期间让多个防撞系统同时运行。因此优步在无人驾驶模式下禁用了沃尔沃系统。最终，自动驾驶车没有对行人的路径作出反应，并且疏忽的安全员无法快速反应以避免撞击。 这次事故由以下组成： 感知系统无法正确识别行人，用自行车和规划系统来避免侦探物体, 即便类别是不确定的, 这样导致了这次失败，同时，缺乏人或紧急制动备用最终导致了死亡。

我们可以从这一系列事件中看到 自动驾驶系统的各个方面： 感知、规划和控制都可能导致系统失败和撞击，而且多个系统或多个决策的交互往往会导致意外后果。事实上, 无人驾驶系统还有很多可能失败的方式。 很明显, 我们需要严格和详尽的安全方法, 行业和监管机构正在正面应对安全挑战。 好。现在, 我们对安全评估的挑战有了认识,让我们正式定义一些基本的安全术语。 

我们将使用术语, 

“Harm”定义对生物的物理伤害， 

"Risk" 一词来描述事件发生的概率, 以及事件的严重程度， 可能造成的伤害。 

 

我们现在可以将安全描述为避免对生物造成伤害的不合理风险的过程。例如, 当交通信号灯为红色时驶入交叉路口将是不安全的，因为这会导致不合理的风险， 对车辆和通过交叉路口的其他车辆。最后, 危险是潜在根源，不合理的伤害风险或安全威胁的。因此，如果我的系统软件有可能导致事故的错误，那么软件错误将是一个危险。 

 

现在，您认为自动车辆危害最常见的来源是什么？危险可能是机械的，因此制动系统的错误组装可能导致过早失效。危险可以是电气的，因此有缺陷的内部布线会导致指示灯不亮。危险也可能是计算用于自动驾驶的硬件芯片的失败。如前所述，它们可能是由于无人驾驶软件错误和bug造成的。 危险也可以由传感器数据不良或嘈杂或感知不准确引起的。 危险也会发生，由于不正确的规划和决策，无意中选择危险操作也可能导致危险，因为特定场景的行为选择设计不正确。也有可能是对安全员支援， 提供足够的警告以恢复其责任，或者自动驾驶车可能被某些恶意实体攻击。 这些都是主要类别的危害, 这些危害都是经常考虑：机械、电气、计算硬件、软件、感知、规划、驾驶任务支援和网络安全。 

 

在评估整体系统安全性时，每种危险都需要不同的方法。我们将在后续视频中详细介绍如何处理这些类别。 既然我们知道安全所涉及的基本术语，那么让我们考虑以下问题。我们如何确保我们的自动驾驶车真正安全呢？也就是说，我们如何处理复杂的驾驶任务和可能发生的许多危险，并为完整的自动驾驶系统定义安全评估框架？在美国，国家公路运输安全管理局或国家公路交通安全管理局已经制定了一个由十二部分组成的安全框架，用于构建自动驾驶的安全评估。正如我们将在本单元的下一个视频中看到的那样，该框架只是一个起点，不同的方法，通过结合多种现有的放你发和标准方法已经在行业中已经出现了。让我们首先讨论NHTSA的安全建议。这个框架是作为建议发布的, 而非强制性的。框架在2017年发布。 框架本身由12个领域或 或要素组成，任何自动驾驶公司应该关注或者更确切地说， 鼓励关注。 

        首先, 应采用安全的系统设计方法, 这实际上渗透到了整个框架文件中。精心策划和控制的软件开发过程至关重要，以及现有的 SAE 和 ISO 标准在汽车、 航空航天和其他相关行业应在相关情况下适用。 对于剩余的11个领域， 我们可以将它们大致分成两类。 自治设计，这需要某些组件 被包括在自治软件堆栈中并加以考虑, 测试和缓解碰撞, 其中包括测试自治功能和减少故障负面影响的方法, 以及从中学习。

在自治设计类别中，我们看到了一些我们已经熟悉的组件。 NHTSA鼓励明确定义的ODD（设计适用范围），  让设计人员清楚地认识到这个系统的缺陷和局限性, 并且可以评估哪些方案是支持的并且是安全的，在测试或部署之前。 接下来，它激励经过充分测试的物体和事件检测和响应系统， 这对于感知和避免碰撞至关重要。 然后，它激励汽车具有 可靠和方便的后退机制， 通过该机制警告驾驶员或使汽车自动安全。 开发这种机制至关重要， 记住驾驶员可能会疏忽。 因此，应该考虑如何将系统置于最小风险状态，如果发生这种情况。 还应该设计驱动系统，以便所有联邦级别，州级别和当地交通法规能够在ODD内遵循和遵守。 接下来，该框架鼓励设计人员考虑网络安全威胁， 以及如何保护驱动系统免受恶意代理的攻击。最后，应该对人机界面（HMI）进行一些思考。 因此，汽车应该能够传达机器的状态在任何时间点，对乘客或驾驶员进行。可以显示的状态信息的重要示例是所有传感器是否可操作，当前运动规划是什么，环境中的哪些对象正在影响我们的驾驶行为等等。 

我们现在转向测试和碰撞缓冲区。 首先，NHTSA建议在为公众开展任何服务之前需要进行强有力的广泛测试计划。这种测试可以依赖三个共同的支柱：仿真模拟，近距离测试以及公共道路驾驶。接下来，应该仔细考虑减轻碰撞事件中发生的伤害或损坏程度的方法。碰撞仍然是公共道路驾驶和无人驾驶的考虑，最大限度地减少碰撞能量，要超过乘客安全标准，安全气囊和碰撞价值应该是正常的。接下来，应该支持碰撞后的行为。例如，汽车必须迅速恢复到安全状态，停止燃油泵燃油。发出警报等等。此外，应该有自动数据记录功能或黑匣子记录器。这些碰撞数据的分析和设计系统是有助于将来避免发生特定类型的碰撞，并解决出错的问题，以及在事件发生时出错的地方。 最后，应该有明确地对消费者进行教育和培训。因此，在为消费者驾驶员和乘客进行测试和培训期间，驾驶员的课程可以更好地理解部署的无人驾驶系统的功能和限制。最后一步对于确保我们对自动化的自然过度自信至关重要，这不会导致早期采用者引入不必要的危害。

 请记住，这些是任何公司应该处理的建议区域。尚未强制要求。 NHTSA的主要目标是指导公司 在不过度限制创新的情况下制造自动驾驶汽车。 人们预先选择技术。 随着市场的进入开始出现，可能会出现更加明确的安全评估要求。 这条线的斜率 这个导数是这条线的斜率 让我们总结一下在这段视频中，我们讨论了无人驾驶行业首次发生的一些事故，并揭示了自动化软件失败的多种方式。然后，我们正式定义了危害，风险，伤害 和安全，并列出了自动驾驶车辆危险的主要来源。然后，我们看了NHTSA安全框架。

 

 Supplementary Reading: Safety Assurance for Self-Driving Vehicles

• Check out Dr. Krzysztof Czarnecki'spaper on WISE Drive: Requirements Analysis Framework for Automated Driving Systems. You will watch an interview with Dr. Czarnecki's later in this Module.

• Learn more about the non-mandatory safety guidelines for autonomous cars in the NHTSA - Automated Driving Systems: A Vision for Safety 2.0 report.

Lesson 2: Industry Methods for Safety Assurance and Testing

欢迎来到本周的第二节课。

在本课中，我们将讨论有关安全和测试的各种行业观点。

具体来说，我们先分析

业内两大巨头的安全观点：Waymo 和 GM。

然后我们将讨论两种不同的评估方法

安全性：分析与经验。

        让我们开始。 正如我们在上一个视频中看到的， NHTSA 要求每个自动驾驶开发者， 应制定和描述全面的安全策略 涵盖了其指导文件中包含的 12 个概念。 迄今为止，Waymo 和通用汽车已经出现了两份重要的报告， 我们将使用这两者作为我们讨论行业安全方法的基础。 Waymo 安全报告于 2017 年发布， 并且对如何组织有很多深刻的见解 自动驾驶汽车的综合安全策略。 Waymo 涵盖了 NHTSA 的所有 12 个概念， 但将它们组织成五级安全方法。

        首先，Waymo 系统旨在在行为层面执行安全驾驶。 这包括遵循交通规则的决策， 可以处理 ODD 内的各种场景， 并通过它维护车辆安全。 其次，Waymo 确保系统有备份和冗余。 这样即使发生故障或故障， 汽车可以切换到辅助组件或备份过程以 最大限度地减少故障的严重性并使车辆恢复到安全状态， 如果可能，继续驾驶。 这称为功能安全。 接下来，Waymo 强调 NHTSA 推荐的碰撞安全。 它设计的系统可确保将损坏降至最低 发生碰撞时车内人员。 接下来，它试图确保操作安全。 因此，这意味着它的界面是可用的、方便的和直观的。 这里的重点是让乘客对车辆有一定程度的控制， 但仅限于维护系统安全的方式。 最后，Waymo 促进了非碰撞安全。 这是指最小化的系统设计 对可能以某种方式与系统交互的人的危险， 急救人员、机械师、硬件工程师等。 这五个支柱构成了 Waymo 的安全设计系统， 并导致一个广泛的需求定义系统，设计迭代， 和测试以确保每个组件都满足系统的目标。 该过程使用了来自 现有域，我们将在下一个视频中详细介绍这些工具。

一开始，Waymo 团队确定了尽可能多的危险场景 尽可能并分析每个可能的缓解策略， 即如何保证车辆能够 发生危险时仍能达到安全状态。 然后，他们使用危害评估方法来确定更具体的安全要求。 他们使用的各种方法都是对可能存在的安全风险进行初步分析， 故障树危害评估 在动态驾驶任务方面自上而下， 以及一些自下而上的设计失效模式和影响分析 评估效果 对系统整体功能的小子系统故障。 最后，他们执行大量测试以确保满足要求。

 让我们讨论一下 Waymo 的测试程序以下专门评估其软件，因为它是最公开可见和有据可查的程序。首先，他们测试所有软件更改每天模拟 1000 万英里的模拟量。这代表了持续运行的巨大计算工作量确认对系统安全要求的预期改进。为此，他们挖掘了所有在路上的经验来挑战场景并执行系统的场景模糊测试，这会改变位置和其他车辆和行人的速度参数随机，因此他们可以测试自我车辆是否在所有车辆中安全运行。这种方法对于寻找困难的边缘情况特别有用，例如，难以解决合并或交叉路口的时间间隔。

 然后他们进行封闭式测试，他们在私人轨道上测试他们的软件。它们涵盖了加州大学伯克利分校研究确定的 28 个核心场景，以及 Waymo 添加的 19 个附加场景。这些场景是围绕避免追尾四种最常见的事故场景，交叉路口、道路偏离和车道变更。这些类别中的每一个显然都有很多变体，但它们加起来占所有事故的 84% 以上。

 最后，他们进行真实世界的测试，这些测试是经常出现在美国许多不同城市的街道上，包括位于 Google 主校区附近的加利福尼亚山景城。该测试使他们能够识别越来越多的不寻常的案件主要依靠关于动态驾驶任务回退策略让人类在测试期间监控自治软件。这些测试策略的组合绝非 Waymo 独有，但已成为事实上的标准，因为它提供固定投资的最大灵活性和反馈，将每种测试方法集中在它最擅长的方面，模拟操纵使它们变得困难的场景，封闭课程测试确认具体收益寻找更具挑战性的场景的安全性能和实际测试，并提高公众对该技术的信心。

 

 好的。现在让我们把注意力转向通用汽车的安全理念，2016 年收购 Cruise Automation 并推动因此，它在自动驾驶开发方面处于领先地位。

        GM 战略非常遵循 NHTSA 安全框架密切关注 12 个主要领域中的每一个。通用汽车的安全策略并没有试图重组或简化 NHTSA 指南，而是专注于其实现所需安全评估的实施策略。首先，通用汽车强调了他们的迭代设计模型，其中第一个分析场景，然后构建软件，然后模拟场景，并测试他们的软件。最后，将他们的软件部署在现实世界的汽车上，他们不断添加改进和改进需求和自治系统都是迭代的。

 其次，Waymo 依靠 OEM 来设计它的车辆，只讨论与其自主硬件相关的机械和电气危险，通用汽车完全自己制造汽车，因此可以强制执行更集成的设计与整个自动驾驶硬件的质量标准一致。其次，通用汽车通过全面的风险管理方案确保安全。他们识别和解决风险并尝试完全消除它们，而不仅仅是减轻它们。最后，他们所有的系统都遵循内部明确定义的安全标准，可靠性、安全性等。他们在汽车行业拥有多年​​的车辆开发经验，并因此开发了广泛的安全流程。

他们的安全过程涉及三种类型的分析。 首先，他们通过以下方式进行演绎分析 故障树法和查明 可能有故障的组件并解决它们。 接下来，他们通过设计 FMEA 进行归纳分析。 因此，他们对他们的设计方案进行故障模式和影响分析， 并尽量自下而上确保安全。 最后，他们采用危害和可操作性研究来进行探索性分析， 并找出系统何时可能无法按预期工作。 现在，这听起来可能很熟悉，事实上， 这些与 Waymo 描述的分析支柱相同。 在下一个视频中，我们将详细介绍这些方法的实际工作原理。

让我们谈谈安全阈值和通用汽车。 所有通用汽车至少必须遵循两个关键的安全阈值。 首先，通用汽车定义了一套明确的故障保险、备份系统、 和不同组件的冗余，所以 即使发生故障，系统仍能继续工作。 二、组件必须通过 我们将在下一个视频中更详细地讨论 SOTIF 评估。 通过此评估，我们确保 所有关键功能都在已知和未知场景中进行评估。 最后，通用汽车遵循由性能测试组成的严格测试机制， 需求验证，故障注入， 侵入式测试、耐久性测试和基于模拟的测试。 这两家公司都严格遵守安全标准，并且 因此，很好的例子说明了如何切实有效地确保安全。 因此，我们现在对工业中如何进行安全评估有了更清晰的认识， 但我们仍然有这个问题：真的有可能吗？ 真正准确评估自动驾驶汽车是否安全？ 或者至少比人类司机更安全？

 让我们讨论一下可以采用的各种方法用于评估自动驾驶系统的安全性。我们有两种可能的方法：分析或数据驱动的安全评估。通过分析安全性评估，我们的意思是系统可以被分析来定义可量化的安全性能或基于对危险和情景的严格评估的故障率。如果可以通过分析确定整体系统故障率，它可以为哪些方面提供强有力的指导该系统是整体安全的最大贡献者。一个很好的例子是航天飞机计划，其初步估计分析失败率为 100,000 次飞行中的 1 次。然而节目结束后，一项法医研究表明，早期的航天飞机计划飞行的失败率接近十分之一，到节目结束时，这只会发展到百分之一。令人惊奇的是，这种分析甚至可以用于这样一个复杂的系统，考虑到所有进入航天飞机发射的数千个子系统，以及所有可能影响这些系统运行的数百万个变量。这种详细的分析也适用于自动驾驶汽车，但可能会更复杂，因为车辆的无限多种情况将自己局限在其中。最后，分析方法只能为自动驾驶系统的安全性能提供指导，他们的结果需要通过经验来验证。为了评估经验，我们使用数据驱动测试。这是我们确信的概念该系统是安全的，因为它已经证明，使用特定版本的软件，它可以在一组上达到预期的故障率包含在运营设计领域的道路和场景。在自驾的情况下，这些期望的故障率可以与人类水平的驾驶表现联系起来，我们希望将事故减少 10 倍或 100 倍于当今驾驶员的表现。

那么，数据说明了什么？ 自动驾驶汽车真的更安全吗？ 首先，按照人类的标准，知道驾驶仍然是危险的。 2015 年的一份报告得出的结论是，在所有驾驶致死事故中， 其中大约 90% 是由于人为错误造成的， 有时由于缺乏判断力， 有时是由于人类感知的失败，等等。 但人类也非常擅长驾驶，事实上， 整个驾驶环境都经过精心设计 基于人类的感知和计划能力。 在美国， 每行驶 1.46 亿公里，就有大约 1 人死亡。 每行驶 210 万公里就有 1 人受伤， 大约每 400,000 公里发生一次碰撞。 最后一个数字只是估计的，因为实际上没有报告大多数较小的碰撞。 事实上，自动驾驶可能对 更多地了解这些统计数据 综合报告和重建将 可以使用我们可用的其他传感器。

 现在，让我们考虑初步的自动驾驶车辆统计数据，更具体地说，脱离率由在加利福尼亚测试的所有自动驾驶车辆发布。脱离是当这个自治软件请求驾驶员接管控制或安全驾驶员觉得有必要进行干预。获得真正的崩溃统计数据是可以理解的具有挑战性的整个车队都在接受测试，因为这些都是敏感的统计数据。幸运的是，加州的测试伴随着一些有用的报告要求。2017 年，Waymo 在加州行驶了 56.3 万公里，经历了 63 次脱离接触每 9,000 公里大约有一次脱离接触。GM Cruise 在加州行驶了 210,000 公里大约每 2,000 公里有 105 次脱离接触。两者都在全年迅速改善，达到每 12,500 公里一次的脱离接触率，每年最后三个月分别为每 8,300 公里。这些是很难与人类表现相关的数字，但大致意味着一个典型的通勤者只需要对于自治系统的失败，每年进行一次干预。这是巨大的进步，但距离人类每年在数万亿英里内实现的碰撞之间的距离为 400,000 公里。按频率顺序排列 63 次 Waymo 脱离的主要原因，是不需要的车辆操纵，感知差异，硬件问题，软件问题，行为预测，最后是一个鲁莽的道路使用者的案例。很明显，感知的核心任务，预测和行为规划仍然是具有挑战性的问题，还有很多工作要做。

最后，关于统计意义。

从今天的舰队观察到的表现令人印象深刻，

但它们在多大程度上代表了与人类能力的准确比较？

我们真的需要开车到多少英里

证明自动驾驶汽车比人类驾驶员更安全，

特别是在死亡人数方面？

在补充材料中，

我们已经包含了指向报告的链接

兰德公司试图解决这个问题，

数字令人吃惊。

由于死亡事件是如此罕见，而且考虑到的因素很多，

报告指出，如果

纯粹的道路测试用于验证自动驾驶系统的安全案例。

一个由 100 辆汽车组成的车队 24/7 行驶至少需要 400 年，

等待的时间很长。

 正是出于这个原因，我们看到了如此多方面的安全方法，每家公司都在扩大车队增加在道路上使用自主系统获得的经验。总而言之，在这个视频中，我们研究了自动驾驶安全评估的两个行业观点，Waymo 和 GM，发现了很多借鉴其他行业的方法。我们讨论了当前的离职率和道路测试要求证明比人类表现更好。

Lesson 2 Supplementary Reading: Industry Methods for Safety Assurance and Testing

Supplementary Reading: Industry Methods for Safety Assurance and Testing

Read more about how companies approach safety assurance and testing:

• Waymo Safety Report

• GM Safety Report, 2018

• Ford Safety Report, 2018

• Uber Safety Report, 2018

• NHTSA Crash Statistics, 2015

• Autonomoose: Towards All Weather Driving in Canada, Steven’s presentation, University of Toronto & University of Waterloo (June 15, 2018).

2018_06 Autonomoose Driving in Canada.pdf

PDF File

• How Many Miles of Driving Would It Take to Demonstrate Autonomous Vehicle Reliability?; Rand Corporation Report, 2016

Lesson 3: Safety Frameworks for Self-Driving

欢迎收看本周的最终视频。 在本视频中，我们将讨论一些流行的安全框架， 其中一些我们在上一课中遇到过。 更具体地说，我们将描述一些通用的， 分析框架，包括故障树， 失效模式和影响分析或 FMEA， 危害和可操作性分析或 HAZOP。 然后我们将重点放在 汽车和自主安全框架并讨论功能安全或 FUSA， 和预期功能的安全性，或 SOTIF。

 我们稍后会在视频中定义这些术语。让我们开始。我们将从故障树分析开始。故障树可以作为初步的分析框架，并且可以稳步扩展以包含尽可能多的必要细节。故障树是自上而下的流，我们在其中分析要避免的系统可能出现的故障，然后确定它可以使用的所有方法发生在系统较低级别的事件和故障中。故障树中的顶部节点是根或顶部事件。故障树中的中间节点是逻辑门，定义了根本事件的可能原因。分解继续到详细程度可以定义此类事件的概率。然后可以通过组合来分析故障树使用布尔逻辑定律的概率。评估总体概率根本原因事件和最有助于其发生的原因。让我们考虑一个简单的例子，并将车祸作为我们的根本事件。车祸的原因可能会被分解无论是软件故障还是硬件故障，在我们提供的许多其他可能性中在我们之前的视频中被描述为危险等级。非常粗略地说，硬件故障可能是因为例如，制造缺陷或材料缺陷。同样，软件错误可能是由感知代码故障或某些网络安全问题，比如说，如果我们被黑了。从那里，我们可以继续进行软件子系统和这些子系统中的特定计算在每个连续的分支处加深树。

 最终，我们将得出我们可以达到的特定故障率分配每小时或每英里运行的发生概率。我们现在已经到达故障树的叶子节点。然后使用逻辑门结构，我们可以显式计算给出了对单个叶节点故障率的评估的总体故障率。用于向上传播这些概率的操作将与事件遵循集合论时的概率规则相同。因此，例如，对于独立事件，OR 和 AND 概率将是子节点概率的总和或乘积。这是故障树背后的一般思想，被称为概率故障树，当概率包含在叶节点时。概率故障树是一种自上而下的安全方法已广泛应用于核工业和航空航天工业，并且可以类似地应用于自动驾驶。挑战在于建立一个综合树和错误地识别叶节点事件的概率。

现在让我们看看 FMEA， 代表失效模式和影响分析。 鉴于故障树从系统故障流向其所有可能的原因， FMEA 是一个自下而上的过程，它着眼于 个人原因并确定所有可能发生的影响。 通常，FTA 和 FMEA 一起用于评估安全关键系统。 失效模式是模式或方式，其中 整个系统的特定组件可能导致系统发生故障。 效果分析是指分析所有 这些模式故障可能导致的可能影响。 通常，效果分析旨在确定 那些导致最严重故障的模式， 然后可以导致改进的设计增加 更多的冗余或更高的系统可靠性。

让我们来看看 FMEA 背后的大想法。 目标是按优先级对故障模式进行分类。

所以，我们会问这样的问题， 后果有多严重， 这些故障发生的频率有多高， 检测这些故障有多容易？ 然后我们使用优先级值量化所有失败， 然后我们首先开始处理具有最高优先级的故障。

 以下是步骤。目标是构建所有可能的危险情况的表格，我们开始，首先与现场专家讨论在表中我们想要的详细程度识别流程。然后，我们质疑系统的目的并列出所有失败的可能性。那么对于每一个失败的可能性，我们确定可能的后果并分配每个后果的严重性等级在 1 到 10 之间，10 是最严重的。对于每个后果，我们确定可能的根本原因，对于每个路径原因，我们在 1 到 10 之间分配另一个数字，表示此原因发生的频率。然后，我们确定了操作员可以检测到故障模式的所有方式，维护、检查或故障检测系统。我们之前评估了整体模式检测的可能性它会产生效果并从 1-10 分配另一个分数，1个保证被检测到，10个不能被检测到。最后，我们计算一个称为风险优先级的最终数字，这是严重程度的产物，发生和检测。这个值越高，优先级越高。

最终，我们通过修改来解决最有问题的故障模式 我们实施该系统，直到我们将风险降低到可接受的水平。 也可以执行 FMEA 故障树分析中的实际故障概率， 并根据以下方面定义可接受的风险水平 在固定的运营期间发生关键事件的可能性。 该方法不仅改变了 完成整个分析的数量和复杂性。

让我们坚持简单的评分方法，让 FMEA 过程通过一个简短的例子更加具体。 考虑车辆行驶的特定故障 由于道路建设而出现在其测试区域的砾石斑块上， 从而导致控制器不稳定。 最坏的情况可能是物理崩溃， 这将是严重程度 10。 它还可能导致驾驶员不适， 或有惊无险， 但这些将是较低严重性的事件。 此事件可能会在城市环境中定期发生 任何特定类型的构造发生的地方。 所以，有点可能。 假设我们能够评估出现次数为四。 同样，我们可以将当前分数分配给其他效果。 让我们假设这个问题目前无法检测到，因为 路面纹理不活跃 在我们的自治软件运行期间进行监控。 因此，所有这些影响的可检测性都排在第 10 位。 那么，崩溃的风险优先级数将是 10 乘以 4 乘以 10，即 400。

同样，我们也可以有其他故障模式。 比方说，优先级数为 100 的符号感知失败， 优先级数为 300 的 GPS 同步失败， 也可能是优先级为 150 的车辆运动预测失败。 因此，我们将着手解决这些失败 通过专注于在砾石上行驶而不是 GPS 故障来实施， 比运动预测，最后是符号感知。

 这就是 FMEA 背后的一般框架。FMEA 是一种风险评估理念，由军事和航空航天工业，后来又带到了汽车工业。它提供了一种真正结构化的方法来量化风险并进行处理。先说最重要的。最后，经常出现的 FMEA 的一个常见变体，是危害和可操作性研究或 HAZOP。与 FMEA 相比，HAZOP 更像是一个定性过程，我们寻求定量地定义风险。因此，在 HAZOP 中，主要目的是有效地对可能出现的一系列危险进行集思广益。对于复杂的过程，可以评估风险无需为发生分配特定值，严重性和检测，这可能很难做到。HAZOP 通常在设计过程的早期用于指导概念设计阶段。HAZOP 中的关键补充是，引导词用于引导应用于每个系统要求的头脑风暴。这些引导词包括诸如不、更多、更少、早期、晚期并导致可能不考虑的故障模式。因此，可以将 HAZOP 视为一种简化的持续 FMEA 头脑风暴方法。

 现在让我们关注更具体的安全类型并讨论用于汽车和低级自主功能开发的现有安全框架，这通常用于评估自动驾驶汽车的硬件和软件故障。特别是，让我们讨论功能安全方法在 ISO 26262 中描述和安全在 ISO 上延伸到的预期功能方法26262 并在 ISOPAR 21448.1 中定义。我们将无法详细介绍这两个过程，但如果您想了解更多信息，我已经包含了补充材料的链接。功能安全或 FUSA，是不存在不合理的风险由汽车硬件和软件故障引起的故障行为，或与其预期设计相关的意外行为。ISO 262 标准定义了功能安全术语和机动车辆内电气和电子系统的活动。因此，仅解决硬件和软件危害这可能会影响自动驾驶汽车的安全。该标准定义了四个汽车安全完整性等级或 ASIL。ASIL D 是最严格的，A 是最不严格的。每个级别都有与之相关的特定开发要求，必须遵守才能获得认证。

功能安全流程遵循 V 型流程。 从左上角的需求规范开始，然后进行分析 危害和风险并着手实施功能。 然后我们爬上正确的分支以确认设计目标已经实现。 我们从低级验证开始，例如软件单元测试， 然后通过仿真进行子系统和全系统验证， 测试轨道、操作和道路测试。 当我们沿着左边的V下降时， 高层次的需求变成低层次的实现。 当我们爬上右边的 V 形时， 我们在之前确认每个低级函数实现 将它们结合起来以确认安全操作的系统要求。 最后一步是总结功能安全评估， 评估剩余风险和 确定我们的系统是否已达到可接受的安全水平。 在功能安全 V 开始时， 我们使用 HARA 或危害和风险评估。 在HARA，我们识别和分类 危险事件，并规定避免不合理风险的要求。 这个过程推动了所有系统的开发和测试。 为此，我们首先确定可能的硬件和软件 可能影响汽车安全的故障或故以及意外功能。 这是使用 FMEA 或 HAZOP 的地方 功能安全框架，并导致我们系统的一系列特定危害。 然后，我们定义了一系列场景或情况， 系统必须在我们的 ODD 上绘图才能创建此列表。 接下来，我们将危险和情况组合成危险事件，描述预期的损害， 并确定风险参数， 计算数值 每种情况和危险组合的潜在风险。 风险评估后， 我们选择风险最高的情景。 每个可能的故障可能发生的最坏情况事件。 最后，我们根据这些最坏的情况定义我们的安全要求。 HARA 流程为系统设定设计目标 一种了解所有可能发生的最坏情况故障的方法。 通过验证确认 这些最坏情况下的故障仅以合理的风险进行处理。 这就是功能安全背后的主要思想。 您专注于最坏情况的需求，然后实施 至少可以处理这些最坏情况要求的硬件和软件。

 最后，让我们简要探讨一下预期功能标准或 SOTIF 的安全性，在 ISOPAS 21448 文档中正式定义。SOTIF 特别关注与相关的故障原因系统性能限制和可预见的系统误用。由于执行功能的性能限制或不足技术限制，例如传感器性能限制和噪声，或算法的限制，例如物体检测故障和执行器技术的局限性。硬件和软件故障通过以下方式解决ISO 26262 中的功能安全标准，不在 SOTIF 的范围内。SOTIF 还解决了由于用户可预见的误用而导致的不安全行为。比如用户混淆，用户超载和用户过度自信。当前的 SOTIF 标准针对自动化水平，零，一和二。它还指出，它的方法可以应用于第三级，四个和五个自治，但可能需要额外的措施。SOTIF 可以看作是功能安全流程的延伸，专为应对自动驾驶功能的挑战而设计。因此，它遵循非常相同的V型发展理念，但有增强的组件。SOTIF 还使用 HARA 来识别性能限制和误用引起的危险。然后执行类似的设计序列，单元测试和验证和确认，确认已满足安全要求。如果您想深入了解功能安全或 SOTIF 标准，请查看补充材料中的链接。

 让我们总结一下我们在这个视频中学到的东西。我们首先讨论了通用安全框架。故障树分析作为一种自上而下的方法安全评估和故障模式和效果分析作为一种自下而上的安全方法。然后我们讨论了常用的功能安全的概念。软件和硬件风险评估和讨论了 SOTIF 作为功能安全的扩展，这说明了性能限制和误用。所有这些想法在行业中被大量使用，正如我们在 Waymo 和 GM 中看到的那样几乎所有这些技术都在他们的安全评估中。

 恭喜。你已经完成了这个安全评估模块。让我们总结一下我们这周学到的东西。我们首先讨论了为什么安全很重要，特别是如何广泛的不同故障可能导致自动驾驶事故。然后我们正式定义安全概念并讨论NHTASA 对自动驾驶汽车的安全建议。然后我们讨论了 Waymo 和通用汽车如何看待自动驾驶安全。然后，我们描述了展示安全性的分析和数据驱动方法。最后，在今天的视频中，我们讨论了共同的安全评估框架。包括故障树、故障模式和影响分析，功能安全和预期功能的安全性。

 希望本周能让你深入了解设计安全的自动驾驶系统并正确评估您构建的系统。在我们结束这周之前，我们将与滑铁卢大学的 Krzysztof Czarnecki 教授，自主安全评估专家。我有很多有趣的问题要问。敬请关注。

第三课补充阅读：自动驾驶的安全框架

补充阅读：自动驾驶的安全框架

查看以下有关自动驾驶汽车安全框架的链接：

• 失效模式和影响分析 - asq.org

• ISO 26262-1:2018 - 道路车辆的功能安全

• ISO/PAS 21448 - 道路车辆预期功能的安全性

证明自动驾驶汽车的可靠性需要行驶多少英里？

兰德公司关于安全驾驶的报告