Why so many computers for flight controls in A320?
Bear Behind
Join Date: Dec 2001
Location: Yerp
Posts: 350
Likes: 0
Received 0 Likes
on
0 Posts
The answer is redundancy (whether you accept it or not, that is the answer) and when designing the systems, Airbus insisted that separate teams within the manufacturers, or where possible different manufacturers, designed both the hardware and the software. Airbus (or the DGAC) was not willing to accept that a fault with the same piece of code in two separate computers could cause the loss of an aircraft.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
OK, I guess here's where I come in... 
The general gist of the previous replies is correct. To answer the question thoroughly would require an essay-length reply or longer, so I'll try to stay brief for now and for a more in-depth look, direct you at this PDF, which covers things in greater detail:
http://www.cs.ucc.ie/~herbert/CS4504...2000627364.pdf
A few ground rules worth understanding include the following:
As far as the dissimilar codebase goes, the ELACs, SECs and FACs each have the same basic hardware implementation per type (the ELACs based around the Motorola 68010 and the SECs around the Intel 80186), but the code developed for ELAC1 was different to that of ELAC2, and the same went for the SECs and FACs.
To give an example of function-sharing and redundancy in the physical sense, I'll quote from the article linked above:
At the risk of repeating myself, I'm going to reiterate the point about the hardware used being obsolete even by mid-'80s standards because it is crucial to understand, given the scuttlebutt aimed at the system over the years. Your home PC with its modern processor is the equivalent of a Formula 1 engine - designed to run complex software at tremendous speed, with the caveat that it will crash from time to time. Realtime systems use obsolete hardware and very simple code and would be the equivalent of an old pick-up truck or VW engine - not amazingly fast, but designed to run problem-free and reliably for an unbelievable amount of time. For this reason, specialist firms are still knocking out hardened packages based on processor designs that are over three decades old, because for most realtime work you don't need anything much more complex!
The software too is based on completely different principles to what most people are used to. In engineering terms this design principle is known as a Finite State Machine and you tend to encounter them in things like washing machines and microwave ovens. Put simply, there is only a finite number of states (e.g. Fill, Wash, Rinse, Spin, Drain) that the machine can be in, and usually only one of those states applies at any given time. The Airbus flight control software is essentially an interconnected set of these FSMs which can trigger changes in behaviour amongst themselves. This means that a system which appears complex to the outside observer is actually made up of a group of very simple systems which were tested exhaustively in isolation and later in combination with each other.
I realise I've exceeded the bounds of the original question slightly, but I hope this info is useful!
The general gist of the previous replies is correct. To answer the question thoroughly would require an essay-length reply or longer, so I'll try to stay brief for now and for a more in-depth look, direct you at this PDF, which covers things in greater detail:
http://www.cs.ucc.ie/~herbert/CS4504...2000627364.pdf
A few ground rules worth understanding include the following:
- We're talking purely of flight control computers here -or the FBW aspect. FMS/automatics are a completely separate concept.
- As the A320 was not just the first iteration of Airbus's civil FBW technology, but a world first - the tendency was to overengineer things slightly. As an example, the functions handled by the FACs in the A320 were folded into the PRIMs and SECs on the A330/340 (and hence the change in designation).
- There are several layers of redundancy at work. Not just duplicating the systems themselves, but function-sharing in terms of physical connections and a dissimilar codebase for each.
- The hardware used was already obsolete by the mid-'80s. This meant that the hardware was fully understood and predictable in terms of operation.
- This in turn necessitated a very simple codebase - which was and is standard practice in realtime systems development.
- Megabytes and gigabytes of storage have little bearing on this kind of technology, because it is designed to be lightweight in terms of complexity (and as such reduce risk of error).
As far as the dissimilar codebase goes, the ELACs, SECs and FACs each have the same basic hardware implementation per type (the ELACs based around the Motorola 68010 and the SECs around the Intel 80186), but the code developed for ELAC1 was different to that of ELAC2, and the same went for the SECs and FACs.
To give an example of function-sharing and redundancy in the physical sense, I'll quote from the article linked above:
The computers and actuators are also redundant. This is illustrated by the A320 pitch control (left imd right elevator, plus Trimable Horizontal Stabilizer - 'THS). Four control and monitoring computers are used, orie is sufficient to control the aircraft. In normal operation, one of the computers (ELAC2) controls the pitch, with one servocontrol pressurised by the Green hydraulic for the left elevator, one pressurised by the Yellow hydraullic on the right elevator, and by electric motor NO2 for the THS. The other computers control the other contra11 surfaces. If ELAC2 or one of the actuators that it controls fails, ELAC1 takes over (with the servocontrols pressurized by the Blue hydraulic on elevators, and with THS motor NO1). Following same failure method, ELACl can hand over control to SEC2. Likewise, pitch control can be passed from one SEC to the other depenlding on the number of control surfaces that one of these computers can handle.
The software too is based on completely different principles to what most people are used to. In engineering terms this design principle is known as a Finite State Machine and you tend to encounter them in things like washing machines and microwave ovens. Put simply, there is only a finite number of states (e.g. Fill, Wash, Rinse, Spin, Drain) that the machine can be in, and usually only one of those states applies at any given time. The Airbus flight control software is essentially an interconnected set of these FSMs which can trigger changes in behaviour amongst themselves. This means that a system which appears complex to the outside observer is actually made up of a group of very simple systems which were tested exhaustively in isolation and later in combination with each other.
I realise I've exceeded the bounds of the original question slightly, but I hope this info is useful!
Last edited by DozyWannabe; 27th Jun 2013 at 23:23.
Beau_Peep
Thread Starter
Join Date: Apr 2007
Location: India
Posts: 228
Likes: 0
Received 0 Likes
on
0 Posts
Thanks for the link.. very detailed answer. It proves that sometimes 'OLD IS GOLD'.
Another point I would like to add is that redundancy means duplication which usually 'kicks in' AFTER a failure.
Sharing processing job among many computer is not redundancy. it is reducing risk of failure by not letting a single computer run the entire show.
Another point I would like to add is that redundancy means duplication which usually 'kicks in' AFTER a failure.
Sharing processing job among many computer is not redundancy. it is reducing risk of failure by not letting a single computer run the entire show.
Last edited by IFLY_INDIGO; 28th Jun 2013 at 03:27.
Join Date: May 2008
Location: denmark
Posts: 9
Likes: 0
Received 0 Likes
on
0 Posts
@IFLY_INDIGO
Another point I would like to add is that redundancy means duplication which usually 'kicks in' AFTER a failure.
Another point I would like to add is that redundancy means duplication which usually 'kicks in' AFTER a failure.
Wee may have an application with a pressure sensor to monitor if the oil pressure is so low that it could damage an engine.
The sensor might have failure modes where you can't detect if the reading is correct or not.
In this case you need to compare the reading with another sensor to find out if the pressure reading is ok. In case of disagreement you might not know witch of the two sensors are correct.
This is fine if it is ok to stop the engine on pressure disagreement.
If we are not allowed to stop the engine on a false low reading then we need additional redundancy. E.g. 2oo3 or dual 1oo2.
Micro-controllers have the same problem, it is not able to detect if it has had a hardware error, resulting in a faulty calculation. (There are some that claim that they can do this like the TMS570)
Normally lock-stepping and voting is used. (Design to avoid Byzantine faults).
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
Such functions in the computing world are a specialised form of redundancy known as "Defence In Depth".
http://en.wikipedia.org/wiki/Defense...pth_(computing)
Last edited by DozyWannabe; 28th Jun 2013 at 17:31.
Join Date: Apr 2013
Location: Earth
Age: 49
Posts: 152
Likes: 0
Received 0 Likes
on
0 Posts
It's about reliance on the gear, trying to take the pilot out of the equation.
One good lightning strike, back to pilots again...no telling them that though, - lightning strikes, bombs, Oxy fires, sabotage, malware, ground interception...none of that happens in their world.
One good lightning strike, back to pilots again...no telling them that though, - lightning strikes, bombs, Oxy fires, sabotage, malware, ground interception...none of that happens in their world.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Nov 2009
Location: flying by night
Posts: 500
Likes: 0
Received 0 Likes
on
0 Posts
Everyone has his/her own favorite "weird" thread with seemingly unnecessary questions (arguably they're still ok though).
If I was to chose, this one gets my vote. Many excellent and very detailed answers here, but I'll add to the noise, because this is a simple question, which doesn't need complicated answers. All the computers... it's definitely not about conspiracy theories and computers vs men, taking over the world. Why do we need so many doors on aircraft? Isn't one pilot enough? Why all the cabin attendants? Multiple hydraulic systems? Engines? Generators? Sensors? Instruments? Radios? And do we really need fuel for alternate airports?
Redundancy, redundancy, redundancy. The more, the safer. It's that simple. Without redundancy, the evil computerized Qantas A380 would have fallen out of the sky because of an uncontained engine failure. Despite heavy damage and multiple failures, it didn't. It was build like a tank, metaphorically, and kept flying in a safe and controllable way
If I was to chose, this one gets my vote. Many excellent and very detailed answers here, but I'll add to the noise, because this is a simple question, which doesn't need complicated answers. All the computers... it's definitely not about conspiracy theories and computers vs men, taking over the world. Why do we need so many doors on aircraft? Isn't one pilot enough? Why all the cabin attendants? Multiple hydraulic systems? Engines? Generators? Sensors? Instruments? Radios? And do we really need fuel for alternate airports?
Redundancy, redundancy, redundancy. The more, the safer. It's that simple. Without redundancy, the evil computerized Qantas A380 would have fallen out of the sky because of an uncontained engine failure. Despite heavy damage and multiple failures, it didn't. It was build like a tank, metaphorically, and kept flying in a safe and controllable way
Last edited by deptrai; 29th Jun 2013 at 18:44.
I would imagine that safety analysis of real time operating systems is much simpler if the hardware and software are cleanly partitioned so that the functional architecture maps the physical architecture.
Join Date: Nov 2009
Location: flying by night
Posts: 500
Likes: 0
Received 0 Likes
on
0 Posts
btw, from what I see, A320 has 2 ELAC (elevator and aileron computers) and 3 SEC (spoiler and elevator computers); the ELACs were produced by Thomson-CSF based on a 68010 CPU and the SECs were made by SFENA/Aerospatiale based on the 80186, as already noted. So you have 2 sets of completely different Hardware (CPU and architecture), and also different functional specs. (and at the Software Level, you have 4 different Software packages: ELAC control channel and monitoring channel, and SEC control channel and monitoring channel). Then there's also the FACs, for the A320...all this info is easily available. Imho this level of redundancy is completely appropriate, it's not "overdone" in any way, it's just based on safe and sound principles to avoid common mode failures, conservatively engineered, and adapted to the capacity of the hardware.
if you look at the A380, a much more modern design, possibly there's been a minimal increase in functional density (I counted 51 control surfaces vs X for A320?), but it still needs 3 Primary Flight Control and Guidance Computers, 3 Secondary Flight Control Computers, and 2 Slats & Flaps Control Computers.
I can't see how reducing the number of computers would be of any big help for anything (quite contrarily).
if you look at the A380, a much more modern design, possibly there's been a minimal increase in functional density (I counted 51 control surfaces vs X for A320?), but it still needs 3 Primary Flight Control and Guidance Computers, 3 Secondary Flight Control Computers, and 2 Slats & Flaps Control Computers.
I can't see how reducing the number of computers would be of any big help for anything (quite contrarily).
Last edited by deptrai; 30th Jun 2013 at 18:16.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
@dash6:
To be fair, it's a little more complicated than that...
@deptrai:
Unfortunately I do not as yet have the kind of in-depth info on the A380 that I have for the A320, but to my mind the big 'bus has to be a significantly more complex beast than her smaller older sister. Not just in terms of flight surfaces, but things like landing gear operation are far more involved - and the systems built on top of them (e.g. Brake To Vacate) require a much more precise level of monitoring.
That said, the principles behind the design seem to have remained fundamentally the same - they've just evolved over time.
To be fair, it's a little more complicated than that...
@deptrai:
Unfortunately I do not as yet have the kind of in-depth info on the A380 that I have for the A320, but to my mind the big 'bus has to be a significantly more complex beast than her smaller older sister. Not just in terms of flight surfaces, but things like landing gear operation are far more involved - and the systems built on top of them (e.g. Brake To Vacate) require a much more precise level of monitoring.
That said, the principles behind the design seem to have remained fundamentally the same - they've just evolved over time.
Last edited by DozyWannabe; 3rd Jul 2013 at 18:42.
