Characterization of the Next Generation Aircraft Fuel Pump Using LabVIEW, PXI, and SCXI

Author(s):
Ben Rayner - Data Science Automation

Industry:
Aerospace/Avionics

Products:
LabVIEW, PXI/CompactPCI,

The Challenge:
Developing an automated data acquisition and test system that incorporates jet-engine simulation to characterize a developmental Ultra-Efficient Fuel Delivery System (UEFDS).

The Solution:
Using LabVIEW Real-Time, we developed code to control the four outputs and a LabVIEW application for a Windows 2000 system that displays and logs all 100 analog input channels of data at 1000 samples per second along with at least 30 information channels received from the electronic control module (ECM) via RS-485.

Introduction
To test this unique fuel pump, we had to design, develop, and demonstrate a test system. The system had to dynamically simulate the behavior of a jet engine flying through a range of operating conditions as described by altitude, speed (mach-number), and throttle position (power lever angle). Of the more than 100 channels of data we needed to monitor and log, the control logic required 12 channels to determine the control of the four outputs, including the pump drive speed, fuel heat exchanger valve position, back pressure valve position, and actuation flow valve position.

We used two National Instruments PXI systems to control and monitor the UEFDS test cell. The four PID control loops on the real-time system along with the engine simulation model execute 100 times per second and read 12 input channels, which sample by 10X. The real-time system controls three valves and the pump drive speed. With the LabVIEW Windows application on the second PXI system, the user can monitor and log all 100 channels of data collected at 1,000 samples per second through the SCXI DAQ system, the 30 parameters collected on the RS-485 network connected to the unit under test, and the UDP status messages from the real-time system.

Deterministic Control
The LabVIEW Real-Time system monitors the12 critical channels, also at 1,000 samples per second. We used 5B series modules for signal conditioning of these signals. The system buffers data from these channels and averages 100 times per second. A hardware timed loop executes 100 times per second, calculating and updating the four outputs. LabVIEW calculates the math necessary for the simulation, which contains four PID loops, nine rate limiters, a derivative, and 12 look-up tables.

Global variables monitor interim values during the refinement phase and pass data to a second loop. The second loop executes 100 times a second and passes critical information to the fuel pump across the same RS-485 network that the Windows system uses to monitor the status of the fuel pump. The system also contains a simulate mode so the application can run on a regular PC for testing and development without a real-time system or data acquisition hardware.

PID Control
Ensuring the PID control worked reliably and fast was a challenge. Without over-sampling, the bit-noise in the analog inputs made the derivative unusable. The automatic calculation of the delta-t in the PID VIs also caused problems. Although there was no hardware jitter, a software jitter of 1 ms could cause a 10 percent change in delta-t at our loop-rate of 100 Hz. Oversampling 10X and explicitly providing the delta-t helped stabilize the system transient response, although the noise on the signal still complicated use of the derivative term.

RS-485 Communication
Communication with the ECM also posed significant challenges. The data generated by the unit under test was too much for the real-time system to analyze and log, yet we needed to send the commands to the unit deterministically. We implemented a RS-485 network, enabling the real-time system to write commands to the ECM while the Windows system reads the responses and logs the unique data. Because the test article was a one-of-a-kind developmental system, members of the support team from three different companies developed wiring and naming conventions. Once we negotiated the protocol conventions, the RS-485 proved quite robust. Even at the wrong baud-rate and the wrong polarity, we still received data.

Data Management
The system generated enormous amounts of data in response to manual triggers. It buffered 30 seconds of data from all channels to store or display pretrigger binary data at anytime during transient events. "Snapshots" provided a more manageable data storage mechanism for steady-state conditions, in which the system averaged data during a configurable time interval. Utilities took multiple logs or snapshots and converted them to the ASCII format.

Conclusion
With the powerful features of the Measurement & Automation Explorer, we could test and calibrate each channel independently without customized software. We significantly reduced hardware problems resulting from software problems. With the rapid development capabilities of LabVIEW and the robustness of the PXI system, we created a reliable system in a very short time. The powerful testing and debugging capabilities of LabVIEW Real-Time assured we made our deadline.

For more information, contact:

 Ben Rayner or Gregory Cala

Project Consultants

Data Science Automation

400 Southpointe Blvd., Suite 210

Canonsburg, Pennsylvania 15317

Tel: 724/745-8400

E-Mail: gcc@DSAutomation.com

Browse All Case Studies »