1. ISO26262概述：功能安全的历史背景、ISO26262的诞生与演变、标准的核心目标与适用范围
1.1 为什么我们需要功能安全？
说实话，我刚入行那会儿，对功能安全这事儿真没太当回事。
那时候做嵌入式开发，脑子里想的全是「功能能不能跑起来」、「性能够不够快」。至于安全？嗯，那是硬件工程师该操心的吧？
直到有一次，我参与的一个项目出了点小状况——一个简单的刹车信号因为电磁干扰被误读了。幸好是在测试阶段，没有造成实际事故。但那次之后，我整个人都变了。
你想想看，一个刹车信号出错，后果是什么？
这就是功能安全要解决的问题。它不是说「你的产品会不会坏」，而是说「你的产品坏了之后，会不会伤人」。
核心区别：
- 传统可靠性：产品别坏，坏了就是故障
- 功能安全：产品可以坏，但坏了不能伤人
1.2 功能安全的历史背景
功能安全这个概念，其实是被「逼」出来的。
上世纪七八十年代，电子系统开始大规模进入工业控制和汽车领域。那时候大家都很兴奋——电子控制多精准啊，比机械强多了。
但问题也随之而来。
我记得看过一份资料，1985年到1995年这十年间，全球因为电子系统故障导致的重大工业事故就有十几起。最典型的是1986年的切尔诺贝利核事故，虽然主要原因不是电子系统，但安全系统的设计缺陷暴露了功能安全标准的缺失。
汽车领域也一样。随着ABS、安全气囊、电子油门这些系统普及，大家发现一个问题：
机械系统坏了，你还能感觉到（比如刹车变软）。电子系统坏了，可能连个提示都没有。
这就很可怕了。
于是，各个行业开始制定自己的安全标准：
| 年份 | 标准/事件 | 说明 |
|---|---|---|
| 1998年 | IEC 61508 发布 | 通用功能安全标准，所有行业的基础 |
| 2000年 | MISRA C 发布 | 汽车行业C语言编码规范 |
| 2005年 | ISO 26262 启动 | 基于IEC 61508的汽车专用标准 |
| 2011年 | ISO 26262 第一版发布 | 覆盖乘用车，最高ASIL D |
| 2018年 | ISO 26262 第二版发布 | 扩展到卡车、摩托车、半导体 |
1.3 ISO26262的诞生与演变
ISO26262 说白了，就是汽车行业的「安全驾照」。
它脱胎于IEC 61508这个通用标准，但针对汽车的特点做了大量定制。为什么？因为汽车和工厂里的设备不一样：
- 汽车是批量生产的，成本敏感
- 汽车的使用环境极其恶劣（-40°C到125°C，振动，电磁干扰）
- 汽车的使用寿命长（10-15年）
- 汽车出事故的后果严重（可能涉及多人伤亡）
2011年第一版发布的时候，主要覆盖的是乘用车，也就是我们开的私家车。当时我正好在做一个EPS（电动助力转向）项目，标准刚出来，整个团队都懵了——这玩意儿怎么落地？
说实话，那段时间挺痛苦的。没有工具链支持，没有成熟的流程，大家都是摸着石头过河。我印象最深的是，光一个「安全分析」的模板，我们就改了七八版。
到了2018年，第二版出来了。这次扩展了不少：
- 覆盖了卡车、公交车、摩托车
- 专门增加了半导体的章节（这个太重要了，后面会细讲）
- 对「安全案例」的要求更明确了
- 引入了「安全导向的分析」概念
我个人习惯：看标准的时候，别死磕第一版的内容。第二版在很多地方做了澄清和优化，直接学第二版就好。但要注意，有些客户可能还在用第一版做认证，这时候你得两边都懂。
1.4 标准的核心目标
ISO26262 的核心目标，用一句话说就是：
把电子电气系统的故障风险降低到可接受的水平。
这里有两个关键词：
- 故障：包括系统性故障（设计错误）和随机硬件故障（器件老化、短路等）
- 可接受：不是零风险，而是风险足够低
怎么衡量「可接受」？标准引入了ASIL（汽车安全完整性等级）的概念：
| ASIL等级 | 严重度 | 暴露概率 | 可控性 | 典型应用 |
|---|---|---|---|---|
| ASIL A | 轻伤 | 低 | 容易控制 | 尾灯 |
| ASIL B | 轻伤~重伤 | 中 | 一般 | 仪表盘 |
| ASIL C | 重伤~致命 | 高 | 困难 | 自适应巡航 |
| ASIL D | 致命 | 高 | 不可控 | 刹车、转向 |
| QM | 无安全要求，按普通质量管理即可 | |||
嗯，这里要注意：ASIL D 不是「最高安全等级」这么简单。它意味着——如果这个功能出故障，大概率会死人，而且驾驶员完全没办法补救。
我曾经参与过一个ASIL D的线控制动项目。那压力，真不是开玩笑的。每次代码评审，安全工程师都坐在旁边，眼睛瞪得跟铜铃一样。
1.5 适用范围
ISO26262 适用于什么？标准里写得很清楚：
- 适用对象：安装在量产道路车辆上的E/E系统
- 适用阶段：从概念阶段到退役的全生命周期
- 适用技术：电气、电子、软件、可编程逻辑器件
但实际工作中，你会发现它的影响范围远不止这些：
避坑指南：我曾经见过一个团队，觉得「我们只做软件，硬件是别人的事，所以ISO26262跟我们没关系」。结果项目做到一半，客户要求提供软件的安全分析文档，整个团队加班两个月才补上。
记住：ISO26262覆盖的是整个系统，包括软件、硬件、系统集成、生产、运维。谁也别想甩锅。
另外，第二版明确把以下内容纳入了范围：
- 半导体器件（MCU、SoC、传感器、执行器）
- 摩托车
- 卡车、公交车
- 功能安全相关的AI/机器学习（这个还在发展中）
说白了，只要你的代码跑在汽车上，只要你的芯片装进了车里，你就得懂ISO26262。
1.6 我的几点体会
做了这么多年功能安全，我有几点体会想分享：
- 别把标准当圣经。标准是工具，不是目的。你的目的是造出安全的车，不是造出符合标准的文档。
- 安全是设计出来的，不是测试出来的。等到测试阶段才发现安全问题，成本至少翻10倍。
- 流程很重要，但别为了流程而流程。我见过有的团队，安全文档写了一堆，代码里该有的保护一个没有。这有什么意义？
好了，这一章就到这里。下一章我们会深入聊聊ISO26262的框架结构和核心概念，包括那个让很多人头疼的「V模型」到底是怎么回事。
咱们下章见。