功能安全基础：ISO 26262概述、ASIL等级定义、功能安全生命周期
大家好，我是这次课程的主讲工程师。咱们直接进入正题——功能安全。说实话，我刚入行那会儿，觉得这东西就是一堆文档和流程，烦得很。直到有一次，我在一个ADAS项目里亲眼看到，因为一个不起眼的软件bug，系统在高速上突然误刹车……嗯，从那以后，我对功能安全的态度彻底变了。
今天这一章，咱们把最基础的东西捋清楚。说白了，就是搞清楚三个问题：ISO 26262是什么？ASIL等级怎么定？功能安全生命周期怎么走？
一、ISO 26262：汽车功能安全的“宪法”
ISO 26262，全称是“道路车辆——功能安全”。它源自工业界的IEC 61508，但专门为汽车行业量身定制。你想想看，一辆车上几十个ECU，几百个传感器，万一哪个模块乱来，后果不堪设想。
我个人习惯把ISO 26262理解成一套“防错机制”。它不保证你的产品不出错，但保证出错之后，系统还能安全地停下来，或者把风险降到最低。
核心思想： 功能安全不是消除故障，而是控制风险。
我记得2018年做某个L2级自动驾驶项目时，客户要求必须满足ISO 26262 ASIL B。当时团队里有人觉得“差不多就行”，结果审核时被开了十几个不符合项。从那以后，我再也不敢对标准打折扣了。
二、ASIL等级：风险有多高，安全就得有多严
ASIL，全称Automotive Safety Integrity Level，汽车安全完整性等级。它分四个等级：A、B、C、D。A最低，D最高。怎么定的？看三个参数：
- Severity（严重度）：出事后对人的伤害有多大？轻伤？重伤？致命？
- Exposure（暴露率）：这个危险场景出现的概率高不高？天天遇到？一年一次？
- Controllability（可控性）：驾驶员或周围人能不能在危险发生前控制住局面？
这三个参数组合起来，查表就能得到ASIL等级。举个例子：
| 参数 | 示例场景：刹车失灵 | 等级 |
|---|---|---|
| Severity | 高速下刹车失灵 → 可能致命 | S3 |
| Exposure | 每天都会用到刹车 | E4 |
| Controllability | 驾驶员几乎无法控制 | C3 |
| 结果 | ASIL D |
为什么会这样？因为刹车一旦失效，后果太严重了。所以ASIL D要求最严格，从开发到测试，每一步都得有证据。
避坑指南： 我曾经见过一个项目，把ASIL B的功能错误地按ASIL A来开发，结果测试时发现覆盖率根本不够，最后不得不返工。记住：ASIL等级不是拍脑袋定的，必须基于危害分析和风险评估（HARA）。
三、功能安全生命周期：从概念到退役
ISO 26262把整个开发过程分成几个阶段，我习惯叫它“安全生命周期”。说白了，就是告诉你什么时候该做什么事。
主要阶段包括：
- 概念阶段：定义功能、识别危险、确定ASIL等级。
- 系统级开发：设计系统架构，分配安全需求。
- 硬件级开发：硬件设计、FMEDA、故障注入测试。
- 软件级开发：软件架构、单元测试、集成测试。
- 生产与运维：确保量产后的安全一致性。
- 退役：产品生命周期结束时的安全处理。
你想想看，这就像盖房子。先画图纸（概念），再打地基（系统），然后砌墙（硬件），最后装修（软件）。每一步都不能跳，跳了就得返工。
注意： 很多团队在“概念阶段”草草了事，觉得“先干再说”。我踩过这个坑——项目做到一半，发现安全目标没定义清楚，结果所有测试用例都得重写。嗯，那滋味不好受。
四、我的实战建议
讲完理论，说点实在的。如果你刚开始接触功能安全，我建议你从这三件事入手：
- 先做HARA：别急着写代码，先把危险场景列清楚。ASIL等级定了，后面的事才有方向。
- 文档要跟上：ISO 26262很看重证据。你做了测试，就得有测试报告；你做了分析，就得有分析文档。别偷懒。
- 故障注入要早做：别等到系统集成完了才想起测安全机制。我在项目中吃过这个亏——硬件都定型了，才发现安全机制覆盖不到某个故障模式，改起来成本巨大。
好了，这一章就到这里。下一章咱们聊聊故障注入的具体方法，包括怎么设计故障列表、怎么选择注入点。到时候我会拿一个实际项目案例来拆解，保证干货满满。
一句话总结： ISO 26262是规矩，ASIL是尺度，生命周期是路线图。这三样搞懂了，功能安全就算入门了。