FRACAS

FRACAS（Failure Report Analysis and Corrective Action System，故障报告、分析和纠正措施系统）—— FRACAS通常也称为“故障信息闭环管理系统”，FRACAS还有称为，如“归零管理”、“PRACAS”、“DRACAS”等。

　　由世界著名的可靠性公司一一美国RELEX公司推出的FRACAS(故障报告、分析和纠正措施，Failure Report Analysis and Corrective Action System，缩写为FRACAS)专业系统软件，通过报告产品的故障，分析故障原因，制定和实施有效的纠正措施，以防止故障的再现，同时把故障根本原因和纠正措施信息反馈到设计过程中，改善和促进产品的可靠性增长。

　　1980年颁布的美军标MIL-STD-785B (《系统和设备研制生产的可靠性大纲 要求军用系统承包商建立FRACAS，以有效地开展、监督和控制研制过程中的故障报告、分析和纠正活动。为使这一工作更加规范化，1985年美国国防部又颁发了军用标准MIL—STD．2155(AS)《失效报告、分析和纠正措施系统》，对故障报告、分析和纠正活动规定了统一的要求和准则。我国早在1986年由原国防科工委颁布的《军工产品质量管理条例》中，就提出了承制单位应当制定质量、可靠性信息的收集、传递、处理、贮存和使用的管理办法，并同使用单位建立质量信息反馈网络、故障报告制度和采取纠正措施制度。之后，为满足在我国军工领域推行可靠性工程的需要，参照美军标先后于1988年颁布了国军标GJB450．88《装备研制和生产的可靠性通用大纲 ，1990年颁布了GJB841-90《故障报告、分析和纠正措施系统》，明确要求承制单位在军工产品的研制和生产阶段建立FRACAS，并规定了该系统建立及运行的程序、方法和要求。

　　按GJB450要求,研制、生产单位要建立一个闭环故障报告系统。该系统包括:

　　(1)对故障进行报告和分析的程序;

　　(2)将纠正措施反馈到设计、生产、试验过程中去的程序;

　　(3)跟踪、评审故障分析及纠正措施状况的制度;

　　(4)有关故障的文件记录的规定。

　　GJB841为如何实现GJB450上述要求提供了指导。

　　由于产品研制涉及许多外购、外协产品,因此,对于协作配套产品的故障信息应纳入主承制单位的信息收集系统,以利于跟踪故障。同时要把有关故障信息纳入相应的故障文件内。对于产品使用过程中的故障信息,也应疏通渠道,及时加以收集,以利于改进产品。

　　对于像航天系统这样复杂、昂贵、重要的产品,为使故障报告、分析和纠正措施的各项活动得到控制,设立一个故障审查组织是非常必要的。其目的在于控制FRACAS的运行并增加管理的透明度。图1表示了故障报告闭环系统工作流程及其与故障审查组织的关系。

　　目前一些单位建立了信息系统,应当把FRACAS作为本单位信息系统的组成部分,并根据FRACAS要求来完善现有的信息系统。

　　对所有故障、故障原因的调查和分析、采取的纠正措施及效果以及故障评审活动等均应记录并保存,将这些记录编制成为有统一编号的故障文件,以便于检索、查阅。它也为信息交换提供了基础。

　　FRACAS应在研制阶段的早期就建立并运行。这是由于在研制的初期,允许设计作较大的更改来解决故障问题。而等到研制后期,虽然仍可提出纠正措施,但受到很大的约束,付诸实现就很困难。

　　GJB450-88和GJB841—90中规定，“建立FRACAS的目的是要及时报告产品的故障，分析故障原因，制定和实施有效的纠正措施，以防止故障再现，改善其可靠性和维修性”。

　　“FRACAS应由承制方(包括转承制方)尽早建立，并在订购(使用)方的协同下加以实现。该系统应保证对合同规定层次的产品在研制阶段和生产阶段所发生的故障及时报告、分析和纠正”。从上述要求可以看出建立FRACAS的目的，是为了对产品在研制和生产阶段所发生的故障进行严格的“归零”管理，做到及时报告、查清原因、正确纠正，防止再现，从而实现产品可靠性增长，以保证达到对产品可靠性和维修性的要求。可见，FRACAS的建立与运行是开展可靠性工程活动的重要组成部分。可靠性工程的主要任务就在于纠正己发生的故障，防止故障的发生，控制和减少故障发生的概率。而FRACAS正是利用“信息反馈、闭环控制”的原理，并通过一套规范化的管理程序，使分散发生的产品故障，得到及时的解决，并防止故障的重复发生。建立FRACAS是实现产品可靠性增长、提高产品质量的重要手段。它既有纠正己有故障的现实意义，又能对未来新品发生类似的故障起到积极预防的作用。通过FRACAS的运行， 可以积累大量处理故障的实践经验，对类似产品的改进与设计提供可供参考的信息，起到举一反三，防止其他产品出现类似问题的作用。FRACAS的建立与运行主要适用于产品的研制阶段和产品的早期使用阶段，因为在研制阶段采取纠正措施方案的选择灵活性最大，最易于实施，效果也最为明显。

　　Relex FRACAS系统不仅是一个强大的可靠性软件，还是一个质量追踪和管理系统，实施和应用FRACAS技术将能为企业成功实现6σ、ISO9000、AS9000、QS9000和TL9000等质量目标提供保障。同时，FRACAS系统也能帮助企业提升ERP、PDM、SCM和CRM 的投资价值。

　　FRACAS与流行的8D管理思想相同， 主要针对实际发生的故障信息进行闭环管理，FRACAS是构建可靠性工程平台的基础。Relex FRACAS系统基于局域网和Web技术，将产品的可靠性数据积存到数据库中，通过完整的闭环管理流程对各种信息进行过滤、统计、分析和计算，同时对可靠度、可用度、失效率、MTBF等进行计算，进行可靠性增长和费用的分析。系统可为不同规模的企业进行定制，为每一位使用者量身定做各种界面、流程、计算、图形、报表、报警等内容。

　　故障信息传递和故障件处理的流程图见图：

　　图：故障信息传递和故障件处理流程

　　一、故障报告

　　(1)故障报告的范围

　　军工产品在研制过程中发生的所有故障和重大质量问题等(以下简称为故障)都应及时记录，并填写故障报告表。

　　(2)故障报告的内容

　　故障报告的内容应能完整、真实地反映故障发生时的一切情况，一般包括：

　　a．产品发生故障的时间、地点及何种试验；

　　b．发生故障时产品所处的工作状态及环境条件等；

　　c．故障产品的详细描述；

　　d．故障现象和特征的详细描述；

　　e．故障的观测者及观测故障时的环境条件

　　(3)故障报告的要求

　　故障报告一般应满足如下要求：

　　a．各产品研制单位应根据实际情况，制定统一的故障报告的表格，以便对故障报告进行传递、统计处理和储存(推荐使用G．IB841—90所列各表)；

　　b．产品的故障报告应按不同的层次(如总体、系统、设备、部组件等)和故障的严重等级规定故障报告应报告到哪一级；

　　c．故障报告应规定报告的时限，如重大故障应在多少小时内报到最高管理级，一般故障应在多少小时内报告到规定的管理级等；

　　d．供方在产品研制过程中出现的一般故障由各单位自行处理，但应经常与总体单位保持联系，通报故障的处理情况。

　　(4)故障的核实

　　有关职能部门接到故障报告后，应根据故障等级和故障报告的详细程度，对故障情况进行调查，对故障报告的准确性进行核实。一般应做以下工作：

　　a．重新证实初次观测故障的真实性，进一步录取故障信息；

　　b．查找故障的部位，一直到最低一级可更换的故障件；

　　c．用相同合格件更换、代替故障件后，重新进行测试和试验，以确定故障是否被纠正；

　　d．对更换下来的故障件进行测试，以核实该可疑故障件是否确有故障，初步确定故障的范围；

　　e．对于不可重复试验的故障件，可以通过对故障影响和后果(如泄露、断裂、损坏等)的详细观察来证实。

　　二、故障分析

　　故障分析是由故障现象、后果去查明故障的原因和故障机理的过程，追查故障原因，应一直查出根本原因，并能构造出反映故障因果逻辑关系的故障链，确定造成故障的责任方。对于特别重大故障应成立故障分析工作组，负责故障的调查、分析工作，给出分析结论，完成故障分析报告，提出改进措施的建议。故障分析工作组组长一般由与该故障无直接责任关系的专家担任；故障分析工作组成员应由各方面、各专业的代表组成。

　　(1)故障分析的步骤

　　对故障进行分析的一般步骤为：

　　a．分析有关产品及其故障的资料(如产品的设计资料、试验程序、FMEA报告、故障报告等)；

　　b．分析故障产品的全部工作历史和故障历史；

　　c．分析可能导致产品发生故障的外部因素(如试验测试设备、测试方法、操作环境及人为因素等)；

　　d．对故障件进行检查或测试；

　　e．提出故障原因和故障机理的假设，并用试验或理论分析的方法进行验证；

　　f.根据试验或理论分析的结果，给出故障分析结论，完成故障分析报告；

　　g．提出纠正措施建议；

　　h．整理各种资料、工作记录、试验数据，编成档案及时归档。

　　(2)故障分析的方法

　　对报告的故障进行彻底的分析，以确定故障的根本原因。故障分析的方法一般分为以下3种：

　　a．工程分析

　　根据工程原理和工程经验，对故障产生的原因和机理进行分析，可以通过理论分析计算、故障模拟试验或对故障件进行分解等方法。应充分利用FMECA分析结果提供的信息，运用故障树分析方法来帮助查明故障模式和原因之间的逻辑关系。

　　b．失效机理分析

　　利用观察、测试、理化分析、解剖、X光检查、电子扫描显微镜观测等方法，去研究物质结构、工艺过程可能产生的缺陷，分析导致这种缺陷的机理和过程。该方法主要适用于元器件、零部件和材料等硬件。

　　c．统计分析

　　通过对故障产品累计工作时间、次数和出故障次数，对该故障模式在类似产品出现的次数加以系统的整理，以估计该故障模式的性质和出现的概率。

　　(3)对故障分析的要求

　　无论采用上述哪一种故障分析方法，其分析的结果都应能判明以下问题：

　　a．该故障是相关故障，还是非相关故障?以便估计产品在未来使用环境中是否会发生类似的故障；

　　b．该故障是责任故障还是非责任故障?以便在估计产品可靠性时考虑是否记入该故障，同时也利于分清故障产品是故障源还是受害者；

　　c．确定引起故障的责任方面，如是设计、制造的原因，还是元器件、原材料、外购件的缺陷；是设备的问题还是人为操作的错误，或是其他未查明的原因等；

　　d．该故障是初次发现，还是类似产品中早已出现过的故障；

　　e．该故障是需要纠正的系统性问题引起的，还是偶然性问题引起的，如果是偶然性故障，它出现的概率是多少?是否需要纠正。

　　(4)故障分析报告

　　一般故障的分析报告可参照故障分析报告表，完成对故障的分析和拟采取纠正措施的建议。

　　重大故障应由相关职能部门或故障分析工作组完成故障分析报告。

　　故障分析报告是对整个故障分析处理过程的总结，是确定和实施纠正措施的依据。重大故障的分析结论应由有关方面组织评审，确认后方可提出纠正措施的建议。

　　故障分析报告一般包括以下内容：

　　a、对产品工作的历史和对故障件的故障现象、特征的描述；

　　b．故障调查和分析过程；

　　C．故障原因和机理的分析、论证；

　　d．建议的纠正措施和需说明的问题建议等。

　　如故障原因一时难以查清，应在故障分析报告中，说明理由，经故障审查委员会主任或主管技术的领导批准后，可暂时结束故障分析工作；如已查明故障原因，但未采取纠正措施的故障，也应编写故障分析总结报告。报告中应申述不采取或无法采取纠正措施的理由，经审批后可暂时结束故障分析工作。

　　在产品定型前，对上述暂时结束的故障分析报告工作应重新组织审查，才能最后结案。故障分析报告必须按规定的程序进行会签和审批。

　　(5)故障件的管理

　　对所有的故障件应做明显的标识，以便于识别和控制，确保按要求进行处置。为了便于对故障的调查和分析，在完成故障分析之后到纠正措施实施之前，应对现场加以保护，对故障件要妥善保管，不应随意处理。故障调查和分析完成后，对于典型的、重要的故障产品也应妥善管理。

　　三、故障纠正

　　对于已查明原因的故障，责任单位的有关部门应依据对故障分析的结论制定纠正措施，防止故障的再发生。故障的纠正按以下程序进行：

　　(1)纠正措施的确认

　　纠正措施必须通过试验来验证其有效性。同时应分析纠正措施实施的可行性，是否会带来新的故障模式或附加的不可靠性。所以在对提出的重大故障或质量问题纠正措施正式批准前，应组织有关专家和部门的代表对纠正措施进行评审，经故障审查委员会批准后实施，以确保纠正措施的有效性、可行性，并与其它相关部分接口相协调。

　　(2)故障纠正措施的报告

　　故障单位的有关部门在进行故障分析和制定纠正措施后，应及时按规定的要求准确、规范的填写纠正措施实施报告表；在特殊情况下，如查不出故障原因或不能采取纠正措施，应在表中说明原因，做为遗留问题备查；对于早期使用中发生的偶然性非重大故障或质量问题可暂不填写此表。

　　表中故障审查组织意见栏，对于重大故障或质量问题，由该组织的故障审查委员会填写；一般故障由该故障单位的质量管理部门负责人填写，做为对故障及其纠正措施的确认，并发给有关部门贯彻实施。

　　(3)纠正措施的实施

　　批准的纠正措施反馈到设计、生产、试验过程中，要通过技术状态管理系统完成相应的文件和产品的更改。

　　对于可能出现相同的故障模式的类似产品，应本着“举一反三” 的原则，研究是否需要采取措施；

　　对于与故障有关联的其它可疑产品，应进行必要的分析或试验，证明其可靠性并未降低，寿命未受损。

　　故障审查委员会办公室负责跟踪检查纠正措施的落实情况。

　　(4)纠正措施效果的验证

　　对于已采取纠正措施的故障产品，有关部门应通过试验、试用等方法，验证纠正措施的有效性，如达不到预期的效果，则需进一步分析故障的原因或采取其它的纠正措施，直到故障得到彻底解决。最后将纠正措施纳入有关技术文件，并落实到所有产品上。

　　(5)管理改进

　　通过分析产品的故障原因，还应进一步从管理上、质量管理体系上等多方面人手查找需要解决的问题，以进一步完善制度，改善体系，促进产品质量和可靠性的不断提高。

　　步骤一：制定目标和成功要素

　　制定适当初级目标是成功实施FRACAS的基础。项目组中的负责不同工作的成员都必须明确自己在FRACAS实施过程中的具体目标。具体目标包括降低维修成本、提高整体可靠性，改进下一代产品设计。目标一旦制定，各小组的代表和执行人应召开专门的会议针对这些目标进行评价、调整，并赋予这些目标一定的优先权。

　　同时在会议期间，应针对上述已经制定的各个目标确定出实际、可量化的成功要素。例如：如果目标是降低维修成本，那么量化的成功要素就是将随后12个月的维修成本降低10%。目标和成功要素确认后，必须将具体内容和细则下发到FRACAS小组的所有成员。

　　步骤二：定义输出

　　依照目标，各小组必须确定FRACAS所需要的输出，从而评估是否能实现分配给他们的成功要素。通常情况下，输出可以是计算结果、图、表，或报告等。为了方便对输出的管理，每个输出都应该和目标和成功要素相对应。

　　步骤三：绘制过程/工作流程

　　通过与使用者的一系列走访和会谈，确定各小组的工作流程，绘制统一的流程图，这个流程图最好能简化整个FRACAS过程，以便及时生成所需的输出。过多的步骤会给实施过程带来消极影响，因此必须将工作流程减到最简，从而降低实施过程的复杂度。

　　步骤四：设置数据限制和输入方法

　　利用输出要求和统一的流程图，确定设置数据限制。目的是过滤那些重要数据，减少对无用数据的收集。数据限制确定后，接下来是如何收集这些数据，故障报告人员通过什么形式来报告。收集方法包括早期的手工填写、从选择表中挑选、直接数据输入或是计算机条码的录入。同时必须制定数据输入规则（例如：故障信息的那些数据必须要求输入）以及如何保证数据的准确性和一致性。

　　步骤五：实施FRACAS基本原型

　　上述四个步骤即实施FRACAS的前期准备工作，完成之后可以开始实施基本原型。目前实施FRACAS的工具有三个层次：Excel或者Access等通用工具或者自开发的实施工具满足基本需要，缺点是无法满足多用户共同使用，数据处理能力有限，数据安全性差。

　　部门级的应用工具，能包括基本的FRACAS功能，适合用户较少的部门应用。

　　企业级应用工具（例如后面介绍的RelexFRACAS等专业软件工具），提供全部FRACAS功能，支持大规模数据和多用户，采用WEB技术，与企业信息化管理软件（ERP、PDM等）有接口，便于实现数据的共享与传递。

　　项目组根据当前的实际情况采用不同的应用工具来实施FRACAS。

　　步骤六：接受反馈和修改FRACAS

　　FRACAS基本原型建立好之后，让使用者参与进来，确定其输出是否能够达到预定的目标要求，是否满足成功要素。同时寻找需要改进的工作区域，通过收集建设性的反馈意见，来进行适当的修改。在进行系统演示前,要得到小组代表和执行人或负责人的认同和支持。

　　步骤七：演示和培训

　　确定是将系统立即展示给所有使用者，还是采用逐步推开的方式。如果时间充裕，那么逐步推进的方式会更好一些。

　　在培训过程中，担当不同角色的使用者可能出现不同的问题，我们可以对这些暴露出来的问题进行有针对性的解决，从中总结经验。

　　步骤八：持续改进

　　根据使用者的反馈，对FRACAS进行持续的改进。如果商业目标和流程发生了变化，那么也需要对FRACAS做适当的修改。在这个过程中有一点需要注意，即要保证所有改动并不违背最初制定的整体目标。

　　采用专业的应用工具可帮助实施者建立科学严谨的闭环流程，下面介绍美国RELEX公司推出的Relex FRACAS系统。

• 通过FRACAS的成功运行，能够建立比较完善的产品零部件的故障信息和可靠性信息数据库，利用该数据库，可以为本型产品的可靠性改进和后续产品的可靠性设计提供数据基础；

• 通过FRACAS的成功运行，能够得到产品整机及其组成成件的可靠性评价参数值，以此作为制定备件支持和维修保障策略的重要参考；

• 通过FRACAS可以建立以可靠性为中心的故障信息管理和控制系统。