RR_NDB

Hi,

Let me put slightly different:

Is there "technical limitations" not allowing the "slowly return" of A/P after the "inputs" became normal again?

My rationale is to provide crew ASAP a full set of tools in the order to make easier their task under difficult conditions.

I understand the "discontinuity" typical when automated resources enter or exit during "transitory".

Mac

RR_NDB

Hi,

Looking to the safety aspect we may say ii would be good to preserve some functions of the A/P after anomalies are presented to inputs of the System.

AS not valid during the transitory (when AS is not briefly valid by any reason) is not necessary to "roll corrections".

My rationale is:

Every effort should be made from the designers to "present a machine" capable to help the crew most of the time.

It seems the GIGO approach (used by IT professionals) could be better applied in an A/C for the sake of "Graceful Degradation" of the (effective) A/C, when PF is "suddenly inserted" in the "great loop".

The Stability of the System was affected by "tiny ice crystals" and IMHO the System could be designed (with about the same resources) to better "handle" similar situations.

Before, for example, better AS sensors are available.

(*) By "effective aircraft" or "effective system" we call the System + PF (when plane with it's automated resources has PF inserted in the "great loop"). Such occurred when PF started to hand fly F-GZCP that night.

Lyman

RR NDB

Howdy, you make a strong point (s). "Transitory". Not for nothing is the word "transition" heavily used in aviation. At the out set, the underlying focus is generally on the loss of autoflight, and the inability (apparent) of the crew to do some simple things, with skill and speed.

"Do nothing". Wise and elderly pilots here have said this is crucial. Do not start something that muddies the water, to eventually exclude knowing how the a/c is reacting.

Then, Set "Pitch and Power". Use a table, to select appropriate settings, if low, level and troubleshoot, if high, await the return of accurate A/S.

There is a stark chasm between the loss of automatic flight, and the manual control that followed.

For instance, the autopilot started to "do nothing" the moment it quit. It did not reset Pitch and Power, though of the two flight regimes, it was better equipped to do it. The protocol at the time was to set the two after consulting a table.

Does the computer not know the correct P/P? Of course it does, its memory is nearly foolproof. Whilst the computer knows the settings, the life of the a/c depends on pilots using a loose leaf reference, which they must locate, then consult?

So, the computer has already accomplished that which the designers have said the crew must now do, to save the flight path.

I had an instructor once, a Naval aviator whom I admired greatly. I asked him once what he disliked most about flying. He said.... "surprises".

Thus transition. RR NDB you eloquently state "graceful degradation". "Degradation" is an unfortunate term, no? The bottom line here, for me, is the apparent lack of attention and design invested in the transition between one regime and the next.

Should the computer handle the "middle ground" in a/p loss due UAS?

At this critical point, the a/c is left in the middle, to include the passengers.

It is easy to say the crew were not up to the task. Until the final report, and more important traces are available, I make no conclusions. I only ask that folks here try to remain doubtful of the entire context, and not judge ahead of time.

most respect to all.

RR_NDB

Hi,

Bear:

I had an instructor once, a Naval aviator whom I admired greatly. I asked him once what he disliked most about flying. He said.... "surprises".

I would include most surprises presented by "she". This includes A/C.

LOL

RR_NDB

Hi,

Bear,

apparent lack of attention and design invested in the transition between one regime and the next.

And AFTER the transition, during the next "state".

For example:

From apogee to SL the man-machine interface did provide the (entire) crew the required information (in the proper way) to even understand they had an ETA (to SL) in ~4 minutes?

Apparently a "surprise" was presented (understood) after crossing 100.

RR_NDB

Hi,

Bear,

Quote:

It is easy to say the crew were not up to the task.

The task (mission) had to be accomplished not just by the crew. PF inherited a task he was not even (adequately) trained for.

HF study (being performed) could reveal why "mission" failed.

3 crew members tried hard and "barely understood only near the end".

Lyman

I seldom mention intuition, but here an exception. I feel there will be surprises in store that soften the blame on the pilots, and offer some mitigations that will help us understand. Noisy airstream, full power at 16 degrees NU for three minutes does not compute. Not even to a valet. There is something here, be it only hysteria/poor displays. HF indeed, it will be informative, and life saving.

It is clear they never grokked STALL. Last command......"Pull, PULL, PULL...."

RR_NDB

Hi,

If what we learned (from BEA) is adequate to inform us, specially from apogee to SL, we must be impressed how the man-machine interface failed to provide reliable resources to allow the crew to just aviate.

The biggest surprise to me was this fact. During 4 minutes an entire crew (CPT partially) was not capable (or not well informed by the System) to do this basic and essential task.

More important than obsolete Pitot's, persistent NU from PF, inaction from PM, etc. is this fact, imho, in the analysis, in order to improve the safety of the equipment.

They worked ~4 minutes (man-machine interface and crew) with a near complete (*) fiasco (the interaction of the crew with the A/C through man-machine interface) and a total loss in the end.

We need to wait to conclude on the magnitude of this fiasco. We may receive additional info.

(*) When closing in to SL the imminent end was realized. Too little, too late.

Organfreak

Not as if this hasn't been mentioned already, but let's not forget that, as far as we know, both pilots had very rapidly unwinding altimeters. Those who suspect that PF's displays were farkled have more ammunition for their beliefs thereby, but we really don't know, once again, what PF saw. But really, if neither of them had the altimeter in their scans, that would be shocking. I say this in opposition to the idea that they didn't have enough information to fly the plane.

RR_NDB

Hi,

Organfreak,

Quote:

I say this in opposition to the idea that they didn't have enough information to fly the plane.

When i comment on the man-machine interface i am looking to the "global picture" the crew were submitted.

My simple (K.I.S.S. one) feeling is:

The man-machine interface should be improved. "Bus drivers" would like.

I am not saying to replace SS, etc. Airbus SAS certainly knows very well what to do.

And authorities (based in HF group) should act.

For the benefit of the entire industry.

We do not have enough factual info. on that. We need to wait.

I am just trying to be better prepared to evaluate the conclusions.

Lyman

Organfreak

Indeed, the altimeters. Their conversation from the beginning revolved around v/s. Especially at the end, they were quite aware of their rapid descent.

The only explanation is that they believed their nose was low, not high. How? The PF especially with his insistent pull. I think PNF eventually signed on to the Nose Low concept. Also Captain. So if true, the three of them reached the same false conclusion, though at different stages. One cannot dismiss the tacit power of the one with the controls. It is extremely difficult to justify a takeover, unilaterally, absent a plan, which none of them had. "Let me try" sounds cool, but given the stakes, all three acquiesced to the alpha dog, the PF. By default?

I doubt the "Lone Stick" theory, if they had instruments, they knew what was up with Bonin's SS. That alone may have helped convince the other two PF had a plan. It was not out of panic, wholly, that they all pulled, at the last. I believe they believed they were without a single cue upon which to base a recovery. Don't ask me how.

One thing. In ALTLAW2, the STALL WARN bug is absent from the speed tape. For what its worth.
adios O/f

RR_NDB

Hi,

Bear,

How?


You told to Organfreak to not ask you.

Lyman

Mostly from the lack of discussion re: the various instruments. PNF essentially was the last one to base his "get" on instruments, save Captain's Rudder comment, late. The scan may have been conflicting, or volatile. They set the stage for loss of trust on instruments at the outset. With help from the instruments, to be sure. Our picture has developed from data they did not have, accelerometers, traces, trends, graphs, etc. Can anyone say, that from this CVR data, that the instruments were reliable, and the Pilots proceeded as if? No.

I will be most disappointed in BEA should further data serve to explain their predicament to us, having allowed such condemnation to prevail thus far.

Hasta manana, amigo.

HazelNuts39

No, it isn't.

Lyman

HazelNuts39.

Yes, it is. I could have been more precise, sorry, but here is my reference.

"...In cruise at Mach 0.8, the margin between the flight AoA of the STALL WARNING is of the order of 1.5 degrees, but the STALL WARNING speed displayed on the air speed tape (in ALTERNATE or DIRECT LAW) will be around 40 knots below the actual speed. The value of the angle of Attack is not displayed directly to the pilots. The angle of attack is the parameter that allows the STALL WARNING to be triggered, but the activation threshold of this warnng is indicated by a marker on the airspeed tape. When the ADR are rejected by the flight control computers, this marker disappears." (my bold).

BEA #3 pp. 20,21.

Suffice to say that the time when this marker would be important, is when the speed window incorporates speeds (low) aroind the AoA for STALL WARN. The speeds are low because of FMC ADR rejection, so the marker is missing, just when it is imperative to be present?

HazelNuts39

Hi Lyman,
I'm impressed. Another quote from Interim Report #2:
We don't know if and when all three ADR were rejected by the FCPC's(*), but IMHO it is unlikely to have occurred before 02:11:40. The (second) stall warning was triggered at 02:10:51.

In your quote the part that reads "but the activation threshold of this warnng is indicated by a marker on the airspeed tape" is strictly speaking only correct for flight at 1g.

(*) In my understanding that condition triggers the ECAM message F/CTL ADR DISAGREE, which according to the ACARS transmissions was generated in the minute commencing at 02:12:00.

P.S. When the stall warning began at 02:10:51, the right PFD was showing 121 kt. The stall warning speed VSW would have been close to 216 kt, the speed shown on the left PFD while the LF was close to 1. In other words, VSW would have been off scale for the right PFD.

RetiredF4

I´m not saying that the discussion about improving the system to prevent those events is wrong, quite the contrary.

However, let´s not forget, that the crew should be in the great loop all the time, also when "George" is doing the handywork. At least that was the way pilots had been trained when the aircraft was designed.

RR_NDB

Hi,

RetiredF4,

When you are monitoring (PF before SS use) your entry in the loop should be done (ideally) with an understanding of why you are being called for. In order to allow you to have better chances to act precisely and fast enough to apply the right corrections (normally required). This was necessary (roll).

When i think on the man-machine interface i consider it's characteristics not just during abnormal situations or emergencies. IMO it should be designed to keep PF very close to the loop. In an effective "hot stand by" condition. And automatism must take into account HF related to how "hot" (aware) and prepared the crew is "put" (kept)

In summary, a professional must always be prepared to any scenario. (*) Even outside the (not acting) loop we should be "in the loop". In "parallel"

An analogy could be on the "synchronized processors" in certain fault tolerant Systems. They are working together in a "hot stand by condition" and can perform immediately if required.

In high speed vehicles (land) or near limits (e.g.aquaplaning threat) i learned it is better to "fully enter the loop" before any chance of LOC. This analogy is to agree with your rationale on the need to be "in the loop": I had an incident (with no consequences) in which i put myself in the loop, before. When the problem started (absolutely predicted and anticipated) i was yet in the loop (i started the maneuver applying a familiar large amplitude stimulus). After a surprise (vehicle reaction much different than normal) i performed perfectly the correction. But had no "maneuver room" to complete the task and eventually capsized (at very low speed) due a water drain hole at road side. When i left the vehicle (by the rear window i detected TWO flat tires (at rear) that explained the different behavior of the car (was not my one at this rainy night trip). This car had CG well ahead and used tubeless dangerous to detect when flat (difficult or even impossible to detect "on the fly" or even visually when parked) with low car weight in the back. This was my only "incident" (just testing the car after a previous LOC) since 1963, when started to drive cars at higher speeds.

In this case i remember i made an analogy of me as having two processors and their specific software (algorithms). When the 1st one didn't find the "car behavior" in the data base it dropped and put the 2nd to act. The second was used in a "emergency inside an emergency" and was capable (allowed me) to "calibrate" the correction stimuli. The adrenaline was enough to give me enough time to think (in "parallel" during the maneuver: How i would say to my friends i had two incidents in the same night? (because after not detecting the reason of the LOC (1st maneuver some 30 minutes before) i decided to understand why it happened. And later realized the first LOC was due just ONE flat tire. At cruise speed. And the 2nd with TWO under "test speed" some 50% lower.

In next day i concluded (in the local of the incident) it was fine to test because if i used the car (at cruise speed) with TWO (undetected) flat tires, the chances to suffer a serious accident would be enormous. It's possible to see all tire marks in the road (asphalt) very weak in next day (sunny) despite incident occurred at wet surface. (light rain)


(*) 5 Gorillas joke i learned in Silicon Valley in early 80's. on the Professionals.


One detail (available) was the reason of A/P and A/THR drop. IMHO this should be informed clearly to the crew ideally before. When AS began to show inconsistencies. If the System provide this info. (a "benign" event) the crew (PF) could enter the loop better prepared. But this is just a detail in a set of facts we don't know. And could not had helped too much.

jcjeant

Hi,

organfreak
At least they scan the vario ......

BEA report N°3
2 h 11 min 58
The vertical speed is around -
15,300 ft/min.

PF
I have a problem it’s
that I don’t have vertical
speed indication
Capt
Okay
PNF
I have no more displays

roulishollandais

Scaning vario 4 times in 4 minutes : Yes it is very schocking !