ChinaAutoRegs｜GB/T 43267-2023英文版翻译《道路车辆预期功能安全》
Road vehicles—Safety of the intended functionality
CONTENTS
Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Overview and organization of SOTIF activities
5 Specification and design
6 Identification and evaluation of hazards
7 Identification and evaluation of potential functional insufficiencies and potential triggering conditions
8 Functional modifications addressing SOTIF-related risks
9 Definition of the verification and validation strategy
10 Evaluation of known scenarios
11 Evaluation of unknown scenarios
12 Evaluation of the achievement of the SOTIF
13 Operation phase activities
Annex A (Informative) General guidance on SOTIF
Annex B (Informative) Guidance on scenario and system analyzes
Annex C (Informative) Guidance on SOTIF verification and validation
Annex D (Informative) Guidance on specific aspects of SOTIF
Annex E (Informative) Examples of acceptance criteria for risks of automated driving system
Bibliography
1范围
本文件提供了用于确保预期功能安全（SOTIF）的通用论证框架和措施指南。预期功能安全指不 存在因预期功能不足引起的危害而导致的不合理风险,功能不足包括：
a）整车层面预期功能规范定义的不足；
b）系统中电气/电子要素实现的规范定义不足或性能局限。
本文件为实现和保持SOTIF所需的适用的设计、验证和确认措施以及在运行阶段的活动提供 指导。
本文件适用于依靠复杂传感器和处理算法进行态势感知且感知的正确性会对安全产生重要影响的 预期功能，特别是紧急干预系统的功能和驾驶自动化等级为L1〜L5级的系统的相关功能。
本文件适用于安装在除轻便摩托车外的量产道路车辆上的包含一个或多个电气/电子（E/E）系统 的预期功能。
可合理预见的误用属于本文件的范围。此外，对于由远程用户操作或辅助车辆运行，或与后台通信 可影响车辆决策的情况，如果可能导致安全危害,也属于本文件的范围。
本文件不适用于：
——GB/T 34590（所有部分）涵盖的故障；
一信息安全威胁；
—因系统技术直接导致的危害（例如，激光雷达光束对眼睛造成的伤害）；
一与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、能量释放等相关的危害和类似的危害，除 非危害是直接由电气/电子（E/E）系统的预期功能引起的；
— 明显违反系统预期用途的故意行为（被视为功能滥用）。
2规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文 件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于 本文件。
GB/T 34590（所有部分）道路车辆功能安全
GB/T 34590.1—2022道路车辆 功能安全 第1部分：术语
3术语和定义
GB/T 34590.1—2022界定的以及下列术语和定义适用于本文件。
3.1
接受准贝U acceptance criterion
表征不存在不合理风险（3.23）水平的准则。
注1：接受准则可能是定性的，也可能是定量的。例如：当某特定行为被认为是危害行为时所对应的物理参数、每小 时的最大事件数、最低合理可行风险水平（ALARP）等。
示例1：从交通统计数据得到合理风险水平是每X km发生一次事故。
示例2：与在应用中已证明驾驶员可控的同等整车层面影响进行比较，可支持接受准则的定义。例如，由非预期的 车道保持辅助功能的干扰而引起的轨迹扰动，可类比为横风，以定义该功能的接受准则。
注2：预期功能安全的接受准则包含两个层面：
a）第一层：判断车辆行为是否属于危害行为而可能导致危害事件的准则，即危害行为接受准则；
b）第二层：判断车辆运行过程中残余风险是否处于合理水平的准则，即残余风险接受准则。
示例3：在使用预期功能安全接受准则进行评估过程中，可首先针对车辆某一行为或事件进行评估，判断是否构成 有风险的危害行为或危害事件;然后针对一定行驶里程或行驶时间内出现的危害行为可能导致的残余危害风险进行评 估，判断是否可以接受。见图1所示。
图1双层接受准则的评估
注3：双层接受准则的指标值可能受多方面因素（如：技术演变、场景变化、交通文明程度提升等）的影响，因而在应 用过程中接受准则及其指标值可能随着影响因素的变化而变化。
注4：在考虑特定功能场景的风险时，双层接受准则的理念可能存在融合，例如：通过基于一定时间内、某一场景下 人类驾驶员操作行为的风险统计,来定义自动驾驶功能的危害行为接受准则。但这并不影响使用双层接受准 则对预期功能安全的评价。
3.2
彳亍为 action
场景快照（3.27）中任何参与者所实施的单一行动或表现。
注1：行为/事件（3.7）的时序和场景快照是场景（3.26）定义的一部分。
示例：自车（3.6）点亮危害报警灯。
注2：在该术语定义中，参与者是人员、另一目标、另一系统或与所考虑功能相互作用的任何要素。
3.3
驾驶策略 driving policy
定义整车层面可接受的控制行为（3.2）的策略和规则。
3.4
动态驾驶任务 dynamic driving task；DDT
车辆在交通流中运行时所需的实时操作功能和决策功能。
注：以下功能是动态驾驶任务的组成部分：
——车辆侧向运动控制（操作）；
一车辆纵向运动控制（操作）；
一监控驾驶环境（操作和决策），及执行对目标与事件（3.7）的响应（操作和决策），见OEDR（3.20）；
运动规划（决策）；
一通过照明、发信号或打手势等增强可见性（决策）。
3.5
动态驾驶任务后援 DDT fallback
当发生失效或探测到功能不足（3.8）后，或探测到潜在危害行为时，为执行动态驾驶任务（3.4）或过 渡到最小风险状态（3.16）而由驾驶员或驾驶自动化系统做出的响应。
示例：驶离ODD（3.21）或传感器被冰雪遮挡会导致危害行为，此时要求驾驶员做出响应。
3.6
自车 ego vehicle
装备了为实现SOTIF（3.25）而进行分析的功能的车辆。
3.7
事件 event
在某一时刻所发生的事情。
注1：行为（3.2）/事件的时序和场景快照（3.27）是场景（3.26）定义的一部分。
注2：虽然每个行为也是一个事件，但不是任何事件都只是一个行为，即行为是事件的子集。
示例1 :树倒在车辆前方50 m的街道上。
示例2：交通灯在给定的时间变绿。
3.8
功能不足 functional insufficiency
规范定义不足（3.12）或性能局限（3.22）。
注1：功能不足包括整车层面或系统中电气/电子要素层面的规范定义不足或性能局限。
注2： SOTIF（3.25）活动包括对功能不足的识别及对其影响的评估。根据定义（见3.12和3.22）,功能不足会导致危 害行为或无法防止、探测及减轻可合理预见的误用（3.17）。在促成危害行为或无法防止、探测及减轻可合理 预见的误用的能力尚未被建立时，可能使用术语“潜在功能不足”。
注3：图2〜图4描述了 SOTIF因果模型，涵盖以下关系：触发条件（3.30）,功能不足，输出不足，危害行为，无法防 止、探测及减轻可合理预见的间接误用，危害（3.11）,危害事件（3.7）和伤害。
注4：对于促成伤害发生的间接误用，通常涉及两类功能不足。一类是导致系统在触发条件下产生危害行为的功能 不足，另一个类是导致无法防止、探测及减轻可合理预见的间接误用的功能不足。见图2〜图4。
示例：一辆配备了 L2级高速公路驾驶辅助功能的车辆，探测驾驶员注意力不集中的驾驶员监控摄像头是该系统的 一部分。为了简化,假设以下描述为真：
一感知要素存在功能不足,若被触发条件1触发,该功能不足会导致危害行为，例如，执行错误的车辆运行轨迹；
一驾驶员监控摄像头存在功能不足，若被触发条件2触发，该功能不足会导致系统无法探测和减轻可合理预见的 间接误用。
为使伤害发生，场景（3.26）需包含：
一驾驶员的间接误用：驾驶员注意力不集中且未及时发现系统的危害行为，以对其进行控制；
一触发条件2,其导致系统无法及时探测和减轻出现的可合理预见的间接误用；
一触发条件1,其导致系统危害行为。
注5：若整车层面的功能不足被触发条件触发，这将会导致危害行为，或导致无法防止、探测及减轻可合理预见的间 接误用。见图4中A。
注6：若要素层面的功能不足被触发条件触发，这将会导致输出不足。输出不足本身或与其他要素的一个或多个输 出不足相结合，将促成整车层面的危害行为或无法防止、探测及减轻可合理预见的间接误用。见图4中B。
a危害是伤害的潜在来源，由整车层面的危害行为导致。
b包含使危害能导致伤害的条件的场景是伤害发生的助推因素，但不是伤害的来源。
。无法充分控制危害事件是伤害发生的助推因素，但不是伤害的来源。
图2危害和伤害发生的关联
图3危害事件未得到控制的原因
a取决于系统架构，要素层面的功能不足被认为是单点功能不足（3.28）或多点功能不足（3.19）。
b输出不足本身或与其他要素的一个或多个输出不足相结合，促成整车层面的危害行为或无法防止、探测及减轻可 合理预见的间接误用。
图4 SOTIF因果模型
3.9
功能修改 functional modification
功能规范的变更。
注：“功能修改”与GB/T 34590.1—2022中定义的术语“修改”不同。本文件中“功能修改”在GB/T 34590（所有部 分）术语中称为“变更”。
3.10
后援用户 fallback ready user
有能力操作车辆，并能在一定时间内（对处于已定义的非驾驶期间的用户是合适的）进行干预以按 要求执行动态驾驶任务后援（3.5）的用户。
3.11
危害 hazard
由整车层面危害行为导致的伤害的潜在来源。
3.12
规范定义不足 insufficiency of specification
可能不完整的规范定义，当被一个或多个触发条件（3.30）触发时，会导致危害行为或导致无法防 止、探测及减轻可合理预见的间接误用（3.17）。
示例1：自适应巡航跟车距离的规范定义不完整，导致自车（3.6）未与前车保持安全距离。
示例2：由于规范定义的偏差，导致系统无法处理不常见的道路标识，即：不常见的道路标识不在规范定义的范围 内，因而系统不能恰当处理该标识。
注1：在系统生命周期的某个给定时间点上，规范定义不足可能是已知的，也可能是未知的。
注2： SOTIF（3.25）活动包括对规范定义不足的识别及对其影响的评估。在促成危害行为或无法防止、探测及减轻 可合理预见的误用的能力尚未被建立时，可能使用术语“潜在规范定义不足”。
注3：从规范定义、其他系统或要素的假设或系统性分析（如第6章包含的分析或引出SOTIF设计及实现所需要求 的其他分析）中衍生出的要求，可包含在正式的数据库中，以助于确保验证。很多组织可能不认为这些要求是 “规范定义”，但对于确保SOTIF是必要的。本文件中使用的术语“规范定义不足”包括此类衍生要求的不足。
3.13
预期行为 intended behavior
预期功能（3.14）的行为。
注1：预期行为是开发者考虑了因所用组件和技术的固有特性导致的能力局限后，认为的标称功能。
注2：开发者定义的预期行为，尽管不代表不合理的风险（3.31）,但可能与驾驶员对系统行为的期望不匹配。
3.14
预期功能 intended functionality
已定义的功能。
注：预期功能是在整车层面定义的。
3.15
驾驶自动化等级 levels of driving automation
基于驾驶自动化系统能够执行动态驾驶任务的程度，根据执行动态驾驶任务（3.4）中的角色分配以 及有无设计运行范围（3.21）限制，对驾驶自动化进行的等级划分，分成L0级至L5级。
注：见表2（参考GB/T 40429—2021中的表A.l）o
表2驾驶自动化等级与划分要素的关系
3.16
最小风险状态 minimal risk condition；MRC
当给定的行程无法完成时，为降低风险（3.23）所进入的车辆状态。
注1：这是动态驾驶任务后援（3.5）的一个预期输出。
注2： GB/T 34590（所有部分）中相似的功能安全术语是安全状态。
3.17
误用 misuse
以制造商或服务提供商不期望的方式使用。
注1：误用包括非故意的人员行为，但不包括故意改变系统或以造成伤害为目的而使用系统。
注2：误用可能源于对系统性能的过度信心。
注3：根据与危害行为的因果关系，有直接误用和间接误用两种误用。
注4：直接误用可能是导致系统发生危害行为的原因，被认为是潜在的触发条件（3.30）。如果其形成了导致危害行 为发生的能力，则将其作为触发条件。直接误用也可能是触发条件的一部分，即在直接误用后，需存在场景的 其他特定条件，才能发生系统的危害行为。
示例1：直接误用：在城市环境中激活用于高速公路的功能，导致车辆未探测到停车标志并做出响应的场景（3.26）。
示例2：直接误用：在产品使用说明书定义的ODD（3.21）范围之外，驾驶员激活了自动化系统。这被视为直接误 用，与系统是否包含了用于防止在定义的ODD范围之外激活功能的自车（3.6）定位组件无关。
注5：间接误用会导致对危害行为的可控性降低，或导致事故的严重度增加，或二者兼有。间接误用不被视为潜在 的触发条件，因为其自身不能导致系统的危害行为。
示例3：间接误用：一个L2级高速公路辅助系统存在已知的感知问题，要求驾驶员持续监控系统对DDT（3.4）的正 确执行，并在必要时做出干预。间接误用是驾驶员睡着，而没有监控。该间接误用与驾驶员监控系统是否探测到此情况 并做出纠正无关。
示例4：间接误用：当自车处于自动驾驶状态并在运动过程中，乘员解开安全带。该间接误用潜在增加了事故的严 重度，但不是触发条件。
注6：参考图2〜图4。
3.18
误用场景 misuse scenario
发生误用（3.17）的场景（3.26）。
3.19
多点功能不足 multiple-point functional insufficiency
在一个或多个触发条件（3.30）触发下，且仅当与其他要素的功能不足结合出现时，才会导致危害行 为或无法防止、探测及减轻合理预见的间接误用（3.17）的要素的功能不足（3.8）。
3.20
目标和事件探测与响应 object and event detection and response ；OEDR
动态驾驶任务（3.4）中的任务，其包含监控驾驶环境并对目标和事件（3.7）执行恰当的反应，以完成 动态驾驶任务和/或动态驾驶任务后援（3.5）。
3.21
设计运行范围 operational design domain；ODD
对于给定的驾驶自动化系统，设计确定的功能运行的特定条件。
注1：条件是空间的、时间的、内在的或环境的。
注2：驾驶自动化系统自身的条件，例如：车速、计算能力及感知能力，也属于ODD的范畴。
3.22
।性能局限 performance insufficiency
技术能力局限，其在一个或多个触发条件（3.30）触发下，促成危害行为或无法防止、探测及减轻合 理预见的间接误用（3.17）。
注1：在系统生命周期的某个给定时间点上，性能局限可能是已知的，也可能是未知的。
注2：性能局限考虑系统中的电气/电子要素，及与实现SOTIF（3.25）（见3.8注1）相关的其他技术要素。
注3： SOTIF活动包括对性能局限进行识别并评估其影响。在促成危害行为或无法防止、探测及减轻可合理预见 的误用的能力尚未建立时，可能使用术语“潜在性能局限”。
示例：技术能力局限包括有限的计算性能、有限的传感器感知范围、有限的执行等。
3.23
风险 risk
伤害发生的概率及其严重度的组合。
3.24
反应 reaction
场景快照（3.27）中任何参与者对行为（3.2）的反馈。
3.25
预期功能安全 safety of the intended functionality；SOTIF
不存在因预期功能（3.14）或其实现的功能不足（3.8）引起的危害（3.11）而导致不合理的风险（3.31）。
注1：可能导致危害的系统危害行为，是由场景（3.26）中的触发条件（3.30）引发的（见图2）。可合理预见的直接误 用（3.17）被认为是潜在的触发条件。
注2：在识别危害事件（3.7）时，对“预期使用和可合理预见的间接误用（3.17）”与“因规范定义不足（3.12）或性能局 限（3.22）导致的危害行为”进行结合考虑。
3.26
场景 scenario
按场景快照（3.27）的先后顺序，对几个场景快照的时间关系进行的描述，包括特定情况下受行为 （3.2）和事件（3.7）影响的目标和取值。
注1：每个场景都开始于一个初始的场景快照，定义行为、事件、目标及取值，以对场景中的时间关系进行特征化。 与场景快照不同，场景持续了一定的时长。
注2：提及的“目标和取值”是预期功能的条件参数。目标是“保持在车道线以内”，取值是“行人安全的优先级高于 避免财产损失”。
3.27
场景快照scene
环境快照，包括背景、动态要素、所有参与者和观察者的自我表征以及这些实体之间的关系。
注1：场景快照可能包含环境要素（状态、时间、天气、照明和其他周边条件）、道路设施或内部要素（道路或内部几何构 造、拓扑结构、质量、交通标识、道路边界等）及对象/参与者（如果适用,静态的、动态的、运动的、交互、动作）。
注2： 一个包含所有实体（如风景、动态要素、参与者）的包罗万象的场景快照（即客观场景或基本事实）只能在模拟 中建模。在现实世界中，场景快照是由传感器感知的。自车（3.6）或人类驾驶员感知到的场景快照是对真实 情况的不完整、不准确、不确定和潜在错误的投影。
注3：场景快照也可能包含自车及实施预期功能（3.14）的系统的情况，如：胎压、用户使用情况及系统部件存在的 失效。
3.28
单点功能不足 single-point functional insufficiency
在一个或多个触发条件（3.30）触发下，直接导致危害行为或无法防止、探测及减轻可合理预见的误 用（3.17）的要素的功能不足（3.8）。
3.29
态势感知 situational awareness
对态势的理解。
3.30
触发条件 triggering condition
场景（3.26）中的特定条件，这些条件引发了系统的后续反应，这些反应促成了危害行为或无法防 止、探测及减轻可合理预见的间接误用（3.17）。
注1： “触发”的概念包含由多个条件逐步发生而导致危害行为或无法预防、探测及减轻可合理预见的误用的可 能性。
注2：场景中的触发条件触发了功能不足（3.8）,导致系统的后续反应。见图2〜图4。
示例：在高速公路上运行时，车辆自动紧急制动（AEB）系统误将道路标志识别为前车，导致了 Xg的制动持续了 Y so在此示例中，触发条件是在高速公路上运行时导致误识别路标的环境条件，而AEB具有相关的性能局限（3.22）（例 如，感知精度低或算法分类错误）。
注3： SOTIF（3.25）活动包括对触发条件进行识别并评估系统的响应。在引发相应反应的能力尚未被建立时，可能 使用术语“潜在的触发条件”。
注4：可合理预见的直接误用可直接引发系统的危害行为，被视为潜在的触发条件。
注5：参考图2〜图4。
3.31
不合理的风险 unreasonable risk
按照现行的安全观念，被判断为在某种环境下不可接受的风险（3.23）。
3.32
用例 use case
一组相关场景（3.26）的描述。
注1：用例包括以下系统相关信息：
个或几个场景；
一功能范围（如最大允许车速、最大允许减速度）；
——预期行为；
系统边界；
——关于环境和人员操作的假设。
注2：典型的用例描述不包括该用例的全部相关场景详单。相反，用这些场景的更概要的描述。
3.33
确认目标 validation target
用于论证满足接受准则（3.1）的值。
注1：确认目标的定义取决于目标市场和运行场景（3.26）。
注2：在SOTIF（3.25）范围内，确认是一种保证，基于检查和测试,确保接受准则（对于已识别的危害）会得到实现且 具有充分的置信度水平。
示例：功能在Yh的耐久运行中无危害行为，或在X次泊车中发生一次某种严重度的危害行为。
注3：为完全满足一个给定的接受准则，满足多个确认目标可能是必要的。
3.34
整车层面安全策略 vehicle level safety strategy；VLSS
针对预期功能（3.14）的一组整车层面要求，用于支持设计、验证和确认活动以实现SOTIF（3.25）。
注：为每个SOTIF相关的系统定义一套整车层面安全策略是可能的。
3.35
优先度子集 priority subset
按照一定的规则对要素的属性进行排序，所挑选出的部分要素的集合。
示例：根据场景（3.26）要素中与预期功能不足（3.8）的相关性（触发条件），及这些要素的发生概率，可以给出预期功 能（3.14）的一组场景（3.26）优先度子集或用例优先度子集。
注1：由于场景和用例的完整描述难以实现，优先度子集有助于支持SOTIF（3.25）分析、验证和确认、评估活动中，应 对大量的场景和用例。
注2：对要素属性的排序规则可能是定性的，如与预期功能是否相关,可能是定量的，如场景要素出现的概率大小。
注3：场景优先度子集是给定规则的场景概要描述，支持对用例和场景的分析和建立，以及对场景覆盖率的论证。
4预期功能安全活动概述和组织
4.1 概述
4.2 〜4.4提供了：
a）预期功能安全原理的概述；
b）关于预期功能安全活动的工作流程和使用本文件的指南；
c）关于预期功能安全活动管理和支持过程管理的指南。
本文件规定的活动适用于整车、系统和组件层面。
4.2预期功能安全的原理
4.2.1 预期功能安全相关的危害事件模型
本文件的主要目的是，对用于确保所有已识别的SOTIF相关危害事件达到足够低的风险水平的活 动和理由进行描述。
功能和系统规范及设计包含了相关用例，而这些用例又由多个场景组成。这些场景可能包含导致 伤害（简化的示意图见图5,详细的示意图见图2〜图4）的触发条件。为了避免伤害，适当的态势感知 是必要的。
，触发条件包括可合理预见的直接误用。
“无法控制危害事件也可能是由于可合理预见的间接误用导致的，例如，驾驶员没有按照规定的方式监控系统。
图5 SOTIF相关危害事件模型的示意图
示例1：当一个仅适用于高速公路的功能在城市环境中被激活时，该功能将难以识别和解释弱势道路使用者的 运动。
示例2：对系统运行模式的错误理解，例如，系统未激活，但驾驶员误认为系统处于激活状态。在这种情况下，用于 防止这种混淆的系统人机交互的潜在不足或系统缺乏恰当的反应（如果驾驶员行为可以被监控），可能也被视为系统的 危害行为。
注1：正确的态势感知依赖于：
一对相关环境条件具有足够全面、准确的感知，对场景快照的正确理解（例如，探测停车标志），以及关于每 个道路参与者的状态的预测模型（例如，行驶方向、速度）。定位、自车运动、与其他车辆或环境的通信等 信息可进一步用于态势感知。
——驾驶时，适当的行为或反应（例如，遵守与停车标志相关的规则）。
在车辆的整个运行生命周期中，可能会产生以下变化：
——环境（例如，新型交通标志、道路标记、车辆）；
一适当的响应（例如，新交通标志要求的新驾驶行为、驾驶场景的变化、驾驶法规的变化）。
注2：第13章描述了对此类变化的监控。
注3：该问题可能通过源于驾驶策略的要求来解决。见D.1中的示例。
在定义ODD和系统开发过程中（例如，风险识别、定义适当的措施），考虑上述这些变化，以确保运 行阶段的预期功能安全。
1.1.2 场景的4个区域
在本文件中，危害场景指的是导致危害行为的场景。作为相关用例的一部分,车辆运行场景可以分 为4个区域（见图6和图7）。
区域2：集合等于已知场景 ‘与不安全场景的交集
区域3：集合等于不安全场 景与已知场景的补集
区域4：集合等于所有场景 中已知场景和不安全场景 并集的补集
区域1：集合等于已知场景 与不安全场景的补集
已知场景的集合
不安全场景的集合
所有可能场景的集合
图6场景的可视化分类
图例：
萼已知安全场景（区域i）
室已知不安全场景（区域2） 匚二I未知不安全场景（区域3） 区因未知安全场景（区域4）
图7场景可视化分类的替代方案
定义区域1、区域2、区域3和区域4.旨在构建和指导对本文件的理解：
– —已知安全场景（区域1）;
– 已知不安全场景（区域2）；
一未知不安全场景（区域3）；
– 未知安全场景（区域4）。
示例：当存在以下任一情况时，未知区域与场景是相关的：
一定义了潜在的触发条件（例如，极端低温、不同驾驶场景的特殊组合），但系统的行为是未知的；
存在未知的触发条件（例如，概率极低的偶发事件）；
——场景的已知参数可组合成未知的潜在触发条件（例如，天气和交通条件的组合）。
注1：区域4中的场景是未知但安全的，不会导致伤害风险。一旦区域4中的场景被发现（即成为已知的），它就会 被移至区域1.
该模型是一个抽象概念，其代表了 SOTIF活动的目标.即：
– 基于对预期功能的分析，评估区域2的风险是否可接受；
– 通过功能修改（见第8章）,将区域2中引起危害行为的已知不安全场景的概率，降低到可接受 的标准；
– 通过充分的验证和确认策略（见第9章和第n章），将区域3中引起潜在危害行为的未知不安 全场景的概率，降低到可接受的标准。
注2：这只是一种概念性描述方法，因为这些区域的大小是不能测量的。
注3：各区域的大小代表场景的数量大小，而不是这些场景导致的风险大小。然而，这只是一种概念性描述方法，因 为这些区域的大小并不是真正能测量的。SOTIF的任务是为预期功能的风险足够低提供论据，场景的数量 是其中的一个方面，但不是唯一的方面。造成伤害的严重度和危害场景出现的可能性会影响预期功能的风 险，但这些并未在区域中体现。
注4：即使在所应用的系统开发方法中，某些SOTIF相关活动未计划使用场景的方法，也不会改变SOTIF的目 标，即，避免不合理风险。
一个给定的用例可以包含已知和未知的场景。探索每个用例的场景可以识别出以前未知的场景。
SOTIF活动的最终目标是评估区域2和区域3中存在的潜在危害行为.并提供论据以证明这些场 景导致的残余风险足够低，即达到或低于接受准则。虽然明确评估了区域2中已知场景产生的风险.也 需要通过基于统计数据的测试,以论证区域3中未知场景产生的风险足够低。
期望降低区域2和区域3的残余风险。通过不断增加区域1（见图8和图9）中的场景集合.将提高 实现SOTIF的信心。
图8预期功能安全活动带来的场景区域演变
图9预期功能安全活动带来的场景区域之间的演变替代表现形式
1.1.3 “感知-规划-执行”模型
本文件中，导致危害行为的可能原因，与系统能力密切相关，这些能力包括创建足够准确的环境模 型，基于环境模型做出正确决策并推导出正确的控制动作，以及执行该控制行为。
关键系统要素及其交互由“感知-规划-执行”模型表示（见图10）。“感知”要素执行感知部分（包括 定位），即依据从车辆外部和内部环境以及车辆和系统状态所感知并接收到的信息，创建环境模型；”规 划”要素将其目标和策略应用于由“感知”要素提供的环境模型，以得出控制行为；最后,“执行”要素执行 控制行为。
注：决策算法被包含在,,感知-规划-执行”模型的所有要素中（例如，分类、传感器数据、融合、态势分析、行为决策人
图10 “感知-规划-执行”模型
基于“感知-规划-执行”模型,对有能力的整体系统架构的选择,是实现高效SOTIF过程的一个重 要考虑因素，在高效的SOTIF过程中.与整体能力相关的活动可在早期阶段启动.并贯穿整个功能开发 生命周期。选择一个有能力的系统架构对于确保SOTIF至关重要。因此，可在系统开发的早期阶段启 动系统架构的定义工作。此外，在系统整个生命周期中，定期评审系统架构，并在必要时进行更新。
4.3 本文件的使用
4.3.1 本文件的流程图和结构
第5章（规范定义和设计）旨在启动SOTIF活动（见图11）。规范定义和设计中包含了那些在后续 SOTIF活动和周期开始前就已知的功能不足。SOTIF活动的迭代可能会导致规范定义和设计的更 新，以及新的先前未发现的功能不足。SOTIF活动的每次迭代开始于规范定义和设计，目的在于将规 范定义和设计更新到最新的状态。
第6章（危害的识别和评估）旨在对预期功能的潜在危害行为进行危害识别和风险评估。对已识别 出的危害事件进行风险评估，并定义相应的风险接受准则。如果证明危害事件不会导致不合理的风 险,则不需应用额外的设计措施。第6章不考虑预期功能的危害行为的原因,而仅考虑其对安全的影 响。因此,重点是评估可能由危害行为引起的危害事件,并定义所需满足的接受准则。
第7章（潜在功能不足和潜在触发条件的识别与评估）旨在识别可能导致预期功能危害行为的根本 原因（见图4）.并评估由所识别出的潜在功能不足和触发条件引起的风险是否合理。
第8章（修改功能以解决预期功能安全相关风险）旨在根据第6章、第7章、第9章〜第13章的活 动，如果认为有必要*则对功能进行修改（例如.改进传感器的能力，对ODD进一步的限制），以改进 SOTIF o
第9章（定义验证和确认策略）旨在制定验证和确认策略，以提供证据来证明：与SOTIF相关的整 车层面残余风险符合可接受的水平,要素满足其功能要求,对ODD的覆盖是充分的。第10章（已知场 景的评估）和第11章（未知场景的评估）旨在基于验证和确认策略导出相应的验证和确认测试用例.且 测试用例对ODD的覆盖度足够高。
第12章（预期功能安全实现的评估）旨在评估SOTIF活动的结果是否充分.足以论证实现了 SO¬TIF o
第13章（运行阶段的活动）旨在定义在运行阶段识别和解决可能出现的SOTIF现场运行问题的 流程。
图11描述了本文件中为确保预期功能安全所需的活动流程。带圆圈的数字表示本文件中的相应
早O
“可控”或“不
附录A提供了关于SOTIF的一般指南。
附录B提供了关于场景和系统分析的指南。
附录C提供了关于SOTIF验证和确认的指南。
附录D提供了关于SOTIF特定方面的指南，例如，驾驶策略的定义,对机器学习的影响以及对地 图和V2X的考虑、感知系统目标量化与常见传感器性能局限以及对OTA更新的考虑。
附录E提供了风险接受准则的示例。
4.3.2 规范的条款
通过在各章节的开始列出目标，提供实现目标的论据，并记录相应的工作成果,可以声明符合本文 件。目标的规范性特征是通过使用关键词“应”来表达的，表示一种要求。
注：A.1给出了基于目标结构表示法（GSN）的论证小例。
4.3.3 表的解释
本文件中的一些表列出了为实现某一开发目标的一系列方法和措施。这些条目旨在说明可能的方 法和措施,而表的条目可能并不详尽。可以采用其他等效的方法和措施。这些表的目的是支持开发团 队选择一个或多个适当的措施和方法。
注：选择一组适当的方法可能取决于各种因素，例如，危害事件的复杂性或暴露概率。
4.4 预期功能安全活动管理和支持过程
4.4.1 质量管理、系统工程和功能安全
为了开发安全的产品，严格的工程和质量管理过程至关重要。这些已经在其他标准中予以说明,如 IATF 16949,GB/T 34590 （所有部分）和ISO/IEC/IEEE 15288。本文件仅关注这些过程中的SOTIF 特定方面。
注1：在产品开发过程中，本文件和GB/T 34590（所有部分）规定的活动是并行开展的。一般而言，实施的措施可能 对SOTIF和功能安全产生影响，并按照这两种方法论进行评估。A.2为并行应用GB/T 34590（所有部分）和 SOTIF提供了实践指南。
对于管理活动和支持过程,可以将GB/T 34590.2、GB/T 34590.7,GB/T 34590.8扩展到SOTIF活 动中。5.3和10.2进一步描述了要求的传递和追溯性。
对于SOTIF相关的活动，选择以下一组方法和措施。
——SOTIF过程（见图11）始于规范定义和系统及其架构的设计（见第5章）。
– 对预期功能的潜在危害行为进行危害识别和风险评估（见第6章），以识别危害及其相应的危 害事件。如果证明危害事件不会导致不合理的风险，则不需应用额外的设计措施。
注2：第6章不考虑预期功能的危害行为的原因，而仅考虑其对安全的影响。因此，重点是评估可能由危害行 为引起的危害事件，并定义所需满足的接受准则。
– 第7章旨在识别可能导致预期功能危害行为的根本原因（见图2）,并评估由所识别出的潜在 功能不足和触发条件引起的风险是否合理。
– 根据第6章、第7章、第10章、第11章、第12章、第13章的活动，如果认为有必要，则对功能 进行修改（例如，改进传感器的能力，对ODD进一步的限制），以改进SOTIF。见第8章。
– 制定验证和确认策略,以提供证据来证明：与SOTIF相关的整车层面残余风险达到可接受的 水平，要素满足其功能要求（见第9章），对ODD的覆盖是充分的。为了能够收集所需的证 据，可从该策略中导出相应的验证和确认测试用例，且测试用例对ODD的覆盖度足够高（见 第10章和第11章）。
一根据先前活动的结果，评估残余风险（见第12章）。
一在运行阶段定义了识别和解决可能出现的SOTIF现场运行问题的流程（见第13章）。
注3：关于GB/T 34590（所有部分）功能安全和本文件之间的交互，A.2给出了进一步解释。
4.4.2 分布式预期功能安全开发活动
在分布式产品开发的情况下，所有相关方之间定义了开发接口协议（DIA）.DIA的目的是在项目的 早期阶段确认SOTIF活动的所有职责,并在开发方之间交换充分的技术信息。
IATF 16949提供了一个基本流程框架,也可在SOTIF过程中予以考虑。本条侧重于如何将DIA 扩展到分布式SOTIF开发和实施中。GB/T 34590（所有部分）提供了关于功能安全方面的DIA和供 应协议框架。为了将此框架应用于SOTIF,可以进行剪裁，增加与SOTIF开发和实施相关的各方职 责。考虑并商定各方的责任，以计划和执行第5章〜第13章的整个SOTIF活动。对将要共享的信息 和工作成果进行定义。可根据GB/T 34590.8—2022中5.4.1、5.4.2、5.4.3、5.4.4和5.4.6所描述的过 程,并为SOTIF进行剪裁.来完成这些活动。在项目开发初期就文档格式达成一致。
4.4.3 独立于环境的预期功能安全相关要素
为了实现SOTIF,对不同系统（硬件和软件）之间的接口的描述是必要的。为了确保集成的系统在 所定义的ODD内是安全的，每个子系统（例如，独立的感知系统）的边界都要经过仔细的评估。因为环 境因素（例如，（）DD、场景）是SOTIF开发的基本问题，所以系统及其要素依层面的不同具有不同的关 注点。就这些系统和要素的开发而言，它们可以分为以下三种类型。
a）在环境中的开发：整个系统的所有SOTIF活动遵循V模型进行开发。对于从事系统及其要 素的分布式开发的各方，根据任务角色来确定要求，包括规范定义和设计（见第5章）以及其他 活动（见第6章〜第13章）。在GB/T 34590（所有部分）中.这种开发被视为“在环境中”的开发。
b）独立于环境的SOTIF相关要素：对于这些要素，可以对它们在整个系统中的使用及其对预期 功能的贡献做出假设。因此，可以对与S （） TIF相关的输出不足及其容许的发生概率目标做出 假设。记录这些假设并将其作为这些要素后续开发的输入。SOTIF活动提供了实现相应概 率目标的证据。对于独立于环境的SOTIF相关要素，记录已识别出的触发条件及其引起的输 出不足。通过整车层面功能环境下的SOTIF活动，确定假设的有效性（见GB/T 34590.10 2022中第9章的SEooC） 0
c）非特定的SOTIF相关开发：这些要素的功能可通过多种方式帮助实现预期功能.因此,如果使 用这些要素的环境未知，提前预估SOTIF相关要求在实践上是不可行的。
示例：分配给GPU的要求依赖于系统环境和运行在这些GPU上的软件。
5规范定义和设计
5.1 目的
本章的目的是实现以下目标：
a）规范定义和设计应包含充分的信息以开展SOTIF相关活动；
b）在SOTIF相关活动的每次迭代后，应根据要求对规范定义和设计进行更新（见图11）。
5.2 功能规范的定义和对设计的考虑
规范定义和设计可包括本条所列的各个方面。某些方面仅与特定的自动化等级或特定的实现相 关。此外,某些方面与整车层面或要素层面的功能规范定义相关。
考虑的方面（如适用）包括但不限于以下方面。
—对预期的功能、支持子系统和组件的功能的描述,包括：
• 设计运行范围（ODD）；
• 自动驾驶功能控制车辆动态任务的权限级别和细节；
• 整车层面的SOTIF策略；
• 功能可被激活或关闭的用例，以及激活和关闭用例间的转换；
• 决策逻辑的描述（例如，路径规划、驾驶策略，见D.1）。
-实现预期功能的相关系统及其要素的设计。
-为实现预期功能而安装的传感器、控制器、执行器或其他输入及组件（例如，地图，见D.3）的性 能目标。
注1：自动驾驶系统的性能目标（见D.5）,例如，包括在ODD范围内对关键目标和事件（例如，行人、车辆、自 行车、摩托车和交通标志）的探测与响应。
一预期功能与如下条目间的依赖关系、交互或接口 ：
• 驾驶员；
• 驾驶员交互（例如，HMD,及如何使用交互以减轻已知的可合理预见的误用；
• 远程/后台操作人员；
• 乘客、行人、骑自行车的人和其他道路使用者；
• 相关环境条件；
• 道路基础设施和道路设备；
• 云端、车辆间或其他通信基础设施（例如,V2X/X2V.见D.4）以及涉及诊断和参数更新的 在用远程信息处理之间的数据交换；
• 软件更新的远程刷写；
• 车辆上可能干扰预期功能的其他功能,包括信息交换和相应的使用假设。
——可合理预见的误用（直接和间接）。
-系统及其要素的潜在的性能局限、已识别出的触发条件、应对措施。
注2：在SOTIF活动中，识别出的一些潜在的性能局限和风险可能是可以接受的，无应对措施。在此情况 下，在规范定义和设计中予以记录。
——实现预期功能的系统和整车架构。
—报警和降级概念：
•报警策略；
• DDT后援:接管/后援的条件和方案，用于在各自的用例中.将控制权从自动驾驶系统转移 到驾驶员或另一个系统；
• 最小风险状态方案（例如，自动靠边停车、在路径中停车、后援用户）；
• 驾驶员监控系统及其对后援策略的影响。
-在预期功能的开发过程中和开发后，支持数据收集和监控的程序：
• 数据收集的目的和要求；
• 在SOTIF发布前，支持开展所需数据收集的架构、实现和机制；
• 运行阶段,支持数据收集的要求、设计和机制，以用于SOTIF分析（见13.5）,包括可能基 于云、OTA或射频通信的技术。
-运行阶段，支持形成风险缓解能力的机制、设计和要求。
注3： A.4给出了一个简化后的规范定义和设计框架性示例。
5.3系统设计和架构的考虑
规范定义和设计提供了对系统及其要素、功能和性能目标的充分理解,以便执行后续阶段的活动。 这包括一份已知的功能不足、相关的触发条件及其应对措施（如果适用）的详尽列表。在开展SOTIF相 关活动前，一些潜在的功能不足、触发条件、应对策略是已知的并记录下来，而其他的则在开展SOTIF 活动过程中被揭示出来。在系统设计中实施应对措施,以缓解已知功能不足对整个系统的影响。
SOTIF相关活动（见图11）的每次迭代,可引发在任何相关层面上更新规范定义和设计的工程活 动。每次迭代依赖于在任意相关层面上对规范定义和设计的更新，这也体现出此前迭代中发现的所有 信息。
各开发方［整车制造商（OEM）、1级供应商（Tier 1）、N级供应商（Tier N）］之间的合作,对于发现 集成系统、组件或要素的潜在功能不足，并在开发阶段（见4.4）针对这些不足制定应对措施是必要的。 将设计和规范的相关部分传达给较低层面的系统及组件开发人员。在每个开发周期/迭代之后，所使用 的假设、可预见的误用和潜在的性能局限从一个层面传递到相邻的层面，包括OEM。
随着SOTIF活动识别出新的功能不足和触发条件（见第7章）.并定义改进SOTIF的措施（见第8 章），规范定义和设计将作为每个开发周期的一部分进行更新，见图11。
SOTIF工作成果如果影响规范定义和设计，包括预先存在的相关内容*则其与规范定义和设计是 相关联的（如5.2中的定义）。这确保了从之前的迭代中获取到所有信息、，同时确保规范定义为下一个 迭代周期做好了准备。
注：规范定义和设计（工作成果5.5）的可追溯性和完整性可通过与SOTIF措施（工作成果8.5）的关联性予以证 明，这些措施可以进一步关联到以下方面。
一相关设计文档。
——工作成果”来自：
• 第6章：对已识别出的危害事件的评估（例如，需要达到S=0、C = 0或需要满足更宽泛的接受准则）；
• 第7章：系统对潜在触发条件响应的评估（例如，与分析关联，该分析表面触发条件的风险不可接受）；
• 第9章和第10章：已知不安全场景的验证报告（例如，与验证测试报告关联，该报告表明与要求相关的 性能不可接受）；
• 第9章和第11章：未知不安全场景的确认报告（例如，与确认测试报告关联，该报告表明与不安全场景 或确认目标相关的性能不可接受）；
• 第12章：SOTIF发布的论证（例如，与记录拒绝发布请求理由的报告关联）；
• 第13章：现场监控（例如，与记录现场监控期间发现的新的不安全场景的报告关联）。
第6章（6.4）和第7章（7.4）中与风险评估相关的SOTIF技术假设不一定与第8章（8.3）中的 SOTIF措施相关，但仍可将这些技术假设追溯至规范定义和设计。那些可提供基于模型的设计和不同 模型工件（要求、组件、接口、分析、测试用例和结果）之间的自动追溯的设计工具，可以支持这一过程。
5.4性能局限和应对措施的考虑
设计包括对可能因要素输出值引起潜在性能局限的考虑,这些性能局限可能潜在导致整车层面的 危害行为。潜在性能局限的非穷尽示例包括：
— 分类不充分；
测量不足；
— 跟踪不足；
— 目标选择不足；
—运动学估算不足；
—— 假阳性探测（误报，例如，鬼影、幻影物体）；
—假阴性探测（漏报）;
一驾驶策略层面的局限，例如，对遮挡区域的考虑。
B.3提供了关于识别功能不足和相应整车层面危害行为的可能方法的指南。功能不足与系统在已 定义的ODD范围内运行时最为相关。但系统对离开ODD的探测方式.以及在离开ODD时控制权限 转换期间系统如何运行,与支持完整的分析也相关。
系统开发基于对设计中的性能局限的假设。实施措施以应对这些性能局限，从而确保实现预期功 能安全。集成到规范定义和设计中的设计和措施，降低了残余风险，提高了整体鲁棒性（见图6和 图7）。
注1 ：第7章详述了识别潜在功能不足及其触发条件的方法和措施。
注2：第8章描述了解决功能不足的方法和措施，例如，冗余、多样性和互补要素。
注3：规范定义和设计中的SOTIF内容，按照第10章的详细说明进行验证。
以下是性能局限和可能的应对措施的示例，相关内容包含在规范定义和设计文档中：
示例1：用于车道保持等功能的高速公路车道边界探测算法，可能由于道路上的废弃物而错误地确定车道。然 而，导致碰撞的车道偏离可通过其他自动驾驶功能来缓解。例如：使用高清地图和定位来确认车道，基于前面车辆的轨 迹将自车轨迹合理化，保持与其他车辆距离的防碰撞算法，即使这意味着离开已识别出的车道等。
示例2：目标探测算法将滑板上的人视为行人，但由于其速度不可信而拒绝该目标。在这种情况下，通过对目标探 测算法和感知及处理算法之间进行抽象，并使用其他不同的合理性检查的系统，可以缓解与滑板者的碰撞。
示例3：在某些区域，用具有三维视错幻象的人行横道（见图12）来提醒驾驶员。在道路上绘制图像的目的是欺骗 人类的感知，但也可能欺骗视觉系统，使其探测到不存在的物体。在这种情况下，基于光流的分析机制可防止错误制动。 光流分析和基于雷达的环境识别作为相互替代的应对措施*以应对由视觉分类局限而导致的此类情况。
图12可能欺骗视觉系统的视觉幻象图的示例
示例4：使用自动泊车系统时，有物体从打开的后备箱中伸出，可能会导致危害事件。系统设计中的应对措施是只 准许在后备箱关闭时进行自动泊车。
5.5 工作成果
工作成果是实现目标5.1 a）和5.1 b）的规范定义和设计。
注1：规范定义和设计拆分或链接到多个文档，例如，SOTIF相关系统的需求规范、功能规范定义和设计规范。
注2：缓解措施的SOTIF规范可集成到现有功能安全设计文档中*例如*功能安全概念和/或技术安全概念。
6危害的识别和评估
6.1 目的
本章的目的是实现以下目标。
a）应系统地识别整车层面定义的预期功能所导致的危害。
b）应系统地识别和评估由预期功能的危害行为导致的风险，及危害行为可能导致危害的相应场 景。应定义预期功能的行为被视为不安全的情况下的参数。
示例：参数可以是速度偏差或与其他物体的最小距离。
c）应定义残余风险的接受准则。
6.2 概述
为实现本章的目标,可考虑以下信息：
-规范定义和设计，按照5.5；
一用于推导接受准则的可用数据。
6.3 危害识别
系统地确定整车层面由功能不足引起的危害。这种系统的识别主要是基于对功能的认识及可能因 功能不足而引起偏差的认识。这可以通过应用GB/T 34590.3-2022中定义的方法来实现。 GB/T 34590 （所有部分）和本章要求的危害分析的通用要素的说明如图13所示。图14以AEB系统
一 导致
。具有的特性
图13 GB/T 34590（所有部分）和本文件中危害分析的通用要素示意图
注1：与GB/T 34590.3不同，在分析SOTIF相关的危害时，不会为危害事件确定汽车安全完整性等级（ASIL）。然 而，严重度（S）、暴露概率（E）和可控性（C）参数可用于调整确认工作所需的工作量。
注2：发生率反映了功能在运行阶段遇到触发条件的概率。
触发条件的发生率和危害导致伤害所处的场景的暴露概率，两者有重要的区别。一般来说.触发条 件并不独立于场景。因此*为支持在SOTIF风险降低的论证中使用场景暴露概率.评估时需要考虑处 于场景的暴露概率和遇到触发条件的概率之间的统计相关性。
示例2：对于行驶在高速公路上的场景和针对高速领航驾驶功能的触发条件之间，不能假设存在统计学上的独 立性。
在某些特定情况下，可对统计学上的独立性进行假设，如图14所示。
可控性参数C可用于评估SOTIF相关危害是否可控（见10.6和表10）。关于道路参与者反应的 研究或假设可用于支持可控性评级。
—导致
o具有的特性
图14使用图13中术语的AEB示例
注3：图14中的示例说明从两个层面评估所导致的风险：首先是给定场景中与特定危害相关的风险；其次是与全部 危害行为相关的总体风险，这包括对多个危害和相应场景的评估。
除针对可能的功能不足导致的危害进行系统性识别外，还可考虑驾驶员或用户与系统的交互（包括 可合理预见的误用），以识别出更多的危害。根据可合理预见的误用与导致危害的关系，对其进行区分。 对预期功能的直接误用会形成触发条件，而对预期功能的间接误用会降低可控性，或增加因危害行为造 成的危害事件的严重度（例如，驾驶员注意力不集中或驾驶员对功能局限的误解）。
第7章涵盖了对可合理预见的间接误用的识别及其影响的分析。
注4： 7.3.4和B.1提供了分析可合理预见误用的通用指南。
6.4 风险评估
风险评估旨在评估给定场景中危害行为的风险;这有助于定义SOTIF相关风险的接受准则。
注1：由整车层面功能不足导致的危害行为（如果有）是本评估的一部分。
可以使用GB/T 34590.3—2022中第6章描述的方法来评估伤害的严重度和危害事件的可控性。 尽管共享分析方法，但SOTIF分析中观察到的结果和特定危害的评估参数可以是不同的。
注2： GB/T 34590.3—2022给出了可控性、严重度和暴露概率等级。在本章中，仅考虑危害事件在总体上是否可 控，或者是否会导致伤害。暴露概率不是本章风险评估的决定参数。这是因为，对场景中需要评估的风险的 选择已经意味着它们的暴露与SOTIF相关，否则分析中将不作考虑。
注3：为定义确认目标，可能考虑暴露于特定场景的概率（见第9章）。
示例1：对于因自动紧急制动引发的与主车辆的追尾，可通过限制制动干预的幅度来降低严重度。幅度限制可被视 为增加可控性的安全措施，或视为对预期行为的功能修改。在分析危害时，该限制被认为是预期行为的一部分；与此不 同的是，对于该限制在实施过程中的失效，则属于其他安全标准的范畴，例如GB/T 34590（所有部分）。
考虑危害事件的严重度和可控性，以确定危害行为在给定场景下产生的风险是否合理。严重度和 可控性的评估考虑功能规范（根据第5章规范定义和设计）。可控性评估包括相关人员为控制危害而 做出的“无反应”或“延迟反应”，例如这些反应可能是由可合理预见的间接误用导致的。评估也可考虑 外部措施。如果可控性被评为“可控”（即C = 0）或严重度被评为“无伤害”（即S=0）,则认为不存在不 合理的风险。其他情况的危害事件被认为与SOTIF相关。对这些危害行为.使用可测量的参数（如速 度的偏差和与其他物体的最小距离）来进行描述，这些参数是危害行为接受准则（第一层接受准则）的来 源,对于不符合这些接受准则的危害行为，需要进行合理的应对,并在接下来的SOTIF残余风险评估中 予以考虑。
注4：对于危害行为的风险评估和接受准则的定义，考虑目标市场人员和场景的合理水平，包括可能的驾驶习惯、文 化、人员能力、交通情况及其随时间的演变等。
注5：支持危害行为接受准则定义的可测量参数，也可能基于所考虑场景下的交通数据统计结果。例如：基于交通 数据统计分析，给出高速公路上存在风险的跟车距离的定义。
注6：危害行为接受准则可能用于支持整车安全策略及安全要求的制定，附录E提供了一个基于交通数据分析来定 义危害行为接受准则及整车安全策略的示例。
示例2：在危害事件归类中，可考虑高级驾驶员辅助系统（ADAS）无法以安全方式处理某一环境条件，并因此需要 驾驶员恢复控制。
驾驶员延迟的反应或不恰当的反应，包括驾驶员为获得足够的态势感知和恢复控制所需的时间,可 能会影响可控性的评估，是SOTIF相关分析时需要考虑的。
注7： SOTIF分析中考虑人员可能由于未及时、正确地反应，而比功能安全分析时考虑人员及时反应而定义的可控 性更低，或者因为人员对车辆预期行为存在误解而导致在特定场景中的误操作，使严重度升高。例如：驾驶员 由于紧张或缺乏信心，可能对自动驾驶车辆的一些行为偏差矫枉过正。
如果在功能修改后（见图11），危害事件被判断为S=0或（’ = 0,则该危害已得到充分解决。
示例3：表3给出了针对AEB系统SOTIF相关危害事件的潜在后果进行评估的示例。
6.5 残余风险接受准则的定义
针对不满足危害行为接受准则的那些行为，可导致S>0且 O0的危害事件，需要为这些危害行 为定义残余风险接受准则，即第二层接受准则，并从第7章继续开展相关活动,最终实现对残余风险接 受准则是否得到满足的评估。
作为SOTIF流程的一部分.对S = 0或C = 0分级的论证进行评审.包括对分级证据（例如，测试或 分析结果）的评审。
接受准则考虑：
适用的政府和行业法规；
‘项功能是新功能还是市场上已存在的功能；
– 对于可能暴露于风险的人（例如，自动公共交通系统中的车主、操作员、行人或乘客），风险是否 合理；
已存在的功能的接受准则；
—— 以模范方式行事的驾驶员的表现。
示例1：接受准则可以是每小时事故的最大数量，在第9章中的验证和确认策略是基于特定接受准则定义的。
在制定接受准则时，可考虑的方法包括：
—目标市场的可用交通数据（例如，事故统计、交通分析）（见C.2.2.4）；
一现场运行中,类似功能的现有准则。
示例2：已量产的类似碰撞报警系统，每工公里产生的误报事件数量（采用类似的测试分布）。
如果给出有效的理由，就可选择适当的定量接受准则。总体理由可基于以下理由中的一个或多个 的组合。
一风险容忍原则。例如GAMAB或GAME.这两个法语术语的意思是“至少在全球范围内一样 好”。遵循这一原则，任何新系统的残余风险（关于安全方面）不应高于那些具有类似功能或危 害的现有系统。
– 正向风险平衡原则。这种风险容忍原则应用于考虑了新系统所有危害的整体残余风险，可以 进行相关风险权衡。对于某个危害，即使残余风险增加，系统也可发布，前提是通过降低一个 或多个其他残余风险来达到平衡补偿。
– ALARP原则。ALARP风险管理框架可以提供一个有用的风险降低原则,尤其是在目前不存 在“良好实践”的情况下，开发和引入新技术。通过承认零风险状态是不可能的，ALARP原则 旨在通过权衡风险与进一步降低风险所需的努力，将风险降低到“合理可行”的水平。
—MEM（最小内源性死亡率）原则。MEM原则基于的理念是技术系统的引入不应显著增加社 会死亡率。由技术系统导致的死亡概率的定量接受准则源自自然原因导致的最小死亡概率。 注1：本文件中的理由仅包括与SOTIF相关的风险，不包括来自其他安全领域（例如，电气安全）的风险。
注2 ： C. 2和C. 6给出了定义和评估接受准则和确认目标的示例。
注 3：关于 GAMA&ALARP 和 MEM 的描述，见 EN 50126-2：2017, A.KRAMS）™ .
注4：有效的理由可能基于整个车队的风险或与单个车辆相关的风险。即使车队进入包含触发条件的某一场景的 概率非常低，但如果给定的单个车辆面临这种场景的概率很高，系统的响应也可能是不可接受的。
注5：附录E提供了一个基于交通数据分析定义风险接受准则的示例。
6.6 工作成果
6.6.1 整车层面的危害，实现目标6.1 a）。
6.6.2 危害行为的风险评估,实现目标6.1 b）。
6.6.3 接受准贝h实现目标6.1 c）。
7潜在功能不足和潜在触发条件的识别与评估
7.1 目的
本章的目的是实现以下目标：
a）应识别出潜在规范定义不足、潜在性能局限和包括可合理预见的直接误用在内的潜在触发条 件，并确定导致危害行为的来源。
b）应对系统的响应进行SOTIF可接受性评估。
注1：包括在可合理预见的直接和间接误用情况下，识别功能不足和相关触发条件。
注2：本活动考虑整车层面预期功能的潜在规范不足以及系统中电气/电子要素的潜在规范不足或潜在性能局限。
注3：根据危害行为接受准则，判断规范不足、性能局限及潜在触发条件是否导致了不可接受的危害行为。对于新 识别出的、不可接受的危害行为.需要对危害行为接受准则进行补充完善.
7.2 概述
为实现本章的目标，可考虑以下信息：
——规范定义与设计，按照5.5；
-一整车层面的危害，按照6.6.1；
-危害行为的风险评估,包括已识别出的可合理预见的间接误用,按照6.6.2；
-接受准则，按照6.6.3；
一基于外部信息或经验教训（例如，13.5）的.可导致危害行为的系统及其要素的已知潜在功能不 足和已知潜在触发条件（包括可合理预见的直接误用）。
7.3潜在功能不足与触发条件的分析
7.3.1 概述
对潜在的功能不足和触发条件进行系统性分析。该分析可考虑从相似项目或专家中获得的现场经 验和知识。可从以下两方面同时进行该分析：
-基于已知的潜在规范定义不足和性能局限，确定导致已识别出的危害行为的场景（包含触发 条件）;
一基于已识别出的环境条件和可合理预见误用，确定潜在的规范定义不足和性能局限。
注1：关于SOTIF分析技术的更多细节见附录B,或参考IS。34502。
注2：归纳、演绎或探索性的方法用于支持分析。
注3：可能进行定性或/和定量分析。
注4：定量目标可能向下定义至要素层面，其源自整车层面的接受准则或确认目标。
注5：对所有相关用例参数的适当抽象（例如，生成和使用等价类或优先度子集），有助于处理大量用例组合。
注6：交通统计数据可能用于那些可导致潜在危害行为的合理用例。
注7：可能通过仿真来支持分析，例如，使用蒙特-卡罗方法。
可使用表4列举的方法.进行适当的方法组合，来识别和评估潜在规范定义不足、性能局限、输出不 足和触发条件。
现成译文，到款即发。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 13306496964/Email: standardtrans@foxmail.com 获取完整译文。
本英文译本为纯人工专业精翻版本，保证语法术语准确率和专业度！
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！迄今为止已翻译上千个国内外汽车标准法规！独家打造千万级汽车专业术语库和记忆库。
任取样页验证译文质量。
提供正规增值税电子发票。
请联系手机/微信: 13306496964/Email: standardtrans@foxmail.com 获取完整译文。
本英文译本为纯人工专业精翻版本，保证语法术语准确率和专业度！
专业源于专注|ChinaAutoRegs 始终专注于汽车标准翻译领域！迄今为止已翻译上千个国内外汽车标准法规！独家打造千万级汽车专业术语库和记忆库。