一、SOTIF概述与背景
大家好，我是老张。在智能驾驶这个领域摸爬滚打了十几年，今天咱们来聊聊预期功能安全——也就是SOTIF。说实话，这个概念刚出来的时候，我也觉得挺绕的。但干得越久，越觉得这东西是绕不开的坎。
1.1 预期功能安全（SOTIF）的定义
先说说SOTIF到底是什么。用大白话讲，就是：系统在没出故障的情况下，因为功能本身设计得不够周全，或者遇到了它没见过的场景，导致出了安全问题。
举个例子你就明白了。我前几年参与过一个L2级辅助驾驶项目，功能逻辑跑得好好的，硬件也没坏。结果有一次，测试车在高速上遇到了一辆打着双闪的静止货车——系统直接撞上去了。为什么？因为感知模型从来没“见过”这种场景，它以为那是个路牌。
这就是典型的SOTIF问题。不是硬件坏了，不是软件崩溃了，是功能在预期之外的表现。
官方定义（ISO 21448）：预期功能安全是指不存在因功能不足、功能局限或可预见的人员误用而导致的不合理风险。
说白了，SOTIF关注的是：
- 功能不足——该有的能力没有，比如感知距离不够
- 功能局限——能力有，但边界条件没覆盖到，比如雨雾天失效
- 可预见的人员误用——用户瞎操作，但系统没拦住
1.2 ISO 21448标准的起源
ISO 21448这个标准，其实是被逼出来的。我记得2016年左右，行业内出了好几起自动驾驶相关的事故。事后分析发现，系统硬件没坏，软件也没崩溃，但就是出事了。
为什么会这样？因为传统的功能安全（ISO 26262）只管“系统坏了怎么办”，它不管“系统没坏但设计有漏洞怎么办”。
于是，ISO 21448应运而生。它的前身是2018年发布的PAS（公开可用规范），2022年正式升格为国际标准。我个人的理解是：ISO 21448是给智能驾驶系统补上的一块拼图。
我的经验：很多团队一开始只做ISO 26262，觉得SOTIF是“附加题”。结果项目做到一半，发现大量安全问题根本没法用故障树分析（FTA）来解释。这时候才回头补SOTIF，代价就大了。
1.3 与功能安全（ISO 26262）的区别与联系
这两个标准经常被放在一起说，但它们的关注点完全不同。我画了一张图，帮你快速理清思路：
这张图你看懂了吗？我解释一下：
| 对比维度 | ISO 26262（功能安全） | ISO 21448（SOTIF） |
|---|---|---|
| 关注对象 | 系统故障（硬件/软件失效） | 功能不足/局限（无故障） |
| 典型问题 | 传感器坏了、代码跑飞了 | 传感器没坏，但没识别出障碍物 |
| 分析方法 | FTA、FMEA、FMEDA | 场景分析、触发条件分析 |
| 安全等级 | ASIL A~D | 无等级，但需满足可接受风险 |
| 适用范围 | 所有电子电气系统 | L2及以上自动驾驶系统 |
注意：千万不要以为做了ISO 26262就万事大吉了。我曾经见过一个团队，ASIL D的架构都做完了，结果上路测试发现系统在隧道出口处频繁误刹车。查到最后，是感知模型对光线突变的适应性不够——这根本不是故障问题，是SOTIF问题。
1.4 两者的联系
虽然关注点不同，但这两个标准不是割裂的。我个人的习惯是：把SOTIF看作是功能安全的“上游”和“补充”。
- 上游关系：SOTIF先定义“功能应该怎么设计才安全”，功能安全再保证“这个设计在实现过程中不出故障”
- 互补关系：有些风险既可能是故障导致的，也可能是功能局限导致的。比如摄像头黑屏——可能是硬件坏了（26262），也可能是光线太暗导致算法失效（21448）
- 流程融合：我建议在项目早期就把SOTIF和功能安全的分析活动合并进行，避免重复劳动
避坑指南：我曾经在一个项目中，SOTIF团队和功能安全团队各做各的。结果到集成测试阶段，发现同一个风险被分析了两次，而且结论还不一致。后来我们统一了风险登记表，两个团队共用一套场景库，效率提升了不少。
1.5 为什么SOTIF越来越重要？
你想想看，现在的智能驾驶系统越来越复杂。L2+、L3级别的系统，感知、决策、执行环环相扣。任何一个环节的“认知盲区”都可能导致事故。
我记得2020年有个统计数据：在已公开的自动驾驶事故中，超过60%的事故原因被归类为“系统未识别到障碍物”或“错误识别”。这些都不是硬件故障，而是SOTIF问题。
所以，ISO 21448的出现不是偶然的。它逼着我们去思考：
- 你的系统在哪些场景下会“看不懂”？
- 用户会不会做出你没想到的操作？
- 你的功能边界到底在哪里？
嗯，这些问题没有标准答案。但SOTIF给了我们一套方法论，去系统地寻找答案。
好了，这一章就聊到这里。下一章我们会深入SOTIF的核心概念——触发条件、场景分析、ODD定义。这些东西听起来抽象，但我会用实际案例帮你吃透。