|
|
Diagnostician Implementation in a Test Program Set - a Software Engineering PerspectiveIn 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. The traditional approach to the development of diagnostic programs 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 ability of the human mind. Test programs have been written 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 program sets and poor rehostability. 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.
In this chart, the original unstructured code is called SPAGHETTI CODE because GO-TO statements are used to control the execution flow when there are diagnostic failures. 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 testsrun 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 figure 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 figure, 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.
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. The result of using the Diagnostician is object oriented diagnostic capability with no Diagnostic Flow Charts. 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 which allows the 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! The development of the diagnostic software object (the diagnostic model) is supported by the Diagnostic Profiler. The selection of test points and the assessment of fault isolation probabilities as well as validation of these probabilities are all done using the Diagnostic Profiler during development of the TPS. Diagnostic engineering and test engineering are uncoupled. Test programming tools 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 test result data for each measured parameter into 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. Use of the diagnostic object in run-time to perform fault isolation is done by the Diagnostician. To incorporate diagnostics into 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 test results to the Diagnostician. 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. In addition to reducing TPS development time and cost, the model-based diagnostics reasoning approach is easily updated for design changes and allows fault simulation for diagnostics V&V.
|
|
Send mail to webmaster@giordano.com with
questions or comments about this web site.
|
