SGML Intermediate Format

In order to capture diagnostic logic from legacy data, the user must assign a unique name to each test procedure and a unique name to each repair procedure. The conditional branching (if pass go to X, if fail, go to Y) must be defined for each test procedure, using the names defined. This information must be entered into a the intermediate file format (ASCII text file) with the exact format described below. The intermediate format contains the most basic, common information found in troubleshooting procedures: definition of tests/measurements and repairs, and definition of the branching logic. The test/measurement data forms the basis of the columns of the fault/symptom matrix, and the repair data forms the basis of the rows of the matrix.

The following format has been established for test/measurement data:

<ITEM>     where     <ITEM> is a unique name designation provided for the entry
<TEST>     where     <TEST> is the name provided for this test/measurement item.
<IF>           where     <IF> represents conditions for branching
<GOTO>    where     <GOTO> represents the branching result of the previous condition being met (which <ITEM> to branch to, either another test procedure or a repair procedure).

NOTE: Each test is uniquely named but may appear in more than one item if appropriate.

The following format has been established for repair data:

<ITEM>      where     <ITEM> is a unique name designation provided for the entry
<REPAIR>  where     <REPAIR> is the name provided for this repair item.

NOTE: Each repair is uniquely named but may often does appear in more than one item.

Authoring Troubleshooting Data Directly into the Intermediate Format

An example is provided below of the content and formatting of the data in the intermediate format. The example consists of two test procedures and two repair procedures, and has been extracted from a larger, actual troubleshooting procedure.

EXAMPLE

<ITEM>T 40
<TEST>F_4
<IF>FAIL
<GOTO>T 51
<IF>PASS
<GOTO>T 41

<ITEM>T 41
<TEST>F_5
<IF>FAIL
<GOTO> R 1
<IF>PASS
<GOTO> R 5
 
<ITEM>R 1
<REPAIR>MAP_DISPLAY_UNIT

<ITEM>R 5
<REPAIR>CABLE_ASSEMBLY_W814
 
The example above represents the troubleshooting flow found in the figure. The <ITEM> designations were assigned as arbitrary numbers in sequence - T for Tests and R for Repairs. To prevent data entry errors, each test and repair procedure was assigned a number in sequence. If the test result for T40 is PASS, then the branching logic is to go to (<GOTO> ) that block that has been assigned the ITEM name T41. If the test result is FAIL, then the branching logic is to go to the Test that has been assigned the item name T51. If T41 fails, the branch is to an ITEM R1 that is a REPAIR procedure for the Map Display Unit, and if T41 passes, the branch is to an ITEM R5 which is a REPAIR procedure for the Cable Assembly W814.

Using this approach, each test path to each fault is represented in the branching logic to be captured in the "model" that will become the basis for the reasoning logic. Here, a one-for-one representation of the troubleshooting logic is captured, including exact test sequencing.

In this example, tests names have been assigned alphanumeric names that tie back to the paper-based procedures quite well, but are not at all descriptive. More descriptive names may be more desirable in actual applications. Either descriptive or non-descriptive names may be used, at the discretion of the author, however, it is recommended that a style be adopted and followed. NOTE: When descriptive names are not used in this file, descriptive names can be added after translation test and repair description fields.

To capture an entire troubleshooting procedure, assign a item designation and a name to each test and repair procedure. Then identify the branching associated with each procedure as shown in the example above. This information must be entered into an ASCII file with the extension .FLW using a text editor. Once this has been completed use the SGML Import tool in the Diagnostic Profiler to convert the file into a Diagnostic Profiler project. The procedure for using the SGML Import Tool is described below.

Use of the SGML Import Tool

To import a troubleshooting procedure from an SGML Intermediate file, create the file as described in the previous section.

To Import an SGML Intermediate File

2. Press Use Tool

or

Double Click on SGML Troubleshooting Data Import Tool in the tool list.

The SGML Troubleshooting Data Import dialogue box will appear.

3. Enter the full path and name of the SGML intermediate file in the text box labeled "Select SGML Troubleshooting File" or use the Browse function to locate the file.

4. Enter a project name in the Name text box under "New Project"

You should use a name descriptive of the project. Often the same name as the SGML file is used. The name is limited to 64 characters, and can include spaces.

5. Enter a location (path) to where you wish to place the project directory. By default, the project directory will be placed in a subdirectory created under the \profiler\projects directory.

You can type-in the directory location or use the standard windows directory box to traverse through your system's directory structure.

6. Press the Import pushbutton.

A pop-up window will display execution progress of the SGML Import tool. A minimized window will appear in the lower left corner of your display. This window provides more detail on the import process. You can maximize this window to view processing. When the last message in that window reads done, press the OK pushbutton.
 
The newly created project will be loaded into the Diagnostic Profiler, with a single default candidate which has a single test, called Sim_Candidate. This candidate has tests already defined representing the existing troubleshooting procedure's tests, repairs and test sequences.

NOTE: The SGML Import process generates a series of messages, warnings, cautions and errors. This information is output to an ASCII file named Import.LOG. If your import process ends up in an error, the log may provide more insight as to the cause of the error. It is recommended that you view the contents of this log. The Import.LOG file is located in the project directory (\profiler\projects\<projectname>\import.log).

Projects Resulting from Use of SGML Import

The SGML Import will result in a Diagnostic Profiler project directory for the project created. The resulting model will represent the tests, repairs and exact sequencing contained in the SGML file. The sequencing is represented as a series of constraints on the sequence of tests, and may be viewed or modified with the Test Sequence tool in the Specify Tests and Repairs tab of the Diagnostic Profiler.

Tests inherit the names contained in the <TEST> tag. Parts/Repairs come from the <REPAIR> tag. Faults for each of these Parts/Repairs is generated during the analysis process and are numbered sequentially. Each test path to each fault is treated as a separate failure mode of the part (repair item). Since the newly created project inherits all test, repair and sequencing information from the translation process, the model is complete. Normally, after import, the next step is to define tests and repairs. However, this is not necessary in import of the SGML data.

To add descriptive names to the test items, use the Test Information Tool in the Specify Tests and Repairs tab. To add descriptive names to repair items, use the Specify Repair Items tool. To add Failure Rate data to the repair items or modes, use the Specify Failure Rates tool. To perform Testability Analysis, use the Testability Analysis tool. To generate a run-time diagnostic knowledge base, use the Generate Run-time tool.

The model resulting from the translation process inherits all test sequencing represented in the original troubleshooting procedure as a series of constraints on test order. These constraints in test order are used in run-time to ensure accurate fault isolation. If engineering expertise is available on the subject system, these test ordering constraints can be lifted, or eliminated, as appropriate. Lifting test ordering constraints will serve to provide a more dynamic run-time fault isolation capability that can be optimized to the current failure.