Yes, but this thread is about the "Search" not about speculation and other rubbish. Pages of crap with only some few updates about media releases etc.

Keep the thread about the actual progress of recovery. This isn't the "AF447 Speculation on cause" thread.

@bobman84

As you like sir, I however enjoy the contributions from the regular posters on here while we wait for more actual information from the BEA.

Mr Amos is entitled to his opinion of course but this isn't the first time he has expressed it (badly).......

Hi,

My first scenario is:
Find a means to avoid blocked pitot tube and so avoid a unsafe condition.
this will eliminate the other scenarios you suggest.

Given the availability of technologies such as GPS, Inertial navigation, radio navigation, radar, AOA sensors - is it possible to build an avionics package which could automatically control (and provide pilots with information to manually control) the flight throughout all phases without requiring a pitot-static system at all?

Given the current low cost of electronic pressure tranducers - would it not make sense to have multiple static pressure transducers spread throughout the airframe (e.g. on the wings, horizontal stabiliser) to monitor the actual aerodynamic performance of the aerofoils and adjust thrust/pitch based on this?

In the event of multiple pitot probe failure/icing - would it not make sense to lower the RAT and calculate airspeed based on RAT power output/rpm?

In the event of multiple pitot probe failure/icing - would it not make sense for the flight control system to execute minute movements of the control surfaces (spoilers/elevator, rudder) and estimate airspeed based on the force required to move the control?

It seems there are a lot of readily available alternative sources of airspeed information - it's just that the rate of adoption of new software technology to take advantage of these is very slow.

Dozy Wannabe,

You make some good points about software testing. Having worked in the field of research (Best part of 30 years ago) that was looking at how to prove programs correct for life critical systems (A320 included), one of the facinating topics was how to add the extra dimension of time to unit and regression testing.

If all expected (unexpected and down right surprising) inputs to a function (should say object but let's keep this in layman's terms) produce expected output, then you have a function that works in isolation. The problem with any "real-time" system is that you do not know when such inputs will occur and what else will be happening at the time. I no longer work in this field but the probelm of how to test for an acceptably comprehensive set of time related inputs is something that was not solved at the time.

Keep testing until you are satisfied that nothing new will occur was the method. This can take a while in a system as complicated as that flying the A330. There is no doubt that the "two teams" approach that you describe for the A320 helped bring a lot of confidence to the testing teams.

RE Takata’s post #2233
 

Assuming that image is from a genuine Airbus publication, I really do hope that their ability to find bugs in software is somewhat more effective than their proof reading of what must surely be extremely critical documentation!


http://i52.tinypic.com/2r7oigg.jpg


Witches in the ADIRU’s!
Could that be the explanaton everyone is seeking?

deSitter, #2217

Well, someone else did ask http://images.ibsrv.net/ibsrv/res/sr...lies/smile.gif

I think you are being overly pessimistic, even bordering on alarmist in
that many people reading this thread won't understand that commercial IT
does not equal software engineering. The whole tone is embittered and
disparaging and does you no credit. Sorry to be blunt, but standards in
software engineering, when done right, are just as rigorous as any other
branch of engineering. It looks like you came into IT out of desperation
and just for the money, but many people, believe it or not, really are
dedicated and come to work every day with the intention of doing the very
best that they are capable of. Sure, a lot of companies have inept
management, but you can always move on, or like myself, work freelance
to get more variety, interesting challenges and more experience.

I do agree up to a point about "methodologies" and fashion, but many such
ideas are nothing more at root than formalisation of common sense and
methods used informally / ad hoc for decades. Such tools and techniques
can be very usefull, used intelligently, but are only ever part of the overall
development process.

Sorry, irresponsible alarmist nonsense. No other way to describe
the allusion that Paris fashion is in some way connected to aircraft
safety http://images.ibsrv.net/ibsrv/res/sr...ies/tongue.gif...

They only cast a spell of "Proof Reading" aimed at such documentation piled up, nothing more. But it actually never worked as expected due to some bugs induced by German-French accents: finally, there is plenty of such typos in many parts of the manuals. (more seriously, it comes certainly from OCR bugs during pdf transfer).

syseng68k has already addressed the last point. Ada was indeed included in my Software Engineering course for those that wanted to study realtime systems (class of 2001).

As to the first point, military work is one thing, where there is more likely to be use of bleeding-edge technology and the assumption of a reasonable degree of risk is acceptable. However to design a system intended for commercial operations, which could theoretically kill hundreds of taxpayers at a time if things are not done correctly (including many in first class whose families can afford extremely good lawyers) is an entirely different ballgame.

BUSS
 

GolfSierra:

"Given the availability of technologies such as GPS, Inertial navigation, radio navigation, radar, AOA sensors - is it possible to build an avionics package which could automatically control (and provide pilots with information to manually control) the flight throughout all phases without requiring a pitot-static system at all?"

Apparently at least one such system exists for the A330. Cited text:

"The BUSS or "Backup Speed Scale" Air France - Corporate : The BUSS or "Backup Speed Scale"
The "Backup Speed Scale" or BUSS is a tool which pilots use when speed indications cannot be used.
To use the BUSS, the crew must first disconnect the three ADRs (air data reference - anemometric stations). Once these have been disconnected, the crew can no longer use them during the flight.
With the BUSS system, speed is no longer calculated by the Pitot probes, but by the aircraft's incidence probes. The speed indication, which is less precise, is presented in the form of green, ambre and red stripes. In a high turbulence situation at high altitude, the speed indication given is very unstable and difficult to use.
On its A330s and A340s, Air France considered installing the BUSS system offered by Airbus and carried out tests on its flight simulators These tests did not lead Air France to adopt this system.
This is because it has the incovenience of depriving the crew of anemometric data during the flight once the BUSS system is activated, whereas experience has shown that the loss of speed indication is generally for a short time only. Moreover, the system is difficult to use at high altitude.
This has been confirmed by Airbus which recommends in a FOT (Flight Operations Telex) dated 9 September 2009 not to use this system at an altitude higher than 250, i.e. 7,600 metres (25,000 feet)."


Regards

Diversification:

This sounds contradictory to the description given by takata here. The manual says that if the ADR is disconnected, it turns off both the pitot probes and the AoA probes ("incidence probes"). So something is inaccurate here?

GolfSierra:
Potentially, one solution to an air-data-independent flight control system might be based on the inertial and acceleration sensors, see my suggestion here.

The big challenge, however, is that an airplane flies in the local air which is moving around affected by local wind and turbulence, and must remain within its flight envelope in relation to that local airmass. Some sort of airspeed sensor (as opposed to groundspeed, as provided by GPS and inertial) therefore seems fairly indispensable, at least for critical flight regimes at high altitudes and approach/landing phases where the local wind needs to be considered.

I recall reading in the forum, and I then asked for confirmation without any answer, that A330 SOP for unreliable air speed called for CT and 5degrees up nose.
Can anyone confirm that? (if i´am wrong sorry for introducing noise in the forum)
if above is yes: aren´t those settings prone to induce a stall when flying at 37thousand feet at max cruise speed?

If i´m asking a non sense, disregard my chopper flyer questions

sf2 - IF, and that is a very big 'IF', it is insisted that an automatic system should fly pitch and power in that situation, then a database of settings for weights and atmospheric conditions etc is easily do-able, and a 'take-me down' button easy to install in the system. Why bother? Back to pilot training. We can also do that. We SHOULD be trained to do it (some are). It should be instinctive - revised every time we level off in the cruise. Why add yet another system with potential software f-u's and failure modes? Ah! Good! More ECAM actions.

Regarding an 'inertial airspeed reading' - be very careful - How would the system interpret a change in wind component of 10 kts in a storm area? Greater than the margin between stall and overspeed sometimes! Deceleration/acceleration away from 'datum', yes, but now - was that a speed change or a wind change? How will Hal know?

no. Did you mean min? (With 10 up you could probably loop it:))

BUSS again
 

SnowFalcon2 wrote:
"This sounds contradictory to the description given by takata here. The manual says that if the ADR is disconnected, it turns off both the pitot probes and the AoA probes ("incidence probes"). So something is inaccurate here?"

Please use the link in my previous post and read. There is also a pdf-file from Airbus which argues for the installation and use of BUSS in case of unreliable airspeed.

What I don't understand is why it would not be possible to revert back again to normal sytstem functions.

Regards

Hi,

http://i.imgur.com/LF5fM.jpg

I think because you can't align the ADIRUS while in motion...?

Diversification:

I think I found the error, reading this interesting writeup about handling of unreliable airspeed. Quote:
So based on this, the BUSS system in fact uses inertial data based AoA information, and not the AoA probe data. This is now consistent with the information provided by takata.

Dozy and syseng68k, I am not trying to be alarmist - but I do find it very telling of the entire world of developing software, that tools like APL, FORTH, and Smalltalk, which are purpose-built for solving specific problems, are universally scorned in favor of bloated "software development universes" that operate according to internal laws that make string theory look sane. The problems get lost in the process of development and the software becomes an end in itself. The effects are most obvious when things go south, and one is presented with blizzards of useless information. It may be OK to wade through such dross while sitting in the data center, but pilots with a troubled airplane don't have time to think about such things.

3holelover

As an addendum to your reply to Diversification, I would say that in an earlier discussion it was determined that once in ALTLAW2, Normal Law is inop for the rest of the flight, until the system can be re-indexed.

My recall of the B-2 Guam crash is that in re-indexing the computers in the evening prior to launch, the ground crew neglected to dry out the sensors, and the data loaded was bunk for TO. GIGO. The pilot's of the Liberty had no mystery, when the Computers yack, Adios amigo. Not so pretty clear with AB.

Re 447, a transport of conventional airframe architecture, one could start a train of thought that included, "If not in Normal Law, then straight to direct." The B-2 cannot be flown in any fashion by hand, so its experience is suggestive only. One gets the notion in following this (AB) discussion that in the stink, one needs to know how to fly at least four different a/c.

One cannot wish to hire BoxMonitors and also expect a "Four-in-one Type Rating." Aviation will NEVER be so predictable that one can expect pilots under normal circumstances to revert to "golden arms"* on a milsec's notice.

Machinbird

I think it fair at this point to say "Raise the Nose Up". There is precedent, and neither can be supported by the information at hand, at least not conclusively. Finally getting the nose down, the crew may have succeeded too well, and could not raise it once again. It fits into what happened at Perpignan (loosely).

There was a Pitch problem by definition. Considering the RoD, why not at least consider more than one "recovery" of Pitch authority?

aside. BUSS was one of two systems discussed earlier, along with the unselected AH at the upper left of Captain's Panel. Bean counting can bite.

There's your first problem - Smalltalk took a while to catch on in the commercial world, but it has set the stage for languages like Haskell, which are general-purpose, but with very clearly-defined functional properties. They still have to be compiled into machine-readable instructions though...

I don't know how many more times we can say this before it sinks in, but:

they don't. Safety-critical real-time software uses a completely different paradigm to any other software development methodology you care to name.

It really takes me back all this discussion of IT and SE. I worked on the "Green" compiler for a short while and it was very clear when DoD selected Green as the official Ada language, everyone from Jean Ichbiah down accepted that Ada needed a lower level tasking mechanism than that provided by Green. It did not happen until 95.

deSitter might realise that the A320 flies with 60 000 lines of code, something that would not even get a "Hello World" working in Windoze:=. Small, tight, well tested packages that do a specific task without any excess bloat are the tools that are needed to build ultra-reliable systems. While many could argue with the specification for Airbus' FBW system, few could argue that it does anything other than what the box says (that is good software engineering)

The 'Maneuvre d'urgence' contains a note that refers to the follow-up procedure 'Vol avec IAS douteuse/ADR Check' that is reproduced in BEA's Interim Report #1, Appendix 9. There you'll find for FL250 - 370, W>190t: 3.5°/90%N1.

PJ2 has explained that a pilot would not be expected to go to 5° at FL350 and M.82.

Bad air data? we've been there, done that...
 

Salute!

The B-2 crash was another topic that got my attention like the AF447 one. Guess I am a FBW freak. STOP ME before I read/post/mull/wonder again!!!!

Most of the links do not work now, but someone might find the accident report referenced in this URL from the F-16.net.

http://www.f-16.net/f-16_forum_viewtopic-t-10556.html

Worth a read, as one of the designers chimes in with some good poop.

Some of the pilot's comments are very revealing., as in "...plane was doing exactly what it was supposed to be doing..." I have heard that this past week or so someplace.

Hi,

:confused:

http://i.imgur.com/LF5fM.jpg

But what are the limits of what a pilot can do? Set the pitch and adjust the power, OK. Is your average (or even above average) pilot going to be able to factor in issues such as aircraft weight, CofG, bleed and generator load to name a few and select the right values? Will the pilot have any sort of spatial awareness of what is going on with the aircraft? There was a case when a jet took off with the static ports taped up - somehow setting power/pitch didn't ensure a good outcome in that case.

Computers can tackle problems such as these. There are millions of flight hours worth of data available covering thousands of parameters of an aircraft such as the A330. I can imagine that by processing this data it would be possible to develop a probabilistic model of the actual dynamics of the aircraft. Computer processing power is available to analyse the actual flight parameters against such a reference database real-time and (a) identify any discrepancies, (b) extrapolate to a high degree of certainty any missing parameters. The real challenge will be to get such solutions certified.

The pitot-static system relies on a duplication of the same devices to achieve redundancy. This approach was far too simplistic for the computers - not only are they multiplied - but they are in fact totally different computers. If we expose 3 identical probes mounted more or less on the same place to the same conditions we are far more likely to encounter multiple failures then if we have different devices. Why were not the same criteria as applied to the fbw computers applied to the air-data system?

My avionics experience is not current either.....
Wot's an 'rto'? (other than a rejected take-off)?

thanks for your post on state machines.... saved it. We never used that 'notion', but then I'm an analog dinosaur.... Was a good time actually, until the µP asteroid hit.

Redundancy, Fault Tolerance and Graceful Degradation
 

Hi,

Simply, because (it seems) there are no solutions yet available (sensors) to have the (could provide) required redundancy.

In an earlier post you could find patents filed by Airbus SAS on sensors (laser based).

We heard about another solution being prepared for short time UAS. A Software based "hysteresis like" band-aid.

ChristiaanJ; RTOS= real time operating system K

Common mode errors
 

Forgive me if this has already been covered - I have tried to keep up on the thread, but the posting has been very prolific.

I work with sensor driven control systems and have noted that when exposed to slightly abnormal conditions, sensors using the same design initially tend to degrade toward failure in a very similar manner. In redundant sensor systems this can result in a common mode error which may be difficult or impossible to detect. It is only when abnormal conditions become excessive and the sensors become erratic that they provide enough differential error to be detected.

Since the ADR's depend on differential errors to detect potential sensor faults, it seems to me that if all pitot tubes initially began to degrade at about the same rate (perhaps due to water buildup at the drains), such a common mode degradation would not be detected initially and would fool the system into believing that the A/C was traveling faster than it really was. The AP would respond accordingly and slow the A/C down. Then, as water/ice build up continued, the differences in readings would have exceeded the error detection threshold for the system, causing the AP, etc to disconnect. But when that finally happened, the A/C would be going slower and closer to the stall speed than the computed flight envelope would expect.

Could a scenario like this have robbed the crew of precious time needed to make corrections? Are there parameters recorded on the FDR that could be used to determine retroactively that something like this occurred?

gums, #2226

Something that's been bothering me for some time as well. I'm really not
concerned what language is used to program the system, or any other software
related issue, as the field is by and large, well proven. What does bother
me is more of a human factors issue. If the whole idea of automation is
to reduce workload and do something predictable under all circumstances,
how is it that the system can max out the crew by too many or ambiguous
warning messages to the point that they have no idea of the state of
the aircraft ?. Speculation ?. Well perhaps, but how did a perfectly
servicable aircraft with a highly competent crew just fall out of the
sky ?.

The other point, again, is the probes. It cannot be beyond the wit of man
to design a probe that doesn't overheat on the ground, yet has enough
capability to melt ice under worse case conditions. Any engineer looking
at this cold would put in one or more temp sensors such as platinum film or
even a simple thermostat, perhaps a 3 term controller and big fat heating
element. No on/off switches or modes needed either, further reducing
workload and possibility of human error.

All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft.

Someone correct me if i'm adrift here, but "for want of a nail" seems
quite appropriate w/respect to the probes...

When everything is said and done, if the root cause points beyond a doubt to crew action or lack thereof, the approach taken will be, "if it ain't broken, don't fix it". The most recent AIT from Airbus already points in that direction. Given the complexity of systems involved, on the whole, it may the wiser approach. Improvements will come when they are ready. Until then just fly the airplane.

Not saying its good or bad, just the way it is.

I think this point is worth repeating, in terms of what a redundant system is, and what it isn't. Unless there is something different about each probe, they represent a potential (in terms of being in identical environment) single point of failure in three part harmony. :( Given the criticality of the probess function, how different can they be and still provide the input that permits airspeed to be used by both the flight crew and the computers in the flight control system?

I'll ask the Airbus drivers a question that has come up before: would an AoA gage (which is apparently not common in any airliner design, and for most regimes of flight a supplemental scan item) be a useful addition to the flying display?

AoA is already detected and provided to the system for protections and laws. Is there a good reason not to feed AoA to the flight crew? Adding "one more thing" to the display or HUD or instrument panel isn't to be done lightly, given ergonomics and scan development.

Or, is the general consensus something like this:

if you are flying, your charge is to stay ahead of the aircraft far enough to avoid getting into marginal AoA conditions? From the comments in this, and a host of other threads regarding varying mishaps, I get the impression that adding an AoA gage isn't perceived as the way ahead.

*shields up*

syseng68k

hello chris. This was a long train on BA038. Redundancy, Reliability, and Reconciliation.

"...All 3 probes are currently of similar design and would thus be expected
to fail in a similar way worst case, representing an effective single
point of failure. Avoidance of single point failure is the first line of defense
in any safety critical work, especially relevant in this case when one
considers how important the probe info is for safe operation of the aircraft...."

************************************************************ *****

Aviation IS "single point". Flying an aircraft is not overly complicated, yet we are discussing complex ways to approach simple things. Of course the solution is complex, it proposes to be so. One Pitot is all one needs. If it plugs, we heat it. If it has a wasp nest in it, my bad. If it has tape over the hole, also my bad, though I did not install the tape. To fix to an a/c three of the same type of pitot is not only redundancy, it is the raison d'etre for three separate flight computers. Collecting, reconciling and determining are slick computer work, but something has to re-simplify to input the single command that keeps the a/c flying. Of course since flight is dynamic, it is composed of sensing trends, and arresting bad behaviour. It is usually no more difficult than juggling one ball. But Nature being who she is, sometimes it requires the panache to juggle two balls. Then Three, etc.

When navigating in a complex system, it takes time, man or machine.
One can have simple, or one can have complex, but one cannot apparently have both. At least not quickly, also apparently. Something about 447's situation caused the autopilot to quit. No big, hand fly. One does not understand why it is called for to "troubleshoot" the thing that caused the issue. Hand fly. She troubleshot herself, hence ACARS, which have nothing to do with aviating.

It really is that simple. If any argument can be proven that these gents got confused, I'll consider it. If they did, who paid them to do it? Who "trained" them to ?

It is counterintuitive. Laugh if you like, intuition in a professional is money in the bank.

It was NOT the pitots. Something got in between a patent and ho hum gotcha and the pilots. Who let the dogs out?

syseng68k;
Respectfully, I disagree.

The point in this accident is NOT the probes.

A loss of airspeed information is not cause for Loss of Control.

A series of ECAM messages and chimes, (expected, with such loss of data), is not a cause for LOC.

A loss of attitude information IS cause for LOC but as far as we know, that did not occur here.

In previous pitot incidents, the exact same ECAM messages occurred. The crews continued to fly and within a few moments/minutes indications returned to normal.

We see such "ECAM streams" of multiple faults/failures in the simulator, during practised dual hydraulic failures for example.

As aircraft systems degrade, they engage in their monitoring/BITE behaviours and, according to their individual timings in sending data to the FWC which in turn are distributed to the CMC, DMUs etc, there will be a cascade of re-prioritizing messages until things settle down. I have seen such streams, many times in the simulator, once, during a serious hydraulic emergency in the air. In such circumstances, one must slow things down, wait and respond deliberately, with "pace", but not hurry.

I have previously observed that the UAS QRH drill memorized items to set the pitch at 15, 10, or 5deg and to set the power to the TOGA detent or in the last two cases, to the CLB detent, are intended for immediate "safe" responses right after takeoff, (catering to the Birgenair and Aeroperu accidents). The qualifying condition is at the end of the memorized items, which states that once the aircraft is above the MSA it should be leveled off for "troubleshooting". Such troubleshooting means getting out the QRH and reading-doing the checklist items. The first items involve appropriate pitch and power settings for weights and altitudes.

Ergo, none of the memorized items in the UAS QRH checklist applied here.

The first response would be to do nothing and touch nothing while the QRH was brought out.

The airplane was stable before the event, and, short of significant disturbance either through heavy turbulence, (thunderstorm entry) or intentional alteration of pitch or, (to a lesser extent) power, the aircraft should remain in a stable state for a reasonable period of time while the P1 hand-flies the aircraft and calls for the UAS drill, and the P2 brings out the QRH.

Contrary to some of the ill-informed statements made here and in the media by those who have never flown, or who have never flown the A330, this airplane hand-flies beautifully at all flight levels and is not a "hand-full", unless, like any airplane, it is near/at the boundaries of flight it was designed for and the crew trained for.

The crew could respond to all the messages, once the ECAM had settled down...it doesn't take long, but the professional airline pilots here I'm sure will say that slowing things down a tad (but not dragging it out), and gathering thoughts before launching, is a key to successfull handling of very complex and serious events. One must get one's surprise and rush of adrenaline under control first, then, as a crew, begin.

Even DP Davies advises "lighting up a pipe", (so to speak!), before rushing into drills. He quite markedly states that the only drill which must be done swiftly, accurately, with discipline and deliberation is the rejected takeoff.

However this unfolds on Friday and in the subsequent months, we must bear in mind first, the families whose loved ones died in this accident and set aside any desire to be "first" or "right" with this or that solution to this accident. The presentation of the actual data will not resolve all questions and, as many have already observed, "the crew" are a part of a very complex, dynamic system in which human factors will inevitably play a part.

What information should we expect from crash investigators later this week? I assume they will not be drawing any conclusions on the likely causes at this juncture; right?

AoA Works
 

Angle of Attack works just great at approach and landing speeds. AoA is the primary speed sensor for carrier landings. At cruise speeds, it's not sufficiently sensitive.

PJ, respectfully, I understand your explanations, acknowledge your type experience, and consider a nose up command as inappropiate at cruise speed /height for an unreliable air speed event , but No single sentence in the AF card posted here restricts its use to a below_MSA or take_off condition!

And pilots DO Train to follow the card or SOP, not our instinct (provided there is a card /SOP )

PJ:

I will defer to your deeper understanding of this flight problem set.

I will offer, as a point related to training, that since airspeed is an imbedded element of an instrument scan, and a critical performance measure in any instrument scan, the unexpected lack of it disrupts the scan. The "don't pay attention to the airpspeed" scan is a non-standard scan, and (IMO, I am biased due to some years of training pilots) should be practiced so that the PF is flying and crosschecking while deliberately ignoring a fundamental scan item ... while the PNF is doing as you illustrate, and handling the trouble shooting.

EDIT: I don't think I need to tell any experienced pilots this, but for those who aren't -- if you don't practice and use your instrument scan habitually, it tends to start off a touch slow when you begin to use it at need. Also, if you don't practice your degraded mode scan, your scan will tend to be slow (initially) when you need to implement that scan pattern. How much time did this crew have to get into that rhythm? Don't know.

This I have seen first hand, not only in my own flying, but also in hundreds of other pilots, when I gave them instrument checks or was being the SOB at the console for a simulator training event intended to "run them through the wringer." This observation applies to both inexperienced and experienced pilots. How quickly the scan, or degraded mode scan, was established, or re-established, varied with the pilot.

I grant you that crews in some other events where AS became unreliable (under other conditions and variables) were able to manage that transition via one means or another. Based on the points you raise, unreliable airspeed wasn't a new failure mode experienced for the first time by AF 447's crew. What it may have been was that rare failure mode, experienced with some novel other conditions, and most likely for the first time by that crew. (This consideration is related to the question I asked to studi about what Conventional Wisdom is and was among the A330 pilot community in re his described escape maneuver ...)

Friday will hopefully be enlightening.

Hi areobat,
Certainly. This is the main reason why the BEA should be given all the time necessary to make a complete correlation between all the dataset recorded as, of course, some data could have been erroneously displayed (and recorded). Because all the flight parameters are related to each others, it would be possible to find, beyond any doubt, if anything was wrong with the airspeed before the system started to reject it.

In fact, in normal flight, all the sensors are already not displaying the same data by a certain margin due to their airframe location: an aircraft is almost never flying in a perfect symetrical attitude and this will cause some noticeable variation between the various sensed pressures. This is also the main reason why a clean probe system would very very unlikely be clogged (in flight) at exactly the same rate and at exactly the same time.

ChristiaanJ, #2261:

Thanks for that, and for the record, am a bit of a dinosaur here as well :-).
I originally came into embedded work from a hardware, rather than comp sci
background and still do some analog work from time to time. It never
ceases to amaze me what was achieved in the past with mechanical gyros,
servos, synchros and discreet components. Often straddling many disciplines,
the designers of old were masters of their art...