It seems that PBL has already posted an objection to the "Expert Computer" concept. I guess I'm reading too slowly to keep up with all the twists and turns.
The key to the expert system is a cross checking of data types, not just comparing identical data types. Much better resistance to common mode failures this way.
Quote:
Originally Posted by
atakacs
... is there some "über"computer checking in real time that all sensor readings are within reasonable value respective to each other, and provide a clear ECAM message if not ?
No, there isn't. The general opinion of such things is that it wouldn't do much good, and maybe quite a lot of harm.
First, think what would happen if it failed.
Then, how it can fail. You might think of building in redundancy, but in fact one Byzantine fault can take out arbitrary levels of redundancy, as shown in one shuttle attempted flight (scrubbed during launch) when the entire 4-processor FCC partitioned itself inside seconds into 3-1, then 2-1-1, then 1-1-1-1 (info, and the observation of consequences for redundant architectures, courtesy of Kevin Driscoll).
PBL
So in response to this objection, let me propose an architecture that perhaps makes sense.
Two computers-physically separated in the aircraft, reading the identical inputs and performing identical calculations on the data using the "expert knowledge base". Any discrepancy in outputs causes the system to disconnect from the system and advise the crew. Result-reversion back to basic Airbus that everyone is familiar with. How the information is presented to the aircrew is important to avoid over-reaction/under-reaction. This will require significant development work, but should result in usable advisories to the crew.
FullWings
I think there already are expert systems monitoring aircraft "looking for anomalous data using a wide variety of screening methods": the pilots. Like any other system they have limits and in this case they were exceeded. Their 'diagnostic bandwidth' was occupied/unavailable.
It is comparatively easy to take an example like one working and two frozen probes and figure out some logical/procedural way of discounting the false readings, specific to this actual failure mode. What is not easy (or indeed possible in our current understanding, as PBL points out) is to have a process which will always return valid data when 2 out of 3 of the inputs are misbehaving in some way.
In the old days, you had one altimeter and one airspeed to look at. Today when you look at these indications in a modern aircraft, you are looking at a computer selected presentation of multiple
identical sensors as chosen by the computers. If the crew's "diagnostic bandwidth" was exceeded (which probably isn't too hard in today's complex aircraft), it is an indication that they could have used some help.
Supposing an expert system noted that there was a discrepancy between gross weight and AOA or between airspeed and AOA. First it could observe the output of the 3 AOA sensors and note that two of them didn't make sense in the context of airspeed and gross weight. Next it could observe the output of the sensors for a change in output and if the same two sensors that seemed aberrant before showed no change, it could advise the crew of a possible AOA malfunction involving two sensors and request a small test maneuver. If still no response by the two affected sensors to the test maneuver, then they would be locked out of the control system and the crew would either be advised or would authorize the lockout. Result-the one remaining good AOA sensor is used for all AOA inputs. There is no reason that similar procedures could not be applied to all sensor data.