《自动驾驶系统安全新规》对OEM建立安全档案的要求

D.1 系统描述

D.1.1 一般要求

车辆制造商应提供系统描述，至少包括D.1.2和D.1.3的内容。

D.1.2 功能描述

D.1.2.1 系统描述应包括以下内容：

a) ADS 的预期用途；

示例：个人车辆使用、城市出租车车队运营、货运运输服务等。

b) ADS 的配置和运行特性，包括每项自动驾驶功能、预期用途和使用该功能的限制；

c) 每项自动驾驶功能的 ODC 如何被定义，并按照 GB/T 45312 说明其 ODC；

d) 自动驾驶功能的激活条件；

e) 执行 MRM 的条件；

f) 自动驾驶功能的退出条件；

g) 发出介入请求的条件（如适用）；

h) 本附录外其他需要在安全档案中描述的相关内容。

D.1.2.2 系统描述应明确 ADS 设计用于与之交互的 ORU 类别（例如，行人、骑自行车的人等），并说明这些 ORU 类别与 ADS 之间的交互策略。

D.1.2.3 系统描述应明确 ADS 设计所针对的用户，并说明这些用户与 ADS 之间的交互策略。

D.1.2.4 针对允许行驶中退出至人工驾驶的自动驾驶功能，系统描述应说明：

a) ADS 如何对用户视线进行监测以及如何判定用户视线朝向驾驶任务相关区域；

b) ADS 在此类区域内为符合 5.2.2.3.3 b）所使用的用于判定视线持续时间的各项参数。

D.1.2.5 针对接管能力监测，系统描述应包括以下内容：

a) 后援用户安全带监测方式及判定方法，说明每种监测方式的评估周期和评估指标；

b) 后援用户是否坐在驾驶位的监测方式及判定方法，说明每种监测方式的评估周期、评估指标及阈值；

c) 后援用户执行 DDT 能力的监测方式及判定方法，说明每种监测方式的评估周期、评估指标及阈值。

D.1.2.6 若ADS可请求远程协助，系统描述应说明此类交互的策略及流程。

D.1.2.7 系统描述应说明激活、干预、接管或退出自动驾驶功能的方法。

D.1.2.8 系统描述应说明自动驾驶功能可实现的 MRC，包括：

a) MRM 的过程；

b) MRC 的风险评估。

D.1.2.9 系统描述应包括以下信息：

a) 可识别的 ADS 故障清单；

b) 除 ADS 自身外，其失效会直接导致 ADS 无法执行 DDT 的其他的车辆系统或部件清单。

D.1.2.10 系统描述应说明自动驾驶功能对失效情况的响应方式。

D.1.3 系统布局和原理

D.1.3.1 系统描述应包括 ADS 硬件组件及其功能的概要、软件组件及其功能的概要及 ADS 与其他的车辆系统的关系，概要应包括。

a) 框图和/或示意图，至少包括：

1) 在硬件组件概要中说明 ADS 硬件组件分布；

2) 在框图和/或示意图中整合 ADS 各组件的硬件标识，并提供列表，将硬件标识与软件标识相关联；

3) 对于集成在单一组件（例如，控制单元）中，但在图中以多个模块呈现的功能，采用单一硬件标识。

b) ADS 的组件或功能，以及与符合本文件要求相关的其他的车辆系统的组件或功能，至少包括：

1) 展示 ADS 组件或功能与其他的车辆系统组件或功能之间的互连，通过电路图展示电子传输链路、通过管道图展示气动或液压传输设备、通过布置简图展示机械连接；

2) 硬件和软件组件概要、示意图和/或框图中的传输链路，与对应功能的概要、示意图和/或框图中组件及系统之间传输的信号，有明确的对应关系；

3) 当信号优先级影响性能或安全时，确定多路复用数据传输链路上信号的优先级。

c) 实现以下功能和内容的方式：

1) 对目标和事件的感知；

2) 决策与规划；

3) 由远程方式提供的相关功能和内容（如适用）；

4) 信息显示或用户交互界面；

5) 数据记录系统（例如，DSSAD）；

6) 组件和/或连接的冗余（如适用）。

d) 硬件组件概要应提供用于组成感知系统的各个组件的安装选项信息，至少包括：

1) 当感知系统安装在车上，包括但不限于部件在车辆内或车辆上的位置、部件周边的材料、部件周边材料的尺寸和几何形状、部件周边材料的表面光洁度；

2) 包括对 ADS 表现至关重要的安装规范（例如，安装角度公差）；

3) 感知系统的各个组件或安装选项的任何更改都在文档中更新。

D.1.3.2 系统描述应提供所有 ADS 的 ECU 输入的清单（包括来自传感器的输入），并定义这些输入的工作范围，同时说明感知输入与 ADS 控制功能的关系，以及对 ADS 行为的潜在影响。还应包括每个传感器的标称范围和覆盖区域。

D.1.3.3 系统描述应提供所有 ADS 的 ECU 输出的清单，并在每种场景下解释输出是直接控制车辆还是通过其他的车辆系统控制。还应定义对每个变量的控制范围以及控制执行器的标称能力。

D.1.3.4 系统描述应说明 ADS 如何探测 ODC 的符合情况，并说明其响应方式。

D.2 安全概念

D.2.1 一般要求

D.2.1.1 车辆制造商应将其安全概念形成文档，文档应包含根据 6.1.3 活动所识别出的与 ADS 相关的风险，并应说明这些风险是如何被降低、缓解或接受的。

D.2.1.2 车辆制造商应证明 ADS 在非故障和故障状态下实现了功能概念和安全概念。

D.2.1.3 车辆制造商安全概念文档应说明 ADS 的功能概念、为实现安全目标而制定的安全策略、安全措施、开发过程和方法，以证明 ADS：

a) 通过设计保证系统在非故障和故障状态下实现了功能概念和安全概念；

b) 符合本文件规定的非故障和故障状态下的性能要求；

c) 开发过程和方法是适用的。

D.2.1.4 文档应包括 D.2.1.5 规定的提交的文档和 D.2.1.6 规定的备查的文档。

D.2.1.5 车辆制造商应提交以下文档，并对所提交的文档与产品实际开发的一致性、可追溯性做出自我声明，具体包括：

a) 危害分析和风险评估总结（见 D.2.2.1）；

b) 接受准则和确认目标总结（见 D.2.3）；

c) 安全措施说明（见 D.2.4）；

d) 整车层面的安全分析总结（见 D.2.5.2）；

e) 系统层面的安全分析总结（见 D.2.5.4）；

f) 功能安全验证确认计划和结果总结（见 D.2.6.2）；

g) 预期功能安全验证确认计划和结果总结（见 D.2.6.4）；

h) 安全评估发布报告总结（见 D.2.7）。

D.2.1.6 车辆制造商应具有下列相关文档，并对所保管的文档一致性、可追溯性及所采取的安全策略不会对车辆安全运行产生影响做出自我声明，具体包括：

a) 详细危害分析和风险评估（见 D.2.2.2）；

b) 详细整车层面的安全分析（见 D.2.5.3）；

c) 详细系统层面的安全分析（见 D.2.5.5）；

d) 详细功能安全验证确认计划和结果（见 D.2.6.3）；

e) 详细预期功能安全验证确认计划和结果（见 D.2.6.5）；

f) 其他支撑性材料或数据（若有）。

D.2.2 危害分析和风险评估

D.2.2.1 危害分析和风险评估总结

D.2.2.1.1 车辆制造商应提交危害分析和风险评估总结。其中，功能安全危害分析和风险评估总结应符合D.2.2.1.2，预期功能安全危害分析和风险评估总结应符合 D.2.2.1.3。

D.2.2.1.2车辆制造商应提交功能安全危害分析和风险评估总结，描述 ADS 系统的功能异常表现、整车层面危害、汽车安全完整性等级（ASIL）和安全目标。危害分析和风险评估总结的结果应至少涵盖表D.1中的整车危害及对应的安全目标。

D.2.2.1.3 车辆制造商应提交预期功能安全危害识别和评估总结。危害识别和评估总结的结果应至少涵盖表 D.1 中适用的整车危害。

D.2.2.2 详细危害分析和风险评估

车辆制造商应具有详细危害分析和风险评估以备查，并提供相关的企业名称、文件名、版本、状态、日期、储存位置等基本信息。

D.2.3 接受准则和确认目标总结

D.2.3.1 接受准则

D.2.3.1.1 车辆制造商应提交 ADS 安全接受准则总结，包括：危害行为接受准则和残余风险接受准则。

注： 接受准则考虑因系统功能不足、故障等原因可能导致的风险。

D.2.3.1.2 ADS 危害行为接受准则应至少涵盖表 D.1 中的整车危害。

注： 危害行为接受准则指判断车辆行为是否属于危害行为而可能导致危害事件的准则，例如当某特定行为被认为是危害行为时系统所对应的安全度量物理参数。

D.2.3.1.3 车辆制造商应定义 ADS 残余风险接受准则，考虑现有的事故数据（例如，人驾事故数据、驾驶辅助事故数据、自动驾驶事故数据等）以及行业内先进的技术。

注1：残余风险接受准则指判断车辆运行过程中残余风险是否处于合理水平的准则，例如，考虑目标市场交通事故统计的单位时间或单位里程的最大事件数、正向风险平衡原则等。

注2：考虑将ADS引入市场，与原有风险情况相比，不会导致风险恶化。根据中国国家统计局、道路交通事故统计年报等数据集，设定残余风险接受准则，即：碰撞等事故率低于10-4/h。考虑不同伤害程度的风险，设定残余风险接受准则，即：轻伤事故率低于10-5/h、重伤事故率低于10-6/h、致命事故率低于10-7/h。车辆制造商可以使用其他指标。

D.2.3.1.4 对于因系统功能不足、故障可能导致的碰撞风险，总体应符合残余风险接受准则的要求。

D.2.3.2 验证的准则和确认目标

D.2.3.2.1 车辆制造商应提交 ADS 安全验证准则和确认目标总结。

D.2.3.2.2 针对危害行为验证的接受准则应至少符合表 D.1 中的安全目标和安全度量要求；

注1：危害行为的验证接受准则基于对ODC范围内的人类驾驶场景和行为数据的研究得出。

注2：危害行为的验证接受准则用于判断在验证和确认过程中，对应于危害场景的危害行为可接受准则，一般是反映客观物理世界关系的量，例如，时间型、距离型、综合型指标等。

D.2.3.2.3 车辆制造商应设计量化的残余风险确认目标，以论证是否符合残余风险接受准则。

注1：参考GB/T43267—2023中C.3的方法，针对残余风险接受准则10-4/h定义确认目标为16000小时，以论证验证和确认阶段若该累积运行时间内没有发生功能不足、故障导致的安全相关事件，则有80%的置信度认为该系统符合定义的残余风险接受准则。车辆制造商可以使用其他方法定义确认目标。

注2：确认目标的实际达成效果，依赖于试验场景对ADS ODD的代表性。

D.2.4 安全措施说明

D.2.4.1 一般要求

车辆制造商应提交安全措施的说明。其中，功能安全措施应符合D.2.4.2，预期功能安全措施应符合D.2.4.3。

D.2.4.2 功能安全措施

D.2.4.2.1 车辆制造商应提交功能安全措施说明，描述 ADS 如何识别和应对危害、对应采取的功能安全措施，涵盖 D.2.4.2.2～D.2.4.2.16 的要求，并确保为实现安全目标而选择的安全措施不会在故障及非故障条件下影响车辆的安全运行。

D.2.4.2.2 安全概念应描述相应策略以避免 ADS 在系统无法执行 DDT 时操控车辆。这些策略可能包括技术解决方案或其他相关措施。

D.2.4.2.3 自动驾驶功能运行过程中，应对可能影响安全运行进而引发危害的车辆故障进行探测，若存在影响安全运行的情况，应通过警告信号或提示信息等方式告知用户，并执行后援响应。

D.2.4.2.4 在 ADS 运行过程中发生安全相关故障时，安全概念应描述为符合安全目标至少采用以下一种或多种安全措施（含外部措施）：

a) 使用 ADS 的部分系统实现 ADS 后援响应；

注： 描述的内容包括激活该模式的条件（例如，失效类型）、在此模式下自动驾驶功能行为和能力（例如，到达MRC）、向后援用户发出预警的策略（如适用）。

b) 使用独立系统实现冗余设计；

注： 描述的内容包括独立系统实现的冗余、切换机制的原则、用于确定切换的逻辑架构、该措施的局限性。

c) 执行相同功能的多样性系统设计；

注： 描述的内容包括多样性系统实现的冗余、切换机制的原则、用于确定切换的逻辑架构、该措施的局限性。

d) 限制部分或全部自动驾驶功能。

注： 描述的内容包括按照本文件的相关规定来执行此操作的方法、与自动驾驶功能相关的所有输出控制信号的抑制策略。

D.2.4.2.5 在 ADS 运行过程中，避免因电气/电子系统的单点故障导致完全失去主动转向、主动制动和主动驻车能力。

注1：根据ADS是否需要后援用户接管、故障发生的潜在可能性等，合理定义故障诊断覆盖率的要求。

注2：采用容错架构方案，适度提高MRM能力的冗余度，如采用冗余组件或通过其他系统实现替代功能，以降低因故障导致丢失MRM能力的风险到合理可接受的水平。

D.2.4.2.6ADS的故障不应直接导致车辆应急辅助功能的关闭，但对于 ADS 与应急辅助系统的共用组件发生严重故障的情况除外。

D.2.4.2.7 对于 3 级自动驾驶功能，避免因电气/电子系统的单点故障导致完全失去提醒能力。

注：用户提醒能力包含声学提醒（例如，车内语音等）、触觉提醒（例如，安全带震动、座椅震动、点刹等）和光学提醒（例如，仪表、中控屏幕、氛围灯、转向盘灯带等）等可被用户感知的方式。

D.2.4.2.8 对于可能导致丢失 MRM 的严重故障或极端情况，其残余风险应控制在合理的水平。

注1：对于合理水平的评估，在考虑累加其他潜在风险的同时，不违背残余风险接受准则的要求。

注2：对于非电气/电子系统故障导致的丢失MRM的评估，参考适用的相关技术领域标准及行业实践。

D.2.4.2.9 若存在导致系统无法执行 MRM 的严重故障或极端情况，车辆制造商应予以声明。

注：对于其他技术领域可能导致丢失MRM能力的严重故障，例如，爆胎、底盘物理损坏等，在总体残余风险评估中作为外部交互予以考虑，所分解出来的要求传递给对应技术领域。

D.2.4.2.10对于支持远程协助的ADS，应对远程通信链路的故障进行探测，若存在安全相关故障，不应使能远程协助功能。

注： 若远程协助作为ADS系统安全运行时的必须项，则及时进入MRM。

D.2.4.2.11 车辆制造商应提交 ADS 运行阶段安全保障措施的说明，针对 ADS 运行阶段可能出现的故障，具备安全监测、风险探测和缓解措施，确保系统运行阶段符合残余风险接受准则。

注： 监测、探测和缓解措施可能包括车载措施和/或非车载措施（如云端措施）。

D.2.4.2.12 安全监测和风险探测应涵盖以下异常事件的判定，以发现 ADS 潜在的安全相关故障：

a) 系统输入异常，例如，系统无输入信号、不正确的输入（含故障）；

b) 系统输出异常：

1) 未输出；

2) 不正确的输出。

c) 安全事件/事故：

1) 故障导致 MRM 激活的事件；

2) ADS 直接或间接涉及的碰撞事故。

D.2.4.2.13 针对监测到的因故障导致的安全相关事件，应具备风险评估机制，以支持判断可继续运行或需要采取应对措施。

注： 风险评估考虑安全相关事件的发生率、严重度和措施的有效性。

D.2.4.2.14 应具备现场运行中因故障导致风险问题的管理流程，包括事件或事故上报、问题调查、风险评估、对策管理、应对措施的实施和效果反馈等。

D.2.4.2.15 针对因故障导致的不可接受的运行风险事件，应具备如下风险应对措施：

a)开展调查行动以确定风险原因（例如，基于现场采集的数据重构场景）；

b) 如适用，针对系统性故障进行系统设计更新（例如，OTA 升级）。

D.2.4.2.16 功能安全措施实施后，应针对其有效性进行监测和评估，若风险仍然不合理，应进行调整。

D.2.4.3 预期功能安全措施

D.2.4.3.1车辆制造商应提交预期功能安全措施说明，涵盖 D.2.4.3.2～D.2.4.3.22 的要求，描述 ADS存在的功能不足及对应的触发条件、导致的整车危害、对应采取的安全措施。

D.2.4.3.2 自动驾驶功能运行过程中，应对可能影响安全运行进而引发危害的预期功能安全问题进行探测，若存在影响安全运行的情况，应通过警告信号或提示信息等方式告知用户，并及时执行后援响应。

注： 相关预期功能安全问题的安全分析参考D.2.5和表D.2。

D.2.4.3.3 与 ODC 相关的安全概念应包括以下内容：

a) ADS如何判定 D.1.2.1 c）所述条件的存在与否，以及任何相关联或依赖条件（例如冰雪天气下的减速）；

b)ADS在其运行中可合理预见的触发条件，包括但不限于环境和地理条件，和/或某些存在或缺失的交通/道路特征，并说明预期条件与 D.1.2.1 c）所述的 ADS 的 ODD 如何匹配；

c) 可合理预见的触发条件清单应至少涵盖表 D.2 中的条件；

d) 确保功能在不符合 ODC 的情况下无法开启的方法；

e) 对即将或突然不符合 ODC 的情况，发起后援用户响应；

f) 应对突然不符合 ODC的情况以及限制ADS频繁激活或退出情况的策略。

D.2.4.3.4 终止自动驾驶功能的预期功能安全策略应包括：

a) 针对运行中预期功能安全风险问题的判断；

b) 针对不符合安全相关 ODC 条件进行判断；

c) 针对用户关闭功能或接管合理性的判断，含用户状态的判定。

D.2.4.3.5 ADS系统与其他驾驶自动化系统之间的转换策略应包括：控制优先级、导致其他驾驶自动化系统的抑制或中断等。

D.2.4.3.6 可控性策略应包括：

a) 对于终止自动驾驶过程中确保可控性的策略；

b) 对允许用户干预/接管的 ADS 确保用户可控性的策略；

c) ODC 边界条件下合理的系统可控性保障策略（如通过识别天气情况主动降速）。

注： 对于3级自动驾驶功能主动发起介入请求的情况，从首次报警信息发出后，后援用户未接管合理的介入请求持续时间一般不少于10s，若计时结束后后援用户未接管或在此过程中风险升级，系统立即执行MRM，以最小化车辆运行风险。对于潜在的介入请求持续时间不足10s的情况，提供风险合理性的说明。

D.2.4.3.7 针对不允许行驶中退出至人工驾驶的自动驾驶功能，应描述对于乘客的安全风险清单（例如未系安全带、乘客未就座等可合理预见的误用），并描述在自动驾驶功能处于激活状态时，如何管理这些安全风险。管理安全风险的措施应包括：

a) 自动驾驶功能处于激活状态时，通过警告信号或提示信息告知乘客不安全的行为；

b) 对于发出警告提示后一定时间内乘客不纠正误用行为或期间发生风险升级时，发起 MRM 并视情况进入 MRC；

c) 对因误用引发碰撞不可避免时，执行紧急减速、紧急转向等策略以降低事故伤害或损失。

D.2.4.3.8 如适用，针对不允许行驶中退出至人工驾驶的自动驾驶功能，应描述实施的措施或策略，防止或减轻车内用户可能影响 DDT 安全执行的滥用、误用及操作失误（例如，车内用户试图接触驾驶操纵件）。

注1：通过隐藏、隔离（如机械或电子方式）等，阻断用户对驾驶控制装置的错误操作。

注2：通过提升作用力、施加反向力等方式，抵抗用户未按照接管/干预程序对驾驶控制装置的不安全操作。

D.2.4.3.9 如适用，车辆制造商应提交防止、减轻或阻止外部来源对车内用户造成伤害（例如，未授权人员试图进入载有车内用户的车辆）的措施说明。

注： 避免未授权的车外人员打开车门及前后盖，但特殊情况除外（例如，车辆发生碰撞、热失控等）。

D.2.4.3.10 如适用，车辆制造商应提交防止、减轻或阻止外部来源对车辆或其 ADS 的滥用、误用（例如，车辆运行期间被放置异物、试图损坏车辆的行为）的措施说明。

D.2.4.3.11 应描述相应的策略以避免 ADS 在车辆工作条件不佳（例如，轮胎、外部负载等的异常状态）时操控车辆。这些策略可能包括技术解决方案、物理查验或其他相关措施。

注： 针对无法通过系统自身查验的问题，如不可探测的车身改装、轮胎磨损、外部拖挂负载等，通过产品使用说明告知用户。

D.2.4.3.12 针对用户误用的策略应包括：

a) 探测用户状态的策略，例如对 3 级自动驾驶功能后援用户接管准备能力的判断及响应；

b) 判断用户操作合理性的策略，例如对用户误干预的判断及响应；

c) 对可合理预见的用户误用的风险减轻策略。

D.2.4.3.13 应描述 ADS 为避免碰撞而应采取的安全措施，包括：

a) 对道路和路面情况（例如，施工、障碍物、低附着系数路面等）进行监测；

b) 对 ORU 进行监测和行为预判；

c) 合理应对未知目标物；

d) 合理应对 ORU 的非预期行为；

e) 合理应对不可见区域；

f) 保持安全速度和距离；

g) 必要时通过应急响应避免碰撞。

D.2.4.3.14应描述ADS用于判定车辆是否与安全相关目标发生碰撞的策略。

示例：通过传感器等方式识别车辆与安全相关目标发生的碰撞。

D.2.4.3.15 应描述 ADS 用于判定与安全相关目标发生碰撞是否会造成重大损害的策略。

注1：基于碰撞目标对象、碰撞位置、碰撞相对速度、自车车速等，判定与目标发生碰撞的损害严重程度。

注2：基于历史事故或风险事件数据集，得到ADS与目标发生碰撞造成损害严重程度的规律。

D.2.4.3.16 若碰撞无法避免，ADS应对碰撞进行检测，并尽可能减轻风险，包括：

a) 通过调整自车速度以降低相对碰撞速度从而减轻碰撞严重度；

b) 使车辆达到静止状态。

D.2.4.3.17 车辆制造商应提交 ADS 运行阶段安全保障措施的说明，针对 ADS运行阶段可能出现的功能不足，具备安全监测、风险探测和缓解措施，确保系统运行阶段符合残余风险接受准则。

D.2.4.3.18 安全监测和风险探测应涵盖以下异常事件的判定，以发现 ADS 潜在的安全相关功能不足：

a) 系统输入异常：

1) 系统无输入信号、不正确的输入（含感知系统磨损和老化）；

2) 突然离开 ODD 范围；

3) 人员不合理操作或未正确接管。

b) 系统输出异常：

1) 未输出；

2) 不正确的输出。

c) 安全事件/事故：

1) 功能不足导致 MRM 激活的事件；

2) ADS 涉及的潜在风险事件（例如，应急辅助功能激活事件）；

3) ADS 直接或间接涉及的碰撞事故。

D.2.4.3.19 针对监测到的因功能不足导致的安全相关事件，应具备风险评估机制以支持判断可继续运行或需要采取应对措施。

D.2.4.3.20 应具备现场运行中因功能不足导致风险问题的管理流程，包括事件或事故上报、问题调查、风险评估、对策管理、应对措施的实施和效果反馈等。

D.2.4.3.21 针对不可接受的因功能不足导致的运行风险事件，应具备如下风险应对措施：

a)开展调查行动以确定风险原因（例如，基于现场采集的数据重构场景）；

b) 如适用，限制功能使用范围、功能降级、功能停用；

c) 如适用，针对系统功能不足进行系统设计更新（例如，ODD 更新、OTA 升级）；

d) 如适用，告知用户使用风险、更新操作限制、更新操作指导等。

注： 根据现场风险紧迫性的评估，采取立即行动或长期演进。

D.2.4.3.22 安全措施实施后，应针对其有效性进行监测和评估，若风险仍然不合理，应进行调整。

D.2.5 安全分析

D.2.5.1 一般要求

D.2.5.1.1 车辆制造商应提交整车层面和系统层面的安全分析，说明对导致表 D.1 中整车危害的故障、功能不足进行了有效识别和处理。

D.2.5.1.2 安全概念应证明车辆制造商在危害识别过程中采用了自上而下（从潜在危害到设计）和自下而上（从设计到潜在危害）的方法。

示例：FMEA、FTA、HAZOP、STPA 等。

D.2.5.1.3 系统层面的安全分析应采用适合系统安全分析的方法（例如，FMEA、FTA、STPA 或其他类似方法）。

D.2.5.1.4 针对 D.2.5.2、D.2.5.4 规定的整车及系统层面的安全分析总结，应列出系统所监测的参数，针对安全分析中的每一种故障情况，列出给予用户、维修人员、检验人员的警告信号。

D.2.5.1.5 针对 D.2.5.2、D.2.5.4 规定的整车及系统层面的安全分析总结，应描述对应的措施，确保系统在性能受环境条件（例如，气候、温度、灰尘进入、进水、冰封等）影响时，不会妨碍车辆的安全运行。

D.2.5.2 整车层面的安全分析总结

D.2.5.2.1 车辆制造商应提交整车层面的安全分析总结，且符合D.2.5.2.2～D.2.5.2.9 的要求。

D.2.5.2.2 应描述自动驾驶功能如何识别和应对危害，包括以下内容：

a) ADS 如何表现（例如，控制策略）以减轻或避免可能影响用户和 ORU 安全的危害；

b) ADS 如何应对未知危害场景。

D.2.5.2.3 应描述 ADS 与车辆其他系统的交互（含故障条件下）可能导致的潜在安全风险及对应的安全措施。

D.2.5.2.4 应描述 ADS 系统故障可能引起的整车安全风险及对应的安全措施。

D.2.5.2.5 应描述自动驾驶功能不足可能引起的整车安全风险（如由于对车辆环境感知不足导致的风险、可合理预见的误用）及对应的安全措施。

D.2.5.2.6 应描述车辆制造商推导行为能力和 ODD 相关场景的方法。

示例：基于功能不足和触发条件分析的方法。

D.2.5.2.7应描述场景识别与生成的方法，并说明该方法如何符合以下要求：

a) 涵盖适当的标称、风险及失效等场景；

b) 采用数据驱动、知识驱动、随机方法等方式系统性地识别危害事件及其他安全相关事件；

示例：数据驱动方法如已有场景或事件数据集等，知识驱动方法如行业标准、最佳实践、专家经验、推演等，随机方法如随机场景抽样等。

c) 涵盖 ODD 内体现实际交通状况的要素（尤其是动态要素）；

d) 涵盖所有相关场景要素的已识别特征和行为。

D.2.5.2.8 应描述车辆制造商的场景选择方法，该方法应覆盖 ADS 会遇到的以下可合理预见的场景及条件：

a) 充分选取了需要触发 ADS 后援响应的场景（例如，接近 ODD 边界）；

b) ADS 不可预防的场景（例如，与 ORU 的不安全行为或基础设施故障相关的）；

示例：如ORU切入、横穿等不安全行为；道路施工、红绿灯故障等基础设施故障。

c) 在选择具体场景时，使用适当的技术来探索参数空间。

示例：通过数据统计、随机生成方法。

D.2.5.2.9 应说明所定义的 ODC 场景条件的代表性。

D.2.5.3 详细整车层面的安全分析

车辆制造商应具有详细整车层面的安全分析以备查，并提供相关的企业名称、文件名、版本、状态、日期、储存位置等基本信息。

D.2.5.4 系统层面的安全分析总结

D.2.5.4.1 车辆制造商应提交系统层面的安全分析总结，且符合 D.2.5.4.2 至 D.2.5.4.5 的要求。

D.2.5.4.2 应描述 ADS 系统架构层级要素、要素的功能、要素的潜在安全相关失效模式及失效影响（含系统层面和整车层面）。

D.2.5.4.3 应描述针对系统要素失效建立的安全机制，并说明其有效性。

D.2.5.4.4应描述系统架构要素的功能不足、触发条件及系统/整车层面安全影响。

D.2.5.4.5 应描述针对功能不足及触发条件建立的安全措施，并说明其有效性。

D.2.5.5 详细系统层面的安全分析

车辆制造商应具有详细系统层面的安全分析以备查，并提供相关的企业名称、文件名、版本、状态、日期、储存位置等基本信息。

D.2.6 验证确认计划和结果

D.2.6.1 一般要求

D.2.6.1.1 车辆制造商应提交验证确认计划和结果。其中，功能安全验证确认计划和结果应符合

D.2.6.2，预期功能安全验证确认计划和结果应符合 D.2.6.4。

D.2.6.1.2 应描述车辆制造商如何确定适合的过程、资源和专业人员，以实现以下内容：

a) 设计和执行试验，用于提供支撑 ADS 安全档案的证据；

b) 选择用于场地试验的场景，由静态和动态元素组成，用于正确复现真实交通场景；

c) 识别道路试验的试验路线，包含 ODD 可预见的相关元素（例如，道路类型和拓扑结构）、标称场景中的相关元素（例如，ORU、交通标识、交通信号）及典型的动态条件（例如，拥挤/稀疏的交通流）。

注： 道路试验的试验路线也能用于标称场景中对人机交互的试验验证，包括从ODD外到在ODD内以及从ODD内到超出ODD的情况。

d) 评估 ADS 在每个场景下的 DDT 执行是否符合行为能力要求；

e) 评估 ADS 能力以保障用户安全及 ADS 的使用安全。

D.2.6.2 功能安全验证确认计划和结果总结

D.2.6.2.1 车辆制造商应提交整车层面和系统层面的验证确认计划和结果，说明对影响表 D.1 中安全目标的所有危害和故障，进行了验证和确认。验证确认应基于硬件在环测试、实车测试或其他适当的方法。

注：系统层面的范围，包括实现系统功能的传感器、控制器、执行器相关接口及处理部分。

D.2.6.2.2 功能安全验证和确认计划总结应包含以下信息：

a) 准则和目标，并解释如何选择验证及确认的场景；

b) 验证准则的评估方法；

c) 为选择的验证准则提供合理说明；

d) 包含证明目标被达成的证据的验证及确认结果（例如，验证准则符合接受准则）。

D.2.6.2.3 车辆制造商应提交系统层面的验证计划和结果总结，说明对所有影响系统功能安全概念的系统内部故障、外部接口故障及安全措施的有效性进行了验证。至少包括：

a) 验证对象，例如车辆型号、系统名称、软件和硬件版本等；

b) 验证目的，例如验证功能安全概念是否得到充分实现；

c) 验证方法及步骤概述（若通过测试开展验证，还需说明测试设备、测试环境）；

d) 接受准则；

e) 验证结果概述。

D.2.6.2.4 车辆制造商应具有详细系统层面的验证计划和结果以备查，并提供相关的企业名称、文件名、版本、状态、日期、储存位置等基本信息。

D.2.6.2.5 车辆制造商应提交整车层面的验证确认计划和结果总结，说明对所有影响表 D.1 中安全目标及功能安全概念的跨系统/组件集成结果、跨系统/组件接口故障及安全措施的有效性进行了验证，对安全目标的充分性及达成效果进行了确认，至少包括：

a) 验证和确认对象，如车辆型号、系统名称、软件和硬件版本等；

b) 验证和确认目的，如验证系统与整车其他相关系统的安全交互要求，确认安全目标正确、完整且得到充分实现；

c) 验证和确认方法及步骤概述（若通过测试开展验证或确认，还需说明测试设备、测试环境）；

d) 接受准则，包括安全度量、其他接受准则（如有）；

e) 验证和确认结果概述。

D.2.6.3 详细功能安全验证确认计划和结果车辆制造商应具有详细整车层面的验证确认计划和结果以备查，并提供相关的企业名称、文件名、版本、状态、日期、储存位置等基本信息。

D.2.6.4 预期功能安全验证确认计划和结果总结

D.2.6.4.1 预期功能安全验证和确认计划总结应包含以下信息：

a) 验证准则和确认目标：

1) 解释如何选择验证及确认的场景，以保证合理覆盖 ODC 及其边界；

2) 确定 ODC 合理覆盖度的方法、度量指标和目标；

3）依照 D.2.3.2 定义的验证的准则和确认目标；

b) 验证准则的评估方法；

c) 为选择的验证准则提供合理说明；

d) 包含证明目标被达成的证据的验证及确认结果（例如，验证准则符合接受准则）。

e) 防止 ADS 或自动驾驶功能退役后被重新激活的策略。

f) 验证对象，如车辆型号、系统名称、软件和硬件版本等；

g) 验证和确认方法及步骤概述（若通过测试开展验证或确认，还需说明测试设备、测试环境）；

h) 根据预期功能安全验证确认计划，确定了适合的验证确认过程、资源和专业人员。

D.2.6.4.2 应确认残余风险接受准则的达成，及试验里程与系统预期运行场景具有相同或高度相似的场景分布。

D.2.6.4.3 应采用合适的方法，开展针对ADS的验证和确认（例如，试验、数据驱动、分析评审等方法）。

D.2.6.4.4 试验应作为验证和确认的主要方法之一，可采用仿真试验、场地试验、道路试验等适用方法。若无法通过试验获得足够的证据，或通过试验难以符合验证和确认的全部要求时，应补充采用其他适用的方法。

示例：仿真试验中的场景生成可以使用数据回灌、数据生成等方法。

注1：数据驱动与试验相结合，以进行验证和确认。

注2：分析评审与分布式开发活动结合，以评估不可测/难测部分是否影响残余风险接受准则。

注3：若采用道路试验开展验证和确认活动，在确保交通安全的情况下，按照预期运行场景选定试验条件。

D.2.6.4.5 对于场地试验，应对静态及动态的场景元素进行选择和组合，用于正确复现试验场景。

D.2.6.4.6应根据不同的风险类型或场景类型对残余风险确认目标进行分解，针对性选择合适的验证和确认方法。

注1：在符合可信度和等效性的基础上，按一定比例分配仿真试验和实车试验的目标及试验量。

注2：若采用仿真试验方法开展验证和确认活动，对试验目标及等效试验的里程或时长的合理性进行论证。

D.2.6.4.7 对于影响安全的变更，应制定回归策略，确定是否需要重新开展全部或部分验证和确认活动。

注：对于回归策略，进行文档化和追溯管理，通过评审确保其合理性和有效性。

D.2.6.4.8 验证和确认试验所使用的仿真工具链、实车测量设备、试验车辆等应符合安全验证和确认的相关要求。

注： 若采用仿真试验方法开展验证和确认活动，选择合适的仿真试验工具链，以确保试验的准确性、结果的可信度及一致性。

D.2.6.4.9 对于通过数据驱动手段进行验证和确认的情况，应采用合适方法（例如，数据监测、影子模式等）。

注1：若通过构建基于场景或事件触发的数据监测和回流机制，进行不同场景或事件下的残余风险评估。

注2：若单独使用影子模式或与仿真试验相结合的方法，进行危害场景的风险评估与复测，对方法的有效性和可信度进行说明。

注3：若基于影子模式开展验证和确认活动，存在必要的机制以避免对ADS的正常工作产生干扰。

D.2.6.4.10 通过数据驱动手段进行验证和确认，应说明相关数据链路需符合的要求，包括数据采集、数据处理、数据传输、数据标注、数据挖掘等活动。

D.2.6.4.11 车辆制造商应提交预期功能安全验证确认结果总结，根据系统和整车层面开展的预期功能安全验证确认活动，以验证已知危害场景相关的功能不足已被优化改进或已被安全措施有效的覆盖，并证明已知和未知危害场景中的残余风险以足够的置信度符合接受准则，至少包括：

a) 对已知危害场景的验证结果总结；

b) 对已知和未知危害场景的残余风险确认结果总结。

D.2.6.4.12 应基于 D.2.5 对于触发条件的分析结果（至少涵盖表 D.2 中的触发条件），对于可能引发系统违背接受准则的触发条件及其组合，进行充分的已知危害场景的验证和确认。

注1：根据ADS的ODC定义、场景及触发条件发生的频次、严重度和相关性等因素，定性或定量地开展场景验证的重要度排序，参考GB/T 43267—2023中表B.5和表B.6的优先度子集方法。

注2：在进行危害场景生成时，考虑对ODC内、ODC边界的覆盖，根据不同触发条件类型，基于数据驱动或知识驱动，进行不同类型的场景覆盖度的定性或定量评估。

D.2.6.4.13 应采用适当方法进行已知危害场景的残余风险确认。对于不能接受的已知危害场景及对应的功能不足，制定并实施风险缓解措施，直至残余风险降低到合理水平。

注：根据已知危害场景的发生概率、严重度、涉险人员的可控性（如适用），评估对达成总体残余风险接受准则的影响。

D.2.6.4.14 已知危害场景的残余风险确认和结果认可，应判断是否符合下列条件：

a) 已知场景导致危害行为的风险不会导致违背总体残余风险接受准则；

b) 不存在可能导致特定道路使用者（包括用户和 ORU）面临不合理风险的已知危害场景。

注： 对于短期无法修复的风险场景及对应的功能不足，通过适当措施避免不合理风险（例如，基于地理位置限制自动驾驶功能的使用）。

D.2.6.4.15 应对 ADS 在未知危害场景中的残余风险进行确认，以确保具有足够的置信度符合残余风险接受准则，并符合确认目标。

注1：每次ADS发生变化（例如，算法变化、驾驶策略变化、ODC变化、目标和事件探测与响应策略变化、车型变化）时，都可能带来新的未知危害场景，因而需要重新评估残余风险。

注2：识别未知危害场景的方法如真实世界数据挖掘、影子模式、场景泛化/合成/生成、专家经验、极端和边缘场景挖掘、场景敏感度分析、用户使用研究等。

D.2.6.4.16 对基于里程累积测试的未知危害场景残余风险确认，应根据预期运行场景选择路线，包含ODD 可预见的相关元素（例如，道路类型和拓扑结构）、标称场景中的相关元素（例如，ORU、交通标识、交通信号）及典型的动态条件（例如，拥挤/稀疏的交通流），进而通过道路试验（例如，车辆长期测试、车队道路测试）等方式进行确认。

注： 由于真实世界中未知危害场景的随机分布特性，开展统计学的分析和论证以支持基于里程的确认。

D.2.6.5 详细预期功能安全验证确认计划和结果车辆制造商应具有详细预期功能安全验证确认计划和结果以备查，并提供相关的企业名称、文件名、版本、状态、日期、储存位置等基本信息。

D.2.7 安全评估发布报告总结

车辆制造商应提交安全评估发布报告总结，评估所有安全相关活动实现情况，以及每项工作成果的完整性、正确性和一致性，评估安全验证和确认活动中对系统预期运行场景的覆盖性、残余风险与接受准则的符合性，应包括：

a) ADS 在每个测试场景下的 DDT 执行是否符合行为能力（危害行为接受准则）的要求的评估；

b) 考虑全部功能安全和预期功能安全活动中识别的风险后，ADS 能力是否足以保障用户安全及ADS 的使用安全，总体残余风险是否符合接受准则的评估；

注： 功能安全方面评估系统实现了安全目标，且无导致违背安全目标的问题或存在的问题风险可接受。

c) 功能安全和预期功能安全评估发布的结论；

d) 运行阶段的功能安全和预期功能安全监测及保障措施总结，以有效识别系统运行阶段的残余风险，并针对不合理的残余风险问题及时实施保障措施。

D.3 声明、论据和证据

D.3.1 一般要求

D.3.1.1 安全档案应包括一系列声明，至少应：

a) 每项声明至少有一项论据支持；

b) 每项论据至少有一项证据支持；

c) 每项声明、论据和证据应有唯一的标识。

注： 一项证据可能支持不止一项论据。

D.3.1.2 以下要求均应至少对应一项声明：

a) D.3.1.3 涉及章节中规定的各项要求；

b) D.3.1.4、D.3.1.5 规定的各项要求；

c) 车辆制造商自行规定的各项要求（如有）。

注：若一项宽泛的声明不充分或需要额外的解释，则可能创建多项子声明，只要子声明符合逻辑连贯性且声明间的关系说明在总结文档中被包括。

D.3.1.3 声明、论据和证据应易被理解、符合逻辑、正确和稳健，并证明：

a) ADS 对用户及 ORU 不会造成不合理的风险；

b) ADS 符合本文件的以下要求：

1) DDT 执行要求（5.1）；

2) 人机交互要求（5.2）；

3) 用户告知要求（5.3）；

4) 其他要求（5.4）。

D.3.1.4 声明、论据和证据应描述如何将 SMS（6.1）应用于 ADS 全生命周期的安全管理。

D.3.1.5 声明、论据和证据应证明所采用的试验方法适用于安全档案以及性能或功能要求的符合性证明。

D.3.1.6 声明、论据和证据应提供以下总结信息：

a) 确定声明及其支持论据和证据之间关系；

b) D.3.1.2 涉及的每项要求都被识别且符合。

D.3.1.7 与声明、论据和证据相关的各项相关假设均应说明。

D.3.1.8 支持声明的每项论据都应提供背景信息和支持信息，解释如何根据一系列适当的证据符合声明。

D.3.1.9 支持论据的证据应包括试验结果或分析（例如，系统布局及示意图、图片、所需文档等）。

D.3.2 生成证据的试验活动要求

D.3.2.1 生成证据的试验条件要求

D.3.2.1.1 用于生成证据的仿真试验条件应符合 6.2.1 的要求，安全档案中的仿真试验条件描述应至少包括：

a) 仿真试验的预期用途及其在整体试验方案中的作用；

b) 考虑 6.2.1.7 要求的关键性分析结果，以提供支撑安全档案的证据并用于评估 ADS 是否符合功能要求或用户要求；

c) 仿真工具链及其组件；

d)仿真工具链的限制、假设以及可能影响结果的不确定性来源（6.2.1.5）；

e) 仿真工具链的适用范围（6.2.1.6）；

f) 确认仿真工具链的方法（6.2.1.9.7）；

g) 验收试验（6.2.1.9.3）和验收准则（6.2.1.9.4），用于确认仿真工具链能生成支撑安全档案所需的证据（6.2.1.9.2、6.2.1.9.8）。

D.3.2.1.2 用于生成证据的场地试验条件应符合 6.2.2 的要求，安全档案中的场地试验条件描述应至少包括：

a) 预期用途及其在整体试验方案中的作用；

b) 体现 ODC 和预期运行工况的静态和动态元素。

D.3.2.1.3 用于生成证据的道路试验条件应符合 6.2.3 的要求，安全档案中的道路试验条件描述应至少包括：

a) 预期用途及其在整体试验方案中的作用；

b) 所选试验路线及其路线选择策略。

D.3.2.2 生成证据的试验场景及其管理的要求

D.3.2.2.1 用于得出与 ADS 的 ODC 及安全档案相关的 ADS 行为能力采用的过程应适当。

D.3.2.2.2 识别和生成场景的方法应符合 D.2.5.2.7 的要求。

D.3.2.2.3 生成和识别的场景集应适用于证明安全档案并能涵盖 ADS 在实际运行中可能遇到的可合理预见的场景和条件。作为支持安全档案的证据所选择的场景集应至少包括以下内容：

a) 触发 ADS 后援响应的场景（例如，不符合 ODC）；

b) 可合理预见且不可预防的场景（例如，ORU 的不安全行为或基础设施故障）。

D.3.2.2.4 选择具体场景时应采用适当的技术来探索参数空间。

D.3.2.3 生成证据的试验过程的要求

D.3.2.3.1 生成证据的试验过程应符合 D.2.6.1.2 的要求。

D.3.2.3.2 生成证据的试验过程应适当且符合以下要求：

a) 识别需要采用不同试验方法开展试验的场景；

b) 验证所采用的不同试验方法之间试验结果的一致性。

D.3.2.4 试验结果的要求

D.3.2.4.1 试验结果应包括适当的验收准则。

注： 试验结果可能单独提供或汇总提供。

D.3.2.4.2 试验结果应能证明 ADS 在执行 DDT 时的行为能力，至少证实了安全档案中以下情况的声明和论据：

a) 在标称场景、风险场景和失效场景下；

b) 从符合到不符合 ODC 时；

c) 在无法避免与 ORU 发生碰撞的情况下。

D.3.2.4.3每项试验应包括足够的信息，或以可根据要求复现的方式记录（例如，相同的软件/硬件版本、相同的工具版本、相同的场景、相同的参数等）。为便于复现该证据，车辆制造商应为必要的工具和分析软件提供获取和执行条件。

D.3.2.5 试验证据的要求

D.3.2.5.1 试验证据应来源于经过充分描述的仿真试验、场地试验和道路试验的组合，并表明试验方法间结果的一致性。

D.3.2.5.2 仿真试验证据应至少包括风险场景及低概率事件。风险场景应至少包括可能导致碰撞的场景。

D.3.2.5.3 场地试验证据的场景中应至少包括可导致碰撞的风险场景。

D.3.2.5.4 道路试验收集的证据应至少符合：

a) 涵盖 ADS 在实际运行中可能遇到的各种场景和条件，覆盖预期运行的道路类型；

b) 若 ADS 在道路试验过程中遇到风险场景或失效场景，结合场地试验和仿真试验的结果考虑ADS 的响应，包括与标称场景下 DDT 执行要求的任何差异。

D.3.2.5.5 与交互相关的特定试验用例应符合：

a) 参与试验的人群能够代表预期的用户群体以及 ORU 群体（如适用）；

b) 所获数据结果具备统计显著性。

D.4 车辆制造商安全档案内审要求

D.4.1 作为符合6.1.4的要求的部分证明，车辆制造商应在型式批准之前评审其安全档案。

注： 建议在开发过程中实现。

D.4.2 内审员应保持独立性，不应受任何可能威胁其公正客观评审安全档案能力的影响。

注： 内审员可能是车辆制造商的内部或外部人员。

D.4.3 内审应被记录、可供查验，包括：

a) 内审员或内审团队的资格；

b) 内审日期或周期；

c) 被内审的安全档案、工具和 ADS 的版本；

d) 用于内审安全档案的方法；

e) 任何可复现的证据清单；

f) 已识别的偏差项、问题、置信度较低的部分或尚不明确的部分。

D.4.4 车辆制造商应在每次内审后合理的时限内，将针对所发现问题的整改或完善措施（例如，版本发布说明）纳入内审文档。