1. 功能安全与SOTIF概述：功能安全（ISO 26262）与SOTIF（ISO 21448）的基本概念、发展历程与核心目标
1.1 为什么要把这两个标准放在一起讲？
说实话，我刚入行那会儿，功能安全和SOTIF还是两拨人在做。搞功能安全的盯着硬件随机失效，搞SOTIF的盯着传感器感知缺陷。两边开会经常鸡同鸭讲。
但后来我慢慢发现，这两者其实是同一枚硬币的两面。你想想看，一个L3级自动驾驶系统，如果功能安全做得再好，但遇到暴雨天摄像头识别不了车道线，那车该停还是该走？这就是SOTIF要解决的问题。
所以，咱们这门课的第一章，先把这两个概念掰扯清楚。
1.2 功能安全（ISO 26262）到底是什么？
功能安全，说白了就是「系统出故障了，也不能伤到人」。它关注的是系统性故障和随机硬件失效。
我记得2015年做第一个ADAS项目时，客户要求ASIL B。我当时觉得不就是加个冗余嘛，结果评审时被问得哑口无言——「你的安全机制覆盖率是多少？诊断时间窗口怎么定的？」嗯，从那以后我再也不敢小看ISO 26262了。
核心目标：将不可接受的风险降低到可接受的水平。
关键手段：安全机制、故障检测、故障响应、安全状态。
ISO 26262从2011年第一版发布，到2018年第二版，最大的变化就是加入了半导体指南。我建议做芯片的朋友重点关注这部分。
1.3 SOTIF（ISO 21448）又是干嘛的？
SOTIF，全称是「预期功能安全」。它解决的是没有故障，但系统行为依然不安全的问题。
举个例子：
- 功能安全管的是「刹车踏板信号丢失了怎么办」
- SOTIF管的是「摄像头把白色卡车误认为天空，直接撞上去怎么办」
我在做L4级无人小巴项目时，遇到过最头疼的问题不是硬件坏了，而是「系统明明没坏，但就是识别错了」。比如雨天、逆光、隧道出入口这些场景，传感器性能受限，但系统又没报故障——这才是最危险的。
个人经验：SOTIF的核心在于「已知不安全场景」和「未知不安全场景」的识别与覆盖。我曾经花了一个月时间，专门跑各种corner case，最后发现80%的问题都集中在5%的极端场景里。
1.4 两个标准的发展历程
| 时间 | 功能安全（ISO 26262） | SOTIF（ISO 21448） |
|---|---|---|
| 2011年 | 第一版发布，覆盖乘用车 | 尚未形成标准 |
| 2018年 | 第二版发布，加入半导体、摩托车等 | ISO 21448第一版发布 |
| 2022年 | 持续更新中 | 第二版草案讨论中 |
为什么会先有功能安全，后有SOTIF？
因为早期的汽车电子系统相对简单，硬件故障是主要矛盾。但随着自动驾驶等级提升，传感器和算法的复杂性成了新的风险源。说白了，技术发展倒逼标准更新。
1.5 两者的核心目标对比
功能安全：「系统坏了，要安全地停下来」
SOTIF：「系统没坏，但也要安全地运行」
我个人的理解是：
- 功能安全是底线——出了故障不能死人
- SOTIF是天花板——在复杂环境中也要靠谱
举个实际项目中的例子：
我们做自动紧急制动（AEB）系统时，功能安全要求：如果雷达失效，必须在100ms内检测到并降级。而SOTIF要求：在雨天、雪天、隧道等场景下，AEB的误触发率不能超过某个阈值。
你看，一个是「失效了怎么办」，一个是「没失效但环境变了怎么办」。两者缺一不可。
1.6 避坑指南
我曾经踩过的坑：
- 别把SOTIF当成功能安全的子集。它们是并列关系，不是包含关系。
- 功能安全的HARA（危害分析与风险评估）和SOTIF的H&R（危害与风险分析）方法不同，别混用。
- SOTIF的验证比功能安全更依赖测试数据，别指望光靠文档就能过审。
1.7 小结
这一章我们讲了：
- 功能安全管「故障」，SOTIF管「性能不足」
- 两个标准的发展脉络——从硬件到算法，从确定性到不确定性
- 核心目标：一个保底，一个保优
下一章，我会带大家看看在实际项目中，这两个标准怎么协同工作。说实话，这才是最有意思的部分。
学习建议：如果你刚接触这两个标准，我建议先别急着啃原文。先理解「为什么要有这两个标准」，比背条款重要得多。