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 as well as the date of implementation should be captured.
• Failure Verification. All reported failures need to be verified as actual failures by repeating the failure or evidence of failure (e.g., a leak or damaged hardware). This verification needs to be tracked within the FRACAS.

A FRACAS is an essential tool when considering the design for reliability process, as it provides a systematic closed-loop process for reporting, analyzing, and tracking failures through development and testing. Much like reliability growth testing, a 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.

The terms FRACAS, bug tracking, or defect tracking all relate to the process of recording issues, problems, defects, unexpected behavior or performance, testing anomalies, or product returns to effect product improvements. Failure happens. Recording, resolving, and learning are the gifts provided by a product failure.

A FRACAS may be as informal as a small team discussing issues noticed the previous day to the use of specialized database programs with hundreds of people involved. The essence is for every defect or failure to be captured within the system. The process usually entails some form of failure analysis and triage to determine the appropriate action to take in response to the failure. Options include making a product design change or adjustment or a material change—or even ignoring the issue. Every failure provides information, some will require action, and often not all issues that arise will have available time or resources to effect a change.

Tracking issues during the design phase helps to ensure that issues identified during the design process are resolved prior to customer use. Given the limited number of prototypes generally available, every failure, if not resolved, may indicate a relatively high failure rate once the product is in the field.

Tracking issues once the product is shipped provides the necessary feedback on actual product reliability under normal operating conditions. Here is where the assumptions made during the design process are actually put to the test. If the failure rate is from the expected failure mechanisms and at the expected rate, then the work during the design process has been accurate. If not, the new information provides a means to not only improve the product now but also feedback to the entire process of designing a reliable product.

Bio:

Fred Schenkelberg is an experienced reliability engineering and management consultant with his firm FMS Reliability. His passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs. If you enjoyed this articles consider subscribing to the ongoing series Musings on Reliability and Maintenance Topics.