Chris Scott said of the two channels in the ELAC/SEC/FAC boxes:
Originally Posted by Chris Scott
my ...... understanding was that, in the event of an anomaly between the command channel and the monitor channel, the computer concerned merely shut itself down.
I'm sorry, Chris, what I wrote was ambiguous.
What you say is of course correct when considering "command" and "monitor" channels inside one of the boxes.
My comment was addressed to discrepancies *between* two (or more) of the ELACs; or SECs; or FACs, and I didn't make that clear.
There are three SECs: they could presumably vote. But there are only two ELACs (FACs are less critical). What happens when they disagree? I don't know.
But I do know of one case in which they should have disagreed: the March 2001 incident to Lufthansa at Frankfurt, when the captain's sidestick was reverse-wired in roll. Since only one ELAC had been rewired (all plugs), then the two ELACs should have been getting exactly opposite inputs in roll (one ELAC the commanded roll; the other the exact opposite of what was commanded). So what happened, and how was it dealt with? The report is absolutely silent on this. (As well as being on the BFU WWW site, the report is in our compendium
computer-Related Incidents with Commercial Aircraft ) I wonder why?
Originally Posted by Chris Scott
For a given computer type, we always wondered how genuinely independent the "command" SW programmer-team could be from the "monitor" team. After all, they presumably each have the same basic mission?
The big question is which faults are likely to be correlated, and which not. Mismatches between requirements and actual operational environment, which I call "requirements faults", account by some studies into aerospace critical digital systems for well over 95% of failures (Lutz, NASA/JPL, early '90's. The UK HSE looked at all types of critical systems from simple to complex, digital and non-digital, and got a figure of over 70% in the late 90's). So if 19 of 20 failures are due to requirements faults, then N-version programming is only going to avoid at most 1 out of 20 failures. That doesn't seem to me like a huge win.
A classic example of a failure of this sort in aviation is the 1983 Lufthansa overrun at Warsaw (also in the compendium, with commentary, including some by the former chief aerodynamicist of Concorde, Clive Leyman).
Another possibility for correlation amongst teams performing N-version programming is dependencies caused by mode of presentation of requirements (one description might tend to lead all teams "along certain paths"; another description along other paths). A third possibility is common types of errors occurring in the most likely places in both.
Originally Posted by Chris Scott
Isn't it remarkable that, 20 years on, the SECs may still be employing an Intel 80186 chip, now ancient history in the home-PC world? We were all buying PCs with 80286/80386 chips, even as the A320s were first going into service.
ve3id and BobT hit the nail on the head. Evolution in desktop computers is driven by evolution in requirements (the need to process video streaming from the network, for example, which did not exist when the 80186 was designed). The requirements for digital kit on the A320 are more or less stable as of certification; why change something which does a demonstrably adequate job? Especially when you have put all that effort into the demonstration!
The PFCs on the Space Shuttle are even older! There are five of them. Four of them are identical, running identical but very highly inspected SW of a few thousand lines of code (LOC). The fifth is a fall back: extremely limited functionality, but different HW and SW from different organisations.
This is all a bit of a Tech-Loggie diversion, but it does make a change from the continuing catalog of attempts to (mis)understand the B777 fuel system
While I am at it, I might as well stick my neck out on this one. I am with avrflr: I am guessing that something lies in the cracks between what is recorded and what went on; either something was not recorded or something wrote it was "X" on the recorders when it was really "Y"; for example, the command signal was sensed and recorded but not the true state of the component. Such things can take months to years to sort out.
BTW, bsieker has prepared both a Causal Control Flow Diagram (CCFD) of the EEC signal paths, and a similar diagram (but where what flows is fuel, not signals; maybe we should call it a CFFD) of the fuel paths in the Trent-powered B777. We have them out for review at the moment and will make them generally available after initial feedback. A CCFD is like a functional block diagram of a control system, except for three points:
* signal magnitudes are omitted (we sometimes use signs ± indicating monotone-increasing and monotone-decreasing influence where necessary, but it is not necessary here);
* equipment duplication (usually there to provide redundant pathways) may be omitted, and in this case only one instance of each duplicated device is shown;
* it will include the human operator as a control-system component if heshe is one
It shows the signal paths (or in the case of the fuel, the liquid-flow path) between all the various devices.
The CCFD (resp CFFD) is quite complicated. We find them indispensable for any reasonable understanding of how a moderately-complex system works; a necessary supplement to text-based description. They might well aid discussion here.
PBL