Generate Run-Time Diagnostic Knowledge Base

GENERATE RUN-TIME DIAGNOSTIC KNOWLEDGE BASE

Introduction

This section describes how to generate a run-time diagnostic knowledge base. The Generate Run-Time tab provides the tools necessary to prepare the design candidate for use in a run-time test environment with the Diagnostician. You can use the Specify Runtime Configuration Parameters tool to set up any optional operating modes of the Diagnostician. The tool will generate the internal file necessary to configure the Diagnostician to those modes. The tool Generate Run-Time Diagnostic Knowledge Base will convert the candidate currently loaded into a run-time diagnostics knowledge base, binary file, for use with the run-time Diagnostician.

Later sections provide highlights on how to integrate the Diagnostician automated diagnostics software package in a test environment. The Diagnostician acts as a server task which performs functions that provide diagnostic services to any client program. When properly interfaced on the client side, the Diagnostician functions as a library of subroutines within the client program.

Specify Runtime Configuration Parameters

The Diagnostician can be configured to operate in optional modes. This provides for a great amount of flexibility and tailorability of run-time operations. For most test environments the default operating modes are sufficient. The Diagnostician's optional operating modes are set via either 1) a configuration file, 2) the adrSetConfig function or 3) through default values. When a model is loaded, the Diagnostician software looks for a configuration file in the same directory as the model's dkb file. If it finds a configuration file, it reads the contents of that file and sets its configuration according to the parameters defined in the file. If the file does not contain a setting for a specific configuration item, then the default is used. The configuration file is named with the model base file name as the prefix with the extension .cfg. If no configuration file is found, then default settings are used. After the dkb is loaded, any/all of the configuration settings can be changed via the adrSetConfig function.

The configuration file is an ASCII file residing in the project directory. The configuration file is only required if other than default values are desired for run-time. The name of the configuration file must match the name of the knowledge base (which has the extension .DKB) and must have the extension .CFG (example, RF_CIRC.CFG). The configuration file is case sensitive and must be in all upper case.

The Specify Runtime Configuration Parameters tool generates and modifies the configuration file.

The file can also be modified by a standard ASCII editor. The following shows the contents of the standard configuration file.

CLUSTERINFERENCES=Yes
DEBUGERRORS=No
DEBUGLEVEL=0
DEBUGLOGFILE=adrdll.log
EVIDENCEWEIGHT=20
FLATMODELMODE=Yes
GENERATEMODELRPR=No
IGNORECASE=Yes
INPUTFAULTS=Yes
MAXOUTPUTCHARACTERS=64
OUTPUTBLANKFILL=No
PARTISOLATIONMODE=Yes
PASSVALUESTOCHILD=No
SETREMAININGTPS=Yes
SHOWPOSSIBLEPARTS=No

There are three methods of setting Diagnostician configuration parameters: through the operating system environment, through a configuration file having the same base name as the currently loaded model and an extension of 'CFG' (e.g. MODELNAME.CFG), and through arguments to adrSetConfig(). In each case, the data provided has the same format:

<parameter-name>=<parameter-value>

The items that can be set in the configuration settings of the Diagnostician, their default values and their meaning are presented in the table below.

Parameter Name Parameter Values Description

CLUSTERINFERENCES Y or N Y is default. Y means that inferences of a higher level model are passed as input to a child model

DEBUGERRORS Y or N N is default. Y means, attempt to recover from a model load error enough to provide debug error info

DEBUGLEVEL 0 thru 63 0 is default. Identifies which debug messages are logged. Bits interpreted as follows:
x'01' - routines x'30' detail
x'02' - test data levels
x'04' - model data
x'08' - reasoning

DEBUGLOGFILE <file-name> Default is 'adrdll.log'. Identifies a file into which debug data is logged.

EVIDENCEWEIGHT <positive-integer> 20 is default. Identifies the equivalent failure probability to accord each piece of evidence when ordering the repair parts in an ambiguity group

FLATMODELMODE Y or N N is default. Y causes child models to look like repairable items.

GENERATEMODELRPR Y or N N is default. Y causes a file whose base name is the model and whose extension is 'RPR' to be generates. The file contains the suspect repair parts and associated data to be generated.

INPUTFAULTS Y or N N is default. Y causes faults at repair part inputs to be considered in inferences.

MAXOUTPUTCHARACTERS <positive-integer> 64 is default. The maximum number of characters that will be placed in output arguments. Unless OUTPUTBLANKFILL=Y, this should be one less than the calling program makes available

OUTPUTBLANKFILL Y or N N is default. N means that output strings are terminated by a hex 00. Y means that the output is extended by spaces to completely fill to the MAXOUTPUTCHARACTERS of the buffer provided. Y is required for Visual Basic.

PASSVALUESTOCHILD Y or N N is default. Y causes all test input to be written to a file and reread by each lower level model in the hierarchy before any inferences are made.

SETREMAININGTPS Y or N N is default. Y causes all test points of the current test to be set whenever it is superseded by a different current test. Those test points of a test that have not been specified in the data are set to UNKNOWN. The result is that adrGetNextStep will not try to get that test again.

To use the Specify Run-time Configuration Parameters tool to generate or modify a configuration file

1. Load the project and diagnostic candidate that you want to generate the configuration file for.

2. Press the Generate Runtime tab from the main Diagnostic Profiler Screen.

3. Highlight the tool titled Specify Runtime Configuration Parameters. Double-click in the tool title, or Press Use tool.

4. The Specify Runtime Configuration Parameters screen will appear, as shown below.

5. Press Done to generate a configuration file with default values, or modify the default values as desired, and press Done.

6. At any time, you can press the Restore Default Values pushbutton to return each parameter to its default value.

Create the Run-Time Diagnostic Knowledge Base

The candidates generated by you in the development of a diagnostic design reflect various test strategies that can be implemented. Once a candidate has been selected for implementation, this candidate must be converted into a run-time diagnostic knowledge base.

In creating a run-time knowledge base, the attributes related to a specific candidate are converted into a Diagnostic Knowledge Base (DKB). The DKB is a binary file used in the run-time environment.

To create a run-time diagnostic knowledge base

1. Load the project and diagnostic candidate that you want to generate the knowledge base for.

2. Press the Generate Runtime tab from the main Diagnostic Profiler Screen.

3. Highlight the tool titled Generate Runtime Diagnostics Knowledge Base. Double-click in the tool title, or Press Use tool.

4. A pop-up window will pop up showing you the percentage of processing completion. This is shown below.

5. In the lower left corner of the screen, a minimized window will contain detailed processing messages. This screen can be enlarged, as shown below, to view the processing messages, if desired.

Once the knowledge base generation has begun, a number of calculations and processes are performed. Generation of a knowledge base may take a few moments to few minutes to complete, depending on the size of the model.

The file resulting from generating a run-time Diagnostic Knowledge Base file will have the extension "DKB" (e.g., JAST.dkb) and will reside in the candidate's project directory (e.g., \Profiler\Projects\JAST\Working Candidate\JAST.dkb).

Diagnostician Overview and Run-Time Configuration

Each Diagnostician application consists of 1) the inference engine, 2) a diagnostic knowledge base, and, optionally, 3) a run-time configuration file. The inference engine functions are contained in the library file adrdll.dll. The diagnostic knowledge base is a diagnostic model of a specific system or UUT generated by the Diagnostic Profiler from UUT CAD data and from user provided diagnostic strategy specifications and interface descriptions, such as executable test routine names.

The Diagnostician reasons about the exact cause, or location, of a fault based upon interpreting the results of tests. It relates Pass/Fail data to the hierarchy, interconnectivity, and signal flow of the unit under test. The Diagnostic Profiler assists the developer in defining what tests must be written to achieve a high level of diagnostics.

External programs can use Diagnostician functions as a means of executing the various services of the Diagnostician. You can use any of the Diagnostician functions by calling them from within your program.

Diagnostician Functions by Category

The following pages contain a listing of the Diagnostician function calls available within the Diagnostician server program. These functions are broken into the categories for 1) overall control, 2) entry of test result data to the Diagnostician, 3) diagnostic reasoning functions, 4) hierarchical services, 5) miscellaneous services, and 6) DKB information services. Each function call is defined. Further detail on each function call, including syntax, return values, descriptions and sample programs are provided in the Diagnostician Programmer's Reference Guide.

Note: Each of the subroutines that does not return a count returns an integer function value of zero if successful and non-zero if an error occurred.

Overall Control Functions

The overall control routines let you load a diagnostic knowledge base, set configuration values, start a diagnostic session and unload the diagnostic knowledge base. These routines represent requirements for the basic handling of the diagnostic knowledge base during a diagnostic session.

adrLoadDKB - Diagnostician^TM call which identifies which working directory and knowledge base to use in subsequent reasoning

adrUnload - Diagnostician^TM call which frees all memory utilized for the model, the data and the reasoning functions

adrSetConfig - Diagnostician^TM call to set a specific configuration flag or value

adrStart - Diagnostician^TM call to terminate the existing diagnosis and start another one.

The adrSetConfig routine sets certain optional operating modes of the Diagnostician.

Data Entry Functions

Test result data is the primary input to the Diagnostician. The data entry routines allow you to input test results to the Diagnostician. Primarily, the adrAddData routine will most often be used to input test result data on a single test location. You can also have the Diagnostician read a data file containing test results for one or many test locations.

adrAddData - Diagnostician^TM call to provide a single Pass/Fail value for a specific test point

adrAddDataFile - Diagnostician^TM call to identify a file from which data is to be read

adrEndData - Diagnostician^TM call to indicate that no more data will be provided and final results should be computed across all hierarchical models

adrExcludeRepair - Diagnostician^TM call to identify repair parts that are known to be good

Diagnostic Reasoning Functions

The diagnostic reasoning functions contain the core reasoning algorithms for deriving diagnostic information based upon test results. These core diagnostic services are provided through calls that request either information about the current fault call-out (or ambiguity group) or a call for the next test procedure to be performed to reduce the current ambiguity group.

adrGetNextStepTst - Request that the Diagnostician^TM evaluate the data given and return the name of the best next test to be implemented

adrGetNextStepOpt - Request that the Diagnostician^TM evaluate the data given and return the procedure option assigned to the best next test to be implemented

adrGetSuspectCnt - Request that the Diagnostician^TM evaluate the data given if necessary and return the number of suspects for repair in the ambiguity group

adrGetSuspect - Request that the Diagnostician^TM evaluate the data given if necessary and provide the repair name for suspect 'index' in the ambiguity group

adrGenSuspectFile - Request that the Diagnostician^TM evaluate the data given if necessary and write the list of suspect repair part repairs to the file specified

adrGetSuspectFaultCnt - Request that the Diagnostician^TM evaluate the data given if necessary and return the number of fault locations in the ambiguity group

adrGetSuspectFault - Request that the Diagnostician evaluate the data given if necessary and provide the fault location for fault 'index' in the ambiguity group

Hierarchical Services

The hierarchical services functions provide the means for a user to obtain information about the current diagnostic session when a hierarchical series of diagnostic knowledge bases is being used.

adrGetCurrentModel - Requests the name of the model currently loaded

adrGetParentModel - Requests the name of the model which loaded the current model if any

adrGetChildModelCnt - Returns the number of child models that can be loaded by the current model during diagnosis

adrGetChildModel - Requests the name of child model number 'index'

Miscellaneous Services

The miscellaneous services function calls provide a variety of services related to the current diagnostic session.

adrGenStatusFiles - Requests that the current reasoning status be written to files in the specified directory

adrGetConfig - Requests the value associated with a configuration name

adrGetCodeVersion - Requests text identifying the version of the Diagnostician^TM

DKB Information Services

The DKB information services functions allow the user to obtain data contained within the currently loaded binary diagnostic knowledge base.

adrGetTestEnvData - Requests Identification of the name assigned to the test result data file associated with a test routine name

adrGetTestEnvSetup - Requests identification of the name assigned to the test setup routine associated with a test routine name

adrGetTestEnvTest - Requests identification of the name assigned to the test procedure option associated with a test routine name

adrGetTestEnvCleanup - Requests identification of the name assigned to the test cleanup routine associated with a test routine name

adrGetSystemTestName - Requests identification of the name assigned to the system test system test is normally the first test to be executed, such as a go/no-go test routine)

adrGetTestCnt - Returns the number of tests in the model

adrGetTestName - Requests the name for test number 'index'

adrGetTestPntCnt - Returns the number of test points in the model

adrGetTestPntName - Requests the name of test point number 'index'

adrGetPartCnt - Returns the number of repair parts in the model

adrGetPartName - Requests the name for repair part number 'index'

adrGetPartNameOpt - Requests the repair option tag for repair part number 'index'

adrGetFaultCnt - Returns the number of faults in the model

adrGetFaultName - Requests the name for fault number 'index'

adrGetFaultSetName - Future Use Only

Use of Diagnostician Functions

A typical sequence of operations might follow the procedure outlined below, however, you may operate the Diagnostician functions in any sequence you desire.

Load a Knowledge Base

To initiate the Diagnostician functions, use the command adrLoadDKB to enter the name of a diagnostic knowledge base.

<dkbname>.dkb

where <dkbname> is the name of the knowledge base generated, usually the same as the model name. Inclusion of the extension .dkb is optional.

Once you load the DKB into memory, all of the function commands become available.

A status message will also be returned as a response to each command. The status will identify error codes associated with the last entered command. Normally, this line should read 0. If it does not read 0, then an error has occurred in the last Diagnostician function call.

Configuration Information

The adrOperatingMode command can be used to set an operating mode of the Diagnostician. If a configuration file exists in the same directory as the knowledge base, and that configuration file has the same base name as the DKB file, then any valid configuration settings from that configuration file will be in effect. If there is no configuration file, then default settings will be used, unless the default settings have been changed by the user since loading the current diagnostic knowledge base. To change a configuration setting, use the adrSetConfig command with the argument that is the configuration item and the desired setting. The new settings will be in effect after issuing the command. To verify that the changes have been effected, check the response on the status line returned from the command, which should read 0. This changed mode will remain in effect until the next time you load a knowledge base, at which point the settings in the configuration file will take effect, or, in the absence of a configuration file, the default settings will take effect. (Note: adrStart does not re-set configuration settings. )

Get Next Test

This function (adrGetNextStepTst) will cause the Diagnostician to identify and return the name of the next test to perform. Initially, this function will return the name of the System Test, if one had been identified during Profiling. The function adrGetNextStepOpt will return the Procedure Option associated with this test name. The procedure option may be an entry point into a test program, a stand-alone executable program or routine, or any other designation which was entered into the DKB using the Diagnostic Profiler Field "Procedure Option."

Enter Test Results

Test results may be input in several ways: either through a test results output file (to be generated by the test program) using adrAddDataFile or one at a time using adrAddData.

Test Result File

If a Test Result file name was assigned during Diagnostic Profiling, then this name can be used to input all of the results associated with a test routine using the adrAddDataFile command. If the test program is designed to output test results into a data file, this can be a very efficient way to handle test results transfer. The command adrAddDataFile with the argument of the file name will cause the Diagnostician to open the data file and read the test results. To get the name of the data file associated with the test, the command adrGetTestEnvData can be entered with the argument of the test name.

Test result data files must comply with specific format requirements.

When the Diagnostician opens a test result data file, it will read all test data contained within that file. Therefore, if you have multiple tests output test results to the same file name in an append mode (as opposed to an overwrite mode), the Diagnostician will read and process all of those test results, not just the results associated with the last test identified with the adrGetNextStepTst command. Therefore, you can use test result files as a means of grouping tests. For example, you could execute a whole series of end-to-end test routines and append the result of all of these to the same data file name. This will speed overall operations. There are many other ways of grouping tests, and forcing the order of tests.

Add Test Results Data

Test results may be input to the Diagnostician one at a time by issuing the adrAddData command for each test result to be entered. Test results must comply with specific format requirements.

A word of caution - if you are exercising the Diagnostician functions via simulating test results, and are using test results which do not correspond with an actual fault, and which could not actually occur given the circuit topology, the Diagnostician will enter into a Data Conflict Mode. Using test results which would be produced from an actual failure, as are generated by Giordano Automation's Fault Propagation Simulator (FPSIM), will produce meaningful, consistent results. Also, if you enter a result from a test point associated with a test routine, and then enter the result of a test point associated with another test routine, and there was more than one test point associated with the first test routine, the Diagnostician will assume that all other test points associated with the first routine are "Unknown" and will not request or use results associated with the other test points in generating a diagnosis.

Generate Ambiguity Group List

At any point in the diagnostic session, you may issue the adrGetSuspectCnt command to obtain an up-to-date number of items in the ambiguity group. adrGetSuspectCnt returns a number which can then be used as an index with the adrGetSuspect command to obtain a list of the items in the current ambiguity group.

The items returned by adrGetSuspectCnt and adrGetSuspect relate to repair parts, which are items which have the same repair procedure designation in the diagnostic knowledge base. Remember that by default, the repair parts are component names, except where these names have been changed or grouped in the Diagnostic Profiler. To obtain a list of fault locations (component and pin) in the ambiguity group instead of repair parts, use adrGetSuspectFaultCnt and adrGetSuspectFault.

Exclude Repair Part

Up until the final diagnosis is reached, you can exclude any repair parts from being considered (suspected) as faulty. To do this, use the adrExcludeRepair command with the argument that is the name of the repair part. Again, repair parts are usually the component name, except where these names have been changed or grouped in the Diagnostic Profiler. You may only exclude one repair part at a time (to exclude more than one, you must issue multiple adrExcludeRepair commands).

End Test Results

The adrEndData command may be used to indicate to the Diagnostician that no more test results will be provided, and that final diagnosis can be made. This button is useful when many tests have been defined in the Profiler, but you wish to use only a subset of those tests.

Generate Suspect File

The adrGenSuspectFile function writes the current suspect list (ambiguity group) to an ASCII file. The name of the ASCII file is defined by an argument passed with the command. The data in the Suspect File is most useful at the end of the diagnostic session, when the final call-out has been achieved. The suspect file is overwritten with each diagnostic session, not appended to, so if it is desired that this data be saved, an additional routine should be written by the applications developer to append the contents of the suspect file into a central file after each diagnostic session.

Unload DKB and Clear Memory

To unload the current Diagnostic Knowledge Base and clear memory, issue the adrUnload command. However, if you just want to start a new session with the same DKB, use the adrStart command which will clear all test results associated with the current diagnostic session and start a new diagnostic session. If you are planning to use the adrStart within a series of diagnostic sessions, and you are using test result data files, you should consider removing all existing test result files from the working directory before starting the new diagnostic session in order to avoid the Diagnostician reading test results associated with a previous diagnostic session.

Generate Status Files

The adrGenStatusFiles command will cause the Diagnostician to generate a series of files which provide information related to the diagnostic session. These status files were primary used for software debug and may or may not be useful to you. You must identify, as an argument to the command, the directory where the files are to be written to. Enter the path and directory name (e.g., \Profiler\Projects\jast). If you do not identify a directory, the files will be placed in the directory from where you initiated the Diagnostician. A period (.) indicates the current working directory. The files will get generated when you issue the adrGenStatusFiles command. This provides a snapshot of the diagnostic session, including the reasoning, at that moment in time. Generating the status files causes deletion of the previous "snapshot" therefore, to get a representation of the final results, issue this command after the diagnostic session has been completed. Note that these files are overwritten each time the adrGenStatusFiles command is issued. If you want to maintain a log of these files, you might want to write a script that appends these files into another file or files.

The following identifies the files and the content of the files:

FHYPOTHS.DBG This file contains the fault hypothesis - a listing of suspect fault locations.

FSTATUS.DBG This file contains the reasoning evidence used by the Diagnostician in indicting fault locations. This file is used by the software developers as a debug mechanism and is not generally used by the user. The information contained in this file is as follows. At the top of the file is the reasoning status of the Diagnostician. This may be Exact Match, Single Fault, Multiple Fault, or Data Conflict depending on the current mode. The middle column is a listing of all of the potential fault locations in the circuit. The information in the columns to the left and right of the fault locations listing is related to the fault locations. To the left of the fault locations, a number is presented. The number indicates that for that fault location, the number of test results (at test locations), which have been input, that have failed that were expected to fail if this fault location had a fault in it. To the right is either a n for no or a Y for Yes. No indicates that no mismatches have occurred - no pass where a fail was expected for that fault location to be indicted as faulty. Yes indicates that a mismatch has occurred - if a fault was true at this location, then it was contradicted by the evidence. To the right of the n/Y column there might be a 'p0' or 'in'. p0 indicates that the failure probability of this fault location was set to zero (during Diagnostic Profiling) and that this fault location should therefore be excluded from consideration as faulty. 'in' indicates that this fault location is a component input, which by default is also excluded from consideration as faulty. However, a configuration value can be set to tell the Diagnostician to consider inputs as potentially faulty. This configuration flag is INPUTFAULTS, which by default is set to N (No). Setting this to Y (yes) causes component inputs to be considered as potentially faulty. When dealing with hierarchical models, this must be set to Yes to facilitate the passing of test result data between levels.

PHYPOTHS.DBG This file contains the part hypothesis - a listing of the repair parts in the suspect list. The repair option is listed, therefore, where parts have been grouped by repair procedures, the grouping is listed.

PREPAIRS.DBG This file contains a list of the repair procedures associated with the current ambiguity group. The file is ordered by an evidence weighing factor which includes failure rate and the amount of evidence supporting the indictment of the suspect parts. (See Evidence Weight in the configuration settings Table.)

REFUSED.DBG This file contains a listing of test points that have been refused or unknown during the current diagnostic session. REFUSED.DBG will contain a listing of the test points for which test results were asked for by the Diagnostician (via Get Next Test), but not input. These test locations are set to "REFUSED" and are not considered in the diagnostic analysis, nor will they be requested again. Also, if a test routine has a number of test points associated with it, and you enter test result data for one but not all of the test points, the test points that you did not enter will be set to REFUSED. However, this can be changed through the configuration flag SETREMAININGTPS=Y will cause remaining test points to be set to Refused. SETREMAININGTPS=N will cause remaining test points to not be set to Refused. The default for this configuration setting is N. REFUSED.DBG often has no entry, because in using the combination of FPSIM, which generates and comprehensive set of test results, seldom are tests refused in the "Exercising" operations.

TSELECTS.DBG This file contains a listing of the last test that was recommended to be performed.

TVALUES.DBG This file contains a list of the test result values that have been input to the Diagnostician during the current diagnostic session.

MODE.ADR This file contains the current reasoning mode employed by the Diagnostician. This might be: Exact Match, Multiple Fault, Data Conflict, Single Fault.

Format of Test Results Data

The test program application must pass the results of tests to the Diagnostician. This is accomplished using the adrAddData or adrAddDataFile command. 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 in this section.

The adrAddData or adrAddDataFile commands must pass test results data in the exact format specified below. Test results are provided to the Diagnostician as an argument to adrAddData().

An alternative to sending test results to the Diagnostician dynamically with a single adrAddData per test result is to send the Diagnostician a group of test results via a test result file. The test result file is a simple ASCII file which contains one line of test results for each measured location. The test result file may contain results for one test routine or for many test routines.

Test results are provided via a data file identified using the Diagnostician function adrAddDataFile(). In this approach, each line of data in the file provides data for the equivalent of one call to adrAddData() and may provide a pass, fail or unknown value for one test point, all the test points in a test, or all the remaining test points in a test. adrAddDataFile has, as an argument, the name of the data file to be read.

The format of a adrAddData() argument or a line in the adrAddDataFile() file is as follows: (with quotes around literals, pipes to separate alternatives, and brackets to denote optionality)

[<test-identification>]<testpoint-identification>=<value>;

where

<test-identification> = "[" [<model-name> "."] <test-name> "]"

and

<testpoint-identification> = <testpoint-name> | "<A>" | "<R>"

and

<value> = "P" | "F" | "U"

with the following meanings:

<A> =All testpoints in the current test
<R> = All the remaining testpoints in the current test (that are not set)

P = Passed

F = Failed

U = Unknown

The value <test-identification> originates from the names assigned to test routines in the Diagnostic Profiler and is case sensitive. This test routine name must appear in square brackets.

The value <testpoint-name> originates from the Edif netlist and used in the Diagnostic Profiler to denote a physical location in the design where a measurement, or test, is being made.

For example, let us assume there are three test procedures, POWER, FREQ, and GAIN. POWER measures test location U14, pin 3 (U14.3), U18, pin 5 (U18.5) and U23 pin 9 (U23.9). The following are valid test result inputs.

[POWER]U14.3=P;
U14.3 passes power test
[POWER]U18.5=F;
U18.5 fails power test
[POWER]U23.9=U;
U23.9 power test unavailable

The following combination of test results:

[POWER]U18.5=F;
[POWER]<R>=P;

means that of the three measurements, U18.5 fails the test, and the remaining measured locations pass the test.

[POWER]<A>=F;

means that all measured locations associated with the test POWER have failed.

NOTE: While test data is being input to the Diagnostician, no calculations will be performed, i.e., no analysis of test results is performed until one of Diagnostic Reasoning functions is requested by your application.

Each line within the test results file represents either a test name or a test result. Test result lines must end with a colon (;). The following is a valid test result file:

[POWER]
U18.5=P;
U12.2=F;
U11.3=R;
<R>=P;
[FREQ]
<A>=P;
[GAIN]
U22.4=P;
U17.4=F;
U16.2=F;
U11.6=P;

TEST RESULT DATA INPUTS / FORMAT

[Testname] This message identifies the name of the test for which test results will subsequently be passed to the Diagnostician from the test program application. If test results are being passed for a test which the Diagnostician has just identified via the adrGetNextStepTst, then this identification message is not necessary. However, if the test results to be passed are associated with a test which was not just identified 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/U; 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 U=Unknown. The Test_Location designation must exactly match the name of the test location as it appears in the Diagnostic Profiler, and is case sensitive. The message terminates with a colon (;). An unknown 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. Once a test is unknown, it will not be asked for again, and reasoning will be performed without that test result data.

<A>=P/F/U; A in this message indicates ALL which can be used to signify that all of the measured tests locations associated with the identified test name have either Passed, Failed or are Unknown. The angle brackets (<...>) are required, and the keyword A must be sent in capital letters.

<R>=P/F/U; R in this message indicates REMAINING which can be used to signify that the remaining test locations associated with the identified test have either Passed, Failed or are Unknown. This can be useful for tests which have many measured 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 sent, and the message <R>=P; can be used to simplify the message string. The angle brackets (<...>) are required, and the keyword R must be sent in capital letters.

Parameter Name	Parameter Values	Description
CLUSTERINFERENCES	Y or N	Y is default. Y means that inferences of a higher level model are passed as input to a child model
DEBUGERRORS	Y or N	N is default. Y means, attempt to recover from a model load error enough to provide debug error info
DEBUGLEVEL	0 thru 63	0 is default. Identifies which debug messages are logged. Bits interpreted as follows: x'01' - routines x'30' detail x'02' - test data levels x'04' - model data x'08' - reasoning
DEBUGLOGFILE	<file-name>	Default is 'adrdll.log'. Identifies a file into which debug data is logged.
EVIDENCEWEIGHT	<positive-integer>	20 is default. Identifies the equivalent failure probability to accord each piece of evidence when ordering the repair parts in an ambiguity group
FLATMODELMODE	Y or N	N is default. Y causes child models to look like repairable items.
GENERATEMODELRPR	Y or N	N is default. Y causes a file whose base name is the model and whose extension is 'RPR' to be generates. The file contains the suspect repair parts and associated data to be generated.
INPUTFAULTS	Y or N	N is default. Y causes faults at repair part inputs to be considered in inferences.
MAXOUTPUTCHARACTERS	<positive-integer>	64 is default. The maximum number of characters that will be placed in output arguments. Unless OUTPUTBLANKFILL=Y, this should be one less than the calling program makes available
OUTPUTBLANKFILL	Y or N	N is default. N means that output strings are terminated by a hex 00. Y means that the output is extended by spaces to completely fill to the MAXOUTPUTCHARACTERS of the buffer provided. Y is required for Visual Basic.
PASSVALUESTOCHILD	Y or N	N is default. Y causes all test input to be written to a file and reread by each lower level model in the hierarchy before any inferences are made.
SETREMAININGTPS	Y or N	N is default. Y causes all test points of the current test to be set whenever it is superseded by a different current test. Those test points of a test that have not been specified in the data are set to UNKNOWN. The result is that adrGetNextStep will not try to get that test again.