最近，听到一个说法：SOTIF就是解决性能不足、功能局限、人为误用的问题。

刚听说的时候，觉得挺有道理。但仔细想想，如果真的把这句话当成SOTIF的全部，就很容易把问题想简单了。因为这里面涵盖着三大类风险，而每一类都藏着一堆让人头疼的工程细节。

1. 性能不足：算法也有“软肋”

什么是性能不足？说白了就是算法在它应该能处理的情况下，却没有处理好。

组成员在做规控时遇到过一个问题，他们的MPC轨迹规划器在仿真里跑得特别漂亮，各种场景都过了，但有一次在封闭场地做测试时，遇到一个特定曲率的弯道，对面又来了一辆车，然后规划器就突然懵住了，输出了一条很不合理的轨迹。他分析后发现，问题出在几个参数的组合上：预测时域长度、成本函数里的权重、对对面车辆意图的估计等等，这些单独看都没有问题，但凑到一起就出事了。工程师感慨说：算法的软肋不是设计出来的，是碰出来的。

但是，做汽车研发单纯靠碰那是不可能的，如果想提高效率，就需要即便不知道什么时候会踩到某个坑，但是你得知道这个坑将来会出现在哪里。这也就是SOTIF里常说的“识别触发条件”，需要能够找出那些能让正常系统“不正常”的环境条件组合。

2. 功能局限：用户根本不管你的ODD

功能局限这件事，说起来其实挺扎心的。在设计系统的时候，设计师划了一个圈叫ODD（运行设计域）。但是用户其实根本不管这个圈。之前同事做过一个L2+ 系统，明确写了“仅适用于高速公路”。结果，很多用户在乡间小路上还继续开着。

这种用户手册写清楚了，系统也提示了，但是用户在受到广告和体验过一段时间后，会误以为“这车挺智能的，复杂问题能处理”。但用户不知道的是，功能局限的发生有两类触发条件，一种是典型触发条件，指那些我们都能想到的，比如目标物被遮挡等场景；第二种是特殊的触发条件，指那些我们想不到的或者不太容易量化评估的，例如特殊的降雨强度下，传感器的感知效果会大幅下降等情况。典型的触发条件是能够测量的，而特殊类型的最不好整，因为你不知道它存不存在，假使存在，又存在于哪里，一直惴惴不安，直到某天真的出了问题。

3. 人为误用：用户不是故意的

这类风险可能是最让人无奈的一类。

看“误用”的字面意思，你可能会理解为是用户操作不当。但了解后才明白，很多时候并不是用户操作不当，而是用户的“心理模型”和系统的“设计模型”对不上。

2026年1月发表于《SAE International Journal》的一项研究中提出了针对“合理可预见的误用”的结构化评估框架。该研究以自动紧急制动（AEB）系统为例，分析了驾驶员在高速状态下过度依赖AEB的场景。因为正常情况下，AEB不该在高速行驶的时候产生急刹，因为后面可能会有车，急刹车容易造成追尾事故。但有些驾驶员在高速上遇到前车减速的情况时，却会想着依赖AEB，觉得系统会帮自己去刹车，但结果是系统根本没打算介入，最后就造成了事故的发生。

该研究团队用了一个很有意思的方法来分析这个问题，他们先是做了STPA分析，这是一种系统性的安全分析方法，不是列清单那种，而是从“控制行为”的角度去找漏洞。之后他们用仿真测试去量化风险，最后用驾驶员在环测试系统做实验验证。最终，研究团队认为，合理可预见的误用是可以在设计阶段被建模、仿真和验证的。换句话说，人为误用可以通过在设计阶段考虑上用户的行为逻辑而减少发生。

SOTIF到底是做什么的？

SOTIF分析框架是建立在场景分类的基础上，业内称之为“四区模型”（见下图），SOTIF的工程目标就是要扩大区域1，压缩区域2和区域3，直到残余风险可接受。

其中区域3是最麻烦的，因为你不知道危险在哪儿，所以根本没有办法去一个一个地测出来。于是，工程师们想到一个办法是用统计学来“兜底”。简单说，就是在一个很大的范围内进行随机测试（主要是仿真），如果跑N个场景都没出事，那在95%的置信度下，真正会出事的概率也不会超过3/N。这就是行业里常说的“三分法则”。理论上来讲，如果要证明风险足够低，那就得跑足够多的测试。这也是为什么SOTIF验证需要用到海量仿真的根本原因，因为物理路测无法高效满足那么多的里程要求。

有哪些方案可以用来验证SOTIF？

1. 高级整车在环系统（VaHIL）

有次在实验室里看到一套设备：一辆真车停在测试台架上，面前的环形屏幕里跑着仿真场景，一会下暴雨，一会突然窜出个行人，一会又有隧道口光线突变的场景出现等。这些仿真场景恰恰就是SOTIF需要测试的那些触发条件，而这些特定的光照角度、特定的雨量、特定的目标物等在真实道路上很难按需出现以及复现，但在这个测试台架上就可以精确控制，想跑多少次就跑多少次。后来我们把几个之前路上很难复现的corner case放到VaHIL上跑，很短的时间就出测试结果了。测试工程师说：“如果早点用上这个，之前加班熬夜追BUG的日子能少上一半。”

2. “水母”云仿真平台

SOTIF验证需要的测试量是惊人的，我们不可能在路上跑那么久，所以大部分的测试基本会在云端完成。“水母”云仿真平台内置了很多场景库，包括C-NCAP、E-NCAP等法规场景、交通事故场景、自然驾驶场景、针对SOTIF设计的触发条件场景等等。这个平台可以实现多节点并发测试，每天能跑上百万公里以及千万公里，能够高效积累有效测试里程。

3. “水木灵境”场景工场

场景多了也会有问题，因为需要分辨出哪些场景是有价值的，哪些是冗余的。“水木灵境”场景工场可以将各种来源的数据加工成可用的测试场景，通过多源场景数据体系的建设以及对车路云一体化场景数据的构建，可以更有效地进行SOTIF有效性的验证。SOTIF的难点不在已知的危险域，而在未知的危险域。场景工场可以帮工程师在“未知”里找线索。

一些暂时没想清楚的问题

目前，SOTIF的基本框架是大概了解了，但还有些问题依然存在疑问：

1. 怎么判断“足够安全”？

就这个问题，统计学方法给了一个数据，例如风险低于10的-8次方。但，这个数字是怎么定的呢？定高了，成本扛不住，定低了，安全又没有保障。那行业里有没有一个公认的标准呢？查了很多资料，发现不同的厂商、不同场景的标准都不一样。

2. AI算法怎么SOTIF？

传统的SOTIF方法（例如STPA）是针对规则系统的，但现在自动驾驶越来越依赖AI，模型的输出是不确定的，那怎么对不确定的系统做SOTIF分析呢？看到有些研究在尝试用对抗生成的方法去探测模型的边界，但感觉离工程化还有些距离。

3. 人为误用怎么建模？

人的行为太复杂了，上述提到过的那篇有关AEB的研究给了我些启发，但研究中用到的方法需要做大量的人因实验，成本不低。那有没有更高效的建模方法，还是说，SOTIF里的“人为误用”只能是一个案例一个案例地去分析？

等等。

最后

回到开篇的那句话：SOTIF就是解决性能不足、功能局限、人为误用的问题，这句话到底有没有说对呢？个人的感觉是：说对了，但是只说了一半。说对的部分是它点出了SOTIF关注的核心风险类别。没说到的部分，是它省略了从“识别风险”到“证明安全”之间的那一整套工程方法。

SOTIF不是单纯的一个概念，而是一套需要落地的工程体系，它要求工程师能够系统性地找出算法的“软肋”在哪儿（即，触发条件的识别）；借助海量测试去覆盖那些“未知”的角落；借助测试台架安全可复现地进行极端工况的测试（借助VaHIL）；以及重要的是要把用户的真实行为考虑进设计里（人为误用建模）。但是这个体系里的每个方面都不是简单的，也没有一个能跳过去。毕竟，安全这件事，从来就没有捷径。