ChinaAutoRegs｜GB/T-2022英文版翻译 智能网联汽车 自动驾驶系统通用技术要求
Intelligent and connected vehicle—General technical requirements for automated driving system
1 范围
本标准规定了自动驾驶系统的总体要求、动态驾驶任务执行要求、动态驾驶任务后援要求、人机 交互要求、说明书。
本标准适用于装备自动驾驶系统的M类、N类汽车。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文 件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适 用于本文件。
GB/T 40429-2021 汽车驾驶自动化分级
GB/T XXXXX-XXXX 智能网联汽车 术语和定义
GB XXXXX-XXXX 智能网联汽车 自动驾驶数据记录系统
GB/T XXXXX-XXXX 汽车软件升级通用技术要求
GB/T XXXXX-XXXX 汽车整车信息安全技术要求
GB/T XXX-XXXX 智能网联汽车 自动驾驶功能场地试验方法及要求
GB/T XXX-XXXX 智能网联汽车 自动驾驶功能道路试验方法及要求
GB/T XXX-XXXX 智能网联汽车 操纵件、指示器及信号装置的标志
3 术语和定义
GB/T 40429-2021、GB/T XXXXX-XXXX界定的以及下列术语和定义适用于本文件。
3.1
自动驾驶功能 automated driving function 驾驶自动化系统在特定的设计运行条件下代替驾驶员持续自动地执行全部动态驾驶任务的功能。 注：GB/T 40429-2021中规定的3级及以上驾驶自动化功能的总称，包括“有条件自动驾驶”“高度自动驾驶”和
“完全自动驾驶”功能
[来源：GB/T XXXXX-XXXX，6.4]
3.2
自动驾驶系统 automated driving system；ADS 实现自动驾驶功能的硬件和软件所共同组成的系统。 注：“自动驾驶系统”为GB/T 40429-2021规定的3级及以上驾驶自动化系统。 [来源：GB/T XXXXX-XXXX，5.3]
3.3
设计运行范围 operational design domain；ODD 驾驶自动化系统设计时确定的适用于其功能运行的外部环境条件。 注：典型的外部环境条件有道路、交通、天气、光照等。
[来源：GB/T 40429-2021，2.11]
3.4
设计运行条件 operational design condition；ODC
驾驶自动化系统设计时确定的适用于其功能运行的各类条件的总称，包括设计运行范围、车辆状
态、驾乘人员状态及其他必要条件。 [来源：GB/T 40429-2021，2.12]
3.5
动态驾驶任务 dynamic driving task；DDT
除策略性功能外的车辆驾驶所需的感知、决策和执行等行为，包括但不限于：
——车辆横向运动控制；
——车辆纵向运动控制；
——目标和事件探测与响应；
——驾驶决策；
——车辆照明及信号装置控制。 注1：策略性功能如导航、行程规划、目的地和路径的选择等。 注2：动态驾驶任务一般由驾驶员、驾驶自动化系统或由两者共同完成。 [来源：GB/T 40429-2021，2.4]
3.6
目标和事件探测与响应 object and event detection and response；OEDR
对目标和事件进行探测，并进行适当的响应。 [来源：GB/T 40429-2021，2.7]
3.7
最小风险状态 minimal risk condition (MRC)
车辆事故风险可接受的状态。 [来源：GB/T 40429-2021，2.8]
3.8
最小风险策略 minimal risk maneuver；MRM 驾驶自动化系统无法继续执行动态驾驶任务时，所采取的使车辆达到最小风险状态的措施。 [来源：GB/T 40429-2021，2.9]
3.9
动态驾驶任务后援 dynamic driving task fallback
当发生即将超出设计运行范围、驾驶自动化系统失效或车辆其他系统失效等不满足设计运行条件
的情况时，由用户接管或由驾驶自动化系统执行最小风险策略的后备支援行为。 [来源：GB/T 40429-2021，2.10]
3.10
介入请求 request to intervene 驾驶自动化系统请求动态驾驶任务后援用户执行接管的通知。 [来源：GB/T 40429-2021，2.13]
3.11
接管 take over 动态驾驶任务后援用户响应介入请求，从驾驶自动化系统获得车辆驾驶权的行为。 [来源：GB/T 40429-2021，2.14]
3.12
用户 user
与驾驶自动化相关的人类角色的统称。 注：用户的角色可以在特定的条件下进行转换。 [来源：GB/T 40429-2021，2.17]
3.13
驾驶员 driver 对于某个具体的车辆，实时执行部分或全部动态驾驶任务和/或接管的用户。 [来源：GB/T 40429-2021，2.17.1]
3.14
自动驾驶数据记录系统 data storage system for automated driving；DSSAD
装备在具备自动驾驶功能的车辆上、在自动驾驶系统激活期间具备监测、采集、记录和存储数据 功能并支持读取记录数据的系统。
[来源：GB/T XXXX-XXXX,5.13]
3.15
未激活状态 inactive state
ADS未执行车辆横向运动控制或车辆纵向运动控制的状态。
3.16
未就绪状态 not ready state
ADS不可被激活的未激活状态。
3.17
就绪状态 ready state
ADS可被激活的未激活状态。
3.18
激活状态 active state
ADS执行车辆横向运动控制和车辆纵向运动控制的状态。
3.19
ADS 严重失效 severe ADS failure 针对ADS必要部件的一种发生概率非常低但影响ADS安全运行的失效。 注：单个传感器失效，只有当影响系统安全运行时，才会被视为严重失效。
3.20
车辆严重失效 severe vehicle failure 任何影响ADS执行DDT能力且影响车辆手动操作的车辆失效。 示例：电源掉电、制动系统失效、胎压突然下降。
3.21
计划接管事件 planned takeover event
ADS预先知晓并需要发出介入请求的事件。
3.22
非计划接管事件 unplanned takeover event
ADS 非预先知晓但假设极有可能发生，并需要发出介入请求的事件。
示例：道路施工、车道标线消失等。
3.23
干预 intervene
用户主动通过系统已明确的有效方式影响驾驶自动化系统执行动态驾驶任务的行为。
3.24
安全目标 safety goal 由整车层面危害分析和风险评估得出的最高层面的安全要求。 [来源：GB/T 34590.1-2017，2.108，有修改]
3.25
安全措施 safety measures
用以避免或控制系统性失效、探测随机硬件失效，控制随机硬件失效或减轻它们的有害影响的活 动或技术解决方案。
[来源：GB/T 34590.1-2017，2.110]
3.26
接受准则 accepted criteria
代表不存在不合理的安全风险的准则。
3.27
控制策略 control strategy
针对一组特定的环境和/或运行条件（例如：道路表面条件，交通流密度和其他道路使用者，不利 的天气条件等），确保系统各种功能鲁棒、安全运行的策略。
示例：自动关闭功能、降低最高运行速度。
4 总体要求
4.1 ADS 应具有明确的设计运行条件，设计运行条件可参考 GB/TXXXX《智能网联汽车 自动驾驶系统 设计运行条件》。
4.2 ADS 应仅允许在其设计运行条件下被激活。
4.3 ADS 应及时响应用户的有效操作，若用户的操作将导致紧迫的碰撞风险，ADS 可根据车辆制造商 声明的方式暂缓响应用户的操作。若 ADS 具备暂缓响应功能，应具有明确的暂缓响应的条件。
4.4 ADS 应采取适当的控制策略处理可合理预见的用户误用。
4.5 ADS 应持续执行自检，以检测 ADS 的失效并确认系统可执行全部 DDT。
4.6 ADS 在激活状态下，应执行全部 DDT，且不应造成不合理的安全风险。
4.7 ADS 在激活状态下，执行 DDT 应符合道路交通规定。
4.8 ADS 在激活状态下，执行 DDT 应符合其他道路使用者的预期。
4.9 ADS 在激活状态下，应确认支持驾驶员恢复人工驾驶所需的装置或系统处于适当状态。
注：所需的装置或系统如除雾装置、挡风玻璃雨刷器、照明装置。
4.10 ADS 在激活状态下，针对可合理预见且可预防的场景，应避免导致碰撞事故。
4.11 ADS 在激活状态下，当碰撞事故不可避免时，ADS 应采取合理控制策略降低事故伤害或损失。
4.12 ADS 在激活状态下，当 ADS 检测到车辆发生碰撞事故后，除车辆制造商声明的情况外，应使车辆 静止，且至少应通过车辆制造商声明的方式进行安全检测，才允许再次被激活。
4.13 ADS 在激活状态下，当设计运行条件即将不满足或已经不满足时，ADS 应执行合理的控制策略。
4.14 ADS 在激活状态下，ADS 应与其他道路使用者进行有效的信息交互。
注：信息交互方式如转向信号灯、制动灯等。
4.15 ADS 在激活状态下，ADS 应避免扰乱正常的交通流而导致整体通行效率下降。
4.16 装备 ADS 的车辆应具备自动驾驶数据记录系统，自动驾驶数据记录系统应符合 GB XXXX-XXXX
《智能网联汽车 自动驾驶数据记录系统》。
4.17 装备 ADS 的车辆应符合 GB XXXXX-XXXX《汽车整车信息安全技术要求》。
4.18 若 ADS 具备软件升级功能，装备 ADS 的车辆应符合 GB XXXXX-XXXX《汽车软件升级通用技术要 求》。
4.19 ADS 应不存在由于功能异常表现引起的危害而导致的不合理风险，应符合附录 A。
4.20 ADS 应不存在由预期功能不足或合理误用引起的危害而导致的不合理风险，应符合附录 A。
4.21 应通过合理方式证明 ADS 符合本文件要求，包括但不限于审核、仿真试验、场地试验和道路试 验。应在审核的基础上，优先采用场地试验和道路试验开展验证，分别按照 GB/TXXX-XXXX《智能网联 汽车 自动驾驶功能场地试验方法及要求》和 GB/TXXX-XXXX《智能网联汽车 自动驾驶功能道路试验方 法及要求》开展；若开展仿真试验，应先对仿真工具链和模型进行可信度评估。证明方式选择可参考 附录 B。
5 动态驾驶任务执行
5.1 ADS 应具备充分的 OEDR 能力，支持其安全且合理地执行全部 DDT。
5.2 ADS 的感知能力应覆盖足够的范围。
5.3 ADS 应能持续识别 ODC 是否满足。
5.4 ADS 应以合理的控制策略应对传感系统的性能衰退。
5.5 ADS 至少应能确定自车位置、探测周围环境中的目标和事件，例如：
a) 道路，含道路类型、道路表面条件、道路几何、车道特征、道路边缘等；
b) 道路设施，含交通标志、交通信号灯等；
c) 目标物，含机动车、非机动车、行人、障碍物等；
d) 天气环境，含天气、光照条件等；
e) 数字信息环境，含无线通信、位置信号等。
5.6 ADS 应能探测目标的位置以及动态目标的移动速度。
5.7 ADS 应以合理的控制策略应对探测到但无法识别类型的目标物。
5.8 ADS 应以合理的控制策略应对无法探测区域内存在的安全风险。
注：无法探测区域如传感器布置及感知范围造成的盲区、由其他交通参与者或障碍物遮挡造成的盲区、道路拓扑 或形状造成的盲区等。
5.9 ADS 应合理规划和控制车辆行驶路径与行驶速度，以适应道路、道路设施、目标物、天气环境、 数字信息环境等。
5.10 ADS 应以合理控制策略应对静止的其他道路使用者。
5.11 ADS 应避免与车辆前方无遮挡的行人发生碰撞，若因行人行为导致无法避免碰撞，ADS 应尽可能 减缓碰撞。
5.12 ADS 应至少探测由于前方车辆减速、车辆切入或突然出现的障碍物而导致碰撞的风险，并应自 动执行适当的控制策略以最大限度地减少对车辆驾乘人员和其他道路使用者的安全风险。
5.13 ADS 应控制车辆与其他道路使用者保持足够的安全距离，若其他道路使用者的行为导致当前距 离无法满足安全距离要求，则应执行适当的控制策略以降低安全风险，在后续合适时机调整保持安全 距离。
5.14 ADS 不应导致车辆失去控制出现倾覆等。
5.15 ADS 应合理控制车辆的照明和光信号装置，包括但不限于转向信号灯、危险警告信号、制动灯。
6 动态驾驶任务后援
6.1 驾驶员接管能力监测系统
6.1.1 一般要求
6.1.1.1 对于需要驾驶员执行接管的 ADS，应具备驾驶员接管能力监测系统。
6.1.1.2 驾驶员接管能力监测系统至少应具备在位监测和执行 DDT 能力监测。
6.1.2 驾驶员在位监测
ADS在激活状态下，当满足以下任一条件时，ADS应按照6.2发出介入请求： a) 驾驶员不在驾驶位超过 1 s；
b) 驾驶员未系安全带。
6.1.3 驾驶员执行 DDT 能力监测
6.1.3.1 驾驶员接管能力监测系统应至少通过 3 种不同的指标（例如特定的人机交互动作、眨眼、闭 眼、有意识的头部或身体运动等）对驾驶员状态进行监测和判定，
6.1.3.2 驾驶员接管能力监测系统判定驾驶员是否具备执行 DDT 能力的周期应不超过 30 s。
6.1.3.3 当 ADS 处于激活状态，若驾驶员被判定为不具备执行 DDT 的能力时，驾驶员执行 DDT 能力监 测系统应立即发出明确的接管能力不足提示信号，每次发出的能力不足提示信号应在满足以下任一条 件时关闭：
a) 监测到驾驶员恢复接管能力；
b) ADS 发出介入请求；
c) ADS 执行 MRM；
d) ADS 退出。
6.1.3.4 接管能力不足提示信号应明显区别于车辆其他提示信号。
6.1.3.5 接管能力不足提示信号发出 15 s 内，ADS 应按照 6.2 发出介入请求。
6.2 接管
6.2.1 一般要求
对于需要驾驶员执行接管的ADS，应具备安全、可靠、有效的接管策略，并应能够检测驾驶员是否 执行接管操作。
6.2.2 发出介入请求
6.2.2.1 对于需要驾驶员执行接管的 ADS，应具备明确的介入请求触发条件，且 ADS 应能识别需要发 出介入请求的所有情况，当不满足 7.1.2.1 中任一条件时，除本文件规定的特殊条款，ADS 应发出介入 请求。
6.2.2.2 介入请求的发出时机应保证驾驶员有足够的时间安全接管车辆，至少应满足以下要求： a) 对于计划接管事件，ADS 应在适当的时刻发出介入请求，以确保即使驾驶员未接管，最小风
险策略仍能使车辆在计划接管事件发生前停止；
b) 对于非计划接管事件，ADS 应在检测到该事件时及时发出介入请求；
c) 对于影响 ADS 安全运行的失效，ADS 应在检测到该失效时立即发出介入请求。若该失效为 ADS
严重失效或车辆严重失效，则 ADS 可不发出介入请求，直接执行 MRM。
6.2.3 介入请求阶段
6.2.3.1 在介入请求发出过程中，ADS 应持续执行全部 DDT。
6.2.3.2 在介入请求发出过程中，除车辆制造商声明的特殊情况，ADS 不应使车辆静止。若因特殊情 况使车辆达到静止，应在静止 5 s 内激活危险警告信号。
6.2.4 终止介入请求
6.2.4.1 仅当 ADS 被用户退出或执行 MRM，才能终止介入请求。
6.2.4.2 介入请求从发出到因执行 MRM 而终止的时间应至少保持 10 s，以确保驾驶员有充足的时间接 管车辆。若发生车辆制造商所声明的无法保障驾驶员有充足的时间接管车辆的危险情况，可立即执行 MRM。
6.3 最小风险策略
6.3.1 执行 MRM
6.3.1.1 ADS 应有明确的执行 MRM 的条件，且 ADS 应能识别需要执行 MRM 的所有情况，至少应包括： a) 对于需要驾驶员执行接管的 ADS，驾驶员未在车辆制造商声明的时间内响应介入请求，所声
明时间应不小于 10s。
b) 对于不需要驾驶员执行接管的 ADS，当 ODC 即将不再满足，ADS 及时执行 MRM 并确保车辆在不 满足 ODC 之前达到静止。
c) 对于不需要驾驶员执行接管的 ADS，当 ODC 已经不再满足，ADS 立即执行 MRM 并确保车辆达到 静止。
6.3.1.2 当 ADS 执行 MRM 时，ADS 应将用户和其他道路使用者的安全风险降至最低。
注：在执行MRM期间，ADS可能不再有能力满足本文件第4和5章的要求，但其目标是使安全风险降至最低。
6.3.1.3 当 ADS 执行 MRM 时，ADS 应开启并保持危险警告信号，在车辆换道期间应暂停危险警告信号。
6.3.1.4 除非 ADS 在执行 MRM 期间被退出，否则 MRM 应使车辆停止。
6.3.2 终止 MRM
6.3.2.1 仅当 ADS 被用户退出或 ADS 使车辆静止后，才应终止 MRM。
6.3.2.2 当终止 MRM 后，ADS 应退出。
6.3.2.3 当因车辆静止而终止 MRM 后，不应因 ADS 退出导致关闭危险警告信号。
7 人机交互
7.1 激活和退出
7.1.1 一般要求
7.1.1.1 ADS 应配备供用户激活和退出 ADS 的专用操纵方式，该方式应防止用户可合理预见的误用。
注：专用操纵方式如专用的操纵件或对操纵件的专用操纵方式等。
7.1.1.2 当 ADS 处于激活状态时，至少一种退出 ADS 的操纵方式对用户应总是可见的。
7.1.1.3 车辆每次点火（上电）后（发动机自动启停除外），ADS 应处于未激活状态。
7.1.2 激活
7.1.2.1 对于需要驾驶员执行接管的 ADS，仅当驾驶员执行激活操作且满足以下所有条件时，ADS 才 应被激活：
a) 驾驶员坐在驾驶位置上，且系好安全带；
b) 驾驶员具备执行 DDT 能力；
c) ADS 通过自检确认，且不存在影响 ADS 运行的失效；
d) DSSAD 处于工作状态；
e) 车辆未正在执行影响 ADS 运行的软件升级；
f) 车辆制造商声明的其他设计运行条件。
7.1.2.2 对于不需要驾驶员执行接管的 ADS，仅当用户执行激活操作且满足以下所有条件时，ADS 才 应被激活：
a) ADS 通过自检确认，且不存在影响 ADS 运行的失效；
b) DSSAD 处于工作状态；
c) 车辆未正在执行影响 ADS 运行的软件升级；
d) 车辆制造商声明的其他设计运行条件。
7.1.3 退出
7.1.3.1 当用户通过专用操纵方式退出 ADS 时，ADS 应及时退出。仅当用户执行的退出操纵将产生碰 撞风险时，系统可暂缓退出。
7.1.3.2 除 7.1.3.1 外，应满足如下任一条件时，ADS 才可退出： a) 驾驶员按照 7.2.2 干预横向控制；
b) 驾驶员按照 7.2.3.1 干预纵向控制，且车辆横向运动被驾驶员控制；
c) 在介入请求发出或执行 MRM 过程中，驾驶员手握转向盘，且 ADS 确认驾驶员专注于 DDT；
d) 终止 MRM。
7.1.3.3 在发生车辆严重失效或 ADS 严重失效的情况下，ADS 可采用车辆制造商声明的其他安全退出 策略。
7.1.3.4 ADS 的退出不应导致：
a) 任何应急辅助功能自动关闭；
b) 任何部分驾驶辅助功能或组合驾驶辅助功能自动激活。
7.2 干预
7.2.1 一般要求
ADS应具备安全、可靠、有效的干预策略，并应能检测驾驶员是否执行干预操作。
7.2.2 横向控制干预
当驾驶员对转向控制的干预超过车辆制造商声明的为防止误用而设计的合理阈值时，且确认驾驶 员专注于DDT，ADS应执行驾驶员输入的横向控制。
7.2.3 纵向控制干预
7.2.3.1 当驾驶员对制动控制的干预产生比 ADS 引起的减速度更大，或通过任何制动系统使车辆保持 静止时，ADS 应执行驾驶员输入的制动控制。
注：驾驶员对加速控制的输入也可能干预ADS的纵向控制。
7.2.3.2 对于需要驾驶员执行接管的 ADS，当驾驶员对制动或加速控制的干预超过为防止误用而设计 的合理阈值时，ADS 应发出介入请求或执行 MRM。
7.2.3.3 对于不需要驾驶员执行接管的 ADS，当驾驶员对制动或加速控制的干预超过为防止误用而设 计的合理阈值时，ADS 应具备合理的控制策略。
7.2.4 干预抑制
若驾驶员的干预将导致紧迫的碰撞风险，ADS可根据车辆制造商声明的方式减弱或抑制驾驶员的干 预对任何控制的影响。
7.2.5 其他干预策略
7.2.5.1 在发生车辆严重失效或 ADS 严重失效的情况下，ADS 可采用车辆制造商声明的其他安全干预 策略。
7.2.5.2 若驾驶员操纵车辆其他干预装置，ADS 应对驾驶员进行提示，并按照车辆制造商声明的控制 策略执行。
注：其他干预装置如急停装置。
7.3 系统状态提示
7.3.1 一般要求
ADS应持续向用户提示明确、充分的ADS状态信息，不应对用户造成干扰。当ADS状态发生变化时， ADS应及时向用户提供必要的提示信息。
7.3.2 未就绪状态提示
若由于ADS未就绪而导致用户激活系统失败，则应向用户直观地提示。
7.3.3 就绪状态提示
当ADS处于就绪状态时，应至少通过光学信号向用户提示系统可被激活。
示例：视觉文字、图标指示等。
7.3.4 激活状态提示
7.3.4.1 ADS 由未激活状态进入激活状态时，应通过专用的光学信号向用户提示 ADS 已激活。
7.3.4.2 ADS 处于激活状态时，应通过光学信号向用户进行持续提示。
7.3.5 退出提示
ADS由激活状态退出至未激活状态时，应通过两种以上的方式向用户提示ADS已退出，至少包括光 学信号。由于驾驶员接管导致ADS退出，可仅用光学信号提示。
7.3.6 介入请求
7.3.6.1 介入请求应至少包含光学和声学提示信号。
7.3.6.2 介入请求的光学提示信号应直观和明确地提示驾驶员介入请求的响应方式，应至少包括手和
方向盘的信息，应符合 GB/T XXXX-XXXX《智能网联汽车 操纵件、指示器及信号装置的标志》4.1 表 1
的要求。
7.3.6.3 在介入请求发出过程中，介入请求应在发出 4 s 内升级并保持升级状态至介入请求结束，升 级的介入请求应增加持续或间歇性的触觉提示。
7.3.7 MRM 提示
7.3.7.1 在 ADS 执行 MRM 过程中，应对用户给出明显提示，提示方式应至少包括光学信号，并附加声 学或触觉信号。
7.3.7.2 ADS 处于 MRC 时，应至少以光学、声学或触觉中的两种信号提示用户直至 ADS 退出。
7.3.7.3 对于需要接管的 ADS，MRM 的提示信号应与介入请求不同。
7.3.8 失效提示
在ADS激活状态下，若检测到ADS失效，应对用户给出明显提示，应至少包括光学提示信号。
8 说明书
对于装备ADS的车辆，其产品说明书至少应包含： a) “本车具备 ADS”等内容的说明；
b) ADS 允许被激活的设计运行条件的说明；
c) 激活 ADS 的方法及条件的说明； d) ADS 就绪状态提示信号的说明； e) ADS 激活状态提示信号的说明； f) ADS 是否需要接管的说明；
g) 若 ADS 需要接管，“本车 ADS 在特定条件下需要被驾驶员接管”等内容的说明；
h) 若 ADS 需要接管，介入请求的说明； i) 若 ADS 需要接管，接管 ADS 的方法； j) 驾驶员接管能力不足提示信号的说明； k) 干预 ADS 的方法及结果的说明；
l) ADS 执行 MRM 的条件的说明；
m) ADS 执行 MRM 期间的提示信号的说明； n) ADS 执行 MRM 的状态及结果的说明； o) 退出 ADS 的方法及条件的说明；
p) 发生碰撞事故后，对用户的建议。
附录 A
（规范性）
适用于 ADS 的安全性的特殊要求
A.1 总则
本附录旨在确保车辆制造商在自动驾驶系统设计和开发过程中对功能安全和预期功能安全进行了 充分的考虑，并贯穿整个车辆的生命周期过程（设计、开发、生产、在用、报废），以避免因自动驾 驶系统故障、预期功能不足以及合理误用导致的对驾驶员、乘客和其他道路使用者造成不合理的风险， 确保自动驾驶系统的运行安全。
本附录规定了自动驾驶系统在功能安全和预期功能安全方面的特殊要求。 本附录不针对自动驾驶系统的标称性能，也不作为自动驾驶系统功能安全和预期功能安全开发的
具体指导，而是规定自动驾驶系统设计、验证和确认过程中应遵循的方法和应具备的信息，作为满足 功能安全和预期功能安全的依据。
A.2 文档
A.2.1 总体要求
A.2.1.1 车辆制造商应建立覆盖车辆全生命周期的功能安全和预期功能安全流程。 注：功能安全流程与预期功能安全流程可合一。
A.2.1.2 车辆制造商应具有相应的文档以证明自动驾驶系统在声明的 ODC 内（包括边界）不会对驾驶 员、乘客和其他道路使用者造成不合理的风险。
A.2.1.3 车辆制造商应确保文档和分析数据在该车型确定停产后的 10 年内保持可用。
A.2.2 系统功能描述
A.2.2.1 车辆制造商应具有相应的文档，用来对自动驾驶系统的功能（包括其对应的驾驶控制策略） 进行描述。
A.2.2.2 车辆制造商应具有相应的文档，用来对在设计运行条件内执行动态驾驶任务所采取的方法以 及对应的系统设计运行条件进行描述。
A.2.2.3 车辆制造商应具有相应的文档，用来对自动驾驶系统与驾驶员、乘员和其他道路使用者预期 的交互以及人机界面进行描述，包括当达到系统运行边界时的人机交互（HMI）和系统向驾驶员发出接 管请求的各种情况。
A.2.2.4 车辆制造商应具有相应的文档，用来对系统激活、干预（包括干预的阈值，例如力矩、角度、 持续时间）、最小风险策略和系统退出进行描述，包括如何防止非预期的系统退出策略。此外，如适用， 还包括系统如何确认驾驶员状态（例如，是否具备动态驾驶任务接管能力）的相关说明。
A.2.2.5 车辆制造商应具有相应的文档，用来对感知系统的输入、输出，以及感知系统正常工作范围
（包括应对传感器的衰退）以及感知系统对 ADS 行为的影响进行描述。
A.2.2.6 车辆制造商应具有相应的文档，用来对决策系统的输出，以及对车辆运动控制的影响进行描 述。
A.2.2.7 如果包含连续学习算法，车辆制造商应具有相应的文档，用来对数据处理过程进行描述。
A.2.3 系统布局和原理图
A.2.3.1 系统组件清单
A.2.3.1.1 车辆制造商应具有组件清单，该清单应包含自动驾驶系统的所有单元，同时也应列出为实 现相关自动驾驶功能所需的车辆其它系统。
A.2.3.1.2 车辆制造商应具有自动驾驶系统布局及原理图，该图应能够清晰地展示组件分布和相互连 接。
A.2.3.1.3 布局及原理图应包括：
a) 感知系统（包含地图和定位系统，如适用）；
b) 决策系统；
c) 由远程后台提供的远程监管或远程监控（如果适用）。
A.2.3.2 单元功能
车辆制造商应具有相应的文档，用来概述系统各单元的功能，并展示该单元与其它单元或车辆其 它系统间的连接。可使用带标记的框图或其它示意图说明。
A.2.3.3 单元的识别
A.2.3.3.1 车辆制造商应具有相应的文档，文档中应能清晰明确地识别每个单元（例如，硬件单元、 软件单元）并提供相应的说明。
A.2.3.3.2 车辆制造商应明确标识硬件和软件的版本。
A.2.3.4 感知系统组件的安装说明
车辆制造商应具有相应的文档，用来说明感知系统中单个组件的安装信息。这些信息应包括但不 限于：
a) 部件在车辆上的位置；
b) 部件外表面的材料；
c) 部件外表面的尺寸和形状；
d) 部件外表面的光洁度；
e) 对ADS性能影响大的安装规范。
A.2.4 危害分析和风险评估
A.2.4.1 车辆制造商应根据系统控制下的车辆目标使用场景及目标用户，在整车层面开展面向功能安 全的危害分析和风险评估，并定义相应的汽车安全完整性等级(ASIL)和安全目标，符合 GB/T 34590.3- XXXX 第 6 章的要求。
A.2.4.2 车辆制造商应根据系统控制下的车辆目标使用场景及目标用户，在整车层面开展面向预期功 能安全的危害分析和风险评估，并确定风险接受准则，符合 GB/T XXXXX-XXXX《道路车辆 预期功能安 全》第 6 章的要求。
A.2.5 面向功能安全的安全概念
A.2.5.1 车辆制造商应至少在系统层面进行面向功能安全的安全概念活动，以保障系统在故障条件下， 对驾驶员、乘客和其他道路使用者不存在不合理的风险。
注：安全概念包括功能安全概念和技术安全概念。
A.2.5.2 车辆制造商应进行安全分析活动，并制订对应的安全措施，以说明系统一旦发生失效该系统 如何避免或减轻可能对驾驶员、乘客和其他道路使用者的安全产生影响的危害。安全分析至少包括： a) 系统层面的安全分析，可采用潜在失效模式与影响分析(FMEA)、故障树分析(FTA)、系统理
论过程分析（STPA）或任何适合系统安全分析的其他类似过程。
b) 应至少考虑如下因素可能导致的危害以开展安全分析：
1) 感知系统故障
2) 决策系统故障
3) 应描述对应的安全措施，确保功能安全需求和目标的达成。
A.2.5.3 车辆制造商应具备文档，用来对 ADS 的提示信号优先级以及在典型故障情况下向驾驶员提供 警告信号进行描述。
A.2.5.4 车辆制造商应进行安全措施制订，以确保安全概念实现。系统可采取如下安全策略：
a) 使用部分系统维持运行。在某些故障条件下（例如：探测相邻车道的传感器故障）维持部分 性能（例如，维持在本车道，不支持变道）的运行模式，应说明这些故障条件并确定其效果；
b) 切换到备用系统。如选择备用系统实现动态驾驶任务，应对切换机制的原理、冗余的逻辑和 层级、备用系统的状态检查机制进行说明并界定备用系统的效果；
c) 退出自动驾驶功能。如果选择退出，过程应符合本文件要求。
A.2.6 面向预期功能安全的安全措施制定
A.2.6.1 车辆制造商应制定面向预期功能安全的安全措施，以保障对于功能不足和合理误用，系统不 会对驾驶员、乘客和其他道路使用者造成不合理的风险。
A.2.6.2 车辆制造商应进行安全分析活动，以挖掘系统潜在功能不足和潜在触发条件，并制订对应的 安全措施，以说明在对应的场景下，该系统如何避免或减轻可能对驾驶员、乘客和其他道路使用者的 安全产生影响的危害。安全分析至少包括：
a) 系统层面的安全分析，可参考 GB/T XXXXX-XXXX《道路车辆预期功能安全》表 4 和附录 B.3， 或任何适合系统安全分析的其他类似过程。
b) 应至少考虑如下因素可能导致的危害以开展安全分析：
1) 感知系统和决策系统常见功能不足
2) 未能充分考虑或未遵守交通规则
3) 驾驶员可合理预见的误用
4) ODC 边界场景识别不足
c) 应描述对应的安全措施，确保预期功能安全风险可接受。
A.2.6.3 车辆制造商应制订面向预期功能安全的安全策略。系统可采取如下安全策略：限制系统激活、 向驾驶员发出警告、请求驾驶员接管、降级或降速运行、最小风险策略等。
A.3 验证和确认
A.3.1 功能安全验证和确认
A.3.1.1 车辆制造商应执行验证和确认活动，并对验证/确认计划和结果进行检查，以证明满足面向 功能安全的安全概念。验证和确认应基于仿真测试、场地测试、道路测试或其它适当的方法。 A.3.1.2 车辆制造商应通过向自动驾驶系统相关的电子电气组件施加相应的输入，来模拟组件内部典 型故障的影响，以检查系统组件发生失效的情况。
A.3.2 预期功能安全的验证和确认
A.3.2.1 车辆制造商应执行验证和确认活动，并对验证/确认计划和结果进行检查，以证明满足面向 预期功能安全的接受准则。验证和确认应基于仿真测试、场地测试、道路测试或其它适当的方法。 A.3.2.2 车辆制造商应检查在关键典型场景下系统的目标与事件探测和响应（OEDR）、系统决策和人 机交互（HMI）等是否符合本文件的要求。
A.3.2.3 车辆制造商应对自动驾驶系统 ODC 内典型的可合理预见场景进行充分确认，包括难于利用场 地测试和实际道路测试的场景。
注：面向功能安全的验证和确认与面向预期功能安全的验证和确认可能是同时进行的。
A.4 系统评估报告
车辆制造商应基于附录A要求进行系统评估并输出评估报告。评估报告应具有可追溯性。
***********************************************
现成译文，到款即发。
任取样页验证译文质量。
免费提供正规增值税发票。
请联系手机/微信: 133-0649-6964/Email: standardtrans@foxmail.com 购买完整译文。
专业源于专注|舍吾予言标准翻译/ChinaAutoRegs/始终专注于机动车标准翻译！迄今为止已翻译上千个国内外汽车法规标准！独家打造千万级汽车专业术语库和记忆库。