第1章 SOTIF概述

1. SOTIF概述：ISO 21448标准背景、SOTIF与功能安全的关系、SOTIF核心概念

大家好，我是你们的老朋友。今天咱们正式开始聊SOTIF——也就是ISO 21448标准。说实话，我第一次接触这个标准的时候，心里也犯嘀咕：功能安全（ISO 26262）还没吃透呢，怎么又冒出来一个SOTIF？但干过几个项目之后，我慢慢明白了，这两个东西其实是「两条腿走路」，缺一不可。

先说说这个标准是怎么来的。你想想看，传统的功能安全主要对付的是「系统故障」——比如传感器坏了、芯片烧了、软件跑飞了。但自动驾驶时代来了之后，我们发现一个更头疼的问题：系统本身没坏，但就是干不好活。

举个例子，我有个朋友做ADAS项目，摄像头、雷达都好好的，算法也跑得挺顺。结果一到下雨天，车道线识别就乱跳。你说这是故障吗？不是。硬件没坏，软件也没bug。但就是功能不足——这就是SOTIF要管的事。

ISO 21448就是在这样的背景下诞生的。它专门针对「预期功能安全」，说白了就是：系统在正常工作时，会不会因为设计上的局限性，导致危险发生。

核心要点：ISO 21448不是要替代ISO 26262，而是补上后者管不到的那块——「功能不足」带来的风险。

这两个标准的关系，我习惯用一个比喻来讲：

我在做L2级辅助驾驶项目时，就踩过这个坑。当时功能安全分析做得挺全，所有硬件故障都覆盖了。结果路试时发现，系统在隧道出口处突然急刹车——因为摄像头从暗到亮，瞬间过曝，把阴影误判成了障碍物。

硬件坏了吗？没有。算法错了吗？也没错。但就是功能不足——摄像头动态范围不够，这就是SOTIF要解决的问题。

我的建议：做项目时，别把这两个标准割裂开。我习惯在系统设计阶段就同时考虑「故障」和「功能不足」两种风险，这样后期返工少很多。

好，接下来咱们聊聊SOTIF的三个核心概念。这三个词你搞懂了，SOTIF就算入门了。

什么叫功能不足？说白了就是：系统能力有限，应付不了某些场景。

我举个例子你就明白了。现在的自动紧急制动（AEB）系统，大部分在白天、干燥路面表现不错。但一到晚上、下雨天，性能就大打折扣。这不是故障，是功能不足——传感器感知能力有限，算法处理能力有限。

功能不足分两种：

注意：功能不足不是bug，不是故障。它是系统设计时「有意或无意」留下的局限性。你没法完全消除它，只能通过验证和确认来降低风险。

触发条件，就是让功能不足「暴露出来」的那个导火索。

我曾经做过一个项目，系统在高速上表现完美，但一到城市道路的十字路口就出问题。后来一查，触发条件是「行人突然从停着的公交车后面窜出来」。系统不是不能识别行人，而是对这种「遮挡后突然出现」的场景，反应时间不够。

常见的触发条件包括：

你想想看，这些触发条件千奇百怪。我个人的习惯是，先列出所有可能的触发条件，然后按严重程度排序。这样测试时就能有的放矢。

危害事件，就是功能不足 + 触发条件，最终导致的结果——有人受伤了，或者财产损失了。

注意，不是所有功能不足都会导致危害事件。比如，自适应巡航在弯道中速度控制不够精准，但驾驶员及时接管了，那就没出事。只有当功能不足 + 触发条件 + 驾驶员来不及接管，三者凑齐了，才会酿成危害事件。

危害事件的严重程度，一般从三个方面评估：

避坑指南：我曾经犯过一个错误——只关注了「高严重度」的危害事件，忽略了那些「低严重度但高频发生」的场景。结果路试时，系统频繁触发不必要的制动，用户体验极差。记住，SOTIF不仅要管「会不会死人」，还要管「好不好用」。

好了，第一章的内容就到这里。咱们回顾一下：

下一章，咱们会深入聊聊「SOTIF的生命周期」——从设计到验证，每一步该怎么做。到时候我会分享一些实际项目中的踩坑经验，保证让你少走弯路。

嗯，今天就到这里。有问题随时交流。