DIAGNOSTIC PROFILER HELP SYSTEM

DIAGNOSTIC PROFILER INTRODUCTION

Introduction


The Diagnostic Profiler is a commercial off-the-shelf software product that implements automated diagnostics in both embedded and off-line support environments. The Diagnostic Profiler implements model-based reasoning technology while facilitating a process that breaks the wall between design and support engineering. This wall has been the major inhibitor of a truly integrated approach to diagnostics. Use of this process results in a highly integrated "diagnostic subsystem" where the diagnostic capability is developed, evaluated, validated and deployed concurrent with system development.

The Diagnostic Profiler is very powerful because we have focused heavily on run-time - providing a fault isolation capability that you can host in virtually any environment. We have also focused heavily on the "process" of concurrent engineering for support, so our complete tool set supports an integrated product development process.

This package consists of a development tool, the Diagnostic Profiler, and a run-time tool, the Diagnostician.

The Diagnostician, in run-time, will read test results and interprets cones of evidence produced by pass and fail data to provide a diagnostic call-out. It does this by correlating test results to a diagnostic model of the item under test. The model is derived from CAD data (EDIF netlists) using our development system, the Diagnostic Profiler. You identify what tests will be available in run-time and the diagnostic knowledge base is complete. Use of the Diagnostician will allow you to write much less complicated test programs: all of the diagnostic logic that is normally "hard-coded" in the test program is now contained in the diagnostic knowledge base. It is a simple process, and provides you with a comprehensive fault isolation capability without writing expensive diagnostic tests and flow charts.

Since the Diagnostic Profiler also performs testability analysis and provides visibility of test/diagnostics design issues up-front, it also provides an overall concurrent engineering framework.

Using the Diagnostic Profiler, a diagnostic representation, or model, of the system and its constituent elements is derived directly from CAD data. The model is a representation of the diagnostic behavior of the system: how faults propagate out to points where they are observable by tests or monitoring points. The model, when first translated from design data is based upon component definition, signal flow, hierarchy and interconnectivity. The engineer uses the Diagnostic Profiler tools to add information regarding the coverage of actual and/or proposed tests (possible test alternatives). The alternatives can reflect different maintenance strategies, test resources, test scenarios and so forth. The Diagnostic Profiler calculates testability statistics to determine the effectiveness of the test alternatives. Since the result of the analysis, the model, is deployed as the diagnostic capability, this analysis is not a hypothetical, paper based analysis, but rather is a profile of the actual diagnostic effectiveness to be achieved in run-time.

The diagnostic model of the system can be derived for any level of system indenture. This means that different subsystems developed by different development organizations and at different points in time, can be dealt with at any level of granularity from circuit card assemblies, all the way up to functional model representation of major subsystems.

The models are integrated as a hierarchy in run-time operations. The Diagnostician is intelligent reasoning software reads test data and performs fault isolation based upon correlation of test result data to the model. The test data can be from any source: performance monitoring, data bus, sensors, built-in test, operator observations, off-line ATE tests, and so on.

The Diagnostician software and the hierarchical models can be integrated in the system in a number of ways. For example, an equipment manufacturer hosted the model on a large-scale Teradyne test system to provide automatic diagnostics without writing complicated diagnostic routines. In another example, in an application on a Navy submarine, they were hosted on an embedded maintenance computer. On a NASA application, they were hosted on an embedded micro-controller among prime mission circuitry. This flexibility facilitates implementations that make sense within the context of the overall system architecture.

In these applications, model-based diagnostic software (DiagnosticianTM) is used in lieu of programmed no-go flow paths which are the basis of diagnostic test programs and BIT fault codes. In run-time, the DiagnosticianTM provides dynamic fault isolation without complex diagnostic test programs.

The Diagnostician is a major innovation to the overall test process. To support embedded and off-line applications, the run-time Diagnostician has been designed to operate in myriad host platforms. The DiagnosticianTM run-time environment is implemented as a library of functions providing diagnostic services to any program that requests its services. It uses the system/UUT model, the diagnostic knowledge base, generated by the Diagnostic Profiler to derive a fault isolation call-out. The DiagnosticianTM makes use of artificial intelligence in the form of Set Covering Algorithms that interpret the Cones of Evidence produced by pass and fail data from the test results. To integrate the Diagnostician into a run-time environment, the developer need only be concerned with the use of "building block" diagnostic functions to implement the test/diagnostic strategy that makes the most sense for the application. Test results such as observable data, BIT data, or ATE test results are passed to the Diagnostician via a library function. Diagnostician results, or outputs, are also requested via simple library function calls. These outputs may be a fault isolation call-out, an ambiguity group, an ambiguity group size, or the next optimum test procedure to be executed. The fault isolation call-out may be any form required to effect system maintenance, including part name, an SGML/HTML frame tag to remove/replace instructions for the faulty item, or even a reconfiguration control function.

The Diagnostician is a set of intelligent software algorithms which operates on a product's knowledge base and provides automatic fault isolation. The Diagnostician is capable of dynamic interpretation of test results and is a significant departure from the static 'diagnostic flow chart' strategies inherent in other expert system applications.

The Diagnostician is "object-oriented," that is, the data and software needed to isolate faults are merged into objects called Diagnosticians. The transition to Object-Oriented programming for diagnostics will have dramatic impacts on the implementation of concurrent engineering for support. The same Diagnostician generated by the system engineer will be used as a "server" in both embedded and off-line test environments.

Model-based reasoning enables a concurrent engineering approach to all aspects of integrated diagnostics and testability development. It also facilitates a program view of all diagnostic elements where these elements can be viewed as a highly distributed subsystem - a diagnostic subsystem. Our reasoning software is also ideally suited for overlay on existing products to improve diagnostics.


The Diagnostic Profiler contains a number of tools and utilities that step you through the process of generating a model-based diagnostic capability. The user interface is a series of tabs that represent specific functions that are performed sequentially through the development process. These functions include 1) Import Design, 2) Specify Tests and Repairs, 3) Testability Analysis, 4) Generate Run-Time, and 5) Diagnostics V&V. An overview of each of these steps is provided below.

Import Design Tab

The first step in the process of developing a model-based diagnostic capability is importing design data. The underlying data files and directory structures are managed by the Diagnostic Profiler's graphical user interface. All that you need to be concerned with is the naming of your project. The EDIF Import Wizard will automatically translate an EDIF Version 2 0 0 or greater netlist into the format used by the Diagnostic Profiler. Another tool in the Import Design area is the Design Changes Wizard. This tool merges an updated design data file with a Diagnostic Profiler project already in process. The project is updated automatically to reflect the design changes. The wizard also provides detailed information on what design changes were made, how these changes impact the tests that had already been defined, and can step you through each area impacted. A Combine Designs Wizard is used to combine two or more designs. You define the interconnectivity between the two designs, and the two are merged into a single model. This is useful for multi-level boards. SGML Troubleshooting Data Import allows capture of SGML tagged fault trees for creation of Class V Interactive Electronic Technical Manuals from legacy data. The Create Designs Wizard allows you to create a model manually from a list of parts & faults. Digital Fault Simulator Data Import enables you to import data directly from the output files of a fault simulator (HP3070/3075 available at this time).

Specify Tests and Repairs Tab

The Specify Tests and Repairs tools provide the means for you to define the tests that will be applied to the design and define repair actions. In using the Specify Tests tool, you map tests to the design model. First, you give the test a name, select measurement location(s) and stimulus location(s) as appropriate. The Profiler will display a list of the components/pins covered by the test. You can modify this list based upon actual component coverage of the test. You can map partial tests as well by defining the signal attribute to be measured and the components covered. The Test Ordering Wizard allows you to establish forced test sequencing for run-time. In using the Specify Repairs tool, you define what comprises a Repairable Item. By default, each individual component is a repairable item. Components can be grouped into a single repairable item. Using the Specify Failure Rates tool, you can define a failure rate at the component or the pin level. The Specify Test Information tool allows you to enter descriptive information on the test.

Testability Analysis Tab

The Testability Analysis tab provides one tool: the Testability Analyzer. This tool performs calculations based upon design and test information to derive fault detection and fault isolation percentages and ambiguity group size and composition. Testability statistics are displayed on the screen. You can also generate a number of reports which document the testability statistics.

Generate Run-Time Tab

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. The tool Specify Runtime Configuration Parameters will assist you in setting up the optional operating modes of the Diagnostician. It will then automatically generate the internal files necessary for the Diagnostician to configure to those modes. The tool Generate Run-Time Diagnostic Knowledge Base will convert the candidate currently loaded into a binary file for use with the run-time Diagnostician.

Diagnostics V&V Tab

The Diagnostics V&V tab provides tools which assist you in simulating fault events and determining diagnostic capability provided by the run-time Diagnostician. These tools help to verify and validate the diagnostic capability provided by the combination of the Diagnostic Knowledge Base and the Diagnostician. The Maintenance Exerciser lets you define single or multiple fault events, simulate the events, and view the runtime Diagnostician in action as it reads test results, selects the optimum next test to be executed, reads those results, until it derives the best fault call-out possible. You can see what test result data was used by the Diagnostician, and view either the Repair action, the Repairable Item call-out, or the pin-level fault call-out. Another way to use this tool is to allow it to run in batch mode. In batch mode, the tool will run all fault events and accumulate fault isolation resolution statistics, and will also generate a log file which profiles the diagnostic results of each simulated fault event.