ISO 26262中硬件随机失效度量指标(PMHF)的分解

1  简介

ASIL分解是ISO26262道路车辆功能安全的一个非常重要的安全活动。这种方法是将冗余的安全要求分配给具有足够独立性的要素，以达到相同的安全要求，减少分配给相应要素的冗余的安全要求的ASIL。

在车用领域的分布式开发中，整车企业通常会进行较高层级的开发集成行为，各个供应商承担系统产品或者零部件的开发。因此根据分布式开发的特点，整车企业会对供应商输出对应的系统和零部件需求， 要求供应商在产品的开发过程满足其提出的要求。如果在整车企业执行了分解的行为，那么在对供应商 提出的需求中必须含有分解之后的相关指标的具体要求，否则很容易出现无法满足需求的情况。

例如， 如果在某个系统的开发中，整车厂要求对于系统总的 指标-系统总质量不允许超过100kg.如果系统由A， B， C三家共同开发，后由整车企业进行产品集成。如果没有针对A或B或C的单独细化的要求，供应商如果各自按照小于100kg为限值，那最终集成产品很可 能超过总成的总质量要求。因此，在进行了ASIL分解之后，如果承担分解之后需求的隶属于不同的开发组织，有必要对各自提出细化的分解之后的要求。

ISO26262在第9章ASIL分解部分的需求和推荐 中明确指出，对于硬件架构指标和违反安全目标的硬件随机度量指标，不允许进行分解。本文要进行分析的就是违反安全目标的硬件随机失效度量指标（ProbabilisticMetricforrandomHardwareFailures以后 简写为PMHF）对分解后系统的分配问题。

上文中所谓的不允许在ASIL分解过程中对PM⁃ HF进行分解的含义通过示例说明如下：原有需求的属性是ASILD，分解之后的两个需求的属性均为：ASILB(D)和ASILB(D)。

从而根据分解后得到的ASILB (D)的需求，根据下表1中的ASIL级别及对应的PMHF 目标值，作为其分解之后所需要达到的目标值。



以上描述的这种根据分解之后的ASIL来定义其PMHF目标值的行为是被ISO26262所禁止的。在此，ISO 26262中并没有定义ASILA和QM的PMHF目标，出于经验，针对ASILA和QM（区别于ASIL，表达常规质量管理的含义）都对其PMHF定义为比ASILB的目标值低一个量级.ISO26262对于ASILB的需求的PMHF目标仅为一般推荐并非强制推荐，因此可以按照一般推荐值来做为其目标值。

但是如果我们在需求分解的过程中进行了 PMHF的分解，结果会违反初始或分解之前的PMHF 指标吗？

本文将依据以下思路来展开分析：

a)ASIL分解根据分解对象的性质，可以分成如下 两种：功能和功能的分解或功能和对应安全机制的分解。本文只讨论功能和功能的分解而不讨论功能和安全机制的分解。

b)根据分解对象ASIL不同，分解的结果也会不同。由于PMHF在ISO26262中仅仅对ASILC和 ASILD强制要求，因此在以下章节，会仅针对分解前 需求属性为ASILC和ASILD的情况对应分析。因此下文中针对不同的分解方式进行分析，ASILC和 ASILD的所有分解方式如表2所述5种情况。



c)根据被分解需求,对于安全目标覆盖的范围不同，会呈现不同的分解结果。比如需求的分解既可以是针对整条安全目标所需功能的分解，也可以是其中一部分。举例说明如下，如果整个安全目标是当电池出现过压的时候，高压电路必须断开。那么针对整个安全目标的安全功能-过压断开可以分解成足够独立的两条功能：一个功能路径持续检测电压，判断是否过压，一旦过压进行切断处理。另外一条与之独立的功能路径也持续检测电压，判断是否过压，一旦过压进行切断处理。此外，需求分解也可以是检测电压和判断过压都依照原有的ASIL开发，而切断部分通过两个路径的冗余需求进行需求分解。此处，第二种分解方式就是部分分解--只针对输出部位进行分解，或者说对于整个安全目标实现进行局部需求分解。

因此，在下面的分析过程中会对这两种（全部和部分）覆盖范围进行区分分析。以下的分析过程会做如下分析假定：

1）假定分解之后的冗余路径的独立性可以被保证，即分解之后的两个部分不存在共因失效和级联失效。

2）假定分解之前的系统和分解之后的子系统系 统工作的所有工时均为8000h。

3）假定失效概率的计算中所有的λ×T<<1，那么就可以直接使用失效概率P=λ×T。

此处λ是失效率， T是系统工作的总时间。分解之前的最大失效可能性根据以上公式计算得到。分解之后的冗余路径的最大失效可能性根据概率布尔运 算法则得到。

2 完整安全功能的需求分解

首先，针对完整安全功能的需求分解情况。因为分解是针对的是整个安全目标，因此分解前最大的失效率（即PMHF）为完全引用自表1.



在表3中，第3列为根据分解前需求的ASIL级别 定义出的PMHF的目标值。第5列为根据PMHF目标值和时间计算得到的失效概率（P=λ×T）。第6列为分 解之后根据ASIL级别定义出的PMHF目标值。第8列为分解之后各自路径的失效概率值。第9列为基于 两个独立路径的失效概率值计算得到的基于布尔运算的总体失效概率值。这样，只要保证分解之后计算得到的总体失效概率值（第9列）小于等于分解之前的 失效概率值（第5列），即可满足原PMHF要求。

从以上结果可以看出，分解之后的最大失效可能性小于分解之前的PMHF计算出的最大失效可能性。因此在这种情况下即使在ASIL分解过程中执行PMHF分解，依然可以达到分解之前对于PMHF要求的结果。

3 局部安全功能的需求分解

其次，针对不完整安全功能的需求分解情况。因为分解是针对的部分的安全功能，因此分解前最大的失效率为原来的失效率可能性的1/3。此处1/3并没 有特殊含义，只是考虑如果不能全部继承来与安全目标的PMHF的目标值而得到的一个小于原目标值的某一个值。



从上表4结果可以看出，分解之后的最大失效可能性小于分解之前的PMHF计算出的最大失效可能性。因此即使以上情况下的ASIL分解过程中执行 PMHF分解，依然可以达到分解之前对于PMHF要求的结果。
但是并不是所有情况都可以得到以上结论。下表中调整原有的最大失效率为安全目标PMHF目标 值得1/130的分析计算结果。



从上表5结果可以看出，分解之后的最大失效可能性大于分解之前的PMHF计算出的最大失效可能性。因此在这样针对一部分安全功能需求分解过程中执行PMHF分解，并不能一定可以达到分解之前对于PMHF要求的结果。

分解之前的最大PMHF目标值在原有基础上缩小130倍，那如果针对后面的PMHF目标也同样缩小130倍，结果如何？表6针对这种情况进行了分析计算。

从表6结果可以看出，在这样针对一部分安全功能ASIL分解过程中执行PMHF分解，如果分解后的PMHF目标即使缩小到一定程度，如果对应的分解之后的PMHF对应缩小同样的倍数，仍然可以达到分解之前对于PMHF要求的结果。

对于以上两种情况，当分解后路径的工作时间偏大时，也可以导致分解之后的总体最大失效可能性值大于分解之前的最大失效可能性值，从而不满足PM⁃ HF的目标要求。但是这种情况在常规车用控制器开发中并不普遍，因为对于冗余路径的时间要求并没有那么大。

因此，表3、表4、表5和表6的计算分析结果表明，在保证足够独立的分解情况下，不论进行整个安全目标的PMHF的分解，还是部分PMHF目标值得分解，只要保证分解之后的失效概率值小于等于分解之前的失效概率，进行PMH分解并不会违反原有的要求。此处，虽然本文撰中多次使用PMHF的分解字样，实际上所表达的含义是在进行了ASIL分解之 后对于子系统的PMHF值的定义或者分配。从以上计算可以看出，我们进行比较的一直是失效概率值（P，P=λ×T），而非失效率值（PMHF/λ）。

4 结束语

ASIL分解是工程人员对于需求分解的通俗称呼， 其分解过程的关注重点并不分解硬件随机失效的应对举措。而硬件随机失效在需求分解中所做的是根据分解关系把分解前总体失效概率指标分配给分解后的功能元素。
基于上述表格的计算分析，那么不进行分解的理由至少可以认为含有如下两项。

（1）上表结果表明，依据同样的倍率进行PMHF 分解后，得到的失效的可能性更低，这样就很可能造成过设计。从这点可以认为ISO26262在避免过设计，以规避没必要的成本增加。此处，所谓的过设计是指如果在可以满足系统的安全或者性能指标的基础上，额外所做的设计内容。如果按照上文的（更严格的）PMHF指标要求分配给供应商，实际上分解之后的PMHF即使再大一些也可以满足上层的需求，而在底层软硬件设计中会加大额外的不必要的开发成本。

（2）避免进行分配之后（倍率缩小后）较小的PM⁃HF在分解过程中发生系统性失效，没有有效的倍率调整，造成最终能无法到达分解前PMHF的结果。