企业官网建设流程全解析

ASIL分解的核心逻辑：如果一个高ASIL的安全需求太难实现，可以把它拆成两个相互独立的低ASIL需求，分配给两个独立的元素。只要两个元素同时失效的概率足够低，整体就能达到高ASIL的安全水平。

什么是ASIL分解？

官方定义

ISO 26262-9:2018第5章将ASIL分解定义为一种允许在概念阶段和开发阶段应用的方法。核心思想是：

“将安全要求冗余地分配给充分独立的要素，目的是降低分配给相关要素的冗余安全要求的ASIL等级。”

拆开来看，三个关键点：

重要提醒：ASIL分解是在不得已的情况下，“情非得已”的备用手段，而不是“必须做”的需求。能不拆就不拆——拆了就要额外做一堆分析来证明“独立性”，有时候省下的钱还不够做分析的。

分解的“标号规则”：括号里的秘密

ASIL分解有一个非常重要的标号规则——拆完之后，每个需求的ASIL等级后面必须用括号标出原始ASIL等级。

为什么括号这么重要？

括号里的原始ASIL等级决定了验证活动的严格程度——虽然每个组件按较低等级开发（省钱了），但验证和集成活动仍然必须按原始ASIL等级执行。

比如一个ASIL D的需求被拆成两个ASIL B——每个组件按ASIL B开发（SPFM≥90%就够了），但集成测试时必须按ASIL D的要求（覆盖率100% MC/DC、故障注入测试全覆盖等）。

所以，ASIL分解降低了组件的开发成本，但没有降低系统的验证要求。

ASIL分解的“官方菜单”：什么等级能拆成什么？

ISO 26262-9:2018的Table 1给出了所有允许的分解组合：

关键规则：

• 两个分解后的ASIL等级相加，必须等于或大于原始ASIL等级
• ASIL A不能进一步分解（除非拆成ASIL A(A) + QM(A)，但没啥意义）
• 原始ASIL D不能拆成“ASIL C + ASIL C”——因为相加=ASIL C+C，达不到D的要求

多级分解：拆了又拆

ISO 26262允许多级分解——一个需求拆成两个之后，其中任何一个还可以继续往下拆。

示例：

ASIL D → ASIL C(D) + ASIL A(D)

然后 ASIL C(D) → ASIL B(D) + ASIL A(D)

最终得到三个需求：ASIL B(D)、ASIL A(D)、ASIL A(D)。

但要注意：多级分解会引入更多的“独立性”证明工作量。拆得越多，DFA分析越复杂，必须避免多级分解组件的共因失效。

分解的“前提条件”：独立！独立！独立！

ASIL分解的核心前提是：参与分解的元素之间必须充分独立（Sufficiently Independent）。

为什么独立性这么重要？

ASIL分解的本质是冗余——两个元素互相备份。但如果两个元素之间存在共因失效（Common Cause Failure）或级联失效（Cascading Failure），一个故障把两个都干掉了，冗余就白做了。

共因失效：同一个原因导致两个元素同时失效（比如两个芯片共用一个电源，电源一坏两个都死）。

级联失效：一个元素的失效导致另一个元素也失效（比如A芯片过热把B芯片也烤坏了）。

没有独立性的冗余，叫“伪冗余”——看着有两套，其实一荣俱荣、一损俱损。

怎么证明独立性？DFA是“必修课”

ISO 26262要求，任何ASIL分解必须通过相关失效分析（DFA, Dependent Failure Analysis）证明元素间的独立性。

DFA要检查的内容包括：

如果DFA发现了共因失效的可能，但通过适当的安全措施可以控制，这仍然可以作为独立性的论据。但必须提供充分的证据。

同构冗余为什么“不够独立”？

同构冗余（Homogenous Redundancy）指用完全相同的硬件和软件来做冗余。

比如：用两颗同一批次的芯片 + 完全相同的算法软件做双通道冗余。

问题在哪？

两颗芯片来自同一批次 → 可能有同样的制造缺陷→ 一个坏了，另一个大概率也坏了。

两个软件完全一样 → 可能有同样的设计缺陷→ 一个出bug，另一个也出bug。

ISO 26262明确指出：同构冗余通常不足以降低ASIL等级，因为元素之间缺乏独立性。

那同构冗余就完全不能用吗？

也不完全是。如果通过DFA证明了不存在相关的共因失效，或者所有潜在共因（如环境、老化等）在允许的生命周期内都不会导致失效，同构冗余也是可以用的。但证明难度极高。

实战建议：尽量采用异构冗余——不同的芯片供应商、不同的算法实现方式、不同的开发团队。异构冗余更容易通过DFA的独立性审查。

实战一：胎压监测系统的ASIL分解

📋 场景描述

一个胎压监测系统（TPMS），原本只靠单个传感器监测胎压。

HARA分析结果：

单个传感器→ASIL D→开发成本极高😱

应用ASIL分解

分解方案：采用双传感器冗余设计——两个独立的胎压传感器，分别监测同一轮胎的气压。

分解后：

✅ 必须满足的条件

1. 独立性证明（DFA）

   ：两个传感器必须独立供电、独立通信、独立安装位置，不能共用一个电源或同一条总线。

2. 标号规则

   ：分解后的需求必须标注为ASIL C(D)和ASIL A(D)。

3. 验证按原等级执行

   ：虽然传感器A按ASIL C开发、传感器B按ASIL A开发，但系统集成和验证仍然必须按ASIL D执行。

效果对比

实战二：电子转向锁（ESCL）的ASIL分解

📋 场景描述

电子转向锁（ESCL，Electronic Steering Column Lock）是一种转向管柱锁定装置——以物理方式限制转向轴的旋转运动，防止未经授权的操作。

安全目标SG-01：当车辆行驶时，转向锁不应意外接合【ASIL D】。

高速行驶中转向锁突然锁死 → 方向盘转不动 → 直接失控 → ASIL D

应用ASIL分解

TÜV北德的专家给出了一个经典的分解方案：

两阶段分解：

第一阶段：ASIL D → ASIL C(D) + ASIL A(D)

第二阶段：ASIL C(D) → ASIL B(D) + ASIL A(D)

最终得到三个需求：

✅ 关键条件

三个元素必须充分独立：

• 控制通道和监控通道不能用同一个MCU

• 执行通道的电机驱动必须独立于控制逻辑

• 通过DFA证明不存在共因失效和级联失效

这个案例的价值：展示了多级分解的实际应用——一个ASIL D的需求，经过两轮分解，变成了三个低ASIL的需求，大幅降低了每个组件的开发难度和成本。

ASIL分解中容易踩的“坑”

坑1：把“分解ASIL等级”当成“分解需求”

❌ “我要把ASIL D拆成ASIL B + ASIL B”
✅ “我要把这条安全需求拆成两条独立的安全需求，分别分配给两个独立元素”

分解的是需求，不是等级本身。

坑2：忘了做DFA

❌ “两个传感器，肯定独立”——没有证据
✅ 必须通过DFA（相关失效分析）提供独立性的证据

坑3：用同构冗余还不做分析

❌ “两个一样的芯片，够冗余了吧”
✅ 同构冗余通常不足以降低ASIL等级，除非通过DFA证明不存在共因失效

坑4：验证时按分解后的低等级执行

❌ “ASIL B(D)嘛，按ASIL B验证就行了”
✅ 虽然组件按低等级开发，但验证和集成活动必须按原始ASIL等级执行

坑5：把安全目标也拆了

❌ “我把安全目标SG-01也拆成两个”
✅安全目标不能分解。只有安全需求（FSR、TSR、HSR、SSR）可以分解。