说到ASIL分解，相信从事汽车功能安全的朋友都会很“喜欢”，最直观的是，它直接降低了组件的ASIL等级，有助于在处理随机硬件故障方面达到性能目标—单点故障度(SPFM)、潜在故障度(LFM)和硬件随机故障目标值(PMHF)。换句话说，可以少花钱了，可以不用那么“麻烦”了。但是，必须看到，ASIL分解是在不得已的情况下，“情非得已”的备用手段，而不是“必须做”的需求。事实上，当部件要求符合ISO26262时，没有义务应用需求分解；而且，如果应用了需求分解，则必须遵守某些附加要求。
01从IEC61508说起：
老郑喜欢追根溯源，既然ISO26262来自IEC61508，那么，源头在哪呢？其实，ASIL分解是SC—“系统性能力”冗余方案的一个让步措施。
在IEC61508中：对于系统性能力SC n中的两个元素，允许组合中的两个元素声称具有系统能力(n＋1)，前提是安全功能的失效仅由两个元素的组合系统故障引起，并且两个元素之间存在足够的独立性。在应用该组合方案时，需要对常见故障原因进行分析，以证明各要素的独立性。
在ISO26262中：举例说明，ASIL D需求可以分两个阶段分解为三个需求，在三个独立元素之间继承ASIL B(D)、A(D)和A(D)。
这中间，老郑提醒大家一点，IEC61508不允许多次使用该成分，即不允许多次组合SC n元素以达到n+2的能力。但ISO 26262允许多级分解，这也就是在汽车上特别要注意不要引入风险的地方：必须避免多级分解组件的共因失效。
02到底什么是ASIL分解：
ASIL分解是很多人经常挂在嘴上的说法，其实，老郑认为，这个约定俗成的说法既不科学，又容易误导。事实上，所谓ASIL分解，其实是一种需求分解，或者说，针对的是目标ASIL等级及其可能的等级降低措施。
从两方面来看，以便明确这个定义：
1“汽车安全完整性水平（ASIL）”值表示应在需求开发、实施和验证中应用的严格程度，以避免最终产品中存在不合理的剩余风险。
2随着标准所要求的过程应用，安全目标通过一系列安全要求(包括功能安全要求、技术安全要求以及最终的硬件和软件安全要求)逐步细化。在这个过程中，安全需求被分配到架构设计的元素中。每个安全需求在层次结构中继承其父级的ASIL值，并最终继承其派生的安全目标的ASIL值。如果在体系结构的设计中存在足够独立和冗余的元素，那么就有可能对两个(或更多)这些元素分配特定的安全要求。这样分配的冗余需求可以继承比父级更低的ASIL值。
03电子转向锁的例子：
简单来说，电子转向锁是一个防盗装置，在车辆锁定时将锁紧螺栓打入转向柱，从而防止未经授权的操作。具体解释：给定条件，在CAN总线上接收到一条消息，由微控制器处理和验证，驱动电机在适当的时间以适当的方向操作螺栓，以锁定或解锁转向柱。
安全目标SG01
当车辆行驶时，转向锁不应意外接合[ASIL D]。
通过开发“功能安全概念”和“技术安全概念”，开发人员已确定，在其他项目限制条件下，使用微控制器和软件控制锁可能无法满足给定ASIL的以下技术安全要求：
技术安全要求22：当通过CAN总线接收到“锁定”条件时，微控制器应激活桥接器驱动信号。[ASIL D]
因此，该架构已被更新以添加第二个微控制器，并且已尝试进行需求分解。
技术安全要求22.1：当通过CAN总线接收到“锁定”命令时，主微控制器应激活桥接器驱动器的驱动信号。[ASIL B(D)]
技术安全要求22.2：当通过CAN总线接收到的车速表明锁定条件是合理的(即车辆静止)时，二级微控制器应激活桥接器驱动的启用信号。[ASIL B(D)]
随着需求分解到位，期望主微控制器元素现在可以开发为ASIL B(D)因为B(D)将是需要由该元素实现的需求的最高完整性级别。这里忽略的是，主微控制器充当网关，接收车速CAN信息并将其传递给辅助微控制器。这意味着存在一个共同原因故障(CAN接收；元件的子部件和软件)，可能导致技术安全要求22.1和技术安全要求22.2同时故障。此外，还没有考虑与can总线本身相关联的故障，也没有考虑其他CAN节点之一伪造消息的能力，当然，这是一项安全要求，不在ISO26262的范围内。
因此，合理解决方案，二级微控制器也配备了CAN硬件，因此能够独立于一级微控制器满足技术安全要求22.2。此外，还应注意，还使用单独的CAN总线来避免项目外部的常见故障。此外，利用不同的输入源意味着这些输入的完整性不必如此之大，因此这样的解决方案避免了对外部系统提出如此高的完整性要求。另外，另一个经常被忽视的方面是微控制器的支持电路。在这种体系结构中，应注意确保没有共同原因的故障，并且故障不会通过共同电源或共同时钟电路从一个微控制器传播到另一个微控制器。
捡证网提供相关检测认证咨询服务，咨询电话：13636483412 QQ: 495226609 邮箱：yangda@jz-cert.com
