编号	文档
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 21448: Road vehicles- Safety of the intended functionality
Ref [7]	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 43267: 道路车辆预期功能安全

3 术语缩写与定义

3.1 缩写

表4列出了本规范中专有名词的英文全称及相应的中文。

表 4 缩写

缩写	含义
ACC	Adaptive Cruise Control( 自适应巡航控制 )
ASIC	Application -Specific Integrated Circuit( 专用集成电路 )
ASIL	Automotive Safety Integrity Level （汽车安全完整性等级）
BIST	Built-In Self-Test( 内建自测试 )
CAN	Controller Area Network( 控制器局域网络 )
CPU	Central Processing Unit( 中央处理单元 )
EMC	Electro Magnetic Compatibility( 电磁兼容性 )
EMI	Electro Magnetic Interference( 电磁干扰 )
FMEA	Failure Mode and Effects Analysis( 失效模式与影响分析 )
FPGA	Field Programmable Gate Array( 现场可编程门阵列 )
FTA	Fault Tree Analysis( 故障树分析 )
HARA	Hazard Analysis and Risk assessment （危害分析与风险评估）
HAZOP	HAZard and Operability analysis ( 危害分析和可操作性分析 )
HSI	Hardware-Software Interface( 软硬件接口 )
QM	Quality Management( 质量管理 )
ISO	International Standards Organization （国际标准组织）
RAM	Random Access Memory( 随机存储器 )
SIL	Safety Integrity Level （安全完整性等级）
MEL	Minimum Equipment List （最低设备清单）
FTTI	Fault Tolerant Time Interval （故障容错时间间隔）
DDT	Dynamic Driving Task ( 动态驾驶任务 )
ODD	Oper Operational Design Domain( 设计运行范围 )
SOTIF	Safety Of The Intended Functionality( 预期功能安全 )

3.2 术语和定义

危险等级

对与未缓解危害相关的风险进行分类的级别。

可接受

足以实现安全案例中确定的总体项目风险。

故障模型

执行故障分析时要考虑的所有故障（及其类型）的规范。

项目

评估符合本规范的产品、元素、系统或其他与产品相关的范围。

减轻

降低到可接受的风险水平。

证据

用于支持参数的数据或其他信息。

风险

损失事件发生的可能性和该损失事件的严重性组合。

安全

具有安全案例所定义的可接受的缓解后项目级风险。

安全案例

有证据支持的结构化论点，提供了令人信服、可理解和有效的证据，表明系统对于给定环境中的给定应用程序是安全的。

接受准则

表征不存在不合理风险水平的准则。

行为

场景快照中任何参与者所实施的单一行为或表现。

驾驶策略

定义整车层面可接受的控制行为的策略和规则

动态驾驶任务

车辆在交通流中运行时所需的实时操作功能和决策功能。

事件

在某一时刻所发生的事情。

功能不足

规范定义不足或性能局限。

功能修改

功能规范的变更。

危害

由整车层面危害行为导致的伤害的潜在来源。

规范定义不足

可能不完整的规范定义，当被一个或多个触发条件触发时，会导致危害行为或导致无法防止、探测及减轻可合理预见的间接误用。

预期行为

预期功能的行为。

预期功能

已定义的功能。

误用

以制造商或服务提供商不期望的方式使用。

误用场景

发生误用的场景。

设计运行范围

对于给定的驾驶自动化系统，设计确定的功能运行的特定条件。

性能局限

技术能力局限，其在一个或多个触发条件触发下，促成危害行为或无法防止、探测及减轻合理预见的间接误用。

反应

场景快照中任何参与者对行为的反馈。

预期功能安全

不存在因预期功能或其实现的功能不足引起的危害而导致不合理的风险。

场景

按照场景快照的先后顺序，对几个场景快照的时间关系进行的描述，包扣特定情况下受行为和事件影响的目标和取值。

场景快照

环境快照，包括背景、动态要素、所有参与者和观察者的自我表征以及这些实体之间的关系。

单点功能不足

在一个或多个触发条件触发下，直接导致危害行为或无法防止、探测及减轻可合理预见的误用的要素的功能不足。

态势感知

对态势的理解。

触发条件

场景中的特定条件，这些条件引发了系统的后续反应，这些反应促成了危害行为或无法防止、探测及减轻可合理预见的间接误用。

不合理的风险

按照现行的安全观念，被判断为在某种环境下不可接受的风险。

用例

一组相关场景的描述。

确认目标

用于论证满足接受准则的值。

优先度子集

按照一定的规则对要素的属性进行排序，所挑选出的部分要素集合。

架构

相关项或要素的结构的表征，用于识别结构模块及其边界和接口，并包括将要求分配给结构模块。

A SIL 等级分解

为有助于实现同一安全目标，将冗余的安全要求分配给具有充分独立性的要素，以降低分配给相关要素的冗余的安全要求的A SIL 等级。

评估

对相关项或要素的特性使否实现目标的检查。

可用性

在定义的生命周期内，产品在给定条件下按照要求提供规定功能的能力。

标定数据

在开发过程中，软件构建后将用作软件参数值的数据。

组件

由一个以上硬件元器件或一个到多个软件单元组成的逻辑上或技术上可分的非系统层面的要素。

配置数据

在要素构建过程中分配的且控制要素构建过程的数据。

可控性

通过所涉及人员的及时反应[可能具备外部措施的支持 ] 避免特定的伤害或者损伤的能力。

降级

相关项或要素的功能缩减、性能降低或两者均有的状态，或向该状态的过渡。

诊断覆盖率

由实施的安全机制探测或控制的失效率占硬件要素失效率或硬件要素某一失效模式失效率的百分比。

诊断测试时间间隔

安全机制执行在线诊断测试之间的时间间隔，包括在线诊断测试的执行时间。

多样性

以实现独立性为目标，满足相同要求的不同解决方案。

双点故障

与另一个非相关故障组合而导致双点失效的一个故障。

双点失效

由两个独立硬件故障的组合引起，且直接导致违背安全目标的失效。

电气/电子系统

由电气和/或电子要素，包括可编程电子要素所构成的系统。

要素

系统、组件、硬件元器件或软件单元。

紧急运行

相关项的一种运行模式，用于对故障作出反应后提供安全，直到过渡到安全状态。

紧急运行时间间隔

保持紧急运行的时间间隔。

紧急运行容错时间间隔

在无不合理风险的情况下，能够维持紧急运行的特定时间间隔。

错误

计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。

暴露

处于某运行场景的状态，在该运行情况下，如果发生所分析的失效模式，可能导致危害。

外部措施

独立于且不同于相关项的措施，以降低或减轻由相关项导致的风险。

失效

由于故障出现导致要素或相关项预期行为的终止。

失效模式

要素或相关项未能提供预期行为的方式。

失效率

硬件要素的失效概率密度除以幸存概率。

故障

能够引起要素或相关项失效的异常情况。

故障探测时间间隔

从故障发生到被探测到的时间间隔。

故障处理时间间隔

故障探测时间间隔和故障响应时间间隔的总和。

故障注入

评估要素内故障影响的方法，该方法通过注入故障、错误、或失效从而通过观测点对注入后的响应进行观测。

故障响应时间间隔

从探测到故障到进入安全状态或进入紧急运行的时间间隔。

故障容错

在一个或多个特定故障存在的情况下，实现特定功能的能力。

故障容错时间间隔

在安全机制未被激活情况下，从相关项内部故障发生到可能发生危害事件的最短时间间隔。

现场数据

从相关项或要素的使用中获得的数据，包括累积运行时间、所有失效和服务中的安全异常。

免于干扰

两个或两个以上的要素之间，不存在可能导致违背安全要求的级联失效。

功能概念

实现预期表现所需的各预期功能及其交互的定义。

功能安全

不存在由电气/电子系统的功能异常表现引起的危害而导致不合理的风险。

功能安全概念

为了实现安全目标，定义功能安全要求及相关信息，并将要求分配到架构中的要素上，以及定义要素之间的必要交互。

功能安全要求

定义了独立于具体实现方式的安全行为，或独立于具体实现方式的安全措施，包括安全相关的属性。

硬件元器件

硬件组件在第一层级分解时的一部分。

伤害

对人身健康的物理损害或破坏。

危害

由相关项的功能异常表现而导致的伤害的潜在来源。

危害事件

危害和运行场景的组合。

独立性

两个或者多个要素间不存在会导致违背安全要求的相关失效，或从组织上分隔执行某一活动的各方。

继承

在开发过程中，某些要求的属性以一种未改变的方式传递到下一细节层面。

检查

为发现安全异常而依据一个正式的流程对工作成果进行考查。

3.3 约定术语

本文档中使用了下列术语：

 “强制性”：表示不允许出现安全案例偏差

 “需要”：表示仅当通过提示证明提示元素与项目和/或其安全案例本质上不兼容时，才允许发生安全案例偏离。

 “强烈推荐”：表示是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。

 “推荐”：表示这些是可选的提示元素，记录了良好做法和/或有用技术的建议。

4 系统设计融合安全概述和组织

4.1 概述

本规范的目的是：

a) 提供支撑自动驾驶系统功能安全、预期功能安全和信息安全开发的规范定义和设计的要求；

b) 按照功能安全和信息安全目标，导出功能安全和信息安全要求；

c) 按照功能安全和信息安全要求，制定技术安全要求；

d) 对系统响应进行 SOTIF 可接受性评估；

e) 确定并实施解决 SOTIF 相关风险的措施；

f) 定义系统需要满足的自治功能和支持要求；

g) 定义系统可靠性和安全要求。

4.2 总则

如图 4.1 所示，本规范为自动驾驶系统系统安全设计列出的要求和建议，规范内容包括系统规范定义和设计、功能安全与信息安全概念、功能安全与信息安的技术安全概念、潜在功能不足和触发条件的评估与识别、改进预期功能安全的措施、自治功能和支持、系统可靠性和安全要求等。

图 4.1 本规范整体架构

4.3 系统设计融合安全原理

如图 4.2 所示，在系统规范定义阶段可将功能安全相关项定义、预期功能安全规范定义、信息安全项目定义合并为一组文档；根据危害分析结果依次执行功能安全和信息安全活动及预期功能安全活动；对功能安全和信息安全活动与预期功能安全活动的相互影响进行考虑和处理；最后，验证系统整体自治功能和支持及系统可靠性和安全要求。

图 4.2 系统设计融合安全原理

5 系统规范定义和设计

5.1 功能安全相关项定义、预期功能安全规范定义和信息安全项目定义的考虑

功能安全中的相关项定义、预期功能安全中的规范定义、信息安全中的项目定义和设计文档可合并为一组文档，提供对系统及其要素、功能和性能目标的充分理解，以便执行后续阶段的活动。这组文档可包含以下所列的各个方面，某些方面仅与特定的自动化等级或特定的实现相关。此外某些方面与整车层面或要素层面的功能规范定义相关

考虑的方面（如适用）包括但不限于以下方面。

5.2 功能规范

在功能规范中应描述系统功能相关的定义和约束，包括：

a) 功能清单与功能定义，描述系统预期的功能和典型用例；

注：描述系统在生命周期各阶段 [ 如产品开发（测试）、生产、运营、维护和停用 ] 的预期行为，包括系统实现的车辆功能

b) 设计运行条件（ ODC ）；

c) 自动驾驶功能控制车辆动态任务的权限级别和细节；

d) 自动驾驶系统的性能目标，包括在 DOC 范围内对关键目标和事件的探测与响应能力；

e) 状态及状态转换的定义；

f) 数据收集和监控系统描述：

- 数据收集的目的和要求

- 在 SOTIF 发布前，支持开展所需数据收集的架构、实现和机制；

- 运行阶段，支持数据收集的要求、设计和机制，以用于功能安全、预期功能安全和信息安全分析，包括可能基于云、 OTA 或视频通讯等技术；

g) 适用的法规要求、国家标准和国际标准。

5.3 系统架构与规范

应对自动驾驶系统的范围进行定义，明确属于该系统的子系统和要素，并识别与其存在交互关系的外部系统或要素，该部分包括：

a) 定义该自动驾驶系统的范围，系统的组件，包括主要硬件和软件；

b) 识别并定义与该系统存在交互关系的外部系统或要素；

c) 车辆上可能干扰系统功能的其他功能，包括信息交换和相应的使用假设；

d) 车辆及系统架构图，包括自动驾驶系统和整车架构，说明该自动驾驶系统及其组件构成、外部相关系统及零部件、系统内外部接口；

e) 描述系统组件的主要功能和性能目标，包括传感器、控制器、执行器 / 或其他输入组件；

f) 感知组件的输入、输出形式，感知组件正常工作的范围，感知组件异常对自动驾驶功能的影响；

g) 感知系统组件的关键安装信息，包括：

1) 部件在车辆上的位置

2) 部件外表面材料、尺寸、形状、光洁度；

3) 对 ADS 安全性能具有较大影响的安装规范，等；

h) 决策逻辑的描述（如：路径规划，驾驶策略等），决策组件的输出，以及对车辆运动控制影响的描述。

注：可以考虑有关制约因素和适用的网络安全标准的信息。

5.4 外部交互

应描述系统与如下条目间的依赖关系、交互或接口 :

a) 与驾驶员的交互，包括对驾驶员提醒的方式和预期的行为，驾驶员干预的条件（如：干预的方式、转向干预的力矩、踏板干预的开度、持续时间等），及如何使用交互以减轻已知的可合理预见的误用；

b) 远程 / 后台操作人员；

c) 乘客、行人、骑自行车的人和其他道路使用者；

d) 相关环境条件；

e) 道路基础设施和道路设备；

f) 云端、车辆间或其他通信基础设施（见 5.6 ）以及涉及诊断和参数更新的在用远程信息处理之间的数据交换；

g) 软件更新的远程刷写；

h) 应描述与网络安全相关的项目的操作环境。

注：对操作环境及其与项目相互作用的描述，可以识别或分析相关的威胁情景和攻击路径。

注：相关信息可以包括假设，例如假设该项目所依赖的每个公钥基础设施证书机构都得到了适当的管理。

5.5 系统安全与响应策略

基于以下原则，制定自动驾驶系统的安全与相应策略：

-功能激活后，系统执行动态驾驶任务，管理包括故障在内的所有运行情况，对车辆乘员和/或其他道路参与者不存在不合理的风险；

-系统不主动引起可合理预见和可预防的碰撞；

-可安全地避免碰撞地发生，过程中不导致新的其他碰撞

示例：当车辆涉及可检测的碰撞时，可通过使车辆过渡到或处于静止状态而避免风险。

在系统安全与相应策略中，描述已识别出的潜在风险、应对策略和机制等，以使系统达到并保持合理的安全水平，包括但不限于：

a) 整体安全策略

b) 已知的功能安全失效，潜在安全影响及相关安全措施；

c) 可合理预见的误用（直接和间接）及应对措施；

d) 系统及其要素的潜在的性能局限、已识别出的触发条件、应对措施。

e) 对 ODC 边界的探测及应对措施（在即将离开 ODC 时，系统发起控制权限转换，如何保障过程中的安全运行和驾驶权妥善移交）；

f) 报警和降级概念；

 报警策略；

 DDT 后援：接管 / 后援的条件和方案，用于在各自的用例中，将控制权从自动驾驶系统转移到驾驶员或另一系统；

 最小风险状态方案（例如，自动靠边停车、在路径中停车、后援用户）；

 驾驶员监控系统及其后援策略的影响。

g) 运行阶段，支持形成风险缓解能力的机制、设计和要求。

5.6 车路云通信规范定义

定义车路云通信的属性：

a) 车路云系统要求：

 时延要求；

 可靠性要求；

 互操作性要求。

b) 车路云数据要求：

 车路云消息中包含的物体或事件的准确率要求：数据被认为正确或真实的程度（包括位置和时间精度）；

 车路云消息中包含的物体或事件的完整性要求：确保数据元素没有损坏；

 精确度要求：平均值的标准差；

 分辨率要求：两个相邻值的最小差值；

 可追溯性要求：跟踪质量满足情况的能力；

 一致性要求：符合互操作性标准，以及基本通信要求、基本防护要求、安全要求、信任和保证等级要求

c) 车路云消息在整车层面的功能应用。

d) 已知车路云的局限（例如，超出道路设施的覆盖范围，其他设备的干扰）。

5.7 AI 系统架构

针对 AI 系统中的 AI 模型部分，其架构设计中还需要包含以下内容：

a) 系统架构 AI 模型的详细架构描述

b) AI 模型其包含组件的详细描述

c) AI 模型其构成组件之间的接口定义；

d) AI 模型的配置与参数；

e) AI 模型的动静态特性；

f) AI 模型所依赖的第三方组件。

注 1 ：如果适用，应在 AI 模型及其组件描述中体现激活函数相关信息。

示例 1 ：详细描述还可包括模型架构，损失函数，优化算法，正则化方法，输入和输出，训练细节，性能评估指标，超参数设置，数据集描述，模型解释性，模型限制和假设，实现细节等。

示例 2 ：基于卷积神经网络的目标检测模型中经常使用的 backbone ,neck ,head 结构。

示例 3 ： AI 模型的参数一般都至少包含超参数与模型参数（权重与偏置）两类。

注 2 ：如果适用， AI 模型的动态特性描述需要至少对模型的前向传播与反向传播两个过程进行描述。

示例 4 ：在 AI 模型中使用经过开源数据集预训练的 VGG16 卷积神经网络作为 AI 模型的 backbone ，其中 VGG16 卷积神经网络便属于第三方组件。

5.8 系统安全定义和设计的迭代更新

根据 5.2-5.7 的要求，建立的系统规范定义和设计文档，可随着功能安全、预期功能安全和信息安全相关活动的迭代，引发相关层面上对规范定义和设计的更新。随着系统与安全相关的功能设计发生变化，安全活动识别出新的风险，定义安全改进需求及措施，规范定义和设计也将同步进行更新。

需确保系统规范定义和设计从系统迭代中获取到相关信息，同时确保规范定义和设计为下一个迭代周期做好准备。

6 功能与信息安全概念模块

6.1 功能安全与信息安全要求的导出

6.1.1 功能安全要求应由安全目标导出，并考虑系统架构设计。

6.1.2 应描述技术或操作性信息安全控制措施及其相互作用，以实现信息安全目标，同时考虑到：

a) 项目的功能之间的依赖性；

b) 信息安全索赔；

注 1 ：说明中可以包括：

—— 实现网络安全目标的条件，如预防入侵、检测和监控入侵。

—— 专门用于处理威胁情况的具体方面的功能，例如使用安全通信渠道。

注 2 ：该描述可用于评估设计和确定信息安全验证的目标。

6.1.3 应根据 6.1.2 的描述，为信息安全目标确定项目的信息安全要求和对运行环境的要求。

注 1 ：信息安全要求可以取决于或包括项目的具体特征，如更新能力或在操作中获得用户同意的能力。

注2：对运行环境的要求是在项目之外实现的，但它们包括在项目的信息安全验证中，以确定是否实现了相应的信息安全目标。

注3：对作为运行环境一部分的其他项目要求可以是对这些项目的信息安全要求。

6.1.4 应为每一个安全目标导出至少一项功能安全要求。

注：同一个功能安全要求可以由几个不同的安全目标导出。

6.1.5 如果适用，功能安全要求应为以下内容定义策略：

a) 故障避免；

b) 故障探测、对故障或其导致的功能异常表现的控制；

c) 过渡到安全状态，及如果适用，过渡出安全状态；

d) 故障容错；

e) 故障情况下的功能降级，及其与 f )或 g )的交互。

示例：将车辆保持在跛行模式，直到点火开关从 “ 开 ” 切换到 “ 关 ” 。

f) 将风险暴露时间缩短到可接受时间所需的驾驶员警告；

g) 增加驾驶员可控性所需的驾驶员警告（例如，发动机功能异常指示灯、 ABS 故障报警灯）；

h) 如何满足整车层面的时间要求（即，如何定义故障处理时间间隔来满足故障容错时间间隔）；

i) 避免或减轻因不当仲裁了不同功能同时产生的多个控制请求而导致的危害事件。

注：列出项目 c ）、 e ）、 f ）和 g ）可以作为报警和降级策略的一部分。

6.1.6 如果适用，应考虑以下内容来定义每项功能安全要求：

a) 运行模式；

b) 故障容错时间间隔；

c) 安全状态；

d) 紧急运行时间间隔；

e) 功能冗余（例如，故障容错）。

注：为了制定一套完整有效的功能安全要求，安全分析 [ 例如， FMEA 、 FTA （故障树分析）、 HAZOP] 可为以上活动提供支持。

6.1.7 如果可以通过过渡到或保持一个或多个安全状态来避免安全目标的违背，那么应定义相应的安全状态。

示例：一个安全状态可以是发生失效时在规定时间内 “ 关闭 ”“ 锁定 ”“ 车辆静止并保持 ” 或 “ 功能降低 ” 。

6.1.8 如果在一个可接受的时间间隔内，不能过渡到安全状态，应定义紧急运行。

6.1.9 如果为了避免违反安全目标而对驾驶员或其他人员的必要行动做出假设，则应：

注 1 ：这些行动包括在可控性预测期间被认为是具有可信度的那些行为，以及在实施安全要求之后为满足安全目标所做的任何进一步的必要行为。

示例：自适应巡航控制（ ACC ）：当驾驶员踩下加速踏板时， ACC 产生的制动被抑制。

a) 在功能安全概念中应定义这些行为；

b) 在功能安全概念中应定义可供驾驶员或其他人员使用的足够的方法和控制手段。

注 2 ：对驾驶员的工作任务分析有助于考虑防止驾驶员超负荷，防止驾驶员的惊吓或恐慌（丧失控制车辆的能力）和模式混淆（关于操作模式的不正确的假设）。

注 3 ：报警和降级策略的定义、驾驶员和其他潜在涉险人员的必要行动是用户手册的一种可能输入。

6.1.10 功能安全与信息安全要求应分配给系统架构设计中的要素：

a) 在分配要求时， ASIL 等级和 6.1.4 中所给出的信息应从相关的安全目标中继承得到；

b) 如果无法证明系统架构设计中实施安全要求的各要素之间免于干扰，则这些架构要素应按照所实施安全要求中最高的 ASIL 等级进行开发；

c) 如果相关项包含多个电气 / 电子系统，则应根据系统架构设计定义各个电气 / 电子系统以及系统之间接口的功能安全要求，这些功能安全要求应分配到各个电气 / 电子系统中；

d) 如果相关项包含多个电气 / 电子系统，则可定义相应的随机硬件故障度量目标值并分配给各个电气 / 电子系统；

注 1 ：按照系统架构设计定义电气 / 电子系统的目标值，并在各开发阶段进行细化。

e) 信息安全要求应分配给该项目，并在适用时分配给其一个或多个组成部分。

注 2 ：信息安全控制的描述是对网络安全要求和操作环境要求的具体化和分配的补充，它们共同构成了信息安全概念

6.1.11 如果功能安全概念依赖于其他技术的要素，则以下内容应适用：

a) 导出基于其他技术的要素所实现的功能安全要求，并将其分配给架构中的相关要素；

b) 定义与其他技术要素的接口相关的功能安全要求；

c) 通过特定的措施来保证基于其他技术的要素所实现的功能安全要求；

d) 无需对分配给这些要素的安全要求分配 ASIL 等级。

注 1 ：对于分配给采用其他技术的要素的安全要求，可以定义合适的安全属性。

注 2 ：在安全确认活动期间需要提供证据证明，采用其他技术的要素是充分的。

6.1.12 如果功能安全概念依赖于外部措施，则以下内容应适用：

a) 导出并传达由外部措施实施的功能安全要求；

b) 规定与外部措施接口的功能安全要求；

c) 如果外部措施由一个或多个电气 / 电子系统实施，则按照本规范指定功能安全要求。

注：在安全确认活动期间需要提供证据证明外部措施是充分的。

6.2 安全确认准则

6.2.1 应基于功能安全要求和安全目标对相关项安全确认的接受准则进行定义。

注 1 ：安全目标的安全确认不仅在 V 流程的安全确认中执行，也在开发阶段中执行。

6.3 功能安全与信息安全概念的验证

6.3.1 功能安全与信息安全概念应按照验证模块进行验证，提供证据证明：

a) 其与安全目标的一致性和符合性；

b) 减轻或避免危害的能力。

c) 在信息安全索赔方面的一致性。

注 1 ：在概念阶段，可以对减轻或避免危害事件的能力进行验证，来评价安全概念并指出概念改进之处。此验证可与安全确认中使用的方法相同。然而，安全确认不能只基于概念研究（例如，原型）。

示例：减轻或避免危害的能力，可通过测试、试运行或专家判断来评估，可结合原型、研究报告、专项测试或仿真。

注 2 ：针对该故障的特性（例如，是瞬态或者是永久的），对减轻或避免危害的能力进行验证

注 3 ：对于验证，可使用一种基于可追溯性的论据（即，如果相关项符合功能安全要求，则该相关项符合安全目标）。

7 功能安全与信息安全的技术安全概念模块

7.1 功能安全与信息安全的技术安全要求定义

7.1.1 技术安全要求应按照功能与信息安全概念、相关项的系统架构设计来定义。考虑如下：

a) 相关项、系统及其要素安全相关的关联性及约束条件；

b) 系统的外部接口，如果适用；

c) 系统可配置性。

注 1 ：设计约束可能来自于：环境条件、安装空间、实施本身（例如可用性能、热容量、热扩散）以及其他功能或非功能性要求（例如安全性、所用技术的物理限制）。

注 2 ：系统的可配置性由系统要素中的变量、配置数据或标定数据来确定，通常作为将现有系统复用于不同应用的策略的一部分。

7.1.2 技术安全要求应定义系统对影响安全要求实现的激励的响应。这包括在各种相关运行模式和所定义的系统状态下，激励与失效的组合。

示例：如果收到的 ACC 指令信息未通过错误检测代码检查，则制动系统电控单元（ ECU ）将禁用自适应巡航控制（ ACC ）制动。

7.1.3 除技术安全要求已定义的那些功能外，如果其他功能或要求也由该系统或其要素实现，则应定义这些功能或要求，或者参考其规范。

示例：其他要求可能来自联合国欧洲经济委员会（ UN/ECE ）法规、美国汽车安全技术法规（ FMVSS ）、公司平台战略、功能概念或其他概念，例如信息安全概念。

7.1.4 技术安全要求和非安全要求不应冲突

7.2 识别定义安全机制

7.2.1 技术安全要求应定义安全机制，用于探测故障并防止或减轻出现在系统输出端的违反功能安全要求的失效，包括：

a) 与系统自身故障的探测、指示和控制相关的安全机制；

注 1 ：包括用于探测随机硬件故障及探测系统性故障（如果适应）的系统自身监控

注 2 ：包括对通信通道失效（例如：数据接口、通信总线、无线射频链接）的探测和控制的安全机制。

注 3 ：可以在系统架构适当的层级定义安全机制

b) 涉及探测、知识和控制与本系统有相互影响的其他要素发生故障的安全机制 ;

示例：外部设备包括其他的电控单元、电源或者通信设备。

c) 使系统实现或维持在相关项的安全状态的安全机制 ;

注 4 ：包括来自安全机制的多个控制请求的仲裁

d) 定义和执行报警和降级策略的安全机制 ;

e) 防止故障处于潜伏故障的安全机制 ;

注 5 ：如同 a) ～ d) ，这些安全机制通常与上电过程（运行前检查）、运行中、下电过程（运行后检查）及维护过程中发生的自检相关。

7.2.2 对于每个使相关项实现安全状态或维持安全状态的安全机制，应定义下列内容：

a) 状态间的转换；

注 1 ：包括控制执行器的要求。

b) 与从适当的架构层级分配得到的时间相关的故障处理时间间隔；

注 2 ：该子要求的目的是在针对每个安全目标定义的故障处理时间间隔范围内，实现时间一致。

c) 不能在 FTTI 内进入相关项安全状态时的紧急运行容错时间间隔

注 3 ：整车测试和试验能够用于确定紧急运行容错时间间隔。

示例 1 ：安全状态之前的降级运行持续时间。

示例 2 ：一个依赖于电源的线控制动应用的安全机制，可以包括定义备用电源或储能设备（容量、启动和运行时间等）

7.2.3 本要求适用于 ASIL(A) 、（ B ）、 C 和 D 等级。如果适用，应定义安全机制，以防止故障处于潜伏故障。

注 1 ：仅随机硬件故障的多点故障有可能成为潜伏故障

示例：自检可作为检测多点故障的安全机制。用于验证组件在不同运行模式（例如上电、下电、运行或额外的自检模式）下的状态。阀、继电器或灯在常规上电时进行的功能检测就是自检的例子。

注 2 ：识别是否需要防止故障处于潜伏状态的安全机制的评估标准来源于良好的工程实践。

7.2.4 此要求适用于 ASIL(A) 、（ B ）、 C 和 D 等级。为了避免多点失效，应为每个探测多点故障的安全机制定义诊断测试策略，包括：

a) 硬件组件的可靠性要求，并考虑其在架构中的角色及其对多点失效的贡献；

b) 定义的量化目标值，表征由于随机硬件失效而违背各安全目标的最大可能性；

c) 已分配的 ASIL 等级，从相关安全目标、功能安全要求或更高层面的技术安全要求中导出；

d) 多点故障探测时间间隔。

注 1 ：诊断测试策略可以是时间驱动（例如使用诊断测试时间间隔）或者时间驱动（例如启动测试）。

注 2 ：二阶多点失效包含以多点故障检测时间间隔分隔的两个故障。

注 3 ：下列措施的使用取决于时间约束：

1) 系统或要素在运行过程中的周期性测试；

2) 要素在上下电时的自检；

3) 系统或要素在维护时的测试

7.2.5 本要求适用于 ASIL(A) 、（ B ）、 C 和 D 等级。仅为了防止双点故障处于潜伏状态而实施的安全机制的开发应符合：

a) ASIL B 等级（对于分配为 ASIL D 等级的技术安全要求）；

b) ASIL A 等级（对于分配为 ASIL B 等级和 ASIL C 等级的技术安全要求）；

c) QM 等级（对于分配为 ASIL A 等级的技术安全要求）；

注：如果安全要求运用了 ASIL 等级分解，那么本章的要求亦适用于分解后的要求。

示例：某内存存储采用奇偶校验作为安全机制，其安全要求被评为 ASIL B 等级。针对用于测试该奇偶校验机制在探测和指示内存故障的能力的自检测试，其要求可被评为 ASIL A 等级。

7.3 系统架构设计规范和技术安全概念

7.3.1 技术安全概念和该子阶段的系统架构设计应基于相关项定义，功能安全概念和先前的系统架构设计。

7.3.2 系统架构设计应实现技术安全要求

7.3.3 关于技术安全要求的实现，系统架构设计应考虑：

a) 验证系统架构设计的能力；

b) 与实现功能安全相关的预期软硬件要素的技术能力；

c) 在系统集成过程中执行测试的能力。

7.3.4 应定义安全相关要素的内部的外部接口，其他要素不应对安全相关要素产生不利的安全相关影响。

7.4 避免系统性失效

7.4.1 应按照表 4 和 GB/T 34590.9-2022 第 8 章进行系统架构设计的安全分析，其目的在于：

—— 为系统设计的适合性提供证据，以证明其适合提供与 ASIL 等级相适应的特定安全相关功能和特性；

—— 识别失效原因和故障影响；

—— 识别或确认安全相关系统要素和接口；

—— 支持设计规范，并基于已识别的故障原因和失效影响验证安全机制的有效性。

表 4 系统架构设计分析

方法		ASIL 等级
方法		A	B	C	D
1	演绎分析	o	+	++	++
2	归纳分析	++	++	++	++

注 1 ：安全相关特性包括独立性和免于干扰的要求。

注 2 ：这些分析的目的是辅助设计。因此在该阶段，定性分析是足够的。如果有必要，采用定量分析。

注 3 ：在足以识别随机硬件失效和系统性失效的原因和影响的细节层面上进行分析。

注 4 ：演绎和归纳的方法结合使用的目的是提供互补的分析方法，见 GB/T34590.9-2022 中的 8.2 。

7.4.2 为符合安全目标或要求，应消除已识别出的引起失效的内部原因，或在必要时减轻它们的影响。

7.4.3 为符合安全目标或要求，应消除已识别出的引起失效的外部原因，或在必要时减轻它们的影响。

7.4.4 为了减少系统性失效的可能性，宜在适用处应用值得信赖的系统设计原则。这些原则可能包括：

a) 值得信赖的技术安全概念的复用；

b) 值得信赖的要素设计的复用，包括硬件和软件组件；

c) 值得信赖的探测和控制失效的机制的复用；

d) 值得信赖的或标准化接口的复用。

7.4.5 应对值得信赖的设计原则的适用性进行分析并形成文档，以确保其和最终产品应用的一致性和适用性。

7.4.6 为了避免系统性故障。系统架构设计应具有以下特征：

a) 模块化；

b) 适当的颗粒度水平；

c) 简单；

注：可以通过使用诸如分层的设计，精确的接口定义，避免组件和接口不必要的复杂性，可维护性和可验证性之类的的设计原则实现上述特征。

7.4.7 在安全分析或系统架构设计过程中新识别的尚未被安全目标涵盖的危害，应更新到按照危害分析和风险评估中。

7.5 随机硬件失效的控制措施

7.5.1 按照 7.3 中的系统架构设计，定义探测、控制或减轻随机硬件失效的措施。

示例 1 ：这些措施可能是硬件的诊断特性，通过软件对其的使用来探测随机硬件失效。

示例 2 ：随机硬件失效发生时，不需要探测即可进入安全状态的硬件失效（即：失效 - 安全的硬件设计）。

注： 7.4.1 中归纳和演绎分析的量化估计有助于确定是否需要采取进一步的安全措施，并进行硬件分析，做出最终决定。

7.5.2 本要求适用于等级为 ASIL(B) 、 C 和 D 的安全目标。应选择可替代流程中的一个，用于评估随机硬件失效导致的对安全目标的违背，并应定义目标值以用于相关项层面的最终评估。

7.5.3 本要求适用于等级为 ASIL(B) 、 C 和 D 的安全目标。适当的失效率和诊断覆盖率的目标值宜在安全要素层面进行定义，以符合：

a) 硬件架构度量中的目标值

b) 随机硬件失效导致违背安全目标的评估

7.5.4 本要求适用于等级为 ASIL(B) 、 C 和 D 的安全目标。对于分布式开发，推导出的目标值应通报给每个相关团队。

注： GB/T 34590.5-2022 第 8 章和第 9 章中描述的架构约束，不一定适用于商业现成产品的元器件和组件。这是因为供应商通常不能预测终端相关项中如何使用他们的产品以及潜在的安全影响。在这种情况下，供应商会提供基本的数据，例如失效率、失效模式、每种失效模式的失效率分布、内置的诊断等，以便允许在整体硬件架构层面上预估架构约束。

7.6 技术安全要求分配

7.6.1 功能安全与信息安全的技术安全要求应分配给以系统、硬件或软件作为实施技术的系统架构设计要素。

注：如果将技术安全要求分配给作为实施技术的系统中，则再次进一步开发这些要求，直到能将他们分配给硬件和软件为止。

7.6.2 分配和分区决策应符合系统架构设计。

注：为了实现独立性和避免失效传播，系统结构设计可以采用功能分区和组件分区。

7.6.3 每个系统架构设计要素都应继承其实现的技术安全要求的最高的 ASIL 等级。

7.6.4 如果系统架构设计要素由指定为不同 ASIL 等级的子要素组成，或由安全相关和非安全相关的子要素组成，那么每一个要素都应按照最高 ASIL 等级进行处理，除非满足共存标准

7.6.5 如果技术安全要求分配到具备可编程功能的定制化硬件要素 [ 如专用集成芯片（ ASIC ）、可编程门阵列（ FPGA ）或是其他形式的数字化硬件 ] ，宜结合软件和硬件的要求来定义和实施适当的开发流程

7.7 软硬件接口（ HSI ）规范

7.7.1 软硬件接口规范应定义硬件和软件的交互，并保持与技术安全概念一致。软硬件接口规范应包括组件中由软件控制的硬件元器件以及支持软件运行的硬件资源。

注：软硬件接口 (HSI) 中详细描述的方面和特性见附录 A 。

7.7.2 软硬件接口规范应包含下列特性：

a) 硬件设备的相关运行模式和相关配置参数；

示例 1 ：硬件设备的运行模式，例如：默认模式、初始化模式、测试模式或者高级模式。

示例 2 ：配置参数，例如：增益控制、带通频率或时钟分频。

b) 确保要素间独立性或支持软件分区的硬件特征；

c) 硬件资源的公用和专用；

示例 3 ：内存映射、寄存器分配、计时器、中断、 I/O 端口。

d) 硬件设备的访问机制；

示例 4 ：串、并、从、主 / 从

e) 由技术安全概念得出的时间约束。

7.7.3 硬件的相关诊断能力和软件对其的使用应在软硬件接口规范中定义；

a) 应定义硬件的诊断特性；

示例：过流、短路或过温的探测。

b) 应定义需要在软件中实现的对硬件的诊断特性。

7.7.4 应在系统架构设计过程中对软硬件接口（ HSI ）进行定义。

注：在硬件开发和软件开发过程中对软硬件接口（ HSI ）进行细化。

7.8 外部交互规范

7.8.1 应定义与驾驶员的交互的要求 ;

a) 系统必须明确定义与驾驶员的交互方式，包括提醒的类型、时机和内容。

b) 规划和明确驾驶员干预的条件，例如干预方式（如刹车、转向）、所需力矩或踏板开度，以及持续时间。

c) 设计交互界面和警告系统，以减少已知的可合理预见的误用，通过直观的用户界面设计和明确的反馈机制来实现。

7.8.2 应定义与远程 / 后台操作人员交互的要求（若适用）：

a) 制定安全的远程操作协议和权限管理方案，确保只有授权人员可以远程访问和控制车辆系统。

b) 实施强身份验证和加密通信，防止未经授权的访问和数据篡改。

7.8.3 应定义与乘员、行人、骑自行车的人及其他交通参与者交互的要求：

a) 分析系统如何识别、预测和与道路上的各种用户交互，确保其安全和可预测性。

b) 设计系统以最大程度减少对道路使用者的潜在风险，通过先进的感知技术和实时决策能力实现。

7.8.4 应定义相关环境条件交互的要求：

a) 考虑并记录系统在不同环境条件下的行为和响应，例如在不同天气、光照和路面状况下的性能。

b) 确保系统在各种环境条件下的可靠性和稳定性，尤其是在极端条件下的操作能力。

7.8.5 应定义道路基础设施和道路设备交互的要求：

a) 描述系统如何与周围的道路基础设施和设备（如交通信号、路牌）进行通信和数据交换。

b) 确保系统能够安全地集成和利用道路设施提供的信息，以支持智能决策和行为。

7.8.6 应定义云端、车辆间或其他通信基础设施交互的要求：

a) 规划系统与云端服务、车辆间通信或其他通信基础设施之间的安全数据交换。

b) 实施加密和数据完整性验证机制，确保在诊断和参数更新过程中数据的安全传输和准确性。

7.8.7 应定义软件更新的远程刷写（如 OTA ）的要求：

a) 设计安全的远程软件更新流程，包括验证更新的来源和内容，以及安全的升级和回滚策略。

7.9 生产、运行、服务和报废

7.9.1 应定义在系统架构设计过程中识别出的对生产、运行、服务和报废的要求。这些包括：

a) 在生产、服务或报废期间达到、保持或修复相关项及其要素的安全相关功能和特性所需措施；

b) 安全相关的特殊特性；

c) 确保正确识别系统或要素的要求；

d) 生产的验证措施；

e) 包含诊断数据及服务记录的服务要求；

f) 报废措施。

示例：组装或拆卸指南、服务记录、关于系统要素允许维修的指南、报废指南、要素标签。

注：确保生产、运行服务和报废期间的功能安全主要包括两方面。第一方面涉及那些在开发阶段中确保充分系统架构设计和对合适的安全相关的特殊特性的定义而展开活动，第二方面涉及确保在生产和运行阶段实现或维持功能安全的活动（例如：基于特定的与安全相关的特殊特性）。

7.9.2 在考虑了安全分析的结果和所实施的安全机制的情况下，应定义需具备的诊断特性，以提供按照生产、运行、服务和报废安全管理要求对相关项或其要素进行现场监控所需的数据。

7.9.3 为了修复或保持功能安全，应定义诊断特性以便服务时能够识别故障并对维护或修复的有效性进行检查。

7.10 技术安全要求验证

7.10.1 应对技术安全要求进行验证，以提供其在给定系统边界条件下的正确性、完整性和一致性的证据。

7.10.2 应使用表 5 所列的验证方法对系统架构设计，软硬件接口规范以及生产、运行、服务和报废的要求规范以及技术安全概念进行验证，以提供证据表明实现以下目标：

a) 它们适合并足以达到按照相关 ASIL 等级所要求的功能安全水平；

b ) 系统架构设计与技术安全概念的一致性；

c ) 先前开发步骤中系统架构设计的有效性和符合性。

表 5 验证

方法			ASIL 等级
方法			A	B	C	D
1a	检查 a		+	++	++	++
1b	走查 a		++	+	o	o
2a	仿真 b		+	+	++	++
2b	系统原型和车辆测试 b		+	+	++	++
3	系统架构设计分析	演绎分析	o	+	++	++
3	系统架构设计分析	归纳分析	++	++	++	++
a 方法 1a 和 1b 用于检查要求是否得到完整和正确的实施。 b 2a 和 2b 可以作为故障注入测试的有利方法，以支持系统架构设计关于故障方面的完整性和正确性的论证。

8 潜在功能不足和潜在触发条件的评估与识别

8.1 潜在功能不足与触发条件的分析

8.1.1 概述

对潜在的功能不足和触发条件进行系统性分析。该分析可考虑从相似项目或专家中获得的现场经验和知识。可从以下两方面同时进行该分析：

—— 基于已知的潜在规范定义不足和性能局限，确定导致已识别的危害行为的场景（包含触发条件）；

—— 基于已识别出的环境条件和合理预见误用，确定潜在的规范定义不足和性能局限。

注 1 ：关于 SOTIF 分析技术的更多细节见 ISO 21448 附录 B ，或参考 ISO 34502 。

注 2 ：归纳、演绎或探索性的方法用于支持分析。

注 3 ：可能进行定性或 / 和定量分析。

注 4 ：定量目标可能向下定义至要素层面，其源自整车层面的接受准则或确认目标。

注 5 ：对所有相关用例参数的适当抽象（例如，生成和使用等价类或优先度子集），有助于处理大量用例组合。

注 6 ：交通统计数据可能用于那些可导致潜在危害行为的合理用例。

注 7 ：可能通过仿真来支持分析，例如，使用蒙特 - 卡罗方法。

可使用表 6 列举的方法，进行适当的方法组合，来识别和评估潜在规范定义不足、性能局限、输出不足和触发条件。

表 6 潜在功能不足和触发条件的分析方法

方法
A	需求分析
B	ODD 、用例和场景分析 a
C	事故统计分析 b
D	边界值分析
E	等价类分析
F	功能相关性分析
G	共同触发条件分析 c
H	来自现场经验和经验教训的潜在触发条件分析 d
I	系统架构分析（包括冗余）
J	传感器设计与潜在技术局限分析 e
K	算法及其输出或决策分析
L	系统老化分析 f
M	车辆运行周期内可能的环境变化分析（例如，干扰）
N	内部和外部接口分析 g
O	执行器设计的潜在局限分析
P	事故场景分析 h
Q	可合理预见误用分析 i
a 包括 ODD 边界分析。 b 例如 STATS19 、 GIDAS 、 GES 、 CARE 、 IGLAD 。 c 单一触发条件可以触发多个性能局限或规范定义不足（例如大雨能够影响如雷达、摄像头等不同传感器的性能）。 d 考虑市场上相似系统、先前系统和项目以及客户索赔分析。 e 考虑技术上的局限（例如由于相机成像器、雷达天线设计局限或缺少如密封和振动等环境隔离而导致的较低分辨率）和由于安装位置所导致的技术局限（例如由于传感器未能覆盖车辆周边全部 360° 视野所导致的盲区）。 f 例如在规定范围内由于老化效应而变得暗淡的相机镜头。 g 例如车辆与车辆之间、车辆与基础设施之间、 OTA 地图。 h 例如基于自动驾驶数据存储系统 / 事件数据记录器（ DSSAD/EDR ）中记录进行分析。 i 表 6 列出了分析方法。

注 8 ：安全分析方法可能调整用于识别和评估潜在功能不足和触发条件及其对危害的影响 [ 例如，因果树分析、事件树分析（ FTA ）、归纳性的 SOTIF 分析或危害与可操作性分析（ HAZOP ） ] 。 ISO 21448 附录 B.3 提供了调整使用安全分析方法的示例。

基于系统架构，要素的潜在功能不足可分类为：

—— 单点功能不足

—— 多点功能不足

该分类有助于确定充分的功能修改，以实现 SOTIF 。其可用于导出要素层面所需的要求，以实现整车层面的 SOTIF 。

示例：如果整车层面实现了 SOTIF 特定的接受准则，则可将性能目标分配给不同的相关要素，如图 8.1 所示。与单个传感器系统相比，每个传感器可以分配到较少的约束性性能目标（例如，误触发探测率）。

图 8.1 具有两个不同传感器融合的系统架构示例

在定义确认策略过程中，也可以使用这种分类，其中，根据独立性的考虑，可以降低多点功能不足的确认目标（见 ISO 21448 附录 C.6.3 ）。

对于给定的性能局限或规范定义不足，可能存在多个触发条件导致危害行为，此外，已知的环境条件和可合理预见的误用可触发多个整车层面或要素层面的性能局限或规范定义不足。需建立并维护危害行为、触发条件与整车层面或要素层面潜在性能局限或规范定义不足之间的追溯性。

图 8.2 给出了危害、触发条件与整车层面或要素层面潜在的性能局限或规范定义不足之间关联的说明和示例。

a 功能不足（作为设计属性）可存在于所有视角和抽象层级。

图 8.2 潜在功能不足与触发条件之间关联的说明

为了方便展示， 8.1.2 、 8.1.3 节分别对规划算法、传感器和执行器进行说明。如果有益，传感器和执行器中的潜在功能不足和触发条件也可用于规划算法分析，反之亦然。

8.1.2 与规划算法相关的潜在功能不足和触发条件

分析可考虑以下类别：

—— 环境与位置；

—— 道路基础设施；

—— 城市或乡村基础设施；

—— 高速基础设施；

—— 驾驶员或用户行为（包括可合理预见的误用）；

—— 其他驾驶员或道路使用者的潜在行为；

—— 驾驶场景（例如，施工现场、事故、紧急通道上交通堵塞、车辆行驶方向错误）；

—— 已知的规划算法局限（例如，无法应对可能的场景或不确定的行为）；

—— 已知的机器学习的规范定义不足；

—— 已知的机器学习的测量数据不足；

—— 已知的功能不足和功能改进。

8.1.3 与传感器和执行器相关的潜在功能不足和触发条件

分析可考虑以下类别：

——ODD ；

—— 天气条件；

—— 机械干扰（例如，因传感器在车上的位置导致的震动而引起的传感器噪声输出）；

—— 传感器上的污垢；

—— 电磁干扰（ EMI ）；

—— 来自其他车辆或其他来源的干扰（例如，雷达或激光雷达）；

—— 声音干扰；

—— 眩光；

—— 低质量的反射；

—— 精度；

—— 范围；

—— 响应时间；

—— 由于耐久性、磨损、老化导致的性能影响；

—— 权限能力（适用于执行器，例如，液压制动系统预期的最大可用制动压力）；

—— 多传感器数据融合；

—— 传感器的校准和安装。

示例 1 ：雨和雪可影响雷达性能。

示例 2 ：车辆前方升起的太阳可影响视频摄像头的性能。

示例 3 ：行人身上厚重的羊毛外套可影响超声波传感器的性能。

示例 4 ：不正确的校准可影响许多个传感器类型。

注 1 ：已知的潜在功能不足和触发条件的某种组合可能导致某个潜在的危害行为。

注 2 ：详细分析类别见 ISO 21448 附录 B 。对于每个分类，详细的干扰列表基于知识和经验（包括来自相似项目和现场经验的知识积累）来制定。

注 3 ：如果由基础设施要素所提供的传感器输入与自动驾驶（ AD ）或 ADAS 功能相关，则本条也适用于这种情况，以分析功能不足。

注 4 ：附录 B 给出了驾驶自动化系统常见的性能局限示例。

此外，在可能的数值范围内（包括潜在的和观察到的场景），对每个环境的输入进行系统性分析。

8.1.4 可合理预见的直接或间接误用分析

预期功能的可合理预见的直接和间接误用可导致不合理的风险水平。

一方面，作为潜在触发条件分析的一部分，本章覆盖了针对直接误用的分析。另一方面，可能导致针对间接误用的措施无效的潜在功能不足也在本章范围内。

可合理预见的直接或间接误用的原因可以是：

—— 用户缺乏对系统的理解，例如，驾驶员被市场中某个具有不同操作规程的相似系统误导；

—— 用户对系统的错误理解，例如，呈现给驾驶员的不充分、不恰当或不正确的信息；

—— 注意力不足；

—— 对系统的过度信赖；

—— 系统设计中对用户交互的错误假设。

可使用表 7 中描述的方法来支持对可合理遇见的误用的分析。

此外， ISO 21448 附录 B.1 描述了一种导出 SOTIF 误用场景的方法。

表 7 识别可合理预见的误用的方法

方法
A	来自现场经验和其他来源的经验教训的已知误用场景分析 a
B	测试项目相关的研究
C	用例和场景分析
D	用户与系统交互的分析 b
E	HMI 分析
F	已知的人员行为模式分析，例如，缺乏使用、误用和对自动化水平过度自信
G	针对执行任务或在任务间切换的人员能力分析 c
H	相关标准、法规和指南的应用 d
a 例如一些用户视频，演示了系统或其他相似系统如何以一种可合理预见的方式被误用。 b 例如驾驶员提醒、系统理解、运行模式的混淆。 c 例如人员重新获得态势感知的能力的分析。 d 例如 ADAS 设计和评估的代码实践、欧洲人机界面原则声明。

注 1 ：详细方法见 ISO 21448 附录 B.1 。

注 2 ：在有需要时，驾驶员无法保证驾驶任务的情况下使用车辆，被认为是一种滥用，不属于本文件的范畴。

示例 1 ：驾驶员受到管制药物的影响。

示例 2 ：在雪地上，以超过车辆动态能力的不合理高速行驶。

为防止或减轻可合理预见误用（间接或直接的），所需的额外措施及其有效性，可在预估系统对潜在触发条件的响应的可接受性时进行评估。可在验证和确认阶段对这些措施的有效性进行论证。

8.2 预估系统对触发条件的响应的可接受性

对包含已识别出的触发条件的场景进行评估，以确定是否实现 SOTIF 。

注 1 ：这些已知场景被验证活动所覆盖，用于提供其可接受性的最终评估。

注 2 ：在评估过程中所考虑的假设可能包括系统及其要素的预期行为，或假设的用户行为。

在以下情况下，无需进一步功能修改， SOTIF 被视为可以实现的：

—— 导致危害事件的系统残余风险低于定义的接受准则；

注 3 ：风险评估中所使用的证据将会在验证与确认活动中生成。

— — 没有可导致特定道路使用者的不合理风险的已知场景。

注 4 ：即使车队遇到包括某个触发条件的场景的概率很低，但如果特定单个车辆遇到此类场景的概率很高，则系统的响应也可能是不可接受的。

示例：一种集成在环形交叉口或桥墩中的特殊结构，系统性地引起 AEB 系统制动，从而导致与跟随车辆发生追尾碰撞的概率达到不合理的水平。

根据上述条件，如果系统对触发条件的响应是不可接受的，将启动进一步的功能修改。

9 改进预期功能安全的措施

9.1 系统修改

9.1.1 系统修改措施的目的是尽可能地保持预期功能。这些措施包括但不限于：

a) 通过下列方式提高传感器性能和 / 或精度。

—— 改进的传感器技术；

示例 1 ：提高传感器测量的精度；

示例 2 ：更新为新的和改进后的传感器，以解决已知的局限。

—— 改进传感器扰动探测机制，以触发适当的报警和降级策略；

—— 多样化传感器类型；

示例 3 ：增加额外的感知装置，以适当的方式调高覆盖率。

—— 改进的传感器标定和安装；

示例 4 ：针对具有潜在的性能局限的临界情况，将传感器安装在合适的位置提高覆盖率。

示例 5 ：封装传感器以避免或减少干扰，从而达到可接受的水平。

示例 6 ：进入传感器覆盖率分析，并优化传感器的选择（类型、技术、数量）及其在车内的相对位置。

—— 传感器遮挡探测及清洗方法。

示例 7 ：使用边缘探测方法探测摄像头上的污垢，并用液体和雨刷器清洗。

b) 通过改进执行器技术，提高执行器的性能和 / 或精度（例如，提高精度，延长或限制输出范围，减少响应时间，可重复性，对能力进行仲裁，利用其他功能来辅助或增加新的执行器来辅助）。

c) 通过算法改进，提高识别和决策算法的性能和 / 或精度。

示例 8 ：改进的传感器识别算法 [ 例如，改进相机图像中探测对象的特征描述，如 HOG （定向梯度直方图） ] 。

示例 9 ：考虑模型中额外的输入信息。

示例 10 ：改进算法以提供更好的鲁棒性、精度（例如，从线性模型切换到非线性模型或使用机器学习）（见 ISO 21448 附录 D.2 ）

示例 11 ：随着计算能力的提升，加快图像处理速度（例如，使用机器学习加速器或运行高效的硬件）。

示例 12 ：超出 ODD 的识别（例如，识别高速公路出口坡道的方法）。

示例 13 ：识别已知的不支持的环境条件（例如，根据地理位置、一天中的时间、季节等，预测遇到太阳眩光的情况）。

注：在执行高级算法时，可考虑提升硬件性能。

d) 突出自车的可见性，以在自车发生危害行为时，提高其他交通参与者的可控性。

示例 14 ：在当地法规允许的情况下，安装反光板、开雾灯、开转向灯、主动发出声响等。

9.2 功能限制

9.2.1 功能限制措施的目的是通过预期功能的降级（或限制）来保持部分功能。这些措施包括但不限于：

a) 特定用例的预期功能限制；

示例 1 ：当车道探测装置不能清晰地探测到车道时，车道保持辅助功能限制了转向辅助扭矩，以避免出现不期望的转向干预。

示例 2 ： ODD 的限制，包括环境的、地理的或时段的限制。

示例 3 ：限制或约束驾驶策略（见 ISO 21448 附录 D.1 ）以确保制定决策的安全性。

示例 4 ：摄像头被午后阳光引起的周围光线的反射导致失明；通过雷达和其他传感器进行有限制的操作（例如降低允许的最大车速，限制车道保持功能施加的最大转向扭矩）。

b) 解除特定用例的预期功能权限。

示例 5 ：所有的感知传感器都被暴风雪导致失明，驾驶员被要求接管控制。

示例 6 ：自动驾驶车辆不能处理收费站收费或无标识的施工区域，驾驶员被要求接管控制。

9.3 权限移交

9.3.1 将权限从系统移交给驾驶员的措施旨在提高较低自动化等级的可控性。这些措施包括但不限于：

a) 修改人机交互（ HMI ）；

示例 1 ： HMI 清晰地向驾驶员传递移交请求，为驾驶员提供必要信息，以支持驾驶员实现适当的态势感知并执行该任务。

b) 修改用户通知和 DDT 后援策略。

示例 2 ：当系统探测到视野受限（例如，因泥浆导致距离传感器感知范围缩小）时，车速会降低，相应的 HMI 要求驾驶员接管任务。如果驾驶员在规定的时间内没有执行接管，系统将把车速降为零。

注 1 ：针对不同的自动驾驶等级，权限移交可能不同。

注 2 ：只有在过渡本身可控且不会给驾驶员带来额外风险的情况下，才能提高可控性。

注 3 ：考虑对 HMI 研究的指南。

示例 3 ： ADAS 设计和评估的实施规范 .

9.4 解决可合理预见的误用

9.4.1 解决可合理预见的误用的措施包括但不限于：

a) 客户教育（信息和培训）；

示例 1 ：产品使用说明书、培训课程、市场营销、销售演示。

b) 改进 HMI ；

示例 2 ：通过提供正确的操作信息来帮助驾驶员。

c) 驾驶员监控和报警系统的实施；

注：探测和警告驾驶员注意力不集中的系统，是自动驾驶车辆系统中防止可合理预见的驾驶员误用的有效方法。有效的驾驶员监控系统的选择和实现，取决于目标的误用情况。

示例 3 ：当方向盘被松开时，警告驾驶员。

示例 4 ：忽略可能导致危害行为的输入 / 指令，并将原因告知驾驶员。

d) 实施防止误用的措施。

示例 5 ：尽管发出警告信息，如果驾驶员监控系统探测到仍持续误用，则可采取措施阻止危害行为；例如，在多次脱手警告后，车道保持辅助功能可在后续的行程中解除或降级，并提供适当的警告信息，直到下一个驾驶循环。

示例 6 ：可合理预见的误激活功能，例如，在车速过高时激活驻车辅助功能，可通过在功能的激活条件中增加速度限制来防止误用。

9.5 支持预期功能安全措施实施的考虑

9.5.1 在实施 SOTIF 措施后，根据自动驾驶等级，监控和评审对于确保 SOTIF 措施的有效性非常重要的，为了支持这一点，在设计系统时可考虑一些方面。这些考虑包括但不限于：

—— 对 SOTIF 相关系统行为的可测性；

—— 对 SOTIF 相关系统行为的诊断能力；

—— 对 SOTIF 相关系统行为的数据监控能力。

9.6 更新 “ 系统规范定义和设计 ” 的输入信息

“ 系统规范定义和设计 ” 的输入信息，是基于按照本章中已识别的和实施的 SOTIF 措施的规范来更新的。

10 功能安全与信息安全和预期功能安全的交互

10.1 功能安全与信息安全概念和预期功能安全功能规范

10.2.1 功能安全与信息安全概念和预期功能安全功能规范的交互

功能安全与信息安全概念规定了故障响应（如紧急运行、过渡到安全状态等）。对于高级驾驶辅助系统（ ADAS ）和自动驾驶系统而言，这种故障响应也可能是一个预期功能安全（ SOTIF ）问题。对于这些系统，预期功能安全定义必要的功能，从而以安全的方式执行规定的故障响应。功能与信息安全的任务是在发生故障时确保定义的必要功能可以使用（例如通过故障容错），或者确保故障发生的概率足够小（例如通过故障预防）。

定义安全故障响应其本身既可以被视为预期功能安全任务，也可以被视为功能安全与信息安全任务。

示例：在使用自动驾驶功能的情况下，故障响应应可为如下示例：

—— 在当前车道上安全停车；

—— 开往下一个停车场。

注：通过适当的信息交互和（或）评审，保持第 9 章的功能修改与第 6 章的功能安全与信息安全概念相关分解的要求一致。

10.2 技术安全概念和预期功能安全

10.2.1 应考虑技术安全概念和预期功能安全的交互

a) 由于预期功能安全活动（ SOTIF ）活动，系统设计可能会发生变化（例如，通过引入新的传感器），这可能会影响技术安全概念。

b) 由于功能安全和信息安全活动，系统设计也可能会发生变化（例如，通过引入新的传感器），这可能会影响预期功能安全（ SOTIF ）。

11 自治功能和支持

11.1 通用自治管道

11.1.1 与自治有关的危险已经被识别和减轻。

a) 识别所有与自治相关的危险。如果没有，请说明。

b) ODD 的自主相关含义（见 11.2 节）

c) 传感（见第 11.3 节）

d) 感知（见第 11.4 节）

e) 机器学习和 “ 人工智能 ” 技术（见第 11.5 节）

f) 规划（见第 11.6 节）

g) 预测（见第 11.7 节）

h) 项目轨迹和系统控制（见第 11.8 节）

i) 驱动（见第 11.9 节）

j) 计时（见第 11.10 节）

11.1.2 将描述自治体系结构和操作理论以及自治功能的安全性策略。

a) 自主运行的总体理论和安全策略，包括安全运行的原则

b) 体系结构描述

1) 函数

2) 元素

3) 冗余策略

4) 自主管道（或其他自治方法）阶段

5) 与其他 ITEM 功能和组件的接口

c) 操作设计领域的描述（ ODD ）

1) 定义的方法

2) 预期 ODD

3) ODD 细分，如果有的话

4) 检测 ODD 违规

d) 感测说明

1) 传感元件

2) 传感器校准

3) 通过传感器进行的预处理

4) 与其他组件的接口

5) 传感器融合方法

e) 感知描述

1) 传感器数据到对象的转换

2) 对象分类

3) 识别为 ODD 内部或外部的总体状态

f) 规划说明

1) 路线规划

2) 轨迹创建

g) 控制和驱动的说明

1) 轨迹执行

2) 运动控制

3) 计划反馈

11.2 运行设计领域( ODD )

11.2.1 运行设计领域（ ODD ）应以可接受的完整方式进行定义。

a) 一个可接受的完整的 ODD 定义，可追溯到安全案例的 ODD 依赖方面。

b) 认为这个项目在 ODD 内是安全的

c) 认为，当 ODD 已经退出时，该项目是安全的

示例：故障缓解策略可能有意退出 ODD ，或者环境的更改可能强制意外退出 ODD

11.2.2 odd 应涵盖自主项目将运行的相关环境方面。

a) 记录了 ODD 和相关子集的定义，包括安全方面的覆盖范围

注意：通常，这将采用 ODD 分类法的形式。

b) 旅游基础设施

例如：路面类型、道路几何形状、桥梁限制条件

c) 对象覆盖 ( 即 , 定义为在 ODD 范围内的对象 )

d) 事件覆盖范围

示例：与基础设施和其他对象的交互

e) 行为规则

例如：交通法规，车辆道路冲突解决优先级，当地习俗，正当的安全违反规则

注意：对行为规则的伦理处理可能需要隐式或显式地进行编码，而这种编码可能会导致可能违反交通规则的行为。

f) 环境影响

例子：天气，照明

g) 项目的运行情况

例如：自我车辆设备的临时或永久退化

h) 运行时间

例如：任务长度，预期的系统运行寿命

11.2.3 应以可接受的安全方式处理违反 ODD 的行为。

a) 识别策略，以检测项目何时在 ODD 的范围内

b) 在退出 ODD 时确定了缓解风险的策略

11.2.4 应检测并跟踪 ODD 变更。

a) 识别检测与 ODD 相关的安全相关变化的策略，包括：

1) 新的车辆、元素、特征、行为、物体和其他奇怪的方面

2) 对 ODD 特性的修改

例如：安全相关行为频率的变化，对象类型分布的安全相关变化

b) 为每种类型的变化示例识别数据监测来源：道路监测、测绘服务提供商、政府机构

c) ODD 模型受配置管理和版本控制的约束

11.3 传感

11.3.1 传感器应提供可接受的正确、完整和当前的数据。

a) 识别与安全相关的传感器和传感器数据及其在提供数据中的作用

b) 对整个 ODD 、相关的 ODD 子集、场景或整个操作空间的子集进行辩论

11.3.2 校准、数据过滤、数据处理和数据识别技术应在定义的 ODD 范围内产生可接受的传感器性能。

a) 传感器数据处理方法的描述，包括：

1) 校准

2) 数据过滤

3) 数据处理

4) 异常数据的识别和处理

b) 假阳性与假阴性权衡策略的描述和评估

11.3.3 必要时应使用传感器融合和冗余管理技术，以为定义的 ODD 提供可接受的传感器性能。

a) 用于传感器冗余管理和数据融合的方法说明

注意：冗余方法可能是不需要冗余。

b) 可接受的净传感器性能

示例：参数考虑了一个传感器融合算法的输出是否提供可接受的检测和分类能力。

c) 安全相关假阴性的处理

11.3.4 对传感器多样性和 / 或冗余的任何必要性应予以证明。

11.3.5 应减轻传感器性能下降带来的风险。

a) 基于传感器类型、传感器位置和预期生命周期操作环境分析每个传感器的传感器退化影响。

注意：有关冗余和 / 或不同传感器之间的相关传感器退化。

注：鼓励对同一类型传感器的相关特性进行汇总分析。

11.3.6 传感器应进行可接受的故障检测和故障管理。

a) 故障检测和故障管理所用方法的描述

b) 可接受的故障检测、诊断和响应

c) 覆盖永久故障

d) 覆盖了支持系统，至少包括：

1) 电力

2) 热管理

3) 时间基础

4) 本地化支持

11.3.7 由于主动传感器主动发射造成的潜在安全关键故障应追踪到至少一个危险。

11.4 感知

11.4. 1 感知应提供可接受的功能性能。

a) 识别感知系统的安全相关功能

b) 认为感知系统的功能是可以接受的

11.4.2 定义的感知本体应提供可接受的 ODD 覆盖范围。

a) 为感知功能定义的对象和事件本体

示例：作为特征工程的结果

b) 证据表明本体涵盖 ODD 的安全相关方面可接受

11.4.3 感知应将传感器输入映射到感知性能良好的本体。

a) 描述评估感知性能的方法和结果

注意：在这种情况下，有效性是能够正确地将传感器输入映射到感知本体上。性能包括效率和速度。

b) 对在机器学习设计和训练过程中未使用的现场数据的性能进行评估

c) 关于 ODD 的现场测试数据的覆盖范围分析

11.5 机器学习和 “ 人工智能 ” 技术

11.5.1 安全案例应证明任何基于机器学习的方法和其他 “ 人工智能 ” 方法提供可接受的能力。

11.5.2 机器学习架构、培训和 V &V 方法应提供可接受的机器学习性能。

11.5.3 机器学习培训和 V &V 应使用可接受的数据。

11.5.4 基于机器学习的功能应对数据变化具有可接受的鲁棒性。

11.5.5 部署后对机器学习行为的改变不应影响安全。

11.5.6 安全案例应涉及在机器学习之外使用的任何其他 “ 人工智能 ” （ “AI ” ）技术的可接受性。

11.6 规划

11.6.1 安全案例应证明规划能力是可接受的。

a) 对规划的策略和算法的描述

注意：在不构建明确计划的情况下使用即时响应仍然是一种规划策略。

b) 认为规划是可以接受的

11.6.2 规划方法应被记录下来。

a) 策略、计算方法和避障算法的设计

例如：静态物体，如道路碎片；不寻常的车辆操作 ( 如 , 缓慢移动的街道清扫车、现场消防车、现场拖车执行提取 ) ；动态配置的对象，如吊桥。

b) 生成安全和可行控制措施的策略、计算和设计

示例：考虑项目稳定性、紧急停止、乘员安全

11.6.3 本项目应具有可接受的规划 V &V

a) 规划 V &V 的方法描述

b) 论点和证据表明可以接受规划的能力

11.6.4 应减轻因计划失败而导致的风险。

a) 具有可追溯性到缓解措施的潜在规划故障列表

11.7 预测

11.7. 1 预测功能应具有可接受的性能。

11.8 项目轨迹和系统控制

11.8.1 轨迹和系统控制应具有可接受的性能。

a) 轨迹计算的描述及后续方法

b) 系统控制方法的描述

c) 系统可控性极限的表征

1) 考虑到 ODD 中的整个环境条件的跨度

例如： ODD 最坏情况下的最大制动能力， ODD 最坏情况下的最大曲率（最小转弯半径）；考虑路面条件、坡度等；所有这些最坏的情况都在同时发生

2) 考虑到整个系统条件的跨度

示例：考虑轮胎磨损、货物定位、乘员重量分布

11.8.2 该参数应描述项目轨迹和控制接口。

a) 车辆设备界面描述

示例：发动机控制器接口，转向器接口，制动器接口

11.8.3 论证应证明，尽管有故障和交互影响，车辆界面仍是可接受的。

a) 设备故障响应说明

示例：轮胎爆裂、 ECU 故障、转向指示灯故障

b) 对车辆行为故障或其他非计划项动作的响应说明

示例：被其他车辆推动或影响的车辆

c) 对有缺陷、异常或不寻常的自主命令的响应的描述

例如：超出范围的命令值，自主命令违反了最初为人类使用而设计的控制的假定旋转率，自主命令将导致车辆翻转或旋转

11.8.4 显式和隐式项目操作员通知应安全处理。

11.9 执行

11.9.1 应检测并减轻执行器故障。

a) 定义了每个执行器的能力描述和故障模型

b) 根据相关故障模型覆盖执行器故障的分析

c) 分析表明，高级控制方法与驱动故障模型和故障率兼容。

例如：在制动失败的情况下，人类驾驶员可以使用替代方法来控制车速 ( 例如 , 降档，激活停车制动，转向到一个上坡的道路，转向进入沙子或砾石失控的车辆坡道 ) 。这种可控性可以考虑到基线车辆的制动故障率可接受性。然而，一个自主的算法只能在被设计好时才能参与这些操作。

11.10 计时

11.10.1 自治功能的定时性能应可接受。

a) 从环境变化到项目反应的重要自主元素和总端到端延迟的时间分析，包括：

1) 计算整个计算链的延迟，从感知对象 / 事件一直到采取响应性行动

2) 违反系统的 ODD 参数响应

3) 将功能或设备状态降级到相应的缓解响应

12 系统可靠性和安全模块

12.1 概述

12.1.1 论据应证明该项目在可接受的情况下可以支持安全案例

a) 降级的操作（请参阅第 12.2 节）

b) 冗余（请参阅第 12.3 节）

c) 项目故障与缓解（请参阅第 12.4 节）

d) 项目稳健性（请参阅第 12.5 节）

e) 事件响应（请参阅第 12.6 节）

f) 项目计时（请参阅第 12.7 节）

12.2 降级的操作

12.2.1 降级的任务能力应为物品级安全提供可接受的支持

a) 已定义的灾难性故障（导致项目无法满足任何其他已定义操作模式的最低设备清单（ MEL ）的故障集）处理方法。

b) 通过进入降级的操作模式来确定与危险相关的风险，以及增加的风险。

示例：对故障执行车道内停车可能会增加被另一辆车撞到的风险。

c) 降级的操作模式概念描述。至少包括：

1) 降级操作模式的描述（如果有），包括任务参数

2) 在故障缓解中的作用

3) 在安全论证中的角色

d) 每个降级操作模式对最小设备清单（ MEL ）描述的可追溯性。

e) 认为当每个操作模式都满足 MEL 时，项目是可接受的安全项目。

f) 认为当每个 MEL 的下限都超过阈值时，该项目是可以接受的安全的，包括最低定义的 MEL 。

g) 在输入时说明与降级操作模式相关的操作和其他限制：

1) 与项目交互的人

2) 任何维护和 / 或监控功能

h) 识别与降级操作模式相关的危险。

i) 由于无法接受在适当时候为全面运行提供冗余，因此分流任务时间有限。

示例：拉到最近的安全路边位置，开车到最近的出口匝道。

j) 如果未达到 MEL 要求，则紧急终止任务。

示例：车道内停车

12.2.2 降级的任务能力应提供可接受的冗余度和多样性。

a) 包含所有可能的模式转换的允许和禁止的模式转换的列表。

b) 当组件和其他部分项目出现故障时可接受的冗余。

c) 在组件和其他部分项目故障时提供可接受的操作的多样性。

d) 考虑影响重新配置或模式更改过程的故障

示例：在重新配置之前或重新配置期间模式更改功能失败

e) 激活降级模式的警报、警告

示例：车辆内；其他道路使用者；车队运营商；监管机构；执法部门

f) 如果在项目冗余参数中使用了降级的任务能力，则考虑由主要未降级和降级的项目功能共享的任何组件或功能的共享故障

12.2.3 与运行模式变化有关的危害和风险应予以识别的缓解。

a) 识别项目运行模式

b) 至少要确定项目运行模式

1) 标称运行模式

2) 应急安全机动

示例：将故障车辆移出列车轨道

3) 停放

4) 运输

示例：车辆交付，被牵引，乘坐轮渡旅行

5) 加油 / 充电

6) 保养

7) 开机 / 自检

8) 不安全，无法开始新的任务

9) 故障导致项目在运行时不满足任何 MEL 模式

10) 降级模式

11) 灾难性故障模式

12) 关机

13) 事件发生后

14) 安全状态模式

15) 生命周期状态

示例：制造下线测试

16) 丢失外部数据源

示例：地图状态变化的警报的丢失，如新建的建筑区域

17) 外部导航信息的丢失

18) 任何其他模式

c) 每个识别模式的操作概念，至少包括：

1) 项目的行为和限制

2) 对模式转换机制的故障或故障的响应

d) 进入和退出每个降级模式的条件，包括：

1) 降级模式 MEL

2) 每种模式的操作约束条件

3) 触发导致转换进入和退出模式的事件

4) 在转换模式之前确定是否满足相应 MEL 的策略

5) 禁止进入之前因降级而退出的模式，直到明确确认降解的原因已经解决

e) 在模式转换期间的安全，包括在转换过程中发生的故障

1) 在模式转换过程中，模式切换机制激活时出现故障时的安全

2) 在模式更改期间发生其他故障时的安全

3) 为安全地进入和退出每种模式而更改项目状态和 / 或项目状态的要求

f) 各模式在项目级故障缓解中的作用，以及在安全论证中的作用

g) 定义可以输入的每个模式的初始化状态

h) 标识项目操作模式，至少包括（如果支持）：

1) 能力降低，任务受限

2) 能力降低，紧急操作

3) 以最大努力处理灾难性故障

示例：在车道上停车；停车的同时保持最后已知的良好轨迹

4) 长期存储

5) 从断电中恢复

6) 其他手动操作

i) 创建一个显示项目操作模式与每一个此类模式关联的 ODD 子集（如果使用）之间的对应关系的映射。

j) 响应故障或故障而启动的项目模式更改会阻止进入可能受启动故障或故障影响的相同或其他模式，直到做出明确的补救确认。

12.3 冗余

12.3.1 本项目应具有可接受的冗余性、隔离性和完整性。

a) 项目任务模型的定义

b) 项目物理架构的定义

c) 项目逻辑架构的定义及其与物理架构的映射

d) 确定有关 odd 的冗余、隔离和完整性的方法

e) 如果适用于任务模型：

1) 用于计算可靠性的任务长度配置

2) 诊断方法：

i) 任务前

ii) 任务期间

iii) 任务后诊断

iv) 维修期间

3) 降级任务配置

示例：重大部件故障后的转移任务

f) 如果使用冗余，为安全相关功能及其在物理架构上的映射标识故障遏制区域（ FCRS ）

g) 识别与安全相关的冗余

12.3.2 项目应具有可接受的冗余和故障模式多样性。

a) 冗余和故障模式的多样性是可以接受的。这包括考虑潜在的因素：

1) 硬件故障

2) 软件故障

3) 传感器故障

4) 执行器故障

5) 其他项目元素中的故障

示例：电机、机械故障保险装置、接线、电源

b) 可接受冗余以实现所需的可靠性，包括所有操作模式

c) 考虑硬件基础设施以及冗余和故障模式多样性的环境方面，至少包括：

1) 电源

2) 散热问题

3) 设计和制造问题

4) 共享传感器

5) 共享执行器

6) 共享计算组件，包括多核处理芯片

7) 共享线束

8) 共享网络连接

9) 共享区域位置

10) EMI 和 EMC

11) 常见原因和其他相关故障

示例：振动、温度循环、腐蚀性环境、项目老化效应

d) 考虑到冗余和故障模式多样性的软件基础设施方面，至少包括：

1) 编译器和其他工具链元素

2) 库和其他第三方软件组件

3) 软件更新机制、引导加载程序和其他部署基础设施

4) 时间安排和协调

5) 冗余管理机制和协议

e) 从每个元素和功能的冗余到完整性级别要求的可追溯性

f) 使用相关故障分析

g) 使用故障树分析

12.3.3 冗余元素和功能应具有可接受的隔离性。

a) 确定安全相关故障遏制区域（ FCRS ）

b) 每个 FCR 中的所有元素和功能都按照该 FCR 中的任何元素或功能的最高完整性要求设计

c) 对进出每个安全相关 FCR 的数据流的完整性分析

d) 共模和共因故障分析和冗余避免

e) 分区故障分析与冗余避免

f) 在承载多个 FCRS 的任何单个硬件组件内进行隔离的充分性

示例：多核处理器芯片必须在内核之间具有可接受的隔离，并且每个内核的支持资源必须支持多个 FCRS 。

g) 使用任意故障模型

h) 高完整性监视器和检查器可抵抗由较低完整性元素和功能提供的异常和畸形数据。

i) 根据安全计划考虑的 FCR 之间的恶意攻击 ( 即网络安全问题 )

j) 对隔离和故障传播的跨学科检查，包括电子硬件、电源、机械项目和结构方面。

k) 使用多个独立级别的安全（ MILS ）架构方法。

12.3.4 安全案例应记录冗余的设计意图。

a) 设计意图文档指定了每个冗余故障遏制区域的目的

示例：故障检测、完整性隔离、可用性（热备用、温备用、冷备用）

b) 将公认的实践用于冗余模式，而不是专门创建的架构模式

12.3.5 应为每个自主运行模式定义最低设备清单（ MEL ）。

a) 传感器功能

示例：操作所需的激光雷达、雷达和摄像机的最小数量和位置

b) 当前需要的维护

示例：检查、清洁、消耗品库存、基于工作时间的维护

c) 执行机构能力要求

示例：推进器、制动器、转向器等。

d) 计算能力

示例：处理能力、存储可用性等。

e) 车辆状态

示例：具有有效载荷的车辆重量、轮胎状况、电池状况、照明、通信系统状态和其他因素

f) 软件更新新鲜度、有效配置和完整性检查

g) 软件功能

h) MEL 包括冗余要求，包括所需的任何操作热备用和冷备用单元

i) 校准有效性

示例：自上次校准、自校准以来可接受的工作时间或其他使用指标

j) 低于 MEL 时，项目必须完全脱离

k) 每个降级模式的 MEL

l) 分析支持足够频率检查 MEL 的能力

12.4 故障检测与缓解

12.4.1 本项目应具有可接受的检测和减轻可能导致元素和项目已识别风险的故障的能力。

a) 自我诊断覆盖率的量化和确认

b) 通过维护纠正永久故障后的重新整合策略

c) 在不同任务之间的自我诊断覆盖范围

d) 在任务期间的自我诊断覆盖范围

e) 能够识别哪些安全相关的 FCRS 正在工作，是否激活了失效状态以及是否发生故障

f) 避免随时间累积故障，特别是潜在故障和潜在重合故障的累积

g) 记录检测到的故障和失效，包括瞬态事件。

h) 延期维护的记录和管理

示例：扩展操作发生在 MEL 以上的降级模式下，但由于操作需求、预算限制或备件稀缺，其功能少于所有元素

i) 项目功能和数据日志记录项之间的时间和数据存储隔离。

j) 以下情况的重新整合策略：

1) 瞬态故障

2) 间歇性故障

3) 在执行任务期间发生的故障

4) 在任务之间发生的故障

5) 非操作性故障，包括短期和长期存储

6) 在维护期间发生的故障

12.4.2 故障检测能力应具有可接受的有效性和及时性。

a) 识别与安全相关的故障检测能力，每个能力至少包括：

1) 涵盖的元素或功能

2) 涵盖相关故障模型的具体部分，并说明理由

3) 故障检测延迟，并带有正当理由

b) MEL 故障检测能力（包括覆盖范围）的可追溯性

c) 包括以可接受的频率执行的内置自检（ BIST ）功能

d) BIST 覆盖范围充足的理由。

e) 检测：

1) 电源故障

2) 热故障

示例：高温导致的时钟节流导致错过实时期限；超过设计温度范围限制导致的间歇性故障

3) 未经授权的安全相关设备修改，包括未经授权的软件和配置数据

f) 针对本项目使用以下故障检测方法：

1) 任务之间的内置自检（ BIST ）功能

2) 在任务期间执行的内置自检（ BIST ）功能

3) 任务之间的内置诊断（ BID ）功能

4) 在任务期间执行的内置诊断（ BID ）功能

5) BID 覆盖范围的合理性

6) 使用运行时监控

7) 使用冗余元素交叉检查

8) 使用诊断服务工具来筛选潜在的故障

9) BIST 和监控功能，可接受地与被测试的元素隔离，以避免相关故障

10) 自测的 BIST 和监视器功能，以确保它们正常运行

11) 数据完整性和完整性检查

12) 定时故障检查和顺序故障检查

g) 使用具有可接受的频率和覆盖率的状态测试

12.4.3 故障诊断能力应具有可接受的有效性。

a) 确认系统的故障诊断策略

b) 确认与安全相关的故障诊断能力，至少包括以下能力：

1) 涵盖的元素或功能

2) 识别相关故障模型

3) 涵盖相关故障模型的特定部分，并说明理由

4) 故障诊断性能

示例：假阳性，假阴性

5) 故障诊断粒度

示例：子系统、现场可更换单元（ FRU ）、 FCR 、其他部件

c) 故障诊断能力（包括覆盖率）对已定义的 MEL 的可追溯性

d) 故障诊断能力（包括覆盖率）对已定义的 FCRS 的可追溯性

e) 验证已识别的故障诊断能力

f) 识别故障诊断的及时性要求（如有）

g) 压力测试，以描述意外故障诊断触发和误报警率。

12.4.4 故障缓解能力应具有可接受的有效性和及时性。

a) 识别与安全相关的故障缓解能力，至少包括以下能力：

1) 涵盖的元素或功能

2) 采取故障缓解措施的覆盖范围 ( 即缓解故障模型的哪一部分）

3) 故障缓解延迟，并有正当理由

b) 故障缓解到网络故障模型覆盖的可追溯性

c) 故障缓解能力（包括覆盖率）对 MEL 的可追溯性

d) 故障屏蔽

e) 故障转移功能

示例：热备用、温备用、冷备用

f) 故障保护系统和其他安全功能

g) 关于故障保险和其他安全功能的功能安全分析

h) 确认瞬态故障不是永久性故障并重新启动

i) 部件诊断为无故障后重新集成

12.5 项目稳健性

12.5.1 项目应具有可接受的鲁棒性。

a) 鲁棒性设计元素的定义，相关的鲁棒性阈值，和预期的鲁棒的项目响应

b) 检测和管理自车中与安全相关的已激活故障和失效的能力

示例：机械故障，非命令行为

c) 在可行范围内检测意外运行数据

示例：分布变化，意外

d) 检测是否违反了安全案例中的假设

e) 应对和减轻鲁棒性相关故障的能力

f) 检测错误的置信值（如果使用）

例如：错误的分类置信度

g) 错误预测值的检测（如果使用）

示例：错误的运动预测

h) 检测和报告先前风险为 “ 未知 ” 的不良事件

i) 检测和报告先前 “ 接受 ” 风险的不良事件

j) 支持证据记录和积累违反假设的情况，即使没有要求在安全案例中改变。

k) 检测和报告变更的负面后果

示例：修复、再培训，更新

l) 检测感知鲁棒性缺陷

m) 补偿自我车辆和其他车辆、行人和其他物体的错误和不当行为的能力

示例：传感器故障、基础设施故障、意外对象、意外事件、违反行为规则

n) 具有处理乘客和货物的错误行为的能力

示例：乘客不系安全带，乘客在移动时爬出窗户，货物不安全，货物泄漏

o) 检测跨子系统的歧义数据、不一致的数据、命令、操作模式

p) 与改进故障模型有关的故障现场数据

q) 能够以可接受的方式偏离正常的操作规则

示例：绕过导航车道堵塞，安全驶离道路以避免与其他错误行驶的车辆相撞

12.6 事件响应

12.6.1 本项目应能够检测事件并对事件做出可接受的反应。

a) 检测损失事件

b) 在可行范围内检测到事件

c) 报告检测到的事件和损失事件

d) 记录相关数据

e) 追踪事件和损失事件以识别危害，进行安全案例分析

f) 事故检测可追溯性的高覆盖率 ( 即即使没有损失事件，也可以检测到表现为事件的危害缓解失败 )

12.6.2 论据应证明项目可以检测损失事件。

a) 能够检测项目何时可能造成死亡或重大人身伤害的能力，即使任何物理冲击力都不会被认为是实质性的

1) 包括行人、乘员和其他道路使用者

2) 包括非接触事件

示例：一个突然的自我车辆机动与相邻的汽车转向道路，以避免与不安全的自我车辆碰撞，导致相邻汽车的汽车碰撞。 “ 责任 ” 可能不清楚，但当一个理性的人类司机意识到这样的事故发生时 , 可能会停在现场。可以想象，可能会有一些情况（但肯定不是所有的情况），人类司机不会意识到发生了碰撞事故。

b) 检测项目何时涉及死亡

c) 检测项目何时涉及重大的人身伤害

d) 检测项目何时涉及非重大财产损失

e) 检测到该项目何时涉及到重大环境破坏

f) 检测项目何时与障碍物、其他车辆或其他物体的撞击，从而有可能导致车辆的损害或所撞击物体损坏

g) 检测车辆何时违反了安全案例中的假设，即使该违反不会导致损失事件

h) 使用冗余感知和感知项目之间的不一致来检测可能超出了设计的事件检测能力的事件

i) 当其他可用信息显示项目性能存在问题时，不会检测到的事件，被视为潜在的实质性不足

j) 将违反假设视为事件先兆

12.6.3 本项目应检测并响应即将发生的损失事件。

a) 定义了最佳努力响应，以减少不可避免但即将检测到的损失事件的预期严重程度。

b) 明确的响应可以有效地降低即将发生的损失事件的严重程度

c) 在定义即将发生的损失事件严重性缓解方法时，应考虑伦理问题。

示例：如果碰撞即将发生，并且无法识别出能够避免自我车辆和某些物体之间碰撞的替代路径，则当前路径采用最大制动力和部署外部行人冲击缓解技术 ( 如行人安全气囊）。

d) 预测危险情况，以减少处于失效状态的机会

12.6.4 本项目应对事件做出可接受的反应。

a) 定义事件的分类法

b) 定义事件响应策略并论证可接受性

c) 验证事件响应策略

d) 如果使用了事故处理操作模式：

1) 定义突发事件处理的操作模式，并跟踪事件分类

2) 为每个事件处理模式定义进入和退出条件

3) 定义每个事件处理模式的行为和其他方面

4) 在确定的事件场景中验证每种事件处理模式的可接受性

e) 向应急响应人员报告事件数据（调度；现场）

f) 触发应急人员合作功能

g) 将事件数据报告给其他现场人员

h) 确保已定义的行为考虑到现场人员的安全，包括应急响应人员

i) 将事故数据报告给中心工程部门，以进行现场工程反馈

j) 触发车辆安全功能

k) 触发车辆出口功能

l) 触发车辆内外部显示功能

12.6.5 应减轻与事故后状态相关的项目的危害和风险。

a) 识别事故后的操作模式和相应的安全相关行为。这包括：

1) 碰撞后，无论车辆在造成碰撞中的作用和碰撞严重程度

示例：重大碰撞，挡泥板弯曲

2) 在检测到非碰撞事件后

b) 事故发生后的操作模式可以有效缓解风险

c) 响应重大损失事件，适当固定车辆

1) 固定车辆运动

2) 固定辅助设备

3) 切断电器电源

4) 考虑车辆周围的情况

5) 考虑应急响应人员

6) 考虑乘员

7) 考虑潜在的非乘员受害者

示例：碰撞后车辆固定，即使可以使用降级模式的 MEL ，为应急人员和潜在受害者提供更高的安全性。

d) 将损失事件通知应急响应人员

e) 识别事件后的支持功能

1) 绕过控制和操作功能，方便乘员出入和救援

2) 说明项目的操作模式和固定程度

3) 能够根据需要转换到维护模式

示例：由合格的人员将传动系统切换到 “ 空挡 ” ，以方便拖车

4) 支持积极确认是否适合在恢复服务前进行操作的机制

f) 事故后的操作模式和功能的风险缓解认为是可接受的

g) 在与其他道路用户或其他可以合理地预期会引发或导致损失事件的物体进行交互后的车辆事故处理能力

示例：自我车辆激进的切入另一辆车辆，其他车辆随后立即碰撞。自我车辆停在现场，尽可能提供 / 召唤协助。

h) 永久车辆固定机制

12.6.6 应识别事故后的危险。

a) 事故后状况造成的危害，包括风险缓解机制的损坏或故障，至少包括：

1) 意外的车辆运动

示例：高扭矩电动马达克服车轮堵塞导致意外的车辆运动；机器人出租车调度到下一个乘客位置，覆盖了事故后的禁用模式。

2) 应急设备的意外激活

示例：碰撞序列结束后的安全气囊展开

3) 车辆零部件的意外运动

示例：开门，启动混合动力汽车内燃机

4) 激光安全

示例：光束停止扫描激光，这被认为是眼睛安全的，部分原因是扫描

5) 雷达安全

示例：在事件响应场景中，人头附近的非眼睛安全雷达激活

6) 其他主动发射器安全

7) 高压断电功能的损坏

示例：碰撞损坏高压切断接触器，在应急响应器提取尝试时使高压电源通电而没有故障提示

c) 由于乘客、旁观者和紧急反应人员对项目操作的错误理解和项目状态下的歧义而造成的危险，包括：

1) 车辆 “ 安全 ” 模式激活

示例：车辆静止被误认为是故障车辆，而实际上车辆处于等待下一次乘坐请求事件以开始移动。

2) 车辆识别不正确，无法进行远程控制和诊断

示例：由于在碰撞现场识别相关车辆时的混乱或远程操作员错误而远程禁用了错误的车辆

3) 车辆乘客没有意识到他们应该在事故后撤离

示例：睡觉的乘员、不会熟练使用语言者、儿童、严重受酒精影响的成年人不会从不安全的车辆上撤离。

4) 车辆乘员不知道安全功能

示例：机械紧急出口释放装置位于一个无标记的扬声器格栅后面，需要了解拆卸特定扬声器格栅的步骤，才能为不熟悉或不能激活该功能的乘客激活紧急出口功能。

d) 由于车辆功能和部件的激活或通电而造成的危险

示例：机械部件的运动影响车辆在悬崖上的平衡，部件的旋转对乘员或应急响应人员造成挤压危险

12.6.7 应识别事故发生后的风险缓解行为。

a) 识别与在每种事件后操作模式下缓解每个确定的事故后风险相关的项目行为、要求和项目设计的其他方面。

b) 至少包括以下范围：

1) 事故期间的乘员保护功能

2) 事故发生后的乘员保护功能

3) 乘员出口功能

4) 参与者对执行安全案例所承担的任何行动的教育和指导

5) 任何必要的乘员掌握的物品状态知识

6) 应急响应人员访问车辆和乘员

7) 应急响应人员关于安全处理事件所需的说明和程序的教育

8) 应急响应人员对项目状态的了解

c) 为与安全相关的事故后行为和要求定义故障模型

d) 突发事件场景至少包括以下内容：

1) 被困在车辆内的乘员无法从未损坏的车辆上离开

示例：儿童，受伤的人，丧失行为能力的人，动物

2) 进出稳定的受损车辆

3) 进出不稳定损坏的车辆

示例：电池起火，发动机起火，车辆因洪水而瘫痪，车辆浸没，车辆部分越过悬崖边缘，车辆在树顶上

e) 故障模型包括由于灾难性的碰撞损坏而造成的区域隔离、冗余传感器等的潜在危害。

f) 提供安全处理事件的教育材料和程序

1) 自动化系统的处理

2) 确保牵引时的安全状态

3) 事故后电动汽车问题

示例：电池重新点火

12.6.8 项目应报告项目状态、操作参数、故障、事件和损失事件数据，并具有可接受的法证效力。

a) 定义突发事件和损失事件数据记录和报告的方法

b) 定义数据保留的方法

c) 定义的事件和损失事件数据的记录和报告足以进行重建和根本原因分析

1) 自车项目状态

示例：运行模式、设备状态、运行参数、硬件配置、软件配置

2) 自治管道状态

示例：对象列表、置信度测量、预测值、规划信息、轨迹信息

3) 时间信息

示例：传感器样本和目标轨迹的时间戳

d) 有足够的数据可用于重建事件或损失事件周围的事件，以便执行根本原因分析。

e) 与故障检测、故障诊断和事件报告相关的报告数据的数据字典和数据格式定义

f) 确保报告数据的准确性、准确度和完整性的措施

g) 诊断与安全相关的机器学习和其他非传统算法功能中的故障信息

h) 定义和报告与项目级危害具有相同完整性级别的最小事件后数据

示例：确定致命损失事件的根本原因所需的数据应与生命关键项功能具有相同的关键性。

i) 定期记录重要的项目元素的状态和运行状况，包括传感器、执行器和计算元件

j) 带时间戳的数据

k) 记录传感器反馈

l) 来自事件调查中关于报告数据歧义、不足和其他问题的反馈被可靠地归因于根本原因，然后被跟踪以解决问题。

m) 确保篡改明显的强加密安全数据完整性检查

示例：提供可靠的证据完整性链追溯到崩溃事件

n) 确保数据不可否认

o) 确保故障归因数据以最高的项目关键性级别记录

示例：记录的传感器数据不能通过不可接受的低关键性元素，或有足够的完整性保护来提供完整性的证据

p) 根据安全计划解决隐私问题

q) 记录不确定性的项目状态，以帮助行为重建

示例：如果用于非确定性算法，则定期记录伪随机种子值和本地时间戳值

r) 考虑影响报告内容和及时性要求的法律、法律和应急响应者注意事项。

12.6.9 应定义并执行事件后的分析活动。

a) 定义从事件（包括损失事件）中收集数据的方法

b) 定义分析数据和启动安全案例更新的方法

c) 数据收集方法的有效性

d) 数据分析的有效性和安全案例更新方法

e) 保留对项目队列寿命的分析结果

f) 有效执行应对事件的方法

g) 根据识别的危害更新危害日志

h) 自动化支持常规事件处理和分类

i) 识别并符合任何法律和 / 或法规的报告要求。

12.7 项目计时

12.7.1 应满足项目的实时要求。

a) 项目时序分析，解决时间常数，截止日期，和任何内置的时序工程裕量的问题

b) 定义的实时调度方法

c) 项目中的每个函数都满足其定义的实时要求（如果有）

d) 时序分析至少包括：

1) 对项目提出时间要求的环境时间常数

示例：最大车速，在碰撞前实施轨迹校正的时间

2) 车辆的时间常数

示例：制动的时间、执行转向命令的时间

3) 已缓存和已缓冲的数据效果

示例：在线数据分发系统中过时的缓存数据损害映射数据新鲜度

e) 对控制稳定性的时序要求

f) 使用以下至少一项：

1) 安全相关函数的速率单调分析（包括截止日期单调分析）

2) 针对安全相关功能的时间触发设计技术

12.7.2 应检测并减轻违反实时要求的情况。

a) 定义的项目级实时故障的检测和缓解方法

示例：资源超载，错过截止期限，由于计算延迟导致的控制循环关闭丢失，超时

b) 实时故障检测和缓解方法的有效性

c) 针对安全相关功能的定时故障检测和缓解

示例：检测错过的截止日期、挂起的任务

d) 故障模型，包括缓慢的计算过程，挂起的计算过程

e) 正确使用看门器计时器和其他计时监视器

f) 正确使用资源监视器

示例：空闲内存耗尽，堆栈溢出检测， CPU 过载

g) 包含资源不足的故障模型

h) 故障模型，包括通信拥塞和其他实时延迟故障

i) 软件压力测试，以验证时间裕度

j) 静态可分配资源的技术

示例：静态分配而不是动态分配，在项目启动后禁用动态分配

附录 A 软硬件接口（ HSI ）内容示例

A.1 总则

本附录提供软硬件接口的进一步说明。

软硬件接口规范在子阶段 “ 技术安全概念 ” 中启动。随着开发在硬件和软件开发的继续，软硬件接口规范得到细化。

图 A.1 概述了软硬件接口（ HSI ）的作用及其在系统、硬件和软件层面的产品开发之间的关系。软硬件接口（ HSI ）用于约定硬件和软件开发之间的技术依赖性。

图 A.1 软硬件接口（ HSI ）交互概述

A.2 软硬件接口（ HSI ）要素

为了定义软硬件接口（ HSI ），可以考虑下述软硬件接口（ HSI ）要素。

a) 存储器：

1) 易失性存储器（例如： RAM ）；

2) 非易失性存储器（例如： NvRAM ）。

b) 总线接口 [ 例如：控制器局域网（ CAN ）、局域互联网（ LIN ）、内部高速串行链路（ HSSL ） ] 。

c) 转换器：

1) 模 / 数转换器；

2) 数 / 模转换器；

3) 脉冲宽度调制（ PWM ）

d) 多路转换器。

e) 电气输入 / 输出。

f) 看门狗；

1) 内部；

2) 外部。

A.3 软硬件接口特性

为了定义软硬件接口（ HSI ），可以考虑下述软硬件接口（ HSI ）要素。

a) 中断。

b) 时序一致性。

c) 数据完整性。

d) 初始化：

1) 存储器及寄存器；

2) 引导管理。

e) 信息传输：

1) 发送信息；

2) 接收信息。

f) 网络模式：

1) 睡眠；

2) 唤醒。

g) 存储器管理：

1) 读；

2) 写；

3) 诊断；

4) 地址空间；

5) 数据类型。

h) 实时计数器：

1) 启动计数器；

2) 停止计数器；

3) 冻结计数器；

4) 加载计数器。

表 B.1 提供的示例有助于把软硬件接口 (HSI) 特性分配给软硬件接口（ HSI ）要素。

表 B.1 内部信号的输入示例

描述

硬件标识符

软件标识符

通道 1

通道 2

多路转换器通道 1

多路转换器通道 2

数据类型硬件接口

地址通道 1

地址通道 2

单位

接口类型

注解

值域

精度（值域的百分比）

输入

输入 1

IN_1

U16

0X8000

模拟 - 内部

模拟输入 1

0~5

0.50%

附录 B 关于 SOTIF 特定方面的指南

B.1 感知系统性能目标量化与常见传感器性能局限举例

态势感知对于实现先进的辅助驾驶或自动驾驶功能至关重要。态势感知主要依赖于感知系统。感知系统通常由一系列传感器构成。充分考虑不同类型传感器的性能局限，定义合理的感知系统性能目标对于保障驾驶自动化系统安全很有必要。

感知系统性能目标量化可考虑以下基本要求：

—— 感知系统具备与系统 ODD 下最大运行速度相匹配的感知范围（包含距离）；

—— 感知系统具备合适的视野范围；

—— 对于 ODD 内可合理预见的物体，尤其是关键人物（例如，行人、车辆、两轮车、摩托车等常见交通参与者），感知系统能进行识别和区分；

—— 当感知系统对物体识别的置信度下降时（例如，受天气等影响或不同类型传感器输入冲突），具备整车层面的 SOTIF 安全策略（例如，请求接管、降速、降级等）；

—— 在开放道路上，感知系统（可包括地图）具备识别交通标识、标线和信号的能力，以遵守交通规则。

驾驶自动化系统常见的传感器类型包括视觉传感器、毫米波雷达、激光雷达、超声波传感器等。其中视觉传感器也可用于对车内驾驶员状态进行监控。其中不同类型传感器的典型性能局限（非详尽）见表 D.7 。

表 D.7 不同类型传感器性能局限举例

传感器类型	功能局限
视觉传感器	容易受到光照条件影响（暗光、眩光等）；图像模糊、失真或曝光过度（例如，由于曝光不当、车辆高速运动等原因）等；位置估计或者深度估计可能不准确；目标检测和分割可能不准确（例如， AI 算法）
毫米波雷达	容易受到多径效应（例如在隧道中）或路面金属（例如，易拉罐、交通标识牌）影响；角度分辨率低；对某些波形，可能无法区分在相同距离上的多个物体的速度；垂直向无分辨率或分辨率低；速度只能在径向上直接观察到；容易受到其他毫米波雷达的干扰；对静止物体检测能力弱
激光雷达	容易受到雨、雪、灰尘、雾天或水雾等影响；扫描样式密度不足或者覆盖不足；道路上的轮胎等黑暗物体返回的强度信号低；容易受到其他激光雷达脉冲的干扰
超声波传感器	容易受到气流、空气湿度、温度影响；垂直方向分辨率低；角分辨率低、精度低且非常有限感知范围