Tyropicard responds to bushfiva's query
Originally Posted by bushfiva
Is there any truth in Private Eye's observations on p29 of issue 1204? Is it normal to have redundant software written by different companies in the commercial aerospace industry?
TP says
Originally Posted by Tyropicard
when Airbus went FBW they used at least two software houses - from rusty memory Boeing's 777 design timetable was compromised by going down the same route, so they switched and just used the one company.
I addressed some of Private Eye's suggestions cursorily in
Post #184
Maybe now is the time to be a little more specific. The most accessible short reference to the A320-type architecture is pp131-5 of Cary Spitzer's Digital Avionics Systems (Second Edition, McGraw-Hill 1993).
There are actually 7 computers involved in primary flight control, falling into three different functional types of two ELACs, three SECs, and two FACs, with overlapping functional responsibilities. Each ELAC contains a pair of MC 68000 processors, a "command" (or "hot") and a "monitor" (as a check), which run the same inputs in parallel. The SW running on these two processors is "dissimilar", meaning each is written by a different team.
There is no formal criterion for "dissimilarity"; this is done in the hope that elementary bugs will be avoided, but the (in)famous Knight-Leveson work showed that important errors might well be correlated nevertheless. Bugs may also be avoided by using "correct by construction" (CbC) methods and very close inspection. Some like one; some like another. The very best *demonstrated* quality control in critical software to date uses CbC methods and close inspection.
The SECs also have dual processors, in "command" and "monitor" configuration, with similarly "dissimilar" SW.
They also have different processors: Intel 80186. The FACs have a similar dual structure to the ELACs and SECs.
The FACs, ELACs and SECs run in parallel on the inputs. The outputs cannot be determined by voting (you can't vote with only two processors!) but I don't know how the checks work.
The ELACs and SECs are also manufactured by different divisions of the same company, Sextant Avionique.
It may be that in later versions of the A320 the HW has changed. It is certain that the SW has changed over ops lifetime.
The B777 AIMS uses "common" SW across its multiply-redundant HW platforms, which are also of common design (so-called "line-replaceable units", LRUs). Spitzer is also good on AIMS (I have been on a mailing list for a long time with the primary AIMS designers, Ken Hoyme and Kevin Driscoll). The only reference I have to the PFC is a paper by Bob Yeh of Boeing (Bob has a few papers on it, but they all cost money which I haven't yet forked out). The PFC is triple-redundant *in HW*, but they went with one SW; Yeh cites Knight-Leveson as well as some work by Avizienis at UCLA. But the reason why the PFC is single-source SW is as follows:
Originally Posted by Bob Yeh, B777 PFC designer: Design Considerations in Boeing 777 Fly-By-Wire Computers, n.d.
The development of the PFC software during the 7J7 program confirmed that the three separate teams, in order to code their logic from the requiremnets, were having to ask Boeing so many questions for clarification of the requirements that the independence of the teams was irreparably compromised. This is the reason why Boeing elected to revert to the usual and customary method of creating and certifying flight critical source code. It was determined that there is a net gain in total system integrity with the single software design approach.
There it is in print from the horse's mouth. Note that Yeh also answers bushfiva's question whether it is "normal" to have redundant SW written by different companies by suggesting it was at time of writing "usual and customary" to have single-source, well-inspected code. With A320-type architectures occupying airspace all over the globe in their thousands, and B777 architectures occupying it in their hundreds, it is probably moot to ask what is "normal" or "usual and customary".
I hope this helps answer some questions about duplication and redundancy in the architecture of the digital avionics of common 4th-gen transports. If anybody wants to know more and thinks I may be able to help, please feel free to PM or email me.
PBL