In order to use the knowledge base in run-time, it may be necessary to supply specific information which will link the knowledge base to sources of test data and link to the operator through a display system, to provide information.
The Diagnostician is available as a Dynamic Link Library (DLL) that provides various diagnostics-related functions as a "server" in a client-server environment. In this case, run-time linkages will be managed within the operations of the client program. However, you can set up the client-server to have the Diagnostician provide relevant information in many areas. The information which can be entered into the Diagnostic Profiler in order to effect run-time linkages include:
Test Setup Procedure
Test Procedure
Test Clean-up
Procedure
Test Cost
Test Type
Test Data File Name
To Define
Run-Time Linkages for a Test
A pop-up window will appear with tabs functions supporting New Test
definition, Copy, Edit, Delete. The New Test tab will be active.
2. Enter the name of the new test, and enter any linkage information
available.
3. Press Save, then press Done.
To define or edit run-time linkages for an existing test
2. To select a test to edit, click on the pull-down arrow associated with the field "Select a Test to Edit." A pull-down box will present the names of each test. Click on the test name you wish to access.
The current linkage information for the selected test will be displayed.
Edit the test information as desired.
3. Press Save, then press Done.
Test
Set-Up Procedure/Test Cleanup Procedure
The Setup and Cleanup Procedures fields provide for a capability to
integrate with an on-line information system such as an interactive electronic
technical manual. The variable entered in this field can be passed to the
client program. The variable may be an SGML frame tag, an internal call
to a procedure within an IETM, or any other routine which displays text
and graphics.
When a test is run, specific on-line documentation or messages are often
required before and after the test. Messages that occur before a test is
run are called Setup Procedures. These are required if a test requires
a unique set-up, warning or set of tools/equipment to perform the test.
Messages that are required after a test is completed are called Cleanup
Procedures. These are required if a test procedure required a unique set-up
which must subsequently be "torn-down."
A Setup Procedure is most often needed when the test requires access
to a measurement or stimulus point that is not automatically accessible.
A Cleanup Procedure is typically required when a Setup Procedure has been
performed. Setup/Cleanup Procedures are likely to occur when performing
system/subsystem testing; less likely to occur during automatic off-line
or embedded testing.
One example of the need for Setup/Cleanup Procedures is as follows: A test requires access to a bus connector on an aircraft. To gain access to this connector, a cable must be disconnected and a test cable inserted. The Setup Procedure will provide the maintenance person with the steps to remove the cable and place the test cable on the connector. The Cleanup Procedure will reverse these steps.
At Run-time, setup and cleanup definitions furnish calls to external procedures. Also, for a given set of tests whose Setup Procedures are the same, when any single one of those tests is required, all those with identical Setup Procedures will also be run. This prevents the same Setup/Cleanup routines from being performed multiple times. This feature can be overridden by using the Test Cost.
Names for the
Test Setup and Cleanup fields must be coordinated with the publications
specialist writing the on-line procedures and must follow the conventions
of the operating system or presentation management system.
Test Procedure
The Test Procedure field provides the means to integrate the knowledge base with the actual test routines. Each test routine may have its own executable test, subroutine or test module. In general, tests with identical stimulus routines should be grouped with the same executable defined.
The Diagnostic Profiler provides a data field for a variable that relates to the execution of test modules. When integrated with the Diagnostician, each time a test routine is called for execution, this variable, defining the test procedure option, will be passed to the client program. The test procedure option is simply a call to run a test module with the defined name.
The input to the Test Procedure field will vary depending upon the conventions
used by the source of the test results. In run-time operation, it is simply
a call to the client program, test program, other operating environment
to execute a specific program or subroutine. If the test is part of an
ATLAS test program, then the variable may define a module within the test
program which executes a test or a group of tests.
Names
for the Test Procedure must be coordinated with the test engineer writing
the test routine and must follow the conventions of the operating system
or test executive.
Test Data File Name
The Test Data File Name field identifies the name of the file where
test results will be stored. The test results will denote whether the test
at each measurement location has passed or failed. In this pass/fail form,
the information can be interpreted by the Diagnostician run-time system
to perform fault isolation. Specific format and conventions are required
for the Test Data File Syntax. In many run-time environments, the
Test Data File Name is unnecessary because the test results will be passed
dynamically between the client and the server programs. If a means of program-to-program
intercommunications is being used (e.g., Windows DDE, OLE, Unix sockets,
etc.), then file input/output will not be required for the run-time Diagnostician
to access test results. If a DOS based operating environment is being used,
then file input/output must be employed, in which case test results must
be output to a specific file. The name of that file is defined in the Test
Data File Name field. An example of a Test Data File Name field is "results.out."
When defining a new test, the Diagnostic Profiler automatically assigns
a data file name which is the test name with the extension .out. This can
be modified.
Note: If you are planning to exercise the knowledge base in simulation mode, you must have a Test Data File Name for each test. This is because the program that simulates a fault event outputs simulated test results to the data file(s) such that the Diagnostician can access and perform its reasoning based upon the simulated test results.
To Enter a Filename in the Test Data File Name Field
Names for
the Data File field must be coordinated with the test engineer writing
the test routine. The test routine must generate the test results file
with the appropriate pass/fail information. This file must conform to the
conventions of the operating system and is in ASCII format.
Test Data File Syntax
The syntax required by the DiagnosticianTM software is as
follows:
[Diag_T1]
JAST.TP5=P;
JAST.TP4=P;
JAST.TP3=P;
JAST.TP2=F;
Where the Test Name in square brackets is followed by a list of the measurement locations associated with the test routine. Each measurement location name is followed by an equal sign (=) and then a P to denote that the test location Passed, or an F to denote that the test Failed, or an R to indicate that the test at that location was Refused (e.g., the test information is not available). A semi-colon (;) must end each line of test result data.
Test Cost is a value which is used by the DiagnosticianTM
run-time software to weigh the execution of a specific test, based upon
the diagnostic value which that test result will provide in isolating a
fault versus the cost or penalty associated with running the test.
Test Cost is a relative measure of the characteristics that influence
a test's run-time performance, including (1) time to fully perform the
test, (2) resources needed to run the test, and (3) the relative difficulty
of running test. You can assign a relative cost value to each test reflecting
the total impact of these items. The Profiler allows you to assign a cost
value between 1 and 99. If numbers outside of this range are applicable,
normalization will be required.
Test cost influences test run-time operation. All else being equal,
the less costly a test, the more likely to be run. Since all else is rarely
equal, test costs at the extreme of the range have the most impact. Tests
with costs set to 1 will typically all be run first. Tests with costs at
or near 99 will typically not be run unless all other pertinent tests have
been run. For example, a test may require access to a part buried deep
into the design, forcing the entire system to be shut down and pulled apart.
This test would have a cost of 90 or greater. Alternately, a test may be
part of built-in tests that run are automatically would be assigned a cost
of under 10, such as 2, to denote to the run-time software that this specific
test result can be gathered with no cost. Values of 1 should be reserved
for symptoms which are observable by the operator or maintenance technician,
such as finding a charred power supply.
To Display Test Costs for the Current Test
A pop-up window will appear with tabbed Test functions.
2. Access the Edit Test functions by clicking on the Edit tab.
3. The Test Cost assignment is a numeric text box. The current value
is displayed numerically in the box.
To Change the Test Cost for a selected Test
2. Type the Test Cost number into the text box provided.
Note: From the Edit tab,
you can access and edit the Test Cost field for any Test. To access and
edit the Test Cost field for another test, click on the pull-down arrow
associated with the field "Select a Test to Edit." A pull-down box will
present the names of each test. Click on the test name you wish to access.