The advent of VXI brought with it the promise of interchangeable instrument components. But without a unified software architecture, ad hoc system designs proliferated in the automatic test equipment (ATE) community. As a result, ATE users were forced to contend with system integration and software issues, sometimes at a cost exceeding the initial hardware investment.
This industry shift created a demand for open software components that provided the features and functions of closed-architecture test systems. Our involvement with several customer-specified ATE software projects brought us to one conclusion: Most test-system requirements are similar, with slight variations. By creating an architecture that contains modular components with well-defined interfaces, we are able to build run-time and fault-isolation modules that are applicable to a variety of customer requirements.
System Requirements
The prime objective of test is to ensure the integrity of the unit-under-test (UUT) as economically as possible. This involves testing the unit and, if the test fails, locating the fault and repairing it quickly. To do this requires a comprehensive test program, a way to manage the test process and the capability to isolate the defective device.
When dealing with engineers and software professionals, the requirements can easily drift toward elegant technical solutions that may miss the prime objective of the system. To avoid this pitfall, we partition the system requirements into core processes, then identify their behavior and the interface requirements between them. Although not implemented in a pure object-oriented language, the concepts of encapsulation and message passing are used throughout the design.
At every step of the design process, a minimization of each module application program interface (API) is performed. This eliminates functionally equivalent overlapping software interfaces which unnecessarily add to the complexity of a system.
Following these guidelines, we abstract the system to these core modules: application development environment (ADE), test sequencing, fault isolation tools and translation tools. Figure 1 shows an architectural overview of the system components and their relationships.
Application Development Environment
The ADE is the module that the test programmer or engineer uses to develop test applications. This domain encompasses proprietary tools, standard programming languages, test-development systems and graphical interfaces. Depending on the system configuration, more than one may be used to achieve a complete test solution. Since this is primarily a user requirement and bias issue, the system must be independent and compatible with a variety of development environments. We accomplish this by designing an API that is easily supported by any ADE that can build Windows-compatible programs.
As a minimum, the test program must be a Windows executable that stores test- failure information to a formatted file. A second file is used when storing guided-probe measurements. Because of the component nature of the design, alternate test- execution scenarios are also supported. This includes direct support for table-driven digital testers and other semicustom implementations.
Test Sequencing
Test sequencing, or run-time, requirements depend on organizational needs and user bias. In our view, sequencing is best if it is separate from the test programs. This allows the sequencing module to be reused with different test sets. It also results in a consistent approach that is beneficial to both test operators and developers. In addition, integrating it with a standard run-time library promotes a common user interface for test programs and supports consistent data reporting and logging.
The minimal requirements for a reusable test sequencer, or executive, are configurability, datalogging, flexible test execution and report generation. More advanced features include prerequisites, an external tool interface, pre- and post- sequence operations, integrated test breakpoints and error/warning control.
Ideally, the executive should be configured through simple script files rather than requiring additional programming effort by the developer. With a component-based approach, active version control is crucial to ensure a complete and up-to-date test set.
Finally, an architecture such as this automatically supports test programs developed in a variety of languages and ADEs. For example, our test executive supports test-program modules developed in C++, LabWindows/CVI and Visual Basic. To the test operator, this hodgepodge appears as a seamless and integrated system.
The system design also accommodates run-time systems that have less flexible monolithic views of test sequencing. All the system components operate as either stand-alone executables or as callable dynamic link libraries (DLLs) with simple APIs. This allows a system integrator to provide an upgrade path for existing test sets.
Fault-Isolation Tools
Automated fault-isolation tools significantly reduce the time and cost of repair. This is achieved through quicker and more accurate fault diagnosis and the use of lower-skilled test operators. Traditionally, these tools have been tightly integrated with specific hardware and operating environments. In our architecture, we modularize the processes. This makes the modules independent and configurable for specific system requirements.
Fault-Dictionary Processor
Fault-dictionary isolation compares test failure patterns to stored sets of fault data. When a failure pattern is completely or partially matched, the responsible nodal fault can be predicted. The input to the process is simply a test-failure pattern. The output from the process is a list of probable faulted nodes.
Guided-Probe Processor
Guided-probe fault isolation diagnosis to a failing device by guiding the operator through a series of nodal measurements. Once the nodal behavior transitions from failing to passing, the faulty device is detected. This requires that a test program be run multiple times while an operator samples nodal behavior. Consequently, repeatability of execution is a significant aspect of the design.
Our solution is a server module, the Test Controller, that coordinates test execution for various clients. The clients include the test executive, third-party applications and the guided-probe processor. This approach provides the execution repeatability required for fault isolation via the guided probe.
The Test Controller also becomes the conduit for exchanging information and isolation results. For example, once the fault-dictionary process is complete, the results are passed to the guided-probe processor (GPP) to bias the walk-back algorithm. This additional information significantly reduces the number of guided probe steps required to isolate the fault.
Graphic Browser
Over the years, there has been a significant interest in graphically displaying annotated pictorial views of the UUT for test-setup and fault-isolation instructions. We have investigated several approaches for achieving this, including importing CAD data and custom drawing tools. These approaches are complex and labor-intensive in the preparation of the test-program data. As a result, we developed a tool that mapped hot spots on a pictorial view of the test subject.
This approach allows us to build a program module for a variety of applications. The primary intent is to couple the graphic browser to the GPP to show the test operator where to apply the probe. Since this is a free-standing module, it can instruct the operator in placing setup jumpers, making circuit modifications, performing visual inspections and making adjustments during test.
Test Controller
The heart of our architecture is the Test Controller, a DLL that coordinates the execution of test programs with subsequent support processes. Because it is a standard DLL call, the Test Controller can be accessed from many client programming and development environments. These include C, C++, Visual Basic, LabVIEW, LabWindows, ATEasy and any other environment that can make a standard DLL call.
The Test Controller supports test execution and halting, fault isolation and internal messaging. Actual test execution is handled by a separate execution-resource DLL that allows the Test Controller to operate with a range of test environments.
Figure 2 shows the three primary software layers of the architecture and the different kinds of information involved. To run a test, the Client Application starts the test operation by calling the TcRunTest() routine in the Test Controller DLL. The Test Controller accepts three input parameters that define the test environment, the type of testing to be performed and the desired fault-isolation strategies. The Test Controller returns pass, fail, exception error and fault-isolation result information.
Collaborative Issues
Other related design issues also affect the viability and usability of the ATE system. Specifically, they relate to test-program ADE and instrument-driver architecture.
In the ADE environment, our design relies heavily on capturing test-program and fault-isolation data through a learning process. This is an effective and efficient way to develop test programs, particularly for fault-isolation data. Alternatively, simulation post-processing tools support users accustomed to writing test programs using simulation tools.
We provide a core set of high-level user-interface calls and encapsulate low-level operations within the driver body. This makes the instrument easier to use and optimizes driver performance. An example of this is an Execution Resource we developed for the Talon Instruments SR192, a VXI digital module. The Execution Resource for this instrument runs the test, performs all the vector pass/fail comparison, responds with UUT-oriented error reports and provides probe data management.
Conclusion
Whenever possible, existing technology is used in the design. Also, there is a strong focus on ergonomic issues. The objective is to provide an integrated and seamless user-friendly environment encompassing test-program preparation, run time and fault isolation.
Our effort yields an open and extensible ATE architecture that integrates cleanly to many mainline ATE software packages. As the architecture evolves, we reuse software components for different applications. By building on the architecture, the ATE community may ultimately achieve component standardization and interchangeability.
About the Author
Eric Sacher is president of Serendipity Systems. Before founding the company, he held several software, engineering, marketing and technical management positions, most recently as vice president of marketing at Cirrus Computers and marketing director at GenRad Designs. Sacher has three patents and is a member of the IEEE and ACM. Serendipity Systems, 299 Van Deren, Sedona, AZ 86339, (520) 282-6831.
Copyright 1997 Nelson Publishing Inc.
January 1997