Academic Company Events NI Developer Zone Support Solutions Products & Services Contact NI MyNI

Customer Solutions

LabVIEW Enhances Flight Hardware Acceptance Test

Author(s):

Jerry Olup, Lockheed Martin

Industry:

Aerospace/Avionics

Product:

LabVIEW

The Challenge:

Reducing time and cost of flight hardware checkout tests from one week to under an hour. Automation used to increase reliability and data gathering capability of test procedure.

The Solution:

Remove the human-in-the-loop of the test sequence by integrating the electronics command interface, test console data collection method and data analysis technique in one test executive.


Abstract
Previous acceptance testing of flight hardware involved manually running four programs concurrently while simultaneously hand-recording measurements. This provided a disjointed and time-consuming acceptance test procedure, prone to many problems, both human and electronic. LabVIEW was used to automate the test sequence, reducing one week of test to under an hour. OLE was used in this effort to integrate the test flow with test procedure documentation, maintaining synchronization of the procedure with documentation and variable changes. OLE automation was further used as the interface to special test HW.

System Overview
The Unit Under Test (UUT) performs inertial navigation using a MIPS family avionics computer and x86 family telemetry computer.  Serial interfaces to the UUT communicate with the system test console for telemetry decommunication and system control in the test environment. The drivers /API section were full applications that are integrated into LabVIEW through system calls or the use of OLE. Two test sequences, package checkout and rechannelization, are automated using LabVIEW. The package checkout test verifies that the avionics computer and all packages attached to the system meet basic interconnectivity, power dissipation and basic functionality. The rechannelization test verifies telemetry computer functionality in organizing varying frames of data, requiring verification by comparison of over 2000 words per test.

The following goals were achieved through heavily automating both test sequences:

  • Automate control of hardware interface SW to remove complex operator manipulations.
  • Harvest parameters from Excel files to improve accuracy in translation and interpretation.
  • Automate documentation of test results for speed and accuracy.
  • Replace operator fault detection with SW to improve system monitoring capability.


The old test method is briefly reviewed followed by the automated procedures.

System Overview - Old Test Scenario
As mentioned, manual data collection and analysis was used with obvious inefficiency. More importantly, there was also slower reaction to system faults, as out of tolerance conditions had to be detected by the operator. Overall, the operator would manage four applications in similitude, recording and monitoring hundreds of values by hand. The avionics computer interface was accomplished through a DOS (terminal) application, commands to the telemetry computer were achieved through the menu driven download application. The decom board received the PCM data stream, parsed it according to the operator’s settings, and permitted continuous monitoring of all system variables through the decom application. Minimal automation was used to control the GPIB test equipment, which consists of a DMM and RF section.

System Evolution Through Automation
To automate the test sequencing, several interfaces to LabVIEW were established:

  • OLE automation server interface to the decom application functions.
  • OLE automation server interface to the download application functions.
  • Parameter passing interface to the DOS application.
  • VBA integrated development environment (IDE) automation server interface to Excel for data IO.


The decom board was provided an OLE server interface to the decom card and was made fully controllable using the LabVIEW 4.x OLE interface VIs. Each VI shown uses the LabVIEW 4.x OLE interface to invoke methods and properties within the decom automation server. The integration of this VI saves the operator from invoking the data collection function manually on the proper telemetry channel (‘channel’ in the array select pulldown). At least two ( to ensure proper telemetry sync) major frames are collected from the telemetry stream (sequence ‘1’) and passed from the decom card control VI to the data parsing and collection functions. After the data collection is complete the application is either closed and the automation reference number is released or the automation number is passed to the next time the decom card is used.
The download program is used to interface with the telemetry computer and commands the system into test mode. Clusters were determined through trial and error to correctly map the passing of two hex values to the download program. This program was originally controlled through sequences of commands passed by manually sequencing a series of pulldown menu driven decisions.

The DOS application was modified to be integrated in LabVIEW by using argument passing to main() with argv[], argc[]. Argument passing, incorporated into the program, allowed the terminal application to be integrated into the automation sequence (using argument passing). Upon conclusion, the program releases the serial port and closes. These three programs, combined with a moderate amount of 488 instrumentation, form the foundation of interfacing to the UUT.

Variables used for the test procedures change each time the test is run. To inoculate the test procedure against variation of these revisions, the released documentation is harvested for test parameters immediately prior to test. This is achieved by calling Excel using the automation server, which initializes global variables used in the test process. The operator gathers scaling factors applied against all sensors used in the package checkout test. A similar program is used to gather channelization constants for the rechannelization test.
These programs are integrated into the two test executives, explained next.

Test System Integration
Each VI  gathers data, scales the data, compares it to threshold values presents go/no-go values that provide controlled power down in event of failure and provides storage of results for the final test report in the "start file path" VI. The rechannelization test sequence is not as complicated as package checkout, but provides the most savings, reducing channelization test time from 20 hours to a few minutes.

Summary
OLE was used as the key to significant benefits, providing both unique hardware integration in the decom card server and test plan automation and documentation, in the Excel interface. Using extensive and unique automation methods, otherwise unattainable goals were realized in cost savings and accuracy of package level tests.

View the PDF
olup.pdf

View the entire user solution in Adobe Acrobat PDF format.