The MIL-STD definition of a Failure Reporting, Analysis, and Corrective
Action System (FRACAS) is "a closed-loop system for initiating reports,
analyzing failures, and feeding back corrective actions into the design,
manufacturing, and test processes." The primary objective of a closed-loop
FRACAS is to document failures, analyze the cause of failures, determine
corrective action, and disseminate the data. The timely dissemination of
accurate failure information is necessary so that remedial actions may be
taken promptly to prevent the recurrence of the failure.
A number of pitfalls exist in the world of FRACAS. Typically, there is a lack of detailed procedures at the working level; a lack of integrated feedback of anomalies, problems, and failures; and a definite lack of discipline. Most of these problems exist even though detailed instructions appear in applicable military standards on how a FRACAS should be implemented. Total compliance with MIL-STD requirements often is hampered because the requirements are not tailored to a particular project. Most FRACAS problems can be alleviated through proper planning which describes the management procedures for controlling failure report initiation, failure analysis, and the feedback of corrective actions into the design, manufacturing, and test processes.
An atmosphere of openness and encouragement needs to be fostered so that all problems are surfaced at the lowest levels of hardware at the earliest possible time. Early implementation of a FRACAS is important because corrective action options and flexibility are greatest during design evolution. The earlier that failure causes are identified, the easier it is to implement corrective actions. As the design matures, corrective action still can be identified, but the options become limited and implementation becomes more difficult.
A FRACAS will be effective only if the input data in reports documenting failures are accurate. Essential inputs should document all conditions surrounding a failure to facilitate cause determination. The failed item should be identified when a failure occurs and all pertinent information about the failure should be documented on the report form. Each reported failure should then be verified and analyzed to the extent necessary to identify the cause of failure and any contributing factors. Failure analysis can range from a simple investigation of circumstances surrounding the failure to a sophisticated laboratory analysis of the failed hardware. The level of analysis should be sufficient to provide an understanding of the cause of failure so that logically-derived corrective actions can be developed. Failure data that is collected in a FRACAS is useful only when aggregated for purposeful evaluation. A failure data system should be designed to collect, store, and retrieve failure information and to provide the means for displaying the data in a meaningful form. The outputs of a failure data system should be tailored to provide summaries and special reports for both management and engineering personnel. The failure summary is a useful output of a failure data system should provide information that automatically alerts management when failure reports are open longer than 30 days.
After a corrective action is implemented, it should be monitored to ensure that the failure cause has been removed and that no new problems have been introduced. If the corrective action proves ineffective, then the failure report should be reopened until an effective corrective action is developed.