故障树手册（Fault Tree handbook)（3）

第四章 故障树的基本元素

4.1 故障树的模式

故障树分析可以简单的描述为一项分析技术，凭借一个特定系统的非期望状态（通常是一个安全方面的关键状态），该系统会根据环境和操作的上下文信息来找到非期望事件发生的所有可信途径。故障树本身是一种图形描述方式，这种图形方式描述了各类导致预定义的非期望事件发生的故障的并行和串行组合。（The fault tree itself is a graphic model of the various parallel and sequential combinations of faults that will result in the occurrence of the predefined undesired event.）这些故障可以是和部件硬件故障相关联的事件，人为的错误，或者任何其他可导致非期望事件的相关事件。因此故障树描述了基础事件的内部逻辑关系，这些基础事件导致了非期望事件，而这些非期望事件就是故障树的顶层事件。

很重要的一点是，故障树并不是一个系统所有故障或者导致系统失效的所有可能原因的模型。一个故障树由它的顶层事件所决定，这些顶层事件与一些系统的特定故障模式相对应。因此故障树仅包含导致顶层事件的那些故障。此外，这些故障并不是完备的——它们仅包含分析员评估的最可信的状态。

另一个需要指出的重点是故障树本身并不是一个量化的模型。它是一个定性的模型，但是大部分情况下可以被量化评估。当然这一特点几乎所有的定性模型都具备。故障树是一个特别方便进行量化的模型，这一事实并没有改变模型本身的定性性质。

故障树是一种被看作“门”的复杂实体，它们允许或禁止故障逻辑通过树。这些门表明了一个高级别事件发生所需要的事件间的关系。高等级事件是门的输出；而低等级事件是门的输入。门的符号表明了输出事件所需的输入事件的关系种类。因此，门有点类似于电路中的开关或在一个管道中的两个阀门。图IV-1是一个典型的故障树。

4.2 符号 —— 故障树的组成模块

一个典型的故障树由许多符号组成，这些符号在本章节中被详细的讲解，并总结在表IV-1中以便于读者查阅。

4.2.1 主要事件（PRIMARY EVENTS）

故障树的主要事件是由于这样或那样的原因没有被进一步开发的事件。如果计算顶层事件的概率，则需要提供这些主要事件的概率。主要事件主要分成四种，分别是：

4.2.1.1 基础事件(basic events)

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

这个圆表示一个基本的初始故障事件，该事件不需要未来的开发。换句话说，这个圆表明已经到达的分辨极限。

Table IV-1 Fault Tree Symbols 主要事件标识（PRIMARY EVENT SYMBOLS）

标识	名称	含义
	基本事件	不被进一步开发的基础初始故障
	条件事件	应用在任何逻辑门上的特定的条件或限制（大部分应用于优先与门（PRIORITY AND）和禁止门（INHIBIT））
	非开发事件	一个不被后续开发的事件，因为信息不足或后果不可用
.	外部事件	一个通常情况下被认为会发生的事件

门标识（GATE SYMBOLS）

标识	名称	含义
	与	如果所有输入是“故障发生”则输出也是“故障发生”
	或	如果至少一个输入是“故障发生”则输出也为“故障发生”
	异或	如果输入中恰好一个故障发生，则输出故障发生
	优先与	如果所有输入故障以某种已定义的顺序发生则输出故障发生（序列由绘制在门右边的条件事件表示）
	禁止	如果（单一）输入故障出现在使能条件下，则输出故障（使能条件通过绘制在门右边的条件事件表示）

交换标识（TRANSFER SYMBOLS）

标识	名称	含义
	转入	指示在相应的转出发生时(例如，在另一个页面上)，树将进一步开发
	转出	指示在树的这部分必须链接对应的转入

4.2.2.2 未开发事件

该图形描述了未进一步开发的特定故障事件，原因可能是该事件的后果不足，也可能是与该事件相关的信息不可用。

4.2.2.3 条件事件

椭圆用来记录应用于任何逻辑门的任何条件或限制。它主要用于禁止和优先与门。

4.2.2.4 外部事件

房子用于表示一个事件，通常预期会发生。例如，一个动态系统的相位变化。因此，房子符号本身不表示错误。

4.2.3 中间事件

中间事件是由一个或多个前因通过逻辑门起作用而发生的故障事件。所有中间事件都用矩形表示。

4.2.4 门

门有两种形式：与门和或门。所有其他的门都是这两种形式的变种。有一个例外(禁止门），门用一个盾牌和一个平的或弯曲的底座。

4.2.4.1 或门

或门用于显示仅当一个或多个输入事件发生时才会发生输出事件。一个或门可以有任意数量的输入事件。图IV-2显示了一个典型的双输入或门，其中包含输入事件A和B，输出事件Q。当事件A发生，事件B发生，或A、B都发生时，事件Q就发生。

重要的是因果关系从来不会穿越或门。这句话的意思是，对于一个或门，输入故障绝对不会是输出故障的原因。或门的输入与输出相同，但是更为明确的定义是导致的原因。图IV-3能更好的帮助理解这一观点。

图IV-3的子事件可以在后续进行开发，例如图IV-4所示：

但是，如下事件

是第一个或门的输出事件（下图）的对于一个特殊原因的再次声明。

检测绘制错误的故障树的一种方法是寻找因果关系通过或门的情况。这是一个缺失与门的迹象(参见下面的定义)，也是在进行分析时使用不适当逻辑的迹象

与门

与门被用于表示只有所有输入故障发生，输出故障才发生。一个与门可以有任意数量的输入。图IV-5描绘了一个典型的A，B两个输入事件，Q输出事件的两输入与门。事件Q仅在A、B两事件都发生的情况下发生。

对比或门，与门指定了输入与输出的因果关系，例如，输入故障共同表明了输出故障的原因。与门对于输入故障的前因没有任何作用。图IV-6显示了一个与门的示例。柴油发电机和电池的故障将导致所有现场直流电源的故障。

在描述与门的事件输入时，如果依赖关系影响系统逻辑，则必须将任何依赖关系合并到事件定义中。依赖项通常在故障“更改”系统时存在。例如，当第一次故障发生时(例如，图IV-5中的输入A)，系统可能会自动切换到备用单元。第二次故障，图IV-5的输入B，和假设已经就位的备用单元一起分析。在这种情况下，输入B（图IV-5）将被更精确的定义为“输入B导致A的发生”。

图IV-7中所示的与门的变体显式地显示了依赖关系，当其中一个故障的发生改变了系统的工作模式和/或压力水平，从而影响了另一个故障的发生机制时，这种变体非常有用。

也就是说，描述事件机制或前因的子树(//TODO:The translation is not clearly here)

与描述事件机制的子树不同。

对于一个与门，这个与门有多个输入，还具备影响输入事件间的系统逻辑的依赖关系，这些“被给与的”必须合并所有前边的事件。

禁止门

用六边形表示的禁止门，是与门的一个特例。该模型输出取决于输入，但是在输入产生输出之前，系统必须满足某些预设条件。预设条件以条件输入的形式存在。条件输入用描绘于门的右边的椭圆形表示。图IV-8展示了一个典型的禁止门，该门具有输入A，条件输入B，以及输出Q。仅当预设输入满足条件B，输入A的事件发生时，输出事件Q发生。

为了更好的说明这个概念，我们利用两个例子进行阐述，参见图IV-9。

1. 许多化学反应只有在催化剂的存在下才能完成。催化剂不参与反应，但它的存在是必要的。
2. 如果一条冷冻汽油管线构成一个事件，这个事件仅在温度$T$小于$T_{critical}$时发生，其中$T_{critical}$是汽油的冰点。在该案例中，输出事件是“冷冻石油管线”，输入事件是“低温的存在”，条件输入是$T<T_{critical}$。

有时，特别是在二次失效的研究中(见第五章)，会使用图IV-10中所示的另一种类型的禁止门。

在图IV-10中，单一的条件A对于输出Q是必要的，但是并不是充分的；例如，针对Q的发生，必须具备条件A，但是条件A的发生并不意味着Q一定发生。当右边椭圆形中的A条件发生时，只有部分情况下Q会发生。

我们上面描述的门是最常用的，现在是故障树分析领域的标准。然而，有时也会遇到一些其他特殊用途的门。

异或门

异或门是或门的一种特殊应用，该门仅在其中一个输入事件发生时，输出事件发生。图IV-11体现了两个不同的的方式来描述一个两输入的异或门。

在两个输入事件都发生被抑制的情况下，异或不同于常规的或门或者同或。因此，输出事件Q在A发生或B发生的情况下发生。正如我们将在第六章看到的，同或和异或的量化区分是如此的微不足道，所以区分它们是不必要的。在一些区别较为明显的特殊例子里，它可以在量化阶段解释。

优先与门（the PRIORITY AND-Gate）

优先与门是一个与门的特例，它仅在所有输入以一个特定顺序发生的条件下输出才发生。顺序经常在门的右边以一个椭圆表示。在实际使用中，定义一个序列并不是经常遇到。图IV-12展示了两个互相替换的方式来描述一个典型的优先与门。

在图IV-12中，输出事件Q仅在输入A和B都发生且A在B之前发生的时候发生。

转移符号（TRANSFER SYMBOLS）

引入三角形作为传输符号，是为了方便避免故障树中的大量重复。从三角形顶端引出的一条线表示“转进”，边上的线表示“转出”。一个门上的“转进”将链接它对应的“转出”。这个“转出”或许在另一张图纸上，将包含故障树描述门的输入的部分。

第五章 故障树构建基础

第四章定义和讨论了构成故障树的符号。在本章中，我们将介绍正确选择和定义故障树事件以及构造故障树所需的概念。

5.1 故障（Faults）和失效（Failures)

我们首先要区分“故障（Faults）”这个相对具体的词语和另一个比较通用的词语“失效（Failures）”。想象一个继电器，如果继电器在它端子外加电压时正常闭合，我们称之为“成功”。否则，如果闭合失败，我们叫这个继电器“失效”。另一种可能是继电器因为控制端的不正确的驱动导致继电器在错误的时间闭合。这明显不是继电器的故障；但是，继电器的非按时触发会导致整个电路系统进入到一个不合要求的状态。我们将把类似现象叫做一个“错误”，大体上来说，所有的故障都是错误，但是并不是所有的错误都是故障。故障是一种基本的非正常现象，然而错误是一个“高阶”的事件。

我们在考虑一个桥，这个桥可以偶尔打开来允许渡轮的通过。忽然，毫无征兆的，桥的其中一部分向上翻了几英尺。这不是桥的故障因为桥被下达了开启指令，而它确实打开了。但是，这个事件是一个错误因为桥接机制响应了桥接人员发出的不及时的命令。因此，这个桥接人员也是系统的一部分，是他的不按时的动作导致了这个错误。

在美国内战最早的一场战役中，包瑞德将军通过信使1号向他的一位军官发了一个信息。过了一段时间，情况发生了变化，他通过2号信使发送了一条修改过的消息。稍后，通过信使3号发送了进一步修改的消息。所有的信使都到了，但顺序不对。没有失败，但这样的事件很可能对战斗进程产生有害的影响——在这种情况下，确实如此。同样，我们有一个错误事件，但不是一个失败事件。

“错误”的正确定义不仅需要指定组件的非期望状态是什么，还需要指定它发生的时间。这些“是什么”和“什么时间”应该是输入到故障树中的事件描述的一部分。

5.2 故障发生与故障存在

在我们讨论几种不同的故障树门时，我们已经谈到了一组故障中的一个或多个故障的发生，或者一组故障中的所有故障的发生。根据系统的性质，故障可能是可修复的，也可能是不可修复的。在无法修复的情况下，发生的故障将继续存在。在可修系统中，必须区分故障的发生和存在。实际上，这种区别只在故障树量化中才重要(将在后面的章节中讨论)。从构造故障树的角度来看，我们只需要关注发生的现象。这相当于认为所有系统都是不可修复的。

5.3 被动部件与主动部件

在大多数情况下，我们能简单的把部件分成两种：被动的和主动的（也可以叫做准静态的和动态的）。被动部件或多或少地以静态方式对系统的功能作出贡献。这些部件相当于一个能量转移器的角色，将能量从一个地点转移到另一个地点（例如，一根传输电流的导线或汇流条，或者传输热能的气体管道），或者相当于一个传输负载的角色（例如一个结构成员）为了评估被动元件的运行情况，我们进行了应力分析、传热研究等测试。被动部件的进一步例子有:管道、轴承、轴颈、焊缝等。

主动通过以某种方式修改系统行为，以更动态的方式对其上级系统的功能作出贡献。例如，阀门的开启和关闭改变了系统的流体流动，开关对电路中的电流也有类似的作用。为了评估一个主动部件的操作，我们进行了操作特性的参数化研究和功能相互关系的研究。有源元件的例子有:继电器、电阻、泵等。

被动部件可以看作是“信号”的发送器。这种“信号”的物理性质可能表现出相当大的变化。例如，它可能是电流或力。一个被动成分也可以被认为是一个活动组件的输出成为另一个活动组件的输入的“机制”(如线路)。无源元件的故障将导致其“信号”无法传输(或者，可能是部分传输)。

相反，主动部件会产生或修改信号。通常，这样的部件需要一个输入信号或其输出信号的触发器。在这种情况下，主动部件起着“转移功能”的作用，这是电气和数学研究中广泛使用的术语。如果一个活动组件失败，可能没有输出信号或可能有一个不正确的输出信号。

举个例子，一个邮差（被动部件），它转移一个信号（信件）从一个主动部件（发件人）到另一个（接收人）。接收人之后将以某种方式告诉发件人信息它收到信了。

从数值可靠性来看，被动部件和主动部件的失效机率的区别是非常大的。根据WASH-1400的数据，主动部件的每个请求的失效概率要超过$1 \times 10^{-4}$（还有一种数据形式为超过3 \times 10^{-7}$每小时），而被动部件失效机率远小于该数据。实际上，这两类部件的可靠性一般相差二至三个数量级。

在上文中，主动部件和被动部件的定义适用于部件的主要功能；主动组件的故障(或被动组件的故障)适用于主功能的故障。(例如，如果我们试图根据“主动”或“被动”的定义对特定的失效模式进行分类，我们可能会有主动部件的“被动”失效模式，例如阀门破裂。)

5.4 部件故障分类：主要错误，次要错误和命令错误

故障树分析人员还可以将故障分为三类:主要错误、次要错误和命令错误。主要错误是指组件在其正常环境中发生的任何故障。例如：一个用于承压的压力罐，设计最大压力是$P_0$，但是因为焊接缺陷导致压力罐在承压$P<P_0$时破裂。

次要错误是指组件在非正常的环境中发生的任何错误。换句话说，部件在超出设计的正常工作环境中发生错误。例如：一个压力罐，设最大承受压力是$P_0$，结果在承压$P>P_0$时损坏。

因为主要错误和次要错误都是常见的错误形式，它们通常也被称作主要故障和次要故障。相反，命令错误涉及组件的正确操作，但在错误的时间或错误的位置；例如：由于一些上游装置发出的信号不成熟或错误，高速列车上的保险装置过早关闭。

5.5 故障机制、故障模式和故障效果

系统、子系统和组件的定义是相对的，并且依赖于分析的上下文。我们可以说，一个“系统”是被考虑的整体结构，它依次由称为“子系统”的从属结构组成，而子系统又由称为“组件”的基本构件组成。

例如，在压水堆(PWR)中，喷淋系统可能由两个冗余的加油喷淋子系统组成，它们将水从加油储水罐输送到容器中。每一个子系统依次由阀门，管道等组成，这些都是部件。在特定的分析中，系统、子系统和组件的定义通常是为了给出问题的层次结构和边界。

在故障树的构建过程中，故障效果，故障模式，以及故障机制在决定事件之间的相互关系时是十分重要的。当我们说起故障效果时，我们在考虑为什么这个特殊的故障是我们会感兴趣，例如，它作用于系统的效果是什么。当我们研究故障模式时，我们确切说明了部件故障的哪些方面值得关注。当我们列出故障机制时，我们考虑的是一种特定的故障模式是如何发生的，以及可能发生的相应可能性是什么。因此，失效机制产生的失效模式反过来又对系统的运行产生一定的影响。

为了说明这些概念，考虑一个控制发动机燃油流量的系统。见表与它们。所述的子系统由阀门和阀门执行机构组成。我们可以从系统、子系统或组件级别对各种可能发生的事件进行分类。有些事件在下表的左列中给出。例如，“阀门打不开”是子系统失效的一种机制，是阀门失效的一种模式，是执行机构失效的一种影响。

Table V-1 油路系统故障分析

事件描述	系统	子系统	阀门	执行器
当需要时子系统里没有油	机制	模式	效果
阀门打不开		机制	模式	效果
执行器控制杆捆绑			机制	模式
执行器控制杆腐蚀				机制

为了更清楚地区分机制-模式-效果，考虑一个简单的门铃系统及其相关电路，从系统人员、子系统人员和组件设计人员的角度出发。该系统的示意图如图V-1所示。

从系统人员的角度出发，系统故障模式有：

1. 当按动开关，门铃没响。
2. 没有按动开关，门铃却响了。
3. 松开开关，门铃还在响。

如果系统人员坐下列出由故障模式引起的故障机制清单，他能生成一个清单，这个清单对应子系统人员的故障模式，子系统人员将获得开关，螺线管单元，电池和导线。具体有：

1. 开关：
   • 无法闭合（包括接触不良）
   • 无法断开
   • 断开不完全，产生间或接触
2. 螺线管单元——当驱动后不响（包含通电后不能维持响声）
3. 电池——电量不足
4. 导线——开路或短路

再次强调，最后这个列表构成了系统人的故障机制和子系统人的故障模式。从部件设计人员的角度来看，它也是一个关于故障效果的列表。让我们试着想象一下组件设计人员会列出什么样的列表。参见表V-2

从上表可以看出系统故障模式组成了各种系统故障。在故障树技术中，有很多系统分析人员需要考虑的顶层事件。他将拿出其中之一的顶层事件来分析发生的直接原因是什么。这些直接原因将会是针对所选择的系统故障的直接故障机制。后面这些故障将成为子系统人员的故障模式，并将构成我们的故障树的第二级。我们以这种“直接原因”的方式，一步一步地进行，直到我们遇到部件故障为止。这些部件将是根据故障树的分辨极限所定义的基本原因。

如果我们从组件设计人员的角度考虑问题，那么树中所有较高的子系统和系统故障都代表了故障效果——也就是说，它们代表了特定组件故障的结果。组件设计人员的故障模式也就是组件故障本身。如果组件设计人员要构造一个故障树，这些组件故障中的任何一个都可以构成一个合适的顶层事件。换句话说，设计人员的“系统”就是组件本身。设计人员的故障树的低层级将由该故障的机制或原因组成。它们将包括质量控制效果，环境效果等。而且在很多情况下，利用它们进一步扩展系统人员的故障树的分辨极限是不值得的。

5.6 “直接原因”的概念

现在回到一个系统分析人员的视角，最开始，他会去分析系统（例如，考虑外边界），随后，选择一个要分析的特定的系统故障模式。这些故障模式构成了系统分析人员故障树的顶层事件。他第二步确定造成这些顶层事件的直接原因，必要原因和充分原因。这里需要强调一点是对于事件的分析，没有基本原因这一概念，而是使用直接原因或直接机制。这在后续的例子中是十分重要的观点。

顶层事件的直接、必要和充分原因现在被视为次顶层事件，我们继续确定它们的直接、必要和充分原因。这样做，我们将自己放在了子系统人员的位置，对于这一层级的人员，我们的故障机制就是它们的故障模式；也就是说，我们的次顶级事件对应它们的子系统故障树的顶级事件。

通过这种方式，我们沿着树不断地将我们的观点从机制转移到模式，并不断地接近我们的机制和模式中的更细的分辨率，直到最终，我们达到树的分辨率的极限。这个限制由这样或那样的基本组件故障组成。我们的树现在完成了。

为了更好的说明“直接原因”这个概念，我们来分析一下图V-2。

这个系统应该是这样操作的:A的信号触发A的输出，A的输出为B和C提供输入，B和C再将信号传递给D, D再将信号传递给E。A、B、C和D是被动子系统。
此外，子系统D需要一个来自B或C或两者的输入信号来触发它的输出到E。我们因此在系统的这一部分有了冗余。

图V-2可以被演绎成非常常见的系统。例如,它可以表示一个电气系统，其中的子系统是模拟模块(例如:比较器、放大器等);它可以是一个管道系统，其中A，B，C，D是阀门;或者它可以代表公司“指令链”的一部分。

我们选择其中一个关于输出的顶层事件“没有信号到E”，在分析中我们忽略传输器件（被动部件），这种部件将信号从一个子系统传输到其他子系统。这相当于为连接、管道或命令链接分配零故障概率。

我们接下来按步骤分析该顶层事件。事件“没有信号到E”的直接原因是“D没有输出”。分析人员应坚决抵制将事件“D无输入”列为“没有信号到E”的直接原因的诱惑。在决定直接原因时，应该一步一个脚印。“直接原因”的概念有时被称为“Think Small”规则，因为它是有条理的、一步一步来的方法。

我们现在定义次顶级事件，“D没有输出”，并且必须确定它的直接原因。有两种可能性：

1. D有输入但是没有输出
2. D没有输入

因此，我们的次顶级事件，“D没有输出”，应该是由这两个事件（1和2）引起的。读者应该注意到，如果我们没有按照步骤进行，并(不恰当地)确定了“没有向D输入”的原因，那么上面的事件1就会被遗漏。事实上，考虑直接原因的动机现在已经很清楚了:它保证不会忽略序列中的错误事件。

我们现在准备好找出故障的直接原因了。如果我们的分辨极限时子系统层级，那么事件1（该事件可以换个说法“D因为一些内部原因无法执行正常功能”）将不被深入分析，并作为故障树的一个基础输入。对于事件2，它的直接、必要、充分原因是“B没有输出并且C也没有输出”，这是两个事件的交集。表示为：
$2=3 \ and \ 4$
当

• 3 = “没有B发出的输出”
• 4 = “没有C发出的输出”

就术语而言，如果后续需要对事件进行进一步分析，则可以方便地将其称为“错误”（例如事件2）。但是，像事件1，它表示一个基本的故障树输入，并且后续不会进一步细分，那么就可以成为“故障”。这个术语在“错误”与“故障”的机制定义方面也是一致的。

我们转回头继续分析事件3和4，就3而言，我们有

$3 =5 or 6$

当

• 5=“B有输入但是没有输出”
• 6=“B没有输入”

我们很容易的识别出5是一个故障（基本的故障树输入）。事件6是一个错误，它会在后续进一步分析。我们用类似的办法搞定事件4。

该系统后续的分析读者能很轻易的掌握。当确定了所有相关的基本树输入后，分析将终止。在这种情况下，“A无输入”事件也被认为是基本的树输入。

我们对顶部事件(“E没有输入”)的分析结果产生了由“and”和“or”逻辑连接的故障事件的链接。这些连接产生的模型就是故障树。下一章将给出连接错误事件到框架（故障树）的细节。

此时，读者可能会有兴趣自己进行一个简短的分析，参考之前给出的门铃电路图V-1。最常见的情况是“当手指按下按钮时，门铃不响”。分析将从以下陈述开始:

门铃不响 = 电池没电 OR 螺线管没有激励

其中，“电池没电”事件表示故障或基本树输入。

5.7 故障树构建的基本规则

故障树构建技术从提出之日起，经历了超过15年的不断完善。起初，它被认为是一种艺术，但很快就认识到，成功的树都是根据一套基本规则绘制的。遵循这些规则有助于确保故障树的正确性，于是故障树开始逐渐脱离艺术而变得越来越科学。我们现在来研究故障树分析的基本规则。

如图V-3所示，这是一个简单的故障树，它也可以是一个大型故障树的一部分。注意没有任何一个故障事件被“写入”；它们被表示为Q，A，B，C，D。

当我们面对一个特定的问题时，清晰的描述事件Q，A，B，C，D就变得十分必要。这样的适当程序构成了基本原则一：

将错误以声明的形式写入事件框；描述清楚错误是什么，以及它什么时候发生。（Write the statements that are entered in the event boxes as faults; state precisely what the fault is and when it occurs.）

“what-condition”描述了组件对应的限制（或操作）状态。"when-condition”描述了系统相对于兴趣组件的状态，这使得组件的特定存在状态成为一个错误。

需要注意的是基本原则一可能经常需要很长的声明。那就这样做。分析师被告诫不要害怕冗长的声明。请不要因为你画的事件框不够大而裁剪你的声明。如果有必要，将框画的大一点。使用缩写词是允许的，但是不建议缩略你的陈述。错误声明的一些例子如下所示：

1. 当电动势作用于线圈时，常闭继电器触点不能打开。
2. 加电后马达启动失败。

下一步是检查每个事件框内的声明并问这样的问题：“这个错误能否构成一个部件故障？”这个问题和回答引出了基本原则二：

“这个错误能否构成一个部件故障”，如果回答为“是”，那么这个事件属于“部件状态错误”。如果回答是“否”，那么这个事件属于“系统状态错误”。（If the answer to the question, “Can this fault consist of a component failure?” is “Yes,” classify the event as a “state-of-component fault.” If the answer is “No,” classify the event as a “state-of-system fault.”）

如果错误事件属于“部件状态”，添加一个或门在事件的下方，并查找主要的、次要的和指令模式。如果事件属于“系统状态”，则查找最小必要和充分直接原因。一个“系统状态”错误事件或许需要一个与门、或门、禁止门、或者什么门都不要。一般来说，如果能量来源于部件外的一个点时，这个事件可能属于“系统状态”。

为了阐明基本原则二，考虑图V-4中所示的简单电机开关电池电路。

系统存在两种状态：工作状态和就绪状态。下面的错误可以按照基本规则二进行定义和分类：

工作状态

系统错误	分类
当按下按钮开关闭合失败	部件错误
当按下按钮开关不经意的断开	部件错误
当端子接电马达却没有开启	部件错误
在端子持续供电过程中马达停止运行	部件错误

就绪状态

系统错误	分类
没按按钮，开关却不经意的闭合	部件错误
马达不经意的启动	系统错误

除了上述基本规则外，多年来还制定了若干其他程序性声明。其中第一条就是“没有奇迹规则（No Miracles Rule):

如果组件的正常功能传播一个故障序列，则假定该组件正常工作。(If the normal functioning of a component propagates a fault sequence, then it is assumed that the component functions normally.)

在系统分析的过程中，我们可能会发现，一个特定的故障序列的传播可能会被某些组件不可思议的、完全意想不到的故障所阻止。正确的假设是组件正常工作，从而允许故障序列通过。但是，如果一个部件的正常功能阻止了错误序列的传输，如果错误序列继续向故障树的上方移动，那时错误一定会阻碍正常的功能。另一种说法是，如果一个系统中存在“与”的情况，那么模型必须考虑到它。

另外两个程序性声明解决了缺乏条理和试图简化分析过程的危险。第一个是“完整门规则（Complete-the-Gate Rule）”:

对特定门的所有输入应该全部在其中任何一个被后续的分析前被定义（All inputs to a particular gate should be completely defined before further analysis of any one of them is undertaken.）

第二个是“没有门对门规则（No Gate-to-Gate Rule)：

门的输入应该是正确定义的错误事件，并且门不应该直接与其他门连接。（Gate inputs should be properly defined fault events, and gates should not be directly connected to other gates.）

“完整门规则”指明了故障树应该分层级开发，开发完一层，再去考虑下一层。对于“没有门对门规则”，图V-5展示了一个“快捷”的故障树。

“门到门”的联系意味着草率的分析。如果正在执行定量评估并总结故障树，那么“门到门”的捷径可能是正确的。然而，当实际构建树时，门到门的快捷方式可能会导致混乱，并可能表明分析师对系统的理解不完整。只有当分析人员对要建模的系统有清晰和完整的理解时，故障树才能成功。