Turkish airliner crashes at Schiphol

[StuntPilot]

By keeping the RA systems separate, you won't end up in a situation where the aircraft may flare and pull back to idle power at the wrong altitude. Beware sugested improvements that may make matters worse!

No, it is simple: if you crosscheck and notice data does not make sence, bail out to manual.

The emphasis on what the pilots could / should have done is understandable in this forum. But you should not have tunnel vision and be blind for the other accident enabling factors. Neither should you perform the simplistic act of blaming the crew and play the situation into a personal thing. That way, you don't learn why and how things happened. The 'they were stupid, I'm better' attitude is extremely childish and extremely dangerous.

[glob99]

WhipS Post 1510

What was your reasoning for not turning off the RA giving the spurious reading?

[fireflybob]

Blame will be apportioned in accident reports

Really? I thought the purpose of accident investigation was to establish the facts and then the probable cause with suggested measures to prevent recurrences?

I may be wrong but certainly don't believe the remit of the UK AIB is to apportion blame but maybe other States have different protocols?

[757_Driver]

those of you who think the boeing design is wrong - consider this. To any proposal you have to ask "would this have changed the outcome of the accident". if yes you then have to analyse if you've caused a problem elsewhere in the chain.
All the proposals above with rad alt logic fail the first question, as well as creating major autoland failure modes which fail the second question.
firstly if you want a system with rad alt comparison and rejection of a 'bad' input you need 3 rad alts, not 2. Thats a major new design - i.e a new aircraft. Other wise you don't know which is at fault.
Therefore with 2 rad alts - you want a comparison - fine - the only thing you can have is "hmm rad alt disagree, one of them is buggered, don't know which, immediate autothrottle and autopilot disconnect to ensure that an autoland doesn't continue". (doens't matter whether a single or dual channel approach was occuring with an intent to manaully land - the aircraft doesn't know the intent)
So you really think this crew would have noticed an autothrottle disconnect, rather than a functional autothrottle doing something odd?

Just for completeness in case you think I'm just sitting in the pilot-controls-the-aircraft camp by default then I'll add that before this career I was an engineer by trade, with a masters degree in engineering, Chartered Engineer status and a member of the Institute of Engineering Technology (formerly the IEE) and I have a 15 year engineering career behind me with significant experience of FMEAs and problem solving. With both hats on I still beleive that the buck stops with the pilot and that there was absolutely nothing wrong with the logic of the aircraft

[GearDown&Locked]

Kwh is right! You can have "awkward" radalt readings in a fairly stabilized approach. In the video bellow you can hear the airbus radalt calls going up and down depending on the terrain profile.

[MU3001A]

757 Driver

you will find that the reason that the system is designed thus is not an oversight or mistake by boeing but in order to ensure that it doesn't plough into the ground on a cat3 approach. The rad alt is primarily designed for cat2 and 3 autolands and GPWS, it is thoroughly irrelevent in all other aspects of flight.

So why was this piece of equipment irrelevant as you state, to the approach this crew flew, allowed to initiate the accident chain of events by idling the TL's at an inappropriate altitude and then compound the error by returning them to idle when the crew attempted the subsequent stall recovery?

Sometimes non pilot 'man in the street' perspectives are important and relevant. I think perhaps the apparent woeful performance of the crew in response to the event they faced is causing some to overlook obvious faults with the system as designed and be too dismissive of commenter's that are not rated pilots. Neither RA#1 nor the A/T was a particularly relevant piece of equipment to the approach being flown. But nonetheless the interaction between the two initiated the sequence of events that led to the accident under discussion. The only safegaurds in place to prevent this fatefull interaction between two pieces of non essential equipment were the MEL and a competent crew free of distraction, neither of which proved sufficient. JMHO

[Feline]

Important Semantic Distinction ...

Irrespective of what is linked to which Radalt, seems to me that there is actually a huge difference between "Failed" and "Malfunctioned".
"Failed" means totally non-functional, fuse blown, whatever - Instrument should then be conspicuously flagged as not working. Might have got someone's attention.
"Malfunctioned" implies that the instrument is still displaying an output which is within specified limits and therefore the instrument does not know it has failed.
I suspect (speaking as a one-time RF instrumentation engineer) that fault may have been external to the actual Radalt itself - dodgy connector or antenna - and therefore the Radalt would not diagnose itself as failed.

FWIW

[safta]

Today we simulated the Turkish scenario in a B733 simulator. At 1800 feet AGL and established on the ILS, we retarded the throttles to idle, simulating what the Turkish B738 autopilot did. The aircraft started trimming slowly at first, and then more and more rapidly to maintain the glide slope. We allowed the stick shaker to activate and after around 8 seconds of stick shaker we applied full thrust and attempted a recovery without reconfiguring. With the control yoke pushed as far forward as it could go, the aircraft started to accelerate and a climb was initiated and it appeared that we were recovering. Note that this is with the yoke pushed forward against the forward stop. Then, all of a sudden, the aircraft entered a deep stall as the rudder lost effectiveness and the aircraft forward speed rapidly bled off and we entered a 6000 ft/min plus rate of descent until impacting the ground in an apparent tail low attitude.

The reason for our not recovering was due to the extreme amount of trim the autopilot had applied while attempting to maintain the glide slope. The only way that we could have recovered would have been to apply extensive nose down trim during the initial recovery.

We performed this exercise twice and both times produced the same result. We firmly believe that this is what was the cause of the Turkish crash.

[mr. small fry]

Rainboe, it is very tempting to take the easy route and agree with your view that the crew must have been incompetent not to have realised what (maybe, subject to the final repot) transpires to have been obvious - ie no apparent awareness of speed decay.

I also agree that at any time we should be able to "fly" the airplane out of problems that computers may "guide" us into, and to monitor the automatics at all stages, especially critical ones below MSA.

Unlike you though, I prefer to look for the reason why any experienced 737 Captain could have possibly allowed such a situation to develop, and why he failed to recognise that the speed (apparantly) really was decaying so much. There might just be a bit more to this than first meets your critical eye. Doesn't it in some small way make you wonder just how such a thing could have happened? After all, to you at least it really is so obvious.

I tell myself that I would not make such a glaring error, and I am sorely tempted to believe that I would not, but in the past 22,700 hours I have missed traps that wore red, and were positioned right in front of my face!! I like to believe that I was fooled for a reason or reasons other than my shear incompetence, and for this reason alone I enjoy reading the input of those among us who may be non pilots or "techies" - their views, IMHO should not be discounted.

I enjoy your input to the forum, but please be kind enough not to correct any spelling or grammatical errors I may have made - I haven't mastered that either - yet!

[Fred Bound]

Today we simulated the Turkish scenario in a B733 simulator............We firmly believe that this is what was the cause of the Turkish crash

It's gone awful quiet in here.......

[slip and turn]

Yes, very quiet ... I think there's a few dusting themselves off in the sand tray after finding themselves no longer on their perches ...

[IO540]

I am both a pilot (though only GA and a CPL/IR) and a hardware/software developer of 30+ years.

A number of people have asked whether the system should have a feature to detect erratic radar altimeter readings.

One problem with that is that such a feature would involve some hardware and some software and could itself fail, and then what do you believe? You have yet another warning light trying to tell you something. Another problem is that radar altimeter readings can be erratic depending on the terrain some distance (miles) before the runway, so spurious warnings would not be uncommon.

I think that, reading the stuff in this thread, most pilots will conclude that this crew was not even in the cockpit.

[Rananim]

Can some kind person retrieve the data graph showing speed vs alt.I cant find it in this mess.The point is if idle thrust was sufficient to not trigger the stick-shaker until 450'(due lateish config),then the idea that this crew sat for 100 seconds and watched the speed decay is a nonsense.We need to establish the exact time delay between speed falling below 140 and attempted manual recovery.Disregarding the other errors they obviously made,this time span will reflect the true extent of their attention deficit with regard to speedtape..If you factor in the possibility that cloud break possibly occurred when speed decay was at its most,we can start to get a fairer picture of the why.Normal approaches see 50-60% N1 with Vref +5 being flown from 5-6 miles out.Not the case here.Wont change probable cause but it will be mitigating.

[GearDown&Locked]

At 1800 feet AGL and established on the ILS, we retarded the throttles to idle, simulating what the Turkish B738 autopilot did. The aircraft started trimming slowly at first, and then more and more rapidly to maintain the glide slope. We allowed the stick shaker to activate and after around 8 seconds of stick shaker we...(etc)

safta, how much time have elapsed from throttle closing until 8 secs of stick shaker may I ask?

[FrequentSLF]

According to rainboe the B systems are correct and the the pilots should have acted prevent the outcome. However I would not be surprised if the final report will include a request to B to modify the existing system design to alert/avoid the contributory cause to this accident.
I am still do not understand why the A/P have independent feedback from RA, while the A/T have only and always the feedback from RA1. I am not a pilot, but a former system designer, and the only answer to such design (two feedback for A/P and only one for A/T) is to save money. Other reason was to avoid further testing as a new design. I am not saying that better automation would have save the day, but looking at such design I can see many flaws that could be avoided.
FSLF

[MU3001A]

safta

Thanks for the informative post.

Do you recall HAT at the onset of the shaker/stall? Eight seconds seems a little too long before effecting a recovery, did you try recovering with more judicious application of thrust to preclude an accelerated stall?

[safta]

We did not time it but at a guess I would say around 30 to 40 seconds. Maybe someone else with access to a B738 sim can recreate the scenario I have described and possibly time the various stages of events leading up to the accident. A B738 may react slightly differently.

[Rainboe]

[safta]

did you try recovering with more judicious application of thrust to preclude an accelerated stall

We allowed the 8 seconds based on the probability that the crew would have been surprised by the stick shaker and may not have reacted immediately. However, when we attempted recovery we did so with max available thrust but pitch was limited by the available elevator control due to the immense amount of nose up trim.

We were somewhere around 1200 to 1300 feet AGL when we initiated the recovery.

[snowfalcon2]

Can some kind person retrieve the data graph showing speed vs alt.I cant find it in this mess.

Here is one. I made it last week but did not upload it as I was expecting better data to be released by DSB.

The thin dotted line represents my guess at the ground speed the aircraft should have flown, at prevailing wind and Vref around 130-140 kts.

Not shown in this graph is the fact that the aircraft was laterally off-track about 0.5 NM left of the centerline at the FAF (6.2 NM), and then became established around 5 NM. The QNH correction is 378 ft.



Datapoints are spaced 15 sec except the second from right (virtual FAF position inserted) and the last, which is where the aircraft came to rest. The second last data point is the one with the raw data showing -4096 fpm RoD and altitude -200 ft, i.e. the last reported in the OpenATC data.