|
An innovative aspect of Operator Debrief is the capabilities of and methods to incorporate filtering and grouping of anomalous events, which are
needed to reduce false alarms and increase diagnostic accuracy and effectiveness. These are described below.
Multiple Occurrence Filtering
Consecutive occurrences of a fault code are combined into one incident. Rules
are used that are based on either (1) time frame, or (2) number of occurrences.
An incident can be automatically classified as an anomaly based on the number of consecutive fault code occurrences. For example, “if
BIT Code 718 occurs consecutively 10 times then automatically classify the incident as an anomaly.”
Multiple incidents of the same type within a mission can also be filtered using rules. The types of rules required are:
- Classify only the first incident within the mission as an anomaly and disregard all others.
- Classify all incidents within the mission as anomalies.
- Classify only the X incident within the mission as an anomaly and disregard all others.
Anomaly Filtering
Filtering rules consist of two parts. Filtering rules can be defined as an “if-then” statement. The “if” portion, is the condition. If the condition is met, the “then” portion is applied as an outcome or action. The types of filters
used in Operator Debrief are:
- Always disregard this incident as a nuisance fault, do not display the incident to the operator or report the incident to maintenance as a fault.
- Based on a rule, disregard this incident as a nuisance fault, do not display the incident to the operator or report the incident to maintenance as a fault.
- Always treat this incident as a reliable anomaly that does not need confirmation.
- Based on a rule, treat this incident as a reliable anomaly that does not need confirmation.
- Based on a rule, combine these incidents as one anomaly that does not need confirmation.
- Based on a rule, combine these incidents as one anomaly that requires operator confirmation.
Conditions
Conditions are relationships between incidents and/or parametric data within a time frame. For example:
If incident, BIT Code 718 Hung Stall, also occurred with 30 seconds, then disregard this incident,
BIT Code 702 EGT Over Temperature, as a consequential fault for,
BIT Code 718 Hung Stall. Only the anomaly associated with incident,
BIT Code 718 Hung Stall, will be created.
Outcomes and Actions
There are two types of outcomes when a rule is found to be true. The first is the classification of the incident as an anomaly. All anomalies are reported by Operator Debrief as faults. The second type of outcome identifies the reliability of the anomaly. Reliable anomalies do not get displayed to the operator during debrief for confirmation. A list of reliable anomalies will be available to the operator upon request.
Anomaly Recognition Outcomes - If the rule is true, three anomaly recognition outcomes are possible:
(1) the incident is an anomaly
(2) the incident is not anomaly
(3) the incident is combined with other incidents to create a single anomaly
Reliability Outcomes - If the rule is true, two reliability outcomes are possible:
(1) the anomaly is reliable, no confirmation required.
(2) the anomaly is NOT reliable, confirmation by the operator required.
Reporting Rules
All anomalies are reported as faults. The fault
exists inside the maintenance system at the proper level of
indenture. For example, a fault inside the engine
is assigned to the engine sub-system. The level of isolation achieved by the Diagnostician
is used to determine whether the fault is associated with a replacement or troubleshooting task.
All operator observable faults are reported as system level faults with no task. The maintenance chief will decide whether to assign tasks to the operator’s observations.
|
