1) Presentation of a Repair Procedure related to the specific component or group of components that the fault was isolated to.
2) Traversal to a lower level model, called a child model, for further fault isolation.
3) Execution of a control sequence, such as an automatic reconfiguration/recovery of the system/item.
The Repair Linkage fields in the Diagnostic Profiler have been established to provide flexibility in run-time in terms of interfacing with a variety of operating systems and application programs. The interfaces are defined in the Specify Repair Items tool as the Repair Name and Repair Action. Their use will vary depending on the nature of the application and the other external programs to be used in conjunction with the Diagnostician. Please refer to Diagnostician User Manual and Programming Guide for further information on run-time integration, or request our Run-Time Integration Application Note.
Using the Specify Repair Items tool, you can define and modify repair items and define run-time linkages for repair items. Repair item definition is important because both the Testability algorithms and the run-time Diagnostician perform analysis of fault isolation and ambiguity groups down to the "repairable item" level. By default, each part is a repair item. The specify repair items tool lets you change these default values. In some cases this is needed, such as when it makes sense to group parts into a common repair item.
Use the Specify Repair Items to:
- Group parts into a common repair item.
- Separate a part's fault locations into distinct repair items
- Define Repair Action for repair items
- Designate the Repair action as a Child Model for further diagnostics in a hierarchical model.
To access the Specify Repair Item tool, first access the Specify Tests and Repairs tab from the main Diagnostic Profiler screen. Select Specify Repair Items from the tool list. Double-click on the tool title, or press the Use Tool pushbutton.
Group
Parts into a Common Repair Item
1. Select the repair item name that you want to add the other components to from the pull-down list box at the upper portion of the screen. The part currently assigned to that repair item will be displayed on the lower right list box.
2. Select (from the lower-right list box titled "All Parts") the repair items that you want to add to the selected repair item group.
3. Press the right arrow key to move the selected item(s) to the selected repair item group.
4. Press Save. A message box will be displayed, asking you to confirm the new designation.
Note: at any time you can restore default values to repair item names
by accessing the "Restore Defaults" option available from the menu bar
of the main Specify Repair Items screen. Press Tools...Reset to Default
Repair Items.
Separate
a Part's Fault Locations into Distinct Repair Items
1. From the main Specify Repair Items screen, select the repair item name (from the pull-down list box in the upper portion of the screen) that you want to separate.
2. In the "All Items" list box, change the view from Parts to Faults.
3. Highlight those fault(s) that you want to remove from the selected repair item (in the list box at the right titled "Selected Repair Item Faults")
4. Press the left arrow key to remove those faults from the selected repair item.
5. A message box will pop-up asking you if you want to create a a new repair item name for the parts removed. Press Yes. The tool will assign a repair item name for the separated faults which is the same as the fault location name(s). If you elect to change that name, use the Rename function tab available from the Repairs Items pushbutton.
Note: at any time you can restore default values to repair item names by accessing the "Restore Defaults" option available from the menu bar of the main Specify Repair Items screen. Press Tools...Reset to Default Repair Items.
Define
Repair Action for Repair Items
To define a Repair Action for a Repair item:
1. Select the repair item from the pull-down list box of repair item names.
2. Enter the Repair Action string in the text box labeled "Repair Action"
3. Press Save.
1. Select the repair item from the pull-down list box of repair item names.
2. Enter the Repair Description in the text box labeled "Repair Description"
3. Press Save.
NOTE: the repair item name is normally the information passed from the Diagnostician to the client program to define the fault call-out at the end of the Diagnostic session. Changing this name will result in the new name being passed by the Diagnostician to the client program. Forethought of run-time setup and linkages should be given prior to changing these names. Consider using the Repair Action field for obscurely names SGML frame tags.
To rename repair item names:
1. Press the "Repair Items" pushbutton at the upper portion of the Specify Repair Items screen. The Repair Items functions window will appear.
2. Press the Rename tab.
3. Select a Repair Item to rename from the drop-down list box.
4. Enter the new name in the New Repair Item Name text box.
5. Press Save.
Designate
the Repair action as a Child Model
Sometimes, a repair action can be associated with a lower level model, called a child model. Instead of calling a repair/replace procedure, failure of this part causes a call to the child model.
Each Fault Location has associated with it either a Repair Item name or a Child Model. In order to indicate to the run-time system that the repair item is a child model, it must be designated as a child model in the main screen of the Specify Repair Items screen. In the middle of the screen, under the Repair Action field, is a check-box for indicating that the Repair Item is a Child Model. If you designate a repair item as a Child Model, the Repair Action field must contain the file name of the run-time DKB associated with the child model.
What is a Child Model? When multiple levels are tested, it is often more efficient to divide the testing up into levels. If a "box" is tested, with the corresponding failed component as the diagnostic goal, this is two levels (box level and board level). A single model could be used, but this would be rather inefficient. The better approach is to provide two models during run-time. The first model will isolate to the failed board. The second model will isolate to the failed component on the board. This second model is called a Child Model. When the Run-Time system indicates that the board is bad, its associated Repair Action will refer to a Child Model. Branching to the Child Model will be automatic, if desired. If testing is to proceed at another test station, the branching may be via network or manually via memory storage. A hierarchical approach to diagnostics using child models can also be very useful when developing and performing diagnostics for a highly complex design. In this case, the complexity is divided into several lower level models.
Child level models are also beneficial when complex sections of an overall system require more detailed testing than required by the system as a whole. For a more complete discussion on the use of Child Models, phone Giordano Automation technical support at (973) 729-5888.
Often, in both embedded and off-line applications, multiple level models are required for an adequate diagnostic capability. Multiple Level models can reflect two or more hierarchical levels. A three level box assembly model would contain the box, its boards, each board's components, and descriptions of these components. The three levels are box, board and component.
The top level model is called the Parent Model. Lower level models are called Child models. Embedded applications are often at the system or subsystem level. The capability to define the system as multiple levels of hierarchy allows a completely descriptive model of the system. For example, a control system for a power management unit will contain many subsystems. Within each of these subsystems, replaceable components will exist. A multiple level diagnostic model would contain a model of the system, then each of the subsystems, and for each subsystem, a model of its components. The alternate, one large model, would result in an poorly designed and difficult to manage diagnostic system.
There are two methods of creating a multiple level hierarchical model. One is to create and link each level model using the input data capture program. The alternate method is to create separate levels at the input stage and link them at Run-Time. Both of these approaches are discussed below.
Linking at Input Stage
In order to link multiple level hierarchical models at the input stage, the software package used to supply the Profiler input must support this process. Most popular CAD/CAE packages allow linking of multiple levels and creating a linked output in either EDIF or VHDL. OrCAD supports the definition and linking of multiple hierarchical levels.
If the designer is designing multiple levels of the system or subsystem, then the resultant multiple level model description can be directly input to the Diagnostic Profiler. Unfortunately, most designers are given sections of a design to create. This limits the likelihood that a given CAD/CAE system or network of systems will contain models making up the entire system. Since multiple level diagnostics is a powerful concept, another means to implement is made available in the Diagnostic Profiler. The next section explores this means.
Linking at Run-Time
In a single level, or flat, model, an isolated fault results in repair procedure initiation. In a multiple level, or hierarchical system, a fault found at any level other than the lowest level results in branching to a lower level model, resulting in continuation of the diagnostic session. For example, three models exist. These are listed below:
Top Model
- Subsystem Model
Level 2 Model
- Line Replaceable Module (LRM) Models
Level 3 Model
- Component Models
The top model is a single model that reflects the subsystem and its multiple LRMs. The next model, number 2, is actually a number of models, one for each distinct LRM. The third and lowest model is a series of models, one for each distinct component. During diagnostic run-time, a failure at the Subsystem level will result in a call-out of an LRM. Instead of branching to an LRM repair procedure, the system branches to the corresponding LRM model. A call-out at the LRM level results in the branching to the corresponding component model. At this point, a localized fault results in the branching to a repair/replace procedure. For each repair action except the lowest, the repair action must be designated as a Child Model.
Each model of the hierarchy can be retrieved or created separately.
Instead of placing the burden on the designer to link up models, the Profiler
allows the test engineer to link models using the model name and setting
the Child Model designation appropriately.