本文篇幅较长，因而在此先列出目录：

1. ASIL 的本质与继承规则
2. 为什么需要“降低 ASIL”——技术动机与经济动机
3. ASIL 分解的合规框架
4. 工业场景：从“电机误激活”看分解全过程
   4.1 功能定义与安全目标
   4.2 初始 ASIL 分配
   4.3 技术可行性分析——为何驱动器可降至 QM
   4.4 利用 H&R 分析结果引入安全机制
   4.5 安全机制本身是否改变 ASIL？
5. 软件级分解的可行性与陷阱
6. 硬件级分解：独立安全单元的设计要点
7. 分解“组合”盘点：对称、非对称与遗留约束
8. ASIL 分解十大误区深度澄清
9. 结论与最佳实践建议

随着汽车 E/E 架构复杂度呈指数级上升，功能安全标准 ISO 26262 已成为行业“硬法律”。标准用 Automotive Safety Integrity Level（ASIL）量化风险，从 A 到 D 逐级收紧，迫使开发者在需求、设计、验证、生产、运维全过程投入几何级增长的资源。

“能否在不影响安全目标的前提下，让部分软硬件以更低 ASIL 开发？”——这是每个项目经理在成本评审会上都会提出的问题。

ASIL 分解（ASIL Decomposition）正是标准给出的合法路径，但多年来业界对其理解参差不齐，甚至滋生“分解万能”“QM 即可量产”等危险认知。

本文以一个实战案例为主线，系统梳理分解原理、步骤、证据链与常见误区，供功能安全从业者参考。

1. ASIL 的本质与继承规则

ISO 26262将风险度量拆解为三个维度： 严重度（S）、暴露概率（E）、可控性（C） ，三值查表即可得 ASIL A~D 或 QM（无安全需求）。ASIL有几个关键理念：

• ASIL 绑定的是“功能”而非物理零件。
• 功能的 ASIL 会向下遗传给实现它的所有软硬件元素。
• 若同一硬件（如一颗 MCU）承载多个功能，则取最高 ASIL。

举例：一颗ASIL C的电机调速功能与QM的车窗升降功能共用同一MCU，则MCU整体须满足ASIL C。

2. 为什么需要“降低 ASIL”——技术动机与经济动机

更高ASIL意味着：更严格的流程证据（追溯、评审、审计）；更复杂的安全机制（冗余、ECC、CRC、 双核锁步 ）；更昂贵的工具鉴定、更高覆盖率测试、更长的验证周期。

据有关公司内部统计，ASIL D软件单元测试与验证工作量约为QM的 5–7 倍；硬件层面，ASIL D的FIT指标比ASIL B严苛一个数量级。

若通过合法手段将部分组件降至ASIL B甚至QM，可直接转化为：

• 人力成本下降 30 %–50 %
• 晶圆面积/PCB 面积缩小 10 %–20 %
• 项目周期缩短 3–6 个月

3. ASIL 分解的合规框架

ISO 26262-9:2018第6章给出分解的充要条件：

1）分解前必须已定义清晰的安全目标（Safety Goal）及 safe state。

2）分解后的子元素需满足：
    a. 共同覆盖同一安全目标；
    b. 采取同一 safe state；
    c. 相互独立（Independence），即单点故障不会同时击垮两条路径；
    d. 不存在“干扰”（Freedom from Interference），尤其是共享资源（内存、时钟、电源）带来的级联失效。

3）分解仅降低系统性故障要求，不降低随机硬件失效指标。换言之，原 ASIL D 的 FIT 预算 100 FIT 在分解后仍适用于整体系统，硬件指标不可因“降到 ASIL B”而放松。

标准还给出了“合法组合表”：

• ASIL D → ASIL B(D) + ASIL B(D)
• ASIL D → ASIL C(D) + ASIL A(D)
• ASIL C → ASIL B(C) + ASIL B(C)
• …

括号内字母代表“继承自原等级”的标记方式，提醒审计人员：随机指标并未下调。

4. 工业场景：从“电机误激活”看分解全过程

4.1 功能定义与安全目标

功能 F：依据n个传感器（S1…Sn）综合判断后，输出PWM命令到无刷直流电机M。

H&R分析 确认：若M在行驶中意外转动，将诱发车辆非预期加速，严重度S3、暴露E4、可控性C3，查表得ASIL D。

安全状态Safe State：立即切断M，即“M  deactivated”。
安全目标SG1：“避免M因传感器错误组合而被误激活”。

4.2 初始 ASIL 分配

传统做法：所有可能独立触发SG1违例的元素均继承ASIL D。于是得到：

• 传感器 S1…Sn → ASIL D
• 微处理器 μP（运行应用算法） → ASIL D
• 软件应用层 → ASIL D
• 驱动器、M 本体 → ASIL D

4.3 技术可行性分析——为何驱动器可降至QM

工程团队引入“技术深潜”论证：

• 无刷直流3相电机依赖精确换向时序，任何门级信号错位只会导致失步、抖动或停转，而不会“自发旋转”。
• 驱动器IC若发生单一stuck-at故障，无法产生满足反电动势的旋转磁场，故不可能独自违反SG1。

该结论被记录于“安全分析报告”，经第三方评估后，依据 ISO 26262-9:2018 5.3.2，允许将驱动器、M本体及PWM命令通道降为QM。

4.4 利用 H&R 分析结果引入安全机制

进一步细读H&R报告发现： “仅当车速>15km/h时，M的意外转动才会导致不可控加速；车速≤15km/h时，驾驶员可通过制动轻松克服。”

于是团队引入安全机制： “当车速 > 15 km/h 时，强制关闭 M 电源”。
实现方式：

• 新增独立车速传感器 ∨；
• 新增轻量级安全单元（ Safety Element ），当 ∨> 阈值时拉低驱动器使能脚 drv_en。

此时系统逻辑变为： M被激活 = 应用算法同意 AND 车速≤15km/h， 即“双路 AND”架构，显著降低误激活概率。

4.5 安全机制本身是否改变ASIL？

ISO 26262-9明确：仅添加安全机制并不自动下调原功能ASIL。

本例中，μP、应用算法、S1…Sn 仍保持ASIL D；新增的车速传感器与安全单元亦须按 ASIL D开发，因为一旦它们失效，整体安全机制将丧失。

5. 软件级分解的可行性与陷阱

团队曾试图“不做硬件冗余，仅在软件层面做分解”：

• 将应用层拆分为“非安全”与“安全相关”两个进程；
• 拟把操作系统、RTE、MCAL 等统统标为 QM，仅保留 5 % 的监控代码为 ASIL D。

但独立评估后发现：

• 共享同一颗CPU 核、同一套存储器、同一套缓存与中断控制器；
• 若QM部分的数组越界可能踩坏安全相关进程的栈，导致无法进入safe state；
• 需引入“免干扰分析”——内存保护单元MPU、时隙看门狗、数据一致性CRC、双区 Flash擦写保护等；
• 最终成本高于“外挂一颗简单安全芯片”。

结论：软件级分解并非“省钱捷径”，反而对架构、编码、测试、工具鉴定提出更严苛的系统性要求。

6. 硬件级分解：独立安全单元的设计要点

团队最终采用“硬件级非对称分解”：

• 主 MCU：继续跑复杂算法，ASIL降至C；
• 独立Safety Element：仅实现“车速判别 + 拉低 drv_en”，ASIL A(D)。

Safety Element 实现细节：

• 并非第二颗MCU，而是一次性编程的小规模 FPGA/CPLD ，仅2k逻辑门；
• 独立晶振、独立LDO，与主MCU不共享电源；
• 无嵌入式软件，因此ISO 26262 Part 6（软件）整章可省略，仅需 Part 5（硬件）与 Part 7（生产）证据；
• 成本仅为主MCU的1/10，失效率FIT<10，满足ASIL D的硬件指标分配。

independence 证据：

• 物理隔离：Safety Element 与主 MCU 间距 > 3 mm，满足 PCB 爬电距离 ；
• 时钟隔离：两颗片子的时钟源彼此独立，不存在共因失效；
• 共因失效率 β 经计算 < 1 %，满足 ASIL D 对分解路径的 β 要求。

7. 分解“组合”盘点：对称、非对称与遗留约束

对同一ASIL D目标，理论上存在三种合法组合：

1. ASIL B(D) + ASIL B(D) ——对称双核冗余
• 优点：软件可同质，需求、架构、测试用例可复用；
• 缺点：硬件成本翻倍，且需“软件多样性”证明，否则无法抵御共因系统故障，实际费用最高。

2. ASIL C(D) + ASIL A(D) ——非对称，主从架构

• 本文案例即采用该模式；
• 适合“复杂主控 + 简单安全钳”场景；
• 遗留项目常因“旧有安全芯片性能不足”而被迫采用，不可简单互换角色。

3. ASIL D(D) + QM(D) ——极端非对称

• 只有 QM 路径在任何单一故障下均无法违反安全目标时才合法；
• 本文驱动器降至 QM 即属此列，但其前提是对电机物理特性的深度论证。

8. ASIL 分解十大误区深度澄清

1. 误区 10：ASIL 只与硬件相关
   事实：ASIL 覆盖需求、架构、软件、硬件、生产、运维、支持流程。
2. 误区 9：一颗芯片可“设计为 ASIL X”后通吃所有项目
   事实：芯片在满足特定系统上下文安全需求时，最多只能声称“适用于 ASIL X”，不可脱离系统单独出售“ASIL X”属性。
3. 误区 8：分解＝硬件冗余
   事实：分解引入的是“功能性异构冗余”，与 61508 传统“同构双通道”有本质区别。
4. 误区 7：分解后可降低硬件 FIT/DFA 指标
   事实：随机硬件失效目标维持原 ASIL 等级不变，分解仅降低系统性活动强度。
5. 误区 6：分解主要对付随机失效
   事实：ISO 26262 的分解更关注系统性故障（需求错误、架构缺陷、代码 bug）。
6. 误区 5：26262 强制要求分解
   事实：分解是可选手段，标准仅提供“如果分解，则应满足…”的合规框架。
7. 误区 4：软件分解比硬件分解便宜
   事实：软件分解需大量 MPU、WDT、FFI 分析、工具鉴定，往往更贵。
8. 误区 3：只有分解能降 ASIL
   事实：通过技术与 H&R 深度分析，有时可直接将元素降为 QM，如本文驱动器案例。
9. 误区 2：任何系统都能分解
   事实：若功能高度耦合、共享资源过多、legacy 组件不可触碰，可能无法证明 independence。
10. 误区 1：分解总是值得
    事实：需做成本收益权衡。若 independence 证据代价过高，分解可能“省不了钱还添风险”。

9. 结论与最佳实践建议

ASIL分解是一把双刃剑：用得好，可在确保安全的前提下显著降低开发成本；用得不好，则可能在审计节点被“一票否决”，甚至埋下随机失效隐患。基于本文案例与标准条文，建议：

• 在项目初期就将“能否分解”纳入系统架构权衡，与 H&R 分析同步进行，而非等到软硬件冻结后再“补证据”。
• 建立“技术深潜”流程，对传感器、执行器、软件平台逐项给出“能否独立违反安全目标”的量化论证，形成可审计的“ASIL 降低报告”。
• 若选择软件级分解，应提前规划 MPU、时隙看门狗、FFI 测试用例，并把工具鉴定费用纳入预算。
• 若选择硬件级分解，应优先评估“小体量、一次性编程、独立供电”的 FPGA/CPLD 方案，避免“为了分解而引入第二颗大 MCU”导致成本倒挂。
• 最终交付物务必包含 independence 分析、共因失效估算、FTA/DFA 定量结果，以及“分解后随机指标不变”的声明，否则审核机构将拒绝认可。

功能安全没有银弹，ASIL 分解也不是“省钱捷径”。唯有在透彻理解系统、技术、标准与商业边界的基础上，才能做出既合法又经济的架构决策。愿本文能为广大工程师、项目经理与审计师提供一份可落地的参考，助力中国汽车产业在全球竞争中兼顾安全与成本，行稳致远。