The Failure Reporting and Corrective Action System (FRACAS) is a closed-loop process whose purpose is to provide a systematic way to report, organize and analyze failure data. Implementation of a FRACAS has increasingly become commonplace within an industry. The requirement for implementation of some type of FRACAS within a DoD program was first established in 1985 with MIL-STD-2155. However, in 1995 that standard was reestablished with no changes to content as a handbook, MIL-HDBK-2155, and was recommended as guidance. Today, multiple software solutions exist that provide all the functionality required of a FRACAS.
FRACAS Process
Each FRACAS process will capture a number of different elements; however, the following features are generally required at a minimum:
- Failure Reporting. Failures and faults that occur during developmental or operational testing or during inspections are reported. The failure report should include identification of the failed item, symptoms of the failure, testing conditions, item operating conditions and the time of the failure.
- Failure Analysis. Each reported failure is analyzed to determine the root cause. A FRACAS should have the capability to document the results and conclusions of the root cause analysis.
- Design Modifications. Details of the implemented corrective actions for each failure mode should be documented. The precise nature of the design change should be captured as well as a date of implementation.
- Failure Verification. All reported failures need to be verified as actual failures by repeating the failure or evidence of failure, such as a leak or damaged hardware. This verification needs to be tracked within the FRACAS.
FRACAS is an essential tool when considering the DFR process, as it provides a systematic closed-loop process for reporting, analyzing and tracking failures through development and testing. Much like Reliability Growth Testing, FRACAS should be implemented early on in the system development timeline. Providing detailed failure data from an earlier stage makes it easier and less costly to implement the necessary corrective actions. As system development progresses, newly identified failure modes are limited in the options available for corrective actions, and implementation of design revisions is typically more difficult and costly.
Related:
Field Industry and Public Failure Data (article)
Types of failure data (article)
Discovery Testing (article)
Piyush Kant Singh says
Sir ,
Its Failure reporting analysis and corrective action system
Fred Schenkelberg says
yes, with a comma between reporting and analysis… often I forget the analysis word…. While a descriptive phrase it is hard for me to remember. cheers, Fred