1. 功能安全概述
大家好，我是这次课程的主讲。咱们直接进入正题——功能安全。
说实话，我做了十几年功能安全，每次给新人讲这个概念，大家第一反应都是：「安全？不就是不出事故吗？」嗯，对，但不全对。咱们得把「安全」这两个字掰开揉碎了看。
1.1 功能安全的定义
先给个官方定义。ISO 26262 里说：功能安全是「不存在由电子电气系统故障行为导致的不可接受风险」。
这句话有点绕，我拆开讲。
- 「不存在」——不是绝对安全，而是风险可接受
- 「电子电气系统」——咱们搞的就是这个，机械、液压不算
- 「故障行为」——系统坏了、出错了、乱动了
- 「不可接受风险」——说白了，就是别死人、别重伤
我个人习惯用一个例子来解释：你开车时踩刹车，刹车系统必须能停下来。如果刹车失灵了，车停不住，这就是「故障行为」。如果这个故障导致撞人了，那就是「不可接受的风险」。功能安全要做的，就是确保刹车失灵的概率低到可以接受。
核心一句话：功能安全 = 系统出故障时，依然能保证安全。
1.2 发展历程
功能安全不是凭空冒出来的。我入行时，前辈们还在用 IEC 61508 这个通用标准。后来汽车行业越做越复杂，才专门搞了 ISO 26262。
简单梳理一下时间线：
| 时间 | 事件 | 说明 |
|---|---|---|
| 1998年 | IEC 61508 发布 | 功能安全的「老祖宗」，覆盖所有行业 |
| 2011年 | ISO 26262 第一版 | 专门针对汽车，从 IEC 61508 衍生而来 |
| 2018年 | ISO 26262 第二版 | 增加了半导体、摩托车等内容 |
| 2021年 | ISO 21448（SOTIF）发布 | 预期功能安全，咱们后面会讲 |
我记得刚做第一个功能安全项目时，用的是 IEC 61508。那时候汽车电子还没这么复杂，一个 ABS 控制器就够折腾半年。现在呢？一个智能驾驶域控制器，光安全需求就几百条。时代变了。
1.3 核心目标：避免不可接受的风险
功能安全的核心目标，说白了就四个字：别出人命。
但「不可接受」怎么定义？这得看场景。
- 一个车载娱乐系统死机了，最多是用户骂两句——风险可接受
- 一个刹车系统失效了，可能车毁人亡——风险不可接受
所以功能安全不是让系统永远不出错，而是让「可能导致严重后果的故障」发生概率足够低。
避坑指南：我曾经见过一个团队，把所有故障都当成大事来搞，结果项目延期半年。记住：功能安全只关注「不可接受的风险」。那些小毛病、小故障，交给质量部门去管。
怎么量化这个「概率」？ISO 26262 引入了 ASIL 等级（Automotive Safety Integrity Level）。从 A 到 D，D 是最严格的。你想想看，一个安全气囊的 ASIL 等级肯定是 D，而一个车窗升降可能只是 A 甚至 QM（质量管理即可）。
1.4 与预期功能安全的区别
这个问题，我每次讲课都会被问到。很多人搞混这两个概念，其实很简单。
功能安全（Functional Safety）：系统本身出故障了，怎么办？
预期功能安全（SOTIF）：系统没坏，但功能本身有局限性，怎么办？
举个例子：
- 自动驾驶的摄像头被泥巴糊住了，导致没识别到行人——这是预期功能安全的问题。摄像头没坏，但环境限制了它的能力。
- 摄像头电路板短路了，画面全黑——这是功能安全的问题。硬件故障了。
我做过一个项目，客户抱怨说：「我们的系统明明通过了 ISO 26262 认证，怎么还会出事故？」后来一查，是传感器在暴雨天性能下降，系统没做降级处理。这就是典型的预期功能安全问题。
注意：ISO 26262 管的是「系统坏了怎么办」，ISO 21448（SOTIF）管的是「系统没坏但不够聪明怎么办」。两者缺一不可。尤其是现在智能驾驶越来越普及，SOTIF 的重要性甚至超过了传统功能安全。
嗯，这里要注意一点：两个标准不是互斥的，而是互补的。一个完整的系统安全方案，既要考虑功能安全（故障处理），也要考虑预期功能安全（功能局限）。
好了，第一章就到这里。咱们把功能安全的定义、发展历程、核心目标，以及和 SOTIF 的区别都捋了一遍。下一章，我会带大家深入 ASIL 等级和危害分析，那是写安全需求的基础。