fta故障树分析法案例？FTA故障树分析法！

多年来，在全面深入研究ERP/EAM基本原理及功能应用的同时，我对设备故障诊断及排除方法也很感兴趣。当年在平朔安太堡矿与外方人员合作期间，我就心存了一棵日渐生长的“故障树”。说起最初对“故障树”的认知，我还得从安太堡矿计算机主机房的那些英文技术文档资料说起。

（一）

当年安太堡矿IBM SYSTEM/36计算机主机房里的书架上，有很多英文技术文档资料，其中就有几本关于计算机主机及外围设备的《Trouble shotting guide》英文手册。这本图文并茂的手册其实就是这些设备的“故障排除手册”，它们主要是描述IBM System/36主机、磁带机、显示终端、打印机的故障诊断及排除方法步骤，以便用户根据故障症状逐步查找出故障点及其原因，进而按照维修指导建议更换相应的备件，并彻底排除相关的故障。在诊断流程中每做一步，诊断手册都根据出现的症状给出各种可能的故障原因及备件故障的概率（%），如果更换相应备件后故障依然存在则进入下一步骤，直到找到故障原因并彻底排除为止。

其实，这些“故障排除”指导手册中的故障因果关系图，都是基于IBM公司维修工程师长期积累的“知识库”而形成的故障诊断分析方法。当时，外方人员将这些故障诊断排除流程图形象地称之为“Fault Tree”（故障树）。当年外方在引进先进设备的同时，还带来了很多新理念及新方法，我的不少思维方式及工作方法都是那时向老外学习来的，那是一段看见啥都感兴趣、见啥学啥的艰苦岁月。如今，规范设计“故障树”已经是设备故障诊断、状态预知维修、智能维修保养的前提条件及重要依据。

在人们的实际生活中，树几乎是无处不有、无所不在的普遍存在，树既有根，也有枝和叶。我们这里所说的“故障树”，它不是自然界的植物，而是一种人们常用的分析方法（FTA：Fault Tree Analysis）。“故障树”其实是一种特殊的倒立树状逻辑因果关系图，它主要用事件符号、逻辑门符号和转移符号，来表示事故或者故障事件发生的原因及其逻辑关系。逻辑门的输入事件是输出事件的“因”，逻辑门的输出事件是输入事件的“果”。“故障树”的“树根”在上，“树枝”在下。“树根”所在的位置的方框，我们称之为“顶事件”，也就是我们待分析的“故障”。

故障树分析（FTA）是以一个不希望发生的产品故障事件或灾害性危险事件即顶事件作为分析的对象，通过由上向下的严格按层次的故障因果逻辑分析，逐层找出故障事件的必要而充分的直接原因，并画出故障树，最终找出导致顶事件发生的所有可能原因和原因组合，在有基础数据时还可以计算出“顶事件”发生的概率和“顶事件”的重要度。

“故障树”分析方法是根据维修工程师长期积累的“维修技能资料知识库”而归纳总结整理出来的。起初人们用手工来设计构画简单的“故障树”，其画法其实很简单——从一个可能的故障开始，自上而下、一层层的寻找“顶事件”的直接原因和间接原因事件，直到找到各种基本原因事件为止，然后人们再用逻辑图把这些事件之间的逻辑关系准确地表达出来。当然，如今设计构画“故障树”的软件很多，例如：笔者就曾应用VISIO软件构画过一些简单的“故障树”。

不少现场维修人员可能并不一定知道“故障树”这个字眼，但他们在具体的维修活动中，总是根据丰富的维修经验，则不经意地应用了“故障树”的原理及方法。由此看来，我们不仅要应用好OEM设备制造商提供的“故障排除手册”及“故障树”方法，更应该组织相关技术人员研究编撰总结相应的设备维修手册，并尽量构画并持续完善相应的“故障树”，从而充分发挥设备维修人员的聪明才智，搞好精益维修，杜绝一切故障，全面提高设备的维修管理及技术水平。

（故障树的简要图示）

（二）

1988年2月，安太堡矿数据处理部外方经理哈维尔，安排我编撰一本《计算机主机房标准管理规程及操作》英文手册。在该文档编写过程中，哈维尔对编撰工作进行了全面指导、认真审阅及修改。在最初讨论文档总目录时，他还建议我好好学习IBM System/36小型机运维技术资料，给我介绍了“鱼骨图（相当于现今的思维导图）”系统化思维方式、以及“故障树”分析及排除方法。

在中美合作期间，安太堡矿引进了两套配置完全相同的IBM System/36小型机。在改革开放初期，当时国内几乎没有计算机原始制造商，社会化服务水平也很低，计算机及其重要配件需要从国外进口，很多计算机维修保养工作都无法实施外委。因此，外方人员就很重视计算机系统及设备的日常维护及计划保养工作，当时我们连计算机终端键盘上的按键都需要自行维修。

为了强化计算机维护保养工作，我们在外方的要求下，全面认真学习IBM公司提供的“故障树”理念及方法。在计算机及其外设维修保养时，我们按照《Trouble shotting guide》手册上的说明， 一步一步地诊断故障及其原因。我们每排查一步，“故障树”分析手册都根据设备系统出现的症状，给出各种可能的原因或备件故障发生的百分率。

在找到疑似问题以后，我们就进一步采用“备件互换诊断法”，一般是将同型号设备上的集成电路板卡或备件，更换到故障设备上。如果更换备件后故障依然存在，我们则按照手册提示进入下一步骤，直到故障原因找到并排除为止。如果设备的故障消失，则说明被更换的集成电路板卡或备件损坏了，因而立即更换新板卡或备件；如果手头没有此类板卡或备件存货则立即汇报给外方经理，以便让北京IBM公司或代理服务商尽快发来新备件。

当我们全面熟悉了计算机性能及维修方法以后，我们就可以根据经验，逐步脱离“故障树”来进行故障诊断及维修工作了。在维修过程中，我们在脑海中已经构画有“故障树”，然后从“树根”到“树梢”逐步判断，甄别一个就可以排除一片……此诊断方法屡试屡爽，真可谓“故障分析一个准”。当年我在编写计算机主机房英文手册的同时，还曾幻想模仿IBM故障排除手册中的“故障树”，根据自己的维修经验，用图文来归纳整理一些计算机及外围设备诊断维修方法及技巧。

当年，我虽然圆满完成了哈维尔交给的计算机主机房英文文档编撰整理工作，但我仿照《Trouble shotting guide》来构画自己的维修“故障树”，最终却一直无法做出成型的东西。因此，我就对“故障树”一直耿耿于怀。后来，我还把“故障树分析法”应用在了软件编译错误的诊断方面，其效果还不错。尽管对“故障树”的研究已经超出了我的研究范畴，但针对“FTA分析法”的研究应用却一直伴随着我的企业信息化整个研发历程。

近年来，随着移动互联网及大数据理念、设备智能诊断维修技术的发展，我针对“故障树分析法”的跟踪研究情结也越来越浓烈了。目前，在企业离岗的我，只是抱着“玩”的心态，对“故障树”理念及实施重新进行了一些细化研究，并在“如何利用IT技术为实施‘故障树’提供大数据依据”方面做了一些探索。当然，在研究过程中，我也见识了有些企业维修人员所总结绘制的“故障树”。

（三）

“故障树分析法”（FTA）采用逻辑的方法，形象地进行故障或事故的分析工作，其特点是直观、明了，思路清晰，逻辑性强，既可以做定性分析，也可以做定量分析。FTA体现了以系统工程方法研究安全问题的系统性、准确性和预测性，它也是安全系统工程的主要分析方法之一。而我们规划设计“故障树”的终极目标就是全面实现“零故障”。?

当年，在设备全生命周期管理研究过程中，为了研究“故障树”我曾经深入到安太堡矿设备维修车间，实地了解设备维修工单应用、故障诊断排除方法。在查阅相关设备设备故障诊断文档资料时，我发现这些技术资料中虽然有故障诊断步骤的文字描述，但却基本上没有规范的“故障树”图示。其实，我们很多设备维修技术人员都知道“故障树”概念及作用，他们的故障诊断及维修技术也很精湛，但他们却几乎没有规范地整理构画过“故障树”。由此看来，对于有些设备来说，规划设计“故障树”领域还是一块尚未开垦的“处女地”。

2002年3月，我深入到安太堡矿国外设备厂商驻安太堡矿服务点，针对设备故障排除及“故障树分析法”（FTA：Fault Tree Analysis）、设备状态预知维修方法、车载诊断系统（OBD：On-Board Diagnostic）进行现场调研。在调研中，我还就各设备厂家与ERP、EAM、GPS调度软件商的合作情况、备品备件采购及物流状况、设备远程监测及故障诊断技术（如：685E卡车上的STATEX-III、789B卡车上的ARC、ECAP、VIMS、康明斯发动机上的ECM等）、设备图文档系统管理软件应用、集成信息技术及其发展趋势（无人驾驶技术）等，与各厂商相关现场服务技术人员进行了广泛的交流。我还翻译整理了相关设备的OBD英文资料，并在EAM论坛上发表了《设备状态预知维修管理》等文章。

由于当年设备厂家的设备OBD功能有限、以及无线移动网络技术的限制，安太堡矿矿坑移动设备状态的无线实时监测技术还不大现实，但我们已经将移动设备的状态监测纳入了“采矿设备基于EAM的GPS调度系统项目”的拓展内容。设备状态预知维修就是对设备进行实时状态监测，并根据监测信息而进行维修决策的管理模式。状态维修适用于可实施监测设备，监测信息可以准确定位故障设备的故障所在。其实，设备厂家将“故障树”的诊断过程可以“软化”或“固化”在设备OBD诊断分析系统中，然后让系统直接给出智能诊断结果，而这实际上就是智能诊断维修的重要内容。

成熟的“故障树分析法”应用起来很方便，但“故障树”设计制作起来却很不容易，这需要广大维修人员针对特定设备根据维修历史经验而逐步总结并日益完善。当年，我曾经试图通过维修保养经验逐步形成或完善相应的“故障树”，然而由于有些设备故障极少，且一个人收集故障记录，则很难形成规律性的故障排除指导方法。由此看来，系统故障诊断的大数据积累及其算法很重要，而国际上知名大公司都是通过很多技术人员的运维经验，来共同构建共享“知识库”并形成“故障树”的。

多年来，我特别擅长归纳总结及其文档的编撰工作，但当年“异想天开、脚踏实地”研究“故障树”的行为却纯属越俎代庖。我曾经一度研究“故障树”的设计绘图方法，并试图根据我在计算机维修“故障树”方面的经验，应用VISIO等软件来摸索针对矿用设备构画“故障树”的一些方法。然而，用计算机软件画“故障树”容易，但设计“故障树”所需要的故障诊断经验及依据，却很难在短期内全面规范地整理出来。经过几番折腾以后，我最终知难而退、望而却步了，而现在针对“故障树”也仅仅按照兴趣跟踪研究而已。

（四）

“故障树”看似很容易，但实际设计构画起来却很难。当年我虽然没有取得多大的研究成效，但是我毕竟尝试过了。在学习“故障树分析法”原理的同时，我至少知道哪些能做成？哪些做不成？为什么做不成？其实，规划设计“故障树”工作的难度在于——我们不可能由个别人在短时间内一蹴而就，而需要很多人在长期的维修实践中逐步积累经验资料，并持续改进完善成规范的“故障树”。

我曾经考虑过这样的问题——我们能不能让现场维修技术工人及工程师，将一些维修技巧及心得体会整理出来，并随时随地上传到放在一个“设备运维知识技能”云平台上，就像国外设备制造厂家那样逐步形成“故障树”及“维修知识库”，然后供大家查询共享，甚至将维修工作规程及作业指导书直接推送到维修人员手机端，以方便制定设备维修策略、维修计划，并做好设备维修及成本控制等工作。

按照设备维修“知识库”设计构画“故障树”的方法，我们设备维修管理技术研究人员，应该逐步积累汇集并完善设备故障诊断方法、故障排除流程步骤、维修知识库及维修指导书，并探索研究归纳整理并完善相应的设备“故障树”，同时在“故障树”中明确注明每个症状故障的各类原因及其相应的概率（%）、以及针对每一种故障排除的操作方法。

其实，设备知识库是各类设备静态技术文档、动态运维数据、以及维修管理技术经验及技巧的“集结地”，而ERP/EAM系统中的维修工单则应该是设备运维信息的“归集器”。但可惜的是：即使再先进精益的维修工单跟踪管理系统，在实际应用中都很难完全应用到位，很多时候维修工单只是维修工领用备品备件的依据，而设备故障及处置内容等信息基本上都不输入到维修工单系统中。

例如，维修工单应用不到位的现象有：在维修保养工单中，很多时候并不能确保及时、准确、完整地输入设备所报故障代码、设备维修诊断故障代码、维修工作内容（维修任务代码）、维修所用人工工时、维修所用备品备件、以及设备动力能源消耗等基础信息。由于设备维修不少基础信息没有全面准确地体现在ERP/EAM系统中，当然也就形成不了规范的“基于大数据的维修知识库”及相应的“故障诊断树”，因而也就无法利用“大数据”归纳总结并构画出设备的“故障树”并指导未来的维修工作。

当然，除了应用好ERP/EAM系统的维修工单管理功能以外，我们更应该充分发挥维修车间专业工程师的作用。我们应该采用综合手段，在全面应用好OEM制造厂家整理的“故障排除手册”的基础上，并根据积累总结的维修经验及技巧整理成具有简要文字及图示的《故障排除手册》，然后再按照“故障树”标准转化并构画成规范的“故障树”。规划设计“故障树”的关键是——如何收集整理故障诊断经验及技巧，并按照“故障树”的标准将“故障树”完美地构画出来。由此看来，维修专业人员的维修方法及经验收集整理、归纳总结工作非常重要。

事实上，在设备运维过程中，我们要想做出规范实用的“故障树”是很难的，这比起编撰煤矿三大规程、实施《标准作业程序》（SOP）、质量标准化工作要困难得多。因此，规划设计“故障树”是一项循序渐进、细水长流的管理技术基础工作，并不适合搞轰轰烈烈、疾风暴雨式的突击运动。我们应该根据企业设备状况、维修管理及其人员情况，因势利导、因地适宜、由浅及深、由局部到全部地开展好“故障树”的规划设计及深化应用工作。

尽管如今很多人都不曾经常接触规范的“故障树”，但是我坚信——在每一个维修员工内心深处都珍藏着一棵“故障树”。最后，我但愿每个企业针对设备资产都能绘制出规范的“故障树”，祝愿每个企业的“故障树”森林都枝繁叶茂，并全面实现“零故障”的终极目标。

（吕延斌 2022年8月17日）