Run-Time Operational View

The Diagnostician is a major innovation to the overall test process. To support embedded and off-line applications, the run-time Diagnostician has been designed to operate in a myriad of host platforms.

The new model-based diagnostics paradigm treats the diagnostic logic as an "object" which interacts with test results to perform fault isolation. In the next generation test system, the test executive will be replaced by a "Client" which invokes the "Services" required by the system. The test object will communicate to the Diagnostician object in the Windows Dynamic Link Library (DLL) protocol. For the purpose of this discussion on interfacing the Diagnostician in the Windows-based framework, the term Client will be used. Client is used here as a generic name for any Windows-based software which communicates to the Diagnostician using DLL. Note, however, that the operating modes discussed in this paper may be extrapolated to any operating system: DOS, Unix, X-Windows, VMS, or any test environment including LabVIEW, CVI, HP-VEE, ATLAS, etc.

Since Diagnostician functions are callable as "building blocks" the programmer can implement diagnostic function in any way that fits his test program structure and test philosophy. We show in the next few paragraphs, examples of three different approaches to using Diagnostician functions to effect different test strategies. These examples represent different scenarios for test execution, sequencing and program control based upon using the Diagnostician to perform diagnostics. These examples are characterized as follows:

Diagnostician in Control Example -

where the Diagnostician manages the flow and execution of tests.

Go/No-Go Test in Control Example -

where the Client calls and implements a set of functional, or go/no-go tests, passes the results to the Diagnostician, and the Diagnostician subsequently takes control of the flow and execution of tests.

Mixed Control Example -

where the control of the flow and execution of tests can be passed between the Diagnostician and the test object within the Client.

In the GO/NOGO Control Mode, the Client software will first execute all of the go/no-go (functional/performance) tests. If, at the end of the program, any of the tests fail, the Client initiates the Diagnostician using a simple function call and passes to it all of the test results. Next the Client requests either an ambiguity group call-out or the next best test to be executed. This mode is good for short GO/NOGO test programs where each test does not require a large amount of setup time or long testing sequences.

In the Diagnostician Control Mode, the Diagnostician is used to make all decisions on what tests are to be executed. In this mode, the Client initiates the Diagnostician before any tests are executed. Then the Client issues a DLL function call to the Diagnostician to identify the first test to be executed. The test to be executed is passed to the Client as a response to the function call. The Client will execute only those tests the Diagnostician requests until a final ambiguity group is found. The final ambiguity group is found when either the ambiguity group contains only one replaceable part, or when no more tests exist which will break up the current ambiguity group. This mode is good for tests that require a large amount of setup time or where tests are lengthy. A diagnosis can be made using the least amount of tests and testing time. Only those tests with any diagnostic significance will be executed.

The Mixed Control Mode is a combination of the two previous test modes. The Client will start out in the Go/No-Go Control Mode. All Go/No-Go tests will be executed and if a failure occurs, the Client will initiate the Diagnostician and perform as in the Diagnostician Control Mode. This mode can either stop at first failure in the go/no-go test or can run all go/no-go tests at once. The Mixed Control Mode is good for test programs with both short and long test sequences. The shorter tests can be executed at the top of the program. If they fail first, then the Diagnostician will reduce the number of tests and the testing time required to make a fault call-out.

The software architecture of the Diagnostician is that of a server. The Diagnostician provides diagnostic services to any client program.. The Diagnostician acts as a server task which performs functions that provide diagnostic services. When properly interfaced on the client side, the Diagnostician functions as a library of subroutines within the client program.

The Diagnostician software, in Windows, is compiled as a Dynamic Link Library. It is a true diagnostic server which provides diagnostic services to a client program. That client program may be a test executive, test programs, LabVIEW, ATEasy, HP-VEE, or any other independent program which "sits in-between" the Diagnostician and the test program..

For example, in LabVIEW, these Diagnostician DLL function calls have been implemented as a series of virtual instruments, and the flexible test strategies in the previous discussion can be implemented easily, as shown in the following figure.

Next

Back to Table of Contents

Send mail to webmaster@giordano.com with questions or comments about this web site.
Last modified: July 05, 2000