Maybe I am missing the point here but the AOA's didn't fail. Why is that so difficult to understand.

The AOA's became fixed due to ice because water enter the sensor housing due to inappropriate ground equipment being used.

The AOA's presented their signal output to onboard systems after they froze at 32,000 until the end. You cannot pre-empt that scenario. You cannot detect that event you can only at best warn of discrepencies between the 3 signal sources.

But the dilema of selecting which of the three is faulty has been at the root of previous accidents. Not just involving air data sensors (Korean air 747 adi)

I was using "failure" as a general term in the sense that they were not providing correct information as opposed to the sense that they had completely ceased to function.

Why would they be warned? Strictly speaking, the probes did not fail and it's not an anomaly according to CD 25. They were blocked but they kept working. Not as designed, for sure but there was no (love that Airbusspeak) unequivocal indication of failure. Even the intelligent systems would have problems deciding which data is correct, let alone unintelligent ones, like computers. Two of three agreed so it was simple task. Of course, monday morning quarterbacks now know better, quoting aviation laws while having no basic understanding of the way things work once we slip the surly bonds of earth. 'Tis a pity PBL's plea for the better solution will have to go unanswered.

Subtle failures are not Airbus specific problem; they are aviation specific. Aeroperu 603 had similar problem: blocking of all static ports due to non-standard (transparent) masking tape used to protect static port during washing and not being removed afterwards. Everything worked perfectly during takeoff roll, troubles began when trapped static pressure lost semblance to actual static pressure and the crew was bombarded by the warning for faults that were non-existent. At one point they got stick shaker and overspeed simultaneously and finally, exhausted with battle fell victim to assumption that ATC alt readout is correct one. Do we blame Boeing for that?

I do agree that having one ADC outvoted for considerable period of time, let's say 15 sec, would be nice to have annunciated via ECAM. However, aeroplane is designed to work perfectly fine with 2 out of 3 operative, it's flyable with all 3 failed and Airbus philosophy is to reduce the nuisance warnings as much as possible so this might go against their grain. IIRC if the aroplane was CAT III DUAL at takeoff, outvoting of ADC would change that to CAT III SINGLE. Yes it's subtle but it's on FMA part of PFD. I tought it was a joke when on introduction to Airbus I was told that FMA is primary flight instrument but was quickly persuaded otherwise. That's also the place where USE MANUAL PITCH TRIM is displayed.

Regarding CHECK GW, it was drummed into me that it's to be taken very seriously because it can be result of either:

1. entering wrong ZFW - most often and easily corrected
2. being secretly grossly overloaded - not a chance for European scheduled operation
3. FACs preparing to turn their little electronic backs on you - very unlikely yet possible. Good luck with this one.

I was mere line F/O, not allowed to go anywhere near flight testing. Lucky me for having instructors that understood Airbus very well and regarded "smart aeroplane" merely sales pitch BS.
They never interfered and that's where the real troubles begun. When the aeroplane started tumbling, all protections went off and only G protection ws recovered before making the water contact. I find neither crew performance nor end result satisfactory.

The AoA sensors most definitely did fail. They did not provide correct information about the AoA; those that froze provided incorrect information.

The usual definitions of "failure" have something about not fulfilling the intended function.

Now, you may like to argue, given what you said, that they were not faulty. I would argue they were not faulty, for example. The reason they were not faulty is that a known requirement for correct operation was violated; they were used outside of the intended and prescribed environmental parameters. I use the word "fault" to mean the cause(s) of a failure while operating inside the requirements.

I think you can detect it, under certain assumptions. Assuming that other sensors (pitots and static ports) are working correctly, you can detect it precisely the way that Airbus says that crew can detect it from the instrument readings. The question is whether you would want to go that route with the systems; assuming that the pitot-static systems are working correctly is not universally valid, as we have learnt from the Birgenair and Aeroperu accidents, the A320 rainstorm-contamination incidents, and the ice-particle-icing incidents with A330/A340 series aircraft.

PBL

So we made successful descent into semantics, namely what does "failure" actually mean.

My viewpoint is that CS 25, applied to measuring systems, refers to failure in strict sense: measured output being nonexistent or obviously out of realistic range (e.g. AoA of 400 degrees). Those can be easily detected without any crosschecking. Failure in broader sense of "not fulfilling the intended function" might be impossible to detect without being aware of the big picture and realizing which details don't fit. Despite its shortcomings, I do maintain that this task is (for the time being) better left to head mounted computer.

Now you've mentioned them, there is very significant difference between Birgenair and Aeroperu. Despite having only one pitot blocked, Birgenair crew has inexplicably decided to put its faith into the only datum in cockpit that was wrong. Simple crosschecking of two remaining ASIs would show that no1 ASI was at fault, if its failure during T/O wasn't hint enough. Aeroperu crew was deprived of each and every source of static pressure so simple crosscheck wouldn't do. That they were bombarded by alerts for faults that were nonexistent did not help their situational awareness at all.

Sorry for my naive question but 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 ? If agree that it was very difficult to diagnose the AoA sensor problem alone, but when compared with the great many inputs from other systems I would venture to say that the crew might have been warned in an unequivocal manner...

Some interesting and more relevant posts just above ;)

atakacs Why? What would a line Airbus crew do with such a message? What would they do differently, in say conducting an Approach Brief and landing having received such a message?

NoD

That was my point re: human factors. Despite there being a logical path to determining where the technical fault lay, the fact that it was the Captain's instrument that was wrong and he was the handling pilot at the time created a fixation on the reading of that instrument. This was compounded by the extra warnings they were getting (specifically the audible overspeed warning) seeming to confirm what that instrument was saying. The sensory overload precluded the FO from cross-checking his ASI with the standby ASI and correctly diagnosing the fault.

It's drilled into pilots from their first flight - trust your instruments over all else. When the instruments provide unreliable information you're in a very dangerous situation and need to get out of it as quickly as possible. What the report about the ANZ A320 incident seems (quite reasonably) to be saying is that in a test flight condition you need to presume that the information you are given may not be correct and give yourself an extra margin of safety accordingly - this was not done.

I've been wondering the same thing
 

Quote: Mickjoebill "?How do they do that?"
Anyone have an answer?

For what it's worth, as I read the report, they didn't actually detect fresh water in the sensors. Instead, they recreated how rinse water could have entered them, then proved that if that happened, it would freeze at altitude. Why they wrote "fresh water" and not just "water" is beyond me. Unless it had something to do with the report being translated from French (assuming it was).

Re the "fresh water", please give me the page in the English-language report and I'll try to make sense of the corresponding French text.

'I haven't waded (no pun intended) through the entire report yet.

CJ

Something to do with saline having a lower freezing point perhaps?

Thought it was quite strange going off the CVR that the german crew say twice that they have run out of time at altitude to do the low speed tests so they will do it at altitude on the climb out enroute back to Germany or not at all. Though the Air NZ pilot isn't shown on the CVR as replying to this it did appear at the time as that's what they were intending to do.

Then ATC get them to slow up at low level on the approach back into PPG and while slowing the Air NZ pilot suggests they continue to slow enough to get the low speed tests done as well.

Shows how easily a crew can be swayed into a situation that up until that point they had agreed they wouldn't get themselves into.

Well I guess any pilot might be interested to know about a discrepancy in the sensor readings. Personally I don't think the aircrew should be insulated from known / detected problems for it's own good...

Christiaan,

The reference to fresh water is on page 90 of the English version of the report (with further ones on pages 91 and 96).

As a line Airbus yourself, you would take great care to confirm and even maybe to correct all the limit speeds as displayed on the speed tape by using your QRH ...

AoA sensors are much more than "stall warning devices"

In the Perpignan case, the crew would have politely proceed for a full stop.
Does it make a difference ?

Don't rush or bend the rules.
 

Let us remember this was a Post Lease Handover from XL Airways back to the original Owner.

The Owner had their people sitting in the A/c and seemed to have accepted the flight planning and profiles themselves.
This is all usually discussed in detail prior.
So at least 5 "qualified" Pilots/Examiners/Engineers were ALL in agreement!

The PF - acting as a TRE on both Boeing and Airbus at the time clearly had no idea of what he was flying himself into finally.

The technical failure of the A of A sensors was overlooked or not discovered in time.

The PF elected to perform a series of Checks outside of recommended profiles. I come back to the others who also seemed in agreement including Managers on the ground.

The PF seems to have accepted or initiated these Checks, even if not originally planned, but perhaps as a last minute decision to "Check Off some boxes"..

No doubt there was huge financial and time pressure on this Handover. Remember XL Germany was/is a small operator and even small contract fines on such Handovers can be very costly. Plus they were happy to get rid of the A/c ASAP.

So the slices began to line up.

Lesson learned by me.

Regarding ATC Involvement :
 

Let’s look at this with an open mind; ATC was not responsible for this accident, but is one of the holes in the cheese barrier.

Why ? is easy for us (ATC) to understand per perhaps not for all pilots here. So let me explain, so that , at least to those reading this, you might avoid the same fate in the future if you find yourself in a similar situation.

ATC in Europe is multi-layer . Like pancakes belonging to different entities.. For us , TWR, APP, en-route are totally different things . Coordination through the pancakes / entities involves a lot of work. Today many TWR controllers are basically trained for TWR duties only and are not in the loop of what are the procedures done en-route. So much so that they even can belong to different companies with different procedures. An example : In Germany TWR controllers in say, Dortmund, will belong to the TTC company, the middle low level radar centre (until FL240) above it will be located in Bremen, 100 of Kms away, and belonging to the DFS, and the airspace above that will be controlled from Maastricht, in another country belonging to Eurocontrol.

For us ‘ ATC” is not a generic term. And for a pilot Asking “ ATC” or getting approval from “ ATC” means in fact getting approval for the airspace that controller is responsible for, not for the whole flight profile. To a pilot it means differently of course. The telephone conversation between the TWR controller in Perpignan and the Capt is revealing of the misunderstanding to that effect.

Perpignan is a very large airport with very little traffic, like many today in Europe. EAS is one of the main local employer . Relations EAS-ATC are close and everyone wants to help, and assuming the local flexibility will extend further, But what is feasible in that local environment, especially with very low traffic, is not necessarily transposable elsewhere.

The flight plan issue is another good example. It would appear that the XL Captain counted on EAS to do the proper FPL paperwork while EAS expected the Capt or XL Ops to do this. As a result a few ( more than one ) PLNs were filed that day , none of them correctly, in the sense than none described what was intended in reality.

Performing test flights maneuvers in European en-route controlled airspace is very much traffic dependant. Asking this at he time they asked in a busy Bordeaux sector ( Gaillac) was not going to work . Not in France, not in anywhere in core continental Europe for that matter . I have many times in my career authorized Flight tests, but refused a lot too. It depends on the traffic , period. I do not have to provide an alternative neither( I would not know where to send the aircraft to.) if I am busy, my priorities are to separate and expedite the other traffic, and keep the frequency clear, not to engage in Flight tests negotiations on the R/T. Not an excuse, just explaining how we work.

So if you have to perform flight tests , or acceptance tests maneuvers, if it is long ( say more than 10-15 min ), make an airspace reservation request a day or 2 before, like manufacturers and large airlines do,. You will be assigned a reserved airspace and a dedicated frequency to work for as long as you want .
If it is for a short duration, make a RMK in Flied 18 of the PLN indicating what maneuvers you want to perform, and call ( or have your Ops call ) the supervisor of the en route ACC in which airspace (FIR) you intend to perform the tests, and get his approval . He might, like I always did, suggest a quite time period, or an area, where your chances to get what you want are better. The TWR controller is not the best person to do this with.

There is unfortunately far too little “ bridges” between ATC and Flight OPS. ATC is there to help, but certain things are not always feasible as they used to when traffic was lower and available airspace bigger. I find it personally disturbing to see more and more accidents recently where ATC was one of the “holes” in the cheese. Closing a hole is most of the time very easy, but unfortunately afterwards, always afterwards.

I have not read about the 'fresh water' but surely it is a reasonable conclusion to draw that if it is deduced that 2 out of 3 probes 'failed' and it was again 'reasonably' assumed that freezing of water was the cause of this unlikely event, that it would be 'fresh water'?

I come back to the point I and others have made. Because of the 'trust' that appears to have been ingrained into AB pilots in the past (although I suspect people are slightly more wary now) that the wonder jet will protect you, it appears that this crew 'assumed' the same mental state. The low speed protections will activate. These protections, despite the denial of some, incorporate AoA readings. AoA readings/inputs are TOTALLY un-necessary for the operation of an aircraft, AB included. Why fight the simple suggestion that when a system vital in the mantra of the aircraft operation is compromised, that the crew are told CLEARLY and UNEQUIVOCALLY? Then they can resort to relying on basic flying skills (if they have any - see other thread) to fly to a safe landing. Is this not 'a reasonable technical discussion'? Certainly not a 'requirement' that is 'currently infeasible'.

I hope the AB training system, which has been so faulty over history, being behind many aircraft losses, has finally caught up. "It's an aeroplane, Brian". "Aeroplanes bite fools."

atakacs,

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

PBL

- 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.

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

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

Negative. Thinked at #1314.

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

Has the final report been published yet?

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

As in post #1223

NoD

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..

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.

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.

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

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???"

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.

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 :ooh:

NoD

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.

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

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.

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

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

- 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.

BOAC,

you just don't get it, do you?

PBL

I think its the way you tell them.

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

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

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.