Not really military aviation but putting this in the pub just seemed wrong
Crash Report Shows Confused Cockpit
Cruising at 35,000 feet and nearly four hours into what seemed a routine overnight flight to Paris from Rio de Janeiro, an Air France cockpit crew got a stall warning and responded by doing what even weekend pilots know to avoid: They yanked the nose of the plane up instead of pointing it down to gain essential speed.
Apparently confused by repeated stall warnings and reacting to wildly fluctuating airspeed indications, pilots of Flight 447 continued to pull back sharply on the controls—contrary to standard procedure—even as the Airbus A330 plummeted toward the Atlantic Ocean, according to information released Friday by French accident investigators. The June 2009 crash took the lives of all 228 on board.
The pilots' actions are likely to lead to a global shake-up in pilot training that reappraises the role of computer aids, as aviation-safety experts increasingly worry that many airlines scrimp on drilling manual flying techniques.
Still to be answered is how seasoned pilots for a top airline, flying one of the industry's most advanced jets, violated such a fundamental rule of airmanship.
The introduction of automation has made flying dramatically safer over the years. In the U.S., for instance, fatal accident rates are at record lows. But if pilots are taught to abdicate too much responsibility to automated systems, essential piloting skills can dull and aviators become too reliant on computers in emergencies.
That's particularly troublesome if onboard flight-control computers malfunction, disconnect or, as in the case of Flight 447, give conflicting information and warnings to pilots. "Pilots are starting to serve the automation, not the automation serving the pilots," said Bill Voss, president of the Flight Safety Foundation of Alexandria, Va., an independent advocacy group championing enhanced training. "It's almost like we have to train the pilots to know how to triage these situations."
The long-awaited factual report, though it doesn't explicitly say the pilots acted improperly, provides important new details about their actions during a dangerous loss of forward momentum that lasted more than three and a half minutes.
Investigators already concluded that except for malfunctioning airspeed probes, there were no other mechanical, electrical or system errors.
The report paints a somewhat unflattering picture of a seemingly confused cockpit, with the crew making extreme inputs to their flight controls and the engines spooling up to full power and later the thrust levers being pulled back to idle. At one point, according to the report, both pilots sitting in front of the controls tried to simultaneously put in commands.
The preliminary findings offer "a strong piece of evidence that as an industry, we need to improve upset recovery training," said John Cox, a former airline pilot and accident investigator who now runs Safety Operating Systems LLC, a consulting firm based in Washington, D.C.
The senior captain on the flight, Marc Dubois, who was on a routine rest break in the cabin when the trouble started, rushed back to the cockpit and was present and observing the other pilots' actions during a large portion of the descent.
Air France praised the three pilots, who "demonstrated a totally professional attitude and were committed to carrying out their task to the very end," the airline said in a statement.
The carrier, a unit of Air France-KLM SA, noted that "the initial problem was the failure of the speed probes which led to the disconnection of the autopilot and the loss of the associated piloting protection systems."
The largest trade union representing Air France pilots, SNPL, said Friday the report "describes only part of the sequence of events experienced by the crew" and it awaits the full report.
Throughout the sudden descent, according to the report, "inputs made by the [pilot flying] were mainly nose-up," which reduced the plane's lift. Pilots are taught from their earliest training that if an airplane begins to stall and its wings have lost the lift to remain airborne, they should immediately push the nose down to regain speed, lift and maneuverability.
The report could provide ammunition for the lawsuits against Air France, though plaintiffs also are likely to pursue Airbus for how it handled airspeed-indication issues over the years.
The problems with the speed probes on the Air France plane, and others like it, were well known. They had a history of icing up and giving faulty readings. The probe's maker, Thales SA of France, declined to comment. Airbus and regulators had established procedures to handle such situations with the probes, which are called pitot tubes. These procedures focused on maintaining sufficient thrust and avoiding extreme maneuvers.
Airbus, a unit of European Aeronautic Defence & Space Co., said in a statement it is committed to continuing to provide support to the investigation "with the objective of identifying all potential lessons to be learnt."
About three hours and 40 minutes into the flight, when the airspeed-indication issue first cropped up and the pilots received their initial stall warning at around 35,000 feet, the report shows the crew maintained control and temporarily managed to stabilize the plane at an altitude above 37,000 feet. That took just under a minute.
But then with their jet basically flying level despite airspeed-sensors that continued to display unreliable readings, the pilots started to veer away from typical procedures, the data released Friday reveals. French investigators didn't comment on reasons for the crew's behavior.
Upon receiving a second stall warning, the crew increased engine thrust substantially—part of standard practice to cope with such a situation. But for the next 50 seconds, the pilot at the controls did something that safety experts consider anathema: He continued to pull the jet's nose up, despite the threat of worsening the stall.
About two minutes after the first problems—and with the captain back in the cockpit—the jet was falling at a rate of 10,000 feet a minute, comparable to dropping 15 stories a second in an elevator. Yet the plane's nose remained pointed sharply upward as the wings rocked side to side and its forward speed hovered around 100 miles an hour, too slow for a jetliner to fly.
"I don't have any more indications," one of the pilots said, perhaps referring to airspeed but possibly something else. "We have no valid indications." The report doesn't elaborate.
At that juncture, according to the report, both thrust levers were pulled back to idle. The report also said that both engines were operating and responding normally to pilot commands.
The report goes on to describe how roughly a minute later, with the plane already dropping to around 10,000 feet altitude, there were "simultaneous inputs by both pilots on the sidesticks" that control the aircraft, with one of the pilots trying to clear up the confusion by telling the other "go ahead, you have the controls." Pilots are trained to avoid such simultaneous commands.
The plane's data recorders stopped four minutes and 27 seconds after the autopilot kicked off, with the plane still dropping at roughly 10,000 feet a minute, tail down and slightly rolled to the left.
Air France has had a history of safety issues over recent years. After the crash of an Air France Airbus A340 on landing in Toronto 2005 that resulted in no fatalities but destroyed the plane, the airline ordered a thorough study of its approach to safety. The airline later said most of the report's recommendations had been implemented.
After the 2009 crash, the airline commissioned another study of its practices by a panel of leading international safety experts. That report, which was delivered to the airline in January, found a lack of "strong safety leadership at all levels of management" that resulted in lax cockpit discipline and ineffective pilot training. Air France said it was studying and implementing the report's recommendations.
In terms of future impacts, Friday's report is a prelude to a broad, industrywide study likely to be released later this year, focusing on the interplay of training and automation. After analyzing more than 730 incidents, 26 accidents and thousands of flights world-wide going back to 2001, Kathy Abbott, the Federal Aviation Administration's chief technical adviser for flight-deck design, told a safety conference last year that too many pilots rely excessively on automation.
One cross-cutting theme of the study, featuring broad participation from unions, carriers, manufactures and regulators, is that "pilots sometimes abdicate too much responsibility to the automated systems," according to Ms. Abbott. Part of the reason, she said, are persistent messages from airline management and trainers stressing that "automated systems can do the job better than" pilots.
The final Air France report, which may be a year or more away, also is expected to provide momentum for safety experts seeking sweeping changes in all types of stall-recovery training, including low-level events. Traditionally, flight instructors and senior airline training officials have emphasized the importance of strictly maintaining altitude while powering out of a stall. But lately, regulators and airlines increasingly are embracing a new training approach emphasizing pushing down the nose of the plane to gain speed and recover control—even if it entails giving up altitude.
That technique also was highlighted by findings from the 2009 crash of a Colgan Air turboprop near Buffalo, N.Y., which killed 50 people.
The pitot tube problem was documented before this crash. Pilots were complaining about the confusing checklist when the 'unreliable airspeed fault' came up.
No single thing can cause a passenger jet crash- this was a combination of weak training, faulty equipment, and poor procedures.
"We will go through our federal budget – page by page, line by line – eliminating those programs we don’t need, and insisting that those we do operate in a sensible cost-effective way." -President Barack Obama 11/25/2008
Managing the information flow in the Airbus 330 is one of the most demanding tasks I have seen in aviation.
Too busy following procedures, no time to fly the airplane I guess.
"We will go through our federal budget – page by page, line by line – eliminating those programs we don’t need, and insisting that those we do operate in a sensible cost-effective way." -President Barack Obama 11/25/2008
I had a very strange occurrence about 6 weeks ago in a 737-800 that showed the limitations of the QRH (Emergency checklist), and was similar.
I was flying. We were taking off from San Salvador back to Dallas. Takeoff roll. Everything fine. At 80 knots, the MASTER CAUTION light illuminated. We continue rather than abort high speed. This is standard.
At 100 knots, I note my airspeed is stagnated. A few seconds later, CA says "Rotate", and I immediately have a full and continuous stick-shaker (stall) with an IAS of maybe 90 knots. His side, and the standby, show normal.
The airplane is flying. We clean up, turn downwind. We've got
IAS Disagree
Right AOA Vane light (in the pitot heat panel)
Stall indications (stick shaker)
Incorrect airspeed and altitude on the FO side
The QRH says "Ensure probe heat is on" for the Right AOA Vane" fault, and for IAS Disagree, of course, it's "Compare all the sources and pick the one that is correct." Nothing else.
Can't shut off the stick shaker. The aircraft trims out and feels OK. We come around and prepare to land. At 40 feet, beginning to arrest the descent rate a bit, I pull back, and there's heavy, heavy stick forces, maybe 5X what would be normal. I pull furiously, and luckily avoid cratering the airplane. Nothing in the QRH said "Expect heavy stick forces in pitch."
Taxiing in, I open the window, look out, and see what I expected to see... the right AOA vane was sheared off, completely missing. The stick shaker never turned off until we were on the ground.
Here's what kills me, what the QRH never dealt with, what no school-house instructor could answer.
1) Why would a missing AOA vane compromise airspeed and altitude, which are pitot-static functions?
2) WHERE did the extreme yoke forces come from? And why were we not warned of this possibility?
It was clear weather. At night, or with foul weather, this could have been disastrous, especially the heavy yoke. And there is no stick-pusher on this airplane. So where did it come from?
Sorry to digress a bit but anyone with news on the F-22 crash last year? I thought the report was supposed to be out by now. I understand in the last couple of weeks all F-22s were grounded (something to do with their onboard oxygen system if i remember correctly), could that have something to do with the F-22 crash report?
In light of your full report will there be changes in pilot action in case this incident is repeated? Will the SOP for the Master Caution light coming on change and will an abort become the standard procedure? Would not the SPS computer send you false information once the aircraft is airborne if the AOA had sheared off? Bravo on you quick thinking and professionalism in returning the aircraft safely to ground.Originally Posted by Chogy
On 737 NG the AOA vane inputs to the ADIRS to correct for airflow relative to pitch.
Sounds like you were fighting the stick shaker's mechanical linkage. Agree that should be something pilots should be aware of if that's the case.
Good piece of flying Chogy.
"We will go through our federal budget – page by page, line by line – eliminating those programs we don’t need, and insisting that those we do operate in a sensible cost-effective way." -President Barack Obama 11/25/2008
On the abort procedures, what we have today has been set in stone, rightly so, because high-speed aborts are far more dangerous in most cases than continuing. At American, the mantra is "Abort for anything below 80 knots. Above 80, you abort for any one of these, set up in a memory jingle...
-Fail (engine failure)
-Fire (any fire)
-Fear (Afraid the aircraft is not airworthy; very rare)
-Shear (Active windshear detection)
Otherwise, you press on, and this has been found to be safer. So what we did was correct, and I'd not want that changed. I wrote up a report on the incident, but like any other big bureaucracy, never heard anything. My main objection to the episode was a sadly lacking QRH guidance, and the manuals (Boeing-created) do not do a good job discussing exactly what the AOA vane does in the grand scheme of things. No one says "A bad AOA vane will blow your normal pitot-static indications out of the water." But that is the nature of modern transports - every input goes into a computer, where it is churned about, and the data sent to the cockpit displays. No more separate systems. Everything except the standby is integrated.
Highsea, can you expand on this a bit? You are the FIRST person who might know about this in any detail. Thanks.On 737 NG the AOA vane inputs to the ADIRS to correct for airflow relative to pitch.
I'm afraid I can't give too much insight Chogy, but your first sentence says it all.
On 737, up to -500 the AOA vane input only to the stall warning system, autoslats, and autopilot.
On everything after -600, the AOA vane inputs into the ADIRU which incorporates your pitot static data to the ADIRS. The idea is to correct IAS for AOA.
So a missing AOA vane on 737-800 logically throws off the pitot static data, as you noted:
All the things you would expect from mismatch of ADIRU data caused by bad AOA input.IAS Disagree
Right AOA Vane light (in the pitot heat panel)
Stall indications (stick shaker)
Incorrect airspeed and altitude on the FO side
If you had no stall warnings, you would assume bad ADIRU and switch to backup, which should be normal procedure for IAS mismatch.
But switching to ADIRU 3 in this situation would have no effect, since it is the AOA sensor input that was lost. The bad data would just be sent to another ADIRU with the same result.
This is my understanding, not an official Boeing explanation. I can try to contact the avionics guys if you'd like more information.
"We will go through our federal budget – page by page, line by line – eliminating those programs we don’t need, and insisting that those we do operate in a sensible cost-effective way." -President Barack Obama 11/25/2008
"On May 3, 2000, the FAA issued airworthiness directive 2000-07-27, addressing dual critical failures during flight, attributed to power supply issues affecting early Honeywell HG2030 and HG2050 ADIRU ring laser gyros used on several Boeing 737."
I'm gonna have to stop reading up on this as I'm putting myself off flying
Chogy- this might shed a little light on the heavy control pressure you experienced- From a 737-NG systems summaryLooking more into the ADIRU question- it is looking like you can't switch to center ADIRU from the cockpit? I can't tell if the system is supposed to detect the fault automatically and switch over or what. There are selectors in the avionics bays for using the center ADIRU on the left or right side instrument panels.
Stall Identification
Stall identification and control is enhanced by the yaw damper, the elevator feel shift module and the speed trim system
<snip>
The EFS module increases hydraulics system A pressure to the elevator feel and centering unit during a stall. This increases forward control column force to approximately four times normal feel pressure. The EFS module is armed whenever an inhibit condition is not present. Inhibit conditions are: on the ground, radio altitude less than 100 feet and autopilot engaged. However, if EFS is active when descending through 100 feet RA it remains active until AOA is reduced below approximate stickshaker threshold. There are no flight deck indications that the system is properly armed or activated.
As airspeed decreases towards stall speed, the speed trim system trims the stabilizer nose down and enables trim above stickshaker AOA. With this trim schedule the pilot must pull more aft column to stall the airplane. With the column aft the amount of column force increase with the onset of EFS module is more pronounced.
So theoretically, if the center ADIRU is using the left side sensors, switching over might have eliminated the IAS mismatch and stall indicators in your situation.
I don't know that's the case- don't know where the center ADIRU gets it's air data.
Last edited by highsea; 01 Jun 11, at 00:39.
"We will go through our federal budget – page by page, line by line – eliminating those programs we don’t need, and insisting that those we do operate in a sensible cost-effective way." -President Barack Obama 11/25/2008
"A blocked pitot tube is a pitot-static problem that will only affect airspeed indicators. A blocked pitot tube will cause the airspeed indicator to register an increase in airspeed when the aircraft climbs, even though actual airspeed is constant".
Could this be a reason why they pulled back rather than dip the nose. With a blocked pitot giving a false indication of airspeed, and having a stall warning, they needed to increase speed therefore they had the aircraft climb to gain speed rather than dip the nose.
Airspeed is controlled by pitch, so pitching up means slowing down. That's why stall recoveries always involve pitching down.
"We will go through our federal budget – page by page, line by line – eliminating those programs we don’t need, and insisting that those we do operate in a sensible cost-effective way." -President Barack Obama 11/25/2008
My word, I can actually contribute something to this conversation!!!. I am quite familiar with Ring Laser Gyros and Nav/Orientation Systems which have them at their heart. Funnily enough my system also uses a Honeywell box. Whenever a systme of the level of complexity such as these starts acting "Squirrely" it can be a nightmare to figure out. I have had some seriously heated conversations with some software folks who kept teling me what I was seeing couldnt possible be the case as thats not how the system worked!!!."On May 3, 2000, the FAA issued airworthiness directive 2000-07-27, addressing dual critical failures during flight, attributed to power supply issues affecting early Honeywell HG2030 and HG2050 ADIRU ring laser gyros used on several Boeing 737."
I'm gonna have to stop reading up on this as I'm putting myself off flying
The SYstem I am intimately familiar with has an Inertial Nav Unit (INU) which also takes inputs from a "Crypto Keyed" GPS Reciever and a Vehicle Motion Sensor to continously porovide VERY accurate Loaction and Pointing Information. In a perfect world GPS Aiding would always be available however we dont live in that perfect world. I discoverd that if GPS aiding not available during initialisation of the system some very weird behaviour can occur. Without GPS input the operator has to manualy input a known location for the system in the form of a Easting Northing Altitude and Grid Zone format.
The system then compares this location to the accelaration/motion data stored within its built in "Earth Gravity Model" (EGM) Basically its checking to see if where it senses it is based on teh rotation of the earth matches where you have just told it it is. The Weird behaviour occurs if the operator makes a mistake during the manual input of location. Because teh location does not match teh motion teh INU is sensing it decides it must also be moving and doing whats know as a "moving base alignment" now it can only do a moving base alignment if GPS is available, if it isnt the systme demands that it stop moving giving the operator a "ZUPT RequireD" message which means Zero Velocity Update Required. Well because teh system is not actually moving teh operator simply acknowledges this message.
The system still isnt happy as what its sensing doesnt match what you have told it. It thinks a little bit more however and decides that it is still moving, but if thats the case why is it not getting a signal from the Vehicle Motion Sensor (VMS) mounted to the wheel hub. It now promptly calls the VMS sub system OUT, Calls teh entire NAV Subsystem Degraded then OUT and promptly locks up totally.
It gets better when the Mechanic breaks out his Diagnostics kit to trouble shoot this issue. He can see from the systems stored Built In Test Log file that the last thing the system did was declare teh VMS out before shutting down teh Nav System. So he starts a diagnostics flow on the inputs to the INU starting with the VMS and all its cables connecting it to teh INU, does teh same for the GPS which amazingly all pass!!!! But the Diagnostics system can see the valid failed Built in Test result so their MUST be a fault of which can only be caused by the INU itself.
End result remove and replace a $70000 Dollar box which is promptly returned to Honeywell to be dispositioned as "No Fault Found" incurring additionl cost to the unit and so on a so on. Fun times for all involved.
Im sure that really wasnt that interesting to you folks, but I think the point that I am trying to make is that if a reasonably simple system involving an INU, a GPS Receiver and Motion Sensor and a bunch of software trying to make sense of teh inputs can cause these type of problems, it doesnt surprise me in teh least that a significantly more complex system like teh avionics and flight controls on an Airliner can exhibit "Odd" behavior from time to time aswell!!!
Regards
Arty
"Admit nothing, deny everything, make counter-accusations".- Motto of the Gun Crew who have just done something incredibly stupid!!!!
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
LinkBack URL
About LinkBacks
Reply With Quote
Share this thread with friends: