Failure Reporting And Corrective Action System

 
 
but end tab giftab strip gifproject tab gifcontact tab gifservices tab gifhome tab gif

Reliability Programs
FMEA/ FMECA
Reliability Predictions
Reliability Modeling
FRACAS
Design for Reliability

Failure Reporting and Corrective Action System

The Failure Reporting and Corrective Action System (FRACAS) commonly referred to a "Closed Loop Reporting System", is instrumental in understanding how an equipment or system is actually performing in the field from a reliability (and maintainability) perspective.

The benefits of implementing FRACAS can be realized in a number of ways. A FRACAS can be of great importance to a manufacturer with respect to the operation and performance of a system. The manufacturer will see it in terms of how well their equipment or systems are performing in an operational environment. The information furnished from the FRACAS will enable correlation to be made between predicted reliability and maintainability (R&M) data and actual performance R&M data. This information will permit better informed decisions for new designs and provide confidence over issues associated with warranties etc.

For an organization operating a system or a multiple of systems, an effective FRACAS, will reveal when there are potential reliability (and maintainability and logistical) HOT SPOTS. For example a small airline company operating a fleet of several midsize commercial jets, this information could be used to determine the optimum operations and maintenance costs.

 

 

 

FRACAS Procedure

The purpose of a FRACAS procedure is to provide the required method, guidelines and the responsibility for implementing a Failure Reporting and Corrective Action System (and Data Reporting and Corrective Action System (DRACAS)) that would be required for a particular project or program. The FRACAS could require the support from many team members, who themselves are required to play an active role in the FRACAS process.


FRACAS Responsibilities

The responsibilities of the keys players would be detailed in the FRACAS procedure and could include the following players for a given program or project:

Engineering Manager - responsible for ensuring that program or project requirements and objectives, regarding the failure reporting system, are addressed. This could include, ensuring that all the responsible parties fulfill their obligations as detailed in the procedure.

Program/ Project Manager - is responsible for ensuring the implementation of corrective actions at the program level as a result of the evaluation and identification of problems relating to R&M issues.

Reliability and Maintainability Engineer - is responsible for reviewing collected "Field Data" for quality and completeness. In addition the engineer will review and analysis all data from all sources to identify any potential problems and trends.

System Maintainers - are responsible for the actual collection of "Field Data". The System Maintainer may be the organisation implementing the FRACAS or the customer of the system/ product.

Production/ QA Staff - Would be responsible for the collection of failure data during the production phase. This phase could last for several weeks to several years

Integration & Test Engineering - is responsible for the timely collection of the required R&M "Field Data" as detailed in the procedure, during a test phase.

Subcontractors - are responsible for implementing, as contractually required, a failure reporting system that will address failures for the equipment to which they are responsible for. They will, upon completion of their own internal analysis and evaluation, forward failure report to the organisation maintaining the FRACAS. These failure reports would provide details of an item's repair to the component level.

Vendors - are responsible (where required) for providing failure reports for their products. These reports would be retained within a central collection point.


FRACAS Procedure

A FRACAS and DRACAS could be implemented for a program during the specified production, integration, test and field deployment phases to allow for the collection and analyses of reliability and maintainability data for the hardware items. These items could be considered to be Line Replaceable Units (LRUs) and Shop Replaceable Assemblies (SRAs).


 

Process

The FRACAS/DRACAS information would be collected using a report format. Depending upon the complexity of the system or systems and their intended operational profile, this could be achieved by using a simple form or may require a more complex database. The person as detailed in the FRACAS/ DRACAS process procedure will complete the individual data element field. An example of a process is given in the illustration to the LEFT. Obviously depending upon many factors the actual process would vary, for any particular system and it's operational scenario.

Failure Identification

Upon detection of a system failure, which is deemed to be a cause of a hardware failure the FRACAS/DRACAS process would be implemented by initiating the failure reporting sequence.


FRACAS Process

Click to Enlarge

 

Field Data Collection

The responsible person will collect the required field data. This would vary depending upon program requirements and the phase of the program itself. This data will be collected to a level commensurate to the level of maintenance performed in the field (e.g. to the LRU or SRA level). The action of the responsible person may include;

  • Initiate the Failure Reporting Sequence;
  • Collect the Field Data as listed in FRACAS FORM;
  • Forward the failure report to the Reliability Engineering Manager (This may be done automatically using a database utility).
FRACAS Form
Click to Enlarge
 
Supplementary Data

The subcontractors and vendors for units (LRU and SRA) that will be repaired at their facilities will supply supplementary failure data. The Reliability Engineer will:

  • Annotate the Failure Report with status that "Awaiting Failure Data From The Vendor";
  • Monitor the status for vendor failure data submission;
  • Upon receipt of vendor failure reports, enter required data in to the database; and
  • Review the failure data for possible and actual problem trends.

 Reliability & Maintainability Evaluation

The after the collection "Field Data" elements the Reliability Engineering would review each Failure Report for the following:

  • Field Data is complete, of sufficient detail and quality;
  • Determine if there are potential problems and/ or unwarranted trends;
  • Disposition and close out the Failure Report if no action is required;
  • Initiate a failure analysis, if required due to potential problems or trends;
  • Report potential problems and trends to the Corrective Action (CA) team members;
  • Annotate Failure Reports with CA disposition and the CA log number;
  • Monitor the timely response of and submission of vendor failure reports;
  • Monitor the status of all open Failure Reports; and
  • Preparing the FRACAS/ DRACAS data for inclusion into the R&M Reports (if required and/ or detailed in a R&M Plan).

To ensure that potential problems are identified and in the event that appropriate actions may be initiated, the Reliability Engineer will review all collected data. E.g. if a failure report is raised for WRA xxx, a search will be conducted to ascertain if other similar failure have occurred to the item type in question. This problem review activity will:

Reliability: Monitor the MTBF data in the case of unwarranted failure patterns. Establish possible common failure cause, e.g. SRA, power module yyy

Maintainability: Monitor maintainability characteristics such as, BIT effectiveness, accessibility, fault diagnostics problems etc.

Vendor: Monitor vendor failure report for unwarranted failure trends e.g. same CCA and/ or component, No-Fault-Found (NFF) or No-Evidence-Of-Failure (NEOF), indicates inadequacies in diagnostics capability (BIT, test procedure etc.)

Customer: Focus on gray areas such as physical and functional interfaces for modified between the equipment and system


Failure Analysis

Prior to issuing a corrective action a detailed investigation into the cause of the failure trend maybe warranted. The Reliability Engineer will consult with the Reliability Engineering Manager, to obtain the required engineering support and resources.


Disposition

The Reliability Engineer will disposition a Failure Report with one of the following category types:

No Action Required:

  • Original failure deemed not to of been caused by H/W
  • H/W failure occurs within a equipment, which is not considered as part of the primary configuration.
  • No potential problem or unwarranted trend identified

Observation:

Follow the evaluating of a series of failure the Reliability Engineer flags potential problems

Corrective Actions:

  • The evaluation of a Failure Report has result in a Corrective Action been issued.
  • The Corrective Action is issued to prevent the reoccurrence of a potential problem. This can be a change in procedures, design recommendations e.g. thermal changes, OTS h/w changes etc.

R&M Reports

The Failure Reports will be compiled into a R&M Report, this would be detailed in the project/ program R&M Plan or as supporting procedures. These would normally be compiled and developed by the Reliability Engineer. All Failure Reports that are satisfactory disposition within the reporting period in question will be included in the R&M Report submission.

MTain looks forward to receiving your comments about this Web Site. Send your comments to services@mtain.com



Links: home reliability maintainability logistics programs safety services
Welcome to MTain Services
Copyright © 2001 - 2009 MTain except where otherwise noted. All rights reserved. Reproduction in whole or in part without permission is prohibited.

Last Updated: July 2009
Contact: info@mtain.com