你完成了HARA，画出了安全架构，通过了FMEDA，实现了安全机制，跑完了故障注入，达到了MC/DC。所有技术工作都已就绪。但离TÜV审核员签字还剩最后一道关卡：你怎么向一个不熟悉你具体设计的人，系统地证明你的车是安全的？
这不是三言两语能说清的，而是一份活生生的档案——安全案例（Safety Case）。另一面，项目经理盯着BOM表问：“ASIL D的刹车太贵了，能不能用两个ASIL B拼一个？” 这就是 ASIL分解（ASIL Decomposition） 的两难与智慧。
第10篇，作为专栏的收尾，我们将解开这两个终极谜题：如何说服世界“我安全”，以及如何在安全与成本之间找到“突围之路”。

安全案例：论证，而非流水账

很多初入功能安全的工程师误以为，安全案例就是把所有文档堆在一起——需求规格、设计说明、测试报告……码成一堆PDF交给审核员。大错特错。 审核员没时间读几千页的流水账。他们要的是一个清晰、有逻辑、可追溯的论证：你的系统为什么安全？证据在哪里？有哪些假设？哪些未覆盖的风险？

安全案例的常见组织方式是 目标结构符号（GSN, Goal Structuring Notation） 。GSN是一个树状/网状的可视化论证模型，根节点是最终目标（如“系统在定义的使用条件下无不可接受的风险”），向下逐层分解为子目标、策略、解决方案、证据。

举个例子，一个线控制动系统的安全案例顶层结构（文字简化版）：

• G1：系统在所有可预见的故障下，不会导致非预期的制动力 > 5bar（顶层目标）
  • S1：通过架构设计实现（策略）
    • G1.1：单点故障被检测且进入安全状态（子目标）
      • Sol1.1：锁步核 + ECC + 看门狗（解决方案）
      • Ev1.1：故障注入测试报告（证据）
    • G1.2：潜在故障不会导致双重失效（子目标）
      • Sol1.2：周期性自检 + 诊断覆盖率 >90%（解决方案）
      • Ev1.2：FMEDA报告 + LFM计算（证据）
  • S2：通过软件开发流程避免系统性故障（策略）
    • G2.1：所有安全相关代码满足ASIL D编码规范（子目标）
      • Sol2.1：MISRA 2012 + 静态分析工具（解决方案）
      • Ev2.1：静态分析无违规报告（证据）
    • G2.2：软件单元测试达到100% MC/DC（子目标）
      • Ev2.2：单元测试覆盖率报告（证据）
  • A1：假设——备用电容器在-40°C下仍能供电至少200ms（假设）
    • EvA1：电容器低温特性测试报告（验证假设）
  • J1：论证完整，无未覆盖危害（已覆盖HARA中识别的所有危害事件）

GSN的精髓在于 明确假设和未覆盖项。任何安全案例都有局限性——比如你假设了供电电压不低于9V，但真实环境可能出现更低电压。你必须列出这些假设，并提供证据证明假设在真实工况下是合理的，或者说明低电压下安全目标不适用（例如车辆已经无法行驶）。

审核员会逐节点审查：论证是否完整？证据是否充分？假设是否合理？如果某个节点被判定为薄弱，整个安全案例可能被退回。因此，安全案例不是写完了就锁进柜子，而是一个动态档案，随着设计变更、新发现的失效模式不断更新。

ASIL分解：当ASIL D可以“被拆分”

如果说安全案例是“怎么证明安全”，ASIL分解就是“怎么在满足安全的前提下少花钱”。核心思想很朴素：如果一个ASIL D的安全需求可以通过两个独立且充分冗余的通道来实现，那么每个通道只需要承担ASIL B(D)或ASIL C(D)的要求。

ISO 26262-9第5章明确定义了ASIL分解的规则。用一张表格表示最常见的分解组合：

原始ASIL	分解后的冗余路径ASIL组合
ASIL D	D + D (无分解), C + C, C + B, B + B
ASIL C	C + C, C + B, B + B
ASIL B	B + B, B + A, A + A
ASIL A	A + A, A + QM, QM + QM

注意：分解后的ASIL等级会带一个后缀“(D)”表示源自ASIL D，以区别于原生ASIL B。这纯粹是追溯标记，不代表额外的技术要求。

一个经典案例：线控制动的踏板传感器

安全目标：防止制动压力非预期过大（ASIL D）。解决方案：使用两个独立的踏板行程传感器。如果采用单个ASIL D传感器，成本极高，供应商稀少。但如果我们采用两个ASIL B的传感器，并让控制器比较两者，当差异超过阈值时判定故障，那么：

• 每个传感器只需要满足ASIL B的随机失效概率（PMHF < 10⁻⁷）和开发流程。
• 两者同时输出相同错误值的概率极低（ASIL B × ASIL B ≈ ASIL D 的概率量级，精确计算需考虑共因失效）。
• 控制器内的比较逻辑本身需要ASIL D吗？不需要，因为它只是一个简单的“不一致则切安全状态”，但要注意比较器不能成为单点故障——通常由ASIL D的安全岛执行比较。

这样，整个传感器子系统的安全等级通过分解从ASIL D降级为两个ASIL B，成本大幅降低，且完全符合标准。

分解的陷阱：共因失效

ASIL分解有一个致命的弱点：如果两个冗余通道因为同一个原因同时失效，分解就失去了意义。这种情况叫做共因失效（Common Cause Failure, CCF）。例如，两个传感器共享同一个电源芯片，电源过压会导致两者同时输出错误值；或者两个通道的软件使用了同一个有bug的数学库。

ISO 26262-9要求进行共因失效分析，并提供了一套评分表（共因失效因子计算）。工程师需要从以下维度评估并采取措施：

• 物理分隔：不同PCB？不同连接器？不同供电？
• 设计多样性：不同原理（霍尔 vs 电感）？不同供应商？不同MCU型号？
• 制造独立性：不同批次？不同产线？
• 避免系统性故障：同一软件bug不能同时影响两通道。

只有CCF分析通过，分解才是有效的。否则，审核员会要求你维持原生ASIL D。

ASIL分解的实战流程

在一个真实项目中实施ASIL分解通常包括五个步骤：

① 识别可分解的安全需求
不是所有需求都能分解。只有那些可以通过“冗余+比较”实现的需求才适用。例如，“防止非预期加速”可以分解为两个通道计算扭矩限制并比较；“防止控制器着火”则很难通过冗余解决。

② 设计冗余架构
明确两个通道如何划分：是1oo2（热冗余）还是1oo2D（带诊断）？是硬件冗余、软件冗余，还是混合？

③ 为每个通道分配分解后的ASIL
根据上表选择合规的组合。通常倾向于B+B（因为ASIL B的开发成本远低于ASIL D）。

④ 执行共因失效分析
填写CCF评分表，通常要求总分 ≥ 70分（满分100）。例如：物理分隔20分、多样性30分、避免相同故障模式15分等。低于70分需要重新设计增强独立性。

⑤ 更新安全档案
在安全案例中明确标注每个安全需求是通过分解实现的，并附上冗余架构描述和CCF分析报告。

安全文化：让每个人成为“防御性悲观主义者”

技术讲完了，方法论也捋清了。但功能安全真正的“终极突围”不是靠某个公式或报告，而是靠组织的安全文化。

我曾参观过一家Tier 1的研发中心，他们的墙上贴着一张海报：“如果你不敢让它飞，就别让它上路。” 每个功能安全工程师桌上都摆着一个刹车控制器残骸——那是某次故障注入测试中因软件Bug导致功率管炸裂的样品。他们把失败物化，摆在眼前，时刻提醒自己：我们写的每一行代码，都可能关系到一条生命。

好的安全文化包括但不限于：

• 无责备的事故分析：出了差错，第一反应不是找人背锅，而是问“流程哪里漏了？” 所有工程师都能毫无顾忌地报告自己发现的潜在缺陷。
• 安全评审的“魔鬼代言人”：每轮设计评审指定一人专门挑刺，从最悲观的角度攻击架构和代码。这个人有否决权。
• 从项目第一天就嵌入安全：而不是等到样车出来了再补安全文档。功能安全需要与系统设计、硬件、软件并行迭代。
• 学习失败案例：定期分享行业内功能安全事故分析（丰田加速门、高田气囊、特斯拉断轴……），让每个工程师知道“别人的灾难可能明天就发生在自己身上”。

结语：功能安全不是终点，而是底线

从第1篇的失控刹车故事，到第10篇的安全案例与ASIL分解，我们走完了汽车电子功能安全的完整旅程。你可能已经感受到：功能安全不是一系列酷炫的技术堆砌，而是一套严谨的、有时甚至令人厌倦的工程纪律。 它不创造新功能，不提升性能，不改善续航——它只是确保，当一切正常时你享受科技的红利；当一切异常时，你不会为此付出生命代价。

回看整个专栏，我们讲过V模型的左侧（HARA、系统架构、硬件FMEDA、软件设计），也讲过右侧（故障注入、覆盖率、安全案例）。中间穿插了E2E、SafeOS、Fail-Operational这些让系统“带病工作”的机制。所有这些的终极指向只有一个：让汽车无论何时何地，都保持一种防御性悲观——假设最坏情况，做最充分的准备。

作为功能安全工程师，你的日常可能是枯燥的文档、冗长的评审、无休止的测试。但深夜当你坐在车里，车辆自动驶过一段复杂路段，稳稳停在目的地时，你知道：那几十万行代码、几百页报告、上千次故障注入，没有白费。

安全，是我们送给每一位驾驶者的无声承诺。

---

全专栏完

终章思考题（无标准答案，欢迎分享你的感悟）：
回忆你职业生涯中经历过的一次“后怕”——某个设计缺陷或测试遗漏，险些造成严重后果。如果当时应用了专栏中介绍的任何一项功能安全方法（例如HARA、FMEDA、E2E、故障注入等），这场后怕是否可以避免？你从那之后在流程或个人习惯上做了哪些改变？