How dissimilar are redundant flight control computers?

Question

Facts

On Airbus aircraft there are computers to secure the flight envelope, or to move the control surfaces. FADECs totally control the engines. Computers take decisions in place of the pilots, or even against their commands. Boeing aircraft have similar computers, even if the crew has more authority.

^{A330 electronic bay, source, photo by 'swiss_a320'}

Safety implications

Being critical, systems are redundant and supervise each other to detect possible failures and isolate failed components. However a computer can still be developed from faulty specifications, or be wrongly manufactured, and a program can contains bugs. If the same defect is present on all computers on the production line, the purpose of redundancy may be defeated, as they wouldn't be able to detect erroneous behavior.

This is better stated in this article:

Because of the severe consequences resulting from a single point of failure, hardware redundancy is critical in DAL A systems. But if the aircraft uses a redundant architecture built with similar channels, that system will still be susceptible to common mode failures that can cause all channels to fail in the same way.

Question

What are the principles used in aviation to reduce the possibility for redundant computers to fail or to make the same errors at the same time?

Answer 1

As far as Airbus is concerned:

1. Each unit is composed of two dissimilar boards, one driving the output and the other checking it. Dissimilar means both different CPUs and chipsets (A320 uses i386 (Intel) and m68k (Motorola); newer models use different combinations, basically whatever was widely used at the time they were designed) and software written by two independent teams.

2. There are fail-overs, two or three depending on the system (IIRC the unit reading the side-sticks is the only one with four copies).

3. The two main axes, pitch and roll, are controlled by two different systems. ELAC controls elevator and ailerons, SEC controls horizontal stabilizer and spoilers. This is two completely independent chains including different actual control surfaces except for the side-sticks.

4. A320 has (hydro)mechanical backup for pitch via the trim wheel and yaw via the pedals, utilizing yaw-roll coupling for roll. This works even with complete electrical failure. IIRC the backups on newer models don't though (because complete electrical failure has never happened).

Answer 2

Redundancy is not only achieved by multiplying the computers, but also by diversifying them. On Airbus airliners, two different computers are used (one with Intel chips, the other with Motorola chips in case of the A320) and software is written twice, one for control, the other for monitoring, by two teams which are not allowed to interact.

To cite from chapter 12 of The Avionics Handbook:

Despite the nonrecurring costs induced by dissimilarity, it is fundamental that the five computers all be of different natures to avoid common mode failures. These failures could lead to the total loss of the electrical flight control system. Consequently, two types of computers may be distinguished:

2 ELAC (elevator and aileron computers) and 3 SEC (spoiler and elevator computers) on A320/A321 and,

3 FCPC (flight control primary computers) and 2 FCSC (flight control secondary computers) on A330/A340.

Taking the 320 as an example, the ELACs are produced by Thomson-CSF around 68010 microprocessors and the SECs are produced in cooperation by SFENA/Aerospatiale with a hardware based on the 80186 microprocessor. We therefore have two different design and manufacturing teams with different microprocessors (and associated circuits), different computer architectures, and different functional specifications. At the software level, the architecture of the system leads to the use of four software packages (ELAC control channel, ELAC monitor channel, SEC control channel, and SEC monitor channel) when, functionally, one would suffice.

Answer 3

In general, software isn't manufactured wrong. When the software is created (programmed), defects can be introduced as you described by either faulty implementations or by bad specifications. Faulty implementations are detected by testing the software. Testing takes many forms; unit testing is one of the more basic forms, where individual functions of the underlying programming code is tested to see if it is implemented correctly. This can scale upwards when doing system and integration testing where larger pieces of the software is coupled together to see how it performs as a whole. But simply testing the code at this level doesn't catch everything. Writing a program is rarely about getting it to do what you want it to do, it's mostly about handling all the strange edge-cases and failure scenarios. And this is where most software fail.

To guard against such cases, you can run through audits, simulations, static code analysis and lots of other forms of inspections and testing.

Faulty specifications is a different beast, where you have to rely on documentation. In a perfect world each requirement must be documented to a level describing why the requirement exists, and any input and output that should result from it if applicable. Specifications are developed by multiple people to guard against one person forgetting something, or wrongly interpreting something, but this doesn't catch everything either.

To add another level of protection against software defects, you add multiple instances of the system, and you also have a team create their own version of the systems, preferably on different hardware. You can then divide responsibility of certain subsystems and spread it out among the various computers running the system, adding another level of redundancy as well as to lessen the computational load on each computer, and the risk that any parts of the system interact in unforeseen ways.

The Fast Company had an excellent writeup on the process of writing software for the space shuttle. Although it isn't directly related to neither Airbus or Boeing, it gives an insight into how the process worked and what it resulted in.

Answer 4

Primary systems should have identical computers and software and is the case on many airborne vehicle systems computers. However, the independent backup systems should have dissimilar systems and software depending on the architecture and redundancy management requirements and schemes for safety. Other than flight controls which do have dissimilarity in hardware, primary flights displays for pilot and copilot sides for airspeed and inertial navigation are often triple redundant to retain the attitude function. These correctly use identical 3 nav system computers whereas the "backup" is dissimilar for purpose of flight safety critical functions and determinism. The overall system architecture of parallel or more (triplex) must have independent and redundant systems that meet the agency and regulatory criteria for safety and airworthiness as well as reliability and availability. Generally, having identical computers for "primary systems will require in depth fault insertion testing of combination of complex interaction will minimize the possibility of software faults and sometimes unfounded fears that defects will somehow manifest in latency. Proper testing in all environments is the key to getting rid of any defects that would cause potential hazards and risk. Software safety methods are recommended to prevent, eliminate and control such issues to ensure safety and airworthiness requirements are met. Safety analyses and independent reviews are required in these cases with approvals.