2、SOTIF核心概念：功能不足与触发条件、已知危险场景与未知危险场景、安全性能指标

好，咱们接着聊。上一章我们把SOTIF的来龙去脉讲清楚了，这一章要啃硬骨头了——核心概念。说实话，我刚接触SOTIF那会儿，最头疼的就是这些术语。什么功能不足、触发条件、已知未知场景……听着都像，但实际用起来差远了。

我个人的习惯是，先把概念拆开揉碎了，再串起来。咱们今天就按这个路子走。

2.1 功能不足与触发条件

先说功能不足。这词儿听着挺学术，说白了就是：系统该干活的时候没干好，或者干了不该干的事。

举个例子。自适应巡航系统，前面有车它应该减速。结果因为大雨，摄像头看不清，它没减速——这就是功能不足。不是系统坏了，是它在某些条件下“能力不够”。

功能不足分两类：

• 性能局限：传感器感知范围不够、算法识别率低、执行器响应慢。比如激光雷达在浓雾里性能下降，这是物理限制。
• 功能局限：系统设计时就没考虑某些场景。比如某款车的AEB系统，设计时只考虑了白天，晚上根本不会触发——这就是功能定义本身的问题。

那触发条件呢？就是让功能不足“暴露出来”的那个导火索。我遇到过最典型的例子：某款车的车道保持系统，在隧道出口处经常失效。为什么？因为隧道内外光照突变，摄像头瞬间过曝。光照突变就是触发条件，摄像头动态范围不足就是功能不足。

触发条件可以来自：

• 环境：雨、雪、雾、光照、温度、道路标线磨损
• 系统自身：传感器脏污、软件版本差异、硬件老化
• 用户行为：驾驶员误操作、不按规范使用（比如用身体压着方向盘）
• 其他交通参与者：行人突然冲出、前车急刹、摩托车穿插

2.2 已知危险场景与未知危险场景

这两个概念，是SOTIF方法论的核心。我刚开始做的时候，总搞混。后来一个老工程师点醒了我：“已知”和“未知”，不是按“有没有发生过”分的，是按“你有没有分析过”分的。

咱们用一张图来理解：

这张图我建议你存下来。做SOTIF分析时，脑子里时刻要有这个矩阵。

已知危险场景：就是那些我们已经分析过、测试过的场景。比如“行人从车前横穿”、“前车急刹”。这些场景我们有测试用例，有通过标准，有覆盖要求。说白了，是“心里有数”的部分。

未知危险场景：这才是SOTIF要啃的硬骨头。它分两种：

• 可推理的未知：比如“隧道出口光照突变导致摄像头失效”。虽然没发生过，但通过系统分析、FMEA、STPA等方法可以推理出来。这部分可以通过系统化分析来覆盖。
• 完全未知：比如“一群羊突然出现在高速上”。你设计时根本想不到。这部分只能靠路测、影子模式、OTA持续迭代来发现。

2.3 安全性能指标

好，概念讲完了，怎么量化？这就引出了安全性能指标。

我个人觉得，SOTIF的指标和功能安全最大的不同在于：功能安全指标是“硬”的（比如FIT率、PMHF），而SOTIF指标是“软”的——它衡量的是系统在非故障条件下的安全表现。

常用的指标有这几个：

指标名称	定义	典型值	我的备注
误触发率	系统在不该触发时触发的概率	< 1次/1000小时	误触发多了，用户会关掉系统
漏触发率	系统在该触发时没触发的概率	< 1次/10000小时	这个比误触发严重得多
场景覆盖率	已知危险场景中，已测试的比例	> 95%	注意：只覆盖已知场景
残余风险接受度	经过所有措施后，剩余风险是否可接受	定性/定量	这个需要管理层签字

你可能会问：这些指标怎么定？嗯，说实话，没有标准答案。ISO 21448给了框架，但具体数值得你自己定。我一般这么操作：

1. 先看法规：比如Euro NCAP对AEB有明确要求，那就按它的来。
2. 再看竞品：市面上同类产品的表现如何？不能比人家差太多。
3. 最后看用户接受度：这个最虚，但也最重要。我做过一个用户调研，发现用户能接受ACC偶尔加速慢，但不能接受它突然急刹。所以，不同功能的指标权重是不一样的。

最后说一句。这些指标不是定完就完事了。随着路测数据积累、软件迭代、新场景发现，指标要动态调整。我见过最离谱的项目，指标定完三年没变过——那基本等于没做SOTIF。

好，这一章的核心概念就这些。下一章咱们聊具体怎么做SOTIF分析——从STPA到FMEA，一步步来。

---

公众号:蓝海资料掘金营，微信deep3321