杏吧原创

COCKPIT displays plunged into darkness, engines that throttle back during take-off and contradictory airspeed readings are just some of the problems caused in recent years by inexplicable failures in the software that controls aircraft.

So far there are no known cases of such failures alone causing an accident. Speculation that software problems led to the crash landing of the British Airways Boeing 777 at Heathrow airport, London, on 17 January remain unconfirmed. While software was implicated in the Korean Air jumbo jet in August 1997 on Guam, which killed 228 people, human error, not software design, was to blame. Software failures remain a risk, though, and with aircraft makers set to increase the proportion of aircraft functions controlled by software, experts are warning that they will become more frequent, increasing the chance that one will cause an accident.

In early aircraft, moving parts such as the rudder and wing flaps were linked to controls in the cockpit either by a system of cables and pulleys or by hydraulics. In the 1970s, aircraft makers realised they could get rid of much of this heavy equipment and replace it with lightweight wiring and systems driven by electric motors in the wings and tail. Such 鈥渇ly-by-wire鈥� (FBW) systems vastly increased fuel efficiency.

FBW had another advantage too: because it uses electrical signals, for the first time it allowed a computer to be placed between the pilot and the moving parts. The computers were programmed to modify the pilots鈥� instructions in certain instances: for example, to stop them moving the rudder too far or too quickly and so damage the plane. They also allowed the plane鈥檚 aerodynamics to be finely adjusted during flight in response to wind conditions, further improving fuel economy.

But the addition of software led to different problems. Some of these are documented in a . It lists a number of instances in which software bugs caused frightening problems during flight. In one instance in August 2005, a computer in a Boeing 777 presented the pilot with of airspeed. It said the aircraft was going so fast it could be torn apart and at the same time that the plane was flying so slowly it would fail to generate enough lift to stay in the air. The pilots managed to control the aircraft nonetheless, but it was a stark illustration of what can go wrong.

In another instance in 2005, this time in an Airbus 319, the pilots鈥� computerised flight and navigation displays as well as the autopilot, auto-throttle and radio . Another time, what the NAS calls 鈥渇aulty logic in the software鈥� meant that when the , the back-up systems were not turned on.

鈥淭he pilots鈥� displays, autopilot, auto-throttle and radio all lost power for 2 minutes鈥�

Now Boeing is planning to get rid of the hydraulic wheel brakes on its 787 in favour of lighter electrically actuated ones and to from using pneumatic engine starters and wing de-icers to electrical ones. Airbus will also be adopting a 鈥渕ore electric鈥� approach in its forthcoming A350, says the plane鈥檚 marketing director. 鈥淭he addition of more electric systems will mean even more computer control,鈥� says Martyn Thomas, a systems engineering consultant based in Bath, UK, and a member of the NAS panel that produced the software report last year. 鈥淚t will mean more wires or shared data lines and so still more possibilities for errors to arise.鈥�

But Boeing disagrees. 鈥淔light critical software and systems are isolated from the other systems, so the addition of electric systems doesn鈥檛 add complexity to the separate fly-by-wire flight control system,鈥� says a senior avionics engineer at Boeing鈥檚 Everett, Washington plant.

The software used to control additional electric systems may not be in the same package as the flight control system, but they still add to the overall amount of software that needs writing and verifying as safe for flight. And that has independent experts like Thomas worried.

Why do software bugs arise and why can鈥檛 they be removed? Bugs are sections of code that start doing something different to what the programmer intended, usually when the code has to deal with circumstances the programmer didn鈥檛 anticipate. All software is susceptible to bugs, so it must be tested under as many different circumstances as possible. Ideally, the bugs get discovered at this time and are removed before the software is actually used. This is very difficult in complex systems like aircraft because the number of possible scenarios 鈥� such as different combinations of air densities, engine temperatures and specific aerodynamics 鈥� is huge.

To test for bugs, most aircraft manufacturers use a set of guidelines called the standard, which was created by the US-based Radio Technical Commission for Aeronautics, a collection of government, industry and academic organisations, and the European Organisation for Civil Aviation Equipment. Recognised by the US Federal Aviation Administration (FAA), the standard rates software on how seriously it would compromise safety were it to fail, and then recommends different levels of testing depending on that rating. The most rigorous 鈥渓evel A鈥� test, reserved for software whose failure would cause a catastrophic event, is called 鈥渕odified condition/decision coverage鈥� (MCDC), and it places the software in as many situations as possible to see if it crashes or produces anomalous output.

But it isn鈥檛 clear whether the MCDC test includes enough different conditions to provide any greater protection than the level B tests done on less safety-critical software. So in 2003, UK Ministry of Defence contractor Qinetiq ran both levels on a range of software that is deployed in military transport aircraft. The MCDC should pick out many more flaws than the level B tests, but the Qinetiq team found that there was 鈥渘o significant difference鈥� between them. 鈥淢CDC testing is not removing any significant numbers of bugs,鈥� says Thomas. 鈥淚t highlights the fact that testing is a completely hopeless way of showing that software does not contain errors.鈥�

鈥淭he criteria currently used to evaluate the dependability of electronic systems for many safety-related uses are way too weak, way insufficient,鈥� says Peter Ladkin, a computer scientist specialising in safety engineering at the University of Bielefeld in Germany.

Instead of focusing on testing, Ladkin and Thomas want to see a change in the way safety-critical software is written. Neither Boeing nor Airbus responded to questions about exactly which programming languages their software systems are written in, but according to Les Dorr, spokesman for the FAA, which certifies US commercial software systems, it is a mixture of the languages C, C++, assembler and Ada, which was developed by the Pentagon. Some of those languages, such as C, allow programmers to write vague or ambiguous code, says Thomas, which is the kind of thing that often leads to bugs.

To solve this problem, he suggests using highly specialised computer languages that do not allow ambiguous software specifications to be written, and which mathematically verify software as the programmer is coding. Such languages include the B-Method, pioneered for use on computer-controlled sections of the Paris Metro, and SPARK, a version of Ada. These so-called 鈥渟trongly-typed鈥� languages and their compiler software have strict controls within them that make it very difficult for programmers to write vague or ambiguous code.

The NAS report also backs stricter controls on languages. 鈥淪afe programming languages鈥� are likely to reduce the cost and difficulty of producing dependable software,鈥� it says.

The FAA agrees that an increase in the software control of planes 鈥渕akes validation and verification of software more challenging鈥� and is working to ensure that validation keeps pace with technical advances. But Thomas says their progress is too slow. 鈥淗ow long are we prepared to go on using tools we know are broken to develop software on which people鈥檚 lives depend? No other engineering discipline would rely on tools that have dangerous faults.鈥�

Aviation 鈥� Learn more in our comprehensive .