对于自动驾驶车辆，安全的重要性是毋庸置疑的。为了适当评估自动驾驶车辆的安全性，各国、公司和组织开始努力开发自动驾驶安全框架或至少部分框架进行指导ADS安全测试和部署。

1. RAND公司《衡量自动车辆安全:建框架》

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

• 在不同的环境(模拟、封闭场地、公共道路、有、无安全驾驶员)中，可采用安全测量方法，

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

• 采用 Haddon 为了测量和干预，矩阵分析了碰撞因素。

测量框架侧重于系统和生态系统级

Integrated Safety Framework

2. 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 目前，该模型已达到相当健全可用的状态。

3. NVIDIA公司SFF安全框架

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

安全力场将确定一组可接受的动作，以保护当前车辆和道路上的其他车辆。此外，还将包括缓解危险情况的必要措施。NVIDIA DRIVE 基于物理原理，平台使用车辆传感器数据支持平台SFF逐帧计算。

4. 第一至第十二条自动驾驶安全原则

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

5. Aurora自动驾驶安全案例框架框架

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

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

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

基于安全案例的方法将证据与索赔两个基本概念结合在一起，有效展示确定公共道路上车辆安全驾驶的工作。

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

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

最高级别的目标

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

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

G2:故障安全/Fail-safe：自动驾驶车辆在发生故障和故障时具有可接受的安全性。

G3：不断改进/Continuously improving：评估构成不合理安全风险的所有潜在安全问题，并采取适当的纠正和预防措施。

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

G5:值得信赖/Trustworthy：自动驾驶企业应该值得信赖。

顶级声明是根据覆盖安全操作范围的安全原则来定义的。每个安全原则分解为中间论点、上下文和策略层次，并跟踪每个安全论点作为逻辑分解。

6. Waymo 系统安全计划 SSP

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

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

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

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

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

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

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

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

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

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

8. 美国AV 3.0提出的12项安全要素

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

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

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

2020年4月，非营利标准组织Underwriters Laboratories（简称UL）宣布UL 4600《自动驾驶产品安全评估标准》正式发布，这是UL针对无人驾驶车辆而开发的首个安全评估标准，属于自愿性行业标准草案。

与ISO 26262和21448一样，UL 4600是一个以过程为中心的标准，旨在供制造商在开发AV时使用。

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

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

10. ISO 2626-功能安全

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

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

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

11. ISO 21448-SOTIF预期功能安全

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

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

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

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

12. 美国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将继续研究降低复杂性的方法。

13. 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.

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

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

自动驾驶车辆安全原则对比

Safety Principles		USA (NHTSA FAVP 3.0)	Japan (MLIT-Guideline)	Canada (Transport Canada)	Europe (EC Guidance)
			Vision: “0” accidents with injury or fatality by ADV Ensure Safety : Within ODD ADV shall not cause rationally foreseeable & preventable accidents
1	Safe Function (Redundancy)	1) System Safety 9) Post Crash Behavior	ii) System safety by redundancy	6) Safety systems (and appropriate redundancies)	7) Safety assessment – redundancy; safety concept
2	Safety Layer	3) (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 center	4) International standards and best practices	2) Driver/operator/ passenger interaction - takeover delay; camera & voice link for driverless systems
3	Operational Design Domain	2) Operational Design Domain	i) Setting of ODD	2) Operational design domain	1) System performance in automated mode – description 2) Driver/operator/ passenger interaction – boundary detection
4	Behavior in Traffic	3) OEDR 12) Federal, State and local Laws		3) OEDR	1) System performance in automated mode – behavior 4) MRM – traffic rules; information
5	Driver‘s Responsibilities		iv) HMI – driver monitoring for conditional automation	1) Level of automation and intended use 7) HMI and access of controls – accidental misuse	2) Driver/operator/ passenger interaction – information; driver monitoring
6	Vehicle Initiated Take-Over	4) Fallback (MRC) 6) HMI	ii) Automatic stop in situations outside ODD iv) HMI – inform about planned automatic stop		3) Transition of driving task – lead time; MRM; HMI 4) MRM
7	Driver Initiated Transfer	6) HMI		7) HMI and Accessibility of Controls	1) System performance in automated mode - takeover
8	Effects of Automation			7) HMI and Accessibility of Controls –  unsafe misuse
9	Safety Certificate		viii) Safety evaluation via simulation, track & real world testing ix) In-use safety - inspection	5) Testing and validation 11) After market repairs / modifications	7) Safety assessment – product; processes; risk assessment; standards
10	Data Recording	10) Data Recording	v) Installation of data recording devices	12) User privacy 13) Collaboration with government agencies & law enforcement	5) Data storage system
11	Security	7) Vehicle Cybersecurity	vi) Cybersecurity – safety by design ix) In-use safety – software update	10) Cyber security 11) System update	6) Cyber security
12	Passive Safety	8) Crashworthiness		9) User protection during collision & system failure
13	Driver‘s training	11) Consumer Education/Training	x) Information provision to users	8) Public education and awareness	8) information provision to users