1. 功能安全概述：ISO 26262标准背景、ASIL等级定义、功能安全生命周期
各位工程师朋友，欢迎来到《车规级软件功能安全设计实战》的第一章。
说实话，我刚入行那会儿，对功能安全也是一头雾水。觉得不就是写代码吗？加几个检查不就行了？直到有一次，我负责的一个EPS项目在台架上复现了转向助力异常中断——嗯，从那以后，我再也不敢小看功能安全了。
这一章，我们先打好地基。把ISO 26262的来龙去脉、ASIL等级怎么定、整个生命周期长什么样，一次性讲清楚。
1.1 ISO 26262标准背景
为什么会有ISO 26262？说白了，汽车电子系统越来越复杂，一个软件bug可能导致车毁人亡。传统质量管理管不住这种系统性失效。
ISO 26262脱胎于工业功能安全标准IEC 61508，2011年发布第一版，2018年更新到第二版。它专门针对道路车辆电子电气系统，覆盖从概念到报废的全链条。
我个人习惯把ISO 26262理解成一套「风险管控方法论」。它不告诉你具体怎么写代码，但告诉你：
- 风险有多高，你就得做多严的防护
- 每个开发阶段必须产出什么证据
- 怎么证明你的系统是安全的
核心思想： 功能安全不是「不出错」，而是「出错后系统仍然安全」。
1.2 ASIL等级定义
ASIL（Automotive Safety Integrity Level）是ISO 26262里最核心的概念之一。它把风险分成四个等级：
| ASIL等级 | 风险程度 | 典型系统举例 | 我的经验 |
|---|---|---|---|
| ASIL A | 低 | 尾灯控制 | 一般做点诊断就够了 |
| ASIL B | 中 | 雨刮控制、车窗 | 需要一定的冗余设计 |
| ASIL C | 高 | 制动辅助、ACC | 软硬件都要认真对待 |
| ASIL D | 最高 | 线控制动、转向 | 我做过最严苛的项目 |
ASIL等级怎么定的？看三个参数：
- 严重度（Severity）：出事后人受伤多严重？S0~S3
- 暴露率（Exposure）：危险场景出现的频率？E0~E4
- 可控性（Controllability）：驾驶员能避免事故吗？C0~C3
举个例子：线控制动失效，严重度S3（可能致命），暴露率E4（每次开车都可能用到），可控性C3（普通人很难应对）。查表——ASIL D。
避坑指南： 我曾经见过一个团队把ASIL B的项目按ASIL D做，结果开发成本翻了三倍，交付延期半年。ASIL等级不是越高越好，够用就行。反过来，ASIL D的项目按ASIL B做，那叫玩火。
1.3 功能安全生命周期
ISO 26262把整个开发过程组织成一个生命周期模型。我把它分成三大阶段：
- 概念阶段：定义系统、识别风险、制定安全目标
- 产品开发阶段：从系统级到硬件级、软件级，逐层实现安全要求
- 生产与运维阶段：量产后的监控、维护、报废
下面这张图是我自己画的，把整个生命周期串起来了：
1.4 我的实战体会
做了这么多年功能安全，我有几点体会想分享：
- 别把ASIL等级当摆设：你想想看，ASIL D的项目如果只做ASIL B的测试覆盖，出了事谁负责？
- 生命周期不是瀑布模型：虽然图上画的是从左到右，但实际项目里经常要来回迭代。我见过最夸张的项目，安全目标改了六版。
- 文档不是负担：很多人觉得写安全文档是浪费时间。其实文档是保护你的证据——万一出了事故，你能证明自己按规范做了。
重要提醒： 功能安全不是「做完测试就完事」。生命周期最后阶段——生产与运维——往往被忽视。我曾经参与过一个项目，量产半年后发现了新的失效模式，因为没有建立现场监控机制，差点酿成大祸。
好了，这一章的内容就到这里。ISO 26262的背景、ASIL等级、生命周期，这三个概念是整个课程的地基。后面的章节，我们会一步步深入每个阶段的具体做法。