Really? A sensor failure can’t record invalid data?
Not long ago a mid-lake buoy in Lake Michigan reported waves of 255 ft for a few hours. The next report, 10 minutes later, said the lake was calm. Am I to assume the 255 ft value was correct?
Well sure it could and maybe I was lazy in my wording, but when the aeroplane is stalled, the elevators are up and everything else is consistant with something pulling on the column, and the sensor is recording a pull on the column, it’s fair to think that the pilot is pulling back on the column. The type of failure Zenbeam used as an example is not possible and other types of sensor failures would stand out as an anomaly. In the Colgan and Air France examples the aircraft behaviour is consistant with someone pulling back on the controls so there is no reason to suspect a sensor failure.
Reading yesterday a sum-up of the report, it described a failure that apparently hasn’t been mentioned in this thread : something called “flight director” (I wouldn’t know what is the proper English name, so I translated word-for-word) would have given faulty instructions during the stall and this might have been the reason why the co-pilot choose a wrong course of action. He would have merely followed those instructions.
Can someone explain/elaborate?
I also thought I heard that the Senior pilot was on break, and only returned to the cockpit in the middle of the crisis.
The flight director (correct English term) is a symbol presented on the attitude indicator or primary flight display (modern version of an attitude indicator) that essentially tells you what attitude to fly to achieve whatever parameters you’ve set in the flight guidance controller. For example if you’re flying at 25,000’ and want to climb to 30,000’ at a speed of 0.7 Mach you would set 30,000’ in the altitude selector and 0.7M in the Mach/airspeed selector. The flight director will then give you commands to achieve those parameters. You could either hand-fly those commands or engage the autopilot and the autopilot will follow the commands while you read the paper ;). The problem with the flight director is that it is a dumb instrument. It’ll do what you’ve told it to do and if you’ve got something inappropriate set in the flight guidance controller, the flight director can lead you astray.
I’ve only skimmed through the full report and haven’t read the flight director stuff in detail. It may well have been giving commands to maintain the original cruise altitude. That is no excuse for stalling though. Every pilot should be aware of the limitations of a flight director and should turn it off or reprogram it if it’s giving unwanted commands. In fact, on my aircraft type, one of the actions in several of the emergency procedures is to turn the flight director off.
Yes, that is normal on long haul flights. If you didn’t have an augmented crew and allow each crew member to have a sleep you’d be having a lot more approach and landing accidents.
Edit: The fact the Captain was on a break is no excuse for things to go horribly wrong the way they did. Each of those pilots should have been competent to deal with any standard emergency, and both the loss of airspeed data and the resulting stall are standard emergencies with a set procedure to follow. They failed to follow both procedures. That doesn’t necessarily mean the blame falls squarely on the pilot’s shoulders, it could be that the procedure is confusing or the diagnosing of the failure is confusing. The report mentioned thirteen previous airspeed failure events and in every case the crews failed to use the correct procedure.
Richard-I understand why he was on break. Just wanted confirmation he was (If I sound argmentative, sorry, know you weren’t being argumentative) Amazing that this kind of crisis has such a terrible track record of being resolved happily. (i.e. correct procedure not implemented)
its really were bad experience =)
In the final report they repeatedly refer to “stall 1 warning” and “stall 2 warning”. Can someone explain the difference?
In this case it was just a distinction they made for convenience of the readers:
From the report:
I had to open up the report to see for myself there, as I haven’t read it yet. I’m not familiar with Airbuses but MD-80’s had two separate aural stall warnings which made it sound almost like an echo. (I believe it was the MD-80 anyway.) But nothing so interesting in this case.
Yeah, really. From earlier in the thread:
Haven’t fact-checked that, but I would not put it past an airplane manufacturer. See also the Sioux City DC10 crash where reports say there was no procedure for a triple failure of hydraulics. Every project manager in every industry has to make several decisions to the effect of “<situation x> is one-in-a-million improbable, not worth the hassle of providing for it” – that’s just practical engineering. Sometimes they overestimate the improbability. That’s why the crew has to be on their toes for the unexpected.
I’ve read a few critical comments over the years about the sidestick controller that Airbus uses, and the confusion and lack of feedback seem to have played some part in this accident. The dual-yokes, physically linked and moving together, have been around for a long time. In large jets with a multi-person crew, they were practically universal until Airbus decided to be different.
Does anybody here know why they did? Was it cost saving (made possible by fly-by-wire controls)? Did they think automation made hand flying that much less important? Considering the billions of dollars spent designing these machines, they must have had a reason. What did Airbus think was the advantage of the sidestick, and has their reasoning been borne out in practice?
FDRs are not used to create full-flight simulators: the companies that make sims never obtain or look at this data. The FDR can only tell us what happened to an aircraft under particular circumstances, with pilot input - it cannot tell us how ALL aircraft would behave and need to be modeled without pilot input in order to simulate a variety of emergencies.
When a simulator is made, what is modeled is the cockpit environment, not the aircraft. There aren’t finite-element analyses of airflow over wings going on - “all” there is is a simulation of angles, accelerations and moments to simulate how the cockpit feels under various circumstances. They use flight physics data accumulated from experimental flights (either from the manufacturer or flights managed by the sim manufacturer itself), but these only collect data for the aircraft’s behaviour within the certification flight envelope, not for situations beyond it (you’d kill way too many pilots if you tried!) Once you get outside of that envelope, all the simulator can do is apply theoretical mathematical models and guesswork. Seriously, it’s possible to skip a plane across a lake in a simulator, if you turn off the “crash” function that stops the session… it’ll just keep bouncing and maybe flash some red across the screen to simulate fire or something.
Aircraft simulators aren’t designed to help understand the aircraft (in the sense of understanding how the plane behaves in flight from a structural or design perspective): that’s why airframers keep flight test vehicles. The simulator is designed to help understand the cockpit and the way the crew interacts with it (hit this button, pull that lever, respond to this alarm in this manner, etc).
What is possible to do is to load the scenario from a given crash into a simulator and see how pilots respond to it, but again, this doesn’t necessarily tell you anything about the plane once the simulated event goes beyond the certification envelope. If the scenario stays within the flight envelope, then, yes, you can see whether a situation is recoverable or not and what happens if pilots try different things. Once outside what the simulator was programmed with…it’s all guesswork.
With cable control being obsolete, the leverage provided by big yokes is no longer necessary. Airbus’s philosophy is that the aircraft is the boss, not the pilots, so it’s best to move the controls to a place where the temptation isn’t so great to monkey with them.
The advantage is you free up a lot of space in the cockpit so you have more room for oh-so-important things like dinner trays and laptops which come in handy for bidding on your next assignment.
That’s what I would think. Once you go fully FBW, putting in linked yokes is adding parts and expense for the sake of simulating a familiar control interface, and at some point some project manager needs to decide if it is or is not worth it. I can easily see the Airbus design teams for A320 and above thinking: if sidestick controllers are good enough for F16s, space shuttles and other FBW military aircraft/spacecraft, then they’re good enough for FBW commercial airliners. It is a legitimate decision to make.
It then becomes a matter of properly training the crew and giving them the necessary information, and they then * should* be able to fly “manually” barring catastrophic failure of the flight controls themselves. Remember Captain Sullenberger over the Hudson? Lucky he was flying a good old reliable… oh, wait… He *was *using the Airbus 320’s controller and FBW to glide to a perfect ditching. Of course, Sully and Jeff Skiles were that day the very embodiment of crew resource management done right and environmental conditions were near optimal, but the control interface philosophy at Airbus did not seem to hinder their performance.
How much expense is it? You could still have two yokes, mechanically linked to each other under the floor of the flight deck, and connected to a fly-by-wire system. The cost of such a setup would look like a rounding error on a machine worth $200 million.
Obviously, a side stick can work, in routine operations and in emergencies. But is it better? Human-machine interactions can be very complicated and subtle. We respond to certain cues whether we’re aware of them or not. A smart designer takes advantage of our natural perceptions. Maybe the big, twin yokes were originally built for leverage, but there’s something natural and intuitive about them. You never even have to ask what the other pilot is doing with the controls. I would think someone would need a good reason to abandon them, not just “it’s good enough for an F-16”.
XPlane claims to model the airflow over the wings and with particular hardware-software combinations flight hours logged on it count towards FAA Certification hours. Is XPlanes stall performance simulation realistic for the A330 ?
Isn’t the 777 and/or 787 like this? Mechanically linked yoke, sure, but aren’t those Boeing models fly-by-wire?
Yes. Boeing has a different philosophy to Airbus. I’m not sure why exactly they stayed with the yoke, probably because it is familiar. Boeing also allows the pilot to fly outside the envelope while Airbus in normal law will prevent the pilot from doing something silly. They both have flaws. I guess what Airbus has done is replace one set of failure types with another.
(Bolding mine): Ah, but it seems there’s “something natural and intuitive” because that’s the way we’ve always done it, as you mention in the time of cable-pulled controls it was the best solution for the matter of dual controls in large aircraft. But they are NOT a self-evident logical default that we must justify “abandoning”,* if* we’re blank-slating our design.
IIRC in the initial design stages of the 787 it was debated whether to make it a buyer’s option to install yokes vs. controllers since as mentioned, the 777/787 yokes are functionally just as “virtual” as the controllers. As mentioned by Richard Pearse, in the end the more critical part is not the shape of the thing in the pilot’s hand but how the flight control system work and it’s a tradeoff of one set of failure points for another.