Control at the frontier

Graphical programming has shown itself to be capable of solving some of the most intractable problems in engineering – designing safety critical systems that are supposed to keep functioning despite intermittent faults and ensuring that novel systems work where there is no chance of maintenance or repair. Such tasks can be greatly eased by running crucial algorithms on field programmable gate arrays (FPGA), eliminating potential problems with operating systems, enhancing computation speed and reducing loop time. A system that tests systems that must cope with intermittent faults was described by Richard Furey of Averna UK at National Instrument's Military/Aerospace Solutions Conference. Averna was tasked to deliver a testing system for aircraft brake control units. The system would be used to validate new software and to test pre-production brake control units (BCUs) without the brake unit having to be present. With only slight modification, the system would then be available to test production BCUs. Inputs from the brake pedal LVDT position sensor and speed and temperature sensors have to be simulated and used to produce appropriate signals for the hydraulic valve control. Furey spoke of using an FPGA to simulate the inputs from wheel sensors for testing BCUs and another chip to simulate the hardware in the loop for software validation. Wheel speed sensor input is updated every 500µs. In addition to applying pressure to the wheel brakes, the BCU has two additional tasks. One is to release the brakes if the aircraft bounces up, so the wheels are not locked when it comes back into contact with the runway. The other is to keep the system running, even when sensors suffer intermittent faults. A system shut down caused by sensor malfunction would be totally unacceptable while an aircraft was braking during landing. Motorists know how difficult it is to track down intermittent sensor faults, but these usually just stop the car from going. Sensor faults in aircraft, including intermittent ones, can be much more serious, and, despite dual and triple redundancies, do happen. Control algorithms have to be devised to keep things going based on last good information, no matter what happens, and the best approach to testing them is to simulate every possible kind of malfunction and combination of malfunctions. Failures in robotic planet landers are even more problematic because of the impossibility of providing maintenance. US company Advanced Technology Associates (ATA) is working with solid fuel rocket expert Alliant Techsystems (ATK) on a solid fuel rocket system for a Mars lander that can be throttled. The system may reduce the lander's weight by 10% and the space required by 20% while reducing complexity by a 'considerable amount' relative to a liquid fuel system. According to Chris Scruggs, ATA's Aerospace Toolkit product manager: "ATK has worked on a generator which stores the gas from a solid rocket." The gas is stored at high pressure and can be vented 'in equal and opposite directions'. The key technology is a patent pending pintle valve that operates under what Scruggs described as 'tremendous pressure'. However, the valve can be controlled 'very accurately' and operates in 'microseconds'. A live firing test – described as 'quarter scale' in that it consisted of one real rocket and three simulated gas generators – has been conducted at JPL. Since getting to Mars is costly and any kind of malfunction will result in complete loss of the probe, rigorous simulation is essential and ATA has developed the guidance and navigation scheme used during the descent and landing on the Martian surface, the software to control the engines, dynamic vehicle simulation and integrated the hardware into the test system. Scruggs says a software in the loop test system was created using a PC running NI LabView and the ATA Aerospace toolkit. LabView was also used to create the overall simulation framework and the graphical user interface for all phases of the project. LabView's graphical user interface makes changing simulations relatively easy, useful in this instance as Scruggs said: "At one point, we were going to Mars, then we were going to the Moon, and then we were back to Mars again." Tim Fountain, market development manager, military and aerospace with NI said: "We are really working on LabView FPGA. The vision that we have is to take the system all the way from LabView code to the pin of the FPGA. There won't then be any operating system or drivers in the way, so we get much greater reliability and performance. It's almost like programming chips at machine code level – but with graphical code going directly to the hardware on the chip." When we asked about real world applications, Fountain mentioned a US company that is developing what he described as a 'biometric radar', in which magnetic resonance imaging is used to find who or what might be behind a wall. The system, being developed for the US Department of Homeland Security, uses a FlexRIO adapter and FPGA chips to do all the fast Fourier transformations and cross correlation calculations necessary to produce useful results in real time. Other recent developments include the ability to extend the physical range of the PCI Express databus, currently limited to a maximum range of 7m using cable, to 200m using optical fibre. Fountain said the most common working length was for PCI Express was 3m, but noted that 200m would be 'very useful' when testing live ordnance. Meanwhile, PXI is being used for sound mapping supersonic missiles at the White Sands missile range. VXI databuses and LabView are also being used for flight test evaluation and simulation, assisted by the use of Ethernet fieldbuses on aircraft, particularly AFDX, which is used on the Airbus A380 and the Boeing 787. Is LabView easy to use? We did take the opportunity at National Instruments' Hendon event to see whether LabView was as easy to use as claimed. While a thermometer was made to work using CompactRIO and a motor controller made to work using an FPGA chip, we wouldn't say it was 'easy'. However, the motor driver made extensive use of potted subroutines and wizards and an advantage of graphical programming, especially in the hands of a Eureka editor, is the ease with which faults can be found and rectified. Pointers * Simulation and testing in aerospace is even more crucial than it is for other applications * Graphical programming enables different schemes to be quickly put together and for designs to be quickly amended * While it is moderately hard to use, it is easier to use than hand programming and permits easier location and correction of mistakes * Direct programming of FPGA chips eliminates possible problems with operating systems and enables much faster algorithm cycle times