1. 功能安全与预期功能安全概述：SOTIF与FuSa的区别与联系、ISO 21448标准解读、预期功能安全的核心目标

大家好，我是老张。在汽车电子这行摸爬滚打了十几年，今天咱们来聊聊功能安全（FuSa）和预期功能安全（SOTIF）这对“孪生兄弟”。

说实话，我刚接触SOTIF的时候，也觉得它跟FuSa差不多。后来踩过坑才发现——这俩东西，一个管“系统坏了怎么办”，一个管“系统没坏但干了蠢事怎么办”。你想想看，是不是这个理？

1.1 FuSa与SOTIF：一对互补的“安全卫士”

先说说功能安全（Functional Safety，FuSa）。它的核心逻辑很简单：系统出了故障，不能伤人。比如刹车踏板断了、传感器短路了、ECU死机了——这些都属于FuSa的管辖范围。ISO 26262就是干这个的。

那预期功能安全（SOTIF）呢？它管的是系统本身没坏，但行为超出了人的预期。举个例子：

• 摄像头没坏，但大雾天看不清路——这是SOTIF问题
• 雷达没坏，但把路边的铁皮广告牌当成了障碍物——这也是SOTIF问题
• 算法没bug，但训练数据里没见过逆光场景——这还是SOTIF问题

我在项目中遇到过一件事：某L3级自动驾驶系统，所有传感器都正常，功能安全等级也达标。结果在隧道出口遇到强光，摄像头瞬间过曝，系统直接退出自动驾驶——幸好驾驶员及时接管。你看，这就是典型的SOTIF问题。硬件没坏，但场景超出了设计范围。

1.2 ISO 21448标准解读：SOTIF的“游戏规则”

ISO 21448是SOTIF的专用标准。它不像ISO 26262那样强调“故障率”，而是更关注“功能不足”和“触发条件”。

标准里有个核心概念叫“已知危险场景”和“未知危险场景”。说白了：

• 已知危险场景：你知道这个场景会出问题，比如大雨天摄像头看不清。那就得想办法解决——加传感器融合、加算法优化、或者干脆限制功能使用条件。
• 未知危险场景：你压根没想到这个场景会出问题。比如某款车在雪地倒车时，后视摄像头被积雪覆盖——开发团队从来没测试过这个场景。

ISO 21448还强调一个概念叫“功能不足”。什么意思？就是系统能力不够。比如：

• 感知系统在夜间识别率下降——功能不足
• 决策系统在复杂路口犹豫不决——功能不足
• 执行系统在湿滑路面制动距离变长——功能不足

这些都不是“故障”，而是“能力边界”。SOTIF要做的就是明确这个边界，并在边界内保证安全。

1.3 预期功能安全的核心目标

说了这么多，SOTIF到底想达成什么？我总结了三句话：

1. 减少“系统没坏但出事了”的概率——这是最直接的
2. 明确系统的能力边界——让用户知道什么时候该接管
3. 持续迭代改进——因为未知场景永远存在

我曾经参与过一个项目，团队花了大半年做SOTIF分析。结果发现，最危险的不是那些复杂的场景，而是“看起来很简单但系统就是处理不了”的场景。比如：

• 高速路上，前车突然掉下一个纸箱——系统识别成“静态障碍物”，急刹车——后车追尾
• 十字路口，行人打伞过马路——系统漏检——差点撞上

这些场景，你说系统坏了吗？没有。但就是处理不好。SOTIF要解决的，就是这类问题。

1.4 FuSa与SOTIF的协同关系

很多人问我：FuSa和SOTIF到底谁更重要？我的回答是：缺一不可。

你看这张图就明白了：

从图上你能看到：

• FuSa 管的是“系统坏了怎么办”——需要硬件冗余、故障检测、安全状态
• SOTIF 管的是“系统没坏但不够聪明怎么办”——需要场景分析、算法优化、人机交互
• 两者重叠的区域——比如安全目标定义、危害分析——需要协同工作

我记得有个项目，团队把FuSa和SOTIF分开做，结果发现：FuSa分析出来的安全机制，在SOTIF场景下反而成了隐患。比如：

• FuSa要求：传感器故障时立即降级
• SOTIF场景：传感器没故障，但被遮挡了——系统也降级了——驾驶员困惑

你看，这就是没协同好的后果。所以我现在做项目，FuSa和SOTIF的团队必须坐在一起开会，至少每周一次。

1.5 实际落地中的常见误区

最后，分享几个我见过的常见误区：

好了，这一章就聊到这里。记住一句话：FuSa保底，SOTIF提上限。两者缺一不可。

---

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