Failure Reporting, Analysis, and Corrective Action System (FRACAS)

Purpose

The primary reason to use FRACAS methodologies is to promote/improve the reliability and maintainability of a system. FRACAS provides a disciplined closed-loop process for solving reliability and maintainability issues at the design, development, production and fielding phases of the life cycle of a system. It is an essential element of every reliability program.

FRACAS provides a disciplined closed-loop process for solving reliability and maintainability issues at all stages of a systems life cycle. It originated in the 1970’s and was formalized in 1985 via MIL-STD-2155 when the DoD chose to standardize the FRACAS process. This standard was converted to MIL-HDBK-2155, Failure Reporting and Corrective Action Taken in 1995.

Essential FRACAS activities include:

• Capturing and recording information about failures and other reliability issues
• Selecting, analyzing and prioritizing those failures and issues
• Identifying corrective actions and implementing them to prevent future occurrences of those failures
• Track over time reliability and maintainability information to be further analyzed
• Utilizing failure analysis results and corrective actions to support additional reliability analysis

When should I do FRACAS?

FRACAS is done typically after a system is fielded. Meaning, once failures start to occur, and you are able to obtain failure data, you can then perform meaningful FRACAS analyses. Conducting FRACAS activities, provide several benefits to systems:

• Promoting reliability growth in systems
• Facilitates understanding of failures on system of systems impacts
• Analysis could reveal inherent or underlying reliability issues.
• Validation or disproval of the original engineering baselines established by a Failure Modes, Effects and Criticality Analysis (FMECA)

What is a FMECA and how is it related to FRACAS?
FMECA methodologies are designed to identify likely and potential failure modes for a system, to determine the effects and risks associated with the identified failure modes, to effectively rank the failures by importance and seriousness to the survivability of the system, and to identify corrective actions required. While this definition sounds familiar to a FRACAS, what we find is that a major difference between a FMECA and FRACAS is when they are performed.
 
Typically, a FMECA is performed during the development of a system, even before parts or systems physically exist, they may only exist as a design in an engineering system. A FMECA is done initially in support of the development of a supportability plan and strategy. Who, what, when, where, how am I going to repair this system when a failure occurs? How often will a failure occur? Will the failure impact other systems? Will the failure impact the performance of the mission? How critical are the impacts of the failure?  These are all questions that can be answered with the assistance of a properly performed FMECA.
 
The eight standard steps conducted during a FMECA are:

1. Define the System — the system definition should include the identification of all internal and interface functions, the performance of the system at each indenture level, any system restraints, and any failure definitions.
2. Define the Ground Rules and Assumptions — these aid in better understanding the results of the analysis. Some examples include: mission of the item, operating time, source of source of failure rate data.
3. Build System Block Diagrams — Functional Diagrams and Reliability Block Diagrams should represent operations, interrelationships, and interdependencies. They allow traceability through each level of indenture.
4. Identify Failure Modes — all item and interface failure modes must be identified, understanding that any effects upon function, mission, or system must be determined
5. Analyze Failure Effects/Causes — accomplished on each item in the RBD. Consequences of each failure mode on operation and the next higher level should be identified.
6. Classify by Severity—severity provides qualitative measures of consequence. Severity is typically labeled as Catastrophic, Critical, Marginal, or Minor
7. Identify Means of Failure Detection, Isolation, and Compensation — answer how the failure is by the operator, how the failure isolated, and how is it compensated for (redundancy, monitor, back up)
8. Recommendations-design modifications or Fault Tree Analysis (FTA)

Summary

Often FMECA and FRACAS data use the same data elements definitions, they have the same overarching goals (improved reliability and maintainability), and even use similar metrics (Mean Time Between Failure (MTBF), Mean Time Between Critical Failure (MTBCF), Mean Time to Repair (MTTR), etc…) to determine results. The basic reason why these two processes seem so similar, yet are different, is when they are performed and why. You will often use engineering estimates for data during the FMECA process, and use actual measured failure data during a FRACAS process.