5.0 DIAGNOSTICIAN APPLICATION DEVELOPMENT OVERVIEW

A Diagnostician Application consists of two components: a Diagnostic Knowledge Base and a Runtime Configuration File.

The Diagnostic Knowledge Base component is developed using the Diagnostic Profiler. It identifies context-specific linkages for test execution, test result capture, and test and repair procedures. It also defines what method of communication these linkages will have with the Diagnostician. For the Window-based LabView application, these communication linkages will be Dynamic Data Exchange (DDE) which is a Windows-specific communications protocol.

The Runtime Configuration File is developed using a text editor. It identifies program to program communication protocols, specifies Diagnostician operating modes, specifies data logging files and specifies debugging operating modes, if any. The Runtime Configuration File is used to reduce the amount of redundant information that must be placed in the Diagnostic Knowledge Base and to provide integration services.

The following subparagraphs identify the component elements used in development.

5.1 Run-Time Configuration File

The configuration file for Windows-based applications need only specify the name of the log file which will contain a summary of the diagnostic session. The following line should appear in the configuration file:

where <filename> is the name of the file. The name can have any extension desired by the user. An example is:

The name of the configuration file must match the name of the Diagnostic Knowledge Base. If the name of the knowledge base is RF_CIRC.DKB, the configuration file must be named RF_CIRC.CFG. Note that when a design is initially translated, a configuration file is generated and placed into the project subdirectory. This configuration file contains the many flags and settings required for exercising a knowledge base in the DOS or X-Windows environment using the Fault Propagation Simulator. This configuration file must be modified or recreated when moving the project data to a run-time environment for operating in Windows. Failure to re-create or modify the log file will result in the Diagnostician attempting to operate in simulation mode, and run-time errors will result.

5.1.1 Diagnostician Interface to LabVIEW: An Operational View

When the Diagnostician is first initialized, it expects the execution of the System Test routine, usually an end-to-end test, or a Built-in Test. The name of the test routine is defined as the System Test in the "Show System" window of the Diagnostic Profiler. It then expects those test results to be passed to it. Diagnostician operations are suspended until the LabView application sends a message containing the test results to the Diagnostician. If no System Test routine was identified in the "Show System" window of the Diagnostic Profiler (see Appendix A), then the Diagnostician, when initiated, simply waits for a message or request from the LabView application. If the LabView application is to send test result data that the Diagnostician is not expecting (Diagnostician did not request the specific test name or no test name identified in the "Show System" window) then the LabView application must first identify the name of the test with which the test results are associated (e.g. [POWER]).

The Diagnostician will analyze the test results it has been passed to arrive at a fault call-out. This analysis can have three outcomes: 1) isolation of a fault to a single item, 2) an ambiguity group where no further tests have been defined which will provide greater diagnostic resolution, and 3) an ambiguity group which can be further resolved based upon execution of more tests. In any of these cases, the Diagnostician will not report its findings until requested to do so using the NEXTSTEP Request. Based upon receiving this request, the Diagnostician will, for the first case listed above, send a message containing the Repair Procedure tag for the item to be replaced. For the second case listed above, the Diagnostician will send the full ambiguity group, listed in the order of failure rate. The Diagnostician will signify the end of the ambiguity group listing with the keyword "Done." In the third case listed above, the Diagnostician will pass the executable file name of the test which will best break up the current ambiguity group. The test executable name is that name defined in the "Executable" field in the Define Tests window of the Profiler. Diagnostician operations will again suspend until the test results are passed to the Diagnostician. It is expected that the LabView application will execute the identified test and pass the test results to the Diagnostician for further diagnostic analysis.

This process may continue until either the fault has been isolated to a single replaceable item, or until no more tests are available which will help to reduce the current ambiguity group, or until stopped via a Terminate message from the LabView application.

Send mail to webmaster@giordano.com with questions or comments about this web site.
Last modified: December 27, 2001