文章目录
本文原书为Fault Tree Handbook，所有者为美国核管理委员会（NUREG-0492)。当时学习的时候感觉这本书很不错，故障树对于系统分析很有用，而国内的参考资料相对比较少，就把这本书翻译了下来。本文的英文版所有权归原书发行单位所有，中文翻译的所有权归作者赵星汉所有，未经作者许可，任何人不得将本文用于盈利。
前言
1975年以来，一个题为“系统安全和可靠性分析”的短期课程向200多名核管制委员会人员和承包商开展。本课程由系统科学研究所的David F. Haasl教授、华盛顿大学的Norman H. Roberts教授和美国核管理委员会概率分析人员负责讲授，是概率分析职员组织（Probabilistic Analysis Staff）资助的风险评估培训计划的一部分。
本手册不仅可以作为系统安全可靠性课程的教材，而且还是一份关于故障树构建和评估的文档。这本书的出版是按照风险评估审查小组报告(NUREG/CR-0400)的建议，其中指出，故障/事件树方法应在核管理委员会内外得到更广泛地使用。希望该文件有助于系统分析中故障树方法的制度化和系统化。
（赵星汉同学：在本书中，使用了Fault和Failure两个概念，为了便于区分，在翻译中，我们将Fault翻译为“故障”，将Failure翻译为“失效”。)
第一章 系统分析的基础概念
1.1 系统分析的目的
这本书的主要关注是故障树的相关技术，这是一种获取系统信息的系统化方法。按照该方法获取的信息可以用于决策。因此，在定义系统分析之前，我们应该对决策的过程做一个简要的检查。决策是一个非常复杂的过程，我们将重点介绍有助于系统分析的方面。
大体上来说，我们所做的任何决策都基于我们对目前情况的了解。这种知识部分来自我们对相关情况的直接经验，或来自类似情况的相关经验。通过适当的实验和对结果的分析，我们的知识能得到一定的提升。从某种程度上来讲，我们的知识基于推测，而推测则与我们对事务的看法是乐观的还是悲观的有很大的关系。例如，我们可能会相信，“在这个最好的世界里，一切都是为了最好的”；或者，反过来，我们可能相信墨菲定律:“如果任何事情都能变糟，那它就会变糟。”因此，知识可以通过几种方式获得，但在绝大多数情况下，不可能获得所有相关的信息，因此也几乎不可能消除所有的不确定性因素。
当所有相关信息都收集起来之后再做出决定，这本身就是一个没有意义的假设，这与我们日常生活中被迫做出决定的时机相差甚远，我们一般不可能有十分完备的信息，我们都要面临最后的期限要求。此外，由于在必须作出决定时通常不可能获得所有相关的数据，所以我们根本很难完全弄清楚该决策所导致的全部后续影响。模型I-1 给出了该思想的原理。
由于决策过程往往伴随着时间的限制，因此我们需要区分“好的决策(good decision)”与“正确的决策(correct decision)”。当我们对一件事情进行总结时，我们能判断决策是“好的决策（good decision）”或者“坏的决策（bad decision）”。例如，我买了1000股XYZ公司的股票。六个月后，我发现股票涨了20点，则我之前的决策就是“好的决策（good decision）”。但是，如果股票在这段时间下跌了20点，那么之前的决策就是个“坏的决策（bad decision）”。尽管如此，如果在我做决策时，当时所有可用的信息都表明XYZ公司有一个美好的未来，那么即使后续股票下跌，当初买入股票的的决定依然是一个“正确的决策(correct decision)”。
做出正确的决策（correct decision），需要以下几个方面：
- 识别所有与决策有关的信息。
- 建立能获取相关信息的系统流程。
- 对按流程所获得的信息进行合理的评估和分析。
人们对系统分析有很多种定义。本书的作者们进行过长时间的思考和讨论，选择了如下的定义：
系统分析是指为了制定决策，对特定系统信息进行有序、及时的收集和调查的过程。
(System analysis is a directed process for the orderly and timely aquisition and investigation of specific system information pertinent to a given decision.)
根据上边的定义，系统分析的主要功能是对信息的收集，而不是生成系统模型。这本书的重点（至少在开始阶段）将放在过程（信息的获取）上，而不是产品（系统模型的生成）上。该重点的划分是十分必要的，因为缺乏科学有序的信息收集过程，对应的系统模型往往并不准确和完备。
在信息收集开始前，我们必须确定哪些信息是与决策有关系的。什么信息是必须（essential）的？什么信息是需要（desirable）的？这一点看起来十分简单和自然，但是令人惊讶的是，很多情况下人们并没有遵循这条基本原理。图I-2描述了可能发生的情况。
我们假设图中的大圆表示做出正确的决策所必须的信息。现实中的情况往往是：乔恩斯教授是一个该领域中的一个子领域A的资深专家，并且资金充足。当他开始他的调研后，他的调研发现了一些未知的有意思的问题，这些问题位于A子领域的A1分支上。对A1的调研又导致了A2，如此往复。注意，乔恩斯教授的调研工作使他得到的信息距离实际的决策需要越来越远。阿尔法实验室在一个子领域B的科研中具有重要的位置，调研工作往往从B1导致B2，同样的事情一直在不断发生。当需要决策的时候，必要的决策支持信息并不完备，然而如果有适当的引导，他们的工作本应该是可以获得充足的决策所需的信息的。
一个自然的决策过程如同图I-3所示，A模块表示一个确定的实体。初始阶段，一个实体就像一本“闭合的书”，但是通过实验和调查，我们将会建立对该实体的感知。这时我们会得到代表这个实体的模型B。下一步，通过分析该模型，我们能得到一些结论，这些结论将作为我们决策的基础。因此，我们的决策实际上是我们所建立的模型的衍生物，如果模型建立的不正确，则决策也将是错误的。很明显，决策过程的核心应该是保证所建立的模型应尽可能的与实体相一致。
1.2 系统的定义
在前文中，我们定义了“系统分析”，但什么是“系统”呢？我们常常会说到“太阳能系统”，“政府系统”，“通信系统”等，在这种语境下，系统指的是多个不同种类元素通过某种组织形式存在于一起，它们以某种方式相互作用，这种方式可能是定义好的，也可能是没有完善的定义的。于是，我们可以对系统做出如下的定义：
系统是由相互作用的离散元素集合所构成的确定性实体。（A system is a deterministric entity comprising an interacting collection of discrete elements.)
从实践的角度来看，这个定义并不是很有用，在一些特定的情况下，我们必须指定系统执行的哪些方面是需要着重关注的。系统执行某功能，而对特定执行的状态的选择将决定进行何种分析。例如:我们是否对系统是否成功完成某些任务感兴趣;我们感兴趣的是系统是否会以某种危险的方式失效;或者我们感兴趣的是，该系统是否会比最初预期的成本更高?在这三种情况下，正确的系统分析很可能基于不同的系统定义。
“确定性”一词在定义中意味着所讨论的系统是可定义的，试图对无法明确定义的事物进行分析是完全徒劳的。诗人但丁将地狱看作一个系统，并将它分成了很多令人痛苦的层次，但是，从实践的角度来看，这种系统是很难像家里的管道系统那样被准确的定义。此外，一个系统应该有一些目标——它必须实现某种功能。例如运输系统，热水管道循环系统，地方学校系统等，它们都有自己明确的目标，而不是简单的存在于虚构中。
定义中的离散元素同样也必须是可定义的。例如，太平洋潜艇舰队中的独立潜艇就是其中的可定义元素。需要注意的是，离散元素本身也可以被看成系统。比如说，潜艇由推进系统，导航系统，船体系统，管道系统等组成，它们又可以再向下进一步的划分。
从系统定义中可以看出，系统是由相互作用的若干部件和子系统组成。这些元素间的相互作用可能会非常复杂，这就决定了一个系统的复杂程度不仅仅是这些部件元素相叠加这么简单，这是本书将不断强调的重点。此外，如果系统任何部件的物理特性发生变化（例如，是故障导致的），系统本身也会产生变化。这是一个重要的观点，在某些设计中，假设引入的故障会导致系统的原先的设计发生变化，那么则应针对变化后的新系统开展进一步的分析。以一架四翼飞机为例。假设一个引擎失灵。我们现在有了一个与原来大不相同的新系统，新系统的着陆特性与原系统相比发生了巨大的变化。假设有两个引擎失灵，则会出现六个不同的可能的系统，这取决于哪两个引擎出了故障。
也许在系统定义中必须做出的最重要的决定是如何在系统上设置外部边界。想象一下放在桌子上的电话，简单地将系统定义为仪器本身(耳机、线和支架)就足够了吗？还是应该包括连接墙上插孔的线路？电线杆的外线呢？电线杆上的接线盒呢？那么，由本地、全国乃至全世界的电话系统所组成的庞大而复杂的线路、交换设备等又该怎么办呢？很显然，必须建立系统的外部边界，并且应该根据系统性能的所关注的方面进行决策。如果当前的面临的问题是电话声音太小，那么分析所建立的系统外部系统边界将比较小。如果该问题涉及到线路上的射频传输，则外边界范围将变得很大。
系统定义中的另一个重心是建立分辨极限（limit of resolution)。在电话的例子中，是否应该延申我的分析范围到每个组成设备的独立的部件（螺丝，信号发射器等）？或者是否必要进一步延申到分子层面，或者原子层面或者更低的层面？总而言之，系统分析应该细化到何种程度，与我们需要决策的内容相关。
我们目前所讨论的内容可以用图I-4表示，图中的外部的虚线将系统与它所处的环境分隔开来，这条虚线构成了一条系统的外部边界。我们将系统划分成A，B，C等几个子系统，这样做的目的将在适当的时候讨论。还要注意，为了便于分析，其中一个子系统F已经被分解为更小的“子—子系统”。这就构成了对系统内部边界的选择。F中各个子子系统，以及a、b、c等子系统，就是系统的定义中所指的“离散元素”。
在某些特定的情况下选择适当的系统边界是一件至关重要的事情，因为外部边界的选择决定了分析的全面性，而分辨极限的选择则限制了分析的细节。该问题的几个方面将在这里简要的说明，并将在整本书中进行强调，特别是在各类应用。
到目前为止，我们讨论的系统边界都是物理边界。在许多情况下，在系统上设置时间或类时间的边界也是可能且必要的。比如说一个男人，他习惯每两年换一辆新车。在本例中，系统是车，我们感兴趣的方面是车的保养策略。很明显，在两年时限的时间的边界内，他的维护策略就是有一件事，它将与一个习惯于将车开到报废的男人所采取的策略有很大的区别。在某些应用中，系统的物理边界实际上可能是时间的函数。这方面的一个例子是，系统的时间边界表示不同的操作阶段或不同的设计修改，在每一阶段的变化或设计修改后，物理边界将被重新审查并可能发生变化。
系统分析人员还必须问这样一个问题:“所选择的系统边界是否可行？从分析的目标来看，它们是否有效？”要对一个系统得出某些结论，可能需要在外部边界中包含一个大的系统“容量”。这可能需要广泛而耗时的分析。如果没有足够的资金、时间和工作人员来完成这项工作，也就不可能有更有效的分析方法，那么就必须把外部边界向内收，减少预期从分析中得到的信息量。好比我担心我的电视接收情况，我可能希望在我的分析中包括电离层的状态，但这肯定是不可行的，行之有效的办法应该是尝试电视天线最佳的接收姿态。
分辨极限（内部边界）也可以从可行性和分析的目标来确定。建立一个针对电视机总体可靠性的有价值的研究，而不去关心微观和亚微观层面上发生的事情，是具备相当的可能性的。如果要计算系统总体故障概率，则分辨极限影包括可获取的各类组件故障。不管怎样，一旦选择了分辨极限，就定义了“离散元素”，我们所关心的也就成了这个层面上的相互作用，更低层面上的交互将被忽略。
我们现在可以看出来，系统的外部边界用于描述系统的外部输出（系统对环境的影响）和输入（环境对系统的影响）；分辨极限则用来定义系统的“离散元素”，以建立系统内部的基本交互作用。
具有相关技术背景的读者或许会发现我们的系统及其边界的定义类似于一个经典热力学过程，其中有一个实际的物理边界或一个虚构的边界，该边界用于隔离一定质量的物质（质量控制）或者一定体积的物质（体积控制），系统的输入和输出由进出有界区域的能量或质量来确定。我们把不与环境交换质量的系统叫做“封闭系统”，而在封闭系统中，不予环境交换能量的系统称为“绝热系统”或者“孤立系统”。一个曾研究过热力学问题，尤其是流体问题的学生，会对在尝试解决问题之前建立适当的系统边界的重要性留下深刻的印象。
充分的思考来正确分配系统的边界和分辨极限是十分必要的。一种最合适的说法是，系统的外部边界和分辨极限应该在系统分析前进行定义，并在分析的执行过程中同步修正。在实际情况下，由于在分析过程中信息的不断获取，系统的边界和分辨极限常常需要修改。例如，可能会发现系统结构图不像最初设想的那样详细。在任何分析中，系统边界和决议的限制，以及任何修改，都必须明确定义，并且应该体现在发布的报告中。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DLCYNknN-1586400226597)(asserts/FigureI-5.png)]
为了阐述内边界和外边界的其他方面，我们绘制了图I-5。内部的实线绘制的圆表
示我们的系统边界，我们考察该边界以内的事件发生概率，我们假设发生概率为阶或更高。如果系统边界扩大到图中的虚线位置，事件发生的概率为阶或更高。假设需要给图中实线部分的系统设计一个双重冗余，我们需要将事件发生的概率限制在阶，但是，假设边界设计的不正确（例如本来应该考虑虚线边界却只考虑实线边界内），我们忽视的事件发生的概率就会产生致命后果，我们就会产生错觉，认为我们的系统比实际情况要安全或可靠两个数量级。缺乏细致思考的可靠性计算往往会产生这样荒谬的数字，如或。较低的数字只是表明，系统不会以预先考虑的方式失败，而是以一种未被考虑的方式，以高得多的概率失败。
赵星汉同学：原文章里写的很难懂，这一段其实是说如果外边界划分的不正确，可能会把一些需要考虑的故障事件排除在设计之外，以至于在完成可靠性设计后，在我们考虑到的失效模式上是满足设计指标的，但系统却可能会以我们没有考虑的模式发生失效
1.3 分析方法
本书中，我们所关注的是某些正式的过程和模型。这些模型应该可以按照人类常规思维那样进行分类。人类常用的思维方式有归纳法和演绎法两种。这里有必要对两种方式各自的特点进行讨论。
1.3.1 归纳法(Inductive Approaches)
归纳法是从单独的个案中推导出通用性结论的方法。以一个特定的系统为例，我们假设在启动条件上有一个特定的故障，并试图确定该故障或条件对系统运行的影响，我们就构建了一个归纳的系统分析。因此，我们可以探讨某些特定的控制面损失如何影响飞机的飞行，或探讨预算中某些项目的取消如何影响学区的整体运作。我们也可以询问不插入给定的控制棒如何影响紧急停堆系统的性能，或者给定的初始事件(如管道破裂)如何影响工厂安全。
归纳系统分析的方法很多，我们将在第二章专门讨论其中最重要的方法。该方法的实例有:初步危害分析(PHA)、失效模式与后果分析(FMEA)、失效模式效应与临界性分析(FMECA)、故障危害分析(FHA)和事件树分析。
再次强调——在归纳方法中，我们假设一些可能的组成条件或初始事件，并试图确定其对整个系统的相应影响。
1.3.2 演绎法(Deductive Approaches)
演绎法是从一般原理推导至具体事件的方法。在演绎法中，我们假设一个系统以某种形式失效，我们试图找出是系统或者组件的什么行为模式导致了导致了这次失败。按照通俗的讲法，我们把这种方法叫做“夏洛克福尔摩斯”原理。福尔摩斯面对证据，需要重新再现引发犯罪的各类事件。事实上，所有成功的侦探都是演绎法的专家。
生活中常见的演绎法使用场景是事故调查。是什么事件链导致了“不沉之船”泰坦尼克号在首航的沉没？是仪器故障还是人为故障导致了一架商业客机坠毁在山腰上？
这本书的主题——故障树分析，也是演绎系统分析的一个例子。在这种技术中，假定了某些特定的系统状态(通常是故障状态)，并以系统的方式建立了导致这种不希望发生的事件的更基本的故障链。故障树分析的基本原理，以及与故障树的应用和评估相关的细节将在后面的章节中给出。
总之，使用归纳方法来确定哪些系统状态(通常是失败状态)是可能的;演绎方法用于确定给予者系统状态(通常是失败状态)是如何发生的。
1.4 风险与陷阱
在对系统的研究中，有一些危险的暗礁，这些暗礁限定了分析员必须航行的航线。大多数问题集中在界面的角色：子系统接口与规程接口。
1.4.1 子系统接口
大体说来，系统是一个子系统的综合体，这些子系统由一些不同的分包商和组织进行制造。每个分包商或组织都采取适当的步骤来确保其产品的质量。问题是，当把子系统放在一起形成整个系统时，从单独的组成部分来看，失效模式可能根本不明显。重要的是，在要集成的分析中使用相同的故障定义，另一个非常重要的方面是，系统边界和分辨极限必须清楚说明，以便识别任何潜在的隐藏故障或不一致之处。如果要对集成系统进行评估或量化，则应使用相同的事件标识符，以避免出现歧义。接口问题通常存在于控制系统中，最好不要将任何控制系统分割成“块”。具有控制系统接口的系统(例如，喷淋系统具有喷淋信号输入)可以用适当的“位置”进行分析，以便作为一个整体进行控制分析。这些“位置”或转移将在稍后的故障树分析讨论中进行描述。
1.4.2 规程接口
由于不同学科或不同工作领域的人持有不同的观点，所以经常会出现困难。这位电路设计师认为他设计的电路是完美的，是艺术与科学的结合，应该受到温和的操作和科学的维护。另一方面，用户可能不会这样。他把它扔在地上，踢它，粗暴的对待它。
一位作者年轻时曾被雇用为海洋制图员。原车间项目正在制订扫雷计划。绘图员被分成几组。有船体部分、线路部分、管道部分等等，每个部分都在自己的技术领域内愉快地工作。但是当一个制图员试图制定一个复合的隔间(陀螺的房间,在这种情况下),发现船体特性和管道设备是经常不相容,与通风管道线路和管道经常矛盾,事实上,船员不能正常打开房间门,因为下水道的位置在上层甲板。这个实践证明了对系统集成的明确需求。
其他的冲突很容易想到:工程主管期望从他的数学部分得到定量的结果，但却只得到了完善的存在证明;安全协调员在系统中安装了太多的安全设备，以至于可靠性人员根本无法让系统正常工作等等。
以操作人员和维护人员之间的接口为例，考虑每月进行5分钟的在线维护检查而停机的系统，假设由硬件故障导致的系统故障概率为每月。然后，按月计算，系统不可用的总概率是由于硬件故障而不可用和由于维护策略或
其中
请注意，由于我们的维护策略(每个月只有5分钟停机时间)导致的系统可用性的概率比由于硬件故障导致系统宕机的概率大两个数量级。在这种情况下，最好的维护政策就是根本不维护。系统分析者(系统集成者)必须有足够的知识积累，以便在已出现和将要出现接口问题时能够识别它们。