Sign in to follow this  
Alpha Floor

Accident Study: Swiftair MD83 over Mali 2014

Recommended Posts

The Aviation Herald recently released an analysis of the Swiftair MD-83 crash in July 2014 over Mali, Africa.


I think it's pretty interesting. One of the causes of the accident was the failure of the crew to acknowledge a stall condition and their failure to perform a satisfactory upset recovery. The stalling condition was reached in the first place because of icing on the Pt2 engine sensor, which reduced the thrust output of the engines.



There was no sign of a reaction by the crew, other than the throttles movements, until the disconnection of the autopilot51 which occurred 25 seconds after the triggering of the stickshaker. The speed was then 162 kt, the altitude had decreased by about 1,150 ft. The aeroplane was banking to the left and its pitch was decreasing. The crew applied input mainly to roll to the right to bring the wings level. At the same time, they applied mainly noseup inputs, contrary to the inputs required to recover the stall and continued to do so until the ground.


Another interesting point and contributing cause to consider is the AutoPilot logic of the MD-83, which is capable of not only flying the aircraft into a stall when in Altitude Hold mode, but also of continuing engaged and commanding nose-up inputs even after the stall has commenced, thus making the recover process more difficult for the crew. This qualifies as a design flaw of the AP system. Not even a Boeing 737 would do that, and Boeing aircraft are known for letting the pilot take control.



Without any disengagement by the autopilot, the latter tries to keep its target. If it is in altitude hold mode, as is the case in cruise, the autopilot gives nose-up orders that are contrary to those required to recover the stall. After the triggering of the stall warnings such orders, by maintaining the aeroplane's pitch and by increasing the angle of attack and the nose up position of the horizontal stabilizer, rapidly make the situation worse, as well as the difficulty of recovery for the crew. In fact, these nose-up orders mask or delay the occurrence of a nose down movement which for the crew would constitute the ultimate indication of entering the stall, and make it necessary for the crew to apply a stronger and sustained nose-down input to recover from the stall. The FOB published by Boeing indicates that the aeroplane can slow down until the stall warning before the autopilot disengages. It does not however state that the autopilot may continue to give nose-up orders after the stall warning and does not indicate the consequences of this behaviour in terms of detection of and recovery from the stall.


Contributing to the accident:


  • Night time over the desert, i.e., no visual clues of the aircraft's path/attitude.
  • Trouble establishing communications with ATC.
  • High workload from trying to navigate around thunderstorm activity.
  • Engine EPR and N1 disagreement which they noticed and tried to correct.
  • A not-so-clear policy regarding Engine Anti-Ice usage.


Regarding proper stall recovery procedure, this is an excellent video by an American Airlines instructor:


Share this post

Link to post
Help AVSIM continue to serve you!
Please donate today!

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this