故障树手册(Fault Tree handbook)(2)

第二章 归纳法概论

2.1 概述

上一章我们定义了两种系统分析的方法——归纳法和演绎法。演绎法就是本书的主要讲述的故障树分析法。本章将主要讨论归纳法。

我们用一整章的内容对归纳法进行讨论,主要有两方面的原因,首先,这个方法提供了对故障树分析非常有用和有启发性的比较。其次,很多系统(可能是绝大多数),故障树分析方法的费效比(投入与最终改进)是没有保证的,归纳方法提供了一种有效的、系统的方法来识别和纠正不需要的或危险的情况。因此,故障树分析人员熟悉归纳法是非常有必要的。

在日常应用中,归纳法提供了对于“如果……会发生什么”这类问题的解答方式,更正式地说,这个过程包括假设一个或多个组件的特定存在状态,并进行分析以确定该条件对系统的影响。在可靠性研究中,“存在的状态”是一种故障。在其他领域,情况未必如此。

对于表现出任何程度复杂性的系统(即对于大多数系统),试图验证所有可能的系统危害或所有可能的组件故障模式(单独或组合)变得完全不可能。由于这个原因,我们将要讨论的归纳方法通常是受时间、金钱和人力的限制。将所有情况都分析到是负担不起的。

2.2 部件计数方法

一种可能是最简单和最保守(悲观的)的看法是,我们可以对一个系统做出假设,任何单个组件的故障都会导致整个系统的故障。在这个假设下,得到系统失效概率的上界特别简单。我们简单地列出所有组件及其估计的故障概率。然后将各个部分的概率相加,得出系统失效概率的上限。这个过程如下所示:

故障树手册(Fault Tree handbook)(2)

在这里,F代表系统的故障概率,等于fA+fB+....f_A+f_B+....。根据特定的应用,故障概率可以是故障率、不可靠性或不可用性(这些更具体的术语将在后面介绍)。

对于特定的系统,部件计数技术可以提供对系统故障概率的非常悲观的估计,而悲观的程度通常是无法量化的。对于特定的系统,部件计数技术可以提供对系统故障概率的非常悲观的估计,而悲观的程度通常是无法量化的。“部件计数”技术是保守的,因为如果存在关键组件,它们通常会出现冗余,因此没有单个故障对系统来说是灾难性的。此外,组件通常会以几种不同的方式偏离其正常工作模式,而这些故障模式通常不会对系统运行产生同样有害的影响。然而,让我们看看在图II-1中所示的两个放大器的简单并行配置下,零件计数方法会产生什么结果。

故障树手册(Fault Tree handbook)(2)

设放大器A的故障概率fAf_A10310^{-3},放大器B的故障概率fBf_B10310^{-3}。因为并行配置意味着系统故障只发生在两个放大器同时失效的条件下,并且假设这两个放大器彼此独立,那么该系统故障的概率就为103×103=10610^{-3}\times 10^{-3} = 10^{-6}。根据部件计数方法,组件概率等于简单的概率相加,因此“部件计数系统故障概率”为103+103=2×10310^{-3}+10^{-3}=2 \times 10^{-3},比10610^{-6}要高的多。

因此,如果系统是冗余的,部件计数法可以得到保守数量级的结果。当系统确实存在单次故障时,采用部件计数法可以得到较为准确的结果。因为所有组件都被视为单个故障(任何单个组件故障都会导致系统故障),所以故障之间的任何依赖关系都被覆盖,即,零件计数方法涵盖了由于共同原因造成的多个组件故障。最后,零件计数法也可用于敏感性研究;如果系统或子系统的故障概率没有影响或没有使用部件计数方法,那么它将不会影响或没有使用更精确的分析方法。

2.3 故障模式和效果分析(Failure Mode and Effect Analysis, FMEA)

虽然部件计数法非常简单,但是其分析结果往往过于保守,所以人们设计了很多更具体的技术方法。我们首先介绍故障模式和效果分析方法,我们先回头看上次的图II-1。

我们认识到该放大器系统会以若干种不同的方式失效,所以我们的首要任务是对各类失效模式进行定义。除了传统意义上的“开路”和“短路”失效之外,在我们的分析中还存在28种另外的模式。任何放大器的短路都是相对严重的故障模式,它经常会造成系统故障。我们现在拟制一个表格,它具备如下的信息:

  1. 部件设计(component desination)
  2. 故障的概率(Failure Probablity)(失效和故障的几率是一些使用上的特性)
  3. 部件故障模式(Failure Mode)
  4. 每种故障模式的比例(% Failures by Mode)
  5. 针对对系统总体的作用进行分类(Effects on over system)(最简单的分类是“关键”和“非关键”)

针对该冗余放大系统的结果如表II-1所示。

故障树手册(Fault Tree handbook)(2)

根据我们之前对于该放大器的使用经验,我们估计90%的放大器失效是因为“开路”模式,5%是因为“短路”模式,“其他”模式5%。我们知道不论何时放大器中的任何一个发生短路,则都会引起系统故障,所以我们把该故障的关键等级定义为“关键”,这表示该故障会导致总系统失效。另一方面,任何一个放大器发生“开路”故障,因为系统的并行设计,系统总体运行并不会受到影响。那么其他28种模式的关键程度是什么?在这个例子中,我们是保守的,我们认为他们都是关键的,它们任何一个发生都会导致系统出现故障。表中“Critical”那一列的数字是由第四列中合适的百分比乘以第二列中的10310^{-3}得到的。

根据这个表格,我们能更精确的计算单一故障原因下的系统失效概率,现在只考虑那些关键的故障模式。将表示关键的列(第五列)相加,我们能获得系统故障概率为5×105+5×105+5×105+5×105=2×1045 \times 10^{-5}+ 5 \times 10^{-5}+ 5 \times 10^{-5}+ 5 \times 10^{-5}=2 \times 10^{-4}。这个结果与部件计数方法得到的10310^{-3}相比不是那么保守了,部件计数的方法没有区分这些关键失效模式。这两种方法得到的结果差距会非常大,如同我们的例子一样,如果关键的故障模式在总的失效模式中占比较小,或许会有数量级的差距。

在FMEA(以及它的变量)中,我们能定义和合理的确认那些具备“非关键”作用的部件故障,但是我们可以分析考虑的的部件状态也是很有限的。方法的保守性要求未定的故障模式和不确定的效果都被看作是“关键”的。分析的目标是去定义单独的故障模式,以及去量化这些模式;不需要为这些目的做更多不必要的分析。

2.4 故障模式效果和关键性分析(Failure Mode Effect and Criticality Analysis, FMECA)

故障模式效果和关键性分析(FMECA),本质上类似于FMEA分析,但对失效的关键性进行更详细的分析,并描述了限制此类失效可能性的保证和控制。虽然FMECA分析不是发现危害的最理想的手段,但是却常常用来系统安全性分析的案例中。该方法有四个基本原则:

  1. 故障定义(Fault Identification)
  2. 故障的潜在作用(Potential Effects of the Fault)
  3. 现有的或计划的补偿和/或控制(Existing or Projected Compensation and/or Control)
  4. 探索结果的摘要(Summary of Findings)

这四个方面基本体现了FMECA方法的四列内容。第一列定义了可能的危害情况。第二列解释了为什么该情况是一个问题。第三列描述了为了补偿或控制该情况我们需要做什么。第四列表明了这个情况是否可控或者未来需要采取什么步骤。

在本章的内容中,读者应该注意到在所有这些归纳技巧中或多或少存在的一个最危险的陷阱——表格中的潜在错误。如果项目只是简单地填写表格,而不是进行适当的分析,那么这种做法将完全是徒劳的。因为这个原因。对分析师来说,最好不要把自己限制在任何事先准备好的形式主义中。另一点:如果系统非常复杂,那么一个分析师认为只有他本人才能对所有的系统故障及其对系统的影响进行正确和全面的调查,这是非常鲁莽的。这些技术需要一个良好协调的团队方法。

2.5 预先危险性分析(Preliminary Hazard Analysis, PHA)

到目前为止描述的技术大多是针对系统的,例如系统操作中的故障影响。这一章的主题是预先危险性分析,这是一个将工作环境中的“人”作用于系统,对潜在危害进行分析方法。

本节的主题是预先危险性分析(PHA),这是一种评估系统对工厂人员和其他人造成的潜在危害的方法。PHA的目标是确认系统内部固有的潜在危险条件,并确定可能出现的潜在事故的重要性或关键性。应尽早在产品开发阶段进行PHA研究。这将允许设计和程序相关的安全需求在早期进行考虑和开发,以对这些危险的情形进行控制,从而消除昂贵的后期设计变更。

PHA的第一步是定义潜在的危险元素或系统中的部件。该过程能借助于工程经验、工程判断的实践以及多次使用和改进后的大量的检查表来促进。PHA的第二步是对那些有可能从特殊的危险转化成潜在事故的事件进行定义。然后评估潜在事故的严重性以决定是否采用预防措施。

人们也已经开发出各列内容的格式,以帮助PHA的执行过程,我们列出了或许是最简单的一种:

  1. 第一列 —— 部件/子系统以及危险模式(Component/subsystem and hazard modes)
  2. 第二列 —— 可能的效果(Possible effects)
  3. 第三列 —— 补偿和控制(Compensation and control)
  4. 第四列 —— 调查结果和备注(Findings and remarks)

2.6 故障危害分析(Fault Hazard Analysis,FHA)

另一个方法,故障危害分析(FHA),它的使用场景比较特殊,它用于包含多个组织的工程,其中一个组织用于整合。该技术用于跨组织之间的界面衔接的故障有特别的作用。它最初在Minuteman III项目中起到积极作用。

一个标准的FHA表格如下所示:

  1. 第一列 —— 部件定义
  2. 第二列 —— 故障概率
  3. 第三列 —— 故障模式(所有可能的模式的定义)
  4. 第四列 —— 模式中故障的百分比
  5. 第五列 —— 故障的效果(跟踪到一些相关的接口)
  6. 第六列 —— 上有部件的定义,这些部件可以命令或初始化故障问题
  7. 第七列 —— 能导致次要故障的因素(包括临界等级)。该列应该包含一个有关针对敏感部件的运作的或环境的变量清单。
  8. 第八列 —— 附注。

FHA答题上和FMEA和FMECA接近,但是多了第六列和第七列的额外信息。

在后边的章节我们可以看到,第六列和第七列在故障树分析上有重要的作用。

2.7 双故障矩阵(DFM)

以前的技术关注的是单个故障的影响。考虑双失效影响的一种归纳方法是双失效矩阵(DFM);它只适用于相对不复杂的系统。为了说明它的用途,我们必须首先讨论错误分类的各种方法。以MIL STD 882 标准的基本分类如下表所示:

故障树手册(Fault Tree handbook)(2)

这样对系统做出了更完整的定义:

  1. 可忽略不计(Negligible)—— 对系统没有影响的功能损失。
  2. 边际(Marginal) —— 该故障会在一定程度上降低系统的性能,但不会导致系统不可用;例如,丢失两个冗余泵中的一个,其中任何一个都可以执行所需的功能。
  3. 临界(Critical) —— 此故障将完全降低系统性能;例如,使安全系统不可用的组件的丢失。
  4. 灾难性(Catastrophic)—— 这一断层将产生严重后果,可能造成伤害或死亡;例如,灾难性的压力容器故障。

分类将取决于先前假定存在的条件,并且可以随着假定条件的变化而变化。例如,假设一个泵发生故障,那么第二个冗余泵的故障就是临界故障。

上述粗略的分类可以通过多种方式进行细化。例如,在NERYA项目中,定义了六个故障类别,如表II-3所示。

Table II-3 NERVA项目的故障分类

故障分类 系统方面的表现
I 可忽略的
IIA 第二个错误事件导致过度到分类III(关键的)
IIB 第二个错误事件导致过度到分类IV(灾难的)
IIC 一个系统安全问题,它的效果取决于它所处的状况(例如备用现场电源故障,只要保持主要的非现场电源服务是开启的就不会出现问题
III 关键的故障,会导致任务取消
IV 灾难性的故障

为了描述DFM的概念,参考图II-2的的简单的子系统。在该模型中,阀门模块只能进行全开或全闭两种操作,然而可控的比例阀门还可以进行部分的开发或关闭。

故障树手册(Fault Tree handbook)(2)

让我们定义两种故障状态,并对它们进行分类:

故障状态 分类
需要时没有流动 4
流动无法关闭 3

我们开始考虑所有可能的部件故障和它们的分类。举个例子,如果阀门模块A(BVA)无法打开,我们将其归类为分类IIA,因为如果控制阀门A(CVA)也同样无法打开,我们将级联进入分类III。如果BVA无法闭合我们将分类IIB,因为如果BVB或CVB也无法闭合,我们将级联进入分类IV。这种类型的分析在表II-4所示的双故障矩阵中很方便地进行了系统化。

为了便于说明,我们填写了整个矩阵;对于一阶分析,我们只关注主对角线项,即单次失效状态。请注意,如果BVA打开失败,那么只有一种方法可以让第二次失败将我们级联到第三类;也就是说,CVA也必须失败才能打开。相反,如果BVA关闭失败,如果BVB或CVB也关闭失败,我们可以级联到IV类,这就是为什么表II-4给出了“两种方法”的原因。类似的考虑也适用于CVA、BVB和CVB的单次故障,这些重要的附加信息已经显示在矩阵的主对角线单元格中。

现在只关注单个故障,我们可以进行如下表所示的危险类别计数:

危险分类 发生的方式数
IIA 4
IIB 8

故障树手册(Fault Tree handbook)(2)

如何使用这些信息?一个办法是对如何控制或防范这些危险类别的描述和随后的审查。另一个应用是比较图II-2中显示的阀门配置和另一种设计,例如图II-3中显示的配置:

故障树手册(Fault Tree handbook)(2)

为了叙述简单我们用配置I指代图II-2的系统,用配置II指代图II-3的系统。在配置II中,我们定义了和配置I同样的系统故障状态;换句话说,“当需要时没有流动”是分类IV,“当关闭时流动了”是分类III。我们现在能提出这样的问题:“就我们所定义的各种危险类别的相对数量而言,哪种配置更可取?”配置II的双故障矩阵如表II-5所示。

故障树手册(Fault Tree handbook)(2)

通过比较这两种配置,我们可以看到,从级联到第III类的角度来看,它们是相同的,但是第II类配置有大约一半的方法可以级联到第IV类。所以,根据这种标准,配置II是更好的设计。如果差异不是很明显,也可以使用更正式的分析方法来获取更多信息(这些方法将在后面的部分中讨论)。

2.8 成功路径模式

虽然我们一直在研究“失效”,我们也可以等效的讨论“成功”来替代“失效”。我们给出了一个简单的等效案例,而后继续我们的失效理论。

考虑在图II-4中两个并联的阀门配置。该系统的分析可以通过单一故障(多因素故障概率被认为是可以忽略的)或考虑“成功路径”。让我们先从前者开始。

系统需求如下所示:

  1. 操作包含两个阶段
  2. 每个阶段中至少一个阀门必须打开
  3. 每个阶段最后两个阀门必须关闭

两个相关的部件故障模式是:在需要时阀门无法打开,以及在需要时阀门无法关闭。为了分析目的,让我们做如下的假设:

P()=1×104P(阀门没打开) = 1 \times 10^{-4}(每阶段)
P()=2×104P(阀门没关闭) = 2 \times 10^{-4}(每阶段)

其中PP表示概率,阀门被假设是完全相同的。

故障树手册(Fault Tree handbook)(2)

系统单故障分析可以用表II-6表示。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bzmsKM8R-1586401275373)(asserts/TableII-6.png)]

故障树手册(Fault Tree handbook)(2)

该系统故障概率为8×1048 \times 10^{-4}

现在让我们看看是否可以通过考虑可能的成功来复制这个结果。现在有三个已经定义的成功路径,这些路径我们可以通过口头或图表的方法详细说明。如果ROiR^{i}_{O}表示“阀门i成功开启”,RCiR^i_C表示“阀门i成功关闭”,并且P(Path i)P(Path \ i)表示第i个成功路径对应的成功概率,我们就有了

路径1:两个阀门在两个循环中都能正常工作。

故障树手册(Fault Tree handbook)(2)
路径2:一个阀门在第一个循环打开失败但另一个阀门在两个循环中功能正常

故障树手册(Fault Tree handbook)(2)

路径3:第一个阀门在第二个循环打开错误但是其他阀门两个循环功能正常。

故障树手册(Fault Tree handbook)(2)

用数字表示,系统可靠性可以由如下方式得出

RSYSTEM=(RORC)4+2(1RO)(RORC)2+2(1RO)(RORC)3=0.99880027+0.00019988+0.00019982=0.9991999718×104 R_{SYSTEM} =(R_O R_C)^4+2(1-R_O)(R_O R_C)^2+2(1-R_O)(R_O R_C)^3 \\ =0.99880027+0.00019988+0.00019982 \\ =0.99919997 \approx 1-8 \times 10^{-4}
(****的数学公式怎么不能用mathjax进行渲染啊)
这和以前的结果一样,但是能看出来,这种故障方法非常简便易行。

2.9 结论

虽然我们讨论的各类归纳法可以详细到任何想要的程度,但在实际工作中,它们大多扮演一个“概览”的方法。在很多应用中,这就是我们需要的。对于任何适度的复杂系统,所有部件失效模式的定义都是十分费力的,而且或许并不是必须做的过程。更糟糕的是,关于部件失效模式的可能的组合的定义是个更加苦难的任务。大体来说,对于没有明显功能影响的故障和发生概率可以忽略的故障进行分析是纯粹的浪费时间,在所有这些分析中,某一事件的后果必须与其发生的可能性进行综合评定。

第三章 故障树分析——基本概念

3.1 定位

在第一章中,我们介绍了两种系统分析方法:归纳法和演绎法。在第二章中,我们介绍了归纳法。第三章描述了演绎的基本概念和必要的定义,这是余下的文章的主题。

3.2 失效 vs 成功模式

系统的操作可以从两个方面考虑:我们可以列举不同形式的系统正常的功能,或者我们可以列举各种系统的失效。我们已经从第二章第八节的例子了解到这一点,图III-1描述了失效/成功的空间概念。

故障树手册(Fault Tree handbook)(2)

值得注意的是,成功空间(Success space)中的某些可识别点与失效空间(Failure space)中的某些类似点重合。因此,例如,可以认为成功空间中的“最大预期成功”与失效空间中的“最小预期失效”是一致的。尽管我们的第一个倾向可能是选择系统成功的乐观观点,而不是悲观的系统失败的观点,但是我们将看到这并不一定是最有利的。

从分析的角度来看,失败空间有几个主要的优点。首先,就什么是失败达成共识通常比就什么是成功达成共识更容易。我们可能想要一架飞得高、不用加油就能飞得远、速度快、载重量大的飞机。当这架飞机的最终版本下了生产线,其中一些功能可能已经妥协了,在进行通常的权衡。这种交通工具是否“成功”很可能是一个有争议的问题。另一方面,如果飞机在火焰中坠毁,毫无疑问这一事件构成了系统故障。

“成功”趋向于于系统效能相联系,许多输出,可用的角度,产品和市场元素。这些特质被通过许多连续的变量被描述,这些变量很难依据离散的事件建模,例如“阀门无法开启”,这个事件都描绘了失效空间的特性。(部分失效,例如阀门部分开启,因为其连续的可能性而应该看作一个不同的事件模型)。因此,失效事件,尤其是完全失效,其定义是相对容易的,然而,成功事件设立约束却相对困难。

另一个有利于使用失效空间的观点是,虽然从理论上讲,一个系统失效的方式和一个系统成功的方式都是无限的,从实践的角度来看,成功的方式通常比失效的方式多。因此,单纯从实践的角度来看,失效空间的总量规模小于成功空间的总量规模。因此,在分析中,根据失效空间进行计算通常更有效。

我们已经讨论了为什么分析人员在失效空间工作比在成功空间工作更有利。实际上,所有需要做的就是证明考虑失效空间可以让分析师完成他的工作,这一点在过去已经被证明过很多次了。为一个复杂的系统绘制树形图是一个昂贵且耗时的操作。当考虑到失效时,可能只需要构建一个或两个系统模型,如故障树,它涵盖所有重要的失效模式。当考虑到成功时,可能需要构建数百个系统模型来涵盖成功的各种定义。以失效空间为特征的事件简约性的一个很好的例子是民兵导弹分析。只有三个故障树被绘制对应于三个不希望的事件:意外的程序启动,意外的发动机点火,和故障启动。人们发现,仅对这三件事的仔细分析就涉及对整个复杂系统的全面概述。

为了帮助修正我们的想法,在失效空间中对一些日常事件(一个人开车去他的办公室)进行分析可能是有帮助的(参见图III-2)。

图III-2所指的“任务”是用汽车把X先生从他的家送到他的办公室。预期的到达时间是8:30,但如果X先生9点前到达办公室,任务将被认为是略微成功的。在“最低预期失效”下面是一些可能发生的小问题,但并不妨碍X先生在预期时间到达。9点到达标记为“最大预期失效”。在这一点和“最小预期失效”之间发生了许多事件,导致X先生的到达时间延迟半个小时或更少。让“最大可容忍失败”这一点与某些事故同时发生也许是合理的,这些事故对汽车造成了一些损害,造成了相当大的延误,但没有造成人身伤害。在这一点之上是越来越严重的事件,最终以死亡的灾难告终。

故障树手册(Fault Tree handbook)(2)

注意,像“雨刷不工作”这样的事件应该根据当时的自然环境来定位到对应等级。

像图III-2这样的图表也可以用来确定事件,例如,一架商业客机的生产。“最小预期失效”这一点将对应于所有规范的实现,而下面的这一点将表明某些规范已经超出了满足的要求。“最大预期失效”对应的是一个折衷点,在这个点上所有的规格都没有被满足,但这些差异还没有严重到以物质的方式降低飞机的销售能力。“最大可容忍失效”点对应于建造该飞机的公司的生存点。超过这一点,只有无法忍受的灾难才会发生。一般来说,故障树分析致力于识别和评估此类灾难性事件和完全失效。

3.3 非期望事件的概念

故障树分析是一种演绎式失效分析,它关注于一个特定的不希望发生的事件,并提供了一种确定该事件原因的方法。不希望发生的事件构成了为系统构造的故障树图中的顶层事件,并且通常由如上所述的完整的或灾难性的故障组成。仔细选择最重要的事件对分析的成功非常重要。如果太笼统,分析就变得难以处理;如果它太具体,分析就不能提供足够广泛的系统视图。故障树分析可能是一项昂贵且耗时的工作,其成本必须与与相关不期望发生的事件相关的成本进行比较。

现在我们给出一些顶层事件的例子,这些事件或许对于故障树分析的初学者很适合:

  1. 当一个潜艇在水下时发生灾难性事件。在这个分析中,我们或许要区分“恶意攻击导致的失效”和“常规功能性失效”。
  2. 商用客机的坠毁导致数百人死亡。
  3. 和反应堆在需要遏制喷淋系统工作时没有喷淋。
  4. 非合理的使用核武器。
  5. 在宇宙探索程序中造成航天器或宇航员的损失。
  6. 当拧开关钥匙后汽车不启动。

3.4 总结

在这一章,我们讨论了“失效空间”和“非期望事件”的概念,这些概念是故障树方法的基础。在下一章中,我们将定义故障树分析并开始详细介绍入口和故障事件,这些是组成故障树的重要部分。