In the LabVIEW environment, LabVIEW performs tests, and reports test results to the Diagnostician. The Diagnostician, like a doctor, interprets test results to zero in on the cause of the fault. The conversational flow between LabVIEW and the Diagnostician is much like described above.

As shown in Figure 2, a Diagnostician application consists of the following elements:

1. WINADR.EXE - the executable inference engine which reasons about the cause of failures based upon interpreting test results.

2. modelname.dkb - a diagnostic knowledge base (DKB) which contains all of the diagnostic logic of a unit under test (UUT). The DKB is generated from UUT netlist data and is prepared using the Diagnostic Profiler.

3. modelname.cfg - a run-time configuration file which specifies data log files.

The Diagnostician contains a series of core functions. These functions are implemented within the Windows DDE communications protocol (used by LabVIEW) as a group of Keywords: INITIATE, TESTDATA, NEXTSTEP AND TERMINATE. These primary keywords serve as the basis for implementation of Diagnostician functions. These keywords have been built-up into LabVIEW functions and "packaged" as LabVIEW virtual instruments. These virtual instruments can be easily integrated into your LabVIEW application as you see fit. Integration of the Diagnostician VIs is similar to use of any LabVIEW virtual instrument: simply call the VI (e.g., OPEN_DOC.VI) and provide the required inputs and define how the outputs are used in your application. The Diagnostician VIs (OPEN_DOC.VI, TELL_DOC.VI, ASK_DOC.VI and CLOSE_DOC.VI) are described in Sections 3.1 through 3.4.

Examples of specific implementations, or templates, of the Diagnostician VI's have been provided in the installation. These specific implementations represent a variety of ways that you can use the Diagnostician to provide automated diagnostics. These templates are described in Section 4.

PLEASE NOTE: The Diagnostician is a run-time system which operates on a knowledge base of a specific Unit Under Test (UUT). The UUT diagnostic knowledge bases for specific UUTs are generated using the Diagnostic Profiler. Appendix A provides an overview of this process.

3.1 Initiate LabVIEW/Diagnostician Conversation (OPEN_DOC)

OPEN DOC is a Diagnostician process which is implemented as a LabVIEW Virtual Instrument. OPEN_DOC can be integrated into any LabVIEW application just as any other LabVIEW VI. OPEN_DOC initiates the Diagnostician in the background as another process and initializes the Windows Dynamic Data Exchange (DDE) protocol required by both LabVIEW and the Diagnostician. The OPEN_DOC VI opens a DDE-mediated conversation and will return a DDE reference number to be used by all subsequent calls to the Diagnostician. This reference number is considered the Diagnostician's "mailing address." This number will change only when OPEN_DOC is executed again, re-initiating a new conversation.

When the DDE-mediated conversation is established using OPEN_DOC, the Unit Under Test (UUT) -specific Diagnostic Knowledge-Base (DKB) must be identified to the Diagnostician. This is also accomplished through OPEN_DOC. A string containing the DOS path name for the DKB is passed to OPEN_DOC. The VI will then associate this DKB to the Diagnostician process.

For example, the Diagnostician under Labview is called WINADR. WINADR will be executed in the background as another process. OPEN_DOC will initiate the DDE protocol and assign a reference number, (e.g., B42) and then associate the DKB file name, (e.g., C:\DACDEMO\DAC.DKB), to the WINADR process. The UUT-specific Diagnostic Knowledge Base is generated using the Diagnostic Profiler (See Diagnostic Profiler User Manual for details on creating a UUT DKB.)

The LabView application must pass the results of tests to the Diagnostician. This is accomplished using the TELL_DOC VI. In order for the Diagnostician to correctly identify and analyze the test results, the results must correlate to the Diagnostic Knowledge Base created by the Diagnostic Profiler. This correlation is provided by following the formats defined below.

TELL DOC is integrated into your LabVIEW application to report test results to the Diagnostician. TELL_DOC is a function which can be called to report test information gathered during test execution to the Diagnostician. The TELL_DOC VI is an implementation of the Diagnostician keyword TESTDATA. This tells the Diagnostician that the incoming information is test results data. TELL_DOC uses the reference number assigned in OPEN_DOC.

Test results may be reported to the Diagnostician one result at a time, or several test results at once, depending on the nature of your application and testing scenario. Since the Diagnostician interprets test result data sent in any order, you have complete freedom to implement your application as you see fit. For example, if a group of tests use similar assets, then you may want to run all of those tests, report the information to the Diagnostician using TELL_DOC, and then continue with additional test execution. Section 4 provides information on the various approaches that can be used in integrating the Diagnostician into your Labview application.

NOTE: While TESTDATA is being transmitted into the Diagnostician, no calculations will be performed, i.e., no analysis of test results is performed until the NEXTSTEP command is requested by your LabView application.

TESTDATA

TESTDATA is a keyword which identifies that the information to be passed is information which is test result data.

[Testname]

This message identifies the name of the test for which test results will subsequently be passed to the Diagnostician from the LabVIEW application. If test results are being passed for a test which the Diagnostician has just requested, then this identification message is not necessary. However, if the test results to be passed are associated with a test which was not just asked for by the Diagnostician, then the test that they are associated with must be identified. The square brackets are required. The test name must match the test name identified in the Diagnostic Profiler, and is case sensitive.

Test_Location=P/F/R;

This message identifies the test results of a specific test location, or test points associated with the [Testname], (as defined in the Diagnostic Profiler). The possible test results of the test location are P=Pass, F=Fail and R=Refused. The Test_Location designation must exactly match the name of the test location as it appears in the Diagnostic Profiler, and is case sensitive. A refused test is any test that was requested by the Diagnostician, but not performed for any reason, such as due to operator decision or test equipment availability.

<ALL>=P/F/R;

ALL is a keyword which can be used to signify that all of the effected tests locations associated with the identified test name have either Passed, Failed or were Refused. The angle brackets (<...>) are reqired, and the keyword ALL must be sent in capital letters.

<REMAINING>=P/F/R;

REMAINING is a keyword which can be used to signify that the remaining test locations associated with the identified test have either Passed, Failed or were Refused. This can be useful for tests which have many effected test locations. For example, if three of twenty test locations have failed, and the rest passed, then the names of the three test locations which failed could be poked, and the message <REMAINING>=P; can be used to simplify the message string. The angle brackets (<...>) are reqired, and the keyword REMAINING must be sent in capital letters.

3.3 Request Diagnostician Results (ASK_DOC)

Your LabView application can get several types of information from the Diagnostician. What information you choose to use and how you choose to use it is up to you, based upon the needs of your test scenario and your own preferences. Getting information from the Diagnostcian is done with the ASK_DOC VI. The ASK_DOC VI returns the following data: 1) the Next Step to be performed, 2) the current ambiguity group, and 3) the number of items in the current ambiguity group. The ASK_DOC VI is an implementation of the Diagnostician keyword NEXTSTEP. NEXTSTEP causes the Diagnostician to perform detailed analysis and calculations of all test results it has received in order to derive a fault call-out or a "next best test" determination. NEXTSTEP is the only function which causes the Diagnostician to perform its analysis. NEXTSTEP will return either 1) the next best test to be executed, given the current fault scenario, or 2) a listing of the item(s) which are in the current ambiguity group, or the final fault call-out.

ASK DOC will cause the Diagnostician to calculate the NEXTSTEP. The result of NEXTSTEP will be either a test to be executed or a repair callout. The keyword NEXTSTEP is sent to the Diagnostician. The Diagnostician will process the TESTDATA given to it by the TELL_DOC VI and return the NEXTSTEP information. If it is a test, then a case structure can be employed under LABVIEW, the test will be executed and the test results will be reported using TELL_DOC. If the NEXTSTEP is a fault call-out or ambiguity group, then the call-out can be reported to the user or a repair procedure can be executed (displayed). If there is more than one component, the keyword AMBIGUITY must be used in the ASK_DOC VI. The request for ambiguity will continue until the list is exhausted and the word DONE is returned by ASK_DOC.

Again, the reference number assigned by the OPEN_DOC VI is used to manage the execution flow within LabView.

For example, if ASK_DOC requested the NEXTSTEP and the test name HIGH was returned, then LABVIEW would execute the routine defined as HIGH. LabVIEW would report the results using TELL_DOC and the keyword TESTDATA. Then another ASK_DOC would be issued to request the NEXTSTEP. If this time, ASK_DOC returned a component, (e.g., A11), then LABVIEW would be expected to execute the repair procedure associated with A11. This procedure would consist of calling ASK_DOC with the AMBIGUITY keyword to obtain the list of defective components (R19, Q3, Q4 and C7).

NEXTSTEP

NEXTSTEP is a keyword message which requests the Diagnostician to identify the next step in the diagnostic session. The next step could be either the execution of a test or a tag to a repair procedure. When the Diagnostician receives this command it will respond with a "value" which identifies the next step data back to the client. The client is then expected to cause the requested action to be executed. The Diagnostician then awaits test data in response to a request for test execution. If the next step was a repair procedure, the Diagnostician assumes all tests have been exhausted and awaits a message to terminate.

AMBIGUITY

AMBIGUITY is a keyword which can be passed to the Diagnostician to request the current ambiguity group. The current ambiguity group will be passed, each as its own message string, and will be completed with the keyword "Done" when the end of the ambiguity group has been reached. Note, AMBIGUITY does not end the diagnostic session. Additional tests, if available, can be requested to reduce the ambiguity group that was passed. (Note also that AMBIGUITY does not cause the Diagnostician to process the latest information, or test results received since the last NEXTSTEP. NEXTSTEP must first be executed to receive the most current diagnosis.)

3.4 Terminate Conversation (CLOSE_DOC)

CLOSE DOC is a VI function used to terminate the communications between the Diagnostician and your LabView application. The Diagnostician process should be terminated by your LabView application once the fault call-out has been made. CLOSE_DOC will issue a terminate command.

The basic process flow for the Diagnostician under LabVIEW is to start the WINADR process, which initializes the communications. This returns the reference number to be used for all subsequent calls to the Diagnostician during the opened conversation. At this time, either a request for NEXTSTEP using ASK_DOC or a report of known test results using TELL_DOC can be performed. If ASK_DOC returns a test, then that test is executed and the results are reported through TELL_DOC. ASK_DOC must request a NEXTSTEP after all test results are repored. If ASK_DOC returns a callout or repair procedure, then ASK_DOC must request the AMBIGUITY to complete the diagnostic process. Once the ambiguity list is completely reported and the keyword DONE is returned then the CLOSE_DOC command can be issued. This ends the current testing and diagnostic session.

A typical conversational flow of a diagnostic session execution involving the Diagnostician and LabView is as follows:

1.) The LabView application will initiate the Diagnostician and send the Knowledge-Base filename to the Diagnostician. This will start the Diagnostician process.

The LabView application can then either send test results to the Diagnostician or request NEXTSTEP. If the LabView application is going to send test results, steps 2 through 4 apply. If the LabView application is going to request next step calculation, then steps 5 through 7 apply.

2.) The LabView application will send the test name [Testname]. This line tells the Diagnostician what test results are to follow. The Diagnostician will wait for any results associated with the test name.

3.) The LabView application will send all test results associated with the test name using individual test_locations, <ALL>, and/or <REMAINING>. After the results are entered for this test, the LabView application can either request a calculation for the next step (NEXTSTEP) or it could enter another test name. If more test results are to be entered, the LabView application should go back to step 2.

4.) The LabView application will pass the Done message. This message signifies that the LabView application has completed sending test data.

5.) The LabView application will request the next step by issuing the keyword NEXTSTEP. The result of the NEXTSTEP request may be a name of a test executable or a repair procedure, depending upon the current level of diagnostics.

6.) If the LabView application receives a test name, then the LabView application is expected to execute the test. The LabView application will execute the test and report the results back as in step 2.

7.) If the LabView application receives a repair procedure then the LabView application is expected to cause the procedure to be performed.

8.) Finally, the LabView application will close, or Terminate, the Diagnostician.

The LabView application is the client and the Diagnostician is the server. The LabView application has control over the execution of all test and display-related procedures. The LabView application manages all intercommunications and the passing of information. If the Diagnostician asks for a test and the LabView application executes other tests to get to that test, then the LabView application may or may not report the extra tests. The Diagnostician will report back requested tests or procedures. The LabView application must determine what that request means and how to enact it (usually based upon the items established by the user in the Diagnostician Knowledge Base while using the Diagnostic Profiler).