1、SOTIF基础：什么是预期功能安全？SOTIF的起源与ISO 21448标准概述
1.1 从功能安全到预期功能安全——我们到底在防什么？
做自动驾驶的同行，应该都有过这种体验：
明明传感器没坏，算法也没报错，车却突然来个急刹——因为系统把路边的广告牌当成了行人。
这算不算安全问题？
按传统功能安全（ISO 26262）的思路，这不算。因为硬件没故障，软件也没跑飞。但实际体验呢？吓死人。
这就是预期功能安全要解决的问题。
我个人的理解很简单：功能安全防的是“系统坏了”，预期功能安全防的是“系统没坏但干蠢事”。
举个例子你就明白了：
- 功能安全场景：摄像头被泥巴糊住了，系统应该检测到“视觉失效”并降级。这是硬件故障。
- 预期功能安全场景：摄像头干干净净，但逆光时把白色卡车识别成天空，直接撞上去。这是性能局限。
说白了，SOTIF（Safety Of The Intended Functionality）就是针对“系统在正常工作时，因为功能本身的设计不足或性能局限，导致的安全风险”。
核心定义：预期功能安全关注的是——当系统没有故障时，由于功能不足（功能缺陷）或性能局限（传感器能力、算法边界等）引发的危害。
1.2 SOTIF的起源——为什么会有这个标准？
说来话长。我记得2016年左右，行业内出了好几起自动驾驶测试事故。
事故调查结果很有意思：系统没有故障，传感器也正常，但就是“没识别出来”。
传统功能安全标准ISO 26262对此无能为力。因为它只覆盖“系统性故障”和“随机硬件故障”。
那“功能本身就不够安全”谁来管？
于是ISO 21448应运而生。它的正式名称是：“预期功能安全（SOTIF）”。
我参与过几个早期项目的SOTIF试点，说实话，当时大家都很迷茫。因为标准草案一直在变，2019年才正式发布第一版。
标准的核心思路其实就一句话：找出那些“系统没坏但会出事”的场景，然后要么改设计，要么加限制。
我的经验：别把SOTIF想得太玄乎。它本质上就是“场景探索 + 危险分析 + 验证确认”。跟功能安全最大的区别是——功能安全分析的是“失效模式”，SOTIF分析的是“能力边界”。
1.3 ISO 21448标准概述——它到底讲了什么？
ISO 21448的结构，我习惯把它分成三大块：
| 模块 | 核心内容 | 我的理解 |
|---|---|---|
| 第1-4章 | 范围、引用、术语 | 定义清楚什么是“预期功能”，什么是“触发条件” |
| 第5-8章 | 规范与设计 | 告诉你如何定义功能、分析场景、识别危险 |
| 第9-12章 | 验证与确认 | 怎么证明你的系统在已知/未知场景下是安全的 |
嗯，这里要注意：ISO 21448并不是要替代ISO 26262。它们是互补关系。
- ISO 26262：系统坏了怎么办？
- ISO 21448：系统没坏但不够聪明怎么办？
你想想看，一个L4级自动驾驶系统，如果只做功能安全不做SOTIF，那就像一个人“身体很健康但智商有问题”——不出事才怪。
1.4 核心概念：触发条件与危险事件
SOTIF里有两个概念，我建议你刻在脑子里：
触发条件：导致系统进入不安全状态的那些“外部因素”或“系统自身局限”。
比如：
- 传感器被强光直射（性能局限）
- 道路标线模糊不清（场景复杂）
- 算法对异形车辆漏检（功能不足）
危险事件：触发条件 + 系统行为不当 + 人的误操作，最终导致伤害。
我曾经在一个项目中遇到过这种情况：
系统在雨天夜间（触发条件）把路面积水误判为路面（功能不足），然后没有减速直接冲过去，导致车辆失控。这就是一个典型的SOTIF危险事件。
避坑指南：我曾经见过很多团队把SOTIF分析做成了“功能安全分析的翻版”。这是大错特错的。SOTIF分析的核心是“场景”，不是“故障”。你分析的不是“传感器坏了会怎样”，而是“传感器在什么条件下会看不清”。
1.5 已知危险与未知危险——SOTIF的核心挑战
ISO 21448把危险场景分成四类：
- 已知安全场景：我们知道它安全，也验证过。
- 已知危险场景：我们知道它危险，通过设计或限制来规避。
- 未知安全场景：我们不知道它安全，但实际是安全的——这不用管。
- 未知危险场景：我们不知道它危险，但实际会出事——这是SOTIF要消灭的核心目标。
说白了，SOTIF的终极目标就是：把“未知危险”变成“已知危险”，然后干掉它。
怎么干？
- 场景探索：用仿真、路测、数据挖掘，把那些“没想到的场景”找出来。
- 危险分析：分析这些场景下系统会不会出问题。
- 验证确认：证明系统在这些场景下是安全的，或者根本不会遇到这些场景。
我的建议：做SOTIF别想着一步到位。先聚焦“已知危险”，把能想到的场景都分析透。然后通过路测和仿真不断发现“未知危险”。这是一个迭代过程，不是一次性交付。
1.6 小结——SOTIF到底在做什么？
用一句话总结：
SOTIF就是“找茬”——找出系统在正常工作时，因为不够聪明而可能犯的错误，然后逼着它变聪明，或者限制它的活动范围。
ISO 21448给了我们一套方法论：
- 怎么定义功能边界
- 怎么分析场景
- 怎么验证安全
- 怎么接受残余风险
我个人觉得，SOTIF比功能安全更难落地。因为功能安全有明确的故障模型和覆盖率要求，而SOTIF面对的是“无限场景”。
但反过来想，这也正是它的魅力所在——你永远有新的场景要去探索，永远有未知的危险要去发现。
下一章，我会详细讲场景探索的具体方法——怎么系统地找出那些“要命”的场景。到时候我会分享一些我在实际项目中踩过的坑，希望对你有帮助。