4. SOTIF各阶段活动简介

4.1 规范定义和设计

1. 功能规范的定义和对设计的考虑：

• 功能描述：对预期的功能、支持子系统和组件的功能的描述

• 性能目标：为实现预期功能而安装的传感器、控制器、执行器或其他输入及组件的性能目标

• 相关交互：预期功能的依赖关系、交互或接口

• 误用：合理可预见的误用(直接和间接)

• SOTIF改进：系统及其要素的潜在的性能局限、已识别出的触发条件、应对措施

• 报警降级：报警和降级概念

• 数据监控：在预期功能的开发过程中和开发后，支持数据收集和监控的程序

• 运营要求：运行阶段，形成风险缓解能力的机制、设计和要求

1. 系统设计和架构的考虑

1. 系统架构设计应贯彻规范定义的要求，应考虑以下事项：

2. 验证系统架构设计的能力

3. 预期的硬件和软件要素在实现SOTIF方面的技术能力

4. 在系统集成期间进行测试的能力

5. 应确定安全相关要素的内部和外部接口，确保其他要素不会在SOTIF方面对安全相关要素产生不利的影响

6. 应确定系统状态相关描述和跳转关系

4.2 危害识别和评估

4.2.1危害识别

危害识别，是指系统地确定整车层面由功能不足引起的危害。这种系统地识别主要是基于对功能的认识及对可能因功能不足而引起偏差的认识。

SOTIF可以通过应用ISO26262中定义的方法来进行危害识别。从预期功能层面，结合运行场景，分析功能的异常行为可能造成的危害(先不考虑具体的潜在功能不足和触发条件)。

危害识别方法：

1. 对可能的功能偏差导致的危害进行系统性识别

2. 考虑驾驶员或用户与系统的交互(包括合理可预见的误用)，以识别出更多的危害

4.2.2危害评估

风险评估旨在评估给定场景中危害行为的风险；这有助于定义 SOTIF相关风险的接受准则。

可以使用ISO26262-Part3中描述的方法来评估伤害的严重度和危害事件的可控度。可以共享分析方法。

评估准则：

• 若：“可控”(即 C=0)或“无伤害”(即 S=0)，则认为不存在不合理的风险。

否则，危害事件被认为与 SOTIF 相关。

• 如果在功能修改后(第8章)，危害事件被判断为S=0或C=0，则该危害已得到充分解决。

4.2.3定义接受准则

根据预期功能和对应危害的特性，定义合理的残余风险接受准则。

如果给出有效的理由，就可以选择适当的定量接受准则。总体理由可以基于以下单个理由中的一个或多个的组合：

• 风险容忍原则，例如 GAMAB 或 GAME，这两个法语术语的意思是“至少在全球范围内一样好”。遵循这一原则，任何新系统的残余风险（关于安全方面）不应高于那些具有类似功能或危害的现有系统。

• 正向风险平衡原则。这种风险容忍原则应用于考虑了新系统所有危害的整体残余风险，可以进行相关风险权衡。对于某个危害，即使残余风险增加，系统也可发布，前提是通过降低一个或多个其他残余风险来达到平衡补偿。

• ALARP 原则。ALARP 风险管理框架可以提供一个有用的风险降低原则，尤其是在目前不存在“良好实践”的情况下，开发和引入新技术。通过承认零风险状态是不可能的，ALARP 原则旨在通过权衡风险与进一步降低风险所需的努力，将风险降低到“合理可行”的水平。

• MEM（最小内源性死亡率）原则。MEM 原则基于的理念是技术系统的引入不应显著增加社会死亡率。由技术系统导致的死亡概率的定量接受准则源自自然原因导致的最小死亡概率。

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

4.3.1对潜在功能不足和触发条件进行分析的2种典型方法

• 方法1：以潜在功能不足为起点：潜在功能不足->触发条件

• 方法2：以触发条件为起点：触发条件->潜在功能不足

4.3.2常用分析方法及其比较

4.3.3合理可预见误用的分析方法

4.3.4典型的潜在功能不足和触发条件

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

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

1. 不同类型传感器性能局限举例

4.4 进行功能修改以解决SOTIF相关风险

4.4.1前提

系统对已识别出的可导致危害行为的触发条件的响应被评估为是不可接受的(第 7 章)。

4.4.2定义功能修改措施(SOTIF措施)

4.4.2.1SOTIF措施类型

1. 避免措施：目的是消除风险

2. 缓解措施：目的是降低风险(当风险无法完全消除)

4.4.2.2功能修改类型

1. 系统修改：修改系统本身(传感器、决策算法、执行器等)，目的是保持预期功能(同时降低风险)

2. 功能限制：目的是通过功能的降级(或限制)来维持部分功能(同时降低风险)

3. 权限移交：修改将权限从系统移交给驾驶员的方式，目的是提高在较低自动驾驶等级下的可控性

4. 解决可合理预见误用的修改：改进防止用户误用的措施，如客户教育、改进HMI等

4.5 定义验证和确认策略

4.5.1定义确认目标

首先定义确认目标，即根据接受准则，定义合适的量化目标，例如：

基于一个已知且公认的接受准则(通常非常小而严苛)，结合对应危害行为在危害场景下的暴露概率、不可控概率以及严重度来得到一个“危害行为比率”(通常较接受准则低而宽松)，作为等价的确认目标。

4.5.2定义验证和确认活动

制定验证和确认规范(如集成测试用例、分析等)。

1. 方法

1. 典型的验证和确认环境

4.6 已知场景的评估

1. 按照已定义的验证和确认策略，对已知的潜在危害场景实施评估(验证和确认)。

2. 典型系统的分层验证过程：

1. 系统分层评估方法：

2. 感知

1. 规划

1. 执行

1. 集成系统

1. 根据已定义的确认目标，评估残余风险是否满足接受准则。

4.7 未知场景的评估

1. 按照已定义的验证和确认策略，对未知的潜在危害场景实施评估(验证和确认)。

2. 未知场景的评估方法

1. 根据已定义的确认目标，评估残余风险是否满足接受准则。

4.8 对SOTIF实现的评估

1. 对SOTIF是否实现的最终评估，涵盖第5章到第13章的所有SOTIF活动。

2. 主要评估方面：

3. 所有分析是否完整？

4. 是否充分实施了必要的功能修改？

5. 是否完成了充分的验证和确认？

6. 是否充分降低了风险并满足了所有确认目标？

7. SOTIF发布推荐

4.9运行阶段的活动

5. 展望

当前，SOTIF正经历从“理论框架”向“工程实践”的关键跃迁。展望未来，其发展将呈现三大趋势：

一是标准体系加速完善。 ISO 21448标准持续迭代，从“通用指南”逐步细化为行业可执行的技术规范，尤其在感知系统局限、算法鲁棒性、人机交互等核心领域形成明确评价指标。

二是AI驱动安全验证变革。传统路测难以覆盖长尾场景，生成式AI正在重塑SOTIF验证模式——通过自动生成海量边缘场景，实现从“被动发现”到“主动构造”的范式转变。数字孪生与真实路测的融合闭环，将成为行业标配。

三是安全边界持续外延。 随着L3级以上自动驾驶落地，SOTIF的重心从“算法能力”向“系统冗余”延伸。多传感器异构冗余、端到端与规则系统的互补机制、驾驶权平稳交接等，将成为安全设计的核心命题。

未来五年，SOTIF将从“技术挑战”转变为“竞争壁垒”。谁能更高效地覆盖未知场景、更系统地证明安全性，谁就能在自动驾驶规模化落地的赛道上占据先机。

以上为本次技术分享，后续相关专题文章将持续更新，欢迎关注交流。