From the archives: Fly by wire

      No Comments on From the archives: Fly by wire

Recently I discovered an archive of past work, including a handful of tech features. I guess these come under the heading of ‘vintage’ now, so I figured I’d share them here. In the late 1980s and early 1990s I wrote for a number of computer magazines. I’ve kept very few of the articles, alas, so this is a rare survivor.

This article – headlined ‘Come fly with me’ and the rather unimaginative strapline ‘Computers in Aircraft’ – was originally published in the June 1990 issue of Personal Computer World (PCW) magazine.

This was when magazines really were magazines. I mean, what website now would run a 4,500-word piece? In those pre-Internet days, much of my research was done on online databases, via Telecom Gold. Some of those databases were horrendously expensive: you were billed per minute that you were online – £2 a minute rings a bell. Luckily, the publisher of PCW was paying for the account.

I hacked this out to a deadline so I won’t be held responsible for its accuracy…



It is quite possible that on 26 June 1988 the lives of 133 people were saved by a computer. Yet there are those who would argue that the very same computer may have been responsible for endangering their lives in the first place.

There was nothing particularly special about this group except that they all had one thing in common – they were all on board an Air France Airbus A320 jet airliner as it demonstrated low, slow flight to an audience of awe-struck air show goers at the Mulhouse-Habsheim airfield. That awe was inspired by the airliner dragging itself through the sky in a seemingly suicidal nose-high attitude. But the A320 is good at that sort of thing. As the world’s first fly-by-wire airliner it can achieve feats of aerial posturing that wouldn’t even be considered in other aircraft of its type. The theory is that the on-board computers, which directly control the flying surfaces and engines, will simply not allow the aircraft to stall or crash. Whatever the pilot asks it to do, it will do – up to a point. When things get dangerous, the computers take over.

The plan was to fly by at 100ft above the ground. However, the approach was fast, and the crew – both senior Air France training captains – retarded the throttles to idle setting in an attempt to lose speed. When the aircraft made its fly-by it was down to 30ft. Given the aircraft’s situation – low, slow and the nose being pulled high – the computers would normally have called on a device called alpha floor. This is a protection device aimed at combatting the effects of wind shear – a sudden change in wind speed and direction that can leave aircraft dropping rapidly and panic pilots into heaving back on the stick. It detects a pitch-up motion and, below 200ft, automatically calls for full power. Alpha floor would have kicked in before the aircraft had reached its maximum nose-up attitude, spoiling the display with an untimely application of thrust. So the crew had disengaged alpha floor and had elected to select take-off/go-around (TOGA) power manually.

Yet the awe of the onlookers soon turned to fear and then horror as, instead of climbing away after its pass, the Airbus continued to lose height, descending into the trees of a nearby wood. It began to disintegrate, a wing detached and fuel spilled and burned. Yet the computer system fought to keep the wings level and the nose up, controlling the aircraft’s descent into the trees and softening the impact. This may have contributed significantly to the fact that only three people were killed in the crash (the other factor being a superb cabin crew which evacuated 127 passengers in one minute).

So what went wrong? The official suggestion is that the pilots were slow in going to the TOGA setting. The pilots initially claimed slow engine response when they selected go-around power. The CFM56 engines have an 8-9 second spool-up time from idle to full power. Yet there are suggestions that one or two seconds were added to this because the computer processor controlling the engines was busy doing something else. This isn’t backed up by the official report which says that the flight data recorder – the ‘black box’ – shows a reaction from the engines within half a second of throttle demand, but suspicions remain and they, like many other suspicions about fly-by-wire, are proving hard to shake off.


In a conventional plane, the stick and rudder pedals link directly through a mechanical system of cables, pulleys, rods, levers and bell-cranks to the control surfaces – the ailerons, elevators and rudder. In larger and more sophisticated aircraft, these surfaces are normally hydraulically activated, but the system is still essentially mechanical.

A later version of the Airbus pulls a high-alpha manoeuvre.

In fly-by-wire systems there is no direct link. The control inputs of the pilot are fed into a computer. This sends electrical signals to the hydraulic actuators at the control surfaces. Put like that it sounds like another way of doing the same thing. But the presence of the computer gives designers an opportunity to introduce another element of control, where the computer itself plays an active part in flying the aeroplane.

Perhaps the most visible acknowledgement of the computer’s arrival has been the adoption of the sidestick in the Airbus A320 – and, for that matter, in the General Dynamics F-16 Fighting Falcon jet fighter. In place of the more conventional joystick or control yoke, these aircraft use the kind of small joystick more usually associated with computer games. This is mounted to one side, giving the pilot an unobstructed view of the instrument panel. According to Airbus Industrie’s own literature, at least one senior captain was reluctant to check out on the A320 because he claimed he was lousy at computer games.

Computers have been on board aircraft for a long time. The simple autopilot, which keeps the wings level and the aircraft headed in the right direction, has developed into the flight management system (FMS). The crew programs in the desired route and aircraft data, the FMS works out the best way of achieving it – in some cases selecting the best altitudes for optimum fuel consumption, the best rate of climb and descent, choosing and using navigation aids and beacons from its built-in database, and actually flying the aircraft from just after take-off to just before (even just after) landing. Yet the high level of automation in the cockpit hasn’t been greeted with universal enthusiasm, and is still the subject of some controversy. So it is perhaps predictable that some pilots resent giving up even the possibility of full manual control.

On the Airbus A320, the computer is always there to some extent – you hope. If all five computers fail you have relatively little control over the aircraft – just engine power settings (presuming the separate engine control computers haven’t failed too) and mechanical trim settings on rudder and elevator. The aircraft can be flown and landed this way – Airbus test pilots have proved it – but line crews aren’t trained to do it for real because Airbus is reluctant to admit to the possibility of a complete computer breakdown.


Humans have been flying aircraft for a while now, and are demonstrably good at it. Pilots are proud of their skills and the high standards of their craft. So why hand over the job to a computer?

An F-16 shows off.

The main impetus for the development of fly-by-wire came from the military. In the search for ever more manoeuvrable fighters, air forces wanted jets that were inherently unstable. This sounds dangerous – indeed, in any kind of normal application it is dangerous. Private pilots and airline captains generally want an aircraft that prefers to fly straight and level. Disturb a stable aircraft from this attitude – with a bit of turbulence or control input – and after a few oscillations it will return to straight and level: it actively seeks this state. An unstable aircraft, on the other hand, will suffer oscillations of increasing amplitude until it eventually falls out of the sky. Yet the unstable design does have one distinct advantage: as it isn’t fighting the desire to return to straight and level, it will respond to control inputs very rapidly. It is only too eager to pitch up or down. The problem is that such an aircraft is extremely difficult to fly manually. Any control input is almost certain to lead to pilot induced oscillation (PIO) as the flyer tries to play catch-up with the aircraft’s bucking and dipping. The results would usually be fatal, so a computer, with its sharp responses and analytical abilities is put between the pilot and the aircraft. The pilot indicates what he wants and the computer carries it out. This has led to highly agile machines like the F-16, McDonnell-Douglas F/A-18 Hornet and the Mirage 2000.

And military aircraft may be unstable, or have lousy handling characteristics for reasons other than manoeuvrability. The design of an aircraft may be led by considerations so overwhelmingly important that aerodynamic properties have to take a back seat. Just take a look at the Northrop B-2 bomber or Lockheed F-117A attack plane. These are the infamous stealth aircraft, and their weird – not to say unlikely – shapes are dictated by the desire to present as small a radar signature as possible. As a result, flying qualities suffer – the F-117A isn’t nicknamed the Wobblin’ Goblin for nothing. So both use fly-by-wire systems (in the F-117A’s case borrowed from the F-16) to handle the aircraft and their peculiar aerodynamic properties.

The Wobblin’ Goblin

Getting rid of all those pulleys and cables does mean that fly-by-wire systems are lighter than their mechanical counterparts, and aircraft designers are always interested in saving weight. It means having to stock fewer parts, and fewer mechanical devices to wear out. And digital electronic systems are less prone to catastrophic failure should the aircraft be hit by gunfire or shrapnel, increasing the aeroplane’s survivability.

Airliners don’t need to pull tight loops, out-turn attackers or slip through enemy radar defences. There is nothing to be gained by making the aircraft deliberately unstable – quite the reverse. With safety such a crucial concern in commercial air transport, airliners need to be as stable as possible. So there have to be other reasons for adopting fly-by-wire. These reasons boil down to: fuel efficiency; smoother flight; reduced pilot workload; increased safety; and easier, and thus cheaper, maintenance. Like military aircraft, airliners do also gain from the reduction in weight – it improves carrying capacity and fuel efficiency – and the reduction in mechanical parts.

Maintenance is obviously an important factor. An airliner is a big investment that is recouped only if it is kept flying for most of its life. Downtime for routine or unscheduled maintenance is bad news. Anything which reduces the aircraft’s time on the ground is a major selling feature.

The A320 has a centralised fault display system (CFDS) which acts like an automatic engineer’s log. This is a diagnostic system that records malfunctions during flight, noting the time they occurred, flight phase, cause, symptoms and the part numbers of the units to be replaced. This information can be called up on the display screens or printed out for permanent records. Air France and British Airways are looking at linking the CFDS with a radio communications system – if a fault develops during the flight, the information can be relayed ahead so that the necessary parts are waiting for the aircraft when it lands, reducing the turnaround time.

The greater use of electronics also makes possible more extensive use of line replaceable units (LRUs) – modular system boxes which can be swapped around when a fault occurs. While the aircraft flies with the replacement unit, the faulty box is fixed on the ground. Combined with the diagnostics of the CFDS, these systems have resulted in a very high despatch rate for the A320 – 97-98% of scheduled departures got away without a technical hitch, which is high for a relatively new machine and compares well to older, well-established designs.

Once in the air, the control inputs from the fly-by-wire system are precise – just the exact amount of aileron, rudder or elevator deflection to do the job. Its reactions are faster than a human’s and it can make those movements more frequently. The result is a smoother ride, less stress on the airframe and less drag. This means the aircraft is being flown more efficiently and so burns less fuel – music to the ears of airline managers. Air France has found the Airbus A320 to be 40% more fuel efficient than its Boeing 727s.


One of the reasons fly-by-wire supporters claim safety benefits for their systems is that the pilot cannot exceed the flight envelope of the aircraft. If, for example, a pilot pulls back on the controls, the aircraft increases its angle of attack (alpha) – the angle at which the wing strikes the oncoming air. One of the results of this is that the aircraft will slow down. If the angle of attack is sufficiently great, the airflow across the wing will break up and the aircraft stops flying in what’s known as a stall. Fly-by-wire aircraft won’t let the pilot do this. In an Airbus A320, the pilot can pull the control stick all the way back, an action that could prove fatal in an ordinary aircraft, especially at low altitude. In the A320, however, when the aircraft reaches the edge of its flight envelope, beyond which lies the stall and danger, it quits obeying the control input from the pilot. It will add power and assume the maximum safe angle of attack.

In normal flying regimes this wouldn’t be too important. But in an emergency – severe wind shear or collision avoidance are good examples – some pilots may ask the aircraft to do things it simply isn’t designed to do. Other pilots, only too aware of the dangers of exceeding the limitations of the aircraft, may not use all of the machine’s capabilities. In a fly-by-wire aircraft, however, the pilot knows it is safe to yank those controls around, knowing that the aircraft itself will refuse to go beyond its limitations. This is the basis of the classic Airbus demonstration routine, passing the crowd at low altitude and slow airspeed, with its nose in the air at alpha max. Habsheim proved that the computers don’t always take care of everything.


The computer hardware generally aims to be fault tolerant, usually through the use of multiple redundancy. An aircraft may have four or five complete computer systems, or channels, generally isolated from each other, each capable of doing the job of flying the aircraft. And within each system there may be multiple data paths, subject to constant checks. If something fails, the system automatically reconfigures itself, taking the faulty components out of the loop. A whole channel may be closed down, with another, which had been waiting as ‘hot standby’ instantly assuming the workload. Single faults thus result in a gradual degradation of the system, not a catastrophic failure. The back-up systems rarely sit idle. They are powered up and running. Diagnostic software may poll or compare the different channels as a way of checking the sanity of the channel currently online.

There is always the danger that whatever caused one channel to fail will do the same to whichever channel takes over the job. One way of guarding against this is to use different hardware for the separate channels. GEC, for example, developed a system, aimed at Boeing’s now discontinued 7J7 propfan aircraft, in which three channels were each controlled by a different type of processor programmed in a different language: an Inmos Transputer using Occam; a Motorola 88020 using Ada; and an Intel 80386 programmed in C. To ensure that faults don’t go unnoticed, each system took its turn to act as the main processor at power-up.

The experimental Saab Gripen fighter uses a triplex digital system with a triplex analogue system as back-up. Alas, this didn’t stop the first prototype crashing on its sixth test flight in February 1989 due to a fault in the fly-by-wire system leading to pilot induced oscillation. Further prototypes have since flown successfully.

On the whole, fly-by-wire designers go for proven processors which, even if not perfect, at least have most of their bugs well documented. They are often common or garden Intel and Motorola processors. But there is one school of thought which says that even these are too complex and prone to unexpected problems.

Research at the Royal Signals and Radar Establishment in Malvern led to the creation of Viper Technologies which in turn has produced the Viper 1 and 1A microprocessors. These feature extremely simple architectures with no interrupts. The argument for that approach is that interrupts tend to do their job at the least predictable moments. Without them designers can more rigidly determine what the processor will be doing at any one time. Other special features include special comparison instructions – helpful in ‘sanity’ checks – and a diagnostic register: the processor stops if something goes wrong, and once restarted this register reveals the cause of the fault. The next chip, the Viper 2, is aimed at safety critical applications and is designed to be used with a tested and proven version of the Ada language (de rigeur in US defence contract work). But while bodies such as the Australian National Railways Commission, the Atomic Energy Authority and British Rail have expressed interest in the Viper processors, they have yet to find their way into aircraft.


The Airbus A320 uses more familiar processors. There are five main and two auxiliary computers – two elevator and aileron computers (ELACs) assisted by two flight augmentation computers (FACs) for rudder control, plus three spoiler and elevator computers (SECs). One of the SECs provides roll control only, but any one of the other four main computers is capable of flying the aircraft all by itself.

The ELACs, made by Thomson CSF and based on the Motorola 68000, control roll through the ailerons and pitch through the elevators. The SECs are the work of SFENA/Aerospatiale and use the Intel 80186, controlling the spoilers (used to reduce lift on the wings) and acting as a back-up on the elevators. Each of the five computers uses a command channel and a monitor channel. The two are continuously compared and if they disagree the computer takes itself off-line.

As we all know only too well, even the best computer doesn’t function too well without power. Airliners don’t suffer blackouts, but generator failures are possible. Once again, insurance is offered in the form of multiple redundancy and diversity of systems. On the A320 there are two main generators – one live and one back-up. Should both go down, the electrical systems switch to battery power. And if that doesn’t work, a small fan (or ram air turbine if you want to be fancy about it) unfolds from the side of the fuselage and uses the airflow to generate power.

Although the fly-by-wire system can call for maximum thrust in moments of difficulty, engine thrust setting is essentially a separate system. It’s also computer controlled using a system known as the full authority digital electronic control (FADEC). Its job is to provide optimum power, and the best possible fuel flow, and it forms the auto-thrust part of the autopilot and flight management system.

The aircraft has two main channels, or ‘sides’ – one for the pilot and one for the co-pilot – each with its own ELAC and SEC. The two sides run different software, so there are two programs for the ELACs and two for the SECs – four separate pieces of software in all. Both pilots can use the controls at the same time, and the inputs are algebraically summed. But in the event of a conflict the aircraft follows whoever is deemed to be in control – indicated by red and green lights in the glareshield.

The computer also decides what the pilot needs to know at any time. With the A320, Airbus not only adopted the ‘glass cockpit’, where traditional dials and gauges have been replaced by multi-function CRT displays, but also went for the ‘dark cockpit’. In an ordinary cockpit, all information is available at all times, so long as you look at the right instrument. In a dark cockpit, basic information is always available, but you only see the more obscure stuff if the aircraft needs you to do something about it. This is taken even further in the A320, in that if problems occur during critical flight phases, such as take-off and landing, only the most crucial alarms are shown. Other failures are recorded by the computer, with the pilot being told later.

The hardware has to be pretty robust, with the processors capable of surviving and ignoring momentary power surges. For instance, spikes in the system have caused Air France some headaches on the digital flush control units (FCUs) which activate the high-tech vacuum toilets the airline chose for its machines. A toilet shutdown or overflow might not sound a particularly dangerous problem – messy, perhaps, but not lethal – but it can expensively ground an aeroplane.

Electro-magnetic interference (EMI) is another danger. The US is currently paying to harden the electronics on Israeli F-16s because the broadcasts from a new, 16,500kW Voice of America transmitter in the Negev Desert might interfere with the fly-by-wire systems.

One partial solution to EMI is fly-by-light, replacing wires with optical cables. Messerschmitt-Boelkow-Blohm has flown a BO.105 helicopter using a digital fly-by-light control system for the tail rotor. Although still at an early stage, it has already demonstrated data transmission rates up to ten times that of fly-by-wire systems. And, of course, the system is far less prone to electro-magnetic interference. At one time Boeing was believed to be considering fly-by-light for its forthcoming 777 model, though it may have been dropped now.


It may be the software, more than anything else, that causes people to worry about fly-by-wire. As we’ve already said, computer hardware has been on aircraft for some time in various roles. And multiple redundancy does help to ease fears about equipment failures. But the idea of bugs lurking in the software makes some pilots and designers nervous.

It is generally agreed that there is no such thing as bug-free software. You only have to look at comparatively simple software like word processors and spreadsheets to realise that, however many versions a piece of code might go through, some bugs never go away. And with each new version, new bugs are introduced. Hitting a bug on your PC, in the comfort and safety of your office, may be irritating, but it’s hardly life-threatening. An airliner hitting a bug six miles up in the air is another story.

Part of the problem is that it is hard to test software for faults. Failure rates for hardware can be arrived at statistically after rigorous physical testing. With software it’s hard even to describe what we mean by ‘reliable’. Some bugs appear only under the most unlikely combinations of conditions, hard to predict and perhaps impossible to simulate. In an aircraft system, for example, everything may work perfectly in all normal flying regimes but the software may be unable to deal with certain types of damage.

There is also concern that programmers lack the disciplines necessary for safety-critical work. Other, more traditional forms of engineering constantly stress safety during training. Your average C hacker doesn’t have this background.

Even putting safety considerations aside, there are good reasons for wanting the software to be right. Developing the software can be an expensive business. It has been estimated that half of the costs of the European Fighter Aircraft project will be spent on software development. And it may be that money is part of the solution. If you are prepared to spend enough on the software, you should be able to get it to the point where the probability of failure is sufficiently remote.

There is already a practical example of this in the form of the world’s most famous fly-by-wire machine – the US Space Shuttle. The most complex machine ever built by mankind, a thing of awesome grace and power as it ascends to the heavens on millions of pounds of thrust, when it re-enters the atmosphere for landings the Shuttle reverts to being a glider with the aerodynamic properties of an oven-ready turkey. Not unnaturally the designers opted for a fly-by-wire system: indeed, the whole flight process from take-off to landing and post-flight checks is automated and the pilots need do little except monitor the instruments. The computers control the various kinds of engine and the software provides guidance, navigation and monitoring of onboard systems including life support.

What is perhaps amazing for such a state-of-the-art vehicle is that the five computers on board are none other than IBM 360s, each with a miserly 104K of 32-bit word memory. This made sense back in the 1970s when the Shuttle project was born. The choice also makes sense from the point of view of the processor being very familiar. This may have contributed to the astonishingly low software error rate of 0.11 per thousand lines of code for the 500,000 lines of the flight software – about 100 times better than the industry average. Another factor could be NASA’s willingness to spend around $1000 per line which allowed IBM’s programmers, using the PL/1-like HAL/S language, to allocate the time to getting things right. At times, up to seven different versions of the software were being developed. The programmers also created around two million lines of code on Shuttle-specific software tools, with an error rate of 0.4 per thousand lines, and in the first operating period of 1981-1985 made some 4000 changes to the flight code.

The A320 software uses N-version programming techniques to ensure safety. This is where different programs, doing the same job but designed, written, tested and maintained by completely separate teams, run concurrently. The programs use majority voting and program-output comparisons to check for errors. But the theory is that the two software teams won’t have made the same mistakes. Opponents of this approach argue that all programmers share certain design philosophies, and that common errors in separately-designed programs are not only possible but likely. Airbus Industrie’s response to this is something along the lines of ‘so far so good’. To date not one accident has been caused as the result of a software problem on the A320.

Although fly-by-wire has had over a decade of service in military aviation, it’s hard to use that experience when judging safety. Standards in the military are different from those that must be adopted in commercial aviation. While designers and manufacturers build in as many safety margins as possible, performance is more important than reliability. After all, fighter pilots always have the option of banging out in an ejection seat, a course of action not generally available to passengers on airliners.

One important consideration is the erosion of crew skills. If pilots come to depend on computers, they may lose the skills necessary to deal with emergencies. Many people owe their lives to the expert flying of crews like those who nursed a crippled Boeing 737 back to Hawaii when the top of the fuselage ripped open.

Already, advanced flight management systems are causing disquiet. Below 10,000 feet, when they’re busy on the approach to an airport, crews often spend much of their time with their heads down, punching numbers into computers. This has led to what pundits have called the ‘I can’t fly anymore but I can type 80 words a minute’ syndrome. When automatic systems fail, pilots may be reluctant to override them (presuming they have the option), or they simply may not know how to. And reliance on automated flying can lead to reduced vigilance. Widespread introduction of fly-by-wire will only amplify these concerns. It may be that it’s not just the aircraft manufacturing industry that needs to allay these fears – the computer industry may have its part to play, too.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.