4. SOTIF工程流程概览
SOTIF（Safety of the Intended Functionality，预期功能安全）工程并不是在传统功能安全流程之外附加的一张检查表，而是一条贯穿产品全生命周期的安全论证主线。它的核心任务，是识别并控制由性能局限、场景不足和可合理预见误用所导致的危害行为，最终形成“残余风险可接受”的完整论证。因此，SOTIF流程必须从概念阶段就介入，并持续到开发、验证、确认和运行阶段，通过多轮迭代逐步收敛未知风险。
一、核心原理：四类风险与两对关键关系
ISO 21448 将SOTIF相关风险划分为四个区域：已知安全、已知不安全、未知不安全、未知安全。工程活动的目标，是尽可能把“未知不安全”转化为“已知不安全”，再通过安全措施将其转化为“已知安全”，同时防止新的未知风险被引入。
这一过程依赖两对关键关系：第一，功能不足与触发条件之间的关系，例如摄像头在逆光下漏检行人；第二，可合理预见误用与系统响应之间的关系，例如驾驶员过度依赖辅助驾驶而脱手。SOTIF流程必须同时覆盖这两类来源，而不能只关注传感器性能。
二、方法流程：五个阶段的输入、活动与输出
从工程落地角度看，SOTIF流程可以按阶段组织为“输入—活动—输出”的链条。概念阶段输入是功能定义和ODD，输出是危害清单、场景清单和SOTIF目标；开发阶段输入是目标与场景，输出是安全措施、架构方案和可追溯矩阵；验证阶段输入是设计实现，输出是测试报告和覆盖率证据；确认阶段输入是整车与真实场景，输出是残余风险评估和发布建议；运行阶段输入是现场数据，输出是监控结论和迭代需求。
| 阶段 | 关键输入 | 核心活动 | 主要输出 |
|---|---|---|---|
| 概念 | 功能定义、ODD、法规要求 | 危害识别、场景分类、风险评估 | SOTIF目标、场景库、验收准则 |
| 开发 | SOTIF目标、场景库 | 安全措施设计、架构分配、误用分析 | 安全概念、设计规范、追溯矩阵 |
| 验证 | 设计实现、测试规范 | 仿真、台架、实车测试、回归测试 | 测试报告、覆盖率证据、缺陷清单 |
| 确认 | 整车系统、真实场景数据 | 边界场景确认、残余风险论证 | 确认报告、发布建议、残余风险声明 |
| 运行 | 现场数据、用户反馈、事故信息 | 监控、数据分析、触发条件更新 | 监控报告、迭代需求、场景库更新 |
三、案例场景：AEB行人检测的SOTIF迭代
以自动紧急制动（AEB）行人检测为例。概念阶段定义ODD为“白天、干燥路面、城市道路”，并识别出“逆光、雨雾、遮挡、儿童突然横穿”等触发条件。开发阶段设计多传感器融合与置信度阈值策略，并针对低置信度场景加入降级提示。验证阶段在仿真中注入逆光与遮挡场景，检查漏检率与误触发率。确认阶段在真实道路和试验场中复现高风险场景，评估残余风险。运行阶段通过影子模式收集真实误报与漏报数据，若发现新的未知不安全场景，则返回概念阶段更新场景库和SOTIF目标。
四、误区与复盘：常见问题与改进方向
- 误区一：把SOTIF等同于功能安全。功能安全关注随机硬件失效和系统性失效，SOTIF关注功能本身在无故障情况下的性能局限与误用。二者互补，不能互相替代。
- 误区二：验证通过就等于确认通过。验证证明“做对了”，确认证明“做的是对的事”。缺少真实场景确认，残余风险无法被合理论证。
- 误区三：场景库一次建完就不再更新。未知不安全正是通过运行阶段的数据反馈才逐步暴露，场景库必须持续演进。
- 误区四：只关注传感器性能，忽略人机交互与误用。可合理预见误用是SOTIF的重要来源，提示策略、接管机制和用户教育同样属于安全措施。
总体而言，SOTIF工程流程的价值在于把“未知风险”转化为可管理、可验证、可迭代的工程对象。概念阶段定边界，开发阶段建措施，验证阶段查实现，确认阶段评残余，运行阶段收反馈，五个阶段通过迭代闭环共同支撑起完整的安全论证。