1. 功能安全概述：ISO26262 标准背景、道路车辆功能安全的重要性、功能安全与预期功能安全(SOTIF)的区别
各位同学，咱们今天聊点实在的。功能安全这词儿，在汽车圈里已经火了快十年了。但说实话，真正把它吃透的人，不多。
我刚开始接触这行的时候，还在做传统嵌入式开发。那时候觉得「安全」就是代码别崩、别死机。后来有一次，我在一个ADAS项目里遇到了一个极其隐蔽的故障——传感器在特定温度下会输出一个错误值，而系统居然没有检测到。嗯，那次之后我才明白，功能安全不是锦上添花，它是底线。
1.1 ISO26262 标准的背景
ISO26262 是啥？说白了，它就是一套针对道路车辆电子电气系统的功能安全标准。它脱胎于工业领域的 IEC 61508，但专门为汽车量身定制。
为什么要有这个标准？你想想看，一辆车上现在有多少个 ECU？几十个甚至上百个。这些系统一旦出问题，轻则抛锚，重则要命。没有一套统一的方法论来管控风险，那简直是拿命在试错。
我个人习惯把 ISO26262 理解成一本「安全设计手册」。它告诉你：
- 怎么识别危险
- 怎么评估风险
- 怎么设计系统来避免或控制这些风险
- 怎么证明你的设计是有效的
标准从 2011 年发布第一版，到 2018 年第二版，覆盖的范围更广了。我记得第二版刚出来的时候，我们团队连夜开会，逐条比对差异——那叫一个酸爽。
1.2 道路车辆功能安全的重要性
咱们来聊点实际的。功能安全为什么重要？
我给你讲个真实案例。几年前，某知名车企的定速巡航系统在高速上突然失效，车辆无法减速。最后是靠驾驶员强行挂空挡、拉手刹才停下来的。事后调查发现，是一个软件计数器溢出导致的。
这种问题，放在功能安全的框架下，根本不应该出现。因为按照 ISO26262 的要求，这类关键信号的监控、冗余、故障响应，都是必须做的。
功能安全的重要性，我总结为三点：
| 维度 | 说明 |
|---|---|
| 人身安全 | 直接保护驾驶员、乘客和行人。这是最根本的。 |
| 法律责任 | 出了事故，企业要承担产品责任。功能安全是合规的底线。 |
| 品牌信誉 | 一次大规模召回，足以毁掉一个品牌多年的积累。 |
你想想看，现在自动驾驶、线控底盘、电驱系统越来越普及。这些系统一旦出问题，后果是什么？不是蓝屏重启，是车毁人亡。所以，功能安全不是「加分项」，是「必选项」。
1.3 功能安全与预期功能安全(SOTIF)的区别
这个问题，我几乎每次培训都会被问到。很多人搞不清楚功能安全（Functional Safety, FuSa）和预期功能安全（Safety of the Intended Functionality, SOTIF）到底有啥区别。
咱们用一个简单的例子来说明。
假设你设计了一个自动紧急制动系统（AEB）。
- 功能安全关心的是： 系统本身有没有故障？比如传感器坏了、软件跑飞了、通信断了。这些是「系统故障」。
- SOTIF关心的是： 系统在「没有故障」的情况下，会不会因为场景或功能本身的局限性而出问题？比如摄像头在强光下识别不到行人、系统把路边的广告牌误判为障碍物。这些是「功能不足」或「场景局限」。
我画了一张图，帮你理清这个关系：
我再给你一个更直观的对比表：
| 对比维度 | 功能安全 (FuSa) | 预期功能安全 (SOTIF) |
|---|---|---|
| 标准 | ISO 26262 | ISO 21448 |
| 关注对象 | 系统故障（硬件/软件） | 功能不足、场景局限 |
| 前提假设 | 系统可能存在故障 | 系统本身无故障 |
| 典型问题 | 传感器短路、内存溢出 | 摄像头在逆光下失效 |
| 分析方法 | FMEA、FTA、FMEDA | 触发事件分析、场景覆盖 |
| 安全等级 | ASIL A/B/C/D | 无等级，但需满足触发条件 |
1.4 本章小结
好，咱们把这一章的核心内容捋一捋：
- ISO26262 是汽车电子电气系统的功能安全标准，脱胎于 IEC 61508。
- 功能安全的重要性体现在人身安全、法律责任和品牌信誉三个层面。
- 功能安全管的是「系统故障」，SOTIF 管的是「功能不足和场景局限」，两者互补，缺一不可。