1. ISO26262 概述与功能安全基础
各位工程师朋友，咱们今天聊聊功能安全。说实话，我刚入行那会儿，觉得功能安全就是一堆文档活儿，跟技术关系不大。直到有一次，我在一个ADAS项目中亲眼看到，因为一个不起眼的时序错误，系统在高速上误触发了紧急制动——幸好那是测试车。从那以后，我对ISO26262的态度彻底变了。
这一章，咱们把地基打牢。功能安全不是什么玄学，它是一套系统性的工程方法。说白了，就是回答三个问题：系统会出什么错？出错了后果多严重？怎么防止或控制这些错？
1.1 功能安全概念：到底在防什么？
ISO26262对功能安全的定义很严谨：不存在由电子电气系统故障行为导致的不可接受风险。翻译成人话就是——车子不能因为电子系统抽风而害人。
这里有两个关键点：
- 故障行为：系统没按设计意图干活。比如该刹车时没刹，或者不该刹时乱刹。
- 不可接受风险：不是所有故障都要命。车窗升降失灵算故障，但不会直接导致伤亡，风险可接受。转向助力突然消失，那就严重了。
核心原则：功能安全不追求“零故障”，那不可能。它追求的是“故障发生时，危害被控制在可接受范围内”。
我个人习惯把功能安全理解成一套防御体系。就像建筑里的消防系统——你没法保证永远不起火，但你可以保证起火时喷淋系统能工作、逃生通道能通行。汽车电子也一样，我们设计安全机制，不是为了阻止故障发生（虽然部分机制确实能预防），而是为了在故障发生时，系统还能安全地停下来。
1.2 ASIL等级定义：风险怎么量化？
ASIL（Automotive Safety Integrity Level）是ISO26262里最核心的概念之一。它把安全需求分成四个等级：ASIL A、B、C、D，还有一个QM（Quality Management，即质量管理级）。
ASIL D是最严格的，比如刹车、转向这类系统。ASIL A相对宽松，比如雨刮器、车窗。QM就是普通质量管控，不需要额外安全措施。
ASIL等级怎么定的？看三个参数：
| 参数 | 含义 | 等级范围 |
|---|---|---|
| Severity (S) | 危害的严重程度 | S0（无伤害）~ S3（致命） |
| Exposure (E) | 危险场景发生的概率 | E0（几乎不）~ E4（非常高） |
| Controllability (C) | 驾驶员或其他人控制局面的能力 | C0（完全可控）~ C3（几乎不可控） |
ASIL等级 = f(S, E, C)。具体查标准里的表格，我直接给结论：
- S3 + E4 + C3 → ASIL D（最严）
- S2 + E3 + C2 → ASIL B（中等）
- S1 + E2 + C1 → ASIL A（较松）
- 其他组合 → QM 或更低等级
避坑指南：我曾经在一个项目中，团队把E参数估低了，导致ASIL等级定得太低。后期测试发现场景覆盖率不够，不得不返工。我的建议是——E参数宁可往高估，也别往低估。低估了，安全措施不够，后期补起来成本翻倍。
1.3 安全生命周期模型：从生到死的安全管控
ISO26262把安全活动贯穿整个产品生命周期，这就是安全生命周期模型。它分三个阶段：
- 概念阶段：定义系统、识别危害、制定安全目标。
- 产品开发阶段：从系统级到硬件/软件级，逐层实现安全需求。
- 生产与运维阶段：制造、测试、售后监控，直到退役。
我画了一张图，帮你直观理解这个流程：
你想想看，这个模型最妙的地方在哪？它把安全活动嵌入到了每个开发环节，而不是最后才来补安全。我见过太多项目，功能开发完了才想起来做安全分析，结果发现架构不支持，推倒重来。那成本，啧啧。
1.4 安全生命周期中的关键角色
在实际项目中，安全生命周期不是一个人能搞定的。我列一下常见的角色和职责：
| 角色 | 主要职责 | 常见误区 |
|---|---|---|
| 功能安全经理 | 统筹安全活动、审核交付物、管理安全档案 | 以为安全只是文档工作，忽略技术落地 |
| 系统工程师 | 定义安全目标、分解安全需求、做系统级FMEA/FTA | 安全需求写得太抽象，下级无法实现 |
| 硬件工程师 | 实现硬件安全机制（如看门狗、冗余设计） | 忽略随机硬件故障的定量分析 |
| 软件工程师 | 实现软件安全机制（如ECC、双核锁步） | 安全代码和功能代码混在一起，不好维护 |
| 测试工程师 | 验证安全机制、做故障注入测试 | 只测正常功能，不测故障场景 |
重要提醒：安全生命周期不是瀑布模型，它允许迭代。比如你在硬件开发阶段发现某个安全目标实现不了，可以回到概念阶段重新评估。但迭代要有记录，不能偷偷改。我见过有人直接改安全目标文档，没走变更流程，结果审核时被开了严重不符合项。
1.5 本章小结：你该带走什么？
好，咱们捋一下这一章的核心：
- 功能安全不是消灭故障，而是把风险控制在可接受范围。
- ASIL等级由S、E、C三个参数决定，等级越高，开发要求越严。
- 安全生命周期覆盖从概念到退役的全过程，每个阶段都有明确的安全活动。
下一章，咱们会深入危害分析与风险评估（HARA），那是ASIL等级落地的第一步。我会拿一个真实案例，带你一步步做HARA。到时候你就知道，那些参数到底怎么填、填错了会有什么后果。
今天就到这儿。记住一句话：安全不是成本，是设计的一部分。咱们下章见。