1. SOTIF概述：什么是SOTIF？

大家好，我是你们的老朋友。今天咱们聊聊SOTIF——预期功能安全。

说实话，我第一次接触这个概念时，也觉得很绕。功能安全还没搞明白呢，怎么又冒出来个SOTIF？但干这行久了，你会发现，这两者其实是“一个硬币的两面”。

1.1 什么是SOTIF？

SOTIF，全称是“Safety Of The Intended Functionality”。中文叫“预期功能安全”。

什么意思呢？说白了，就是“功能本身没坏，但用起来可能出问题”。

举个例子。你想想看，一辆车的自动紧急制动系统（AEB）。硬件没坏，软件也没崩溃，传感器都正常。但遇到一个特别大的弯道，系统把路边的广告牌误识别成了障碍物，一脚急刹——这就是SOTIF要管的事。

我遇到过类似的项目。有一次，客户反馈说他们的自适应巡航在隧道出口突然加速。查了半天，不是传感器故障，也不是算法bug。原因是隧道内外光线变化太大，摄像头短暂“失明”了。嗯，这就是典型的SOTIF问题。

1.2 SOTIF与功能安全的区别与联系

很多新人会问：功能安全和SOTIF到底有啥区别？

我习惯用一个比喻来解释：

• 功能安全（ISO 26262）：管的是“系统坏了怎么办”。比如ECU短路、传感器失效、软件跑飞。这是“硬件/软件故障”。
• SOTIF（ISO 21448）：管的是“系统没坏，但能力不够怎么办”。比如摄像头看不清、雷达被遮挡、算法误判。这是“性能局限”。

说白了，功能安全是“防故障”，SOTIF是“防无能”。

但两者不是割裂的。我建议你记住这句话：SOTIF是功能安全的“前置条件”。

为什么？因为如果功能本身就不安全（比如一个设计有缺陷的AEB），你就算把硬件做到ASIL D，它依然会出事故。反过来，如果功能安全没做好，SOTIF分析得再漂亮，系统一坏照样完蛋。

对比维度	功能安全（ISO 26262）	SOTIF（ISO 21448）
关注对象	系统性故障、随机硬件故障	功能性能局限、可预见误用
典型场景	传感器短路、软件栈溢出	传感器极限工况、算法误判
分析方法	FMEA、FTA、FMEDA	STPA、触发条件分析、场景分析
安全目标	避免因故障导致危害	避免因功能不足导致危害

1.3 SOTIF标准ISO 21448简介

ISO 21448，全称是“Road vehicles — Safety of the intended functionality”。

这个标准是2019年发布的。说实话，它比ISO 26262年轻不少。但它的重要性，在自动驾驶领域是“顶梁柱”级别的。

标准的核心思想是什么？我总结为三点：

1. 识别触发条件：找到那些“功能没坏但会出问题”的场景。
2. 评估风险：判断这些场景是否会导致不可接受的风险。
3. 降低风险：通过功能改进、系统冗余、用户警告等方式，把风险降到可接受水平。

标准里有个关键概念叫“触发条件”（Triggering Condition）。说白了，就是“什么情况下，这个功能会掉链子”。

举个例子。对于车道保持系统，触发条件可能是：

• 车道线磨损严重（摄像头看不清）
• 雨雪天气（传感器性能下降）
• 路面有积水（反光干扰）

嗯，这里要注意。ISO 21448并不是一个“认证标准”。它不像ISO 26262那样，有明确的ASIL等级。它更像是一套方法论，告诉你“怎么去分析和验证”。

标准的结构大致是这样的：

• 第4-6章：概念、定义、框架（了解即可）
• 第7章：功能规范与系统架构（重点）
• 第8章：触发条件识别（核心中的核心）
• 第9章：风险评估
• 第10章：功能改进与验证
• 第11章：确认测试

我个人习惯，把第8章到第11章称为“SOTIF的黄金四步”。后面的课程，我们会一步步拆解。

最后说一句。ISO 21448和ISO 26262不是“二选一”。在量产项目中，两者是并行的。功能安全管“故障”，SOTIF管“能力不足”。只有两者都做好了，你的系统才算真正安全。

好，这一章就到这里。下一章，我们深入聊聊“触发条件”到底怎么找。