智能驾驶系统：全生命周期融合安全规范
|
文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 |
|
发文件起草分工： 1. |
|
编制： |
签名： 日期： |
|
审核： |
签名： 日期： |
|
批准： |
签名： 日期： |
|
所有权声明 |
|
该文档及其所含的信息是财产。该文档及其所含信息的复制、使用及披露必须得到的书面授权。 |
1 前言
1.1 目的
确定车辆在生产、运行、服务和报废的要求，包括生产、运行、服务和报废计划及具体要求等，以指导生产、运行、服务和报废工作。
1.2 规范内容
本规范规定了全生命周期问题、指标和安全性能指标、生产、运行、服务和报废安全管理等内容 。
1.3 版本和变更
本规范的版本变更说明，如表 1 所示。
表 1 更改历史
|
版本 |
更改描述 |
更改日期 |
更改人 |
|
1.0 |
|
|
|
|
1.1 |
|
|
|
|
1.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 规范性引用文件
下列文档中的条款通过本标准的引用成为本标准的条款。凡是注日期的引用文档，其随后的修改单（不包含勘误的内容）或修订版均不适用于本标准。凡是不注日期的引用文档，其最新版本适用于本标准。
2.1 国际标准和技术规范
本规范参考的国际标准和技术规范，如表 2 所示。
表 2 规范性引用文件
|
编号 |
文档 |
|
Ref [1] |
UL 4600: UL Standard for Safety for Evaluation of Autonomous Products |
|
Ref [2] |
ISO 26262-1: Road vehicles- Functional safety- Part 1: Vocabulary |
|
Ref [3] |
ISO 26262-2: Road vehicles- Functional safety- Part 2: Management of functional safety |
|
Ref [4] |
ISO 26262-3: Road vehicles- Functional safety- Part 3: Concept phase |
|
Ref [5] |
ISO 26262-4: Road vehicles- Functional safety- Part 4: Product development at the system level |
|
Ref [6] |
ISO 26262-6: Road vehicles- Functional safety- Part 6: Product development at the software level |
|
Ref [7] |
ISO 26262-7: Road vehicles- Functional safety- Part 7: Production, operation, service and decommissioning |
|
Ref [8] |
ISO 21448: Road vehicles- Safety of the intended functionality |
|
Ref [9] |
ISO/SAE 21434 ： Setting the Standard for Connected Car’s Cybersecurity |
2.2 国内标准和技术规范
本规范参考的国内标准和技术规范,如表 3 所示。
表 3 规范性引用文件
|
编号 |
文档 |
|
Ref [1] |
GB/T 34590.1: 道路车辆 功能安全 第 1 部分：术语 |
|
Ref [2] |
GB/T 34590.2: 道路车辆 功能安全 第 2 部分：功能安全管理 |
|
Ref [3] |
GB/T 34590.3: 道路车辆 功能安全 第 3 部分：概念阶段 |
|
Ref [4] |
GB/T 34590.4: 道路车辆 功能安全 第 4 部分：产品开发：系统层面 |
|
Ref [5] |
GB/T 34590.6: 道路车辆 功能安全 第 6 部分：产品开发：软件层面 |
|
Ref [6] |
GB/T 34590.7: 道路车辆 功能安全 第 7 部分：生产、运行、服务和报废 |
|
Ref [7] |
GB/T 43267: 道路车辆 预期功能安全 |
3 术语缩写与定义
3.1 缩写
表 4 列出了本规范中专有名词的英文全称及相应的中文。
表 4 缩写
|
缩写 |
含义 |
|
BIST |
Built-in Self-Test( 内置自检 ) |
|
CPU |
Central Processing Unit( 中央处理单元 ) |
|
CRC |
Cyclic Redundancy Check( 循环冗余校验 ) |
|
ECU |
Electronic Control Unit( 电控单元 ) |
|
FMEA |
Failure Mode and Effects Analysis( 失效模式与影响分析 ) |
|
ISO |
International Standards Organization （国际标准组织） |
|
MEL |
Minimum Equipment List( 最低设备清单 ) |
|
ODD |
Operational Design Domain( 设计运行域 ) |
|
SPI |
Safety Performance Indicator( 安全性能指标 ) |
|
V &V |
Verification and Validation( 验证和确认 ) |
3.2 术语和定义
可接受
足以实现安全案例中确定的总体项目风险。
要求
有助于确立安全性的虚假陈述是可以接受的。
用于支持参数的数据或其他信息。
故障模型
执行故障分析时要考虑的所有故障的规范
现场工程反馈
从系统操作中获取数据，以支持安全案例并识别潜在的安全案例问题
识别
创建一个响应于子句的指定类别，属性或子句其他方面的枚举列表，并具有足够的特异性以启用评估。
事件
发生可能导致损失事件的安全相关故障
项目
在车辆层面实现一个功能的组件或组件集。
生命关键
系统的一个方面，丢失事件可能会导致人员伤亡
减轻
降低到可接受的风险水平
验证测试
超越内置自测（ BIST ）功能来检测潜在故障的测试
损失事件发生的可能性和该损失事件的严重性组合。
具有安全案例所定义的可接受的缓解后项目级风险。
有证据支持的结构化论点，提供了令人信服、可理解和有效的证据，表明系统对于给定环境中的给定应用程序是安全的。
安全相关
直接或间接影响安全性的系统功能，元素，属性或其他方面。
安全性能指标（ SPI ）
用于量化安全性能的度量
审核
针对过程目标对已实施过程的检查。
组件
逻辑上和技术上可分离的组成部分。
网络安全
网络安全道路车辆网络安全状态，在该状态下，资产受到充分的保护，免受道路车辆项目、其功能及其电气或电子部件的威胁场景。
网络安全控制
修改风险的网络安全控制措施。
网络安全事件
与项目或部件有关的网络安全信息。
网络安全信息
与网络安全有关的信息。
影响
对损害情况下的损害或身体伤害程度的估计。
道路使用者
使用道路的人。
威胁情况
一个或多个资产的网络安全属性受到损害的潜在原因，以实现损害情况。
脆弱性
可作为攻击路径的一部分被利用的弱点。
弱点
可导致不良行为地缺陷或特征。
行为
场景快照中任何参与者所实施的单一行为或表现。
在某一时刻所发生的事情。
功能不足
规范定义不足或性能局限。
危害
由整车层面危害行为导致的伤害的潜在来源。
规范定义不足
可能不完整的规范定义，当被一个或多个触发条件触发时，会导致危害行为或导致无法防止、探测及减轻可合理预见的间接误用。
预期功能
已定义的功能。
误用
以制造商或服务提供商不期望的方式使用。
性能局限
技术能力局限，其在一个或多个触发条件触发下，促成危害行为或无法防止、探测及减轻合理预见的间接误用。
反应
场景快照中任何参与者对行为的反馈。
预期功能安全
不存在因预期功能或其实现的功能不足引起的危害而导致不合理的风险。
场景
按照场景快照的先后顺序，对几个场景快照的时间关系进行的描述，包扣特定情况下受行为和事件影响的目标和取值。
场景快照
环境快照，包括背景、动态要素、所有参与者和观察者的自我表征以及这些实体之间的关系。
触发条件
场景中的特定条件，这些条件引发了系统的后续反应，这些反应促成了危害行为或无法防止、探测及减轻可合理预见的间接误用。
不合理的风险
按照现行的安全观念，被判断为在某种环境下不可接受的风险。
架构
相关项或要素的结构的表征，用于识别结构模块及其边界和接口，并包括将要求分配给结构模块。
评估
对相关项或要素的特性使否实现目标的检查。
标定数据
在开发过程中，软件构建后将用作软件参数值的数据。
可控性
通过所涉及人员的及时反应 [ 可能具备外部措施的支持 ] 避免特定的伤害或者损伤的能力。
降级
相关项或要素的功能缩减、性能降低或两者均有的状态，或向该状态的过渡。
要素
系统、组件、硬件元器件或软件单元。
嵌入式软件
在一个处理要素上运行的充分集成的软件。
错误
计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。
暴露
处于某运行场景的状态，在该运行情况下，如果发生所分析的失效模式，可能导致危害。
外部措施
独立于且不同于相关项的措施，以降低或减轻由相关项导致的风险。
失效
由于故障出现导致要素或相关项预期行为的终止。
失效模式
要素或相关项未能提供预期行为的方式。
故障
能够引起要素或相关项失效的异常情况。
故障注入
评估要素内故障影响的方法，该方法通过注入故障、错误、或失效从而通过观测点对注入后的响应进行观测。
现场数据
从相关项或要素的使用中获得的数据，包括累积运行时间、所有失效和服务中的安全异常。
功能安全
不存在由电气 / 电子系统的功能异常表现引起的危害而导致不合理的风险。
硬件元器件
硬件组件在第一层级分解时的一部分。
伤害
对人身健康的物理损害或破坏。
危害
由相关项的功能异常表现而导致的伤害的潜在来源。
检查
为发现安全异常而依据一个正式的流程对工作成果进行考查。
相关项
实现整车层面功能或部分功能的系统或系统组合。
生命周期
相关项从概念到报废的全部阶段。
管理体系
一个组织用来实现其目的的政策、程序及流程。
修改
以现有相关项为基础创建新相关项。
观测点
用来观察故障潜在影响的要素的输出信号。
运行模式
源自相关项或要素的使用和应用中功能状态的一些条件。
运行时间
相关项或要素工作（包括降级模式）的累积时间。
运行场景
在车辆生命周期中可能发生的场景。
阶段
规范中定义的安全生命周期的阶段。
处理要素
提供一系列数据处理功能的硬件元器件，通常包括一个寄存器集、一个执行单元和一个控制单元。
在用证明
通过在用证明对一组给定的声明周期子阶段及相应工作成果的替代。
质量管理
用来指导和控制组织针对质量的协调活动。
随机硬件故障
服从概率分布的硬件故障。
可合理预见的
技术上可能的、且具有可信或可测量发生率的。
重建
改变 T &B 的原始配置，以便执行不同的任务。
冗余
除了足以实施所需功能或足以表达信息的方法外，还存在其他方法。
再制造
按照原始规范，用新的或修复后的零件对已使用一段时间的 T &B 车辆进行拆卸和翻修。
残余风险
实施安全措施后剩余的风险。
评审
按照评审目的，为实现预期的工作成果目标而对工作成果进行的检查。
安全状态
相关项在失效的情况下，没有不合理风险的运行模式。
安全
没有不合理的风险。
安全活动
在安全生命周期的一个或多个阶段或子阶段进行的活动。
安全异常
偏离预期并可能导致伤害的情况。
安全文化
组织中持久的价值观、态度、动机和认知，即：在决策和行为中，安全优先于与之冲突的目标。
安全措施
用来避免或控制系统性失效，探测或控制随机硬件失效，或减轻他们有害影响的活动或技术方案。
安全机制
为了保持预期功能或者达到 / 保持某种安全状态，由电气 / 电子系统的功能 / 要素或者其他技术来实施的 技术解决方案，以探测并减轻 / 容许故障、或者控制 / 避免失效。
安全计划
管理和指导开展项目安全活动的计划，包括日期、里程碑节点、任务、可交付成果、职责和资源。
安全相关功能
有潜在可能导致违背安全目标或有助于实现安全目标的功能。
安全相关事件
安全相关失效的发生
安全相关的特殊特性
相关项、要素自身或其生产过程的特性，这些特性的可合理预见偏差可能影响、促使或造成功能安全的潜在降低。
严重度
对潜在危害事件中可能发生的一个或多个人员的伤害程度的预估。
软件组件
一个或多个软件单元。
软件单元
软件架构中最低层级且可被独立测试的软件组件。
子阶段
本规范定义的。安全生命周期中阶段的细分。
系统
至少与一个传感器、一个控制器和一个执行器相关联的一组组件或一组子系统。
系统性失效
以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。
测试
为验证相关项或要素满足定义的要求、探测其安全异常、确认要求适用于给定的环境和对其行为建立信心，而进行计划、准备、运行或演练的过程。
验证
确定检查对象是否满足其特定要求。
报警和降级策略
如何将潜在降低的功能向驾驶员报警及如何降低的功能以达到安全状态的定义。
工作成果
由本规范相关要求得出的文档。
3.3 约定术语
本文档中使用了下列术语：
-
“ 强制性”：表示不允许出现安全案例偏差
-
“ 需要”：表示仅当通过提示证明提示元素与项目和 / 或其安全案例本质上不兼容时，才允许发生安全案例偏离。
-
“ 强烈推荐”：表示是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。
-
“ 推荐”：表示这些是可选的提示元素，记录了良好做法和 / 或有用技术的建议。
4 全生命周期融合安全概述和组织
4.1 概述
本规范的目的是：
a) 对全生命周期问题提出总体要求，确保与全生命周期活动和阶段有关的危害和风险得到减轻；
b) 为全生命周期过程提供安全指标，并可针对指标进行分析改进；
c) 定义实现和维护生产、运行、服务和报废相关融合安全的组织和人员的职责；
d) 分析和控制安全相关工作成果、相关项和要素的变更；
e) 定义生产、运行、服务和报废计划内容要求；
f) 定义生产活动安全要求，通过对生产过程负责的有关制造商、个人或组织来确保在生产阶段实现安全；
g) 定义运行后持续确保智能驾驶系统安全的过程要求；定义用于识别操作期间的不可接受的安全风险的措施以及用于在运行期间维持安全的措施。
传达网络安全支持的结束；确保在车辆生命周期的服务以及报废子阶段中实现安全。
4.2 总则
如图 4.1 所示，本规范为自动驾驶系统全生命周期安全列出的要求和建议，规范内容包括全生命周期问题，保养，指标和安全性能指标，生产、运行、服务和报废安全管理，变更管理，生产、运行、服务和报废计划，生产，运行，服务、报废和停用。
图 4.1 本规范整体架构
4.3 全生命周期融合安全原理
如图 4.2 所示，为全生命周期融合安全原理。全生命周期问题、保养及指标和安全性能指标对全生命周期安全活动提出总体要求，生产、运行、服务和报废管理和变更管理提出全生命周期安全活动的管理要求，生产、运行、服务和报废计划、生产、运行、服务、报废和停用章节对全生命周期阶段活动提出相应要求。
5 全生命周期问题
5.1 概述
本章的目的是对全生命周期问题提出总体要求，确保与全生命周期活动和阶段有关的危害和风险得到减轻。如图 5.1 所示，本章主要内容包括：需求 / 设计验证要求、从设计到制造的交接要求、制造和项目部署要求、供应链要求、现场修改和更新要求、操作要求、报废和处置要求。
图 5.1 全生命周期问题整体框架
5.2 通用
5.2.1 与全生命周期活动和阶段有关的危害和风险应减轻。
a) 至少确定与以下生命周期阶段有关的生命周期危害和风险：
1） 需求 / 设计 V &V （请参阅 5.3 节）
2） 从设计到制造的交换（请参阅 5.4 节）
3） 制造和项目部署（请参阅 5.5 节）
4） 供应链（请参阅 5.6 节）
5） 现场修改和更新（请参阅 5.7 节）
6） 操作（请参阅 5.8 节）
7） 退休和处置（请参阅 5.9 节）
b） 为每种已识别的危害确认危害缓解措施，包括但不限于：
1） 减轻机制或活动
2） 用于激活机制或执行过程的周期性或触发事件
c) 如果无法通过减轻风险本身来减轻风险，则应确定额外的减轻风险措施，至少包括：
1) 风险缓解机制或活动
示例： 如果组件故障耗尽了维持当前操作模式所需的可用冗余，则过渡到降级的操作模式。
2) 用于激活机制或执行过程的周期性或触发事件
示例： 每固定的工作小时数运行一次证明测试，以减少 BIST 无法诊断的潜在累计故障的风险。
d) 进行缓解活动所需的可接受的文档，过程，工具和其他要求
1) 进行了可接受的数据收集，现场工程反馈，质量检查以及任何其他相关活动，以确保所需的降低生命周期风险的活动将被可接收地执行，包括至少：
i) 数据收集，现场工程反馈和质量检查的完成证据
ii) 这些活动必须遵守规定的程序
iii) 活动在减轻风险方面的有效性
iv) 分析和反馈完成的及时性
2) 分析收集到的数据以衡量 / 改善缓解风险活动的绩效，以支持安全案例
5.3 需求 / 设计验证
5.3.1 应减轻与要求和设计 V &V 活动有关的危害和风险。
a) 识别与 V &V 活动相关的危害和风险，并跟踪关闭
1) 与测试性能有关
2) 与测试过程中项目行为不正确的可能性有关
注： 如果测试的目的是验证该行为实际上已正确实施，则不能假定风险缓解措施的正确行为。
b) V &V 安全计划，至少包括：
1) 识别 V &V 危害和风险
2) 确定缓解 V &V 风险的方法
3) 建议用于跟踪与设计 V &V 活动相关的已识别和新风险并跟踪缓解风险直至关闭的系统
注： 该计划涵盖确保 V &V 活动安全地进行，这可能对永久性和 / 或临时性的设备和程序提出附加要求。
c) 其他数据日志至少执行以下操作时要考虑安全性：
1) 硬件在环测试
2) 故障注入测试
3) 故障诊断测试
4) 跟踪测试
5) 公路测试
6) 其他测试
d) 不断更新与 V &V 活动相关的风险缓解措施，以应对新的风险。
5.4 从设计到制造的交接
5.4.1 应减轻与从设计到制造的移交有关的危害和风险。
a) 识别与从设计到制造以及从追踪到关闭的物品移交相关的危害和风险。
b) 从设计到制造交接时，要积极保证：
1） 软件版本与经过验证的软件版本匹配
2） 硬件配置与经过验证的硬件配置匹配
3） 项目配置与安全箱版本匹配
4） 切换期间未发生软件和数据映像损坏
5） 没有用于特定生产线的组件混合：用于一个项目配置的组件没有与另一种型号或版本相关的混合和交付
示例： 在交付制造时，与设计验证期间使用的 LIDAR 组件相比，当前可用的 LIDAR 组件具有不同的硬件版本或固件版本。
c） 切换要求适用于新版本和更新版本
5.4.2 必须定义项目构建过程。
a) 构建过程至少包括以下元素：
1) 创建清单（即包含版本控制信息的硬件和软件组件列表）
2) 定义并确保符合建立过程验收标准
示例： 可接受的静态分析结果，测试套件结果，恶意软件检查结果，软件许可分析
3) 执行构建软件包完整性验证
示例： 可审核的检查记录，以确认已验证的项目与部署的项目完全对应
4) 软件配置管理
b) 多个构建包的协调。
注： 如果使用了多个构建过程，则需要对它们进行协调，以使部署的产品以已接受可接受构建过程的所有组件的定义版本运行。
示例： 车辆控制构建，信息娱乐系统构建，远程数据库构建之间的协调。
5.4.3 项目构建过程应提供可接受的结果
a) 有关执行构建过程的质量保证。
b) 多个构建包的协调在进行故障诊断时，将构建过程缺陷视为根本原因。
5.4.4 项目配置应在构建中进行管理，并将构建发布到制造中
a) 定义的项目配置管理过程至少包括：
1) 每个项目实例中安装的软件映像
2) 每个项目实例的硬件组件清单，包括每个零件号，制造商和零件修订版
注： 这旨在用于“现场可更换单元”级别，而并非旨在要求识别较低级别的子组件。
3) 制造时与每个项目实例相关的安全案例
b) 可以从归档数据完全重新创建的可接受的软件配置信息和数据，至少包括：
1) 软件源，库和其他组件
2) 开发工具链
3) 校准数据和其他数据文件
4) 用于 V &V 的数据
5) 测试计划，过程，脚本和工具
6) 不受开发人员控制的组件的软件源代码的可更新固件映像和其他软件映像
示例： 验证测试期间已应用的雷达传感器固件更新映像的快照
注： 如果组件不可进行固件更新，则这并非旨在强制向项目集成商提供固件映像。而是，如果某个组件在其生命周期中可能有多个固件映像，则该固件映像必须保持可用，以防配置回滚，诊断或其他目的需要它
c) 每当组件的硬件或软件清单发生变化时，要求组件供应商更新组件版本号。
d) 自动化软件构建过程
5.5 制造和项目部署
5.5.1 应减轻与项目部署有关的危险。
a) 识别与制造和项目部署相关的危害和风险，并跟踪关闭过程
b) 与安全相关的检查，检查和对早期部署的物品执行的其他操作
示例： 工程验证部署，类型批准活动
c) 与安全相关的检查，检查和对每个实例执行的其他操作
示例： 下线检查，经销商准备，购买，租赁或以其他方式部署的物品的所有者进行的必要调试活动。
d) 制造过程中与安全相关的方面，包括：
1) 使用认可的组件
2) 使用正确版本的组件（硬件，软件等）
3) 使用正确的组装工艺
4) 遵守制造工艺参数限制
示例： 储存温度，电路板组装期间的组件温度
e) 售前业务
示例： 在编组和存储区域中进行操作，在陈列室或其他展示位置中放置，在存储和展示位置之间摆渡，客户演示驱动器
f) 与采取的风险减轻信用有关的活动，假设和其他因素
示例： 车辆零售商应注意并在运输中损坏的任何传感器上进行维修
g) 确保在安全情况下考虑自生产发布到制造以来所做的任何更改，至少包括以下方面的更改：
1) 软件清单
2) 硬件清单
3) 组件版本
4) 累积其他数据可能会使安全案例中的假设无效
5) 由于制造缺陷的维修而引起的变化
示例： 不同版本的备件用于纠正在线测试结束时发现的故障组件
5.6 供应链
5.6.1 与供应链有关的危害和风险应减轻。
a) 识别与供应链相关的危害和风险，并跟踪关闭过程
b) 组件管理计划至少解决以下问题：
1) 供应链与制造质量保证
注： 开发人员负责确保可接受的供应商工作产品质量
2) 未经批准的项目和组件修改
示例： 用工作规格降低的组件（例如，降低的温度范围），尚未合格地重新使用的合格零件进行替换
3) 未经批准的备件
i) 用于制造
ii) 为了维护
示例： 假冒组件，未经批准的替代子组件的使用，未经批准的材料的使用，未经批准的项目映像的使用，未经批准的机械项目组件（例如传感器和执行器元件）的使用以及其他类型的未经批准的可疑零件( SUP)。
c) 制造批次中供应商工作产品质量的下降
示例 : 降低质量的组件，减少过程的质量执行，减少来自供应商的质量安全案例数据并入项目安全案例
5.7 现场修改和更新
5.7.1 应减轻与现场改造有关的危害和风险。
a) 识别与现场修改相关的危害和风险，并跟踪关闭过程
b) 该项目安全相关方面的现场修改计划
c) 现场修改计划涉及：
1) 问题报告和根本原因分析
2) 计划的变更
示例： ODD 扩展
3) 计划外变更
示例： 紧急错误修复，紧急安全补丁
4) 变更影响分析至少包括：
i) 安全和安全案例变更
ii) 功能变更
iii) 界面变更
iv) 工艺变更
注： 包括所有适用的流程，例如设计，制造，供应商流程和质量保证
5) 物料和产品系列的变更控制，变更批准和更新管理
i) 问题报告，分类，跟踪用于多个项目的组件或软件
ii) 在已部署的同类群组中跨不同配置进行验证
iii) 批准发布候选版本（发布过程），包含主要版本，次要版本，更新，“热修复”等。
iv) 淘汰过时的配置
示例： 禁用不再受更新和验证活动支持或不再具有有效安全案例的孤立配置
v) 确保更改反映在安全案例中
vi) 定义风险接受政策
示例： 未修复异常，不到完全重新验证的策略，与重新验证并行部署紧急修复程序
6) 现场修改和适应过程的安全影响，至少包括：
i) 软件更新
ii) 硬件更新和 / 或升级
iii) 校准数据更新
iv) 机器学习相关的数据更新
v) 其他数据更新
vi) 更新传送机制
示例： 无线， USB 驱动器交付给客户，专门的技术人员更新工具
vii) 任何自我修改，包括配置管理和自我修改验证
7) 及时执行召回和更新
i) 及时部署召回和更新
ii) 确保更新过程不会降低操作安全性
示例： 项目运行时触发更新，降低了操作安全性
iii) 确保更新过程不会降低非运行安全性
示例： 长时间更新期间滞留在炎热沙漠或洪水上升等危险环境中的乘员
iv) 确保及时完成非软件召回
v) 在未及时进行召回更正和更新时，确定操作的物料要求
示例： 降低车速或 ODD ，直到执行了必要的召回和 / 或更新
vi) 根据安全计划更新完整性
示例： 真实性，数据完整性，配置兼容性
d) 软件 / 硬件更新应遵循与安全案例中所述相同的过程，除非通过变更影响分析保证对安全案例的这一方面进行了更新
e) 与使用空中更新机制有关的风险，包括相关的安全风险（如果使用）
5.7.2 应减轻与软件和数据更新有关的危害和风险
a) 软件更新安全计划，用于确保至少响应一下方面，对安全参数和维护 / 操作要求进行可接受的更新：
1) 软件更新
2) 维修和保养程序
3) 组件更新
4) ODD 定义更新
5) 奇数变化
b) 为每个软件更新执行软件更新安全计划中的适用流程
c) 至少考虑以下因素，更新安全影响分析：
1) 安全论点变更
2) 维护变更
3) 操作程序变更
4) 校准数据变更
5) 地图和数据更新
6) 行为规则
示例： 关于遵守交通法规，互动规则
7) 基础设施期望
示例： 标牌类型，道路标记材料
8) 维修和保养触发事件和 / 或周期性
9) 计算机升级，传感器升级，机电升级
10) 增强训练数据并重新训练基于机器学习的功能
11) 模型和模拟器更新
12) 工具更新
示例： 使用新的编译器，新的静态分析工具，新的构建工具
13) 故障安全更新
14) 监控更新
15) SPI 和指标更新
示例： 重新审查原型和模型，以确保持续的 SPI 有效性；将以前的结果映射到新模型（如果可以）
16) V &V 方法论更新
5.8 操作
5.8.1 与物品生命周期的操作部分有关的危害和风险应减轻。
a) 在特定任务阶段执行的减少危害和风险的方法：
1) 开始任务检查
示例： 最低设备清单（ MEL ）检查，校准检查，配置检查，更新检查和自检
2) 任务期间检查
示例： 内存映像完整性，内置自检（ BIST ）状态
b) 在特定任务阶段执行的其他减少危害和风险的方法
c) 通过证明测试减轻风险
示例： 激活备份项目和保障保护以确保故障检测
d) 指定驾驶员和乘客所需的任何检查，至少包括：
1) 确定程序
2) 争论效力
3) 认为检查将以可接受的质量和频率进行
e) 在非运营和维护情况下降低风险，至少包括：
1) 加油 / 补给
2) 短期储存
3) 长期储存
4) 设备防护措施
示例： 防水布和覆盖物的使用
5) 清洁用品
示例： 手动或自动洗车
6) 例行维修
示例： 加液操作期间的安全性，轮胎压力维护，更换雨刮器刮片
7) 例行检查
示例： 轮胎状况检查时的安全
8) 运输和牵引
9) 退役 / 处置
f) 维护和检查操作期间的风险缓解
1) 校准操作
2) 视察
3) 物品维修
4) 维护后项目测试
g) 解释不同的潜在部署类型
1) 托管车队
2) 个体拥有和维护的单位
3) 在 ODD 内部署到不同的气候和环境条件
4) 以不同的使用占空比进行部署
5) 部署到不同的角色
示例： 相同项目类型的大多数货运与大多数乘客部署
5.8.2 应减轻与项目操作有关的危害和风险。
a) 识别与物品操作有关的危险并追踪关闭
b) 道路测试安全
注： 如何确保道路测试安全的详细信息不在本标准范围之内。可能希望该提示元素与用于确保道路测试安全的单独过程和 / 或计划相对应，其细节未作为本标准的一部分进行评估。
c) 外部人身安全
示例： 暴露于激光辐射，射频辐射，碰撞
d) 项目和元素故障安全
示例： 车辆火灾，货物火灾，电池火灾，爆炸性气体，有毒气体
e) 物品机动安全
示例： 对乘员或货物的作用力过大，与危险 / 松散负载的其他车辆太近，被相邻车辆的投射阻碍
f) 内部车辆物理和环境危害
示例： 有毒烟雾，生物危害物（例如血液），危险的车厢温度，锋利的边缘，挤压危险（包括窗户，门，天窗，座椅调节装置），不固定的货物，展开的安全气囊
g) 非运营项目行为风险
示例 : 在封闭空间中运行短期存放的车辆内燃机，在装填期间释放爆炸性气体，装填时起火，在非操作模式下车辆或元件意外移动
h) 确定在防撞性安全论点中获得的信誉（如果有）
1) 车辆安全机制
示例： 溃缩区，减震保险杠，安全带，安全气囊
2) 行人安全机制
示例： 行人安全气囊，车辆几何形状， 20mph 以下的运行速度
3) 对乘员和其他道路使用者的影响，包括危险设备
示例： 动力电池，在碰撞后遭受非零着火的危险
i) 乘员困扰
示例： 乘员医疗急救，无行为能力的乘员
j) 在不安全的环境中操作
示例： 洪水，陆地，桥梁冲刷，烟雾，龙卷风，飓风，水龙卷
k) 在不安全的环境中过渡到非运行模式
示例： 停在铁轨上，停在与一堆树叶接触的热催化转化器上
l) 任何支持安全机制的命令超控的安全性
5.9 报废和处置
5.9.1 应减轻与组件老化和过时有关的危害和风险
a) 识别与组件老化相关的危害并跟踪关闭
b) 更换磨损的组件
示例： 轮胎，雨刮器，电池，已达到其循环极限的非易失性存储组件，旋转传感器的轴承
c) 更换老化的零件
示例： 轮胎，不可充电电池，一次性编程的非易失性存储芯片，这些芯片具有与使用年限相关的数据退化，光学镜片变色
5.9.2 应减轻与物品报废和处置有关的危害和风险
a) 确定并主张减轻与报废有关的危害
示例： 由于长期暴露于恶劣天气，冰冻或浸入水中而导致的物品控制装置退化和故障，需要报废或大修，而不是简单维修，因为其整体可靠性降至可接受的极限以下
6 保养
6.1 概述
本章的目的是对保养过程提出总体要求，确保与保养有关的危害和风险得到减轻。如图 6.1 所示，本章主要内容包括：保养与检查、所需的检查与维护和非运行安全。
图 6.1 保养安全流程
6.2 保养与检查
6.2.1 应当减轻与维护和检查有关的危险
a) 确定与安全相关的维护和检查活动（参阅 6.3 节）
b) 非运行安全（参阅 6.4 节）
c) 事件后的项目行为（参阅系统开发文档 12.6.5-12.6.7 节）
d) 可追踪的危害日志条目和减轻风险的能力，以维护和检查对风险的潜在贡献
示例： 特定的检查活动是风险缓解的方法的一部分。维护活动可以追溯到其减轻的风险。
e) 通道过载确保对操作项目进行必要的维护和检查方法（参阅 6.3.3 节）
1) 确定确保绩效的方法
2) 确定确保检测到维护和检查不合格的方法
3) 确保有效执行已识别的方法
f) 确保维护和检查不会降低安全性的方法
示例： 检查期间物品损坏，在恢复操作之前忘记重置维护超控机制
g) 解决由错误和 / 或不完整维护引起的危害的方法
6.3 所需的维护和检查
6.3.1 应确定与安全相关的维护和检查。
a) 确定安全相关的维护要求。如果没有，请声明。
b) 确定安全相关的检查要求。如果没有，请声明。
c) 确定维护和检查要求的故障模型，至少包括：
1) 省略和 / 或推迟
2) 程序执行不正确
3) 执行的程序不正确
d) 每次检查和维护
示例：检查传感器是否损坏，清洁传感器
e) 定期检查和维护
1) 由商品使用情况触发
2) 由时钟和 / 或日历时间触发
f) 按需检查和维护
示例： 由病情监测或预后方法触发
6.3.2 必须确定执行与安全相关的维护和检查的程序
a) 指定并记录维护和检查
b) 程序
c) 批准的组件，材料，设备
d) 计划和 / 或需要执行程序的条件（参阅 6.3.3 节）
e) 验证维护质量和有效性
6.3.3 应确定用于提示和监视与安全相关的维护和检查的性能的方法
a) 确定提示每个维护和检查项目执行的机制，方法或触发器
b) 在标识中包括以下因素：
1) 依赖外部到项目的计划支持
示例： 基于日历提醒系统
2) 依靠外部数据进行数据分析
示例： 基于保存在第三方数据库中的运营历史记录
3) 基于时间，营业时间，营业历史等的项目生成的提醒
示例： 发动机维修，旋转零件维修，动力源
4) 与操作情况相关的程序提示
示例： 任务开始清单，日常运行清单
5) 基于项目状态监控的条件触发
示例： 液位，轮胎压力，故障诊断代码
6) 组件寿命限制
示例： 操作周期数，老化，非易失性存储器写入周期，流体老化，进入可靠性曲线的上升部分
7) 其他适用因素
6.3.4 应当减轻由于维护和检查故障引起的风险
a) 确定安全相关的维护和检查程序
b) 关于任何维护故障都将被避免，检测或纠正的论点
c) 考虑与安全相关的维护故障，包括：
1) 维护和检查程序执行不正确
2) 使用实质上不正确或未经授权的组件或材料
示例： 在寒冷天气条件下使用温暖天气的流体补充剂配方会导致安全相关的冷冻流体
注： 由安全案例决定是否为可接受的组件和材料授权机制以及是否采用缓解机制。
3) 延期维护和检查（包括完全不执行）
4) 未经授权违反维护和检查程序
5) 不合格的人员执行维护和检查程序
6) 不正确地报告延期或不正确的维护和检查已完成
d) 现场工程反馈收集和分析维护与检查不符
1) 分析以确定不合格率是否可以接受
2) 改进维护和检查方法，以根据需要改善不符合项
6.4 非运行安全
6.4.1 与任务间隔状态有关的危害和风险应减轻。
a) 识别与非运行安全有关的危害。
b) 减轻与非运行安全有关的危害
c) 不可使用时的人员出口，包括儿童和动物
示例： 车辆转换为“停放和无人看管”待机模式后，乘员未锁定在车内。
d) 充电 / 加油安全，包括无人值守时的油烟排放
示例： 混合动力汽车的一氧化碳排放量，铅酸蓄电池对电动汽车的充电桩所产生的氢气排放量
e) 无指令的运动，包括被动和主动
示例： 意外释放驻车制动器；不可接受的推进项目启动；不可接受的辅助物品移动
f) 维护和其他非操作程序期间的安全
1) 维护安全
示例： 必须禁用为了安全维护而必须禁用的功能；部件移动是维护程序的一部分
2) 检查安全
示例： 安全联锁装置允许安全进入检查
3) 牵引和运输安全
7 指标和安全性能指标 (SPI )
7.1 概述
本章的目的是为全生命周期过程提供安全指标，并可针对指标进行分析改进。如图 7.1 所示，本章的主要内容包括：指标定义和指标分析与回应。
图 7.1 指标和安全性能指标主要内容
7.2 通用
7.2.1 安全性能指标应纳入安全案例。
a) SPI 指标（参阅第 7.3 节）
b) 指标数据分析和响应（参阅第 7.4 节）
c) 展示对指标的改进
d) 支持项目改进的指标定义
e) 指标数据收集和分析
f) 响应指标改进项目
g) 根据现场经验改进度量和安全案例
7.3 指标定义
7.3.1 根据一组定义的安全指标，该项目应可接受。
a) 为至少包括以下内容的整个项目定义量化的 SPI ：
1) 发生率
示例： 违反安全边际，无损坏
2) 违反规则率
示例： 违反交通法规和其他规定，无损坏
3) 轻微碰撞率（仅财产损失）
4) 轻伤率
注： 安全情况下，轻伤和重伤之间的区分取决于与其他条款相对应的该区分的使用
5) 重大伤害率
6) 死亡率
注： 生命关键指标甚至适用于被认为对生命没有实质性影响的物品。在这种情况下，目标指标可能是零丧生
b) 项目级 SPI 具有定义的目标值
注： “目标”值可以是期望值，也可以是阈值，例如对入射频率的限制。此目标值是在开发期间而不是在部署之后设置的。在某些情况下，目标值可能会随着时间推移而总体上得到改善，只要初始项目可以安全部署即可。
c) 至少针对以下各项对安全指标进行分类:
1) 按项目曝光
示例： 每辆车的运营时间，每辆车的公里数，每辆车的英里数，每个方案，每个方案族，每个功能等级的道路
2) 通过人体暴露
示例： 每个乘员小时，每一次行人遭遇，乘员数对共享车辆的影响（例如，死亡率至少部分是致命损失事件数与每次损失事件发生时乘员数的函数）
3) 有助于项目安全指标的事件，事件和其他现场情况在安全案例中记录为证据，并被诊断为根本原因
d) 如果使用的话，按 ODD 子集分类的安全指标
注： 该提示元素旨在解决以下情况：在 ODD 空间的一部分中，车辆的危险远远大于可接受的危险，但是由于平衡了 ODD 空间中不同部分的高于目标的安全性，因此该状态在总体度量中仍然未被检测到。并非所有 ODD 子集都必须具有相同的风险，而是提示提高低于目标的子集。
7.3.2 应当定义 SPI 以检测潜在的无效风险缓解措施
a) 以量化方式识别 SPI 以降低安全案例中的风险的有效性，至少包括：
1) 未缓解的危害和部分缓解的危害的发生
注： 这些是缓解技术未能完全按设计成功或与可接受风险相对应的危害。
2) 未经缓解就已经接受的危害的发生
3) 基于对安全案例中证据的评估而违反的假设，设计目标和结论
4) 碰撞
5) 实际可检测到的事件
注： SPI 是计数，归一化速率还是以其他方式缩放取决于安全性参数的细节。
b) 与安全相关的检测到的硬件和软件组件故障，即使该项目能够成果减轻风险
注： 这特别包括冗余组件的故障，冗余组件允许其继续运行，以提供现场故障率数据
c) 确定 SPI ，以确保基于与安全相关的统计论据对项目各方面进行持续验证，至少包括：
1) 分类算法的分类错误率
2) 假阴性检测率
3) 假阳性检出率
4) 预测错误率
5) 相关故障率
注： 只要使用的名称完全包涵了所需的列出类别，就可以使用此列表以外的其他名称
注： 虽然原则上不能确定地知道传感器性能的错误率，但是可以并且应该基于传感器和其他数据源之间的比较来收集数据，这些数据源提供了冗余数据以估计或限制现场错误率。
示例： 如果成像仪看不到地图数据库中的道路标志，则这两个数据源之一不正确
示例： 如果 LIDAR 未检测到具有雷达检测到的类别的物体，而 LIDAR 也应能够检测到该类别，则说明出现了问题。
d) 识别与物料生命周期相关的 SPI ，至少包括：
1) 部署后与安全相关的软件缺陷率
2) 安全相关的预防性和定期维护项目的现场故障率
3) 需检查项目的现场故障率
4) 寿命有限项目的现场故障率
5) 纠正性维护结果的现场故障率
6) 执行检查和维护
注： 可以帮助检测维护和检查程序以及计划的问题
e) 确定 SPI ，以检测维护物品性能和质量问题，至少包括：
1) 软件执行故障率
示例： 看门狗定时器激活，任务崩溃率，项目崩溃
2) 实时性能故障率
示例： 错过任务的最后期限， CPU 过载
3) 其他软件和硬件执行故障
示例： 资源分配失败，非实时任务挂起，单个事件失败率，网络数据包错误率
4) 其他支持预测性维护和组件寿命终止预测的数据
f) 包括项目验证指标，现场经验指标和过程指标的组合
g) 其他候选指标类型：
1) 安全
2) 任务成功率
3) 缓解失败的成功率
4) 失败率
5) 遭遇“意外”的概率（潜在 ODD 的情况，对象或其他方面，而预期 ODD 的定义未涵盖）
h) 包括领先指标 SPI ，例如：
1) 新危险的识别率
2) 返修安全相关项目元素
3) 识别具有较高缺陷率的软件模块
i) 捕获安全过程进度，状态和完整性的度量标准，尤其是那些掌握当前安全过程差距并有助于评估风险影响的度量标准
示例： 对项目进行计数，例如：已识别的危害，具有控件的危害，具有安全要求的控件，具有安全验证的安全要求，已完成与要求的严格任务的软件级别，通过 / 失败的安全验证等。
7.3.3 应当定义与项目，其子系统，已定义的 ODD 和环境之间的交互有关的 SPI 。
a) 运行故障分析，以确定潜在的 ODD 偏离，行为故障以及其他需要监视的异常
示例： 使用功能危害分析， FEMA 或其他方法识别为可接受
b) 违反或使当前有效的 ODD 无效的物品未有目的地和安全地启动 ODD 出发，至少包括：
1) 环境条件
示例： 在 ODD 或 ODD 段遇到冰；在地理围栏外操作；地理围栏边界在操作过程中发生了变化，移动时瞬间将自车至于地理围栏外。（例如，在新激活地建筑区域中）
2) 基础架构故障和异常
示例： 未映射的建筑区域，无法识别的标志类型
3) 对象
示例： 遇到不应该存在于 ODD 中的对象，例如典型的北美驾驶 ODD 中的袋鼠，或实际上存在于 ODD 中的合理对象，这是当前项目设计中的空白
4) 外部对象和基础结构的事件，操作，行为和其他操作
示例： 在单向街上遇到错误的交通
c) 自我项目的错误和行为
示例： 两个假定独立的冗余元素的重合故障，意外的车辆运动（例如旋转），无论车辆运动是否导致事故。
d) 意外”的到达率和其他例外，至少包括：
1) 已知的未知数
示例： 到达率未知的已知事件的到达
2) 未知的未知数
示例： ODD 中存在但训练数据，需求和项目设计其他方面所缺少的新对象和新事件
3) 自我项目行为异常
示例： 控制系统从有缺陷或有偏差的训练数据中了解到错误的控制动作
e) 至少由于以下原因，识别不同车辆之间的接口不兼容和不兼容（符合接口规范）交互
1) 不同类型的车辆
2) 来自不同制造商的车辆
3) 车辆和非自动道路使用者
7.3.4 必须定义与故障和故障恢复有关的 SPI 。
a) 故障安全保护和其他主动风险缓解功能的激活，至少包括：
1) 成功激活故障安全（成功减轻已激活危险的风险）
2) 错误激活保障安全
3) 故障保障系统激活失败（缓解风险失败）
4) 当应该合理满足激活条件时不激活故障保护
注： 人们认识到，在实践中，假阴性可能不会全部被发现，但是，此项不是检测所有假阴性的必要条件，而是具有一种度量策略，可试图描述这种情况发生的频率，即使已知它被低估了。
b) 是否发生与安全相关的功能受损，无论是否导致现场报告事件，至少包括：
1) 备份组件的故障或失效
2) 故障安全功能或机制中的故障或失效
3) 恢复功能或机制中的故障或失效
7.3.5 必须定义与安全文化有关的 SPI 。
a) 符合项目安全相关方面的要求：
1) 流程遵守
2) 培训和技能验证
b) 现场识别的缺陷分数可追溯到与开发和验证过程的偏差，至少包括：
1) 批准的技术偏差
2) 未经批准的技术偏差
3) 无法执行记录未已执行的活动
4) 活动和人工制品的质量令人无法接受
7.4 指标分析与回应
7.4.1 应收集每个定义的 SPI 的数据。
a) 识别数据收集机制
示例： 运行时监控，车载数据收集，事件报告分析
b) 描述数据收集触发机制，传输方法和存储方法
示例： 特定 SPI 的数据收集由项目监控器触发，并存储在车辆上以备以后传输；车辆定期将收集的数据发送到开发人员数据中心
c) 数据完整性和保留，用于与每个 SPI 相关的数据，至少包括：
1) 数据完整性保证机制
示例： CRC 错误检测代码在源项目中计算并端到端维护，包括开发人员数据存储
2) 数据传递保证机制
示例： 序列号和定期的心跳数据报告，以确保所有项目都在报告数据，并且没有数据丢失
3) 数据来源保证机制
示例： 数据包括项目序列号，公钥签名
4) 数据保留政策
示例： 在已部署的队列中保留现场数据
5) 数据配置管理
示例： 字段数据链接到从中收集项目的配置
注： 项目配置更改可能会使项目相关性无效
7.4.2 应对 SPI 数据进行项目改进。
a) 定期分析每个 SPI 的数据
1) 基于与 SPI 相关的风险缓解量的期限
示例： 假设某个特定机制已减轻了生命危险风险，则每次相关事件发生时，都需要对随附的 SPI 进行重新分析
b) 每个 SPI 与目标值的比较
1) 违反被视为现场缺陷报告且需要采取纠正措施的 SPI 目标
7.4.3 为了验证和提高 SPI 的预测能力，必须分析非 SPI 数据。
a) 用于 SPI 分析的数据分析技术的 V &V
示例： V &V 的工具，技术，报告和汇总功能，用于统计分析，趋势分析，公差超限以及相关安全指标的分析等。
b) 结合每一个根本原因分析来分析 SPI 是否与安全相关的现场事件相关或已预测到安全相关的现场事件
c) 创建并遵循以识别和实施新的 SPI 的过程，以涵盖通过根本原因分析确定的新伤害
d) SPI 数据采集触发条件的 V &V
8 生产、运行、服务和报废安全管理
8.1 生产、运行、服务和报废管理概述
本章的目的是定义实现和维护生产、运行、服务和报废相关融合安全的组织和人员的职责。如图 8.1 所示，本章主要内容包括：安全管理组织、相关项或要素变更和生产、运行、服务和报废管理。
图 8.1 生产、运行、服务和报废管理流程
8.2 安全管理组织
8.2.1 企业和组织应建立、执行并维护流程，以实现和保持相关项在生产运行服务和报废阶段的安全活动，包括应实施与相关项或其要素相关的潜在安全相关事件的现场监控流程，以提供能用于分析识别出安全问题存在的现场数据。
8.2.2 企业和组织应指定具有相关责任和权限的人员，以实现并维护相关项在生产、运行、服务和报废阶段的安全活动。
8.3 相关项或要素变更
8.3.1 生产、运行、服务或报废期间相关项或其要素如有变更，企业和组织应按照生产发布流程对生产发布进行相应变更。
8.3.2 相关项或其要素的变更，生产、运行（包括现场监控）、及服务或报废流程的变更，应按照安全变更管理的要求进行管理。
注： 包含 T &B 车辆的再制造。
8.4 生产、运行、服务和报废管理
8.4.1 在产品运行过程中应建立安全事件响应机制， 例如对于网络安全，当漏洞分析管理流程触发网络安全事件响应机制时，针对网络安全事件，制定事件响应计划。
8.4.2 网络安全事件响应计划包括：对漏洞的补救措施，组织内外部的信息沟通计划，分配相关职责实施补救措施，与网络安全事件有关的信息记录机制，跟踪网络安全事件处理进展，结束网络安全事件响应的标准等。
9 变更管理
9.1 变更管理概述
本章的目的是在整个安全生命周期中，分析和控制安全相关工作成果、相关项和要素的变更。如图 9.1 所示，本章主要内容包括：计划和启动变更管理、变更需求、变更需求分析、变更需求评估和变更的实施和记录。
图 9.1 变更管理流程
9.2 计划和启动变更管理
9.2.1 在对工作成果进行变更前，应计划和启动变更管理流程
注： 配置管理和变更管理是相互关联的，定义并维护两个流程间的接口以确保变更管理的有效性。
9.2.2 应在变更管理计划中识别要进行变更管理的工作成果、相关项和要素，这些工作成果、相关项和要素也要满足配置管理的要求。
9.2.3 应为已识别出的工作成果、相关项和要素定义实施变更管理流程的日程表。
9.2.4 变更管理流程包括：
a) 变更需求，按照 9.3 ；
b) 变更需求分析，按照 9.4 ;
c) 变更需求的决策和依据，按照 9.5;
d) 已接受的变更的实施和验证，按照 9.6;
e) 文档化，按照 9.6;
注 1 ： 变更管理流程可适用于开发过程中的相应阶段。
注 2 ： 可在一个变更需求中处理多个变更。
9.3 变更需求
9.3.1 应为每个变更需求分配唯一的识别码。
9.3.2 每个变更需求应至少包括以下信息：
a) 日期；
b) 所需变更的理由；
c) 所需变更的准确描述；
d) 所需变更基于的配置。
9.4 变更需求分析
9.4.1 对于每个变更需求，应针对以下信息，对所涉及的相关项或要素、接口及关联相关项或要素进行影响分析：
a) 变更需求的类型；
示例： 可能的变更类型有解决错误、调整、消除、加强、预防。
b) 对需更改的工作成果、相关项的要素及受影响的工作成果、相关项 he 要素进行的识别；
c) 在分布式开发的情况下，所涉及的相关方的识别及其责任；
d) 变更对功能安全的潜在影响；
e) 变更的实现和验证的日程表。
9.4.2 对工作成果的每次变更，应重新启动安全生命周期的适用阶段。后续阶段的开展应符合本规范。
9.5 变更需求评估
9.5.1 应使用按照 9.4.2 进行的影响分析的结果对变更需求进行评估，并且应由授权人员决定是否接受、拒绝或推迟变更。
示例： 典型的授权的人员包括：
—— 项目经理；
—— 安全经理；
—— 负责质量保证的人员；
—— 涉及的开发人员。
注： 已接受的变更需求可按优先级排序，并于已接受的相关变更需求合并。
9.5.2 对于每个已接受的变更需求，应决定谁来开展变更及变更的最晚时间。该决定应考虑开展变更时所涉及的接口。
9.6 变更的实施和记录
9.6.1 应按计划实施变更和验证变更。
9.6.2 如果变更影响了安全相关功能或特性，则应在发布相关项前对安全评估和适用的认可评审进行更新。
9.6.3 变更的记录应包含以下信息：
a) 按照配置管理要求，在合适的层面下，变更的工作成果、相关项和要素的清单，包括配置和版本；
b) 开展的变更细节；
c) 变更部署的计划日期。
注 1 ： 对临时变更需求，明确指出该变更需求的理由和变更持续时间（如已知）。
注 2 ： 对被拒绝的变更需求，记录变更需求和拒绝的理由。
10 生产、运行、服务和报废计划
10.1 生产、运行、服务和报废计划概述
本章的目的是为拟安装在道路车辆上的安全相关的要素或相关项，开发和维护一个生产过程；防止在生产过程中引入漏洞；为接触安全相关的相关项或要素的用户，开发关于运行、服务（维护和维修）和报废的必要信息，确保在车辆的整个生命周期实现融合安全。如图 10.1 所示，本章主要内容包括： 生产计划；试生产；运行、服务和报废计划。
图 10.1 生产、运行、服务和报废计划
10.2 生产计划
10.2.1 应计划相关项及其要素的生产过程，该计划考虑如下内容：
a) 对生产的要求；
示例 1 ： 装配指导说明（例如，传感器的标定和设置）。
示例 2 ： IPC （印刷电路协会）相关标准的要求。
b) 安全相关的特殊特性；
示例 3 ： 所选要素的公差。
示例 4 ： 坡度传感器的下线标定。
c) 要素的处理和管理条件；
示例 5 ： 硬件要素的允许存储时间
示例 6 ： ECU 软件的正确程序设定。
d) 产品开发过程中定义的配置；
e) 从以前发布的生产计划中获得的经验总结；
f) 涉及安全相关的特殊特性的生产过程、设备、工具和测试设备的适宜性；
g) 人员的能力。
10.2.2 生产计划应描述实现相关项或要素的功能安全、预期功能安全和信息安全而要求的生产步骤、顺序和方法，包括：
a) 生产工艺流程和指导说明；
注： 生产流程也可包括要素的返工。
示例 1 ： 有三个或更少引脚的元器件的不良焊接点的返工说明。
b) 生产工具和设备；
c) 可追溯性措施的实施；
示例 2 ： 对要素使用标签。
10.2.3 应定义一个流程作为生产过程的一部分，以确保正确版本的嵌入式软件及其相关标定数据被写进 ECU 中。
示例 1 ： 使用校验和，目的是将下载的可执行数据及标定数据的校验和与该特定车辆配置的正确校验和相比较。
示例 2 ： 从下载到 ECU 中的软件回读零件号，并与物料清单中特定车辆的目标零件号进行对比；同样也回读下载的标定数据并与物料清单中针对改特定车辆的标定数据进行对比。
10.2.4 应识别可合理预见的生产过程失效及其对功能安全的影响，并实施恰到好处的措施以处理相关过程失效。
示例： 过程失效模式和影响分析（ PFMEA ）
10.2.5 应建立一个生产控制计划，适用于开发后的功能安全、预期功能安全和信息安全要求。
注： 生产控制计划可以作为整体生产计划的一部分
10.2.6 制定生产控制计划时应考虑对相关项或要素的控制描述（含控制的准则），以及安全相关的特殊特性。
10.2.7 生产控制计划应包括：
a) 适用于开发后的功能安全、预期功能安全和信息安全要求的控制步骤顺序和方法
b) 必要的测试设备、工具和测试准则
c) 网络安全控制，以防止生产过程中出现未经授权的更改
示例 1 ： 防止对持有软件的生产服务器进行物理访问的物理控制。
示例 2 ： 应用加密技术和 / 或访问控制的逻辑控制
d) 方法来确认开发后的功能安全、预期功能安全和信息安全要求得到满足。
注 1 ： 方法可以包括检查和校准检查。
注 2 ： 为了制造一个项目或部件并安装硬件和软件，生产过程中可以使用特权访问。如果在生产后未经授权的方式使用，这种访问会给项目或部件带来漏洞。
10.2.8 计划生产时识别的安全要求，应按照项目安全管理办法，以适当的方式反馈给负责系统、硬件和软件开发人员。
示例： 在接插件中增加防错功能（波卡纠偏）以确保在装配中它被正确地插入 ECU 。
10.3 试生产
10.3.1 试生产过程及其控制措施宜能代表目标批量生产过程。
注： 试生产是生产发布之前相关项或要素的生产。
10.3.2 在试生产阶段，可以分析试生产过程和目标批量生产过程的差异，以确定是否具备生产过程能力。
注 1 ： 如果试生产过程和目标批量生产过程相同，可在试生产中获得符合 11.2.3 的生产过程能力。
注 2 ： 差异可包括生产率、生产或控制步骤的顺序以及方法、测试设备和工具。
10.4 运行、服务和报废的计划
10.4.1 应制定相关项的运行、服务和报废计划，并考虑以下因素：
a) 维护和维修的要求；
b) 为确保车辆安全运行而应具备的用户须知信息的要求（见 10.4.4 ）；
c) 报废的要求；
d) 紧急救援服务的要求；
e) 报警和降级策略；
f) 现场监控流程；
g) 要素处理的条件；
示例 1 ： 硬件要素的允许存储时间。
示例 2 ： ECU 上软件的正确刷写。
h) 在生产发布文件中定义的配置；
示例 3 ： 在维修过程中，硬件、软件和软件标定数据允许的配置。
i) 参与人员的能力。
10.4.2 服务计划应描述对相关项或要素的维护活动的顺序和方法，包括维护间隔以及需要的工具。
10.4.3 服务指导说明应描述如下内容：
a) 服务的流程、方法、工作步骤和诊断程序；
b) 工具和设备；
示例 1 ： 程序设定、传感器标定和诊断设备。
c) 用于验证安全相关的特殊特性的控制步骤的顺序和方法，以及控制标准；
d) 相关项或要素的有关配置，包括可追溯性措施；
注： 如果在服务中进行重刷软件，刷写软件的工具具有确保车辆下载了正确版本软件的功能。
示例 2 ： 对要素使用标签，确保可追溯性。
e) 车辆允许的相关项或要素的功能关闭，及其所导致的车辆的任何变更；
f) 当功能关闭和其他变更发生时，需告知驾驶员；
示例 3 ： 通知驾驶员某项辅助功能已经被关闭。
g) 备件的供应。
10.4.4 用户信息，包括用户手册，应提供正确使用相关项或要素的有关指导说明和警告，如果适用，还应提供如下信息：
a) 相关功能（即预期使用、状态信息或用户交互）及其允许模式的描述；
b) 当报警和降级策略表明失效发生时。为确保可控性所需的用户行为的描述；
c) 当报警和降级策略表明失效发生时，对用户所期望的服务活动的描述；
d) 关于与第三方产品交互所导致的已知危害的警告；
示例 1 ： 当使用额外第三方的拖载挂车时，需要告知用户泊车辅助将不能检查车辆后方。
e) 为了防止驾驶员误解或误用，安全相关的整车新功能的正确使用的警告。
示例 2 ： 相对于手动驻车制动，自动驻车制动的误用可能导致驾驶员没有将驻车制动啮合就离开车辆。
10.4.5 报废指导说明应描述相关项或其要素在拆卸过程中采用的活动和措施，以确保其安全报废。
示例： 为避免对报废作业人员造成伤害，在车辆拆卸前对安全气囊进行解除的指导说明。
10.4.6 在运行、服务和报废计划过程中识别的安全要求，应按照项目安全管理办法，以适当的方式反馈给负责系统、硬件和软件开发人员。
示例： ECU 中的错误日志功能的软件规范，以便于服务中进行诊断。
10.4.7 救援服务信息，包括救援指导说明书或紧急救援指南，如果适用，应提供相关指导说明和警告，以避免救援操作时发生危害。
示例： 防止非预期的气囊点爆或电击伤害的信息。
11 生产
11.1 生产活动概述
本章的目的是通过对相关项及其要素的生产过程负责的有关制造商、个人或组织（如车辆制造商、供应商、子供应商等）来确保在生产阶段（产品发布给生产后）实现安全。如图 11.1 所示，本章主要内容包括： 生产过程、生产控制和生产许可。
图 11.1 生产安全活动流程
11.2 生产过程
11.2.1 生产过程及其控制措施，应按照 10.2 定义的计划进行执行和维护。
注： 这包括对参与生产的人员进行适当的培训。
11.2.2 应对生产过程（包括安全相关特殊特性的偏差）进行分析，目的是：
a) 识别过程失效；
b) 识别由于过程失效导致的对功能安全、预期功能安全和信息安全的潜在影响；
c) 采取恰当的措施，以确保识别的影响可以被避免或减轻；
注： 这类措施可包括要素的进一步控制措施、整理分类、处理和更换。
d) 验证采取措施的有效性。
11.2.3 针对功能安全、预期功能安全和信息安全，应评估并维护如下几项能力：
a) 生产过程；
b) 设备和工具；
c) 测试设备。
注 1 ： 生产过程能力的证据可通过，周期性的过程审核，或者是对每个执行过程步骤的人以及质量管理体系的周期性的资质认证措施来获得。
注 2 ： 过程能力涵盖了维护安全相关特殊特性的能力。
11.3 生产控制
11.3.1 安全测试设备应按照所采用的质量管理体系进行控制
示例： IATF 16949 中对监控和测量设备的管理要求。
11.3.2 安全生产相关控制应按照生产控制计划来执行，相关的控制报告应包含：控制时间、受控对象的识别和控制结果。
注 1 ： 整车层面的受控对象的识别，可以是车辆识别号或生产序列号。
注 2: 组件层面的受控对象的识别，可以是零件号或序列号。
注 3 ： 控制结果可以是一个单一状态，如通过或不通过，或者是对采集的数据针对边界条件的评估结果。
11.4 生产许可
11.4.1 只有在生产发布报告中定义的已被批准的配置才能进行生产，如有任何偏差应得到负责人的授权。
12 运行
12.1 运行活动概述
本章的目的是定义运行后持续确保智能驾驶系统安全的过程要求；定义用于识别操作期间与智能驾驶系统相关联的安全相关的不可接受的安全风险的措施以及用于在运行期间维持安全的措施。如图 12.1 所示，本章主要内容包括： 运行安全活动、安全监控机制和风险评估和应对措施。
图 12.1 运行活动流程
12.2 运行安全活动
12.2.1 应实施与相关项或其要素相关的潜在安全相关事件的运行安全活动，以便：
a) 提供能用于分析以探测功能安全、预期功能安全及信息安全问题存在的现场数据；
b) 分析现场数据，以探测功能安全、预期功能安全及信息安全问题的存在；
c) 启动相关措施，来处理识别到的功能安全问题、预期功能安全及信息安全问题。
注 1 ： 现场监控数据可以提供在用证明所需的证据，用于在其他环境中进行相关项或要素的后续发布。
注 2 ： 安全相关事件的现场监控过程包括决策过程、定义遏制和纠正措施（例如：召回）以及向利益相关者报告事件。利益相关者可以是组织内部的，如果是分布式开发，也可以是组织外部的。
12.3 安全监控机制
现场监控流程的期望取决于驾驶自动化等级、预期功能的复杂性以及危害的严重性。对于较低的驾驶自动化等级，普通的市场观察可能就足够了。对于较高的驾驶自动化等级，额外的手段可能是必需的，例如：自动驾驶数据存储系统（ DSSAD ） / 汽车事件数据记录系统（ EDR ）、车载 / 远程安全监视系统。
观察的内容包括但不限于：
12.3.1 功能已造成或潜在会造成伤害的事件，或功能已超过定义值并在不同情况下可能导致伤害的事件；
示例 1 ： 这些事件可能包括：
—— 事故或事件报告；
—— 驾驶员报告里声称的问题；
—— 车载机制指示的潜在弱点；
—— 可合理预见的误用报告；
—— 违背了与障碍物的最小距离；
—— 接近触发特定系统相应的场景。
注 1 ： 对于高等级的驾驶自动化系统，可能需要实施监控机制，例如车载监控这些机制能在事故发生之前探测到潜在的安全相关问题，在这种情况下，需要在开发阶段中定义功能安全、预期功能安全及信息安全车载监控机制要求。
示例 2 ： 车载监控机制包括：
—— 捕捉触发紧急系统响应的场景；
—— 捕捉驾驶员非预期接管的场景；
—— 车捕捉导致最小风险状态的场景。
12.3.2 知识体系；
示例 3 ： 知识体系可能包括：
—— 来自公共安全机构（包括其他车辆制造商）的市场上公开可用、可能与该功能相关的事件；
—— 来自其他相似系统设计或相似功能的经验教训。
12.3.3 可能影响功能安全、预期功能安全及信息安全并可能导致重新考虑功能安全、预期功能安全及信息安全评估的环境演变。
注 2 ： 环境演变代表了场景中的变化，这些变化包括但不限于运行范围的变化和用户的系统交互的变化。
示例 4 ： 该演变可能包括：
—— 道路和交通的演变；
—— 法规修改；
—— 基础设施改变；
—— 新的用法及其误用；
—— 道路使用者特征的演变；
—— 通常的用户习惯的改变，或因使用系统而导致的改变。
12.4 安全问题评估和解决
在功能安全、预期功能安全及信息安全的问题评估和解决流程中，定义了以下角色和职责：
—— 将相关数据提供给开发团队；
—— 评估收集的数据以确认风险是否仍然合理；
—— 如有必要，定义和推出确保安全的措施。
运行阶段活动包括但不限于以下。
12.4.1 监控和分析
a) 监控的步骤是根据 12.3 定义的观察相关主题进行连续监控。监控可能是被动的 [ 见 12.3a)] 和主动的 [ 见 12.3b) 、 12.3c)] 。此外，监控可能发现在开发阶段未识别的潜在危害场景。
b) 如果观察到了任何安全相关事件，需要分析对安全论证的影响，并对安全论证的有效性再次评估。
注 1 ： 监控目标可能在开发阶段定义。
注 2 ： 安全相关观察能被用于更新或丰富数据库，以用于支持进一步开发所需的安全分析。
注 3 ： 如有必要，安全论证可能被更新。
12.4.2 风险评估
a) 如果安全论证不再有效，就需要评估风险。
b) 与开发阶段的危害风险评估相比，现场风险评估有所不同，特别是现场风险评估是基于运营过程中发生的问题的实际后果，而不是开发阶段的假设或估计。
1) 发生概率的评估
注： 根据安全相关错误与其不同类别根本原因的相关性分析，智能驾驶系统的安全相关问题可能由随机硬件故障和 / 或系统因素（如系统故障或功能不足）引起。
—— 对于与随机硬件故障相关的问题，所考虑的发生率由 GB 34590-2022 所考虑的故障率和暴露于危险场景的概率决定；
—— 对于与系统失效或功能不足相关的问题，风险主要由暴露在关键情况下的概率或触发事件的概率决定；
—— 由于在这个阶段可以知道车辆的数量和位置，因此可以提供比开发期间更高的精度。
示例： 可以根据部件的故障率、现场车辆数量以及车辆面临危险场景的概率来预测给定时间段内问题的发生率。
b) 严重度评估
注 1 ： 严重程度评估可以基于危害分析和风险评估文档定义的方法。
注 2 ： 此外，还可能考虑其他可能因网络安全风险、违反交通规则或严重客户投诉而造成损失的问题
3) 检测和缓解措施的评估
注 1 ： 缓解措施可以帮助检测和减轻智能驾驶系统中的错误风险。如果现场数据显示有相关证据，驾驶员的潜在可控性也可以被视为可控措施。
注 2 ： 对于严重事故（如死亡事故），即使根据预定义的标准将事故发生率评为较低或检测率评为较高，也可以调整评级标准，并以不同的方式考虑风险。
4) 可以根据上述因素以定性或定量的方式进行风险评估（如果为每个因素定义了比率）。评估结果将支持确定要采取的应对措施。
12.4.3 危害缓解
a) 基于观察的风险，来决定风险缓解方法。为缓解不合理风险，快速响应是必需的。在执行相应安全活动来最终修复以前，可以采取不需要任何额外安全活动的措施（如通过 OTA 来部分或完全抑制功能）。增加新的安全措施并升级系统作为长期行动项是必要的，这需要执行额外的安全活动，并进行一次新的安全发布。
注 1 ： 在线升级（ OTA ）能提供一种灵活方便的方法来实施修改，以便在运行阶段及时解决识别出的安全风险（见附录 A ）
注 2 ： 对于量产后，通过在线升级（ OTA ）方式新增或更新驾驶自动化功能时，不能以具备现场安全监控系统为由，代替或部分代替安全验证和确认活动。
b) 如果现场发生危险事件，可采取以下额外对策：
—— 发布调查行动以确定风险原因，例如基于采集的数据重建场景，特别是针对自动驾驶相关事件或事故；
—— 12.4.3 中引入的风险评估；
—— 对使用或功能停用或接管者的环境的限制；
—— 当发现不可接受的系统故障或不足时，更新智能驾驶系统，例如 OTA 更新；
—— 用户通知可以与对使用环境或智能驾驶系统更新操作的限制同时进行，或专门通知以解决误用风险，例如通过在自动驾驶车中控屏中警告显示向用户强调操作要求。
注 1 ： 根据已识别现场风险的紧迫性，可根据风险评估采取立即行动或长期行动。
注 2 ： 适当的问题管理流程对于确保对策的有效性非常重要，包括事件或事故报告、问题调查、风险评估和对策管理流程。
c) 所采取的对策的有效性在实施后进行监测和评估，如果风险仍然不合理，则进行调整。
d) 对于每个网络安全事件，应制定并执行网络安全事件应对计划，包括：
1) 补救行动
注 1 ： 补救措施由脆弱性管理来决定
2) 一个沟通计划
注 2 ： 沟通计划的建立可以涉及内部有关各方，如市场或公共关系、产品开发团队、法律、客户关系、质量管理、采购。
注 3 ： 沟通计划可以包括确定内部和外部的沟通伙伴（如发展、研究人员、公众、当局），并为这些受众开发具体信息。
3) 为补救行为分配的责任。
注 4: 负责的人应有：
—— 受影响的项目或部件，包括遗留项目和部件的专业知识；
—— 组织知识（如业务流程、通信、采购、法律）；
—— 决定权；
4) 记录与网络安全事件有关的新网络安全信息程序
注 5 ： 可以收集新的网络安全信息，例如以下信息：
—— 受影响的部件
—— 相关的事件和漏洞
—— 法政数据，如数据日志、碰撞传感器数据
—— 终端用户投诉
5) 一种确定进展的办法
例： 衡量进展的标准是：
—— 受影响的项目或组件被修复的百分比
—— 受补救行动影响的项目或部件的百分比
6) 结束网络安全事件响应的标准
7) 采取行动进行关闭
13 服务、报废和停用
13.1 报废和停用概述
本章的目的是传达网络安全支持的结束；确保在车辆生命周期的服务（维护和维修）以及报废子阶段中实现安全。如图 13.1 所示，本章主要内容包括： 信息安全支持的结束，服务、报废和停用。
图 13.1 报废和停用流程
13.2 信息安全支持的结束
13.2.1 应建立一个程序，以便在一个组织决定结束对某一项目或组件的网络安全支持时向客户通报。
注 1 ： 这些通信可以根据供应商和客户之间的合同要求进行处理。
注 2 ： 可以通过公告的方式向车主传达信息。
13.3 报废和停用
13.3.1 企业和组织对相关项及其要素的运行、服务和报废应按照服务计划、服务指导说明和报废指导说明来实施和文档化。
注 1 ： 这包括维修和维护流程的应用，以及此应用的纸质或电子文档的提供。
注 2 ： 包含 T &B 车辆的再制造。
注 3 ： 零件的供应、存储和运输按照 10.2.1 。
13.3.2 应提供开发后有关停用的信息安全要求。
注 1 ： 与这些要求有关的适当文件（如说明、用户手册）可以使网络安全方面的停用工作得以进行。
附录 A OTA 更新的安全考虑
由于验证和确认过程几乎不可能遍历所有场景，另外，运行环境也在不断发生变化。因此在运行阶段可能会识别到新的触发条件、功能不足和网络攻击威胁。如果这些触发条件、功能不足和威胁情况导致的风险不可接受，则需要快速响应从而消除或减少这些风险。例如，可通过更新地图数据、更新机器学习算法和 ODD 的变更等措施来应对。这些都依赖于在线更新（ OTA ）技术， OTA 提供了一种灵活、方便的方式来快速修正新识别安全风险。但是需要关注的是，在 OTA 过程中，需要合适的更新策略和流程。否则可能会引入额外的风险。
OTA 更新需要在规范定义阶段进行必要定义，包括以下可能的方面。
—— OTA 更新策略：
-
对新识别到的触发条件、功能不足和威胁情况进行分类；
-
对新识别到的触发条件、功能不足和威胁情况的影响进行分析；
-
OTA 更新过程和更新后对其他车辆功能的影响分析；
-
OTA 更新后功能的安全运行。
—— OTA 更新的条件：
-
车辆状态；
-
功能状态。
示例：在 OTA 更新过程中，部分车辆功能（例如，驾驶功能）可能不可用，因此，车辆要停在不妨碍其他交通流正常通行的地方进行升级。
—— OTA 更新中的 HMI 考虑：
-
OTA 更新需要获得用户同意；
-
OTA 更新前需要提供充分信息给用户，从而避免用户误用。例如， OTA 更新的目的、可能受影响的车辆功能、更新进度和预期结束时间等。
A.1 智能驾驶系统的重新训练、重新验证和重新批准
该系统可以在采集的现场数据和对策的基础上逐步开发，以补偿已识别的风险，是系统更加安全，更稳健。本节旨在介绍自动驾驶模型的重新训练、重新验证、重新批准和重新运行。
a) 重新训练
在运行过程中，可以收集有价值的现场数据，结合先前训练的模型数据，可以用于重新训练新模型，以期望更好的性能。重新训练可以通过微调预先训练的模型或从头开始训练来实现：
—— 微调 ; 微调是指对模型参数进行小的调整。新获取的现场数据可用于微调发布的模型。微调时，使用较小的学习率，以免过度扭曲现有模型。
示例 1 ： 对于某些特定于 DNN 的多任务网络，通常情况下，只有一个特定的任务头，需要进行微调，同时冻结主干和其他任务头，例如，当输入训练数据被标记用于检测时，只有检测头被微调。
—— 从头开始训练：通常在长时间运行后，可以随机初始化模型的所有参数，以从头开始重新训练模型。这种方法有望获得比原始模型中的微调更好的性能。然而，与微调相比，这种方法需要更多的数据量、计算时间和计算资源。使用预先训练好的主干是一种常见的方法。应用现有的主干来训练所需的任务可以降低计算成本并加快收敛速度。
b) 重新验证
重新训练后的自动驾驶模型被集成到智能驾驶系统中，并进行重新验证，并提供证据证明已经解决安全相关问题，满足所有相关安全要求。
示例 2 ： 已知问题的回归数据集可用于在虚拟和 / 或真实世界测试中重新验证更新的智能驾驶系统
c) 重新批准和重新运行
智能驾驶系统更新后，将重新评估安全保证论点。一旦重新批准，就可以重新运行智能驾驶系统。