全自动驾驶汽车的安全标准和方法

摘 要

对于自动驾驶汽车想必很多人是既陌生又熟悉的，大多数人都会在意它的可靠性，安全性，以及舒适性等因素，现阶段确保自动驾驶汽车上路的安全应该是最为重要的。想要保证自动驾驶汽车和其他完全自动驾驶车辆的安全性，对传统的软件安全标准而言，无论是在内容（应解决的安全问题）还是方法（应采取的解决方式）上，都是重大的挑战。

本文提出了一种完全自动驾驶汽车安全的标准方法，该方法基于为整个安全案例设定范围要求。一个可行的方案需要有反馈回路，由于收集了现场反馈，即使在部署完成后，还可以伴随着技术的变化和经验的累积，同时进行安全案例的改进，从而提高标准。外部评估流程是此方法必不可或缺的一部分，确保在流程中能够吸取经验教训，并保证了评估流程的透明度。这种方法为最终制订UL 4600初始标准草案打下了基础。

介绍

大势所趋，自动驾驶汽车终将来临，对交通也可能产生深远的影响。在世界各地，相关企业纷纷大量投入自动驾驶道路测试，每隔一段时间，就有相关企业宣布已研发出新的自动驾驶技术，在不久的将来，自动驾驶汽车能够在没有人类司机的情况下行驶上路。在技术进步速度飞快的当下，安全问题更是迫在眉睫。

事实上，各种安全标准已有几十年的历史了，这些标准的制订就是为传统车辆解决基于计算机的系统安全问题。我们所熟知的ISO 26262:2018便是近年来的最新的标准版本，2019年，为了解决高级辅助驾驶（ADAS）的安全性问题，又发布了ISO PAS 21448 SOTIF（预期功能安全），直至2020年4月，Underwriters Laboratories非营利标准组织（以下简称UL）宣布UL 4600《自动驾驶产品安全评估标准》正式发布，这是UL针对无人驾驶车辆而开发的首个安全评估标准。

如何保证高度自动化车辆（HAV）能够安全部署上路？现有的传统标准是必要的，但还不足以覆盖HAV。确实，我们可以从航空和军事系统等其他领域的安全标准中获得一些见解和启发，但无论是汽车还是其他领域，各个领域的设计人员都在面临着搭建安全自主系统所特有的难题，不能通用。所以，一个灵活且可迭代的方法，才能使HAV保证和规范安全性。

现行标准

1. ISO 26262

传统上来说，车辆最终是由人类驾驶员负责安全操作，汽车设计师会把整体安全策略建立在这个原则之上，以致于ISO 26262聚焦在“功能安全”上。

广义上来说，功能安全可保证系统有足够的能力来充分降级失效风险，以确定危害。降级的程度要求取决于潜在失效事件的暴露性，已识别危害的严重性，以及当失效事件发生时，人类驾驶员对汽车的可控制性。根据这些因素，组成了对汽车安全预先确定的风险表，这就是汽车安全完整性等级（ASIL）。当某一功能分配到相应的ASIL等级后，为达到安全目标，确定采用哪些技术和流程作为降级措施，其中必须包括执行指定的设计和分析任务。IEC 61508定义了安全完整性等级 (SIL)，而 ISO 26262 则定义了汽车安全完整性等级 (ASIL)，所以ISO 26262是符合IEC 61508的安全标准项目的，例如：而 ISO 26262 则定义了汽车安全完整性等级 (ASIL)，所以ISO 26262是符合IEC 61508的安全标准项目的，例如：

·  指定基于V模型作为产品开发不同阶段的参考过程模型

·  利用安全等级来分析软件，硬件和系统方面的风险

·  包含生命周期主题，例如生产，操作，支持和工具· 对危害、安全目标和ASIL采用指定的安全分析方法

·  根据ASIL，指定分析、设计和验证技术

以上综述，ISO 26262强调是避免设计错误（例如，软件质量要求）并缓解操作过程中因设备故障带来的影响（例如。防故障装置）。

2. ISO/PAS 21448 (SOTIF)

那么，当设备没有发生故障时，某些功能还是依旧无法正常运行，该怎么办呢？这就是驾驶辅助功能的难题。为了解决这个难题，汽车行业也建立了新的安全标准—— ISO / PAS 21448“预期功能的安全性”（SOTIF）标准。该标准主要考虑缓解由于意外操作条件（由于传感器和算法的限制，预期功能可能无法始终在其中使用）和需求缺口（缺少关于预期功能实际含义的完整描述）而导致的风险。该标准的重点包括：

·  环境感知不足

·  可预见的误操作和人机交互问题

·  运行环境（天气，基础设施等）引起的问题

·  着重识别和填补需求空白（消除“未知”）

ISO 21448扩展了ISO 26262的范围，以涵盖ADAS功能。两者都明确允许进一步扩大范围，但还不足以完全覆盖HAV安全的全部范围。（ISO/PAS 21448正在更新修订中，尚未发布。）

3. 其他标准

其他领域还有很多安全标准，包括：用于化学流程控制的IEC 61508；CENELEC EN 50128 用于轨道系统；MIL-STD-882E 用于军事系统；以及用于航空行业的SAE ARP 4754A 和SAE ARP 4761。这些标准都提供了额外的安全性观点，但没有一个能够涵盖所有的HAV问题。人类驾驶员的操作行为可预测假设，需求可完整识别，并且相对于HAV来说，人类驾驶员的操作环境更加简单，这些就是为什么现有标准都无法涵盖HAV安全的主要原因。

附：培训课程

9月12日，牛喀网将开展为期2天的《Robot Taxi安全设计》培训，从Robot Taxi的功能定义和目前主流的安全规范体系入手，介绍ISO 26262，ISO/PAS 21448, NHTSA自动驾驶安全规范等标准如何对应到Robot Taxi的各种安全功能和特性上，包括如地图和定位、神经网络算法这些较为核心且极具安全挑战的功能模块。

现行标准

我们迫切需要一个可以涵盖HAV的安全标准！如今各大企业纷纷承诺要将“真正的无人驾驶”商业化，开始部署生产。一般来说，总结十年的生产经验，肯定可以使各企业的HAV设计趋于一致，然后再编写安全标准。但是我们希望早日指定标准，而不是等到十年以后。

尽管现行的标准给我们提供了基础，但是对于HAV安全标准的作者们来说，现在HAV所使用的技术存在种类繁多和不成熟的现象，这成为了具有挑战性的难题。

1. 新技术

目前HAV所使用的技术，本质上与传统安全标准所采用的方法不兼容。所以，适用于HAV的新标准必须至少解决以下问题：

·  机器学习技术（ML）的使用：基于学习的方法来解决棘手的设计困境，这是使用ML技术的显著优势。同时，其显著劣势是缺乏必要条件，导致阻碍了设计的评估能力，也阻碍了评估的可追溯性。

·  不可预测算法的使用：人工智能技术和随机算法都倾向于以不可预测的方式表现，这种算法通常被认为是不确定的。如此一来，创建可重复测试就变得复杂了。

传统安全标准采用的更新周期可能需要耗费5到10年，但是HAV技术的发展要快得多，过早制定标准可能会抑制相关技术的创新。此外，当开发人员仍在研究如何使该技术正常运行时，传统的基于共识的标准方法很难适用于HAV技术。任何标准都需要前所未有的灵活性，才能实现为HAV技术所用。

2. 无人驾驶

任何标准的内容都必须解决系统级故障管理的基本变化。HAV的出现意味着没有人类驾驶员操控了，可控性消失了！因此，自动驾驶系统本身必须管理车辆故障。

自动驾驶产品的行为可能与人类驾驶员的行为不同（但兼容），并可能需要处理人类通常不会遇到的情况，所以，一旦没有人类驾驶员，还会产生大量的其他操作和生命周期活动。这就包括与潜在危险成为和紧急人员进行互动。此外，自动驾驶系统本身管理车辆故障的这种自主性，可能还需要能够减轻由于操作故障引起的风险，比如，汽车火灾中的乘客疏散，并且处理生命周期故障。

安全案例

要使安全标准能够完全涵盖HAV确实有种种困难的限制，我们认为通过以下方法可以：在总体安全设计结构中使用安全案例，指定安全案例范围的广度，吸取学习经验，针对不断变化的环境进行标准更新，以及多层反馈方法，在反馈过程中，必须要有独立评估流程。这种方法不仅可以管理未知因素带来的风险，还可以把不断发展的技术和不断变化的操作环境考虑进去。

1. 特定范围的安全案例：

这种“安全案例”的方法，曾被使用过。我们认为，安全案例不应只是安全方案的一部分，而应成为包含所有内容的首要总体结构。这种方法允许灵活使用诸如工具之类的项目，并遵循其灵活的工程流程。同样，这意味着安全案例不仅必须提出充分有力的论据，证明已经采用了适当且必要的流程和方法，并且确认选择的选项足以保证安全。

只要遵循该方法的其他要素，原则上该标准就不需要指定任何特定的工具或流程步骤方法。相反，该标准可能还满足我们提出的更高级的需求和论点。例如，该标准可以要求识别所有危害和相关风险，但不必识别必须采用什么技术来实现。为避免不必要的工作和花费，可以考虑遵守ISO 26262，ISO 21448，以及其他符合程度高且适用于HAV的标准。

缺乏深度或证据的安全案例，是当下一个潜在的问题。该标准草案通过列举所需的subClaims和安全案例范围，要求有一定的深度。（例如，必须确定与供应链相关的危害。）在较高的级别上，我们已经确定了以下主题，这些主题必须针对HAV专门解决，且超出了其他标准的范围。

·  操作设计领域的定义（例如，天气，场景）

·  机器学习故障（例如学习数据gaps，脆弱性）

·  除驾驶员以外的人员（例如，行人，生命周期参与者）的错误行为

·  高残留未知量（例如，需求差距和部署后的意外）

·  缺乏人为监督（例如，操作故障处理，乘客处理）

·  系统级安全指标（例如，使用领先指标和滞后指标）

·  将系统过渡到降级模式和最低风险条件

2. 持续进行风险评估

考虑到HAV部署所涉及的新颖性，复杂性和后果，一开始就建立一个坚不可摧的安全案例，这真的太难了！比起在部署时，就妄想仅遵照标准就可以毫无缺陷地减轻风险，更重要的是不断评估和改善系统中存在的残余风险。对于识别，实施和验证其他缓解措施而言，识别潜在和紧急风险才是至关重要的。

同样，在使测试人员和公众暴露于不必要的安全风险之前，必须解决已知的安全问题。开发人员应该努力培养负责任的安全风险识别和归属的文化。这包括承担开发错误以及设计、测试和安全案例本身的缺陷。对开发的错误，以及设计，测试和安全案例本身之间的差距进行评估。对系统开发和部署生命周期进行诚实的自我评估和迭代，这些对于完善安全案例都是很重要的。

鉴于HAV开发的高风险，高压环境来看，独立评估也是必不可少的。除了提供对系统安全性的基本检查和平衡之外，独立评估还可以提供一些经验，且不会暴露设计细节。

3. 反馈和经验学习

HAV技术的快速发展不是障碍，我们必须要拥抱它。既不会等到技术成熟不变（这可能永远不会发生）再来构建标准，也不会过早的“冻结”标准，停止更新。我们计划与HAV技术一起发展，在技术进步的同时更新标准。这一定是可行的（图1）：


总结

基于目标的安全案例方法，加上预先植入的反馈路径，这是为HAV创建安全标准的实用方法。最初，可以鼓励企业使用一个公认的安全案例来时间。但是，这个案例还会随着行业的发展仍在不断发展和成熟。