iTest Quality Partners

Download the Automated Fault Tree Analysis (AFTA) tool.

The Automated Fault Tree Analysis (AFTA) facility, originally developed to support missile failure analysis for the defense industry, assists project teams in identifying, organizing, managing, analyzing, and validating the root cause(s) of any type of system failure.

A system failure is any discrepancy between the system in actual operation (whether test or live use) and its expected results.

Moreover, the AFTA facility also permits the examination of potential patterns that may exist in root causes across systems and their failures.

AFTA consists of a database, a set of forms for operating on this database, and a set of reports that provide analytical windows into the content of that database.

There is one AFTA database for each system failure. The name of the AFTA database identifies the particular system failure under investigation.

The observation database is the primary analytical repository within the AFTA facility. It consists of a collection of individual observation records. All the relevant information about the system failure is contained in this collection.

Each observation record in the database defines a specific fact or conclusion related to the system failure that the project team deems important to the investigation. These facts—individual observation records—are entered, defined, enhanced, clarified, elaborated, and refined throughout the investigation by the project team.

There are three classes of information contained in each observation record:

Descriptive, the primary information and analytical content related to this observation instance
Direct Causes, the set of observations that the project team believes are direct causes of this observation; an observation with no direct causes is called a root cause observation
Project Management, the information regarding an observation’s analytical progress and completion status

In addition, certain observations can be classified as failure observations. A failure observation is that observation that the project team believes is the most macro or coarse manifestation of the system failure. A project team will typically identify several failure observations during a given system failure investigation.

Each failure observation becomes the head (or top) of a specific fault tree. A fault tree is simply a hierarchical arrangement of individual observation records in which the fault tree hierarchy itself defines the cause-effect relationships among those observation records in the tree.

From a project management view point there are two pieces of information within an observation record that are considered vital to the successful analytical progress of the investigation:

Classification, the relative likelihood that the given observation is, in fact, a direct cause of the observation(s) it is linked to in the fault tree; there are four possible values each implying an increasing likelihood: None (this is the default value and indicates that the project team has not yet assigned a classification to this observation), Not Probable, Possible, Likely
Status, an indication of the confidence that the project team has regarding this classification; there are four possible values each implying increasing confidence: None (the default value), Open, Pending Review, Pending Closure, and Closed

The goal of the system failure investigation is for the project team to sufficiently understand the meaning and context of these observations so that the actual underlying root cause(s) of the system failure are revealed, and thus can be corrected and the corresponding relevant requirements, design, engineering, construction, and deployment processes improved so that these failures never recur.

This goal is accomplished by carrying out the following activities:

Identifying and defining all the observations necessary to fully understand the system failure and thus its potential root cause(s)
Identifying those particular observations that are considered to be failure observations
Arranging the other observations in the database so that they are contained in one or more fault trees, or are discarded as not being relevant to the system failure under investigation
Closing each observation in the database

As can be seen, the ability of the project team to fully populate the fault trees with the relevant observations that yield insights into its root causes is a vital element of any system failure investigation. Further, the success of this aspect of the project team’s work is largely a function of utilizing a data gathering and analysis process that is organized, rigorous, and complete. Ishikawa, who invented these fault tree diagrams (also known as Ishikawa or fishbone diagrams, see Guide to Quality Control, Kaoru Ishikawa, 1982, Quality Resources, White Plains, NY) suggested three different approaches for carrying out this important work. These three ideas are paraphrased below:

Variation source, this approach organizes observations by the five resource categories that define every process: People, method, material, equipment, and environment. The project team starts with a failure observation and asks: Why does this failure occur? The answers are arrayed under their appropriate resource category. For example, all the observations related to people (lack of training, improper skills, etc.) are placed under the people branch, all the observations related to the method or practices (out-of-date manual, too general procedures, etc.) are placed under the method branch, etc. The key to its effectiveness lies in continually asking the question: Why did this occur?
Process classification, this approach organizes observations by the relevant steps in the engineering, manufacturing, and support processes that were used to actually deliver the system under investigation.
Cause enumeration, this approach seeks to take an open and unrestricted view of the system failure and to ask the project team to free-associate on the possible causes without regard to their source or likelihood. In this approach, observations are noted and identified first in an attempt to get all the key thoughts and ideas captured, and then are organized into cause-effect sub-trees.

The key is to select an approach that is compatible with the skills, background, and working relationships of the project team. Note the AFTA categories table can be used to capture this information for each observation.