PXI snags savings with HIL test

By Richard Quinnell, Contributing Technical Editor -- Test & Measurement World, 9/1/2010 12:00:00 AM

Greg Sussman Automation Systems Consultant Process Automation

Arrestor systems on aircraft carriers can help planes that are damaged or have mechanical issues come to a safe landing. Testing such systems without endangering plane and pilot, however, requires a specialized facility. The design team at Process Automation used PXI to create an HIL (hardware-in-the-loop) tester to minimize the time needed to test an arrestor control system. I spoke with automation systems consultant Greg Sussman to learn more about the application.

Q: What is an aircraft arrestor?
A: The arrestor is used on military land-based runways to provide braking assistance for a safe and controlled stop during landings. A hook on the aircraft catches a cable that crosses the runway. On both ends of the cable are about 1200 ft of heavy nylon mesh tape wound onto reels that have disc brakes under the control of an embedded control system. The system measures the aircraft's speed and determines its response to the applied braking so it can compensate for the differences in mass of various aircraft and apply an appropriate braking algorithm for a controlled deceleration.

Q: What was Process Automation's role in the development of this system?
A: The system's vendor, Zodiac Aerospace, called us to design a replacement for the system's electronic controls, which were based on components that had gone out of production. The new system design used the National Instruments Compact­RIO hardware platform.

Q: What was the role of PXI?
A: We used PXI as the platform for an HIL test system during debug of the control system and software. The tester provided a real-time simulation that emulated the physical plant's response to the controller. The tester looked like the real hardware to the controller and contained a model of both the system and the aircraft physics during a landing. If, for instance, the controller sent a command to change the disc brake control valve setting, the tester would read the signal from the controller and then return signals from the virtual physical plant showing how it and the aircraft responded. We could simulate normal operation for various aircraft and landing scenarios and also simulate a defined set of failure conditions to make sure the controller design was right before committing to field test.

Q: What was the advantage of using this approach?
A: Obviously, it is too risky to debug a system on real aircraft landings, but there is a test facility that uses jet sleds to accelerate a dead load sized to simulate various aircraft and landing speeds. Scheduling time at the facility, however, requires long lead times, and test time is expensive—$50,000 a day—so it made sense to minimize the facility test time by wringing out the design as much as possible ahead of time. With the tester, we reduced our facility use to five days for the new design from the 20 days that were needed for the prior design.

Q: Why use PXI?
A: Other platforms would have needed custom hardware, external PCs for the user interface, and external racks of equipment. With PXI, we were able to put everything into a single, four-slot chassis for less than half the cost and with less risk than VME or VXI. A multicore controller with NI's Hypervisor let us run Windows on one core for the user interface and VxWorks on the other three cores for the real-time simulation. An FPGA board provided custom signals as well as analog I/O for the control interface.

Q: Any recommendations for other HIL test developers using PXI?
A: A good system model is the cornerstone of HIL testing. If the model is not accurate, then your testing is flawed from the outset. Tools like NI's System Identification Toolkit can help you develop that model for a PXI system.