The Diagnostic Profiler facilitates the engineering analysis by providing the ability to project a candidate test strategy, to analyze the circuitry from the perspective of fault locations and fault modes versus potential test locations, and then by the ability to quickly calculate the resultant diagnostic characteristics associated with the application of tests to the circuitry.

The process of developing a diagnostic strategy is iterative and includes the following steps:

1. Identifying specific changes that could be made to the design to support testability (partitioning, design loops, etc.).

2. Evaluating existing built-in tests or other performance tests which already exist to determine diagnostic effectiveness of these tests.

3. Calculating the resultant diagnostic characteristics profile (testability parameters).

4. Identifying what types of tests can be added at each level of maintenance based upon unique trade-off criteria developed for your product.
 
5. Analyzing the resultant diagnostic characteristics: fault isolation, ambiguity group numbers, size and composition.

6. Iterating steps 3 through 5 until diagnostics capability is achieved (this is a function of requirements).

Use of the Diagnostic Profiler involves engineering analysis in the development of a test strategy. The inputs are the design and a general engineering knowledge of the system, its operational and maintenance environment, maintenance requirements and constraints, such as what test equipment will be used. You must assimilate this information and have a good understanding of it in order to derive a diagnostic strategy. This understanding is required for development of a diagnostic strategy with or without the Profiler. The Profiler provides visibility for performing trade-offs and for the implementation of the diagnostic strategy.

When determining the proper subset of tests, the Diagnostic Profiler provides you indications of whether this subset meets all testability specifications. Typically, you will perform an iterative engineering analysis to define the optimum test subset, or best candidate. This iterative "What If" approach allows you to create candidates of selected tests that meet requirements, compare each of these candidates against the known constraints, and modify the candidates until the best candidate is derived.

Test Mapping Terminology

Scope of Diagnostic Engineering Using the Diagnostic Profiler

Test Versus Diagnostics

The Diagnostic Profiler is a tool that enables you to build a diagnostic model of the item you are testing. This model can be used for testability analysis and for creating a run-time diagnostic capability. A major concept here is to separate diagnostic logic from test. The Diagnostic Profiler deals with diagnostic logic, not with test design. How you verify that a circuit or block of circuitry is functioning through performing tests and measurements and applying pass/fail criteria is a test engineering issue, not a diagnostic issue. The diagnostic issue deals with the implication of what fault isolation can be inferred from pass/fail data at various locations within the circuitry. Since this is an important point, let's go through an example:

Assume a test is to be performed at a board output location called J1_1. This test is a DC Voltage measurement. The nominal measurement value is 5 volts with limits of +/- 10%. The test will be performed using a DMM probe across J1_1 to Ground. These are all test issues. None of these points have any bearing on diagnostics issues. What are the diagnostic issues? If this test passes, then I know that R1.1 is fault-free and that U10 pin 6 is good. If this test fails, I know that R1.1 or U10.6 may be faulty. These are diagnostic implications of the test. In using the Diagnostic Profiler, we deal with diagnostic engineering - defining the diagnostic implications of tests. Therefore, in the following discussions of tests, measurements, faults and failure modes, we are dealing with these aspects as they pertain to diagnostics.

What are Tests?

A test is a routine that exercises one or more measurements. From the test program developer's perspective, a test is a routine that stimulates a portion of the circuitry, measures the response, and then compares that response to a known good value. The test is written such that it will detect some or all possible failure modes in the circuit under test. A test must contain at least one measurement, and often contains several measurements. An example of a test routine is a test measuring the output signal of a board or a probing sequence of internal nodes on the board.

What are Measurements?

Measurements are specific signal output evaluations, normally associated with a single circuit location where measurement data can be collected. Measurements are made during testing. For a board, a measurement location may be either a point within the board or one at the output edge. The graphic below illustrates measurement locations for the sample design, Y082. A measurement normally corresponds to a physical location in the design.

Measurements at a pin location can determine not only that the measurement location is free of faults, but also that certain other components in the signal flow are also free of faults. This is referred to as coverage. For example, in the graphic below, let us assume a measurement at U7 pin 12 (U7.12). If the measurement passes (is within specified values), and we assume that the test was adequate enough to fully verify all relevant functions, then we can infer that the signal is good from the board input up to and including U7.12. Therefore, the measurement at U7.12 covers U7, U1, R11, R10, R19, R50 and C12. If the measurement at U7.12 fails, then one (or more) of the components leading up to, or covered by, U7.12 is faulty. Therefore U7.12 covers U7, U1, R11 and so on. In defining measurements using the Diagnostic Profiler, the primary task at hand is to define the coverage of measurements: what faults does a measurement cover. The Diagnostic Profiler assists you by letting you define a measurement location, and gives you a list of all of the faults that are reachable by that measurement, based upon signal flow. When you first define a measurement all of the faults leading up to, or reachable by that measurement location are, by default, denoted as covered.

You edit this coverage list to eliminate the faults not covered using simple point and click mechanisms. The end result is a clear and accurate profile of all tests, all measurements, and the fault coverage of each measurement. From this information, detailed calculations of fault isolation for the entire circuit design can be derived, and diagnostic inferences are established that can be used in run-time (during test) to isolate faults based upon test results. In run-time, pass or fail designations related to tests and measurements are passed to the run-time software, called the Diagnostician. The Diagnostician performs fault isolation when it is supplied this pass/fail information.

What are Faults?

A fault is detected when a measured value does not coincide with what the measurement value should have been for a good circuit. A fault can occur at any pin location. For a board, a fault can typically be found at the output pin of a component. For a "box" level assembly, a fault is typically found at the output edge pins of the boards within that assembly.

In using the Diagnostic Profiler, a fault may be either a part, a pin location, or a failure mode. For example, component U1 may be faulty, or pin 2 on component U1 may be faulty, or pin 2 of component U1 have an in improper gain, stuck at some value or may have an offset. In using the Diagnostic Profiler, you can deal with faults at any of these levels, depending on your test philosophy and the required level of fault resolution.

Fault Detection refers to the capability to identify that a failure has occurred, regardless of its cause. Fault Isolation refers to finding the fault's exact location. The graphic below illustrates fault locations for the sample model.

In the Diagnostic Profiler, Fault Locations are defined as physical points within the design that are subject to failure. A group of fault locations can represent a single part, where a part is identified by a group of fault locations that are singularly replaceable. (For example, each pin on a component would be a separate fault location, but the component is treated as a single part by assigning each fault location within that part a common repair procedure.) The default values that the CAD translator assigns are: 1) each component is one part and 2) each pin on that component is a separate fault location.

A part is a physical entity within the design that can be removed and replaced. For example, at the board level, a part may be a circuit chip. At the box level, a part may be a circuit board. A part usually has more than one fault locations.

The Diagnostic Profiler identifies fault locations based upon the part they are associated with. When a design is loaded, each location that can fail within the design will have assigned its own fault location name. The names will correspond to those from the actual design.

Test Mapping Information

In the Diagnostic Profiler, Tests have the following information associated with them:

Test Name (required)
Measurement Location(s) (required)
Test Setup Procedure (optional)
Test Procedure (optional)
Test Clean-up Procedure (optional)
Test Cost (optional)
Test Type (optional)
Test Data File Name (optional, used by the Maintenance Exerciser)
Test Description (optional)
 
Measurements have the following information associated with them:

Measurement Name (required)
Measurement Location(s) (required)
Measurement Description (optional)

Faults are categorized as repair items, parts, and fault locations. A part normally contains many fault locations. A repair item is normally, and by default, at physically distinct part. However, these physically distinct parts may be combined into a single repair item by assigning them a common repair item name. Fault isolation calculations are provided at both the repair item level and the part level.
 
Repair Items have the following characteristics associated with them:

Repair Name (required)
Repair Procedure (optional)
 
Parts have the following characteristics associated with them:

Part Name (assigned by design description; cannot be changed)
Repair Designation (by default, same as part name; may be changed)
Failure Rate (optional)

(Note: Additionally, repair designations can be identified as child models, indicating a hierarchical modeling scenario with additional diagnostic logic available beyond the current level of indenture.)

Fault locations have the following characteristics associated with them:

Fault location name (assigned by design description; cannot be changed)
Percent of part failure rate (by default, this is equalized across all locations in a part)
Associated Failure Modes (optional)

Failure Mode designation is optional, and has the following characteristics associated with each failure mode:

Associated Fault Location
Failure Mode Name
Percent of part failure rate

All of the tools in the Specify Tests and Repairs tab are oriented toward defining the above characteristics and relationships. The Specify Tests tool is the primary tool for accomplishing this. Use of the other tools is optional. The Specify Repairs tool enables you to change the default names and grouping of repair items. It's use is optional. The Specify Repair Item Failure Rates tool enables you to change default failure rates at the part and pin level. It's use is also optional. By default, failure rates are equivalent across all parts and locations within the part.

Important Concepts in Defining Test Coverage

The Diagnostic Profiler provides the Test Specification Tool for specifying which faults will be seen at which measurements.

The Test Specification tool supports three ways that a fault can affect a measurement. They are:

None  The fault does not affect the measurement in any way

Sometimes The fault sometimes causes the measurement to fail and sometimes does not

Covered The fault always causes the measurement to fail.

The way in which a fault or a part's set of faults affects a measurement can be seen in the Coverage Column of the Test Specification Tool. ' None' is represented by a blank, 'Sometimes' by a question mark and 'Covered' by a check mark. The values can easily be changed by pointing the mouse to the row in the Coverage column that coresponds to the fault or part and clicking. Each click will change its value. It goes from blank (None) to question mark (Sometimes) to check mark (Covered) and the back to blank (None).

The Diagnostician uses this information during diagnosis to interpret the diagnostic implications of the data provided. A measurement that passes is interpreted as excluding any fault which 'covers' the measurement and providing no information about any other faults. A measurement that fails is interpreted as providing evidence of the possible existence of any fault that either 'Covers' it or 'Sometimes' causes it to fail and no information about any other faults. Thus, from the application point of view, the 'Sometimes' relationship provides about half the diagnostic information that the 'Covered' relationship does.

The Covered List (Faults Covered by a Measurement)

A "covered list" should accurately reflect the faults that a measurement covers. This means that: items in the list should include:

1. All of the items that could have caused the measurement to fail, and no items outside the list can cause the measurement to fail.

and

2. If the measurement passes, then all of the items are free of faults.

Situations may arise where it appears that you cannot express the test in this manner:

A. It may appear that you can define a list that includes all items "leading to a failure" but that these items may not all be cleared on a pass. (a pass does not necessarily mean that the components are fault-free, yet a fail does indict those items)

This means that there is something in the list that should not be there. The something may be a part of one of the items in the list, for example, the something might be a component pin in a list that contains only complete components. Or it could be a fault mode in a list that has only components / pins enumerated.
 

In this case, you must break the fault population (faults covered) into more detail by adding a more granular definition of the coverage list. This could mean -

1. Replacing some component-level definitions with pin-level definitions

2. Replacing some component pin-level definitions with failure mode definitions.

B. It may appear that you can define a list of causes that clears the causes when the measurement passes, but may not indict one of the items if the measurement fails.