引言
众所周知，功能安全旨在解决电子电器系统失效带来的对人的伤害问题，其核心就是对电子电器系统的失效进行合理的分析/控制，使得失效风险达到可接受的状态。那这里的失效主要包含系统性失效和随机失效两种。本文尝试对于随机失效展开介绍并探讨对其控制的措施。对于系统性失效，后续再逐步在其他文章中展开探讨。
目录
01 认识随机失效
02 随机硬件故障的分类
03 随机硬件故障的度量
04 随机硬件故障的控制
1 认识随机失效
在进入随机失效介绍之前，我们先来认识一下什么是随机失效？什么是系统性失效？
随机失效（Random Faults）指在产品的生命周期内，非预期发生并服从概率分布的失效。它是偶发的且不可避免的，其对象一定是硬件（软件不存在随机失效，软件的失效一定是系统性失效）。比如内存数据的位翻转，电阻的开路、短路、阻值漂移等等。
系统性失效（Systematic Faults）指以确定的方式与某个原因相关的失效，一旦其trigger event发生就会百分百发生的失效，系统性失效必须通过设计变更才能消除，系统性失效的对象包含硬件和软件。比如软件bug，硬件元器件参数设计/选择错误等。
从以上随机失效的定义来看，随机失效的对象一定是硬件，软件是不存在随机失效的，所以，接下来我们重点要研究的就是随机硬件失效，随机硬件失效是由随机硬件故障引起的。
2 随机硬件故障的分类
一般来说，所考虑的故障组合限定于两个独立硬件故障的组合，也就是说，认为功能安全目标的违反如果需要≥3个随机故障同时发生，即可认为该故障是安全的（除非基于功能安全概念或技术安全概念分析特别要求）。基于这种考虑，对于给定的功能安全目标和给定的硬件要求，随机硬件故障可被分为以下类别：
a） 单点故障；
b） 残余故障；
c） 可探测的双点故障；
d） 可感知的双点故障；
e） 潜伏的双点故障；
f） 安全故障；
图片来自GB/T34590 附录B.1: 硬件要素的失效模式类别
图片来自GB/T34590 附录B.2: 失效模式分类流程图示例
我们先来看一下这几类故障的定义。
单点故障：
即此故障的单独发生就可以导致安全目标的违反；没有任何安全机制预防其违背安全目标。这个可以理解为只进行了正常的功能设计考虑，未进行元器件失效诊断设计。例如，一个未被监控的电阻，如果其开路会违反安全目标，则其开路故障就是一个单点故障。
残余故障：
该故障也可以直接导致安全目标的违反，和单点故障的区别是，该故障有对应的安全机制预防其部分情况下失效违反安全目标，但该安全机制的诊断覆盖率达不到100%，残余故障就是指未被安全机制覆盖的一部分故障。
比如针对一个传感器，假设其有效设计量程为[0~100]，为防止其出现超出量程范围的失效，可以设计一个安全机制：对传感器测量数值进行check，如果发现其超出有效量程[0~100]，则判定其失效，这个安全机制可以覆盖传感器超出量程的随机失效，但无法覆盖传感器在有效范围之内出现卡滞、偏移等失效，这种情况下的卡滞、偏移等就属于残余故障。
可探测的双点故障：
该故障可以促使安全目标的违背（可以理解为对安全目标的违背有贡献，但仅发生该故障无其他故障的场景下，不会违背安全目标）。
与另外一个独立硬件随机故障同时发生，才能导致安全目标的违背。
同时，该故障可被安全机制所探测并提示出来，防止其发生潜伏的情况
以电子转向柱锁（其功能是：为了防止车辆被盗，通常在车辆下电落锁之后，通过电子系统控制转向柱上锁，通过机械卡爪将车辆转向锁死，使车辆丧失转向/横向控制功能）为例，这个功能如果在车辆高速行驶过程中误作动，会产生非常严重的后果，因此安全目标是防止电子转向柱锁在车辆行驶过程中上锁，假设这个安全目标的违反需要两个独立的失效A和B（即随机硬件失效A导致电子转向柱锁电机被异常供电；随机失效B导致电子转向柱锁上锁控制指令输出；）同时发生才会导致安全目标的违反，假设对随机硬件失效A增加了安全机制，进行了探测并提醒（行车过程中如果转向柱锁电机被供电，则输出故障报警灯），则随机硬件失效A即为可探测的双点故障。
另外有一种情况，对于安全机制使相关项恢复到无故障状态的瞬态故障情况，即使驾驶员从未被通知故障的存在，此故障仍可被考虑为可探测的双点故障，比如在数据提供给CPU之前，瞬态的位翻转被错误探测和纠错码（EDC）纠正，并通过写回正确值得到后续纠正。
可感知的双点故障：
类似于可探测的双点故障，该故障也可以促使安全目标的违背。
同样需要另外一个独立硬件随机故障同时发生，才能导致安全目标的违背。
该故障发生后，一定的时间内，可以被驾驶员感知到。
举例：如某一故障发生后，显著的影响到功能（功能丢失/功能降级等），让驾驶员感知到该故障，且该故障单独发生，可促使安全目标违背，但需要另一个故障同时发生才违背安全目标，该故障即为可感知的双点故障。
潜伏的双点故障：
类似于可探测/可感知的双点故障，该故障也可以促使安全目标的违背。
同样需要另外一个独立硬件随机故障同时发生，才能导致安全目标的违背。
该故障不能被安全机制探测出来，且不能被驾驶员感知到，直到第二个独立故障发生前，系统始终可以运行，且驾驶员也不知道发生了故障。（这种情况下，即在发生了该故障后，未被发现和修复前的一段时间内，第二个独立故障实际上已经转化为单点故障）。
继续以上述电子转向柱锁为例，假设针对随机失效A不设计任何安全机制，那么一旦出现随机失效A，电子柱锁的异常供电将会持续发生，这时候驾驶员也不会有任何提醒和感知，这样的情况下，在随机失效A持续时间段内，仅需要随机失效B发生就会导致安全目标的违反，此时随机失效B转化为单点失效，而随机失效A即是潜伏的双点失效。
安全故障：
安全故障包括以下两种：n>2的多点故障（即需要同时出现≥3个独立硬件故障，才会导致安全目标的违反），可认为是安全故障，除非安全概念或技术概念中特别指出该故障与安全目标的违背有关联；与安全目标违背无关的故障。
举例：a）对于被EDC和循环冗余（CRC）保护的内存，被EDC纠正的单个位故障不通过信号指示出来。该故障对安全目标的违背得到了EDC预防，但未通过信号指示出来。如果EDC逻辑失效，该故障被CRC探测到，系统被关闭。只有当闪存中存在单个位故障、EDC逻辑失效且CRC校验和监控失效时，才能发生对安全目标的违背，即同时需要3个故障（n=3>2），因此认为该故障为安全故障；b)通过三个电阻串联以克服短路情况下的单点故障问题，因为需要三个独立的短路才会违背安全目标（n=3>2）,因此认为该故障为安全故障。
图片来自GB/T34590
附录C.1:相关项中与安全相关的硬件要素的故障分类
3 随机硬件故障的度量
我们研究随机硬件故障的目的是能够有效地控制它，而控制随机硬件故障的前提是能够有效度量随机硬件故障，这一部分我们主要来研究如何度量随机硬件故障。
上面已经说明了随机硬件故障的分类，假设所有的故障都是相互独立、没有重复和遗漏、且遵循指数分布的，则每个安全相关的硬件要素的失效率λ可按如下等式来表述：
λ\= λSPF + λRF + λMPF +λS
（来自GB/T 34590附录C.1）
其中：
λ SPF —— 与硬件要素单点故障相关联的失效率；
λ RF —— 与硬件要素残余故障相关联的失效率；
λ MPF —— 与硬件要素多点故障相关联的失效率；
λ S —— 与硬件要素安全故障相关联的失效率。
与硬件要素多点故障相关联的失效率lMPF = lMPF,DP + lMPF,L（λ MPF， DP —— 与硬件要素可察觉或者可探测的多点故障相关联的失效率；λ MPF， L —— 与硬件要素潜伏故障相关联的失效率）
残余故障的失效率估算：
分配给残余故障的失效率可以用避免硬件要素的单点故障的安全机制的诊断覆盖率来确定。可按如下进行残余故障的失效率的保守估算：
来自GB/T 34590附录C.3
式中：
λ RF， est —— 关于残余故障的估算的失效率；
KDC,RF（也称为DCRF） —— 关于残余故障的诊断覆盖率， 用百分比表示。
这里的KDC,RF可根据GB/T34590-5 附录D获得参考。
潜伏故障的失效率估算：
分配给潜伏故障的失效率可以用避免硬件要素的潜伏故障的安全机制的诊断覆盖率来确定。可按照如下进行潜伏故障的失效率的保守估算。
来自GB/T 34590附录C.4
式中：
λ MPF,L,est —— 关于潜伏故障的估算的失效率；
KDC,MPF,L (也称为DCMPF,L) —— 关于潜伏故障的诊断覆盖率， 用百分比表示。
这里的KDC,MPF,L可根据GB/T34590-5 附录D获得参考。
上面主要是介绍失效率的估算方法，失效率是随机硬件故障度量的基础。接下来开始介绍随机硬件故障的度量。随机硬件故障的度量分为两类指标：硬件架构指标和随机硬件失效指标。
1> 硬件架构指标：
硬件架构指标包括了单点故障度量（Single-point faults metric, SPFM）和潜在故障度量（Latent-fault metric, LFM）两部分。简单来说硬件架构度量指标就是衡量我们的硬件架构对应单点/残余故障和潜伏故障的有效性。SPFM和LFM的值越大，代表能诊断出来的故障比例就越高，功能安全做的事情就是让故障更多地被诊断出来，保证功能是安全的。
单点故障度量（Single-point faults metric, SPFM）
这个度量反映了相关项通过通过安全机制覆盖或通过设计手段（主要为安全故障）实现的对单点故障和残余故障的鲁棒性。高的单点故障度量值意味着相关项硬件的单点故障和残余故障所占的比例低。
—在度量中考虑的相关项安全相关硬件要素的λx总和。
单点故障度量的图示：
潜伏故障度量（Latent-fault metric, LFM）
这个度量反映了相关项通过安全机制覆盖、通过驾驶员在安全目标违背之前识别或通过设计手段（主要为安全故障）实现对潜伏故障的鲁棒性。高的潜伏故障度量值意味着硬件的潜伏故障所占的比例低。
来自GB/T 34590附录C.8
潜伏故障度量的图示：
2> 随机硬件失效指标：
随机硬件失效指标，通常用：
PMHF (Probabilistic Metric for random Hardware Failures)来评估，需要依赖于定量分析工具，比如FMEDA（Failure Mode, Effects, and Diagnostic Analysis）。
PMHF (Probabilistic Metric for random Hardware Failures)
PMHF是度量随机硬件失效的一个重要指标，它表征随机硬件失效导致违背安全目标的残余风险是否足够低。
综上，随机硬件失效度量主要依赖硬件架构的两个指标和随即硬件失效率指标PMHF。硬件架构的两个指标是百分数，是相对值，体现硬件架构的设计水平；而随机硬件失效率指标PMHF是一个绝对值，包括了单点/残余故障失效率、潜在故障失效率等。
各ASIL等级的指标要求如下（参考GB/T 34590-5）：
4 随机硬件故障的控制
有了上面了的度量指标，我们就可以对功能安全相关的硬件要素系统进行定量的评估计算了，那接下来的问题是，如果这些度量指标不达标，我们该怎么办呢？这就涉及到了随机硬件故障的控制。
随机硬件故障控制最核心的措施就是增加安全机制，提升对系统单点故障/残余故障和潜伏故障的诊断覆盖率，从而降低整体的失效率。
通过安全机制提升诊断覆盖率的方法，涉及了很多不同的技术和方法，但总结起来，无非是从以下几个方面来考虑：
1> 合理阈值阀值的限定：根据一些特性/需求，分析值的范围，设定合理的阈值范围，出现阈值外的值，认定非法并制定安全响应的措施。
2> 冗余：提供另外的一套或多套要素，可以实现对安全硬件要素的功能替代，在出现失效时，可以通过比较或投票机制，识别失效并采用替代要素保证功能正常。
3> 测试/自检：通过设计一些测试用例并内置到系统要素中，实现对系统硬件要素的测试和自检，并及时报出故障并提醒或自动修复。
虽然整体的设计原则比较简单，但要设计一个好的安全机制还是对设计者有非常高的要求的，需要具体问题具体分析，安全机制的设计方案也是多种多样，如何在众多的安全机制方案中选择最优或更优的解，也是设计者需要面临的考验。限于文章篇幅，本文就不再作展开。后续计划在另外文章中，通过一些案例形式，来进一步和大家一起探索。文章的目的是交流探讨，笔者也是在不断研究和探索中，有些内容，理解上可能并不一定完全正确，如有错误，还请大家帮忙指正，共同学习共同进步。
作者简介—马小龙
某OEM整车功能安全工程师，9年汽车领域从业经验，获得了莱茵功能安全工程师认证；目前致力于公司级功能安全流程体系的建立和完善；参与了智驾/转向/制动/电驱动/电池管理等功能安全系统的功能安全开发/技术支持/评审；熟悉功能安全/预期功能安全方法论。
作者：马小龙
文章来源：sasetech
推荐阅读
更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
