第1章 SOTIF概述

一、SOTIF概述：什么是预期功能安全？

大家好，我是老张。在功能安全领域摸爬滚打了十几年，今天咱们来聊聊SOTIF——预期功能安全。说实话，这个概念刚出来的时候，我也懵了一阵子。

咱们先从一个真实案例说起。2016年，特斯拉的Autopilot在佛罗里达发生了一起致命事故。车辆没有识别出白色卡车车厢，直接撞了上去。传感器没坏，算法也没崩溃，系统本身是“正常”工作的。但结果呢？人没了。

这就是典型的预期功能安全问题。系统没有故障，但它的功能在特定场景下就是不够用。

预期功能安全的定义：

预期功能安全（Safety of the Intended Functionality，SOTIF）是指：在系统没有故障的情况下，由于功能本身的局限性或环境干扰，导致系统无法正确应对预期场景，从而引发危害的风险。

说白了，就是系统“脑子不够用”或者“眼睛花了”。不是它坏了，是它能力有限。

1.1 功能安全 vs 预期功能安全

我经常被问到：功能安全和SOTIF到底有什么区别？

咱们用一张表说清楚：

对比维度	功能安全（ISO 26262）	预期功能安全（ISO 21448）
关注对象	系统故障（硬件随机失效、系统失效）	功能不足、性能局限、环境干扰
系统状态	系统存在故障	系统无故障，但功能受限
典型场景	传感器坏了、ECU死机、通信中断	传感器没坏，但识别不出白色卡车
分析方法	FMEA、FTA、FMEDA	STPA、场景分析、触发条件分析
标准	ISO 26262	ISO 21448

嗯，这里要注意：两者不是替代关系，是互补关系。一个系统要真正安全，两个都得做。

1.2 一个让我印象深刻的项目

我记得2018年参与过一个L3级自动驾驶项目。客户说：“我们的传感器都是双冗余的，功能安全等级ASIL D，绝对安全。”

我当时就问了一个问题：“如果下大雨，摄像头被雨滴遮挡，激光雷达被泥水溅到，你们的系统还能正常工作吗？”

对方沉默了。

这就是典型的SOTIF问题。传感器没坏，但环境干扰让它的性能大打折扣。你想想看，如果系统设计时没有考虑这些场景，那所谓的“安全”就是空中楼阁。

二、SOTIF的起源与发展

2.1 为什么会有SOTIF？

其实SOTIF这个概念不是凭空冒出来的。2016年特斯拉事故之后，整个行业都在反思：我们是不是太关注“系统坏了怎么办”，而忽略了“系统没坏但不够用怎么办”？

ISO 21448标准就是在这样的背景下诞生的。2019年发布了第一版，2022年发布了更新版。我个人觉得，这个标准的发展速度已经很快了，毕竟自动驾驶技术本身也在飞速迭代。

2.2 SOTIF的核心思想

SOTIF的核心思想其实很简单：

识别场景：系统会在哪些场景下运行？
评估风险：这些场景下，系统的功能是否足够？
降低风险：如果不够，怎么改进？

我曾经在项目里遇到过一个问题：系统在高速公路上表现很好，但一进隧道就出问题。为什么？因为GPS信号丢失，定位精度下降。这不是故障，是功能局限。我们后来加了一个视觉里程计作为补充，问题就解决了。

避坑指南：

我曾经见过一个团队，花了大半年时间做功能安全分析，结果SOTIF分析只用了两周。最后测试时发现，系统在雨天、夜间、隧道等场景下频繁出问题。所以我的建议是：SOTIF分析要尽早做，别等到功能安全做完了才想起来。

三、SOTIF与功能安全的关系

3.1 两者如何协同？

很多人觉得SOTIF和功能安全是两套独立的东西。其实不是。它们应该是一个整体安全策略的两个方面。

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

功能安全：就像给车装上了安全带和气囊。万一出事了，能保护你。
SOTIF：就像训练司机，让他能提前预判危险，避免出事。

两者缺一不可。你想想看，一个司机技术再好，车子的刹车突然失灵了，那也不行。反过来，车子再安全，司机是个新手，遇到复杂路况就慌，那也危险。

3.2 实际项目中的分工

在实际项目中，我建议这样分工：

功能安全：负责处理系统故障，比如传感器失效、通信中断、软件崩溃等。
SOTIF：负责处理功能不足，比如传感器性能局限、算法边界、环境干扰等。

举个例子：

如果摄像头坏了，这是功能安全问题。
如果摄像头没坏，但在强光下逆光拍摄效果差，这是SOTIF问题。

注意事项：

千万不要把SOTIF当成功能安全的“附属品”。它们是并行的，不是串行的。我见过一些项目，把SOTIF分析放在功能安全分析之后，结果发现很多问题需要重新设计硬件，成本翻了好几倍。

四、SOTIF的知识体系框架

下面这张图是我自己总结的SOTIF知识体系框架，希望能帮你理清思路：

这张图是我在项目实践中总结出来的。你看，SOTIF的核心就是三个步骤：场景分析、触发条件分析、风险评估。每一步都有具体的子任务。

4.1 场景分析

场景分析是SOTIF的起点。你得先知道系统会在什么场景下运行，才能判断它能不能应对。

我习惯把场景分为三类：

正常场景：晴天、白天、高速公路。这些场景下系统应该表现良好。
边缘场景：雨天、夜间、隧道。这些场景下系统可能表现不佳。
极端场景：暴雪、浓雾、强光直射。这些场景下系统可能完全失效。

个人经验：

我建议在项目初期就建立一个场景库。把你能想到的所有场景都列出来，然后逐步筛选。别怕场景太多，漏掉一个关键场景才是真正的风险。

4.2 触发条件分析

触发条件就是那些让系统“掉链子”的因素。我总结了几类常见的触发条件：

环境因素：光照变化、天气变化、道路条件变化
系统因素：传感器性能边界、算法局限性、计算资源不足
交互因素：与其他交通参与者的交互、与基础设施的交互

举个例子：摄像头在逆光下性能下降，这就是环境因素触发的。算法在复杂路口无法准确预测行人轨迹，这就是系统因素触发的。

4.3 风险评估

风险评估的目的是判断：这个风险到底有多大？需不需要采取措施？

我常用的方法是：

危害识别：这个场景下，系统失效会导致什么后果？
严重度评估：后果有多严重？
可控性评估：驾驶员或系统能否控制住局面？

嗯，这里要注意：SOTIF的风险评估和功能安全的ASIL等级评估是类似的，但侧重点不同。SOTIF更关注场景的覆盖率和触发条件的概率。