ASIL 分解(ASIL Decomposition)
本质 ASIL 分解是把"一条 ASIL D 安全需求"拆成"两路独立的更低 ASIL 子需求"的架构技巧,前提是两路真正独立(无共因)。最常见用法:ASIL D → ASIL B(D) + ASIL B(D),意味着两路都按 ASIL B 开发,但整体仍达 ASIL D——这极大降低开发成本(双 ASIL B 比单 ASIL D 在工具链 / 验证 / 文档上低 5-10×)。但误用代价同样大:两路用相同 MCU / 电源 / 算法,共因失效让"ASIL B + ASIL B" 实际还是 ASIL B,系统欠保护。本页拆 ASIL 分解的 5 种合法组合 + 4 个独立性硬约束(no shared HW / SW / data / specification) + 3 个经典 EPS / 主驱实例 + 5 反模式。
学习目标
读完本页后,你应该能够:
- 说出 ASIL 分解的含义和用途(降低开发成本,不降低系统安全等级)
- 列出 ISO 26262-9 表 1 的 5 种合法分解组合(D→C+A / D→B+B / D→A+C / D→QM+D 等)
- 检验4 个独立性硬约束:no shared HW / no shared SW / no shared data / no shared specification
- 区分 ASIL D 与 ASIL B(D) 标记的含义:括号里的是 inherited level
- 在 EPS / 主驱实例上正确应用分解(主控 ASIL D → 主 MCU ASIL B(D) + 监控 MCU ASIL B(D))
- 识别 5 个分解反模式(共 MCU / 共算法 / 共电源 / 共时钟 / DFA 没做)
1. 为什么要分解
ASIL D 工程比 ASIL B 贵 5-10×——在 MCU 选型、工具链(certified compiler)、verification 强度、文档密度上都成倍上涨。但 OEM 给的安全目标常常就是 ASIL D。ASIL 分解是把"系统级 ASIL D"在两个独立路径上分担,各路降到 ASIL B,大幅减成本——前提是两路真独立。
1.1 成本对比
ASIL D 与 ASIL B 在 4 个开发维度上都成倍上涨——MCU 单价、编译器认证费、测试 effort、文档密度,合起来 5-10× 总成本差。
| 维度 | ASIL D | ASIL B | 倍数 |
|---|---|---|---|
| MCU 选型 | TC397 / S32K344(锁步 + ECC + LBIST) | 普通 ASIL B MCU | 2-3× 单价 |
| 编译器 | 认证版(LDRA / Polyspace) | 普通 GCC + 静态分析 | 5-10× 工具费 |
| 测试覆盖率 | MC/DC + 边界条件 + 故障注入 | 语句覆盖 + 分支 | 5× test effort |
| 文档密度 | Safety Case + FMEDA + DFA + FTA + Audit | 简化文档 | 3-5× |
| 总开发成本 | 100 | 15-25 | 5-10× |
ASIL 分解 D → B + B 直接把 5-10× 的成本压回 2× 多一点(两路 ASIL B 各 ~25,合计 ~50)。
2. 五种合法分解组合
ISO 26262-9 Table 1 列出 5 种合法的 ASIL 分解——任何分解都要落在这 5 种里,否则不合规。
2.1 ASIL D 分解的 3 种组合
ASIL D 可以分成 3 种合法组合——按"两路 ASIL 等级和"必须 ≥ D 的伪加法规则。最常用是 B + B(对称冗余),C + A 用于"主控复杂 + 简单监控"或反过来"简单主控 + 复杂监控"。注意:C(D)+A(D) 和 A(D)+C(D) 是同一种分解——只是 main/monitor 角色互换,标准 ISO 26262-9 Table 3 把它当一个 entry,不是两种。
| 原 ASIL | 子路径组合 | 标记 | 适用场景 |
|---|---|---|---|
| D | ASIL D(D) + QM(D) | D + QM | 一路完整 ASIL D 实施,另一路只做无关功能 |
| D | ASIL C(D) + ASIL A(D) | C + A | 不对称 —— 哪边 C / 哪边 A 视架构而定 |
| D | ASIL B(D) + ASIL B(D) | B + B | 最常用 —— 两路对称冗余 |
常见误解:很多人(包括国内一些教材)以为"D = A + C 不合法"——这是错的。标准 ISO 26262-9 §5.4.10 Table 3 明确列出 C(D) + A(D) 为合法组合,无论标 "C+A" 还是 "A+C" 都指同一种分解。误解源头通常是把 A(D) 当成普通 ASIL A 而忽略 (D) 括号的含义——见 §3.1。
2.2 ASIL C 分解的 3 种组合
ASIL C 同理可分 3 种组合——成本压力比 D 小,实务里很少真正分解 C(因为 C 本身开发成本不算高)。
| 原 ASIL | 路径 1 | 路径 2 | 标记 |
|---|---|---|---|
| C | ASIL C | QM | C + QM |
| C | ASIL B(C) | ASIL A(C) | B + A |
| C | ASIL A(C) | ASIL B(C) | A + B |
2.3 不允许的组合
下面这些组合ISO 26262 明确不允许——分解出的 ASIL 等级不能任意组合:
- ❌ ASIL D → ASIL B(D) + ASIL A(D) (B + A 总和不够 D)
- ❌ ASIL C → ASIL A(C) + ASIL A(C) (两个 A 不够 C)
- ❌ ASIL B → 不允许任何分解(直接做 ASIL B)
- ❌ ASIL A → 不允许任何分解
关键认知:ASIL D 与 C 的分解等级数总和满足"D = 4 / C = 3 / B = 2 / A = 1 / QM = 0"的伪加法——D = D+QM(4+0)= C+A(3+1)= B+B(2+2)。注意这是按等级序数加,不是某些教材里"D=6"那种取 SPFM 百分比意会算法。
3. ASIL B(D) / A(D) 标记的含义
ASIL B(D) 是 ISO 26262 的特殊标记 —— B 是这一路开发的实际 ASIL,(D) 是 inherited(继承的)系统级 ASIL。两个含义都重要:
| 用 ASIL | 何时 |
|---|---|
| B | 选 MCU / 编译器 / 验证策略时,按 B 等级流程 |
| D(继承) | DFA 时检查独立性,仍要按 D 标准做共因分析 |
最容易踩的坑:开发时按 ASIL B 跑工具链没问题,但 DFA / 独立性论证仍要按 ASIL D 严格度——否则两路共因失效让分解失效,系统降回 ASIL B。
3.1 (D) 是"独立性税"——A(D) 不等于普通 ASIL A
很多人看到 D = A + C 的 A 那一侧,以为可以"按 ASIL A 流程做就行"——错。括号里的 (D) 不只是个标签,它带来一组实打实的额外义务,让 A(D) 的真实成本接近 D 而不是 A:
| 维度 | 普通 ASIL A | ASIL A(D) | 是否减负 |
|---|---|---|---|
| MCU / 工具链 | ASIL A 等级 | 可用 ASIL A | ✓ 减负 |
| 单元测试覆盖率 | statement | statement | ✓ 减负 |
| 独立性论证(DFA) | 按 A | 按 D —— 与 C(D) 那侧的共因要全切断 | ✗ 不减 |
| 集成 / 系统测试 | 按 A | 按 D —— 联合通道仍走 ASIL D 测试 | ✗ 不减 |
| 变更管理 / 配置管理 | 按 A | 按 D —— 全程 ASIL D 流程 | ✗ 不减 |
| 失效率账(SPFM/LFM) | 按 A 90% 门槛 | 联合到 ASIL D 预算,不能套 90% 单独脱钩 | ✗ 不减 |
| Safety case 文档密度 | 简化 | 按 D 走完整论证 | ✗ 不减 |
结论:A(D) 的成本通常接近 ASIL B/C,而非 ASIL A。这就是为什么 industry 实务里 80% 项目选 B(D)+B(D) 而不选 A(D)+C(D)——B+B 对称带来的工程便利(同平台、同测试方法、同组织结构)远比"省几个 ASIL 等级"重要。
3.2 什么时候 A(D) + C(D) 反而更合算
不对称分解不是劣选,在两类场景下比 B+B 更合理:
- 已有 ASIL C 成熟 SEooC 复用 —— 例如已有一颗 ASIL C SBC + driver IC 组合,直接当 C(D) 通道,再加一条便宜的 A(D) 监督路径,比从头做两套 B(D) 便宜
- 物理上天然不对称 —— 比如 main 通道是大算力 SoC(自然到 C),monitor 通道是简单 lockstep MCU(做到 A 已够),强行做 B+B 反而要把 monitor 升级浪费
4. 4 个独立性硬约束
ASIL 分解的合法性完全建立在两路独立——独立性破坏时,分解 illusion 立刻碎。ISO 26262 列了 4 类必须独立的方面:
4.1 硬件独立(no shared hardware)
两路必须用物理上分离的硬件资源——同一颗 MCU 的两个 core 一般不算独立(共时钟 / 共电源 / 共封装),除非特殊设计。
| 共享项 | 是否破坏独立 |
|---|---|
| 同 MCU 同 core | ✗ 完全不算独立 |
| 同 MCU 不同 core(非 lockstep) | △ 视设计,共时钟 / 电源算共因 |
| 同 MCU lockstep 双核 | △ 实际是 ASIL D 单元,不是分解 |
| 不同 MCU | ✓ 真独立(典型 ASIL B(D) + B(D) 配置) |
| 同电源域 | ✗ 共因 |
| 同时钟源 | ✗ 共因 |
| 同 reset 域 | ✗ 共因 |
典型 ASIL D → B(D) + B(D) 实施:主 MCU + 监控 MCU(不同 vendor、不同电源、不同时钟、不同 reset)。
4.2 软件独立(no shared software)
两路代码必须没有共享 module / library / 算法逻辑。
| 共享项 | 是否破坏独立 |
|---|---|
| 同算法用两次 | ✗ 同 bug 同时出错 |
| 同 OS / RTOS | △ 取决于隔离机制(MMU / hypervisor) |
| 同 compiler | △ 编译器 bug 是共因 |
| 不同算法不同实现 | ✓ 真软件多样性 |
| 不同语言 / 不同 compiler | ✓ 最强多样性 |
4.3 数据独立(no shared data / signal)
两路用的输入数据 / 信号不能完全相同来源——否则数据出错两路同时算错。
| 共享项 | 是否破坏独立 |
|---|---|
| 同传感器同 ADC 通道 | ✗ 单点故障 |
| 同传感器不同 ADC 通道 | △ 改善但仍共传感器 |
| 不同传感器(同信号) | ✓ 例:Resolver + Hall 双系统 |
| 同 CAN 消息 | △ 取决于 E2E 保护级别 |
4.4 规范独立(no shared specification)
两路的需求规范不能完全同源——同一个规范错误让两路同时实现错。
| 共享项 | 是否破坏独立 |
|---|---|
| 同需求文档 | ✗ 需求 bug 共因 |
| 同需求拆两个职能写 | △ 改善但仍同源 |
| 同需求由独立 team 写两次 | ✓ 高级实施(航天用) |
实务里规范独立要求最难达到——大多数车企 OEM 给一份规范,Tier1 自己实现两路。这种情况严格上算 partial independence,DFA 时要把"规范错误"列为共因风险。
5. 经典实例
5.1 EPS:主控 + 监控双 MCU
EPS 是 ASIL D → B(D) + B(D) 分解的教科书案例:
| 路径 | 角色 | ASIL |
|---|---|---|
| 主控 MCU(如 TC275) | 计算扭矩 + 控制 PWM | B(D) |
| 监控 MCU(如 STM8AF) | 独立计算扭矩 + 比较 + 触发 STO | B(D) |
独立性论证:不同 vendor / 不同电源 / 不同时钟 / 不同 reset / 软件不同 team 写。
5.2 主驱:Lockstep 单 MCU + ASC 硬件双通道
主驱典型不用 D → B + B 分解,而用 D 单 MCU + 硬件 STO 通道:
| 路径 | 角色 |
|---|---|
| Lockstep MCU(TC397 锁步) | 单元素就是 ASIL D |
| SBC + Safety MCU(独立监控) | 不算分解,算冗余监控 |
这是另一种合法架构:ASIL D 单元 + 独立 ASIL D 监控通道。比 B+B 实施成本高但开发周期短。
5.3 BMS:D + QM 分解
BMS 的 cell monitor 是 D + QM 分解的典型:
| 路径 | 角色 | ASIL |
|---|---|---|
| 主 BMS MCU | SOC 计算 + 接触器控制 | ASIL D |
| HMI 显示 IC | 仅显示电量 | QM |
关键:HMI 显示完全不影响安全(显示错误用户最多惊讶,不会触发 hazard),所以 QM 即可。
6. ASIL 分解的 4 步操作流程
把分解从概念变成可执行走 4 步——每步缺失或错误都让分解失效。
| 步 | 动作 |
|---|---|
| 1 识别候选需求 | 哪条 ASIL D 安全需求适合分解(实施成本高 / 有自然双路结构) |
| 2 提议分解组合 | D + QM / C + A / B + B / A + C 选哪种,看现有架构和成本 |
| 3 独立性论证 | DFA 走 4 类独立(HW / SW / Data / Spec)逐项验证 |
| 4 追踪分配 | 后续 traceability 中明确每个低 ASIL 子需求继承的(D)标记 |
7. 5 个 ASIL 分解反模式
ASIL 分解失败集中在 5 个反模式——这 5 个共同特征是"看起来合法但实际共因没消除",让 ASIL D 系统实际只是 ASIL B 保护。
| 反模式 | 表现 | 修法 |
|---|---|---|
| 共 MCU 单 core | ASIL D 拆成两个 ASIL B 软件模块跑同 core | 必须不同 core / 不同 MCU |
| 共算法 | 两路用同一个 control law 实现,只是输入不同 | 用算法多样性(不同实现) |
| 共电源 / 时钟 / reset | "不同 MCU 但同 SBC 供电" | DFA 必走,把电源 / 时钟 / reset 拆开 |
| DFA 没做 | 提议 B + B 但没系统性走 DFA 4 项独立 | 强制每个分解都附 DFA 报告 |
| 规范独立失败 | OEM 一份规范,内部一个 team 写两路实现 | 至少两个 team 独立 review,记录"规范错误"为共因风险 |
| A(D) 当普通 A 做 | 因为标 "A" 就用 ASIL A 流程,DFA / 测试 / 文档全走 A | 见 §3.1—— (D) 括号意味独立性 + 集成测试 + 文档全按 D 走 |
7.1 共 MCU 单 core 的隐蔽危险
最常见也最致命的反模式:工程师以为"两个 ASIL B 软件模块就是 D + D = D 等价"——其实两路跑在同 core 同 OS,单点 core 故障两路同时挂。这种"分解"完全是 illusion。修法:即使两个软件模块,也要跨 core(或者用 lockstep,但那时整体本来就是 ASIL D 单元,不算分解)。
7.2 规范独立失败的隐蔽成本
绝大多数车企项目里规范独立这条做不到——OEM 一份 TSR,Tier1 内部一个 system engineer 写,两路 dev team 都按这一份实施。这意味着规范本身的错误会同时传播到两路。修法:DFA 时把"规范错误"列为已知共因风险,在两路验证阶段加 specification cross-check(test team 用不同人独立 review)。
核心要点
- ASIL 分解是架构层成本优化技巧——D → B + B 把开发成本压回 ~2× 而非 5-10×
- 5 种合法组合(ISO 26262-9 Table 1):D→D+QM / D→C+A / D→B+B / D→A+C / D→ 不允许任何 A+A、B+A 等不足组合
- ASIL B(D) 标记:B 是实际开发等级,(D) 是继承的系统级——DFA 仍按 D 严格度
- 4 个独立性硬约束:no shared HW / SW / Data / Specification —— 任一破坏分解失效
- 典型实施:主 MCU + 独立监控 MCU(EPS),Lockstep MCU + 硬件 STO 通道(主驱),D + QM(BMS HMI)
- 4 步操作:识别候选 → 提议组合 → DFA 独立性论证 → 追踪 ASIL B(D) 分配
- 5 反模式戒除:共 MCU / 共算法 / 共电源时钟 reset / DFA 没做 / 规范独立失败
Cross-references
- ← 索引
- 功能安全
- HARA 危害分析与风险评估 — HARA 输出 ASIL,分解决定如何在架构层达成
- DFA / FMEDA / FTA 三种核心分析方法 — DFA 是分解合法性的论证手段
- ISO 26262 硬件要素三类分类 — 分解后两路各自的硬件要素分类
- 安全机制目录 — 不同 ASIL 等级 SM 组合的复杂度差
- 汽车 MCU — Lockstep vs Software diversity 的实施方式
- SBC 系统基础芯片 — Safety MCU + SBC 作为独立监控通道
- 转矩安全 — EPS / 主驱的 ASIL 分解实例
- 失效模式速查