ASIL分解的核心逻辑如果一个高ASIL的安全需求太难实现可以把它拆成两个相互独立的低ASIL需求分配给两个独立的元素。只要两个元素同时失效的概率足够低整体就能达到高ASIL的安全水平。什么是ASIL分解官方定义ISO 26262-9:2018第5章将ASIL分解定义为一种允许在概念阶段和开发阶段应用的方法。核心思想是“将安全要求冗余地分配给充分独立的要素目的是降低分配给相关要素的冗余安全要求的ASIL等级。”拆开来看三个关键点关键词大白话需求分解不是“分解ASIL等级”而是分解安全需求本身冗余分配把同一条需求分给两个或以上独立元素等级降低每个元素只需要满足较低的ASIL等级重要提醒ASIL分解是在不得已的情况下“情非得已”的备用手段而不是“必须做”的需求。能不拆就不拆——拆了就要额外做一堆分析来证明“独立性”有时候省下的钱还不够做分析的。分解的“标号规则”括号里的秘密ASIL分解有一个非常重要的标号规则——拆完之后每个需求的ASIL等级后面必须用括号标出原始ASIL等级。原始ASIL分解方案示例标号方式ASIL D拆成两个ASIL BASIL B(D)ASIL B(D)ASIL D拆成ASIL C ASIL AASIL C(D)ASIL A(D)ASIL C拆成ASIL B ASIL AASIL B©ASIL A©ASIL B拆成两个ASIL AASIL A(B)ASIL A(B)为什么括号这么重要括号里的原始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 D① ASIL C(D) ASIL A(D)② ASIL B(D) ASIL B(D)③ ASIL D(D) QM(D)ASIL C① ASIL B© ASIL A©② ASIL C© QM©ASIL B① ASIL A(B) ASIL A(B)② ASIL B(B) QM(B)ASIL AASIL A(A) QM(A)关键规则两个分解后的ASIL等级相加必须等于或大于原始ASIL等级ASIL A不能进一步分解除非拆成ASIL A(A) QM(A)但没啥意义原始ASIL D不能拆成“ASIL C ASIL C”——因为相加ASIL CC达不到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分析结果分析维度评估危害胎压监测失效驾驶员未察觉胎压异常严重度SS3高速爆胎可能致命暴露率EE4几乎每次开车都涉及胎压可控性CC2一般可控ASILD单个传感器→ASIL D→开发成本极高应用ASIL分解分解方案采用双传感器冗余设计——两个独立的胎压传感器分别监测同一轮胎的气压。分解后需求ASIL等级传感器A监测胎压数据ASIL C(D)传感器B监测胎压数据ASIL A(D)✅ 必须满足的条件独立性证明DFA两个传感器必须独立供电、独立通信、独立安装位置不能共用一个电源或同一条总线。标号规则分解后的需求必须标注为ASIL C(D)和ASIL A(D)。验证按原等级执行虽然传感器A按ASIL C开发、传感器B按ASIL A开发但系统集成和验证仍然必须按ASIL D执行。效果对比对比项分解前分解后传感器A开发等级ASIL DASIL C✅传感器B开发等级ASIL DASIL A✅系统验证等级ASIL DASIL D不变开发成本极高大幅降低✅实战二电子转向锁ESCL的ASIL分解 场景描述电子转向锁ESCLElectronic 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)最终得到三个需求需求ASIL等级负责元素需求1ASIL B(D)控制通道主控制器需求2ASIL A(D)监控通道监控器需求3ASIL 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可以分解。