2. ISO 21448 标准解读：核心框架与关键术语
好，咱们进入正题。ISO 21448，也就是大家常说的SOTIF（Safety of the Intended Functionality）。这名字挺绕口，说白了就是——功能本身没坏，但它在特定场景下可能不安全。
我刚开始接触这个标准时，第一反应是：这不就是功能安全吗？后来踩了坑才明白，两者完全是两码事。功能安全（ISO 26262）管的是系统故障，比如传感器坏了、代码跑飞了。而SOTIF管的是——系统没坏，但环境太复杂，它搞不定。
举个例子：你开着L2级辅助驾驶，摄像头没坏，算法也没bug。但大雾天，摄像头看不清车道线，车开始画龙。这就是SOTIF要解决的问题。
2.1 标准的核心逻辑
ISO 21448 的核心逻辑其实就一句话：找出那些功能本身没问题、但在特定场景下会出事的工况，然后干掉它。
我个人习惯把SOTIF的工作流分成四步：
- 功能定义与场景分析——搞清楚你的系统在什么情况下工作，什么情况下可能失效。
- 危害识别与风险评估——找出那些潜在的危险场景，评估风险等级。
- 功能改进与验证——通过算法优化、传感器升级、冗余设计等手段降低风险。
- 确认与释放——通过大量测试证明风险已经降到可接受水平。
嗯，这里要注意：这四步不是串行的，而是迭代的。我在项目中遇到过，第一轮分析完觉得没问题，结果路试时发现一个新场景，又得回头重新评估。所以别想着一步到位。
2.2 关键术语：你得搞懂这些词
SOTIF里有一堆术语，我挑几个最关键的说说。你想想看，如果连这些词都搞混，后面分析肯定跑偏。
| 术语 | 英文 | 我的理解 |
|---|---|---|
| 预期功能 | Intended Functionality | 系统设计时打算实现的功能，比如ACC、LKA |
| 功能不足 | Functional Insufficiency | 系统能力不够，比如摄像头在逆光下看不清 |
| 触发条件 | Triggering Condition | 导致功能不足被激活的具体场景因素 |
| 危害行为 | Hazardous Behavior | 系统在触发条件下做出的危险动作 |
| 可接受风险 | Acceptable Risk | 经过评估后认为可以容忍的风险水平 |
重点提醒：功能不足 ≠ 故障。故障是系统坏了，功能不足是系统没坏但能力不够。比如一个摄像头在夜间只能看清50米，这不是故障，是它的物理极限。SOTIF管的就是这种极限问题。
2.3 场景分类：已知 vs 未知
ISO 21448 把场景分成四类，这个分类法我特别喜欢，因为它很直观：
- 已知安全场景——系统能正确处理，风险可控。
- 已知不安全场景——系统处理不了，但我们已经知道，正在改进。
- 未知安全场景——系统能处理，但我们还没发现这个场景存在。
- 未知不安全场景——系统处理不了，而且我们根本不知道有这回事。这是最危险的。
我曾经在一个项目中，把所有已知不安全场景都列出来了，觉得差不多了。结果路试时遇到一个「未知不安全场景」——高速路上突然出现一个掉落的轮胎，系统直接懵了。嗯，从那以后我养成了一个习惯：永远假设还有未知场景没被发现。
2.4 风险评估：S/E/C 三要素
SOTIF的风险评估和功能安全类似，也是用三个维度：
- S（Severity）——严重度，事故造成的伤害程度。
- E（Exposure）——暴露度，这个场景出现的概率。
- C（Controllability）——可控度，驾驶员能否接管并避免事故。
但有个关键区别：功能安全评估的是故障后的风险，而SOTIF评估的是功能不足被触发后的风险。说白了，一个管「坏了怎么办」，一个管「没坏但不行怎么办」。
我的小技巧：做SOTIF风险评估时，别只盯着S值。很多工程师一看到严重度S=3就慌了，但其实如果暴露度E很低（比如一年才遇到一次），风险等级可能并不高。反过来，一个S=1的场景如果天天遇到，也得重视。
2.5 标准的工作流程
ISO 21448 给出了一个完整的工作流程，我把它简化成几个关键步骤：
- 定义系统功能与运行设计域（ODD）——明确系统在什么条件下工作。
- 识别功能不足——通过分析、仿真、测试找出系统的短板。
- 评估风险——对每个功能不足+触发条件组合进行风险评估。
- 制定改进措施——比如增加传感器、优化算法、限制ODD等。
- 验证与确认——通过测试证明风险已降低。
- 持续监控——量产后的数据回传，发现新问题及时更新。
避坑指南：我曾经见过一个团队，把所有精力都放在「已知不安全场景」的改进上，结果量产半年后，用户反馈了一个「未知不安全场景」——系统在隧道出口突然急刹车。原因很简单：隧道内GPS信号弱，出来瞬间定位跳变，系统以为要撞墙了。这个场景在开发时完全没考虑到。
所以我的建议是：别只盯着已知问题，要留出资源去探索未知场景。路试、用户数据、仿真遍历，一个都不能少。
2.6 我的几点体会
做了几年SOTIF，我有几个体会想分享：
- SOTIF不是一次性工作——场景在变，系统在升级，风险也在变化。需要持续迭代。
- 别过度依赖仿真——仿真能覆盖很多场景，但真实世界的复杂性远超想象。我见过仿真里跑得完美，上路就翻车的案例。
- 团队协作很重要——SOTIF需要功能安全工程师、系统工程师、算法工程师、测试工程师一起参与。一个人搞不定。
- 文档要写清楚——ISO 21448要求很多文档，别嫌烦。我吃过亏，项目做完了发现分析记录不全，审核时补文档补到崩溃。
好了，这一章的内容就到这里。ISO 21448的核心框架和关键术语，说白了就是：搞清楚你的系统在什么场景下会不行，然后想办法让它行。下一章我们会深入讲场景分析与危害识别，到时候会用到很多实际案例。
公众号:蓝海资料掘金营，微信deep3321