Fault definitions
Fault definitions, much like other types of task definitions, are reusable templates that describe common and frequently encountered faults and provide information for solving the problem. Maintenance personnel who encounter a problem can raise a fault using a fault definition.
Also, fault definitions are used to create possible faults automatically through the Diagnostics API; this is achieved through the use of failure effects, which are symptoms of problems that are reported by systems on-board an aircraft.
Every fault definition can be associated with one troubleshooting requirement definition. The troubleshooting requirement definition must have a class of CORR (Corrective Action) and a status of ACTV or BUILD. When a fault is raised from a fault definition, the associated troubleshooting requirement is automatically initialized in Maintenix. To provide all possible corrective actions to attempt to solve the fault, you create job card definition subtasks in the troubleshooting requirement.
You can associate each fault definition to other task definitions during which it is possible to encounter the problem covered by the fault definition, for example, an inspection job card. These are referred to as the initiating task definitions. When finding a fault during the execution of a task (the inspection), the technician can search in Maintenix for fault definitions associated with the task, which saves time.
The following diagram depicts the relationships between initiating task definitions, failure effects, fault definitions, troubleshooting tasks, and possible corrective actions.
Figure: Fault Definition Model
Other attributes you can specify in fault definitions include the severity, failure category, failure type, priority, description and operational restrictions. Depending on the severity of a fault, you might also be able to specify a deferral class, which is the type of deferral, and a deferral reference. Deferral references are deferral authorization numbers, usually obtained from maintenance control. Maintenix provides preset values for these attributes; your Maintenix administrator can add more values if necessary.
Unlike other types of task definitions, fault definitions do not have a life cycle—they do not go through the Build, Active, In Revision, Superseded, and Obsolete statuses. If a fault definition is no longer applicable, and you do not want the technicians to reference this fault definition when logging new faults, you can delete the fault definition if it has not been used already, or update the name of the fault definition to indicate that it should not be used, for example, by adding a prefix such as OBSOLETE or DO NOT USE for those that have been referenced.
The following are the benefits of using fault definitions:
- Less data entry for technicians because fault properties are automatically populated in Maintenix based on the fault definition.
- More timely and appropriate fault resolution because information is provided in the fault definition, such as the parts, tools, work instructions, labor skills, and Minimum Equipment List (MEL) details, as well as troubleshooting and corrective actions.
- Improved reliability analysis by standardizing the recording of the faults, which results in historical consistent data.
Fault Severity
The fault severity indicates how critical a fault is. The severity of a fault determines whether users can defer the fault or of they have to leave it open; some severity values allow users to defer a fault, as long as they supply a deadline for the fault resolution, while other severity values do not require a deadline.
Maintenix uses the severity of the most severe open fault to calculate the aircraft operating status. The default severity values range from minor to AOG, and have the following implications:
| Severity code | Description | Aircraft status | Can defer fault? |
|---|---|---|---|
| MINOR | The fault has no operational impact. | No change. | Yes; no deadline. |
| MEL | The failure is MEL related. | MEL no restriction. | Yes with deadline. |
| MINR-WD | The fault has no operational impact. | MEL | Yes with deadline |
| MINR-WND | The fault has no operational impact. | No change | Yes; no deadline |
| CDL | Configuration deviation list fault. | MEL | Yes with deadline |
| CDL-WND | Configuration deviation list fault. | No change | Yes; no deadline |
| AOG | The fault is severe enough to ground the aircraft. | AOG | No |
| UNKNOWN | Unknown severity. | OPEN | No |
Fault Priority
Each fault definition has an associated priority which is used to indicate to a technician the importance of a fault diagnosis.
When defining a fault definition, several factors are considered to determine the fault definition's priority. For example, part cost, flight delay, and operational impacts all contribute to the priority of the fault definition.
Every fault definition has a priority reference term associated with it. Since fault diagnosis is used when raising faults, this priority tells a technician how important or likely a particular fault diagnosis is (as defined by the reliability experts). You can edit the priority of a fault definition.