A NEW BREED OF SMART DEPOT TESTERS USING COTS TECHNOLOGY

ABSTRACT

The most difficult and time consuming portion of depot repair is the diagnostic element (fault isolation). The writing of troubleshooting procedures and/or diagnostic flow charts and programs for automatic test equipment is an extremely labor intensive and expensive process.

As a result of these high costs, the depot service environment is characterized by unique testers with specialized test programs usually written by the product designer staff. This has led to many depots for different products in countries all over the world which are inefficient to operate and do not produce the potential profitability dictated by this huge marketplace.

Major advances in technology have opened up this market to enterprising high technology companies. This paper defines that opportunity, the technologies which make it possible, and a specific COTS approach to depot tester design.

INTRODUCTION

The twenty-first century ATE is a "system engineered" solution to a myriad of complex and sometimes conflicting requirements.

The system described in this paper combines COTS hardware and software standards with breakthrough integrated diagnostic software technology resulting in a truly reconfigurable "open architecture" VXI tester with 100% industry standards and no proprietary interfaces.

A Graphical Programming language for test procedures is used along with a standard SGML interactive electronic technical information system.

A COTS concurrent engineering tool set which implements the diagnostic system engineering process defined by ABBET Levels 1 and 2 is used to generate UUT knowledge bases which interact in run-time with an inference engine to automatically isolate faults..

The authors believe this 100% COTS system is a serious candidate for the 21st Century ATE.

The new breed of tester enabled by COTS technology will have a major impact on the "Depot of the Future".

The following illustrates some potential improvement areas:

"The Re-Engineered Test Process."

The COTS (Commercial Off-The-Shelf) open architecture depot tester is a high-performance smart automatic test system for functional testing and diagnostics of analog, digital, and mixed (analog/digital) circuits at the printed circuit, module, assembly, subsystem, or system level. It is directly applicable in depot and production environments. This system is based on the open VXI architecture standard. The configuration flexibility and expansion capability are virtually unbounded, assuring the ability to meet future testing requirements as product technology evolves.

The key to the system's performance is the use of a commercial off-the-shelf software environment for test. The concepts embodied in the five layers of ABBET (A Broad Based Environment for Test) and the IPDE (Integrated Product Data Environment) military initiatives are used to provide a seamless CAD to test process with extensive use of commercial standards.

Use of innovative model-based reasoning has "Re-Engineered the Test Process." Traditional development of diagnostic test programs required a highly labor-intensive process of going through pages of schematics and circuit diagrams, hypothesizing all potential failure modes, and developing discrete test paths to ensure fault isolation. This process is performed by highly skilled test engineers, at a high cost. As system complexity increases, the ability to comprehend No-Go paths can exceed the ability of the human mind. Test programs have been written as long software programs, 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.

In the next generation Depot Tester, model-based diagnostic software called the Diagnostician is used in lieu of programmed No-Go flow paths. In run-time, the Diagnostician provides dynamic fault isolation without complex diagnostic test programs.

Using the Diagnostician, the fundamental nature and structure of test programs has been changed. Tests are discrete software programs and routines, which may be independently executed. The interpretation of the tests is done by the Diagnostician which dynamically, on-the-fly, interprets test information based upon all information it receives in any order. In this type of test program structure, no code is duplicated. The list of faults is clearly identified and diagnostic data for each fault is kept in one spot. Model based reasoning makes diagnostics independent of the test program. This separation of diagnostics and test software will permit the user to update the test system instrumentation without expensive rewriting of TPSs.

Because of the strict use of industry standards, there are no proprietary items in the overall ATE system design. This will allow flexibility for updates, new designs and major modifications to accommodate current and future requirements.

Technologies

Critical technologies which facilitate implementation of a highly effective depot program are as follows:

1. Information Highway - Product Data Standards

The information revolution has been spurred on by DoD programs such as CALS and Integrated Product Data Environment (IPDE). This is supported by the tremendous Internet following built up over the years.

This adds up to product data flowing freely from point A to point B in a very cost effective manner. Standards have allowed moving data files from product design platforms directly to support activities. This will enable tracking product changes for diagnostic utilization at the depots.

2. Artificial Intelligence - CAD to Test Tools

Advances in artificial intelligence allow the utilization of computer programs for diagnostic analysis and fault isolation as opposed to hard coded test programs. The availability of concurrent engineering tools which translate CAD data into fault symptom matrices and allow the implementation of run-time diagnostics using "Inference Engines" in concert with the products "Knowledge Base" are now available.

Complete elimination of diagnostic flow charts and fault troubleshooting procedures are possible using model-based reasoning concepts.

This technology breakthrough will reduce the cost of establishing an efficient depot by an order of magnitude for the highest cost drivers namely, diagnostic intelligence.

3. Open Architecture Reconfigurable Test Systems - COTS

Test system technology has advanced to Instruments on a Card utilizing very large scale integrated electronic circuitry. These Instruments have been standardized by industry into a backplane called VXI.

It is now possible to design any complexity into automatic test systems using VXI assets and reconfigure these assets as required to meet product workload demand. The day of the obsolete large automatic test system sitting on a depot floor is over.

Utilization of industry standards for software and open architectures for hardware configurations will allow ATE assets to grow as product needs grow and to be reconfigured depending upon the overall depot workload. Once unique and expensive, test systems are now available as Commercial Off-The-Shelf (COTS).

4. Electronic Repair Procedures - Interactive with User

Interactive Electronic Tech Manuals (IETM) are becoming commonplace in the field service industry. As a result it has simplified the task of generating remove and replace procedures tied directly to faults isolated by the diagnostic capability within the automatic test system.

The use of authoring and display tools will allow the generation of information portions of test programs including set up procedures as well as repair procedures eliminating "tons" of documentation.

5. Simplified Test Programming Languages - Instrument on a Card Soft Panels

The test industry has evolved into the generation of graphical programming languages (GPL). These languages allow test programs to be written in extremely short timeframes. The AI based automated diagnostic capability has been integrated with the graphical program language framework as a series of virtual instruments within a Windows framework.

The test programmer is now capable of providing a complete test and diagnostic program with technical information on set up and repair procedures as a complete solution to each products depot requirements.

With the development tools in place the overall problem of generating a depot capability has been reduced to straight forward tasks.

Next Generation Depot Test System Overview

The evolution of computer programming has been to "object oriented" code. The basic idea is that the code associated with different objects or functions is separated into units and the work gets done by the cooperation of the different units. For test programs with diagnostics, the test measurements and the diagnostic analysis are treated as separate objects.

In the "Next Generation" tester all objects are integrated under a WINDOWS environment. The objects include electronic technical information (test set up/remove and repair procedures), test information, and diagnostic information. Control passes from one object to another depending on the mode of operation. Modes are unlimited and are determined by the ATS engineer. They may include:

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. Changes in functional test order have no impact on the diagnostic process - although it may impact which tests are made. Changes in the coverage of a test are reflected in 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 require 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.

Development Tools Are COTS

The LabVIEW Run-Time System, the AIMSS Run-Time System and the Diagnostician are Commercial Off-The-Shelf products which have been integrated into a test system. National Instruments, Hughes, and Giordano all supply development tools.

Smart depot testers are truly an outcome of "dual use" technology being encouraged by the aerospace industry. These systems are now appearing in depot environments for commercial applications.

Perhaps the single most important feature of the new test system is its ability to read the unit under test's internal built-in-test data and utilize the information provided to fault isolate directly to a single faulty card. The marriage of off-line test equipment to a unit's on-line test results will eliminate the need for much of the instrumentation now required for stimuli/measurement functions.

In addition to use of industry standards such as VXI hardware and WINDOWS software there are three overriding technology attributes in the next generation depot test system. They are:

Concurrent Engineering Tool Set (CETS) Overview

The Concurrent Engineering Tool Set (CETS) is a model-based diagnostic design tool set which provides both the development environment of a diagnostic capability and the run-time capability for a diagnostic system. The development tools facilitate a concurrent engineering environment. The run-time capability can be embedded into the prime system and/or used off-line in a portable maintenance aid (PMA) or the next generation COTS Depot Test System to provide fault isolation in real-time. CETS facilitates the evolution of system design information into a hierarchical series (i.e., system, subsystem, board) of diagnostic reasoners, called Diagnosticians.

The CETS automated software tools are designed to transform prime system data (directly from CAD platforms) into diagnostic information as the system development process evolves. These functional tools serve to evolve design data in an automated environment to a deployed diagnostic capability concurrently with system development. For legacy systems CETS provides visibility into diagnostic enhancement without extensive hardware modification.

The diagnostic knowledge-based approach allows uncoupling of the diagnostic information from the test source (built-in-test, performance monitoring, sensors); i.e., the knowledge-based diagnostic software is totally independent of the test source or equipment that is deployed. This modeling paradigm uses the interconnectivity of all the elements that comprise a system to generate a fault symptom matrix (i.e., mapping of suspect faulty element to testable or observable symptom). This data is provided as an input to artificial intelligence (AI) based abductive reasoning software. From a diagnostics perspective, abductive systems can be called intelligent fault dictionaries and can be used to find all failures to explain a given set of symptoms. Abductive systems can diagnose multiple faults in systems, which enables a comprehensive diagnostic capability.

The Diagnostician can be hosted on a variety of processor platforms, including the Sun Workstation, PC platforms, embedded microcontrollers such as the Motorola 68F333, and test station controllers for off-line ATE. The Diagnostician is completely self-contained software. For different applications, the user must only be concerned with how to get information (test results) into the Diagnostician through the input port and how to get information (diagnostic call-out) from the Diagnostician through the output port. The input port can be linked to a 1553 data bus or any other type of built-in-test (BIT) data or ATE test results and the output port to electronic technical information provided to the user.

The structure of the Diagnostician can lead to a host of automated test product applications: interactive electronic technical manuals (IETMs), PMAs, ATE, bus data interpreters, and embedded diagnostic systems. In effect, this capability will provide a Diagnostic Subsystem capability at the platform level, which is applicable across all subsystems and technologies: analog, digital, hybrid, mechanical, electro-mechanical and electro-optics.

Diagnostician as a Virtual Instrument

The next generation COTS Depot Tester provides users with a mature and complete test development and test execution capability.

The operating system installed on the Pentium PC controller is Microsoft DOS (Ver. 6.2) and Microsoft Windows (Ver. 3.1). National Instruments LabVIEW for Windows software (Ver. 3.1) and Giordano Automation Diagnostician are provided as the programming environment for test programs. All software modules or VIs (Virtual Instruments) are provided in LabVIEW, including instrument drivers. VIs are included to enable the test engineer to easily control the test system at a high level. These VIs make the system user-friendly, so that a programmer does not concern himself with low level routing and programming functions, but rather with system instrument functions and ICA pins. All the users need concern themselves with is the capability of the instruments, as specified by an interface specification, and the pin mapping. This system feature simplifies the development and design of a test program. These programming features apply to both digital and analog testing.

The major cost driver in modern ATE is the cost of developing diagnostics for Test Programs. Since the open architecture COTS Depot Tester includes the Diagnostician integrated into the LabVIEW run-time environment, the user is given the opportunity to use model-based reasoning for complex UUT's. The cost savings with automated diagnostics for TPS development is anticipated to be about 30%. The run-time Diagnostician usage is determined by the TPS writer, who has complete flexibility to bypass or use the reasoning attributes of the system. The system operating mode is controlled by the TPS programmer under the Windows environment. A test executive is not required under this "Services" oriented approach.

The Diagnostician operates under LabVIEW, and is implemented as a series of Virtual Instruments. These VIs include:

OPEN DOC initiates the Diagnostician in the background as another process and initializes the Dynamic Data Exchange (DDE) protocol required by the Diagnostician. This VI will return a DDE reference number to be used by all subsequent calls to the Diagnostician. This reference number is considered the Diagnosticians mailing address. This number will change only when OPEN_DOC is executed. At the same time the DDE protocol is setup the Diagnostic Knowledge-Base (DKB) must be defined to the Diagnostician. This is also accomplished through OPEN_DOC. A string containing the DOS path name for the DKB is passed to OPEN_DOC. The VI will then associate this DKB to the Diagnostician process. For example, the Diagnostician under LabVIEW is called WINADR. WINADR will be executed in the background as another process. OPEN_DOC will initiate the DDE protocol and assign a reference number, and then associate the DKB file name, C:\DACDEMO\DAC.DKB, to the WINADR process.

TELL DOC reports all test results to the Diagnostician. This is accomplished through DDE Pokes. The key word TESTDATA will be sent with each DDE poke to the Diagnostician, using the reference number assigned in OPEN_DOC. This tells the Diagnostician that the incoming information is test results data. While TESTDATA is being poked into the Diagnostician no calculations will be performed. Test results must be sent in the following format, each line of data is a separate call to TEL_DOC:

ASK DOC will return the next test the Diagnostician requires for execution, the current ambiguity group list, and the size of the current ambiguity group. Executing ASK_DOC will cause the Diagnostician to calculate the NEXTSTEP. This would either be another test to execute or a repair callout. The key word NEXTSTEP is sent to the Diagnostician using a DDE request command. This again is done using the reference number assigned by the OPEN_DOC VI. The Diagnostician will process the TESTDATA given to it by the TELL_DOC VI and return the NEXTSTEP information. If it is a test then a case structure can be employed under LabVIEW, the test will be executed and the test results will be reported using TELL_DOC. If the NEXTSTEP is a callout or ambiguity group then the callout can be reported to the user or a repair procedure can be execute. If there is more than one component the keyword AMBIGUITY must be used. The request for ambiguity will continue until the list is exhausted and the word DONE is returned to ASK_DOC. For example, if ASK_DOC requested the NEXTSTEP and testname HIGH was returned, then LabVIEW would execute the routine defined as HIGH. The test would report the results using TELL_DOC and the key word TESTDATA. Then another ASK_DOC would be issued to request the NEXTSTEP. If this time ASK_DOC returned a component, A11, then LabVIEW would execute the repair procedure associated with A11.

CLOSE DOCis the command used to stop the DDE communications process. Once the callout has been made then the Diagnostician can be terminated. CLOSE_DOC will issue a DDE terminate command.

The basic process for the Diagnostician under LabVIEW is to start the WINADR process. Then the DDE communications can be initialized. This returns the reference number to be used for all DDE calls to the Diagnostician. At this time either a request for NEXTSTEP using ASK_DOC or a report of known test results using TELL_DOC can be performed. If ASK_DOC returns a test then that test is executed and the results are reported through TELL_DOC. ASK_DOC must request a NEXTSTEP after all test reports are completed. If ASK_DOC returns a callout or repair procedure then ASK_DOC must request the AMBIGUITY to complete the diagnostic process. Once the ambiguity list is completely reported and the keyword DONE is returned then the CLOSE_DOC command can be issued. This ends the current testing and diagnostic session.

Together these four virtual instruments are called from within the LabVIEW application, to provide diagnostic results based upon reading the results of individual tests.

The LabVIEW programming environment allows other application software modules not written in LabVIEW to be linked into the system. This is accomplished by a variety of methods: executable modules and Windows 16-bit Dynamic Link Libraries can be called via VIs, or actual generation of executable VIs called code interface nodes. Executable modules can be DOS or Windows programs called from within a LabVIEW program. This allows existing executable programs to run without modification. Code interface nodes (CINs) are compiled C routines or programs which generate a custom, uneditable (within LabVIEW) VI.

CONCLUSION

The 21st Century ATE system defined in this paper is 100% COTS. The major attributes are software oriented and allow industry to build ATE solutions for various depot environments. With the advances in "Instrument on a Card" technology the ATE hardware has become a commodity item. Several ATE manufacturers are using this design for factory applications. The software can also be used for intelligent maintenance aids as well as embedded "Diagnostics on a Chip".

The technologies used to build the system are available individually. As standalone products they each have striking virtues. By packaging them together under one platform their strengths combine to create a powerful "Smart Depot Tester". CAD to test tools, information authoring tools, and programming of overall diagnostic solutions for the "Depot of the Future" is obtainable today.

Download in Word Perfect 6.0 format" 

Send mail to webmaster@giordano.com with questions or comments about this web site.
Last modified: December 28, 2001