本文来源：智车科技

／ 导读 ／

对于自动驾驶车辆来说，安全的重要性毋庸置疑，为了恰当评价从而确保自动驾驶车辆的安全性，各国家、公司和组织已经开始努力开发一个自动驾驶安全框架或至少部分框架，以指导ADS的安全测试和部署。本文对部分已公开的自动驾驶安全框架进行汇总介绍，欢迎大家留言补充。

RAND公司《衡量自动车辆安全：构建框架》

兰德公司（RAND）2018年发布了一份自动驾驶安全衡量框架的报告Measuring Automated Vehicle Safety： Forging a Framework，提出了一个用于测量配备ADS自动驾驶系统的车辆安全性的部分框架。在开发该框架时，考虑了如何定义ADS安全性、如何测量ADS安全性以及如何传达对AV的了解和理解。报告旨在提供一个框架，讨论如何以技术和公司中立的方式衡量安全性。

呈现了在不同环境（模拟、封闭场地、公共道路，有、无安全驾驶员）中针对不同阶段（开发、验证和部署）可以采用的安全衡量方法，

在报告中明确了自动驾驶汽车生命周期中的三个阶段——开发、验证和投放，并将碰撞事故次数、交通违规次数、和“公路驾驶技能”（roadmanship）作为评定自动驾驶安全性的指标。

采用 Haddon 矩阵对碰撞因素进行分析，以便进行测量与干预。

测量框架聚焦于系统和生态系统级

Integrated Safety Framework

MobileEye 公司RSS责任敏感安全模型

MobileEye提出了一个名为RSS责任敏感安全（Responsibility Sensitive Safety）的框架，旨在解决多智能体安全问题（由其定义为在给定环境中与多个独立道路使用者的安全操作和交互）。RSS是一个多智能体安全的数学模型，希望通过建立数学公式的手段，来使得自动驾驶汽车有能力判断自身的安全状态，从而尽可能避免事故的发生。它结合了驾驶的常识规则，同时与其他道路使用者进行互动，以最大限度地减少造成碰撞的可能性，同时在正常的行为预期范围内操作。该方法是根据“路权”构建的规则、遮挡物体避免以及纵向和横向的安全距离保持。MobileEye称讨论中涵盖了特殊交通条件，包括交通灯交叉口、非结构化道路以及涉及行人（或其他道路使用者）的碰撞。

从本质上来看，RSS 模型是一整套数学公式，将人类对于安全驾驶的理念和概念转化成为数学公式和计算方式，用来界定什么样的驾驶行为才是安全的驾驶。RSS 模型希望把人类驾驶员的本能变化成一套严谨的公式算法，来指导 AI 的决策算法在特定场景下做出合理安全的判断。

RSS描述的不是驾驶策略，而是对驾驶策略的结果进行安全判定。另一方面，RSS在定义不同场景下的危险情况、正确反应、事故责任划分中，是基于人类驾驶员的常识，而非仅仅法律法规。
RSS模型要达到的目标具有两重含义：

自动驾驶汽车本身不会导致事故（卷入事故和导致事故是完全不同的概念，自动驾驶汽车可能卷入事故，但它不是事故的责任方）

自动驾驶汽车应该在其它车辆发生错误时做出正确反应

在实际建立模型的时候，RSS 模型通过四条形式化的规则，来确保车辆在自动驾驶状态下能够保证安全以及避免成为制造车祸的一方：

和前车保持安全距离；

给侧边的人或车留下足够的反应时间和空间；

在堵车的时候更谨慎；

要合理使用路权（路权的使用应优先考虑安全）。

Mobileye 在创建 RSS 模型的时候，则是把 RSS 定位在决策之后、执行之前。

如果决策算法在某个状态下做出了刹车的判断，那么这个判断就会输入到 RSS 模型中，得出刹车操作是否能在当前状况下保证车辆的安全。如果结果显示安全，那么这个命令会直接执行；如果结果显示有危险，那么 RSS 模型会把这个指令返回到决策算法，进行二次决策直到得到最安全的结果。
安全距离是指在最恶劣的情况下仍可以避免碰撞的距离。

Mobileye 发布的官方报告中例举了 37 种可能发生事故的场景，包括了车辆并行状态的安全间距、安全并线的间距、避免追尾的最小安全距离、路边有行人闯入机动车道时的安全车速等等。这 37 种状况基本覆盖了 99．4％的车祸可能性，也说明 RSS 模型目前已经达到了一个相当健全可用的状态。

NVIDIA公司SFF安全框架

NVIDIA2019年3月发布了一种称为“安全力场（SFF：Safety Force Field）”的框架，该框架作为计算方法，用于通过模拟评估ADS是否成功监控其周围环境且未采取不可接受的行动。SFF旨在避免撞车，其目的是通过制定一项驾驶策略来实现这一目标，该策略分析周围环境并预测其他道路使用者的行动。根据这一分析，系统将寻求确定潜在行动，以避免造成或促成可能导致交通事故的不安全条件崩溃。

安全力场会确定一组可接受的动作来保护当前车辆以及道路上的其他车辆。这些动作并不会造成、加剧或导致危险情形的出现，此外还会包括用于缓解危险情形的必要措施。NVIDIA DRIVE 平台使用车辆传感器数据来支持基于物理原理的SFF逐帧计算。

自动驾驶安全第一至12条原则

2019年7月， “自动驾驶安全第一” 11家企业联盟发布了一种描述ADS安全性设计、验证和确认（V＆V）的方法。旨在解决L3和更高级别的自动驾驶问题，并可作为检查适用于ADS的V＆V方法的有用起点。为指导安全工作，该文件确定的共12条原则包括：安全操作；ODD确认；交通行为；用户责任；车辆接管请求；车辆操作员与自动驾驶系统的互相依赖；自动化效果；安全评估；数据记录；安全和被动安全；交通行为；安全层等。

Aurora自动驾驶安全案例框架

Aurora于2021年8月推出了第一个适用于自动驾驶卡车和乘用车的安全案例框架（Safety Case Framework）初始版本。

Aurora使用基于安全案例的方法，评估自动驾驶车辆何时能够安全地在公共道路上行驶，并评估它们是否不会对机动车安全造成不合理的风险。

Aurora安全案例框架评估了车辆的整个开发生命周期，够加快部署的速度，并确定何时可以接受自动驾驶车辆在公共道路上的安全性。

基于安全案例的方法以合乎逻辑的方式将这证据与主张两个基本概念结合在一起，以有效地展示为确定车辆在公共道路上安全行驶所做的工作。

Aurora的安全案例框架覆盖了对评估公共道路上自动驾驶车辆的安全开发、测试和运行至关重要的不同要素。该框架的设计涵盖了与车辆操作员的测试，也包括没有操作员的测试。同时，它是为适应环境而构建的，因此可以根据不同的场景和环境对其进行定制。能够将安全案例声明改编为适用于不同的车辆平台、有操作员的车辆、试车跑道上的车辆以及公共道路上的车辆。

安全案例框架旨在适应不同的车辆、场景和环境。因此，将有多个单独的安全案例，涵盖各种配置、平台和操作领域，而不是涵盖自动驾驶车辆所有用途的单一安全案例。

最高级别目标

Aurora安全案例框架围绕着“我们的自动驾驶车辆在公共道路上运行是可接受的安全性”这一最高级别的声明展开，并将这一主张分解为五个安全原则或子原则。

G1：精通／Proficient：自动驾驶车辆在正常运行期间具备可接受的安全。

G2：故障安全／Fail－safe：自动驾驶车辆在出现故障和失效时具备可接受的安全。

G3：不断改进／Continuously improving：对构成不合理安全风险的所有已识别潜在安全问题进行评估，并采取适当的纠正和预防措施予以解决。

G4：有弹性的／Resilient：在可合理预见的误用和不可避免的事件情况下，自动驾驶车辆具备可接受的安全。

G5：值得信赖的／Trustworthy：自动驾驶企业应是值得信赖的。

顶级声明是根据涵盖安全操作范围的安全原则定义的，使用广度优先、深度第二的方法分解每个安全原则。每个安全原则都被分解为中间论点、上下文和策略的层次，将每个安全论点作为逻辑分解进行追踪。

安全原则分解示例

Waymo 系统安全计划 SSP

Waymo在制定其安全计划时借鉴了航空航天、汽车、国防等行业中的最佳安全实践原则。Waymo的安全体系一共有「五个维度」：

「行为安全」：指车辆在道路上的行驶决策和行为

「功能安全」：确保车辆在系统存故障或失效时的安全操控，这意味着要建立备份系统和冗余机制来应对车辆的意外状况。

「碰撞安全」：车辆通过各种措施保护车内乘客的能力，借助结构性设计来保护车内人员，提供座椅约束装置及安全气囊，减轻车内人员的伤亡程度。

「操作安全」：人机交互，为消费者带来自动驾驶车辆所提供的安全而舒适的体验。

「非碰撞安全」：电子器件与人类的物理隔离，提供身体上的安全防护。

Waymo在开发过程里利用了常用的风险评估方法，如：预先危险性分析（PHA）、故障树（FTA），设计失效模式及后果分析（DFMEA）等，也基于系统架构要求，针对软件在公共道路、闭合环境及模拟驾驶情景内进行了大量的测试。这些铺垫工作为每一个安全课题提供了大量的研究数据。此外，Waymo也采用了全面的安全实践方法来提升系统的可靠性。

NHTSA曾就自动驾驶提出了28项核心竞争力清单，自动驾驶系统需要针对这28项技能证明自己的“行为能力”。Waymo在此基础上，从深度和广度 上都拓展了这个要求（增加了19项核心能力），创建了具有挑战性的测试内容。

VSSF车辆安全与安防框架（RDW）

荷兰交通部车辆认证中心RDW提出了自动驾驶车辆安全框架提议，目标是实现自动驾驶车辆认证流程标准化。

美国AV 3．0提出的12项安全要素

美国AV 3．0中提出了自动驾驶车辆开发、开放道路测试、应用相关最主要的安全要素，包括：系统安全、ODD（Operational Design Domain）、OEDR功能、Fallback（Minimal Risk Condition）、网络安全、数据记录、碰撞安全性（成员保护）、碰撞后处置（Post Crash）、自动驾驶车辆行为、验证与测试、人机界面（HMI）、用户教育与培训、联邦和当地法规。

车辆性能指南框架／Framework for Vehicle Performance Guidance

UL 4600《自动驾驶产品安全评估标准》

2020年4月，非营利标准组织Underwriters Laboratories（简称UL）宣布UL 4600《自动驾驶产品安全评估标准》正式发布，这是UL针对无人驾驶车辆而开发的首个安全评估标准，属于自愿性行业标准草案。
与ISO 26262和21448一样，UL 4600是一个以过程为中心的标准，旨在供制造商在开发AV时使用。

标准范围包括评估自动驾驶产品的安全原则与流程。此标准基于设计流程、测试、工具资格、自主性验证、数据完整性以及针对非驾驶员的人机交互等因素，涵盖相应风险分析与安全相关方面等若干主题，并要求提供安全论证。

标准规定采用安全案例方法来确保ADS的安全性。已发布的安全案例方法包括三个主要要素：目标、论证和证据；每个要素都说明支持前一要素，以构建总体安全案例。

ISO 2626－功能安全

ISO 26262描述了功能安全评估过程的文件，以帮助开发安全相关电气和／或电子（E／E）系统。该框架旨在供制造商用于将功能安全概念集成到公司特定的开发框架中。一些要求具有明确的技术重点，以将功能安全实施到产品中；其他要求涉及开发过程本身，因此可以视为过程要求证明组织在功能安全方面的能力。

ISO 26262解决了由电气和电子故障引起的已识别的不合理安全风险。该框架旨在应用于安全相关系统，包括安装在生产道路车辆（不包括轻便摩托车）中的一个或多个E／E系统。ISO 26262旨在避免与电子系统相关的故障包括与软件编程、间歇性电子硬件故障和电磁干扰相关的故障，并减轻运行期间潜在设备故障的影响。除了解决故障条件外，还包括危险分析和风险评估规定、设计、验证和确认（V＆V）要求和安全管理指南。

ISO 26262旨在确保系统能够充分缓解已识别危险的故障风险。所需的缓解量取决于潜在损失事件的严重程度、危险的操作暴露以及故障发生时系统的人类驾驶员可控性。这些因素结合在一起构成汽车安全完整性等级（ASIL）。ASIL确定应采用哪些技术和过程缓解措施，包括必须执行的指定设计和分析任务。

ISO 21448－SOTIF预期功能安全

ADS的安全性还与其他因素有关，如可想象的人为误用功能、传感器或系统的性能限制以及车辆环境的意外变化。

SOTIF（预期功能的安全性）试图防止预期功能不足或可合理预见的人员误用。即使不存在设备故障，也可能无法正常运行。SOTIF不适用于ISO 26262系列涵盖的故障或直接由系统技术。相反，SOTIF与ISO 26262协同工作，以帮助制造商评估和缓解开发过程中的各种风险，ISO 26262侧重于降低故障风险，ISO 21448侧重于缓解可预见的系统误用。

ISO 21448旨在应用于预期功能，其中适当的态势感知对安全至关重要，并且该态势感知源自复杂的传感器和处理算法；特别是紧急干预系统（如主动安全制动系统）和高级驾驶员辅助系统。根据SAE国际标准，该标准可用于更高级别的自动化，但可能需要采取其他措施。

ISO 21448主要考虑缓解因意外操作条件（由于传感器和算法的限制，预期功能可能不会始终在此类条件下工作）和需求差距（缺乏对实际预期功能的完整描述）而产生的风险。

美国NHTSA 的AV安全框架开发

2020年12月，美国国家公路交通安全管理局（NHTSA）通过ANPRM形式面向社会征集对自动驾驶安全框架的建议。

以功能安全、SOTIF和UL 4600的描述为背景，NHTSA正在考虑如何在制定关于ADS的新框架的背景下，利用这些过程标准，无论是基于法规还是提供指导。该机构预计安全框架将包括管理风险的过程和工程措施。过程措施（例如，在车辆设计过程中分析、按严重程度和频率分类以及减少潜在风险源的一般做法）可能包括稳健的安全保证和功能安全计划。工程措施（例如，性能指标、阈值和测试程序）将寻求提供证明ADS以高水平熟练程度执行其预期功能的感知、感知、规划和控制（即执行）的方法。

NHTSA的一个关键研究方向专注于ADS安全性能，并寻求确定方法、指标以及评估配备ADS的车辆执行正常驾驶任务和防碰撞能力的工具。此类评估包括与系统规定的ODD和对象及OEDR事件检测与响应能力相关的系统性能和行为以及在遇到ODD以外的条件时的故障安全能力。

第二个高级研究重点是功能安全和ADS子系统性能。

第三个研究领域涉及车辆和系统（包括ADS）的网络安全。

最后，NHTSA还研究了配备ADS的车辆可能存在的人为因素问题。

虽然感知、判断、规划与控制四种核心安全功能功能对于ADS是必要的，但它们不一定足以确保ADS的安全，这还取决于系统的各种其他功能和能力，以及该系统如何与配备ADS的车辆内部和周围的人进行交互。

例如，四个功能中未包含的一个安全相关方面是车辆在驾驶环境中与车辆乘员、其他车辆和人员、尤其是易受伤害的道路使用者进行通信的能力。ADS能够准确、可靠地检测车辆中自身系统或其他系统的故障，同时确保为响应任何检测到的问题或故障而开发的操作模式之间的安全过渡（例如，故障保护或跛行回家模式）是可能影响ADS预期性能的另一个重要考虑因素。

可能影响ADS以安全可靠的方式执行其预期计划能力的其他方面包括：

在出现故障时识别降低的系统性能和／或 ODD；

在降低的系统约束下以降级模式运行；

执行将乘客或货物从起点运送至所选目的地的基本任务；

识别来自优先响应者的通信并作出适当反应，包括消防、EMS 和执法；

接收、装载和跟踪 OTA 软件更新；

执行系统维护和校准；

解决与安全相关的网络安全风险；

系统冗余。

NHTSA致力于开发安全性能模型和指标的一个关键例子是2017年发布的ISM瞬时安全指标。ISM瞬时安全指标计算了受试车辆和周围交通中的其他道路使用者在给定一组可能行动时在未来预设的有限时间内可能采取的物理轨迹（例如，方向盘角度、制动／油门），并计算可能导致潜在多因素碰撞的轨迹组合。由轨迹的数量和／或比例（以及导致该轨迹的动作的严重性／概率）确定可能导致碰撞指标，作为评估给定驾驶状态安全风险的工具。

更新的方法是MPrISM模型预测瞬时安全度量（：Model Predictive Instantaneous Safety Metric），建立在ISM概念的基础上并修改其评估方法。MPrISM考虑受试车辆的完全可控动作范围，并在受试车辆做出最佳响应选择和现场其他参与者做出最差选择的情况下计算碰撞影响。

ISM和MPrISM的优点之一是它们的逻辑推理和直接分析结构。然而ISM在实际应用中的一个挑战是有效利用所需的巨大计算复杂性。MPrISM试图通过新的度量开发工作解决这一难题，NHTSA将继续研究降低复杂性的方法。

UNECE WP29《自动驾驶汽车框架文件》

2019年6月，联合国WP．29会议审议通过了中国、欧盟、日本和美国共同提出的《自动驾驶汽车框架文件》。

在系统功能安全方面，要求“车辆制造厂商应该以设计出免于不合理安全风险的自动驾驶系统和保证负荷道路交通法规与本文件列出的原则为目标，根据系统工程方法呈现一个健全的设计和验证过程。设计和验证方法应该包括对以下方面的威胁分析和安全风险评估：自动驾驶系统（ADS），目标事件探测与响应（OEDR），包含上述内容的整车设计，以及更广泛的交通生态系统（如适用）。设计和验证方法应展示出自动驾驶汽车正常运行期间的预期行为能力，避免碰撞的性能以及后备支援的性能，试验方法可组合模拟测试、场地测试和实际道路测试”。

在信息安全方面，要求“基于已建立的网络车辆物理系统最佳实践方案，自动驾驶汽车应免受网络攻击。车辆制造商应表明如何将车辆信息安全考虑整合到自动驾驶系统中，这些考虑包括所有的行动、变化、设计选择、分析和相关测试；以及确保数据在文档版本控制环境中是可追溯的”。在软件更新方面，“车辆制造商应确保系统更新可根据需要、以安全的方式进行，并可根据需要应用于售后修理和修改”。

在事件数据记录（EDR）和数据存储系统（DSSAD）方面，要求“自动驾驶汽车应具有采集和记录与系统状态、故障发生、降级或失效相关必要数据的功能，采用一种可用来确定任何碰撞发生的原因、自动驾驶系统状态以及驾驶员状态的方式”。对于车辆维护和检查，要求“应利用自动驾驶汽车维护和检查等相关措施，确保在用车辆的安全。此外，鼓励车辆制造商提供文件，便于对碰撞后自动驾驶汽车的维护和修理。这些文件将确定能保证自动驾驶汽车在修理后可安全运行的必要装备和过程”。

除了《自动驾驶汽车框架文件》之外，GRVA的提案Proposal for amendments to Framework document on automated／autonomous vehicles （levels 3 and higher） 还提出了UNECE WP29应优先考虑的关键问题和原则：

a．系统安全／ System Safety。

b．失效响应／Failsafe Response。

c．人机界面／Human Machine Interface （HMI） ／Operator information。

d．OEDR／Object Event Detection and Response （OEDR）。

e．ODD／ ［Operational Design Domain （ODD／OD）］ （automated mode）。

f．系统安全验证／Validation for System Safety．

g．网络安全／Cybersecurity．

h．软件升级／ Software Updates．

i．事件记录与存储系统／Event data recorder （EDR） and Data Storage System for Automated Driving vehicles （DSSAD）．

j．车辆维护与检查／Vehicle maintenance and inspection．

k．用户教育与培训／Consumer Education and Training．

l．碰撞预防保护与兼容／Crashworthiness and Compatibility．

m．碰撞后行为／ Post－crash AV behaviour．

部分国家自动驾驶车辆安全原则对比

UNECE曾对已公开的部分国家的自动驾驶车辆安全原则进行了对比，包括美国、日本、加拿大、欧洲，详见下表。

自动驾驶车辆安全原则对比Safety PrinciplesUSA （NHTSA FAVP 3．0）Japan （MLIT－Guideline）Canada （Transport Canada）Europe （EC Guidance）

Vision： “0” accidents with injury or fatality by ADVEnsure Safety ： Within ODD ADV shall not cause rationally foreseeable ＆ preventable accidents

1Safe Function （Redundancy）1） System Safety9） Post Crash Behaviorii） System safety by redundancy6） Safety systems （and appropriate redundancies）7） Safety assessment – redundancy； safety concept2Safety Layer3） （OEDR）ii） Automatic stop in situations outside ODD

iii） Compliance with safety regulation

iii） Compliance with standards recommended

vii） for unmanned services： camera link ＆ notification to service center4） International standards and best practices2） Driver／operator／ passenger interaction－ takeover delay； camera ＆ voice link for driverless systems3Operational Design Domain2） Operational Design Domaini） Setting of ODD2） Operational design domain1） System performance in automated mode – description

2） Driver／operator／ passenger interaction – boundary detection4Behavior in Traffic3） OEDR12） Federal， State and local Laws

3） OEDR1） System performance in automated mode – behavior4） MRM – traffic rules； information5Driver‘s Responsibilities

iv） HMI – driver monitoring for conditional automation1） Level of automation and intended use

7） HMI and access of controls – accidental misuse2） Driver／operator／ passenger interaction – information； driver monitoring6Vehicle Initiated Take－Over4） Fallback （MRC）6） HMIii） Automatic stop in situations outside ODD

iv） HMI – inform about planned automatic stop

3） Transition of driving task – lead time； MRM； HMI4） MRM7Driver Initiated Transfer6） HMI

7） HMI and Accessibility of Controls1） System performance in automated mode － takeover8Effects of Automation

7） HMI and Accessibility of Controls –  unsafe misuse

9Safety Certificate

viii） Safety evaluation via simulation， track ＆ real world testingix） In－use safety － inspection5） Testing and validation

11） After market repairs ／ modifications7） Safety assessment – product； processes； risk assessment； standards10Data Recording10） Data Recordingv） Installation of data recording devices12） User privacy

13） Collaboration with government agencies ＆ law enforcement5） Data storage system11Security7） Vehicle Cybersecurityvi） Cybersecurity – safety by design

ix） In－use safety – software update10） Cyber security11） System update6） Cyber security12Passive Safety8） Crashworthiness

9） User protection during collision ＆ system failure

13Driver‘s training11） Consumer Education／Trainingx） Information provision to users8） Public education and awareness8） information provision to users

－ End －