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 的测试程序以下专门评估其软件,因为它是最公开可见和有据可查的程序。首先,他们测试所有软件更改每天模拟 1000 万英里的模拟量。这代表了持续运行的巨大计算工作量确认对系统安全要求的预期改进。为此,他们挖掘了所有在路上的经验来挑战场景并执行系统的场景模糊测试,这会改变位置和其他车辆和行人的速度参数随机,因此他们可以测试自我车辆是否在所有车辆中安全运行。这种方法对于寻找困难的边缘情况特别有用,例如,难以解决合并或交叉路口的时间间隔。
然后他们进行封闭式测试,他们在私人轨道上测试他们的软件。它们涵盖了加州大学伯克利分校研究确定的 28 个核心场景,以及 Waymo 添加的 19 个附加场景。这些场景是围绕避免追尾四种最常见的事故场景,交叉路口、道路偏离和车道变更。这些类别中的每一个显然都有很多变体,但它们加起来占所有事故的 84% 以上。
最后,他们进行真实世界的测试,这些测试是经常出现在美国许多不同城市的街道上,包括位于 Google 主校区附近的加利福尼亚山景城。该测试使他们能够识别越来越多的不寻常的案件主要依靠关于动态驾驶任务回退策略让人类在测试期间监控自治软件。这些测试策略的组合绝非 Waymo 独有,但已成为事实上的标准,因为它提供固定投资的最大灵活性和反馈,将每种测试方法集中在它最擅长的方面,模拟操纵使它们变得困难的场景,封闭课程测试确认具体收益寻找更具挑战性的场景的安全性能和实际测试,并提高公众对该技术的信心。
好的。现在让我们把注意力转向通用汽车的安全理念,2016 年收购 Cruise Automation 并推动因此,它在自动驾驶开发方面处于领先地位。
GM 战略非常遵循 NHTSA 安全框架密切关注 12 个主要领域中的每一个。通用汽车的安全策略并没有试图重组或简化 NHTSA 指南,而是专注于其实现所需安全评估的实施策略。首先,通用汽车强调了他们的迭代设计模型,其中第一个分析场景,然后构建软件,然后模拟场景,并测试他们的软件。最后,将他们的软件部署在现实世界的汽车上,他们不断添加改进和改进需求和自治系统都是迭代的。
其次,Waymo 依靠 OEM 来设计它的车辆,只讨论与其自主硬件相关的机械和电气危险,通用汽车完全自己制造汽车,因此可以强制执行更集成的设计与整个自动驾驶硬件的质量标准一致。其次,通用汽车通过全面的风险管理方案确保安全。他们识别和解决风险并尝试完全消除它们,而不仅仅是减轻它们。最后,他们所有的系统都遵循内部明确定义的安全标准,可靠性、安全性等。他们在汽车行业拥有多年的车辆开发经验,并因此开发了广泛的安全流程。
让我们讨论一下可以采用的各种方法用于评估自动驾驶系统的安全性。我们有两种可能的方法:分析或数据驱动的安全评估。通过分析安全性评估,我们的意思是系统可以被分析来定义可量化的安全性能或基于对危险和情景的严格评估的故障率。如果可以通过分析确定整体系统故障率,它可以为哪些方面提供强有力的指导该系统是整体安全的最大贡献者。一个很好的例子是航天飞机计划,其初步估计分析失败率为 100,000 次飞行中的 1 次。然而节目结束后,一项法医研究表明,早期的航天飞机计划飞行的失败率接近十分之一,到节目结束时,这只会发展到百分之一。令人惊奇的是,这种分析甚至可以用于这样一个复杂的系统,考虑到所有进入航天飞机发射的数千个子系统,以及所有可能影响这些系统运行的数百万个变量。这种详细的分析也适用于自动驾驶汽车,但可能会更复杂,因为车辆的无限多种情况将自己局限在其中。最后,分析方法只能为自动驾驶系统的安全性能提供指导,他们的结果需要通过经验来验证。为了评估经验,我们使用数据驱动测试。这是我们确信的概念该系统是安全的,因为它已经证明,使用特定版本的软件,它可以在一组上达到预期的故障率包含在运营设计领域的道路和场景。在自驾的情况下,这些期望的故障率可以与人类水平的驾驶表现联系起来,我们希望将事故减少 10 倍或 100 倍于当今驾驶员的表现。
现在,让我们考虑初步的自动驾驶车辆统计数据,更具体地说,脱离率由在加利福尼亚测试的所有自动驾驶车辆发布。脱离是当这个自治软件请求驾驶员接管控制或安全驾驶员觉得有必要进行干预。获得真正的崩溃统计数据是可以理解的具有挑战性的整个车队都在接受测试,因为这些都是敏感的统计数据。幸运的是,加州的测试伴随着一些有用的报告要求。2017 年,Waymo 在加州行驶了 56.3 万公里,经历了 63 次脱离接触每 9,000 公里大约有一次脱离接触。GM Cruise 在加州行驶了 210,000 公里大约每 2,000 公里有 105 次脱离接触。两者都在全年迅速改善,达到每 12,500 公里一次的脱离接触率,每年最后三个月分别为每 8,300 公里。这些是很难与人类表现相关的数字,但大致意味着一个典型的通勤者只需要对于自治系统的失败,每年进行一次干预。这是巨大的进步,但距离人类每年在数万亿英里内实现的碰撞之间的距离为 400,000 公里。按频率顺序排列 63 次 Waymo 脱离的主要原因,是不需要的车辆操纵,感知差异,硬件问题,软件问题,行为预测,最后是一个鲁莽的道路使用者的案例。很明显,感知的核心任务,预测和行为规划仍然是具有挑战性的问题,还有很多工作要做。
正是出于这个原因,我们看到了如此多方面的安全方法,每家公司都在扩大车队增加在道路上使用自主系统获得的经验。总而言之,在这个视频中,我们研究了自动驾驶安全评估的两个行业观点,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
我们稍后会在视频中定义这些术语。让我们开始。我们将从故障树分析开始。故障树可以作为初步的分析框架,并且可以稳步扩展以包含尽可能多的必要细节。故障树是自上而下的流,我们在其中分析要避免的系统可能出现的故障,然后确定它可以使用的所有方法发生在系统较低级别的事件和故障中。故障树中的顶部节点是根或顶部事件。故障树中的中间节点是逻辑门,定义了根本事件的可能原因。分解继续到详细程度可以定义此类事件的概率。然后可以通过组合来分析故障树使用布尔逻辑定律的概率。评估总体概率根本原因事件和最有助于其发生的原因。让我们考虑一个简单的例子,并将车祸作为我们的根本事件。车祸的原因可能会被分解无论是软件故障还是硬件故障,在我们提供的许多其他可能性中在我们之前的视频中被描述为危险等级。非常粗略地说,硬件故障可能是因为例如,制造缺陷或材料缺陷。同样,软件错误可能是由感知代码故障或某些网络安全问题,比如说,如果我们被黑了。从那里,我们可以继续进行软件子系统和这些子系统中的特定计算在每个连续的分支处加深树