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