Turkish airliner crashes at Schiphol
Join Date: Jan 2008
Location: US
Posts: 251
Likes: 0
Received 0 Likes
on
0 Posts
I too value cargun's post
Cargun as a non pilot has introduced an important perspective we would all do well to take into account and doesn't deserve the dismissive put down his comments have received from some.
Yes, the failure of a relatively unimportant piece of equipment should not have led to the accident under discussion, but it did. Yes, the performance of the crew in monitoring the approach appears to have been woeful and well below the standards we as professionals would expect. But guess what, as we all know sh!t happens on a regular basis and under different circumstances I expect this should have been a non event. Just another unremarkable 'save' involving the man/machine interface gone awry yet resulting in a normal landing, leaving no one any the wiser but also leaving the potential for disaster in place for another crew on another day under a different set of circumstances.
Bottom line, what the man on the street will likely take away from all this is that in a well designed system the failure/malfunction of a relatively minor piece of equipment (RA#1), should not lead to inappropriate operation (idle at 2000') of a relatively major piece of equipment (A/T). It would appear that the MEL does in fact address this very scenario by prohibiting the use of A/T with a malfunctioning RA#1, but obviously the MEL was an insufficient safeguard and something else will have to be considered involving both engineering and flight crew procedures.
Yes, the failure of a relatively unimportant piece of equipment should not have led to the accident under discussion, but it did. Yes, the performance of the crew in monitoring the approach appears to have been woeful and well below the standards we as professionals would expect. But guess what, as we all know sh!t happens on a regular basis and under different circumstances I expect this should have been a non event. Just another unremarkable 'save' involving the man/machine interface gone awry yet resulting in a normal landing, leaving no one any the wiser but also leaving the potential for disaster in place for another crew on another day under a different set of circumstances.
Bottom line, what the man on the street will likely take away from all this is that in a well designed system the failure/malfunction of a relatively minor piece of equipment (RA#1), should not lead to inappropriate operation (idle at 2000') of a relatively major piece of equipment (A/T). It would appear that the MEL does in fact address this very scenario by prohibiting the use of A/T with a malfunctioning RA#1, but obviously the MEL was an insufficient safeguard and something else will have to be considered involving both engineering and flight crew procedures.
Join Date: Jan 2008
Location: London
Posts: 58
Likes: 0
Received 0 Likes
on
0 Posts
To all the techies who want to have infallible systems.
The autothrottle received a signal from the radalt to go to flight idle.
The crew apparently didn't notice.
Imagine if
The throttles were in flight idle (normal early in the approach) and then just 'dropped out' of its own accord (it happens) so did not apply power when needed.
The crew did not notice.
The effect in both cases is the same.
Why the autothrottle failed to apply power is not immediately relevant to the accident
The crew not taking action is.
The autothrottle received a signal from the radalt to go to flight idle.
The crew apparently didn't notice.
Imagine if
The throttles were in flight idle (normal early in the approach) and then just 'dropped out' of its own accord (it happens) so did not apply power when needed.
The crew did not notice.
The effect in both cases is the same.
Why the autothrottle failed to apply power is not immediately relevant to the accident
The crew not taking action is.
With all respect to the software engineers, as I have often said before, the only people who understand the pilots' task is (you've guessed it!) fellow pilots.
As pilots we look at this from a completely different perspective. Our experience and training teaches us that no level of automation is perfect. In simple language automation will NOT prevent you from crashing an aeroplane. As an example I don't know about you but when I am doing an autoland in Cat 3 I am watching what it does VERY carefully! I hope I wouldn't hesitate in taking over manually/going around if I thought things were going pear shaped. (And yes I know this was a single channel approach) Another example, I watch very carefully to see that the autopilot acquires and goes ALT HOLD at the correct level etc. I could mention many other examples but in a different context I recall Ronald Reagan's answer when asked about Russia's intent - he said "Trust BUT VERIFY" - I think this can be applied to automation. My early experience on very manual a/c with very basic autopilots (NO Autothrottle) has taught me to be wary of automation. Recently I mentioned to a new copilot that on the B737-200 we didn't even have Alt Alert let along Alt Acquire or autothrottle for speed control - he looked at me in amazement. So in the "olden days" calls like "ONE to GO" were VITAL and the non flying pilot kept a careful eye on what was going on.
The software engineer techie guys want to fix it all with the automation and, yes, maybe the design could be better with hindsight. But I think there is something fundamental which needs looking at with respect to the man/machine interface.
As pilots we look at this from a completely different perspective. Our experience and training teaches us that no level of automation is perfect. In simple language automation will NOT prevent you from crashing an aeroplane. As an example I don't know about you but when I am doing an autoland in Cat 3 I am watching what it does VERY carefully! I hope I wouldn't hesitate in taking over manually/going around if I thought things were going pear shaped. (And yes I know this was a single channel approach) Another example, I watch very carefully to see that the autopilot acquires and goes ALT HOLD at the correct level etc. I could mention many other examples but in a different context I recall Ronald Reagan's answer when asked about Russia's intent - he said "Trust BUT VERIFY" - I think this can be applied to automation. My early experience on very manual a/c with very basic autopilots (NO Autothrottle) has taught me to be wary of automation. Recently I mentioned to a new copilot that on the B737-200 we didn't even have Alt Alert let along Alt Acquire or autothrottle for speed control - he looked at me in amazement. So in the "olden days" calls like "ONE to GO" were VITAL and the non flying pilot kept a careful eye on what was going on.
The software engineer techie guys want to fix it all with the automation and, yes, maybe the design could be better with hindsight. But I think there is something fundamental which needs looking at with respect to the man/machine interface.
Join Date: Oct 2008
Location: Universe
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
foresight: Automation confusing or not informing the crew is just bad design. As RichieD writes either there is redundancy and fallback with equipement like this or it should be left out.
The risk with this is "perceived" safety with systems that have some serious bugs. Perhaps Boeing/Airbus overpromising and underdelivering on automation?
The risk with this is "perceived" safety with systems that have some serious bugs. Perhaps Boeing/Airbus overpromising and underdelivering on automation?
Cargun
As a probationary annonymous Ppruner or not your blood red post above directed at Rainboe does a good job of highlighting some fundamental diiferences in opinions that some of us have about causal factors in this and many accidents.
Perhaps oversimplifying it, but the questions seems to boil down to
'what good is automation if it's not perfect and leads to a crash"?
Burried in rainboes and others words was the hint that automation in total saves lives.
In order for automation to be effective it has to anticipate failure conditions and make choices of what is the safer condition (FMEA stuff). Clearly these choices were approved as viable once certified. Unless you have access to the full Failure Mode and Effects Analysis (FMEA) used to certify the functionality of the equipment you can not fault the design that it made less safe choices.
And once again I say that the FMEA design choices do consider that the average crew will detect and accomodate minor failure conditions for the specfic flight conditions encountered.
What Boeing is saying at this time (my read of their letter) is to remind crews of this presumption. If it turns out that a "lesson learned" is that an average crew may not be presumed to be able to handle this than you can expect a removal of the automation or a design change.
Now I'll stand down for a bit and see how the rest of you feel about this.
As a probationary annonymous Ppruner or not your blood red post above directed at Rainboe does a good job of highlighting some fundamental diiferences in opinions that some of us have about causal factors in this and many accidents.
Perhaps oversimplifying it, but the questions seems to boil down to
'what good is automation if it's not perfect and leads to a crash"?
Burried in rainboes and others words was the hint that automation in total saves lives.
In order for automation to be effective it has to anticipate failure conditions and make choices of what is the safer condition (FMEA stuff). Clearly these choices were approved as viable once certified. Unless you have access to the full Failure Mode and Effects Analysis (FMEA) used to certify the functionality of the equipment you can not fault the design that it made less safe choices.
And once again I say that the FMEA design choices do consider that the average crew will detect and accomodate minor failure conditions for the specfic flight conditions encountered.
What Boeing is saying at this time (my read of their letter) is to remind crews of this presumption. If it turns out that a "lesson learned" is that an average crew may not be presumed to be able to handle this than you can expect a removal of the automation or a design change.
Now I'll stand down for a bit and see how the rest of you feel about this.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
What RB is trying to say in his clumsy way is that this 'design fault' should not be significant. One would expect it to be picked up by an normal crew fairly soon. To overcome it requires a simple click to disconnect the A/throttle. If someone is 'watching the shop', the resulting speed loss should also be picked up early and easily corrected. There are dangers in over-engineering systems and other unknown traps can be generated, as the PGF AB showed. As I said before, I agree it would have been a good idea if an 'alert' were issued by the a/c, since other systems may well be compromised by a 'failure' (of no1 RA) but I would argue against an automatic reversionary mode.
Join Date: Feb 2008
Location: sussex
Age: 80
Posts: 23
Likes: 0
Received 0 Likes
on
0 Posts
It seems at last that most people now agree with my early comment that there was no one flying the airplane, I must add to that the comment that Boeing should not have a system that allows 2 RAs to show different readings (within a specified tolerance of course) without at the very least issuing a warning and more probably disconnecting them both. After all there are still steam altimeters on the panel arent there.
So its both the pilots and Boeings fault. As to why the pilot flying was not flying, without information from the CVR we may never know, lets hope it throws some light on this.
So its both the pilots and Boeings fault. As to why the pilot flying was not flying, without information from the CVR we may never know, lets hope it throws some light on this.
the lunatic fringe
Join Date: May 2001
Location: Everywhere
Age: 67
Posts: 618
Likes: 0
Received 0 Likes
on
0 Posts
I find it interesting in reading this thread, that (broadly) the non-pilot people want to blame and fix the electronics, and the pilots just say... bad piloting.
Having flown the A320, the B747, and B737 through my career, I have had the joy of comparing Airbus automation and fly-by-wire, with the more conventional Boeing. Whilst the extra layers of automation are technically wonderful, and on paper seem a real bonus to safety, my observation is that the added complexities that were designed to make the aircraft safer, merely generated new failure modes that at times were exceedingly hard to diagnose. I loved my time on the Airbus, and love the Boeing. But do not be led down the primrose path of computers and automation and think that safety is necessarily going to be enhanced by an new shiny black box.
Humans fly aeroplanes, and good people, and good training are vital. People need to connect with the aeroplane, and automation often, if badly designed, removes people form the loop. But a conventional aeroplane, with speed decaying gives off numerous signals and clues. Long before a stall warning, or stick shaker. Two big levers in the middle, in the closed position. Pitch increasing. Noise decreasing. Lots of autopilot trimming. But it is the silence that is the huge clue. Who was minding the stall?
"You have control, your radios, I'll run the checklist".
Distraction management is a key issue here. Only the CVR and FDR will tell us how the flight was, or was not mismanaged.
Having flown the A320, the B747, and B737 through my career, I have had the joy of comparing Airbus automation and fly-by-wire, with the more conventional Boeing. Whilst the extra layers of automation are technically wonderful, and on paper seem a real bonus to safety, my observation is that the added complexities that were designed to make the aircraft safer, merely generated new failure modes that at times were exceedingly hard to diagnose. I loved my time on the Airbus, and love the Boeing. But do not be led down the primrose path of computers and automation and think that safety is necessarily going to be enhanced by an new shiny black box.
Humans fly aeroplanes, and good people, and good training are vital. People need to connect with the aeroplane, and automation often, if badly designed, removes people form the loop. But a conventional aeroplane, with speed decaying gives off numerous signals and clues. Long before a stall warning, or stick shaker. Two big levers in the middle, in the closed position. Pitch increasing. Noise decreasing. Lots of autopilot trimming. But it is the silence that is the huge clue. Who was minding the stall?
"You have control, your radios, I'll run the checklist".
Distraction management is a key issue here. Only the CVR and FDR will tell us how the flight was, or was not mismanaged.
Join Date: Jan 2008
Location: London
Posts: 58
Likes: 0
Received 0 Likes
on
0 Posts
dicks-airbus
Speaking as an (ex) NG line captain, i would rather have a simple A/T malfunction than someone flashing/shouting 'Radalt Comparator Warning' as well. That would totally throw me!
It is enough for me that,when it really matters, Boeing assures me that a radalt misreading will cause the autopilots to drop out on a dual channel approach.
Even then, I might not have time to work out why but at least I know what I have/don't have.
Too much information on the status of non essential equipment is undesireable during the approach
It is enough for me that,when it really matters, Boeing assures me that a radalt misreading will cause the autopilots to drop out on a dual channel approach.
Even then, I might not have time to work out why but at least I know what I have/don't have.
Too much information on the status of non essential equipment is undesireable during the approach
Join Date: Dec 2005
Location: At home
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
cargun
Having said all this. Can anyone clear me on the ATC's role in 100 seconds of crew paralysis. Shiphol ATC having a radar and ILS should have closely monitored the 737's approach on their screens, starting at around 2500 feet.
First, as seen by ATC the approach (according to available data) looked perfectly acceptable for the first 85 seconds or so. Slightly hot and high initially but capturing glideslope and slowing down nicely before 500 ft, nothing extraordinary. And even in the critical last 15 seconds as the plane slowed below Vref, it was still on the glideslope until just before stall.
Second, The ATC radar rotates at some 5 sec/revolution so the tower controller had perhaps 3 or 4 echoes available during the critical last 15 seconds to notice the airspeed becoming dangerously low. Not much time.
Third, the tower controller's first job is not to fly the Turkish B737, it's to maintain separation between approaching aircraft and make sure the runway is clear for landing aircraft. So his (assuming a he) attention may actually have been focused on the reducing separation distance to the next aircraft in line and maybe considering instructing that aircraft to slow down or go around. Which actually was what happened, if I remember correctly the ATC discussions from the first days. And he had probably some additional aircraft to monitor and control at the same time.
Fourth, even if he noticed the developing situation he may have been engaged in a radio call to some of the other aircraft and decided to finish it before attending to the Turkish aircraft. The controller is not responsible for basic flying of the aircraft!
Fifth, the tower controller most probably did not get to see the 737 visually in the haze. Or if he did, only the landing light and therefore had no way of visually judging the approach. The stall happened some 1.8 NM before the threshold and the tower is near the opposite end of rwy 18R, i.e. some 3-4 NM from where it stalled.
Sixth, there is no record that the 737 at any time notified ATC of any problem (RA or other) that would have precluded a normal approach.
In summary, this was an accident where the tower controller basically had no information of the problems that led to the stall, until the very last seconds of those 100.
Corrections from pros welcome
Join Date: Oct 2008
Location: Universe
Posts: 71
Likes: 0
Received 0 Likes
on
0 Posts
foresight: Afaik there was no notification to crew that there was a RA failure. The only thing they got presented was "gear down" and not a RA malfunction warning.
Automation leading to confusion is bad and risky automation. Is a bit like Win95 on a plane
.
Automation leading to confusion is bad and risky automation. Is a bit like Win95 on a plane
.
Join Date: Mar 2007
Location: south east UK
Posts: 375
Likes: 0
Received 0 Likes
on
0 Posts
it is VERY easy for them to become so distracted that they forget to do their primary function - IMHO the blame sits firmly with Boeing, they should not have released a system that allows the system to effectively ignore conflicting information WITHOUT warning the crew that there may be an issue
The failure in this instance should have been absolutely insignificant - infact if you use your techie software approach 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.
Besides the crew (aparently) ignored a significant number of 'warnings' (pitch, noise, airspeed indicator, thrust lever movement, FMA annunciations and more) - you really think they would have noticed another one!
I also see an interesing aspect of our modern society in this discussion. i.e it must be someones fault - lets invent another layer of oversight to fix this one issue etc etc. And in todays society I can understand why some people have a problem understanding the fact that the pilot is responsible for his actions - that is a concept that a whole generation cannot appreciate as they have been bought up in a world with no responsibilty or consequence.
Join Date: Feb 2009
Location: Cambridge (the original one)
Age: 76
Posts: 53
Likes: 0
Received 0 Likes
on
0 Posts
This may be too obvious, but the question is "why was there no crew reaction to thrust being too low for over a minute?" The answers and remedies may be CRM-related, avionics design related or, most likely, a mix of the 2. We have to wait for CVR and more FDR data.
Join Date: Oct 2007
Location: Carmarthen
Posts: 63
Likes: 0
Received 0 Likes
on
0 Posts
Add a few lines of code to detect a value change in sensor greater then x in y (milli)seconds. If that happens, issue warning that something is fishy. Repeat at each value change. After that switch over to next available device. If none available inform crew and disconnect all dependant systems.
Join Date: Jul 2000
Location: U.S.A.
Posts: 474
Likes: 0
Received 0 Likes
on
0 Posts
Misuse/misunderstanding of auto throttles is nothing new.....
DCA97MA049
As I recall, the tail of this aircraft was removed for analysis during the investigation of 587.....loads on the vertical fin during recovery were enormous.
DCA97MA049
As I recall, the tail of this aircraft was removed for analysis during the investigation of 587.....loads on the vertical fin during recovery were enormous.
Join Date: Nov 2006
Location: SoCalif
Posts: 896
Likes: 0
Received 0 Likes
on
0 Posts
Expecting Turkish, or Boeing to accept any blame for this accident at this time is stupid. Blame will be apportioned in accident reports and courts of law. Only then may admission of blame be expected.
We third parties can cite the failures of any and all, and expect to be joined by partisans who have a dog in this fight. Some may even be correct.
GB
We third parties can cite the failures of any and all, and expect to be joined by partisans who have a dog in this fight. Some may even be correct.
GB
Join Date: Mar 2009
Location: WAW
Age: 56
Posts: 20
Likes: 0
Received 0 Likes
on
0 Posts
Rainboe,
Yes, perhaps. But its occurence - sudden drop from 2000 feet or whatever to 'on ground' value without transitioning through values consistent with flare - IS NOT and is a clear evidence of malfunction (seemingly a failure mode not taken into account by designers, not quite uncommon as it turns out).
Putting aside obvious airmanship issues, situation of a malfunctioning instrument feeding erroneus data into (whichever) system is not a desired one. Malfunction should have been detected by RA's logic and the RA just flagged INOP, I think you agree.
There's nothing wrong with enhancing onboard safety systems. Eventual modification to the RAs (simple trend monitoring) would not inflict any weight penalty, being made purely in software. One hole in a swiss cheese less.
Regards,
MikeEPBC
1- how does the system 'know' RA1 is at fault? Who is to say what the correct reading should be? It's in failure mode- to the RA, -8 was a perfectly valid reading.
Putting aside obvious airmanship issues, situation of a malfunctioning instrument feeding erroneus data into (whichever) system is not a desired one. Malfunction should have been detected by RA's logic and the RA just flagged INOP, I think you agree.
There's nothing wrong with enhancing onboard safety systems. Eventual modification to the RAs (simple trend monitoring) would not inflict any weight penalty, being made purely in software. One hole in a swiss cheese less.
Regards,
MikeEPBC
Join Date: Mar 2009
Location: Turkey
Posts: 1
Likes: 0
Received 0 Likes
on
0 Posts
Hello all,
Like many people said, I think pilots should aviate first and know their airplane inside out. But I also think it's good to eliminate potential problems.
I have some questions not directly related to this accident..
Some pilots in this thread reported that altitude call-outs were not available when RA#1 indicated -7 ft during their flights.
- Does that mean some or all GPWS modes are inhibited during this type of fault?
- What about TCAS RAs (resolution advisory) being so close to the ground? Does TCAS compare RA inputs? Are they inhibited?
- Fictional scenario on any a/c:
Fail-operational Autoland below actual or wrongly sensed alert height with disagreeing RAs, overreading or underreading?
Alert height is AGL height, sensed by RA. RA failure affecting alert height logic does not sound impossible, but I guess it depends how well the the avionics software handles RA errors and number of RAs.
- Any other potential problem not included in Boeing memo?
Like many people said, I think pilots should aviate first and know their airplane inside out. But I also think it's good to eliminate potential problems.
I have some questions not directly related to this accident..
Some pilots in this thread reported that altitude call-outs were not available when RA#1 indicated -7 ft during their flights.
- Does that mean some or all GPWS modes are inhibited during this type of fault?
- What about TCAS RAs (resolution advisory) being so close to the ground? Does TCAS compare RA inputs? Are they inhibited?
- Fictional scenario on any a/c:
Fail-operational Autoland below actual or wrongly sensed alert height with disagreeing RAs, overreading or underreading?
Alert height is AGL height, sensed by RA. RA failure affecting alert height logic does not sound impossible, but I guess it depends how well the the avionics software handles RA errors and number of RAs.
- Any other potential problem not included in Boeing memo?