1. 功能安全概述：ISO 26262标准背景、功能安全与预期功能安全的区别、SOTIF（ISO 21448）简介
1.1 为什么我们需要功能安全？——ISO 26262的诞生背景
说实话，我刚入行那会儿，对功能安全的理解很浅。觉得不就是“别让车出事故”嘛。后来真正参与项目，才发现事情远没那么简单。
ISO 26262标准的出台，其实是被“逼”出来的。2000年代初，汽车电子系统越来越复杂。一个刹车系统里，电子控制单元（ECU）的代码量可能超过几百万行。你想想看，这么多代码，万一哪个角落的逻辑出了岔子，后果是什么？
我记得有一次，我在一个项目中排查一个偶发性的刹车助力失效问题。查了整整两周，最后发现是某个传感器信号在特定温度下发生了毛刺，导致控制逻辑误判。这种问题，靠传统的测试方法根本覆盖不到。这就是ISO 26262要解决的核心问题——系统性失效和随机硬件失效。
ISO 26262从2011年发布第一版，到2018年的第二版，一直在演进。它把汽车安全完整性等级分成了ASIL A、B、C、D四个等级。ASIL D最高，比如转向、刹车这类系统。ASIL A最低，比如一些非安全相关的舒适性功能。
核心要点：ISO 26262关注的是“系统本身有没有bug”和“硬件会不会随机坏掉”。它假设外部环境是“正常”的，只盯着系统内部的安全问题。
1.2 功能安全 vs 预期功能安全——别搞混了
很多刚接触安全工程的朋友，容易把这两个概念混为一谈。我刚开始也犯过这个错。
简单来说：
- 功能安全（Functional Safety）：处理的是“系统内部故障”。比如传感器坏了、代码写错了、芯片被干扰了。这些是ISO 26262的管辖范围。
- 预期功能安全（SOTIF）：处理的是“系统本身没坏，但就是干蠢事”。比如摄像头没坏，但在大雾天看不清路；算法没写错，但把白色卡车识别成了天空。这些是ISO 21448的管辖范围。
我给大家打个比方：
功能安全就像你请了一个司机，他身体很健康（没故障），但他可能因为路况不熟而走错路。预期功能安全就是确保这个司机在“所有他能遇到的路况下”都能正确驾驶。
个人经验：我在做ADAS项目时，遇到过最典型的SOTIF问题——一个毫米波雷达在隧道出口处，因为多径反射，把静止的护栏识别成了移动车辆。雷达没坏，算法也没错，但结果就是误触发紧急制动。这就是典型的预期功能安全问题。
| 对比维度 | 功能安全（ISO 26262） | 预期功能安全（ISO 21448） |
|---|---|---|
| 关注对象 | 系统内部故障 | 系统性能局限 + 环境干扰 |
| 典型问题 | 传感器失效、代码bug、芯片锁死 | 传感器感知盲区、算法误判、恶劣天气 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、HARA扩展、场景分析 |
| 安全目标 | 避免因故障导致危害 | 避免因功能不足导致危害 |
1.3 SOTIF（ISO 21448）简介——从“没坏”到“靠谱”
ISO 21448，也就是SOTIF标准，是2019年才正式发布的。它专门针对L2级以上自动驾驶系统。为什么？因为L2以上，系统开始承担部分驾驶任务，但又不完全可靠。
SOTIF的核心思想是：系统没坏，不代表它安全。
它把系统的运行状态分成了四个区域：
- 已知安全场景：系统能正确处理，且我们知道它能正确处理。
- 已知不安全场景：系统会出错，且我们知道它会出错。比如我们知道摄像头在强光下会过曝。
- 未知不安全场景：系统会出错，但我们还不知道。这是最危险的区域。
- 未知安全场景：系统能正确处理，但我们还没验证过。
SOTIF的目标，就是不断缩小“未知不安全场景”这个区域。说白了，就是通过大量的测试、仿真、场景分析，把那些“我们不知道系统会搞砸”的情况，变成“我们知道系统会搞砸”的情况，然后去修复它。
避坑指南：我曾经在一个项目中，团队花了大量时间做功能安全分析，但忽略了SOTIF。结果在实车测试时，一个简单的“雨天夜间”场景就让系统崩溃了。从那以后，我养成了一个习惯：做安全分析时，先问自己一句——“这个场景下，系统没坏，但它能正常工作吗？”
1.4 本章知识体系总览
为了让大家更直观地理解这三者之间的关系，我画了一张图：
这张图很清楚地展示了：功能安全和预期功能安全，就像一枚硬币的两面。一个管“坏了怎么办”，一个管“没坏但不行怎么办”。两者缺一不可。
总结一下：
- ISO 26262：系统内部故障 → 功能安全
- ISO 21448：系统性能局限 + 环境干扰 → 预期功能安全
- 两者结合，才能覆盖完整的汽车安全风险
嗯，这一章的内容就到这里。我个人觉得，理解这两个标准的区别和联系，是做好安全架构设计的第一步。很多项目出问题，根源就在于“只做了功能安全，没做SOTIF”，或者反过来。记住，安全不是二选一，而是都要做。