1. 功能安全与预期功能安全概述
大家好，我是老张。在汽车电子这行摸爬滚打了十几年，今天咱们来聊聊功能安全和预期功能安全。这两个概念，说白了就是汽车安全的「两条腿」。缺了哪条，车都跑不稳。
1.1 功能安全（ISO 26262）的起源
功能安全这个概念，其实不是汽车行业原创的。它最早来自工业控制领域。我记得2000年左右，我还在做工业PLC的时候，就接触过IEC 61508这个标准。后来汽车电子越来越复杂，尤其是线控系统、ADAS这些东西出现后，行业发现必须有个专门针对汽车的标准。
于是，ISO 26262在2011年正式发布。它的核心思想很简单：系统要能正确处理随机硬件故障和系统故障。说白了，就是芯片坏了、线路断了、软件跑飞了，车还能安全停下来。
核心要点：ISO 26262关注的是「已知的危险」——也就是我们能预想到的、由硬件或软件故障导致的风险。
1.2 预期功能安全（ISO 21448）的诞生
你可能会问：那ISO 26262够用了吗？嗯，我刚开始做ADAS项目时也这么想。直到有一次，我们在高速上测试自适应巡航——传感器没坏，算法没bug，但车就是在前方有静止大货车时没刹住。为什么？因为传感器在强光下性能下降了。
这就是预期功能安全要解决的问题。ISO 21448在2022年正式发布，它关注的是：系统在「没有故障」的情况下，因为功能不足或性能局限导致的风险。比如传感器在雨雾天看不清、算法在罕见场景下误判、驾驶员过度信任系统等等。
我的经验：很多团队把ISO 26262做得很扎实，但一遇到ISO 21448就懵了。原因很简单——前者是「故障导向」，后者是「场景导向」。你没法用故障树去分析「大雾天摄像头看不清」这种问题。
1.3 核心概念对比
咱们用个表格来对比一下，这样更直观：
| 维度 | ISO 26262（功能安全） | ISO 21448（预期功能安全） |
|---|---|---|
| 关注对象 | 硬件随机故障、系统故障 | 功能不足、性能局限 |
| 典型场景 | 芯片失效、线路短路、软件死锁 | 传感器被遮挡、算法未训练的场景 |
| 分析方法 | FMEA、FTA、FMEDA | STPA、场景分析、触发条件分析 |
| 安全目标 | ASIL等级（A/B/C/D） | 可接受的风险水平 |
| 时间范围 | 全生命周期 | 运行阶段 + 功能定义阶段 |
1.4 两者的区别与联系
很多新手会问：这两个标准是不是互相替代的？绝对不是。我打个比方：
- ISO 26262 就像给车装安全带和安全气囊——防止「车坏了」导致人受伤。
- ISO 21448 就像给车装更好的刹车和转向——防止「车没坏但操作不当」导致事故。
你想想看，一辆车如果只有安全气囊，但刹车在雨天刹不住，那还是不安全。反过来，刹车再好，气囊该爆的时候不爆，也不行。
避坑指南：我曾经见过一个项目，团队把ISO 26262的ASIL等级直接套用到ISO 21448上。结果发现，很多预期功能安全的风险根本没法用ASIL来量化。比如「摄像头在逆光下性能下降30%」——这不是故障，你没法给它定ASIL等级。后来我们改用「风险可接受性」来判断，才把问题说清楚。
1.5 应用范围
这两个标准在项目中的分工是这样的：
- 功能安全（ISO 26262）：适用于所有电子电气系统。从最简单的车窗控制器，到最复杂的自动驾驶域控制器，只要涉及安全相关功能，都得做。
- 预期功能安全（ISO 21448）：主要针对L2级及以上的自动驾驶功能。因为只有这些功能才涉及「系统在正常状态下做出错误决策」的问题。
我个人习惯的做法是：在项目启动阶段，先做ISO 21448的场景分析，识别出所有可能的「功能不足」场景。然后把这些场景中涉及「硬件故障」的部分，交给ISO 26262去处理。这样两个标准就能无缝衔接。
1.6 落地实战中的常见误区
最后，我分享几个我在项目中踩过的坑：
- 误区一：以为ISO 21448是ISO 26262的「升级版」。其实它们是互补的，不是替代关系。
- 误区二：把ISO 21448的分析结果直接写成安全需求。实际上，ISO 21448的输出更多是「设计改进建议」和「验证策略」。
- 误区三：忽略「人因工程」。预期功能安全里，驾驶员的行为模型非常关键。我曾经有个项目，系统设计得完美无缺，但驾驶员在紧急情况下总是误操作——这就是典型的预期功能安全问题。
我的建议：刚开始做这两个标准时，别贪多。先从一个功能模块入手，比如自动紧急制动（AEB）。把ISO 26262的故障分析和ISO 21448的场景分析都跑一遍。等流程跑通了，再扩展到整个系统。这样既不会漏掉关键点，也不会被庞大的标准体系吓到。
好了，第一章就聊到这儿。下一章咱们深入讲讲ISO 26262的ASIL等级到底怎么定，以及我在实际项目中是怎么「讨价还价」的。嗯，到时候见。