Last Update: Friday, Jun 14th 2019 21:31Z 24320 Articles available Events from Jun 19th 1999 to Jun 14th 2019
www.avherald.com
Incidents and News in Aviation
List by:
Filter:
Incident: Lufthansa A321 near Bilbao on Nov 5th 2014, loss of 4000 feet of altitude
By Simon Hradecky, created Tuesday, Nov 18th 2014 17:11Z, last updated Sunday, Dec 28th 2014 22:22Z
A Lufthansa Airbus A321-200, registration D-AIDP performing flight LH-1829 from Bilbao,SP (Spain) to Munich (Germany) with 109 people on board, was climbing through FL310 out of Bilbao about 15 minutes into the flight at 07:03Z, when the aircraft on autopilot unexpectedly lowered the nose and entered a descent reaching 4000 fpm rate of descent. The flight crew was able to stop the descent at FL270 and continued the flight at FL270, later climbing to FL280, and landed safely in Munich about 110 minutes after the occurrence.
The French BEA reported in their weekly bulletin that the occurrence was rated a serious incident and is being investigated by Germany's BFU.
The occurrence aircraft remained on the ground in Munich for 75 hours before resuming service on Nov 8th.
The Aviation Herald learned that the loss of altitude had been caused by two angle of attack sensors having frozen in their positions during climb at an angle, that caused the fly by wire protection to assume, the aircraft entered a stall while it climbed through FL310. The Alpha Protection activated forcing the aircraft to pitch down, which could not be corrected even by full back stick input. The crew eventually disconnected the related Air Data Units and was able to recover the aircraft.
An occurrence was reported where an Airbus A321 aeroplane encountered a blockage of two Angle Of Attack (AOA) probes during climb, leading to activation of the Alpha Protection (Alpha Prot) while the Mach number increased. The flight crew managed to regain full control and the flight landed uneventfully.
When Alpha Prot is activated due to blocked AOA probes, the flight control laws order a continuous nose down pitch rate that, in a worst case scenario, cannot be stopped with backward sidestick inputs, even in the full backward position. If the Mach number increases during a nose down order, the AOA value of the Alpha Prot will continue to decrease. As a result, the flight control laws will continue to order a nose down pitch rate, even if the speed is above minimum selectable speed, known as VLS.
This condition, if not corrected, could result in loss of control of the aeroplane.
The EASA requires as immediate emergency action that the flight crew operating manuals must be amended with a procedure to keep only one Air Data Reference Unit operative and turning the other two off in following cases:
- the aircraft goes into a continuous nose down pitch movement that can not be stopped by full backward stick deflection - the Alpha Max (red) strip completely hides the Alpha Prot strip (black/amber) without increase in load factor - the Alpha Prot strip rapidly changes by more than 30 knots during flight maneouvers with increase in load factor while autopilot is on and speedbrakes are retracted
Infrared Satellite Image SEVIRI Nov 5th 06:00Z (Graphics: Meteosat):
By Simon Hradecky, created Tuesday, Mar 24th 2015 20:43Z, last updated Tuesday, Mar 24th 2015 20:43Z
On Mar 24th 2015 Germany's Büro für Flugunfall Untersuchungen (BFU) reported in their November 2014 bulletin, that the first officer observed an irregularity in the properties of the speed indication just prior to reaching FL310 and disengaged the autopilot, the aircraft in response began a descent that lasted for about one minute before the crew was able to stop the descent at FL270.
The BFU reported Spain's CIAIAC delegated the investigation to the BFU on Nov 11th 2014.
The BFU reported that according to flight data and cockpit voice recorder the first officer (35, ATPL, 6,473 hours total, 5,179 hours on type) was pilot flying, the captain (52, ATPL, 16,384 hours total, 12,414 hours on type) pilot monitoring. After the aircraft climbed clear of top of clouds at about FL200 the flight data recorder recorded a fixed value of +4.2 degrees for the left hand AoA sensor, less than a minute later the FDR began to record a fixed value of +4.6 degrees for the right hand AoA sensor. The aircraft subsequently turned to fly direct to LATEK waypoint, during this turn the captain noticed the Alpha Protection Band had unusually and significantly increased. The first officer therefore reduced the climb rate from 800 to 500 feet per minute to enable the aircraft to accelerate. A short time later the first officer disengaged the autopilot and gave a brief nose down input.
The aircraft however continued to pitch down, inputs to counter the pitch down remained without effect. About 45 seconds after the nose down began the first officer alerted the captain who took control of the aircraft, that at this time had reached a rate of descent of 4000 feet per minute and a pitch of -3.5 degrees. The captain provided a maximum nose up input which caused the aircraft to pitch up again and the rate of descent decreased and the aircraft entered level flight.
The captain was able to maintain altitude by providing a continuous nose up input deflecting the side stick about 50% of its travel. The autopilot could not be engaged again, and a manual nose up trim was not possible.
The crew checked for related checklists but did not find any. The crew reset the Flight Augmentation Computers 1 and 2 in sequence with no effect.
8 minutes after the aircraft began its descent the Aircraft Communications Addressing and Reporting System (ACARS) issued an automated information to dispatch showing the three AoA sensor values amongst other data.
21 minutes after the aircraft began its descent the crew sent a message to maintenance checking whether a simultaneous reset of all FACs would be possible. Maintenance replied in the positive stating that the aircraft would revert to alternate law as result. Another 7 minutes later the crew reported they needed to constantly pull on the sidestick, trim was inoperative and autopilot could not be engaged and the Alpha Prot Band came up extremely quick. In addition the crew received a message "PH6 AOA3" on the centralized fault display system (CFDS). Upon suggestion by maintenance the crew switched off the air data reference unit (ADR3), however, without effect. ADR3 was reengaged. Another 12 minutes later maintenance wrote a message to the cockpit along the lines "after review of the data we found the values for AoA 1 and AoA2 appear to be frozen and report too high an angle of attack. If the problem persists, disengage ADR1 and ADR2 which will cause the aircraft to revert to Alternate Law however." then followed up "perhaps it is sufficient to just disengage ADR2".
The crew disengaged ADR2 which immediately prompted the aircraft to revert to Alternate Law and it was no longer necessary to pull the nose up.
The crew decided to use the remaining hour of flight time to verify the system status and to prepare for landing and landed safely at the destination.
The BFU reported that the aircraft features three Angle of Attack sensors consisting of a heated movable vane, the movement of the vanes is converted into electrical signals and the actual angle of attack computed by the related air data reference unit.
If the measured/computer Angle of Attack exceeds the value of Alpha Prot by one degrees, the autopilot is automatically being disengaged. In manual flight if the Alpha Prot Angles is exceeded, the Alpha Protection activates, the position of trim is stored and used as maximum nose up trim, the function of the side stick changes to command a specific pitch angle with the most nose up angle being Alpha Max which can be reached by full nose up deflection of the side stick.
The BFU reported that all three AoA sensors were examined by the manufacturer, no damage, malfunction or anomaly was identified with either of the sensors.
Airbus analysed the data and stated: "all three sensors worked normally until about 8 minutes into the flight, when the aircraft climbed through FL195. At that point, at an ambient temperature of -35 degrees C, AoA sensors 1 and 2 froze up at a position of approximately 4.5 degrees nose up and remained in this position until the aircraft descended towards the destination airport. At the time, when the autopilot disengaged the aircraft was flying at 0.675 mach, the Alpha Prot angle was 4.2 degrees, the Alpha Max 5.8 degrees. Within 15 seconds the first officer made increasing nose up input until reaching 75% of the maximum travel of the side stick, the attitude however changed from 4.5 degrees to -3.5 degrees against this input. The system disregarded/turned off the AoA 3 sensor because it disagreed more than the permitted value with the other 2 sensors.
When later ADR2 was disengaged, the system immediately reverted to Alternate Law because ADR3 had already been disengaged by the system and now two ADRs were offline.
The BFU reported that they are working to establish how reliable AoA sensors are but annotated: "The algorithms and boundary conditions differ from each other and are not entirely known to the BFU. The investigation is aiming to establish the probability of a repeat of this occurrence."
Graphical Representation of Flight Data (Graphics: BFU):
Reader Comments: (the comments posted below do not reflect the view of The Aviation Herald but represent the view of the various posters)
better sensors By Joe on Tuesday, Jun 9th 2015 03:32Z
In response to SafetyLok, Mar 24th 2015 22:14Z. My group is working on a laser-based sensor that will give simultaneous airspeed and AOA without ambiguity. You would get both if the sensor is working, neither if it isn't. Years away from approval, though.
@pete fitz: Automatically Detecting frozen AoA sensors... Is it not easy to do? By DWL on Saturday, Apr 4th 2015 11:59Z
Good solution promoted by you - BUT: Would be more elegant to REALLY test regually the AoA sensors or others:
There are already algorhytms i.e. In telecommunication units since decades (!) to filter out wrong data transmission. This could help identifiing AUTOMATICALLY frozen or not-functioning sensors like AoA senors or others: i.e. If "data-noise" becomes too even (=frozen) the autopilot changes the REAL AoA of the A/C by a minimal, but normally measurable part- the AoA sensors reflecting the changement are then to be classified as "well functioning", those which do NOT, are out of function. A SERIES of just minimal changements of AOA then would CLEARLY CONFIRM the correctly AOA sensors and even COTRECTLY overrule a "majority" of non-functioning AoA sensors. And even REACTIVATE automatically if returning in non-frozen condition!
A330 AOA blockage! By Hello Kitty pilot on Friday, Apr 3rd 2015 02:57Z
EASA Emergency AD Addresses A330 AOA Sensor Icing
Dec 6, 2012 Sean Broderick | Aviation Daily
EASA Emergency AD Addresses A330 AOA Sensor Icing: Dec 6, 2012.
The European Aviation Safety Agency (EASA), prompted by a recent Airbus A330 incident, has issued an emergency airworthiness directive (AD) ordering A330 and A340 operators to update flight manuals with new procedures if multiple angle of attack (AOA) sensors become blocked.
@m0n1k3r By Cyrus on Monday, Mar 30th 2015 07:06Z
Not only the dodgy batteries of the Boeing 787 but the faulty rudder of the Boeing 737 (2 major accidents possibly more) and the faulty reverse thrust system activating in flight (Lauda Air Boeing 767 crash) which turned out to be not an isolated case. And now we read about the Norwegian 737 with the jammed elevator on this site.
Fly Boeing? I don't think so. By m0n1k3r on Saturday, Mar 28th 2015 22:59Z
TL: Fly Boeing? The company that makes aircrafts with batteries that overheats mid-flight? I don't think so.
It's gootta be a good 'ole 707 before I fly in one.
airbus By jimmy J on Saturday, Mar 28th 2015 02:17Z
Gotta love airbus. Does things pilots cant control
By PF on Friday, Mar 27th 2015 18:49Z
Components in aircraft had failures before and that doesnt make a particular manufacturer better or worse. It just needs the particular part to be fixed and thats it.
Boeing had issues with the rudder hardover on the 737 for example and it was solved. The 787 had battery thermal runaways, and it was solved.
Lets not use this incident as an AvsB discussion.
Both manufacturers produce great and safe aircraft.
I don't know you, but I'll will be looking after AD for those AOA probes By (anonymous) on Friday, Mar 27th 2015 14:56Z
@R. Schneider Do you work for Airbus? Are we supposed to sit calm while we know there is a flaw in the design of these aircraft? If your solution is to turn 2 out of 3 ADRs, this plane shouldn't be flying at all.
@Andy By Brian Johnson on Friday, Mar 27th 2015 08:28Z
It was a Boeing 757, as someone else posted just a few comments below. If you had taken the time to read, you may have seen another poster stating that. That Boeing aircraft (not a Transavia 737) was been controlled by the autopilot and it was the Boeing's autopilot that brought the aircraft into a stall. "... I am not sure if it was 737 of Transavia..." If you are not sure, then please check your facts before posting.
@shcerer By Andy on Thursday, Mar 26th 2015 18:37Z
B757 in Dominicana ( I am not sure if it was 737 of Transavia ) - there was no pilots in the cockpit, but device operator :-)
Pilot should know, how to adjust power and pitch to get level flight at desired speed. Speed indicator is not necessary for safe landing - RA activates bellow 2500 feet, VSI takes data from IRS ( 737 ), not from ADS - what is the problem?
If airline pilot is not able to recognize false indications of speed by comparition with other side and standby one should take more lessons from basic aviation.
AoA stability By pete fitz on Thursday, Mar 26th 2015 12:48Z
A thought on frozen AoA sensors: A frozen sensor would give an absolutely steady output. A working sensor would give very slight variations in its output due to airflow disturbances. Software could detect the frozen state and give an immediate warning to the crew of the problem so they may take appropriate action.
@Pilot By FlatPilot on Thursday, Mar 26th 2015 12:18Z
On Tuesday 24th you already knew the origin of the crash ?? Wow, impressive ! But wait... this was not the origin of the crash... Don't you feel stupid now ?
No problem, Collie By TL on Thursday, Mar 26th 2015 06:14Z
fly Boeing.
@Collie By Ken on Wednesday, Mar 25th 2015 23:33Z
I'm with you Collie. And look what's just happened...
@scherer By John O on Wednesday, Mar 25th 2015 20:18Z
Birgen Air Boeing 757 crash 1996 Dominican Republic - blocked pitot tube.
By (anonymous) on Wednesday, Mar 25th 2015 16:23Z
People say why didn't the pilots just do this or that. Airbus tells companies how to fly the airplane. Companies in turn train to comply. You aren't just allowed to just do whatever you desire. Takes a lot of explaining. When things go wrong procedures are followed that are developed by airbus/operator. Those procedures may or may not be viewed the same by all but that's what's done. The complexity of airbus logic is why many do not like the engineering. Another layer of complexity is introduced that is arguably not needed.
Who is flying the plane By David Bunney on Wednesday, Mar 25th 2015 15:28Z
As a designer of complex control systems (who is not in the aviation business) I have a number of questions about who is flying the plane.
Automated control systems make complex decisions based on input data, control decision algorithms and external input from a human or external separate control system.
1) augment airflow input data with different independent (different technology sources GPS, gyroscope, ground radio beacon, onboard radar)
2) supervisory systems which look at the health of sensors, comparing different sources and looking for sudden or inconsistent changes in information....
3) the pilot should have clear override capabilities and clarity of display showing basic flight data with obvious disagreements between airflow sensors and other sources...
who is flying the plane and based on what information?
Why I don't like Airbus By Collie on Wednesday, Mar 25th 2015 14:18Z
Two of three AOA vanes freeze up. Computer thinks the two bad AOA's must be right so it shuts off the only good AOA. Now Computer thinks the aircraft is in a stall and orders nose down. Pilots pull back on stick to no avail.
Computer thinks it is smarter than the pilots.
Pilots finally turn off Computer and are able to fly in alternate law.
Computer = HAL 9000. (Actually Computer = know-it-all Airbus engineers)
@Pilot and all others who might think this is what's happend to the Germanwings flight as well By R. Schneider on Wednesday, Mar 25th 2015 13:38Z
Two reasons why this incident of frozen AoA-sensors cannot be the fatal cause for the Germanwings crash.
1.) The constant AoA-value due to the frozen sensors exceeded the Alpha Prot angle limit because of the increasing Mach-number during the climb. The constant descent of the Germanwings plane would have led to a Mach-number reduction thus bringing back the Alpha Prot above the frozen value.
2.) Look at the flight data diagramm kindly shared by Simon. Once the Lufthansa crew commenced their planned descent into Munich, at approx. 20.000ft the frozen #1 and #2 AoA-sensors eventually thawed.
Both reasons show that even if the same event of frozen sensors also occured on the Germanwings flight at the beginning, it cannot be the cause of the crash. Even if the crew did nothing to counteract (although a QRH revision was released), at a certain point during the descent, the system would have regained its normal working order again by either the thaw of the sensors or the increased Alpha Prot limit.
By opinionist on Wednesday, Mar 25th 2015 05:51Z
@ pilot: thanks for info. Then is all an unfortunate coincidence.
At jorge: if you look at AoA 3, you will see that there are oscillations (which is normal), while AoA 1 and 2 are flat lines. So it can be implemented a protocol in which the computer to check for such flat lines, and to do something ( warn pilots, disregard sensor readins, etc)
AoA information to pilots By Jorge on Wednesday, Mar 25th 2015 02:39Z
Why don't Airbus implement a way to show the values returned by the AoA vanes to the pilots? This simple implementation would alow pilots to better assess the situation and take measures to handle it.
Frozen sensors on Boeing? By Scherer on Wednesday, Mar 25th 2015 02:32Z
Does anybody know about any event/incident/accident with Boeing aircraft due to frozen AoA sensors or Pitot tubes ?
to lotty about "reminds of AF447" By Antonio.O on Wednesday, Mar 25th 2015 00:48Z
The AF447 did stall. You can read the whole BEA final report, and check the audio/transcription of the cockpit voice recorder from the moment AP disengaged, up until the plane crashed into the ocean.
Summarizing, pitot tubes did freeze, resulting in abnormal airspeed readings, which prompted the AP to disengage. The pilot who gained control of the plane thought they were close to or stalling -which was not the case at this point-, so he started inputting full nose up commands, and set the engines to full thrust. I'm not an expert and I don't remember what really caused the plane to stall, I think it reached an altitude outside the flight envelop of the airplane, where enough lift could not be generated. Stall warnings would sound, and from that moment on, the plane plunged through the sky, nose up, until it crashed into the ocean.
BFU By Pilot on Tuesday, Mar 24th 2015 23:35Z
The BFU document about the Lufthansa plane was created at 09:48:11 on 24th March 2015. The take off of the Germanwings plane was planed for 9:35 on 24th March 2015 and delayed 20 minutes. So the document was created and released while the plane was waiting to take off. All times in CET (MEZ).
heated AoA sensors frozen ? By zurk on Tuesday, Mar 24th 2015 23:24Z
Why doesnt the flight computer track temp of the AoA vanes to verify normal operation ?
AOA By Maciej Swic on Tuesday, Mar 24th 2015 23:13Z
To you who suggest AoA can be replaced by airspeed etc. That is not true. AoA is a function of wing vs airflow angles. Airspeed is a speed, not an angle. Pitch cannot replace it either because you may be in an up or downdraft etc. I agree these accidents shouldnt happen but the AoA sensors are necessary.
By Opinionist on Tuesday, Mar 24th 2015 22:31Z
Interesting that BFU released this material today. Either they have some extra info related to Germanwings crash (via ACARS?) and they prepare the attack against airbus, or they show lack of proffesionalism, by inducing the idea of a probable cause to audience in this domain, just because someone in BFU believe that Germanwings airplane experieced similar situation.
@pilot By il 76 on Tuesday, Mar 24th 2015 22:20Z
The reasons why this isn't the same as the Lufthansa case.
The pilots never calles in a mayday.
They couldn't solve a known problem in 8 minutes? Sounds strange.
2 out-of 3 By SafetyLok on Tuesday, Mar 24th 2015 22:14Z
Its a corner-case with classic m-out-of-n voting systems if the majority of the sensors are faulty then the system has no choice but to disregard the good sensor.
Having an actuator to deflect the sensor on a periodic basis to perform an in-flight self test could only cause more reliability issues.
Is there any better solutions to AoA sensors and Pitot Tubes?
Pilot By B737 Pilot on Tuesday, Mar 24th 2015 22:07Z
A lot of the German Wings pilots are Luftie pilots that transferred over, they are all equally well trained. Total years flying has nothing to do with hours flown and hours on aircraft type