Airbus crash/training flight

[BOAC]

First, think what would happen if it failed.

- my god! You would have to break open the 'emergency pilot' cabinet and sit him/her in the seat. HEAVEN FORBID. Its only a 'clear ECAM warning', not the end of the universe.

[PBL]

Originally Posted by BOAC

Its only a 'clear ECAM warning', not the end of the universe.

Given the number of injuries resulting from a safety-critical system anomaly (a couple of broken bones and some serious bruises at Learmonth), compared with the number of fatal accidents in which advisory systems have been causal factors (Cali 1995, Überlingen 2002, Amazonas 2006, Schiphol 2009 just off the top of my head, and a bunch of incidents that could well have been fatal, including Air Transat's Azores visit, and BMA's Addis adventure), one cannot dismiss the possible safety consequences so blithely. I take it my invitation to think what would happen was declined?

PBL

[BOAC]

'I take it my invitation to think what would happen was declined'

Negative. Thinked at #1314.

[NigelOnDraft]

We're getting into too much detail I think... some who know very little about the Airbus (those who don't fly it), some who know a bit (those who do fly it).

First of all, AoA Failure ECAM messages are available, however, they are for heating failures. As alluded to above, detecting the AoA "failure" of it being frozen is difficult - it is giving a perfectly valid output. The only way of deducing the failure is to apply an algorithm to the AoA values and determine if they are "sensible" versus other values - but how do you now know if it is the AoA or the other (IAS?) value in error? AoA goes into the ADR (ADC equivalent) - and one would assume if the AoA value becomes invalid, or out of range, then that ADR will come off line.

If you try to apply a voting system then we have the ultimate quandry here - it seems 2 AoA values were almost identically in error, and the 3rd correct. Good job the logic did not outvote that one, which remained and gave the (correct) STALL warning.

Some drills do require pilot assessment - ASI discrepency for instance - to analyse and determine the faulty eqpt precisely because of the consequences of an "automated logic" getting it wrong.

As above, I still remain to see how the current design can lead to a credible accident scenario in normal ops. You cannot design an aircraft to prevent people having accidents when they choose to operate so far outside the "rules"... let us remember the purpose of the "test" - to check the AoA systems were acting correctly.

NoD

[BOAC]

Has the final report been published yet?

[NigelOnDraft]

I hope so... It's what we've been arguing about over the last 3 days

As in post #1223

NoD

[BOAC]

Thank you kindly, oh wise one.

I find it difficult to reconcile the pre-amble to Rec. 4 with the events between 15:45:19 and 15:45:23 - that does not look to me like

'impossible for the crew to be aware of the situation and to recover control of the aeroplane'

It looks as if all was going comparatively well at that time, and the failure to maintain forward stick, throttle back and trim then sealed their fate.

Is 99kts a realistic speed for a stall warning at that weight?

You say 'Good job the logic did not outvote that one, which remained and gave the (correct) STALL warning.' - surely it WAS 'outvoted'?

'However, the blockage of angle of attack sensors 1 and 2 at identical values had inhibited the functioning of these protections and led to an erroneous display of the characteristic speeds of these protections.'

to me says We will ignore AoA 3 until the actual stall warning? Back to the point that those of us (probably fortunately lacking in experience of this type) are making - is it not sensible to ask a system to make it clear that what systems you thought you had were obviously not in fact there - a fact really made clear only to the aircraft? I would wager that an average crew, given this information, might not rely on them.

This is not just about a rare event caused by incorrect washing. This goes to the heart of a system which encourages absolute confidence in Msr Ziegler's concierge's undoubted ability and then 'blows a raspberry' at the poor crew. We still do not know if or what 'automatic' dumping of information brought down 447 - and probably never will..

[DozyWannabe]

Originally Posted by NigelOnDraft

The only way of deducing the failure is to apply an algorithm to the AoA values and determine if they are "sensible" versus other values - but how do you now know if it is the AoA or the other (IAS?) value in error?

Got it in one. The other issue there is introducing another layer of complexity into the control and flight management software, which like all other engineering disciplines adds greater potential points of failure as complexity increases.

[NigelOnDraft]

BOAC...

I cannot answer all your points... as ever, what is behind the Airbus is not told to us as pilots... after all, you cannot know each software line.

However, before you say "I told you so", in fact some of the logic seems more robust than I had understood (which is not necessarily a reflection on groundschool or manuals!).

Stall Warning: Conventional understanding of the Stall Warning was that this could not occur in "Normal Law". It now seems that it is not "inhibited" in Normal Law, just the "Normal Law" protections should "act" (prevent you increasing AoA) to the extent the "Stall" warning is never triggered. What happened here was that High AoA protections, which the purpose of the test was to check, did not occur due to the frozen AoA values. The "Stall" wanring therefore did then get triggered, as they slowed, by the remaining AoA probe. So there is a "backup" to the AoA protection.

Is 99kts a realistic speed for a stall warning at that weight?

No idea... But my understanding of the report is it probably is OK.

is it not sensible to ask a system to make it clear that what systems you thought you had were obviously not in fact there - a fact really made clear only to the aircraft?

In the Test case, the Test Schedule gave the speed at which the "protections" should occur, and the test was to ensure they occured at that speed. This is not a "slow the aircraft until it goes bong" test, it is slowing it towards a **** great red tape on the speed scale. Therefore you half know the result of the test before you get there - if Alpha Max is shown as 110K, and the table says 111K, you have a pretty good idea all seems OK. If in this case, they are 20K+ different (cannot recall the numbers), you know even before you get to the speed you have a problem. This is the crux of the test - test protocol would anticipate the result and not sail 10K..20K below it going "errrr???"

I would wager that an average crew, given this information, might not rely on them

To an average crew, in Line Ops, the only time they should get anywhere near these AoA limits is in a "GPWS Pull Up", or possibly a "Windshear Go Around". The rest of the time we fly like your B machine - to speeds that unless you get grossly below keep you well clear of the stall/protections... although a crew should be familiar by experience at those red tape(s) sitting somewhat below the App Speed.

This is not just about a rare event caused by incorrect washing. This goes to the heart of a system which encourages absolute confidence in Msr Ziegler's concierge's undoubted ability and then 'blows a raspberry' at the poor crew.

As you might expect, I would not agree 100% The incorrect washing was but 1 factor. I am 99% sure that if the next sectors were flown by a Line Crew, there would have been no incidents, probably some PFR/Status/Engineering messages, and a moderately sharp crew would have queried the speed scales.

As ever, the tragic outcome took an exceptional event (2 AoA sensors abused by washing), poor approach to the testing (understanding what and why you were doing and no Plan B), poor decisons on the day (do at 10000' below the min stated Alt), and bad luck all the above got combined on the same day

I personally have learned some AB characterstics from this accident, good and bad, but see no need for a substantial change in design or SOPs or training. Some will no doubt disagree - however, the report largely does agree with my pov.

You quote some lovely Airbus folklore above - I think that largely got disspelled at Habsheim and Strasbourg. As with any aircraft, it has it's good points, it's bad points. The "protections" are rarely used - any SESMA / QAR monitor man will be after well before you get there

NoD

[BOAC]

Is it not odd, however, that the High AoA protections did/do not function with a single AoA input, but the stall warning does? I cannot understand the logic.

It is reassuring that the process of 'understanding' goes on apace - I hope the training system is keeping up, which it so significantly failed to do early on. You can preceed the Habsheim/Strasbourg with the Indian fatal, of course. It is not right, in my opinion, that the path of understanding of 'how it works'/'which mode are we in?' is littered with so many corpses. The Bernard legacy is, I fear, a legacy that will take a long time to wash out (and it is not 'folklore'!).

Dozy - I do not seek an 'uber computer' sorting out what is wrong and what is right, and would argue vehemently against introducing any further scope for confusion/malfunction - just something that clearly says -'this is beyond my software programme - beware' in big letters. I have suggested before the 'simple' warning 'tailplane trim excessive' for ALL types - that would help and requires no algorithms, calculus, transformations etc etc. Just a sensible limit.

[NigelOnDraft]

that the High AoA protections did/do not function with a single AoA input, but the stall warning does? I cannot understand the logic.

I have better things to do than read the manuals which you are making me do

3 AoA sensors respectivly go to 3 ADIRUS, all 3 of these are inputs to the Flight Control Computers. We are not privvy to how the readings are combined / prioritised. I suspect the report does go into more detail. However, I would say:

1. To action High AoA protections you need to be pretty sure you have High AoA i.e. a single rogue High AoA value must not lead to a pitch down etc. There may be more on this if you read up the IB A320 Bilbao incident, and the QF A330?
2. A STALL Warning is for crew assessment, and can be ignored. It is therefore more appropriate for a single AoA value to generate it, as happened here.

So my view would be the logic seems fairly good here?

NoD

[BOAC]

Yes, the logic is 'good' but I'd still rather know that the system is 'broken' and do my own thing.

I believe Bilbao resulted from a rapid change in AoA in windshear (on all 3 sensors) triggering a nose-down despite full back sticks, and caused a 'software change'. I have not looked at QF.

[NigelOnDraft]

I believe Bilbao resulted from a rapid change in AoA in windshear (on all 3 sensors) triggering a nose-down despite full back sticks, and caused a 'software change'. I have not looked at QF

Agree on Bilbao, albeit IIRC the "problem" was caused by a software change i.e. the original design did not have the same behaviour. Whatever, it behaved "as designed" just a bad design in that area... and essentially that change was then reversed.
QF, IIRC, the system did not behave as designed... but I think has some relevance here, becuase 1 (?) faulty sensor / determined value caused serious issues?

NoD

[PBL]

BOAC and NoD are now discussing exactly how it might be done reliably, that is, to detect two failed-live AoA sensors. It's indeed fun to discuss, and thinking of how to solve problems is indeed how to get them solved.

Let me, however, tell you what the answer is. You need 7 sensors to detect reliably when two of them are failing-live. That is a hard constraint. And no avionics designer in hisher right mind would seriously try to implement the algorithm that lets you do it with 7.

This result is thirty years old. It is contained in the paper Reaching Agreement in the Presence of Faults by my former SRI colleagues Leslie Lamport (who is still churning out the results that make him one of the top-ten cited people in computer science), Rob Shostak (who shortly thereafter turned into a serial entrepreneur, starting with being one of the two authors of the Paradox DB SW for the PC), and Marshal Pease (who is no longer with us).

It is very well worth reading, but I am not at all sure that anyone contributing to this thread has the necessary technical background to do so.

But, please, do remember the answer. Seven.

If you want to do it in general. If you want to do it just for some cases, but not all, you stand a better chance of doing it with fewer, but first I would recommend acquiring the skills that appear to be necessary to solve problems of this nature, vis., the paper cited.

Then, of course, there are constrained means of propagating the signals to trap and avoid the so-called "Byzantine" events. To do that, you would have to be an outstanding bus designer (algorithms again). I know an outstanding bus designer who is trying.

PBL

[BOAC]

BOAC and NoD are now discussing exactly how it might be done reliably,

- not really! BOAC just wants the computer to stick its hand up and say 'Excuse me sir, although I am so clever, I don't really know what is happening - would you mind awfully behaving like a pilot for a while?'

The answer is 42.

[PBL]

BOAC,

you just don't get it, do you?

PBL

[BOAC]

I think its the way you tell them.

[PBL]

Whatever.

I am just hoping that some other people can see behind the repartee that there is real science here -rather a lot of it in fact- that has something to say about the issue at hand. And might be motivated to look at some of it, if they have the skills. And get them if they don't.

PBL

[PJ2]

PBL;

Perhaps this will be judged thread-drift but the intention is a side-bar that may help understanding, including my own regarding this important and practical understanding.

The notion is necessary of course, because, unlike our anthropomorphizing of technical devices, they really do not have a mind and cannot "discern", anticipate or "remember", (I know there are exceptions) and so designs which can resolve such issues as are under discusssion, (and one's like the Turkish B737 Radio Altimeter failure at Amsterdam) are important to comprehend at least in part.

In the Driscoll paper, p.4, it is stated,

"The implications of the Byzantine Generals' Problem and the associated proofs to modern systems are significant. Consder a system-level requirement to tolerate ny two faults(which includes Byzantine faults). Such a system requires seven-fold (3m + 1 = 3(2) + 1 = 7) redundancy. This redundancy must include all elements used in data processing and tranfser, not just processors. The system also must use three rounds (m + 1 = 2 +1 = 3) of information exchange. This correspond to a twenty-one times increase in the required data bandwidth over a simplex system, (seven-fold redundancy times three rounds of information exchange each).

"To more easily identify the problem, concise definitions of Byzantine fault and Byzantine failure are presented here:
Byzantine fault: a fault presenting different symptioms to different observers.
Byzantine failure: the loss of a system service due to a Byzantine fault."

You reference "5" sensors. In my non-trained view I am slugging through the paper with much more to read/absorb, (and the Lamport paper) so I am needing to understand how the above comments relate, if at all.

If this belongs off-line I am happy to do so but thought the question and momentary diversion might be helpful to the main topic of resolving the question and helping understanding. That it has been around for thirty years means something and opens a number of questions as well.

PJ2

[BOAC]

Meanwhile sitting here at my Byzantine Fault Demonstration Device (a Windows PC) I return to the thread and the non-Byzantine event which caused what should have been a recoverable stall to result in a tragic loss.

Without the excessive tailplane trim this aircraft should have been recoverable, albeit via a hairy ride. Surely the focus should be on ensuring that it does not happen and that when that defence fails - as Murphy states that it surely will - that crews are able to cope. As pilots we can be allowed to gaze in wonderment at (and benefit from) the fruits of all the hunched programmers and whizzing slide-rules, but we MUST retain an element of healthy distrust in it all and recover the innate sense of when things are not looking 'right' and the basic skills to do something about it - like a Neil Armstrong moment.

Back again to LOC events, I fear.