资讯详情

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

Lesson 1: Safety Assurance for Self-Driving Vehicles

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

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

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

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

2017年底,一辆GMCruise雪佛兰Bolt在停车道变换后,撞倒了一名摩托车手。在Bolt启动机动后,它希望进入的间隙能迅速关闭,由于相邻车道的制动引导车辆。正要换车道的摩托车司机在Bolt向前移动,阻挡回程机动。Bolt 进退两难;在相邻车道上与摩托车相撞或撞上两辆车。目前还不清楚选择一个或另一个结果,诉讼也掩盖了案件的细节。但是,因为别的agent自动驾驶汽车的动作也会得到预测,所以在很多情况下评估正确的动作是非常具有挑战性的。如果可能的话,并道可能是一种更激进的驾驶风格,或者中指可能有足够的时间避免撞到摩托车手。这种紧密的决策互动仍然是自动驾驶汽车的一大挑战。

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

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

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

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

我们将使用术语,

“Harm定义对生物的物理伤害,

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

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

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

每一种危险都需要不同的方法来评估整个系统的安全性。我们将在后续视频中详细介绍如何处理这些类别。既然我们知道安全所涉及的基本术语,那么让我们考虑以下问题。我们如何确保自动驾驶汽车真正安全?换句话说,我们如何处理复杂的驾驶任务和许多可能的危险,并为完整的自动驾驶系统定义安全评估框架?在美国,国家公路交通安全管理局或国家公路交通安全管理局已经制定了一个由十二部分组成的安全框架,以建立自动驾驶安全评估。正如我们将在本单元的下一个视频中看到的,该框架只是一个起点,不同的方法已经出现在行业中,结合各种现有的发送和标准方法。让我们先讨论一下NHTSA安全建议。该框架作为建议发布,而非强制性。框架于2017年发布。框架本身由12个领域或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。

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

标签: 常见传感器可监控司机

锐单商城拥有海量元器件数据手册IC替代型号,打造 电子元器件IC百科大全!

锐单商城 - 一站式电子元器件采购平台