4. SOTIF场景分类

SOTIF（Safety of the Intended Functionality，预期功能安全）的核心任务，是系统性地识别和降低由性能局限与可合理预见误用所引发的危害。要完成这一任务，第一步就是把车辆可能面对的全部运行场景，按照“是否已知”和“是否安全”两个维度进行划分。ISO 21448 给出的经典分类方法，将场景划分为四类：已知安全场景、已知不安全场景、未知不安全场景、未知安全场景。这四类场景并非静态标签，而是随着分析、测试与运行数据的积累不断迁移的动态集合。理解它们的定义、边界与转化路径，是构建 SOTIF 场景测试闭环的起点。

一、四类场景的定义与判定维度

分类的两个判定维度非常直观：已知性（Known / Unknown）表示该场景是否已被工程团队识别并纳入分析范围；安全性（Safe / Unsafe）表示在该场景下，系统是否可能产生危害行为。两个维度交叉，形成四个象限：

• 已知安全场景（Known Safe）：已被识别，且经分析或测试确认系统行为安全。例如高速公路正常跟车、白天良好天气下的车道保持。这类场景是功能设计的基准，测试重点是回归验证，防止改动引入退化。
• 已知不安全场景（Known Unsafe）：已被识别，但系统在该场景下存在危害风险。例如逆光导致摄像头饱和、雨雾中雷达误检、施工区锥桶识别失败。这类场景是当前开发阶段的主要攻击目标，需要通过功能改进、限制条件或降级策略来消除。
• 未知不安全场景（Unknown Unsafe）：尚未被识别，但一旦发生可能导致危害。这是 SOTIF 最危险、也最需要主动挖掘的区域，例如罕见的长尾边缘场景、传感器在特定材质与角度组合下的失效。
• 未知安全场景（Unknown Safe）：尚未被识别，但实际不会引发危害。它们通常无需专门处理，但一旦被识别，会转化为已知安全场景，丰富场景库。

二、四类场景的转化关系

四类场景之间存在明确的转化路径，这些路径正是 SOTIF 活动的价值所在。下图展示了四类场景及其主要转化关系：

从图中可以看出四条关键转化路径：

1. 未知不安全 → 已知不安全：通过场景探索、仿真、实车测试或运行数据回传，把隐藏的风险场景暴露出来，使其进入已知集合。这是 SOTIF 最核心的“发现”活动。
2. 已知不安全 → 已知安全：针对已识别的风险场景，通过算法改进、传感器融合优化、ODD 限制或降级策略，使系统在该场景下不再产生危害。这是 SOTIF 的“消除”活动。
3. 未知安全 → 已知安全：在探索过程中被识别，但确认无害，归档进场景库即可，用于完善覆盖度证据。
4. 已知安全 → 已知不安全：这是一种“退化”路径。当系统发生变更（如软件升级、传感器更换、ODD 扩展）时，原本安全的场景可能重新变得不安全。因此回归测试和变更影响分析必不可少。

三、方法流程：从分类到闭环

在实际工程中，四类场景的管理不是一次性分类，而是一个持续迭代的闭环流程：

1. 场景采集
   └─ 需求分析、HARA、仿真、路测、影子模式、事故数据库

2. 场景分类
   └─ 按“已知/未知 × 安全/不安全”四象限打标

3. 风险场景处理
   └─ 已知不安全：制定改进措施 → 验证 → 转已知安全
   └─ 未知不安全：设计探索策略 → 暴露 → 转已知不安全

4. 场景库维护
   └─ 版本化管理，记录每次转化与证据

5. 变更影响分析
   └─ 识别可能退化的已知安全场景，重新纳入测试

6. 残余风险评估
   └─ 当未知不安全集合缩小到可接受范围，SOTIF 目标达成

四、案例：AEB 行人横穿场景

以自动紧急制动（AEB）系统为例，说明四类场景如何动态转化：

五、常见误区与复盘

• 误区一：把未知不安全当成“不存在”。未知不等于没有，只是尚未暴露。必须主动设计探索策略，而不是等待事故倒逼。
• 误区二：只关注已知不安全，忽略退化路径。系统变更后，已知安全场景可能退化为已知不安全，回归测试必须覆盖。
• 误区三：场景分类一次完成，不再更新。四类场景是动态集合，每次测试、每次 OTA、每次事故分析都应触发重新分类。
• 误区四：把未知安全当作无需记录。未知安全场景一旦被识别，应归档为覆盖度证据，支撑 SOTIF 论证。