Turkish airliner crashes at Schiphol

[bobcat4]

MU3001A

Well, it's debatable whether the under-speed/over-speed protection available is worth the risk of a single malfunctioning RA surreptitiously placing A/T in the RETARD mode at 2000' and/or commanding idle thrust after manually selecting max thrust during a stall recovery attempt.

As Rainboe said:

[automation]...that has worked fine for all the world for 25 years.........except for 1 flight.


Of course it is almost impossible to speak about "acceptable losses" so I guess you're right... And what would a redesign mean? Another accident caused by a side-effect we never thought of? Loosing the under-speed protected as auto-retard is could lead to pilots forgetting to throttle down after flare, and over-shoot the rynway. Just one example, the next example is something I've not thought if yet....

[CHfour]

Safta,

The only way that we could have recovered would have been to apply extensive nose down trim during the initial recovery.

I also did a similar recovery in the sim recently. The lack of elevator authority is well documented and TOGA + full down elevator + nose down trim is the only way to go if you're that close to the ground. I still can't see why some recommend thrust limitation as a substitute for nose down trim. I'm sure that everyone gets to see this during initial type conversion.

[MU3001A]

bobcat4 Well learning from the experience of this accident I would suggest that in respect to the NG set-up the overriding design parameter of the RETARD function ought be ensuring that the A/T is only able to command RETARD at 27'RA and nowhere else, then build from there.

Note: the RETARD function is also invoked momentarily with LVL CHG but this doesn't involve the RA.

[HarryMann]

Yes, if the software actually looked for an approach to 27' and then busting that height having 'approached' it in a meaningful way, rather than looked for any (instantaneous) height reading below 27' - it might make a bit more sense...

[MU3001A]

dimitris lam Again yes, the RA didn't 'fail' which clearly, again is part of the problem, no?

In a correctly designed system the A/T would command RETARD reaching 27' RA and only 27' RA, not -8' RA not 1,500' or 0' or any of the other possible RA indications available. Once triggered the A/T should then stay in RETARD until the A/T disconnects 2 secs after receiving the WOW signal. If the RA doesn't see 27' then it shouldn't command RETARD, because landing without RETARD in the flare is a whole lot safer than having the A/T deciding without input from the crew to go into RETARD at 2000'.

HarryMann Yes, a one way check valve. IF (x=27', RETARD, otherwise don't)

[MU3001A]

It's not a design philosophy change it's a programming change. Right now the A/T is programmed to command RETARD when RA#1 sees any value below 27' and it probably needs to be re-programmed to command RETARD when it sees 27' and only 27' or 27' confirmed by two independent RA's or not at all.

[wiggy]

Mu3001a

You say: "Landing without RETARD in the flare is a whole lot safer than having the autopilot deciding without input from the crew to go into RETARD at 2000'"

Being "non - bus" I'm probably talking out of line - apologies if I am - but wasn't a failure to retard possibly the prime reason behind the Airbus going off the end at Congonas last year?

edited to add: In any case, floating along at x feet above the runway because the throttles don't close certainly isn't safe either......

[bobcat4]

Here we go again... Pardon me for not taking any side. In one post I agree with you, in the next I go like this:

MU3001A wrote:

HarryMann Yes, a one way check valve. IF (x=27', RETARD, otherwise don't)

Well, first you have to be 100% sure that the output sample rate is quick enough so it's not jumping from 28' to 26'. And clear every runways outer edges for 2' high objects. No fences more than 2 feet high. Theoretically RA could bounce from a fence when at 27' and in the next reading measure 26'. The result would be no RETARD and the problems that would imply. Although I have to admit this would be a rather low-angle approach, if you're at flare height right above the airport fence.

Now, there is also a question about accuracy. Is the RA really accurate to one feet?

Another spooky thing about this design is that a RA could output a faulty 27' reading at 2000' just like the -8' in this accident. We are not sure what cased the -8' reading, are we? Could as well have been 27' with the same outcome.

As you cleverly put it:

Well, it's debatable whether the under-speed/over-speed protection available is worth the risk [...]

Debatable. Yes indeed! That what it is! And that's what we're doing.

[MU3001A]

That was a bus. On the NG the A/T should disengage 2 secs after WOW and if it were me going into a place like Congonhas, I wouldn't be relying on the automation to close the throttles.

[HarryMann]

Well, I actually said:

... if the software actually looked for an approach to 27' and then busting that height having 'approached' it in a meaningful way, rather than looked for any (instantaneous) height reading below 27' - it might make a bit more sense...

A lot more logic involved than: IF (x = 27') = TRUE Then RETARD

This implies the rate of change should be -ve over a reasonable sample size approaching the condition (x < 27) and that sample should be within certain aboslute values ( e.g. 202'; 147'; 98'; 39' ; -2' (<27' >RETARD)

So 2,000'; 1850'; 5' would NOT produce a LOGICAL TRUE

Requires a simple first in, first out buffer like a keyboard buffer

[bobcat4]

wiggy:

but wasn't a failure to retard possibly the prime reason behind the Airbus going off the end at Congonas last year?

Yes, in a way it was. But it was a very strange accident. They closed (and reversed) the left engine, but left the other one with climb power.

It wasn't a A/T auto-retard failure as far as I know. It was pilot error when they failed to close power on one engine. Contributing factors: Very short runway which was wet. No, wet is not the correct word, more like flooded.

-Bob-

[Teddy Robinson]

The real danger about automation is that it is too damn perfect. If you fly 1000 single channel approaches and everything is normal, speed, attitude, altitude etc... Would you really be that careful the 1001st time scanning your instruments?

The answer is yes because it should be your trained response having had 1000's of hours in far less capable aircraft where you have to monitor and FLY THE AIRCRAFT !

Once the scan becomes an inbuilt and instinctive part of one's flying technique it should be there for good.

An individuals handwriting develops with time but rarely does it undergo radical changes

TR

[grebllaw123d]

bobcat4,,

For info, details regarding the TAM A320 accident may be found in the following link:

TAM Airlines Flight 3054 - Wikipedia, the free encyclopedia

brgds

[Desert Dingo]

How about this for a novel solution?

Require one of the pilots to have his hands on the controls during the approach, monitor the flight path / flight instruments and override / disconnect the automatic stuff if it does not perform as expected.

This just might work, and then we would not need to help Mr Boeing re-design all the systems.

Oops. Sorry. I see that it is already written in the operating manual.

[Maximum]

erm, to those wishing to re-design everything.

Remember there are myriad items which can cause disaster. Take the altimeter pressure setting as an example. Get this wrong in IMC and the rest might be history........

The basic premise of a certain company, as I posted a while back is to assume a certain level of pilot competency, and generally this is proved to be valid when we consider the number of flights that go without a hitch every hour of every day.

This is not to pre-judge the findings in any way, but rather to suggest that you stop assuming that there is some magical way that every system that can cause an accident can simply be fitted with a warning. You'll need warnings on your warnings if you don't set some kind of baseline competency level in the operator.

And again I say this is not a comment on this accident, but simply a generalised observation on machine/human interface.

Wait for the report.

[ALOOGOBI]

You can have all the warning systems the design engineer/pilot wants. Eventually you'll have warnings to tell you that the warning is not working.

Bottom line is that you have to AVIATE. Sommebody has to mind the shop. Every manufacturer's manual I've read has stressed that at all times one pilot is responsible for Flight Path Control. It is clear that this didn't happen in this accident. That is the responsibility of the pilot-in-command - to ensure that one pilot is looking after flying the aircraft while the other one deals with the peripherals whatever they may be - radio, QRH, checklists etc.

In this case it is clear that none of the three pilots did that with disastrous results. The only question now is WHY.

[A37575]

Require one of the pilots to have his hands on the controls during the approach, monitor the flight path / flight instruments and override / disconnect the automatic stuff if it does not perform as expected

Where does all this end? Why not have both pilots with hands and feet on the controls in case one suffers a subtle incapacitation. And if there is a spare pilot in the jump seat he could be given the task of monitoring both pilots in order to be the first to detect the first signs of a heart attack, or epileptic fit.

[Finn47]

In order to understand what in fact happened inside the cockpit, a word-by-word voice recording transcript preferably covering the entire approach and not only the last 2000 ft would be necessary. Any idea when the Dutch board might publish one? I found one report where the board have included a transcript, but it took the board almost three years to publish the final report... see this Onur Air incident, pdf page 75 for the transcript:

Runway overrun after rejected take-off, MD-88, Groningen Airport Eelde - De Onderzoeksraad voor veiligheid

[petermcleland]

I rather liked the Trident "Triplex" system where there were three of everything...Each radalt or AP monitored the other two...If it saw that it was significantly different from the other two then it dumped itself and a Red Flag would come up on the glare shield saying "MAN LND"...Autoland was not permitted with duplex but an Autoapproach was allowed but with a higher "Decision Height".

Seems to me that Duplex does not have the safety of Triplex...One of only Two is different, but which one is wrong? On a Duplex system with an error in any one the whole system should be dumped in favour of manually flying

[protectthehornet]

what pilots really want.

I read a post about what pilots want...something about speed protection.

What pilots want is to be well paid, lots of time off, and pretty flight attendants. We should fly enough to be very proficient in all aspects of non combat flight. We should have enough time off that we look forward to going flying again.

We also want fellow pilots who ''play for keeps''. Perhaps best explained by the "match" incident in "Fate is the Hunter".

We also want honest planes that are reliable and understandable.

We don't want to have to worry about any other aspects of our life when we come to work, whether it is paying the mortgage, family well being and health, or our pensions.

All the gadgets in the world developed since 1992 could be thrown out of a plane and we can still get the job done.


anyone who hasn't read "fate is the hunter'' and doesn't know the ''match'' incident ....while in a terrible storm, making a range approach, with the attitude gyro out of service, having tumbled in terrible turbulence, the captain started lighting matches in front of E.K.Gann, the copilot...he did a fine approach...just as the copilot was going to beat the crap out of the captain, while safely on the ground, the captain said something like: we play for keeps!!!!!!!!!!!

Fly the plane, play for keeps, and yell when the other guy is up....am I allowed to say up on this website?