mm43

Diversification;No, you didn't miss it!

The possible solution was the answer posited by A33Zab to Svarin in AF447 - Thread No.3 , and physical evidence effectively vanished at impact.

I can only assume that as the BEA couldn't substantiate the message, and in determining it had no effect on the outcome, they decided to leave it as described in Interim Report No.2.

RatherBeFlying

That is a possible surmise from BEA's report and webcast.

But do we really expect a crew that ends up in a developed stall and later realises the situation to simply accept their fate in an intact airframe at better than FL300? Is that acceptable to the SLF population?

Stick pushers were once required in transport a/c that could not recover from a stall -- why has that requirement apparently been dropped?

rudderrudderrat

Hi JT,
I have been pondering the same thing ever since the first report was received.

The computers gave the crew direct Roll Control with the ailerons and spoilers, but they retained the management of the position of the elevator and stabiliser.
I think that without the computers' assistance, the crew would have had to trim the load from the elevator themselves as the speed washed off during the stall warning and probably the crew would have had to reprogram their own flight directors to a positive VS (if that is what they really wanted).

HazelNuts39

That requirement is still in force, but we don't really know if the airplane was unable to recover from a stall.

Sriajuda

While it appears a mystery to almost anyone as to why all three pilots seemed unable to recognize the stall, I wonder even more about the apparent lack of the computer's abilities to detect the same.

Even with the speed sensors gone or unreliable, there is ample information remaining to deduct (heuristically) that indeed, the AC was in a stall. From a system engineer's point of view, I perceive a gross discrepance between automation behaviour *before* leaving the predefined, valid flight envelope, and thereafter. Before, there is protection from all sorts of (possibly) stupid control inputs by the pilots, but as soon as a single sensor fails, the whole protection system just quits. That is highly inconsistent behaviour and might, IMHO, explain the actions of the PF. He might just have been too used to the plane doing the actual flying, and he might have expected it to do what he was used to: Interpret his stick inputs as a "goal" definition (climb!) and do the actual flying to achieve that goal.

I understand that the AC had switched to 'alternate law', and that maybe the pilots or, to the very least, the PF might have been unaware of that. The point I want to make is that I see no need for such an abrupt cessation of computer support in that situation. Three minutes is a very long time, much more so for computers. Heuristics looking at all sensory data could have determined, with reasonable accuracy,

- airspeed (correlate previous, valid readings with GPS speed and accelerations measured vs. change in pitot sensor data)
- vertical speed (sensory data was good, AFAIK, barometric and ground radar, no?)
- aircraft attitude (AI was working, no? An even if not, over some period of time it could be deduced just by observing the acceleration data in all three axis)

Using that data would be sufficient to detect the stall. Even more important, such heuristical cross-checking of sensory data by the computers could have avoided both the switch to alternate law *as well as the stall*. Even if the heuristic analysis was not good enough to safely fly the aircraft, the computer could just as well have fallen back onto pitch & power by itself. Of course, alerting the crew to the fact at the same time. Giving them the *option* of manual takeover (including a *manual* switch to alternate law), rather than just quitting and leaving them to sort it out.

Humans are not computers, and are extremely suspectible to fatigue, habits, boredom, surprise and panic. If you wanted to design a system that had the goal of provoking 'human error', these are the human weaknesses you'd exploit. And that is exactly what the airbus did: Lull the pilots into a seemingly fool-proof, fully automated environment, and then, at a slight (!) malfunction of hardware, drop everything raw onto them, intermingled with inconsistent alerts and warnings.

I think these are major user-interface flaws. Sure more/better pilot training is called for, too. But the system's design should strive to be intuitive rather than that additional/repeated training is required just to be able to deal with the system's behaviour.

The same goes for the airbus sidestick configuration: It seems to be designed with the goal of making sure the two (and sometimes a third!) pilots are unaware of what the other is doing. Out of each others sight, the passive one not moving, averaging dual inputs...I just don't get that. Does anyone here think that the captain was aware of what the PF was doing?? And to think how easily that could have been different, with a different setup.

Also the change to alternate law could, nay, should be combined with force-feedback sticks. In humans, not all the senses are equal. They get processed in different priorities. These are:

1. Smell
2. Taste
3. Touch
4. Aural
5. Visual

We can't make much use of 1 and 2, but rather than displaying a small text on a screen (5, lowest priority), why not use no. 3? The change from non-force feedback to force feedback would very distinctly signal the change from 'normal' to 'alternate' law to the PF!

Just a systems engineer's thoughts about the issue(s), who has done very little flying (albeit a lot of sailing).

NARVAL

"Different matter for an experienced experimental TP but we are talking about two line F/Os who (so far as I am able to divine) had no broader experience"
Thank you John Tullamarine, for that comment. One must remember, beyond the fact that the pilots had probably never experienced "out of the flight envelope" excursions, on other planes, as some of us did, at the time of the accident:
-no procedure relating to the stall of the A330 was integrated in the QRH (quick reference handbook)
-The procedure was in the abnormal complementaires (PAC) in the Air France documentation and in the supplementary items in the airbus FCTM.
It appears (modified) in the QRH in august 2010 (Emergency manoeuvers).
It is then seriously modified, again, in the QRH in october 2010.
The stall, until the accident, was not listed in the emergency manoeuvers, and staying competent by recurrent exercises (especially at high altitude) was never considered. The approach to the stall (as the aircraft, of course, prevents you from entering it), was occasionally demonstrated at low altitude, with a drill totally unsuitable to the high altitudes. It si only now that everybody is really sure that lowering the nose and reducing the thrust if necessary, at high altitude, will get you out of trouble... The Airbus FCTM said that it was not necessary to train the pilots to the stall recovery (Operational Philosophy/Flight controls/ Page 01.020 7th january 2009) and Air France had the same attitude (stall recovery training only for "classical" airplanes. The Bus was considered unstallable. I insist on this for my pilot friends who speak of the competent pilots as opposed, apparently, to the crew. Take a look at the pilots experience. Only taking one copilot, not to bore you, no mention of any high altitude manual flying on the A330, and last useful training on that issue in 1998 on the A320...For the captain, 2001.
Sad but true. I was very experienced when I left the job, and I do not entertain the notion, a single second, that they were incompetent. Just had not seen it, had not been there...

slats11

I would agree with this. And I wonder if this logic reflects underlying concerns about blame and legal ramifications if a "protected system" were to crash. So if there is a problem, downgrade the computer support, give greater authority to the pilot and let him/her fly it. If it ends badly, then people will lament the lack of manual flying skills and blame the pilots, the training, the operator, the culture.... rather than the equipment.

So I wonder at the wisdom of abruptly changing horses midstream. And I wonder whether this design logic is in the best interests of the AI, or the passengers.

syseng68k

Sriajuda, #242:

This is something that I was quite shocked about, expecting a much
higher degree of proactive intelligence from the system design, but
perhaps this is the subtext of a company with a corporate mindset of
"it cannot crash, cannot stall". I keep harping on about this, but
in the absence of normal speed and attitude data, subsystems such
as the ins generate more than enough information for some other
part of the system to monitor current and historical state. Use of
this data could provide improved warning and predictive capability.
This sort of on going "big picture" global monitoring would be mandatory
for applications such as nuclear power, but seems sadly lacking in
aircraft.

While there is no doubt that the crew made serious errors, the plethora of
warnings, not warnings and other inconsistent data presented to the crew,
probably already in a state of panic, can only have made the situation much
worse. It's the duty of the system designers to anticipate the worst
possible conditions, design the system so that it is consistent at
the ragged edge and provide accurate data at all times. Clearly not the
case here and from that point of view, the overall system design failed
the crew.

A trivial example: How difficult would it be to prevent a full back stick
6k/minute vs command at 35k ?...

Sriajuda

Exactly my thoughts. And it neither starts nor ends at the computer level: AF447 was not the first AC brought down by a pitot failure. The mistake I see there is what I call 'false redundancy'. While the sensors are there in triple, they are not truly redundant as

a) they are the same type and manufacturer
b) they operate on the same physical principle.

Since numerous ways to measure air speed exist, I cannot understand why not even one truly redundant airspeed measuring device is used in AC. (Boeing is the same here, AFAIK).

airtren

The "redudancy" assumed by this design of speed sensing - which at this point is not different than other manufacturers - seems to target intrinsic/internal sensor failures and less a failure caused by external events, such as weather.

With the current design, the 3 pitot tubes are not only of the same type and same manufacturer, but they are also located pretty much in the same place - under the nose - and thus they're sharing the same fate and will likely behave the same way in front of external events, such as weather. They will fail the same way, and pretty much at the same time, which the case of AF 447 shows so clearly.

From a system architecture and design perspective one can find many weak elements, some of which several recent posts, including yours pointed to.

In the wider perspective, in which design decisions include costs, a very well trained crew, and many others, the presence of multiple factors is supposed to provide an attenuation of the effects of these weak elements. Statistically though, there is always a probability that the elements necessary for the whole to work well are NOT going to be present - as the case with AF 447 shows - with the tragic consequences we know.

Linktrained

If one of the pilots had noticed the hands of "" ... My old Sensitive Altimeter ..." spinning round ( say.. by FL33.0 ?), one of them might have noticed that the THS had reached an unusual reading of fully NU.

I am lead to believe that the THS FOLLOWS commands, from A/P or S/S.
( I had mistakenly believed that it might have been otherwise, until I was corrected by Tanaka.)

The A/P was off. The THS must have moved in response to a S/S.

Some airlines seemed to train that " the THS is something WE do not touch"
I do not know whether this was so in AF.

Never having operated under the PF/PNF system, I would like to be told the etiquette then used when pressing the " I have control button" when one is reluctant to yield to the other.

Lyman

@airtren A corollary to the problem of redundancy showed up in BA038. At some stage, and not just in ETOPS, commonality rears its insistent head: eg turbofans burn fuel to produce energy. So then do pitot heads sense air pressure to indicate an absolute value. after 447, it was considered sufficient resolution of the Thales problem to allow one problematic probe to remain installed.

As in 038, the problem was identified in the penultimate position, an oil cooler in the engines. It was not considered ok to change out one TRENT for a GE. It is identical in presentation, a weak link is not allowed to remain in reduindancy, indeed, redundancy is the problem when common fault is the issue. Can we extrapolate? Two pilots are required as crew, and it is impossible to supply identical pilot one for one. In handover, the new pilot is a different solution, by definition, so redundancy in the case of pilots is not an issue, in fact, the "back up" is a fresh resource with different solution making potentials by definition.

The Thales had a specific problem due corrosion at the drain, was this the cause of the icing? from an "anomalous design solution" perspective, the problem becomes the solution, the difference in corrosion support probe to probe makes the Thales probe anomalous, which is the goal in fault prevention in similar systems. Facetiously, but truly, what makes similar devices superior in multiple install is their separate engineering approaches. See 'pilots' above.....

@Linktrained per the report, the AP was ON (selected ON). No?

Sriajuda

Indeed - and it even only partly achieves redundancy for intrinsic failures, since design/manufacture faults are likely to be present in all sensors if they are from the same manufacturer & type and maybe even from the same production batch.

Since airspeed information is probably THE most important data in an AC (pilots, please correct me), this neglience to provide both true sensor redundance and obviously not implementing secondary, heuristic means to verify and/or determine air speed is incomprehensible to me.

Sriajuda

If I remember correctly, in the Airbus the trim wheel does not make the 'clack-clack-clack' sound that other aircraft do. Another example of technology that seems to be designed to withhold information from the pilots? As in the sidestick configuration?

Lyman

The design of the airbus philosophy is fraught with examples of "inscrutabilities"

IMHO

jcjeant

Airbus met en avant des erreurs de pilotage sur le Rio-Paris - Libération

Google*Traduction

RetiredF4

In this case it moved due to SS input.

To be correct though, THS moves also without SS input to hold the desired g, which would be 1 g without SS input. It has nothing to do with the autopilot on or off.

If PF would have only released the SS on his way up to the apogee (with decreasing speed) the FCS in ALT2B without protections would have deflected the elevators and in the following the THS Trim to full nose up to maintain the 1g (which is the demand with SS neutral) until the same result would have taken place, maybe within a somewhat prolonged timeframe.

Only positive SS ND input would have prevented that.

Sriajuda

Hm, I think that is only partially true. Rigid procedures & training aim to make pilot behaviour both predictable and, consequently, identical.

In the case of AF447, we seem to see just that - but in a failure mode. Three pilots did not understand what was happening, and failed to fly the plane.

That leads me to another thing in the report that sends shivers down my spine: The stall warning was sounded more than 70 times during those fatal minutes, and there was no acknowledgement by any pilot of that, neither through action, nor through speech. It has been speculated that the pilots did not perceive the stall warning, maybe due to sensory overload. To me, it seems much more likely that they did not believe the stall warning. And if that is the case, simultaneously with three pilots, it tells a chilling story of the trust these professionals had in their technology, their aircraft, their instruments. Apparently zero. Wonder why??

roulishollandais

I wonder that FD problem has been emphasized in the final report, but why not : It is easy and mandatory to replicate the flight in simulator to confirm or leave that theory. Scientific method needs !

How could the BEA leave that theory without verifying it ?

Reading once more, and also a little more, in the final report, about the architecture of the flying software and automation, I see many problems with observability and controllability in the men-machine interface , and specialy with that FD who tells the AP , but doing something different : on is disconnected, the other not .... It seems all the possible cases have not been verified. I never worked sofware with such irresponsibility for human lifes.

The connection between air data and inertial reference is also unclear, and the BEA was not very curious ! The voting system between ADR and IR is not enough analysed for example.

DozyWannabe

Not quite true. Since the problems, it seems airlines have either switched to a combination of Thales AB and Goodrich, or all-Goodrich (which are deemed more reliable). The tubes themselves are located on opposite sides of the airframe (with the standby just forward and below the Captain's primary pitot tube).

Welcome to the board!

Right - to answer some of your queries, the issue is one of complexity. The BUSS (Backup Speed Scale) device now offered as an option by Airbus works along the principles you describe - but the fact is that pitot tubes remain the most reliable, accurate and elegant engineering solution to the problem of airspeed determination.

Previous accidents attributed to loss of airspeed information involved either a lack of simplistic redundancy of the kind provided by the Airbus design, or (as in the case of Birgenair) failure to diagnose a fault within a single pitot tube and correctly use the redundancy available. The point behind the "quorum" design that existed prior to AF447 was that the systems themselves would be able to diagnose the problem and switch to the working sensors automatically - cases where all sensors failed within a tight timeframe were practically unheard of up until that point and as such, a triple failure was considered out-of-scope. As is so often the case, reality can intrude and make fools of us engineers in unexpected ways (in this case switching to the Thales AA pitot tube model without exhaustive testing to check whether the replacement was like-for-like in all conditions).

This "failure of imagination" has affected every complex engineering endeavour human beings have embarked upon, from bridge-building through seafaring and aviation right up to spaceflight. The only way to avoid that risk completely is to never embark on such endeavours in the first place.

You could look at it that way, but (IMO) only if you've come at it from a pre-determined conclusion that the Airbus FBW design was intended to withhold information from pilots (which, while a stubborn notion to disprove, is in fact not borne out by the evidence). The sidesticks are not interconnected and do not provide force-feedback because of the additional engineering complexity required to do so, and in jet airliners from the late '40s onwards, any feedback through the control column is in fact artificial and as such can be prone to failure.

The trim wheels are quieter on the FBW Airbus because unlike other airliners of the vintage, trim is an automatic function in every law except Direct and MAN PITCH TRIM ONLY. Even in aircraft of a similar vintage (e.g. 757, 767), pilots will be trimming manually whenever autoflight is disengaged, and the trim wheels are an integral part of manual flight. Because this is not the case on the FBW Airbus in over 99% of cases, the trim wheels are not as intrusive.

Now - obviously in this case, having the trim wheels announce movement more forcefully might have drawn attention to the way the aircraft was being mishandled - but given the fact that neither of the two F/Os had high-altitude manual flight training on type this can't be taken as read.

It may interest you to know that when we ran the scenario in an A320 sim, it turns out that in Alternate [no speed stability] (the A320 equivalent of Alternate 2), autotrim had a hard limit of approximately 5 degrees nose-up, even when holding the sidestick against the back stop. As a result of this we managed to recover with stick full forward after losing barely 8,000ft. In order to test the exact circumstances, our TRE had to manually wind the trim up full once the limit had been reached on the following experiment - this time we lost closer to 18,000ft before recovering, but importantly we found that recovery was theoretically possible using sidestick alone - i.e. without having to manually adjust trim, *provided* that the problem was diagnosed relatively quickly.

Why there's a difference in autotrim behaviour between the A320 and her larger sisters I don't know, but it's definitely an interesting fact to take into account.