Customer Solutions

Using LabVIEW for Automated Testing of Airborne Test Equipment

Author(s):

Chris Koehler, G Systems, Inc.

Industry:

Aerospace/Avionics

Product:

LabVIEW, NI TestStand

The Challenge:

Replacing non-Y2K compliant C-based automated test controllers with new MacOS based controllers and integrate with a new database. Creating reusable code and a program architecture that allows for new tests to easily be added by company engineers.

The Solution:

Improving test speed by converting C code into LabVIEW code and using Test Executive to create a flexible program architecture. Using Apple Scripts from LabVIEW to communicate with the FileMaker Pro database.

Introduction
In the process of updating their Automated Test Controllers, the customer desired to move from a paper-based tracking system to a database system using FileMaker Pro 5 on the Macintosh operating system. The new database keeps track of all equipment that passes through the laboratory for testing and has no size limitation. Maintaining, archiving, searching, and accessing records for any piece of equipment becomes much easier in this new system. All testing specifications and results are also stored in this database developed by StepUp Software, Inc. To correct for the problem of year 2000 compliance and to allow for direct access to the specifications and results in the database, it became necessary to rewrite the automated test code. In their original state, the computers and programs would no longer function after January 1, 2000 and would be difficult to modify to work with a new database structure. Since the code already needed to be rewritten for these reasons, it was an opportunity to rewrite it in an easier to use format- both in terms of the user interface and the maintainability. Replacing the text-based application with the modern tools of LabVIEW and the Mac OS would make the task much easier.

Testing Hardware
The Automated Test Controller test benches contain generic electronics test equipment for evaluating airborne signal conditioning modules and a Mac computer to run the automated test software. The equipment list includes power supplies to power the units under test, a DC Source to apply an input signal, a multimeter to measure output signals, a gain-phase analyzer to measure frequency response and other commonly used test equipment. The computer is rack-mounted in a rugged case in the equipment rack. The computer was fitted with a National Instruments PCI-GPIB TNT 4882C card for instrument communication.

Each signal-conditioning module is a unique combination of amplification, inversion, and filtering. Most are single channel devices, but some are ten channel devices. The Acceptance Test Procedure (ATP) tests performed typically involve injecting an input signal, reading the output signal and verifying that it matches the expected output within a specified tolerance. In order for a module to pass the ATP, it needs to pass a battery of tests performed in sequence without any failures.

Testing Software
The new software replaces a program written in C that ran on an HP9000 platform. The new software runs on the Mac OS and reproduces the exact same functionality with a few exceptions. These exceptions include any bug fixes, inefficient code that could be replaced or dead code that could be removed completely. The major exception was the introduction of a new piece of equipment for making frequency response measurements. Previously, an AC Source and digital multimeter were used to make a limited number of frequency response measurements and it required up to eight hours to perform the required tests at low frequencies. The reliability of this method was in question, particularly for the low frequency measurements, so a new instrument, known as a gain-phase analyzer, was introduced. Introduction of this instrument reduced test time to about 45 minutes at low frequencies and even less at higher frequencies. The old test software could not be translated directly, so a new test had to be developed. Other than these differences, the test code performs exactly the same way.

We chose LabVIEW as the development system. It was the ideal choice considering the need for instrument control, data acquisition, and code maintainability. We also chose to use Test Executive as an environment within LabVIEW for running sequences of tests since Test Stand is not currently available for the Mac OS. Test Executive allowed us to build a flexible program architecture that easily allowed for new tests to be added without having to recompile code every time a new test is added. This feature is obtained since Test Executive dynamically loads all of its test VIs. The test VIs are stored on a server and loaded dynamically by the application residing on one of the three Automated Test Controllers. Source code control is greatly improved by this approach since all the source code is maintained in a single, central location. Engineers may use the existing test VIs as templates to create new tests that can be run without ever needing to rebuild the application. Each test bench computer only needs to have the Test Executive and FileMaker Pro applications installed on it.

The LabVIEW development system need only be installed in one location for developing new test code. The test code is stored on a server for access from any computer connected to it. The FileMaker Pro database resides on a separate server since it contains many other databases and is accessed by many other users. Currently the software only tests a subset of the modules that pass through the lab, but given the flexibility of this approach, new tests will be added in the future.

User Interface
The technician who will perform an automated test on a module begins in the FileMaker Pro application. After logging in and finding the record for the module to be tested, the technician will push a button to launch the Test Executive application. Thus, the testing software is always accessed through FileMaker Pro. Once Test Executive is started, it will read the specifications from the open record in FileMaker Pro and then choose the appropriate test sequences to load. It will automatically begin the pre-test sequence, which initializes the test equipment and checks that it is in calibration and functioning properly.

If the pre-test sequence passes, the user will be prompted to run the Full QAC test. If it fails, program control will return to FileMaker. After the pre-test sequence finishes, the user may run the Full QAC test or a single step in the sequence. All test steps within a sequence pop up as a small dialog box until the step is finished. For test steps that last longer than a few seconds, the dialog box will have an ‘abort’ and a ‘view intermediate data’ button. If the Full QAC passes, the results are automatically saved to the database, if it fails, the user is given the option to save or discard the results. By making use of Test Executive's built in features, the user has more ability to troubleshoot a failed test than previously available, such as running a single test step in a sequence or looping on a test step.

Benefits
The test system not only created a flexible environment for adding new tests, but also improved the testing procedure itself. Test times and the likelihood of errors were reduced due to further automation. The learning curve for the new user was shortened by replacing the existing text interface with an intuitive graphical user interface.

Conclusion
LabVIEW and Test Executive fit well into the new model for testing and tracking with the FileMaker Pro Database. The new system is faster and easier to use. It features an expandable architecture for adding new tests and a simple scheme for source code maintenance. LabVIEW's ability to communicate with FileMaker Pro in addition to performing standard instrument control made it the perfect choice for modernizing this automated test station.

koehler.pdf

View the entire user solution in Adobe Acrobat PDF format.