第1章：功能安全概述
1.1 ISO 26262标准介绍
ISO 26262，这个名字做汽车电子的朋友应该都不陌生。它全称叫「道路车辆功能安全标准」，2011年首次发布，2018年更新了第二版。说白了，它就是一套方法论，教你怎么把电子电气系统的风险降到可接受的水平。
我个人习惯把ISO 26262理解成一本「安全设计手册」。它覆盖了从概念设计、系统开发、硬件软件设计，到生产、运行、报废的全生命周期。你想想看，一辆车上几百个ECU，几十万行代码，如果没有统一的安全标准，谁敢上路？
我在项目中遇到过不少团队，觉得ISO 26262就是一堆文档模板。其实不然。它的核心是让你系统地思考：系统可能出什么错？出错了会怎样？怎么防止或处理？
关键点：ISO 26262不是束缚，而是帮你建立安全设计思维的框架。
1.2 功能安全的基本概念
功能安全，说白了就是「系统在出现故障时，依然能保证安全」。注意，这里说的不是系统不出错，而是出错后不会造成危害。
举个例子：刹车系统。如果刹车踏板踩下去没反应，这是故障。但如果系统检测到故障后，自动切换到备用回路，让刹车还能用——这就是功能安全在起作用。
几个核心概念，我简单列一下：
- 故障（Fault）：系统内部的缺陷，比如代码bug、硬件老化
- 错误（Error）：故障导致的不正确状态，比如内存里存了个错误值
- 失效（Failure）：错误传递到外部，导致系统行为偏离预期
嗯，这里要注意：故障是原因，失效是结果。我们做功能安全，目标就是在故障演变成失效之前，把它抓住。
我的经验：很多新手容易把故障和失效混为一谈。记住一句话——故障是内部的，失效是外部的。你排查问题时，先问自己：这是内部原因还是外部表现？
1.3 ASIL等级定义与分解
ASIL，全称Automotive Safety Integrity Level，汽车安全完整性等级。它分四个等级：A、B、C、D。D是最严格的，A是最宽松的。
怎么确定ASIL等级？看三个因素：
- 严重度（Severity）：出事后对人伤害有多重？轻伤、重伤、致命？
- 暴露率（Exposure）：这种情况发生的概率高不高？
- 可控性（Controllability）：驾驶员能不能在出事前控制住局面？
这三个因素组合起来，查表就能得到ASIL等级。举个例子：
| 严重度 | 暴露率 | 可控性 | ASIL等级 |
|---|---|---|---|
| S3（致命） | E4（极高） | C3（难控制） | ASIL D |
| S1（轻伤） | E2（中等） | C1（易控制） | ASIL A |
ASIL分解是怎么回事？我举个例子你就明白了。
假设一个功能要求ASIL D。你可以把它拆成两个独立的子功能，每个承担ASIL C(D)。注意写法：ASIL C(D)表示这个子功能虽然只要求ASIL C，但它必须满足ASIL D的独立性要求。
核心原则：分解后的子功能必须相互独立。不能一个挂了，另一个也跟着挂。否则分解无效。
我曾经在一个项目中，看到团队把ASIL D的功能分解成两个ASIL B，然后说「够了」。我一看，两个子功能共用同一个电源芯片。这哪行？一个电源失效，两个都完蛋。这就是典型的分解陷阱。
避坑指南：我曾经见过一个项目，ASIL分解时只考虑了功能独立性，忽略了时序独立性。结果两个子功能在同一个CPU核上跑，一个死循环，另一个也跟着卡死。记住：独立性要覆盖硬件、软件、时序、资源所有维度。
1.4 我的个人建议
学功能安全，别一上来就啃标准原文。先理解几个核心概念：
- 安全目标：系统要避免什么危险？比如「防止非预期加速」
- 安全状态：出问题后，系统应该进入什么状态？比如「切断动力输出」
- 故障容错时间间隔：从故障发生到进入安全状态，允许的最长时间
这三个概念，你搞清楚了，后面学ASIL分解、安全机制设计，都会顺很多。
嗯，今天就先聊到这。下一章我们讲功能安全管理，包括安全计划、安全案例、评审流程这些。到时候我会分享一些我在项目里踩过的坑，保证实用。
一句话总结：功能安全不是写文档，是设计思维。ASIL等级不是目标，是约束。分解不是偷懒，是策略。