
OPERATOR DEBRIEF
DEVELOPMENT TOOLS
Introduction
This section describes how to
develop an Operator Debrief application. The Operator Debrief run-time module
performs the following functions:
1)
accepts as input processed data logged from a system's operations,
2)
filters out erroneous or false alarm failures,
3)
prepares a profile of the operation, including any anomalous system behavior,
4)
interfaces with the operational crew to obtain confirmation of the anomaly,
5)
performs initial diagnostics, and
6)
prepares a list of maintenance actions for further investigation/maintenance.
The Operator Debrief uses the
Diagnostician in run-time and also uses a special data base that is created by
using the Operator Debrief development tool. The Operator Debrief development
tool is an option with the Diagnostic Profiler. The tool enables you to:
|
|
define the system data (operational data and anomaly data) that will be logged and provided as an input to an Operator Debrief session, |
|
|
combine the operational and anomalous data with a Diagnostic Knowledge Base generated with the Diagnostic Profiler, |
|
|
tailor how the fault annunciation will be presented to the operator for confirmation, |
|
|
define rules for filtering and grouping of certain classes of faults, and |
|
|
tailor the outputs to the maintenance organization or, if applicable, maintenance information system. |
APPLICATION SCENARIO
AND TERMS
The scenario for an application of
the Operator Debrief is as follows: during a system's operation, certain data
relative to operational parameters are logged and stored to a memory device.
Additionally, operational anomalies and faults detected by performance
monitoring or BIT are logged to the same or another memory device. Potentially,
raw sensor data may also be logged. Upon completion of the system operation,
the logged data is available to the maintenance crew. The Operator Debrief
program prepares this information for the operations/maintenance crew by
correlating anomalous data to operational parameters at the time surrounding
the anomaly. In order for this process to work, the data that is to be stored
on the memory device must be well-defined to the Operator Debrief software.
Several software "bridges" are expected to facilitate this
requirement. The figure below shows the overall software architecture.

The Logged Data can be in any format and on any type of memory storage device.
The Data Stripper is system
specific software that takes the logged data (in a format and content that
is unique to the system) directly from the memory storage device and converts
it to a format that can be input to the Operator Debrief tools.
The Anomaly Analyzer and Anomaly
Organizer analyze and organize the logged data that is output from the Data
Stripper, extracts data that is relevant to faults to be reported, and
organizes them into "snapshots" of relevant information about
operational conditions at the time of any anomalies. These software tools
perform these functions based upon definition of information about faults that
is contained in a database created by the Operator Debrief development tool.
Therefore, in using the Operator Debrief development tool, you are defining
what data is available on the log file, and how that data is analyzed and
organized.

The first step to organizing the
recorded system data is to select all possible failures as
"incidents" based on failure criteria definitions. Incidents are a
sub-set then of all the recorded system data available. From that sub-set,
filtering and grouping rules are applied to obtain verified failures,
"Anomalies" that will be reported as failure conditions by Operator
Debrief. There are two types of anomalies: reliable and unreliable. The
reliability of an anomaly is determined based on the reporting rules defined.
Reliable anomalies require no confirmation by the user during debrief and are
not presented to the user for confirmation. Unreliable anomalies require
confirmation by the user during debrief and always presented to the user during
debrief.
The Operator Debrief Development
Tool has been designed as a Wizard to step the user through the process of entering
the appropriate data. The steps include:
Step 0 -
Create or Load Operator Debrief project
Step 1-
Define System Data in terms of Fields and Frames
Step 2 -
Capture Diagnostic Profiler diagnostic information
Step 3 -
Define Potential Failure Modes in terms of out of tolerance conditions
Step 4 -
Define Potential Failure Descriptions
Step 5 -
Define Potential Failure Display
Step 6 -
Define Multiple Occurrence Filtering, Anomaly Filtering and Reporting Rules