takata,
Thanks for your very careful explanation. It was the word "leg" that I needed to be clarified. Anglophone crews usually use it to mean "sector", i.e., the whole of a flight.

P3s
 

I was a CRP of sorts or a P3 on Yorks in the 1950s. We had to have 4 on the flight deck for our trooping contract, for 40 Troops and one RAF AQM. After 230 hours as the fourth man, I did my "Legal Six " T/O and landings with the Chief Pilot. I was promoted to F/O. I must have been good, or impressed, because it was another 600+ hours world wide, from KIN to BKK, as the only other pilot on board, before I did another one ! (I had flown for a longer flight in a glider before my first flight in a York.)
Modern simulators must be better than the Link D2, or earlier, the Ryper Simulators I was trained with, (they were close to the present Control Tower) at Farnborough in 1945. I do not know how much they cost to run, once you have one, as opposed to what is charged per hour.
The early post war civil aircraft were "cheap to buy and dear to fly" ( Sir George Edwards said that he had sold a Viking for £ 35,000.) Now the pattern is reversed - dear to buy and cheap(ish) to fly.
Our passengers paid £75 (1952 pounds) from KIN to UK.
One of a number of French National Gliding Centres used to be between Toulouse and Carcassone. They used to be run rather like an Outward Bound set up, helped by the French Government, to encourage air mindedness...

I am impressed by the amount of ordinary Traffic which had to be available before anything had happened to AF447.

Stall warning means that the AoA has exceeded a threshold that is several degrees below the AoA at which the airplane stalls. Stall warning continues until the AoA is below that threshold value. IMHO 'twice in a row' means that AoA was just below that threshold, and small 'bumps in the road' caused brief exceedances.



The AoA in level flight at FL350/M.81/275kCAS is 2.55 degrees. 4 degrees is the stall warning threshold at M.81 and would produce about 1.42 g normal acceleration. I don’t think “gee” exceeded approx. 1.4 because it then becomes rather difficult to match several constraints imposed by the FDR data released in the BEA Update. At 10 degrees AoA, M.81 the airplane would be fully stalled, but that didn’t occur here but much later. According to the BEA, “pitch attitude increased progressively beyond 10 degrees” between 2:10:05 and 2:10:50. Therefore I think that the ‘mean’ AoA got close to but did not exceed the S/W threshold at this stage, i.e. the triggering of S/W “twice in a row” was probably due to ‘light chop’ causing some AoA fluctuations between 2:10:15 and 2:10:25.

Hi Chris - what I'm saying is that your initial suggestion was that the "G"-loading system would possibly trim the aircraft nose-up at stick neutral as the speed appeared to decay. What I mean by "calculation" is that if the aircraft systems know that there is an double or triple erroneous airspeed indication, it drops to a mode whereby any protection or flight logic relying on airspeed is disabled. Surely this should be the case with the scenario you're describing - while "G" measurement itself is independent of the air data (thanks A33z), the logic you describe requires that data to work. So without airspeed data, how would the FCUs know to trim the aircraft nose up to maintain "G"?

Hi, and welcome.

The problem with what you're describing - as with any extra logic - is that you get into the engineering reliability maxim, which is that the more complex one makes a system, the probability of introducing errors also increases. The pilots are warned with the current system - an ECAM message "ADR DISAGREE". It's easy for such messages to get lost in the heat of the moment when things start to go pear-shaped however.

Surely an attitude indicator displaying mostly blue would be a hell of a hint, however - and if you're trying to tell me that the ADI was not part of their scan, then that would highlight a terrifying oversight in their training (I suspect that isn't your position, however).

Also, at present we do not know AF's policy regarding training on the trim wheels. Svarin said that his current airline discourages their use, but he does not - as far as I know - fly for AF.

That explains the Captain's reaction, but not that of the F/O, who I believe came straight to the Q400 and did not spend any time on the Saab. They both pulled back hard almost simultaneously. It's a well-known tendency for new pilots to instinctively pull back on the stick when receiving a stall warning (or indeed any unexpected shock) and is something that has to be trained out early on. As I recall the inference from the NTSB report on human factors suggested that fatigue and exhaustion may have caused this instinctive reaction to take over.

I think if it was as simple as that then that information would have been released in the press note and the report would be coming along a lot sooner - along with a service bulletin or AD relating to the warning systems in the A330/340.

I suspect that the BEA are in the process of a long drawn out human factors investigation to answer that question - these things take time. I don't think they're holding information back any more than any other investigative agency would at this stage, certainly not for any nefarious reasons - I think they honestly don't know (or didn't know at the time of the "note"'s release) why the PF reacted in the way he did. So in answer to your later question (paraphrased) of "why haven't they released the final report?" the answer is simply because it is not ready yet. I've already said several times that I doubt the NTSB or AAIB would be under so much pressure to release information early from some quarters on this board in the way the BEA currently is. Why is that, do you think?

Yet you're still advocating more technical solutions to implement in the design - surely if you were *that* concerned about complexity this would not be the case? The logic implemented in these aircraft (and those FBW airliners from other manufacturers) is actually pretty basic in modern computing terms. Asi I've said many times before it also uses obsolete technology (and always has) because the characteristics of obsolete hardware were already well-understood.

With all due respect (and I do respect you - I remember you may well have "flogged [me] round in a Chippy" in my youth. For this and other reasons I will always think very carefully on the knowledge you share about aviation-related matters) - that's a bit rich.

We've had four threads and hundreds of pages, largely of speculation from people - some of them pilots - who nevertheless either do not/have not flown the Airbus FBW aircraft and/or do not understand the systems - including what they can/can't/will/won't do. These speculations have involved - among other things - wild theories about the computers going haywire due to a lightning strike, long-hidden software bugs coming out of hiding to neuter the unsuspecting pilots' authority and software designers and engineers wilfully ignoring pilots' input and building a confusing system out of hubris and a sense of superiority just for starters. Then we move on to the more subtle, but still noticeable digs at the technology - e.g. "confusers", "HAL", that old chestnut "Airbus one man/one dog flight deck" and an intent on the part of engineers to "reduce pilots to systems operators and monitors".

I realise that it is a privilege to talk with you all as a non-aviator myself, but if you can find me an aeronautical engineering forum where an undercurrent of disrespect towards pilots of that magnitude exists, then I believe you would consider it the height of rudeness and complain vociferously. Taking this attitude on the chin is IMO a small price to pay for what I get out of the time I spend on here, but I do ask that you think about what you're saying sometimes.

For the record, at present there is *no* evidence that the pilots were ever "confused" by what they were presented with. Alarmed, certainly - and with good reason - but not confused. There is also no evidence of any overspeed indication, no evidence of software-commanded flight controls outside of what was coming from the PF's sidestick and no evidence of any departure from their intended flight path which caused surprise. When the report arrives, we'll know better. It's also worth remembering that while we pore over the ACARS messages and the apparent crew actions, that the crew were not trying to diagnose the situation based on ECAM messages alone, but with a full set of available and functioning instruments with the brief exception of airspeed. I'm pretty sure that the "WRG" message, as I said before, was simply the FCUs playing catch-up with the already-triggered pitot data failure message, which would have led to the "ADR DISAGREE" message appearing on the flight deck. We're talking seconds and fractions of seconds here - in human terms, the computation delay was minimal.

HN39, OK but eventually the AoA went well over and the aircraft stalled. It is inconceivable that somehow the fwd speed got to 60knots unstalled, so at some stage it should have been continuous until the fwd speed did indeed reach 60kts. One can only surmise that knowledge of previous false stall warnings in UAS conditions were somewhere present in their minds but if the plane was flown upto and into a stall wouldn't the warning have been somewhat insistent ? Is there some other condition of validity which would silence it ?

Searching
 

PJ2
You may find Google more effective in searching PPruNe.
A search on "pprune pj2 rr-ndb" will show all your posts in which rr_ndb is mentioned and conversely all posts from rr_ndb in which pj2 is mentioned.

About 40 seconds later at 2:10:51 the stall warning was triggered again. The airplane probably stalled between 5 - 10 seconds after that, just before reaching its apogee of FL380 at 2:11:06. The airspeed probably remained above 120 kCAS during the descent. The low indicated speeds of 60, then 30 kt were caused by pressure disturbances at extreme AoA - the pitot pressure being lower than the free-stream total pressure and the pressure at the static source being higher than the ambient pressure.

- well, in respect of this thread, this one of yours is not.,

Hi DozzyWannabe,
Will this do?

"Flying for the airlines is not supposed to be an adventure. From takeoff to landing, the autopilots handle the controls. This is routine. In a Boeing as much as an Airbus. And they make better work of it than any pilot can. You're not supposed to be the blue-eyed hero here. Your job is to make decisions, to stay awake, and to know which buttons to push and when. Your job is to manage the systems."
— Bernard Ziegler, former Airbus Senior Vice President for Engineering.
Great Aviation Quotes: Piloting

*sigh*

We've already dealt with Ziegler on this very thread and others, at great length. An intelligent and gifted pilot with a flair for communication certainly, but some of the things he said weren't very diplomatic or clever*. Airbus has long since adopted a very different line, and dragging that old quote up is not unlike us software folks having a giggle at Bill Gates' alleged "640k should be enough for anyone" statement in 1981 - by which I mean it's an entertaining and valuable lesson in hubris from a point in history, but in no way relevant to the current state of affairs.

He was there to make headlines to support sales, not determine engineering practices, and as such I'm also pretty damn sure that there were Airbus engineers just as mortified by some of those statements as some pilots were.


* - As has also been stated, he is now a very elderly and frail man, so I have no wish to haul him over the coals again.

All the required data is available with current FDR´s?
 

Hi,
DW, The use of the "obsolete" building blocks is not a reason to allow a simpler analysis, as you know. My concern is if we really have a "sufficient recording" to understand EVERYTHING that (possibly) happened during certain moments. Suppose during a glitch (a time dependent failure, not stable). Like the one Svarin discussed or other possible reasons that could affect the "output" of the "engineering black box". The always concerning, Testability issue.

I am thinking on that and preparing to answer PJ2 and to CJ post.

I hope i am wrong with this suspicion. If wrong will be better. My objective is to raise only important and relevant issues.

I am busy during this week but "in parallel" watching the thread, posting when possible after considering useful.

One mo'time
 

Salute!

First, I'd like to address the concern/question by Doze.

You do not need "q" or total pressure to trim the jet for a gee ( Nz). And it is disturbing to find from A33Z that the FLCS uses the same attitude reference system that is displayed to the crew. Hence, I continue to question some basic design implementations for the 'bus. It is too easy for the FLCS to have internal accelerometers and rate sensors and even air data sensors besides those the displayed to the crew. A layer of redundancy and a "core" system we humans can rely upon. If those embedded sensors go to "east jesus", then we're flat-a$$ outta luck. Sierra happens.

There are too many autopilot and "convenience" features that degrade one by one until in the "direct law". TOGA for engines and FLCS, "flare", Alt 1, Alt 2, sheeesh!

Once there's a problem, the basic flight control laws should be very clear from an aero aspect and a crew aspect. We don't need bank angle "protection"/overspeed "protection" and such in various modes. What we need is a well-designed plane that has basic control laws that 99.9% of the pilots can fly using basic airmanship. And not be concerned with losing one thing or the other along the way.

The 'bus looks to be a very well designed jet, or you couldn't have a "deep" stall, or a deep stall, for over 3 minutes without going into a spin or worse.

So I will continue to advocate a very straightforward system that has a myriad of autopilot functions as "inputs", not "protections". Once the A/P disconnects, the jet reacts to pilot inputs in a very straightforward manner. I fully understand control surface deflection rates, aero gains, etc. I fully understand why the THS trims to retain elevator effeciveness ( will be a contributing factor in final report, IMHO). I would not want to fly a jet that moves the elevator or commands spoilers and ailerons at the maximum possible rates regardless of the "q" or mach. But when those values are unreliable, the jet must still be flyable and not have all the "protectons" commanding stuff that we pilots don't want or need at that moment. Just let us fly the basic plane!!!

sorry for the rant. ....

Moore ´s law affecting all designs
 

Hi,

DW:}

Now it has quietened down again, can I ask if anyone knows exactly which other bits of RHS 'important' data (apart from IAS) are not recorded?

Thank you, Gums.

K.I.S.S. plane behavior in all situations
 

gums

What we need is a well-designed plane that has basic control laws that 99.9% of the pilots can fly using basic airmanship. And not be concerned with losing one thing or the other along the way....So I will continue to advocate a very straightforward system that has a myriad of autopilot functions as "inputs", not "protections". Once the A/P disconnects, the jet reacts to pilot inputs in a very straightforward manner. I fully understand control surface deflection rates, aero gains, etc. I fully understand why the THS trims to retain elevator effeciveness ( will be a contributing factor in final report, IMHO). I would not want to fly a jet that moves the elevator or commands spoilers and ailerons at the maximum possible rates regardless of the "q" or mach. But when those values are unreliable, the jet must still be flyable and not have all the "protectons" commanding stuff that we pilots don't want or need at that moment. Just let us fly the basic plane!!!

Perfect! :ok:

Or a plane (a/c+crew) that never do K.I.C.S. things sometimes.

C.=Complex

Again, gums, where is the evidence that the flight computers did anything they were not commanded to by the handling pilot? The whole point of the graceful degradation in laws is that the guy in the seat notices as little difference in how he was handling the aircraft before compared to how the aircraft handles if something has gone south as possible!

You've basically just described the A330 (A320, A340, A380) and B777!

Along the lines of what Gums is talking about, It should be possible to measure roll rates achieved for small control deflections and then properly set roll gain after a loss of airspeeds thereby avoiding having to go to a roll direct law (Alt 2). Subsequent control inputs would update the gains. If in dead still air, the system could periodically recalibrate with small doublet inputs.
If wing flexibility causes delays in sensing, you could put accelerometers in the wings to get more timely information.

- may I (as an aeronautically trained engineer, of course...) ask you

Where is the evidence it did not? and

is not the second part of your para the whole nub of the accident? They would 'appear' not to have noticed.

Machinbird - yes, let's put even more electronics and gizmos in the loop to go wrong.:ugh: Look! We can have a whole extra page of ECAMS, bells, whoops and God knows what. What gums and I and a few others want to see is a stick that just moves the ailerons, and pilots who can use it..

BOAC, sir, I'm getting mixed signals from you.

I took this post of yours as a well-intentioned move to stick to the evidence at hand, and when I ask a reasonable question of gums - namely whether he has any proof that the aircraft did not do exactly as the PF commanded (suspecting that he has no more evidence than I), I get a dose of whataboutery from your good self!

I want to make it crystal clear that at no point have I directly speculated on the actions of the crew. I can assure you that any refernce I have made to other accidents such as Birgenair and Colgan Air have been purely for the purposes of providing background information. Am I now to understand that speculation on possible mishandling by the crew despite a largely functioning airliner is beyond the pale, yet myriad speculatory accusations of poor design and engineering practices putting the helpless crew in an aircraft that was, for want of a better phrase, trying to kill them is somehow tolerated?

Talk about your double standards...

Re HazelNuts39
 

Quotes all HazelNuts39
The speed was .8M for turbulence, as the crew stated. Or do you say, they where still in decelerating mode? The AOA value was reached by the sudden pitchup to 10° pitch, which needs an acceleration and changes the stall AOA significantly. I cant tell you the numbers for the bus, but an AOA gauge in front of my nose taught me that over a considerable flying time.

Which one, please elaborate.

On what fact do you ground your statement?
The speed sure as hell was already decreasing after the initial exaggerated pullup, so it was not .80 Mach any more after the start of the pitchup. At 02:10:20 FL 375 was reached graph from A33Zab, at 02:10:55 TOGA was selected and at 02:11:00 FL380 (apogee) was reached. That is a 500´feet altitude gain in 40 seconds. Its prudent to assume, that the initial climb rate was higher, decreasing to zil, and increasing again after TOGA selection (02:10:55 TOGA, 02:11:07 the speed was 185 valid and pitch and AOA 16°. So most of the beyond 10° pitch in that timeframe produced only AOA and not much climb at all.(Aircraft level flight at 10° pitch resembles 10° AOA. And yes, it was stalled, therefore the stallwarning was present and then TOGA selected.

It does not make sense to compute the angle of attack under steady and unchanged lab conditions. The ship was handflown with changing speed and pitch and later on power in unfavourable WX conditions with limited or no protections in an altitude they couldn´t reach just one minute before. Any change of pitch first adds to the AOA. and only leads to change of climb rate (and therefore flight path vector, which influences AOA) with a delay, if the lifties say "Yes" to the pitch change.

Our airliners and all other 70+ types of AC I flew had at most an aural warning when the automation failed if we had automation. The worst that could happen is you would have to put your coffee cup down and handfly the rest of the flight or until you could get the automation working again.

We never knew if they were going to work or not so when they worked we felt blessed. I felt the same in the Lear Jets and the Boeings. They are handy but not at all required for flight. My airline dispatched us in a new, to us, 737 from LAS to MSP and back with no autopilot and we took it because the MEL said it was legal when I was a new captain with a 1st time FO. Hand flying for 3 hrs each way isn't much fun but remember "Fate is the Hunter?"

A stick or a wheel should suffice for any airliner with a competent crew to get you to your destination no matter what fails.

Depending on automation to get you there is a recipe for disaster.

HN39, thanks. So in a known UAS condition the system took what it knew to be unreliable airspeed data to inhibit the warning ?

BOAC, What was suggested would allow the 'Bus to soldier on without getting worse than Alt1 law, without the need to seize the stick firmly, without any great excitement except quieting all the bells and whistles.
It is not a complex thing to generate once the basic calibrations are done in the design phase.

There is much to be said for allowing sleeping dogs to lie quietly. If the aircraft was out of balance laterally, the computer would handle it just the way it had moments before the AP disconnect. If turbulent, the wings would be stabilized. The only difference is that the PF would have to tell the machine where to go and to set the power since the Flight management system wouldn't be doing that for a while.
The next reversion down from Alt 1 would then be Direct law.

Didn't they have everything they needed; reliable attitude, altimeter and engine settings - why would any more help ? The problem may have been the knowledge that it is a complex system and therefore may fail in complex ways. All the imagined failure paths, fault trees and so on may just have prevented timely focus on what really mattered. So the automation failed them but itself wasn't at fault. Make sense ?

BEA's 275 kCAS at FL350 equates to M=0.808. Yes, pitching up results in an increase of AoA and vertical acceleration, and FPA, for example AoA=4.5, FPA=5.5, Pitch =10 degrees at about 1.33 g.

All of them: max 7000 fpm, min 700 fpm, 215 kt at FL375 at 2:10:50, maximum altitude FL350 at 2:11:06, just to name a few.
I don't know how that has been derived, I would put it closer to 2:10:53. I don't think the difference between CLB and TOGA at FL375 is that significant.
Between 2:10:15 and 2:10:35 pitch was reduced to about 5 degrees in order to reduce RoC from 7000 to 700 fpm.

I hope that explains the flight mechanics.

At that point the original UAS condition was no longer present, the pitots had returned to normal. But there was anew ADR DISAGREE condition due to high AoA, that also caused the low IAS value.

Dozy:

I’ll steer clear of the ongoing “Why can’t I have Chocolate?” discussion, but…

I’ll offer an analogy to the inertial sensors, which may or may not address this adequately.

In non-FBW fighter-type aircraft, for a given stick position (i.e. constant pitch control surface position) my body was an adequate sensor to determine commanded G was changing as a result of airspeed changing…without ever looking at the airspeed or knowing specifically what it was.

If G was dropping off I pulled harder (importantly only to a point). If G was building I relaxed the pull. Absolutely no direct reference to airspeed required, but directly a function of airspeed changing. I was a veritable human auto-trim system.

Don’t let them re-design me…

Relax; I agree, pilots are notoriously difficult to deal with.:)

Automation
 

Stick left or right will do it for A. or like any other brand let AP handle this. Already in the 70's you were flying 'Fooled' by Wire and once they remove your 'beloved' yoke and the cable loop which drives it and suddenly it is not worth to call it an airplane?

The brand with the yoke uses the same philosophy on FBW, they fitted some other stuff to keep you guys satisfied and used different naming but have also mode degradation, ADIRU's and Flight Control Computers and a lot of warnings and bells.

Because only AP or P(N)F can do that, if a remote! Failure in a FCPC would do that it would be rewarded with an outvoting and an ECAM message.

BEA:
"The thrust levers were positioned in the TO/GA detent and the PF maintained nose-up inputs."

On the T/L and SS only multiple resolvers (which can't drive the T/L or SS), the only input is by hand (or other object)

If automation can bring one to outer space and back, automation can bring you also from A. to B. and (for the skeptic) from B. to A.

DozyW wrote :

You need to realize that each successive software version, for the FCPCs, for example, would have a lifespan of around a year. Version 19 was out last time I checked. What is the age of this type ? So, a software "bug" (a very small oversight as I see it in detail) could have been introduced, less than a year before. This could perhaps help you realize it is much more likely than one would like to see. Especially as this gets mixed with a similar potential problem regarding ADRs from a different manufacturer ! But these things communicate together. All in all, quite a feat. There are bound to be some minor stuff from time to time, dont you think ?

By the way, if someone could please enlighten yours truly regarding the certification process applied to flight controls computers software versions released after the initial certification process, I would be extremely grateful.

The WRG message CMC time-stamp is 02:10.
The ADR DISAGREE message CMC time-stamp is 02:12.
Two minutes.
If you can provide a consistent theory to explain this gap, I for one will be happy to read it.

I do have a theory myself, of course. I explained it in multiple ways already. It is solidly based upon facts : ACARS messages content and timing, AMM, FCOM, BEA reports, schematics, design principles, multiple accident reports. When your theory relies on similarly solid background, we will have the opportunity for a fascinating discussion ;)

@BOAC
 

BOAC,oh come on; it's a bunch of peeps, with no access to the official, pertinent data, making it up as they go along.

Some have a clue, some more than others, some not.

Some have an axe [large/fictional] to grind, some not.

Evidence? the only evidence you'll get on here is advertising revenue.

Roll on the final report!

Note: NASA does not take off or land when there clouds in the sky.

Automation is great -- IF it is working. When it is all iced up it does not.

Something iced it up. Why was Weather Avoidance Radar ignored?

@Svarin

Mate, your theory is no more grounded in fact than anything I can come up with. All we can do at this point is wait for the report. I do however expect that if such a transitory software bug was introduced it would have manifested itself many more times than once by now. In any case the "bug" you're talking about could only have affected the displays. By the time they were in Alternate Law, the AP was off and the FCUs could not command a significant change in flight path. On top of that it is down in black-and-white that the elevator and trim movements can largely be explained by the PF's inputs based on what we have so far.

Having said that, like the "wear down fluid channels with contaminated hydraulic fluid -> freeze it -> pump with hot hydraulic fluid" process that finally unmasked the 737 PCU failure mode, this aircraft accident reverse engineering lark is a tricky business.

Automation & FCPCs
 

A33Zab wrote :

I agree that it can be done. But is it desirable, from a human perspective ? After flying, what else would you latch automation upon ? How many human endeavours will end up robotized ? What do we do while the machines do all the work and the rest ? Watch TV ?

Possibly, although you know I disagree. At the very least, I am greatly interested in the time it takes for the system to sift through the Byzantine generals lies, or power struggle, as I see it in the "PRIM2 reverted to Normal Law" theory.

Write books? Make music? Paint pictures? Solve complex mathematical/physics theorems? Design and build spacecraft to explore beyond our little world?

I jest, but the whole point of human endeavour is that it is supposed to progress. Being knee-jerk against something just because it might in several generations make one's job obsolete is a pretty dismal place to be. Do you think the night-soilmen of centuries past wanted their great-great-grandkids to be doing the same thing?

I think you underestimate how strict the development and deployment process of real-time safety-critical systems is. I'm not saying it's perfect by any stretch of the imagination*, but I think you do the people on the engineering side of the fence a great disservice by saying that it would be easy to introduce such a failure.

* - Just in case I haven't made it clear enough in the past...:rolleyes:

HZ39, when their high pitch reduced to 5 degrees after their 7,000 fpm climb bringing it down to 5 degrees doesn't that seem like what would happen after their zoom energy had been used up? At that point they were in a deep stall and about to fall like a rock. Too bad the captain wasn't there to help them out when they lost their airspeed indications. By the time he got there he must have been as confused as the copilots.

Basic control laws
 

Salute!

After private posts with members of this august group.......

Make no mistake, I do not advocate an instant reversion to direct commands of the control surfaces using an RC model logic. The FBW implementation allows many "tweaks" that we did not have in the fully-hydraulic systems that we lites flew 50 years ago. Even into the 90's, the heavies had actual mechanical connections to some things - imagine that?

My philosophy is a bottom-up control law that the humans can depend upon regardless of all the bells and whistles and so-called "protections" provided in the higher-tier modes.

It appears to this old fossil that the 'bus has really fine aero characteristic. Otherwise, I would have expected a spin or some weird maneuver. So I question all the bank angle "protections", the seeming multiple AoA "protection" modes, and the beat goes on.

With autopilot engaged, all of the neat features seem logical for reducing workload and making things nice for the SLF's. But when things turn to worms, there has to be a basic, core control law that utilizes all the benefits of FBW and yet exploits the aero design/characteristics of the jet.

As with OK, don't take my seat-of-the-pants sensors away from me. I shall overcome the "leans" in prolonged IMC with no autopilot engaged and maintaining 10 or 15 feet from my flight lead. Some glances at the ADI and other gauges shall save me from my belief that I had been flying inverted for the last 3 minutes, heh heh.

In my second career ( afer hanging up the g-suit), I worked mostly on the crew-vehicle interfaces for the more advanced jets. Working with the end-users, we always had a straightforward means of going to a well-understood, basic display or mode. One of my "laws" was "if you don't like what you see, hit another button". our sfwe engineers implemented extremely rigid state machines that simply would not do weird things based upon weird inputs. If an input was not defined, the machine just sat there waiting for another switch or aero condition or seeker acquisition or ..... If you wanted to start over, then we had the 'start over"button, heh heh.

later,

At that point they had about 215 kCAS and were not stalled. If they had maintained that nose-down push a few seconds longer they would have avoided the stall altogether. Instead they pulled nose-up, increasing pitch, AoA and rate of climb, using the remaining zoom energy to reach FL380, and stalled.

P.S. Fourth update on TE-plots Fig1v4, Fig2v4, and Fig3v4.

I'm not sure you can say that (and this one of the very few things you have said that I disagree with).

From the evidence:

The PNF at least very quickly realised what was going on, a matter of seconds after autopilot disengaged

• At 2 h 10 min 16, the PNF said "so, we’ve lost the speeds" then "alternate law […]".

No confusion there whatsoever, in fact the BEA are telling us that the FD acknowledged that they pretty much realised what the critical information was within seconds of the aircraft handing over control..

But later:

• At 2 h 12 min 02, the PF said "I don’t have any more indications", and the PNF said "we have no valid indications".

That, to me at least, indicates confusion. Either

1) There were no valid indications
or
2) They misunderstood, or were confused by, what they were being shown

My money is on 2)

Confusion of that nature can possibly be caused by
1) Aircraft limitations
2) Pilot limitations
3) Combination of the above

We don't know which of those it was, and the answer (if it can be found) is probably key to the reason why the pilot input was mainly nose up (fact) and the aircraft subsequently stalled into the ocean (fact)

Gums, you've neatly summarised one thought of mine that I have not had time to elaborate fully (and don't at the moment either, but will raise in summary form).

From a human interface standpoint, the idea of multiple "laws" does not seem to me to be the optimum way of structuring things, trying to remember what is or is not in each law. My own intuition is that it would be more intuitive to have a clear indication of what "protections" have been lost that you formerly relied on.*

It would therefore seem that the better way would be:
(a) to know through training what "protections" you have when things are "normal";
(b) when things go wrong, errors are expressed in terms of each "protection" that is lost -- one indication for each protection lost (or, where there are multiple levels of degradation, what degree has been lost and what is left).

So that where one or more protections may be lost depending on the fault, your attention is specifically directed to what you no longer have - (eg simplistically: no rudder travel limiter, no abnormal attitude protection, or something like "no autotrim available - check trim and trim manually" etc). You wouldn't have to think in terms of "law", but rather in terms of dealing with the indication of what has been lost and what you might have to do in response.

This might assist where there is some obscure or not easily remembered (or easily overlooked) protection that is or is not lost when in some sub-law -- to try to avoid the situation where you don't realise you have or haven't lost something.

I realise that since I am not directly qualified to comment, and I am working off what I have gleaned here about laws and sub-laws, with permutations of outcomes. I have not had time to sit down to check this objectively, though, which I would normally do before posting, and won't for quite a long time due to work. so I apologise for that. If I am wrong, and this is effectively what happens now, then what I suggest may at best be a distinction without a difference.

* In CS terms, the point is sort of that laws are effectively "modes", which is what computers are good at but humans aren't as much. In my experience, people are better equipped to deal in terms of the contents/specifics/characteristics associated with a mode, not the fact itself of being in a mode.

Pitch / Thrust in UAS.
 

Finally found it, it is in BEA report #1 page 122
It is in french so I skipped it in previous reading:

"Procedures anormales"
Urgence / secours

CONFIGURATION LISSE

Au dessus de 190T; FL 250 a FL 370
Vitesse 260Kts: Assiete (Pitch) 3.5 / POUSSEE (Thrust?) N1 90%

In comparision to my Hi power ground run tables
90% N1 ~ 80% thrust (temp effects taken in account)

Another 20% is a considerable amount of thrust (and pitch-up) they put in when moving T/L to TOGA. (=100% thrust).

IMO was the first action of capt. to retard to idle, and demanding a ND command. He did realized what was going on.
Unfortunately he couldn't see the position of THS (if F/CTL SD page not selected) and if not already too late to recover.