|
ASIL分解是功能安全系统设计的必要阶段，这部分工作做不好，开发复杂度、零部件成本都是难以接受的。这部分内容，我也刚刚接触，正好写篇文章理一理思路。 什么是ASIL分解？ 控制系统的Safety goal和ASIL等级确定以后，从Safety goal可以推导出功能安全需求。功能安全需求继承了安全目标的ASIL等级。如果一个安全需求可以分解为两个安全需求，那么原来安全需求的ASIL等级可以分解到这两个安全需求上。 这个分解的结果是需求ASIL等级下降，但本质是功能安全需求的分解，最终都是实现相同ASIL等级的安全目标。下图给出了ASIL分解的原则，分解后的ASIL等级后面括号里是指明原始安全需求的ASIL等级，因为集成和需求的验证仍然依据原始的ASIL等级。ASIL的分解可以在功能安全活动的多个阶段进行，比如概念设计、系统设计、硬件设计和软件设计阶段。而且ASIL分解可以分多次进行，比如ASIL D=ASIL C(D)+ASIL A(D),其中ASIL C(D)还可以继续分解为ASIL B(D)+ASIL A(D)。 “ASIL”分解误用案例 电子转向锁系统(Electronic steering lock) 该系统的功能安全目标如下表所示。 由功能安全目标导出的功能安全需求和需求分解如下图所示。 如果上面的分解过程是正确的，可以导出更新后的控制系统架构如下图所示。第一个控制器充当网关角色，作为唯一输入源。如果Primary controller CAN接收失效，两个控制器的的输入都是有误的。会产生共因失效，这在功能安全要求里是不被允许的(ISO26262第九章)。 考虑了共因失效的影响，在做ASIL分解的时候，最重要的要求是子系统的独立性，如果不能满足独立性的要求，冗余单元要按照原来的ASIL等级开发。修正后的系统架构图如下所示。 “ASIL”分解常见误区 误区1：不了解ASIL分解的目的 误区2：认为ASIl分解能够改变随机性失效度量指标 误区3：认为检测机制就是ASIL分解 误区4：无法区分安全冗余与功能冗余
误区5：即使是安全冗余也不一定可以分解
误区6：过早的做了ASIL分解，实际实施时不对应
参考资料： <THE USES AND ABUSES OF ASIL DECOMPOSITION IN ISO26262> ,MIRA Limited UK, D.D Ward 《ASIL分解与常见误区》-TÜV RheinLand, Jemmy Bian. |
|
|
