|
|
A Software Programmer's ViewIn order to define the differences between traditional and model-based diagnostics, one must go back to the beginning of TPS programming. Test programs as we know them today are written as a series of functional end-to-end tests with measurements made at the output pins in order to assure that the system is operating correctly and ready for issue. The diagnostic portion is handled in one of two ways. The first is to go to a diagnostic program after the end-to-end tests are run, or to write a structured program where each test, upon failure, is followed by diagnostic tests to isolate the fault to the level required by the specification. Traditional development of diagnostic logic requires a highly labor-intensive process of going through pages and pages of schematics and circuit diagrams, hypothesizing all potential failure conditions, and developing discrete test paths to ensure fault propagation. This process is performed by highly skilled test engineers at a high cost. As system complexity increases, the ability to comprehend logic paths sometimes exceeds the capabilities of the human mind. The result is test programs structured as long software routines with extensive branching and jumping. A single change in an independent test affects code throughout that program. In many cases, diagnostic tests are duplicated throughout the program. The development and maintenance of these programs is extremely difficult resulting in the high cost of test programs and poor re-hostability. The technology of computer programming has evolved from unstructured code to structured code, and from structured code to object-oriented code. Test programming is a special type of computer program. As such, it too has evolved from unstructured code to structured code and will evolve into object-oriented code. The original unstructured code is referred to as "SPAGHETTI CODE" because GO-TO statements are used to control the execution flow when there are faults. (Click to View Image: Diagnostics in the Past: Traditional Approach) This code had the advantage of grouping all the functional tests of a good UUT together in one spot. This advantage comes from the unstructured nature of the test. This unstructured code also has two important disadvantages. The first disadvantage is that the diagnostic routines are implicitly dependent on the functional tests run before control was transferred to them. In effect, the diagnosis is distributed between the functional tests and the diagnostic routines. In complex situations, a maintainer finds that it is difficult to pull all the data together to understand what the diagnostic routine is doing. Furthermore, any change to the functional tests, either in coverage or order, can invalidate the diagnostics routines or make them incomplete. The other disadvantage is that the diagnostic routines contain tests that duplicate tests in the functional set of tests. The duplicated tests are selected functional tests which occur after the functional test whose failure transferred control to the diagnostic routine. Usually, this duplication is not well documented and a maintainer who changes a functional test must analyze all the diagnostic routines to carry the changes to the duplicate tests. With the advent of structured programming, GO-TO statements were eliminated and overall program execution was made to flow in one direction. The result of applying this technology to the test program is termed CO-MINGLED CODE in the previous graphic because the functional tests and the diagnostic routines are mingled together. The diagnostic routines of a structured test program are essentially the same as those found in the unstructured test program. Consequently, all the disadvantages of the unstructured test program apply to the structured program. The last evolution of computer programming is to object-oriented code. The basic idea is that code associated with different objects or functions are separated into units and the work gets done by the cooperation of the different units.
For test programs with diagnostics, the test (stimulus and measurements) and the diagnostic analysis are treated as separate objects. In the graphic, (Click to View Image: Test Programs and the Diagnostician Model-Based Diagnostics) the test objects are boxes in the left and the diagnostic object is represented by a Fault/Symptom Matrix in the middle column. The object oriented approach is maintainable and modifiable where the earlier approaches are not. The diagnostic information is centralized in one easy to observe Fault/Symptom Matrix. In it, the relationships between tests and failures can be observed, compared to failure modes and modified. Changes in functional test order have no impact on the diagnostic process. Changes in the coverage of a test with respect to failure modes (yes/no/partial) are reflected as changes to the column of the Fault Symptom Matrix describing that test. Additions of new tests are implemented as additional Fault Symptom Matrix columns. All of these changes go to the heart of the diagnostic problem and requires no obscuring software structures. In the object-oriented approach, duplication of tests is unnecessary. The same test can be used as part of a functional test or a diagnostic test depending on the status of the UUT being tested. The elimination of duplication greatly simplifies maintenance, reduces development cost and improves run-time effectiveness.Click to View Image: Diagnostician Provides Fault Call-Out in Run-Time Based Upon Reading Test Results Without Diagnostic Flow.
The result of using the Diagnostician is object-oriented diagnostic capability with no Diagnostic Flow Charts. Use of the diagnostic object in run-time to perform fault isolation is done by the Diagnostician. To incorporate diagnostics in the test program, a single "WHILE" loop can be used: WHILE there is another test that can further isolate the fault, ask the Diagnostician for the next optimum test to perform, run that test, and send the results to the Diagnostician. This WHILE loop continues until either the fault has been isolated to a single replaceable item or there are no more tests which have diagnostic significance. The impact of this technology is dramatic! Savings up to 30-40% of the overall TPS costs can be realized. Maintenance of the test program, storage and use of legacy data, rehosting, updates, and porting to various platforms including portable maintenance aids are all enabled by the new paradigm. And, a Maintenance Simulator is available that enables a user to simulate the diagnostic effectiveness achieved before committing to coding the test software or building the system hardware or test hardware. Concurrent engineering of support for diagnostics is now a reality!! Diagnostic engineering and test engineering are uncoupled. The Diagnostic Profiler is the development environment that outputs a diagnostic model of a system that can be used in run-time to provide automated diagnostics. Use of the Diagnostic Profiler enables substantial cost savings to be realized as a result of the capability to completely eliminate the need to develop diagnostic flow or logic charts and write the associated diagnostic test programs for a system, a line replaceable unit or circuit card assemblies. The Diagnostic Profiler operates on Sun Workstation and PC platform environments.
The Diagnostic Profiler creates, from UUT netlist data, a representation of the diagnostic behavior of an item - how faults propagate to observable points. In using the Profiler, the engineer defines what points will be visible by what tests. This information is converted to a run-time knowledge base that provides fault isolation call-out based upon reading the results of tests performed. Click to View Image: Design to Fault/Symptom Matrix The diagnostic development process using the Diagnostic Profiler includes full automation from input of CAD data to the generation of the run-time diagnostic knowledge base. CAD based EDIF or VHDL data is automatically converted to a diagnostic knowledge base. This knowledge base takes the form of a "Fault/Symptom Matrix" which enumerates all of the components which comprise the system (i.e. fault universe) and all of the system information/data elements which may be read and interpreted by the Diagnostician's run-time inference engine. If EDIF or VHDL data is not available for the subject system, the knowledge base can be manually generated via capturing system connectivity/netlist data (i.e. interconnection of system components) via commercially available schematic capture programs. The Diagnostic Profiler significantly reduces test engineers' fault isolation development efforts, improves the quality of the resulting diagnoses and preserves the underlying test coverage knowledge needed for evaluation and maintenance. In using the Profiler, the engineer identifies test routines and their associated measurement locations. The Profiler identifies the faults that would be caught by each test by restricting his attention to the design locations physically in the signal path leading to the measurement point. The engineer then determines which of those faults would cause the measurement to fail. The Diagnostic Profiler simplifies this task by providing the engineer with all the design locations in the signal path leading to the measurement point and permitting him to select or unselect faults as being covered using point and click techniques. To provide this service, the Diagnostic Profiler assimilates the actual design data as provided by the netlist information. The engineer identifies the need for functional tests or diagnostic tests by identifying faults that are not tested and by identifying runtime fault call-out (ambiguity) groups which are not acceptable. Functional or diagnostic tests are identified incrementally or in groups and at each increment, the engineer determines whether more tests need to be added. The Diagnostic Profiler automates all the analyses needed to determine whether new tests are needed. At the click of a button, the fault detection and fault isolation statistics are provided. The Diagnostic Profiler also provides reports to help the engineer pinpoint what the test must do.
An engineer using the Diagnostic Profiler does not have to develop a diagnostic fault tree or translate that tree into test implementation language "IF...ELSE" structures. Instead, he adds a few lines of code to the test routine to send the test results to the Diagnostician and, if appropriate, to obtain from the Diagnostician the next test to execute or the identity of the faulty part. The engineer can select the best test strategy for the test being written. For example, if the time for making all the measurements is insignificant, all the tests can be run, and at the end, if any tests fail, the Diagnostician can be requested to provide the fault call-out. At the opposite extreme, if each measurement takes a long time, the Diagnostician can be requested after each test to identify the next test that is most likely to shorten the number of tests needed for fault isolation.
The development of the diagnostic software object is supported by the Diagnostic Profiler. Use of the resulting diagnostic object in run-time to perform fault isolation is done by the Diagnostician. Programming tools such as those provided by TYX, LCTI, and GTT are used to write tests. In the process of writing these tests, the test engineer must define Pass/Fail (P/F) criteria for each response value being measured and convert raw test results data for each measured parameter and output a P (Pass) or F (Fail). This function can be implemented utilizing a simple high level language subroutine which accepts measurement test results and associated tolerances values as inputs and outputs a "P/F" character.
The methodology described is straightforward and well within the responsibilities and expertise of a test engineer. Utilizing the Diagnostician paradigm, the test engineer focuses on what he does and knows best: testing. The specifics of diagnosis, which is a function of UUT topology and behavior, is left to automated reasoning algorithms, which are better suited than a human in resolving complex diagnostic situations. Continue on to ...A Run-Time ATE View of the
Show me the development tool set for Generation of Knowledge Bases |
|
Send mail to webmaster@giordano.com with
questions or comments about this web site.
|
