1. 功能安全概述：ISO 26262标准背景、功能安全定义、ASIL等级概念、功能安全开发流程总览
1.1 为什么会有ISO 26262？——标准背景
说起功能安全，得先聊聊它的“出身”。
早些年，汽车电子没这么复杂。一个ECU管一个功能，坏了就坏了，大不了车不动。但后来不行了——电子系统越来越多，线控转向、自动刹车、智能驾驶……这些系统一旦出问题，就不是“车不动”那么简单了。
我记得2010年左右，我参与过一个项目。客户反馈说某款车的ACC（自适应巡航）在高速上突然失效，差点追尾。排查下来，是软件里一个计数器溢出导致的。你说这是软件bug？对。但更深层的问题是——整个开发流程里，没人想过“如果这个计数器溢出了会怎样”。
这就是功能安全要解决的核心问题：不是保证系统不出错，而是保证系统出错时，后果可控。
ISO 26262就是在这样的背景下诞生的。它脱胎于工业领域的IEC 61508，专门针对道路车辆。2011年发布第一版，2018年更新到第二版。现在，几乎所有主流车厂和Tier 1都要求供应商通过ISO 26262认证。
核心观点：ISO 26262不是教你如何造一个“永不失效”的系统，而是教你如何系统性地管理风险。说白了，就是“万一出事了，别死人”。
1.2 功能安全到底在说什么？——定义
官方定义是这样的：不存在由电子电气系统功能异常导致的不可接受风险。
嗯，有点绕。我换个说法。
你想想看，一个刹车系统，它的“功能”是什么？是让车停下来。那“功能安全”是什么？是当刹车系统本身出故障时——比如传感器坏了、软件跑飞了、电源断了——车依然能安全停下来，或者至少不会造成危险。
我习惯把功能安全分成两层理解：
- 第一层：系统正常工作时，别因为设计缺陷导致危险。比如，你设计了一个自动门，逻辑是“检测到障碍物就停止关闭”。但如果传感器被遮挡了，门继续关，夹到人了——这就是功能安全问题。
- 第二层：系统出故障时，要有“兜底”机制。比如，主传感器坏了，备用传感器顶上；或者软件检测到异常，主动进入安全状态（比如切断动力输出）。
我在项目中遇到过不少工程师，觉得功能安全就是“加一堆冗余硬件”。其实不是。冗余只是手段之一，更重要的是识别风险、定义安全目标、然后针对性地设计安全机制。
个人经验：刚开始做功能安全时，我总想着“把所有可能的故障都防住”。后来发现不现实——成本、时间、复杂度都不允许。真正的做法是：先识别哪些故障会导致严重危害，然后集中资源去处理这些“关键少数”。
1.3 ASIL等级——你的系统有多“危险”？
ASIL，全称是Automotive Safety Integrity Level，汽车安全完整性等级。它用来衡量一个系统或功能的安全风险等级。
ASIL分四个等级：A、B、C、D。A是最低，D是最高。还有一个QM（Quality Management），意思是“不需要额外安全措施，按质量管理做就行”。
怎么确定ASIL等级？看三个因素：
| 因素 | 说明 | 等级（从低到高） |
|---|---|---|
| 严重度（Severity） | 故障发生后，对人员伤害的严重程度 | S0（无伤害）→ S3（致命） |
| 暴露率（Exposure） | 故障发生时，人员处于危险场景的概率 | E0（几乎不）→ E4（非常高） |
| 可控性（Controllability） | 驾驶员或其他人员能否控制住危险 | C0（完全可控）→ C3（几乎不可控） |
举个例子。电动助力转向系统：如果转向突然失效，严重度很高（S3），暴露率也高（E4，你每次开车都可能遇到），可控性低（C3，高速上转向失效很难控制）。所以转向系统通常是ASIL D。
再比如，车窗升降：如果夹到人，严重度不高（最多疼一下，S1），暴露率中等（E2），可控性高（C1，你可以松手）。所以车窗升降通常是ASIL A甚至QM。
注意：ASIL等级不是一成不变的。同一个功能，在不同车型、不同使用场景下，等级可能不同。我曾经见过一个项目，把某个功能定为ASIL B，结果客户要求升级到ASIL D——因为他们的车型有自动驾驶功能，风险场景变了。
1.4 功能安全开发流程总览——从概念到量产
ISO 26262把开发流程分成了几个阶段。我习惯把它想象成一条流水线：
- 概念阶段：定义系统、识别功能、分析风险、确定安全目标。这个阶段产出的是“我们要做什么”。
- 系统级开发：把安全目标分解到系统架构中，定义安全机制、分配ASIL等级。这个阶段产出的是“系统怎么设计”。
- 硬件级开发：设计硬件电路、选型、做FMEDA（失效模式影响与诊断分析）。这个阶段产出的是“硬件怎么实现”。
- 软件级开发：写代码、做单元测试、集成测试。这个阶段产出的是“软件怎么实现”。
- 生产与运维：确保量产后的产品依然符合安全要求，以及如何处理售后反馈。
每个阶段都有对应的安全活动和安全文档。比如：
- 概念阶段要做HARA（危害分析与风险评估）
- 系统阶段要做FTA（故障树分析）或FMEA（失效模式与影响分析）
- 硬件阶段要做FMEDA
- 软件阶段要做单元测试、覆盖率分析
嗯，这里要注意：文档不是摆设。我见过不少团队，为了过审核，临时补文档。结果审核员一问细节，答不上来。功能安全的核心是“过程可追溯”——你做的每一步，都要有记录、有理由、有证据。
我的建议：不要等到项目快结束了才想起功能安全。从需求阶段就把它嵌进去。否则后面返工的成本，会让你哭都哭不出来。
1.5 一个小总结
这一章我们聊了：
- ISO 26262的由来——因为汽车电子越来越复杂，故障后果越来越严重
- 功能安全的定义——不是不出错，而是出错时后果可控
- ASIL等级——通过严重度、暴露率、可控性三个维度来评估风险
- 开发流程总览——从概念到量产，每个阶段都有对应的安全活动
下一章，我们会深入概念阶段，聊聊怎么做HARA、怎么定义安全目标。这些东西听起来抽象，但做起来很有意思——你想想看，一个刹车系统，你分析完它的所有失效模式后，会发现原来有这么多“隐藏的坑”。
我曾经在一个项目里，因为HARA做得不够细，漏掉了一个“电源瞬断”的场景。结果实车测试时，系统在颠簸路面偶发重启……嗯，从那以后，我再也不敢跳过任何一步了。
课后思考：你手头的项目里，哪个功能你觉得风险最高？试着用S、E、C三个维度给它打个分，看看它应该是什么ASIL等级。