Reducing the Cost of ATE Software Development

Garth Scheck Crane Aerospace & Electronics Inc

Redmond, Washington 98052 Email: garth.scheck@crane-eg.com

I. INTRODUCTION The expense of test software development is becoming too

much of the total cost of ATE systems. Each test program usually contains a User Interface (UI), sequencing, data handling, and instrumentation control routines. The development time is divided among these routines, sometimes more in the data handling and UI, even though they are non-test related.

Each program’s UI tended to look and behave differently, which required additional operator training and perhaps longer overall test times, as the operator must re-familiarize him- or herself with the different UIs. In addition, the UIs do not contain validation of user input, so the chance of errors creeping into the data is higher.

Time spent maintaining the software increases the support required by the Software Engineer. Due to the redundancy, changing common routines such as reporting or data storage require many ATE programs to be modified. As the number of programs grow, the time investment can become quite significant; there is also an opportunity of introducing new bugs into the code, and risks that some programs do not get updated or changed. Rigid coding introduces other concerns by not allowing instruments to be easily substituted or databases to be changed or enhanced.

Turn Key systems were considered, but were not scalable enough for high mix environments and did not provide easy equipment substitution.

Data was stored in a multitude of different formats: comma separated text, formatted text, and Access data files to name a few. Analysis became very difficult to perform across multiple programs and data formats. A large portion of the data was being stored locally, which made it inaccessible or hard to find. Data archival was an arduous task in these situations.

This mix of software, hardware, and operation issues must be globally addressed, and is especially crucial in a high mix manufacturing environment; an extensible and efficient development strategy is needed.

II. OVERVIEW A new architecture, shown in Figure 1, was introduced for

ATE software development that separated the common routines: IO, instrumentation, and data, into their own libraries. Sharing the routines provided a standardized behavior to all the programs and reduced development time significantly. Having a single user interface across stations eliminated the need for additional operator training. The libraries are language independent, enabling a wide variety of tools to be used in design; this is important because the cost of tools becomes quite measurable as engineering teams grow. Staying with common, widely accepted tools and languages helps ensure longevity of the programs and availability of support. With the exception of the sequencer, all modules are compiled into a library which allows the developer to choose the appropriate language based on the application and his/her skills. The modularity of the architecture also lends well to upgrade paths. Each module of the application can be upgraded one at a time as needed, eliminating the need to completely re-write multiple applications.

Figure 1

III. ABSTRACTION

A challenge in designing ATE software is accommodating substitutions of instruments or data storage methods without

978-1-4673-0700-0/12/$31.00 ©2012 IEEE

impacting the test programs. Having to modify and recompile programs whenever new instruments are changed due to upgrades or obsolescence can be quite cumbersome and time-consuming. To accommodate this, an abstraction layer has been added to the instrument and data handling layers, enabling swapping of compatible instruments and changing data sources, and making the software more scalable and adaptable.

Abstraction is achieved by establishing “contracts” between the blocks. The contracts define the necessary input for each block to perform their function. This approach provided the ability for loose coupling (abstraction) between components; blocks could be changed or replaced as long as the contracts were not broken. Abstraction is also what allows the dynamic loading and execution of test libraries: tests are read in from a test plan file; the test sequencer calls and executes the appropriate method in the test library. Figure 2 shows an example of abstraction: the test library is exposed to the DMM layer, not the actual instrument, so changing meters has no effect on the test library.

Figure 2

IV. DATA In the past, data’s usefulness had not been fully realized.

Data was typically stored as a formatted report in a text file on the local computer. To achieve the data’s potential, a schema was created in a database to represent the data. New ATE programs were designed to upload data directly to the database. Secondly, the creation of a data parser allowed taking existing text files from the legacy systems and port them into the database. These text files did not have a standard look, because each test program tended to format them differently. Configuration files were used to describe the file layout so the parser could process any text file, as long as it contained the necessary data required by the database. Having all data centrally located allowed for universal access and routine archival, opening the door for in-depth analysis and monitoring of product and station performance (Statistical Process Control, SPC).

Another challenge was determining the best method of shuttling data between the sequencer, test libraries, and data

handler. The test libraries create a generic data object for each measurement that it takes. The generic object contains the measurement name, data type, storage destination, and reading. The sequencer accepts this object from the test library and passes it to the data handler to be saved. Since all of the information regarding the data is embedded in the object, the data handler only needs to know the structure of the generic measurement object to upload it to the correct location in the database. The object is also part of a contract so the database or report handling could be modified or replaced without affecting the sequencer or test libraries.

V. AUTOMATION Minimizing operator entry errors was one of the major

objectives in the design of the new ATE software. The first step was to eliminate as much free form entry as possible, and accomplished in several ways: fixtures were designed containing an ID, and read automatically by the software when plugged into the system; the software then queries the database for products it can test based off of this ID. In general, all other user inputs are also validated against the database.

VI. SEQUENCING AND CONTROL The sequencer contains the user interface, engine for

loading and executing test plans, and handles communication between components. Generally speaking, troubleshoot capabilities had been missing in prior ATE software. This is because state information must be retained for each test when performing steps out of sequence.

Examples of out of sequence execution used in troubleshooting are:

• execute a single test • execute block of tests • loop on a single test or block of tests • control fixture from UI

These missing capabilities are important for

troubleshooting a device under test (DUT). In the past, the DUT had to be removed from the auto station and clip leaded to equipment on a bench in order to troubleshoot. This took time gathering equipment and hooking up the DUT. Additionally, correlation between the bench test and the automated test was difficult due to the use of different equipment and cabling. To remedy this, two different modes were created to allow the flexibility of troubleshooting directly on the automated tester: debug and engineering. Debug mode allows the operator to execute a single test, block of tests or loop on tests. Engineering mode contains the same abilities, with the addition of directly controlling the fixture. To accomplish this, an IO class was created that is passed back and forth between the test library and UI allowing either one

control of the fixture. State information is retained. The instrument libraries were created in a similar fashion.

VII. TOOLS AND TECHNOLOGIES

Tools and technologies used in the development of the ATE software were briefly mentioned above. Selection was based on initial cost, availability of support, and flexibility.

Initial cost comparison

• Microsoft Visual Studio Professional $500 • Agilent VEE $1,800 • National Instruments LabView Professional and

TestStand ($4,500 and $4,000)

Visual Studio was chosen as the development environment for several reasons, the primary being cost - it was significantly lower than other comparable products. Another important factor is support - it has a large selection of books and online support available for the development environment and languages: VB, C\#, C++ and Java. And as a plus, all but one of the languages offered in Visual Studio are non-proprietary.

XML was chosen as the format for configuration files for the following reasons:

• human readable • compatible with .NET • is an extendable language

.NET provides the ability to search XML files as though they were a database.

VIII. CONCLUSION

With the new architecture, test programs are standardized both in look and functionality through sharing of a common interface and data and instrument handling routines. Programming time is greatly reduced with the separation of non-test related functions and through the inherent nature of code reuse. Verification and validation time is also reduced since testing is only required on the modified components. New ATE software development can now be measured in weeks versus months. Through its modular design and database/hardware abstraction, the software is highly scalable and flexible. Overall operator time is reduced, either in diminished training or in the ability to troubleshoot on the auto test system. Data is easily accessible from anywhere and can be queried with a multitude of tools, including SPC.

As detailed in this paper, this new ATE development methodology delivers enhanced and robust test software while providing time-savings execution and cost-effective investment.

ACKNOWLEDGMENT

Special thanks to Michele Jarvis and Bob Hook for providing technical reviews of the paper.