第2章 SOTIF标准解读

2、SOTIF标准解读：ISO 21448标准框架、标准适用范围、标准核心概念

大家好，我是你们的老朋友。今天我们来聊聊SOTIF标准，也就是ISO 21448。说实话，我刚接触这个标准的时候，也觉得它有点绕。但干了好几年功能安全，我慢慢发现，它其实是自动驾驶落地最关键的一环。

为什么这么说？你想想看，传统功能安全（ISO 26262）管的是系统故障，比如硬件坏了、软件跑飞了。但自动驾驶面临的最大挑战，其实是那些“系统本身没坏，但就是搞不定”的场景。比如大雾天摄像头看不清、算法没见过的诡异路况。这些，就是SOTIF要解决的问题。

核心观点：ISO 21448 不是要替代 ISO 26262，而是它的“好搭档”。一个管“已知风险”，一个管“未知风险”。

我个人习惯，学一个新标准先看它的骨架。ISO 21448的框架，说白了就是一条“发现问题-解决问题”的闭环。我画了张图，你一看就明白。

嗯，这张图其实就讲了三件事：找问题、分析问题、解决问题。我在项目里最深的体会是，很多人一上来就急着改算法，结果连触发条件都没找全。这就像看病没诊断就开药，白费功夫。

ISO 21448 的适用范围，我总结成一句话：管的是“预期功能”在“非故障”情况下的安全性。

具体来说：

避坑指南： 我曾经在一个项目里，把传感器硬件漂移算成了SOTIF问题，折腾了两周才发现是硬件老化导致的。记住，SOTIF 的前提是“系统本身是好的”。硬件坏了，请找26262。

另外，标准适用范围还包括一个关键点——ODD（运行设计域）。你设计的系统只能在特定条件下跑，比如晴天、高速、有车道线。出了这个范围，SOTIF 就要管了。我见过最典型的案例：某L2级系统在施工路段直接“罢工”，因为算法没学过锥桶。这就是典型的ODD外触发条件。

这三个概念是SOTIF的“三驾马车”。我一个个拆开讲。

功能不足，说白了就是“系统能力有短板”。不是它坏了，而是它天生就干不了某些事。

举个例子：

我在做AEB（自动紧急制动）项目时，发现系统对“鬼探头”场景的响应特别差。算法其实没bug，但就是识别太慢。这就是典型的功能不足——算法性能边界。

关键点： 功能不足 ≠ 故障。它是系统设计时就存在的“先天缺陷”。SOTIF 的目标就是找到这些缺陷，然后要么改进，要么告诉用户“这里我不行”。

触发条件，就是“什么情况下功能不足会暴露出来”。它通常是“功能不足 + 特定场景”的组合。

我习惯用一个公式来理解：

触发条件 = 功能不足 + 场景要素

比如：

你想想看，如果只是功能不足，但没有触发条件，系统可能一直表现良好。但一旦触发条件出现，危害就来了。所以，SOTIF 的核心工作之一，就是穷举所有可能的触发条件。

注意： 触发条件不是凭空想出来的。我建议用“场景矩阵”的方法，把ODD内的所有环境变量（光照、天气、道路类型、交通参与者）组合起来，逐一分析。我曾经用这个方法，在一个项目里找到了37个之前没发现的触发条件。

危害事件，就是“触发条件被激活后，最终导致的人员伤亡或财产损失”。它是SOTIF分析的终点。

危害事件通常包含三个要素：

嗯，这里要注意，不是所有功能不足都会导致危害事件。比如，雨刮器在暴雨中刮不干净，但车速很低且周围没车，那危害风险就很小。所以，SOTIF 要求我们做风险评估，只关注那些“高严重度 + 高暴露概率”的危害事件。

我的经验： 做危害分析时，别只盯着“最坏情况”。我见过一个团队，把所有场景都按最坏情况评估，结果发现所有问题都是S3（致命），根本没法排优先级。正确的做法是：结合真实场景数据，评估实际发生的概率。比如，“夜间黑色车辆”虽然严重，但如果你的车只在白天跑，那风险就低很多。

最后，我用一个实际案例，把这三个概念串起来：

你看，从功能不足到危害事件，中间隔着一个触发条件。SOTIF 要做的，就是切断这条因果链。要么改进功能不足（比如优化雷达滤波算法），要么避免触发条件（比如限制ODD，不让系统在高速上跑）。

好了，这一章的内容就到这里。ISO 21448 的框架、适用范围和三个核心概念，是后续所有分析的基础。下一章我们会深入讲“如何系统性地识别触发条件”，到时候我会分享一些实战中好用的工具和方法。