The FRACAS method also promotes improved reliability throughout the life cycle of a product. It can be used and applied during: FRACAS stands for Failure Reporting, Analysis and Corrective Action System. The FRACAS process originated in the 1970s from the defence and aerospace industry. This was critical to rapidly and sustainably realizing the inherent reliability and maintainability potential of military-related systems, equipment and software. From the late 1970s into the 1980s, major defense, aerospace, automotive and telecommunications players around the world have invested millions of dollars in the development and support of internal software related to FRACAS. In 1985, MIL-STD-2155 was created to standardize the scope, definition and implementation of the FRACAS process. FRACAS is a three-step process originally used to achieve the reliability and maintenance potential of military equipment systems. Its initial scope was focused on defence, aerospace, automotive, telecommunications, etc. Today, FRACAS has become a tool from which all industries can benefit. Since modern manufacturing companies collect a large amount of data and reliability information, FRACAS data is usually kept in a structured database to make the data more convenient to use. This is called a data-centric approach.
This process-oriented method solves two problems: the clear definition of complicated tasks with many people and organizations involved in order to avoid confusion of relationships and responsibilities, and secondly, the definition and regulation of binding tasks within the management system so that employees can be reminded of their commitment. According to a study published in the Journal of Quality and Reliability Engineering, the implementation of FRACAS in this way takes place in three phases: discovery, design and implementation. Let`s back up a bit. The basic elements of effective FRACAS are an efficiently validated device hierarchy, criticality analysis, failure mode analysis, and device maintenance plans. FRACAS checklist: The device hierarchy must be created and validated so that similar errors can be identified on similar devices in an organization. Criticality analysis is developed and validated to classify equipment criticality based on production throughput, plant utilization, cost, environment and safety. Failure mode analysis is performed for all critical devices with FMA, FMEA or RCM. Equipment maintenance plans are designed for all critical equipment to prevent or predict failures. Effective device hierarchy – An asset catalog or device hierarchy must be developed to provide the data needed to manage a proactive maintenance program that includes fault reports, analytics, and a corrective action system (FRACAS).
To eliminate errors, it is necessary to ensure that this is a successful first step. Figure 6 (on the next page) shows the results of an installation with a total of 32 « workpiece bearing » failures of electric motors of different sizes (« part » is identified from a drop-down screen for CMMS/EAM codes). A « Defect – Wear » type occurred in 85% of the errors (« Defect » is identified in a drop-down screen for CMMS/EAM codes). In 98% of cases, the « cause » was found to be « insufficient lubrication ». It is now time to carry out an analysis of the root causes of this common thread. (« Cause » as specified in the CMMS/EAM codes drop-down screen). After the hierarchy is configured, you can find similar errors in an area of a task or in the entire operation. Device hierarchy validation is required against the device hierarchy standard established by the organization.
We are looking for « party » – « defect » – « cause ». Maintenance personnel may not have the training or ability to determine the « defect » (a predictive maintenance technician could identify a failure), and the « cause » can usually be identified by a service technician, maintenance technician, reliability engineer, or predictive maintenance technician. After a thorough analysis, you will find that most failures come from a small amount of equipment. The question is: « What equipment? » Asset criticality analysis – Everyone says they have identified their critical equipment. However, in many cases, the criticality of equipment can change depending on how upset people are with a device problem or because people are confused about the consequences associated with a failure and the likelihood that it will be if we effectively manage the reliability of the equipment. The goal of asset criticality analysis is to determine which devices have the most severe potential impact on business performance in the event of a failure. The consequences for the company can be:• Production throughput or use of equipment/plant• Costs due to loss or reduction of production• Environmental issues• Safety issues• MiscellaneousThe resulting device criticality number is used to prioritize the resources that perform maintenance. The intercept ranking model illustrates this process (Figure 7). On the « Y » axis, you can see that the criticality of the asset is displayed from « Zero » to « High ».
I like to use a scale from 0 to 1000 because not all assets are created equal. With the intercept line, which is removed in the middle, a planner or dispatcher can define which job to schedule or schedule first, or at least get closer to the best response, since management has already been involved in determining the most critical asset and the equipment has told you (on the « X » axis) which has the highest level of error severity (in the worst state). The defence sector is the origin of the term FRACAS. Today, companies that manufacture equipment and systems used by the military use FRACAS to ensure the reliability of the weapons, vehicles, software, and other equipment they manufacture, such as: The main reason for implementing a FRACAS is to use its main purpose: to provide a closed process to effectively track and manage problems that arise and prevent their recurrence. The results of FRACAS` success offer many benefits to companies and all stakeholders who gain a better reputation among industry insiders and the general public through the use of these proven techniques to improve reliability. Common FRACAS outputs may include: part number, part name, OEM, MTBF field, MTBR, MTTR, spare parts consumption, reliability growth, distribution of errors/incidents by type, location, part number, serial number, symptom, etc. Some steps need to be determined at this stage. To name a few, you need to identify error definitions, error descriptions, verification procedures, error modes, and RCA procedures. At the end of this phase, make sure all processes are well documented. Error reporting can take many forms.
The key is to have a disciplined plan to review bug reports over a period of time and then develop measures to eliminate bugs. Below are some examples of bug reports that should be part of your process of continuous improvement and elimination of FRACAS defects.1. Plant condition or percentage of assets with no discernible defects – reported by maintenance management to plant and production management at least monthly (see Figure 9). An asset that has an identifiable defect is in a RED state. An asset that has no discernible impairment is called in the GREEN state.