Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

Turkish airliner crashes at Schiphol

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

Turkish airliner crashes at Schiphol

Old 6th Mar 2009, 23:46
  #1681 (permalink)  
 
Join Date: Jul 2004
Location: Europe
Posts: 246
Received 2 Likes on 1 Post
GXPER:

Is it not possible to contemplate that a single accident (possibly this one) may include components that really are, in reasonably foreseeable circumstances, massively unlikely to be repeated? Put more succinctly - "hard cases make bad law".
Maybe so. I'll leave that to the board's conclusions.


BOAC:

It took me some time to reproduce what my book says about Min Speed Reversion but it seems this must have been against prunes's fine print and must have been sent to the twilight zone by one of the allmighty moderators.
ant1 is offline  
Old 6th Mar 2009, 23:53
  #1682 (permalink)  
 
Join Date: Mar 2009
Location: Istanbul
Posts: 9
Likes: 0
Received 0 Likes on 0 Posts
@ flyinheavy

I've read in a Turkish translation of Boeing 737 RA / FCC maintenance manual that RA data is used to calculate autothrust flare & TO/GA (yet I do not have the original english text page but just the related diagrams).

So I didn't say you can not activate TO/GA. But as TO/GA would have been based on faulty RA reading I thought maybe it wouldn't work properly or even make things worse in terms of fatalities.
cargun is offline  
Old 7th Mar 2009, 00:12
  #1683 (permalink)  
 
Join Date: Mar 2009
Location: USA
Posts: 18
Likes: 0
Received 0 Likes on 0 Posts
BOAC, I'm still digging into autothrottle operation with the right rad alt. The right rad alt output bus IS wired to the autothrottle (same bus wires feel FCC B).

In regards to the MEL you posted, that looks more like a classic MEL for Rad Alt as the NG EGPWS should not be affected by the failure of 1 rad alt (once again, standard is to look at left until it fails, then switch to right).

The MMEL for the -600/-700/-800/-900 states:

34-20 Radio Altimeter Systems (Receiver/Transmitter)
c) (-600/-700/-800/-900)
CAT C (10 days)
2 installed, 1 required
(M)(O) May be inoperative deactivated provided approach minimums or operating procedures do not require its use.

The maintenance note is to pull and collar the breaker for the faulty rad alt.

The non-customized Boeing DDG states for the O note:

OPERATIONS (O)
NOTE: For airplanes with -1, -2, or -3 SMYD, an invalid signal from radio altimeter number 1 will result in failure of both stick shakers to self test.
1. Ensure that weather minimums or operating procedures are not dependent upon its use.

2. With radio altimeter(s) inoperative, do not use the associated autopilot or autothrottle for approach and landing.

3. For airplanes with FCC Operational Program Software (OPS) 2212-HNP-03B-05 or later installed, if the remaining radio altimeter fails:
NOTE: Rockwell Collins FCC Operational Program Software (OPS) part numbers are considered to be equivalent to Honeywell FCC OPS part number 2212-HNP-03B-05 and later.
A. AFDS (both sides) will limit the bank angle to a maximum of 8 degrees in all roll modes.
B. Use of the Autopilot/Flight Director System (AFDS) is at the discretion of the flight crew. AFDS may not:
1) Command sufficient bank angle to execute proper departure and/or approach maneuvers.
2) Make enroute course changes within airspace limitations.

4. For airplanes without FCC Operational Program Software (OPS) 2212-HNP-03B-05 or later installed, dispatch with an inoperative radio altimeter:
NOTE: Rockwell Collins FCC Operational Program Software (OPS) part
numbers are considered to be equivalent to Honeywell FCC OPS part number 2212-HNP-03B-05 and later.
A. Results in the same side Autopilot/Flight Director System (AFDS) limiting the bank angle to 8 degrees in LNAV mode.
B. The opposite side AFDS (operative radio altimeter) is not affected.
C. Failure of the remaining radio altimeter can result in:
1) AFDS (both sides) limiting the bank angle to a maximum of 8 degrees (all roll modes) when flaps are extended, 8 degrees in LNAV with flaps retracted.
2) Use of the Autopilot/Flight Director System (AFDS) is at the discretion of the flight crew. AFDS may not:
a. Command sufficient bank angle to execute proper departure and/or approach maneuvers.
b. Make enroute course changes within airspace limitations.
737AvEng is offline  
Old 7th Mar 2009, 00:37
  #1684 (permalink)  
 
Join Date: Jan 2008
Location: usa
Age: 66
Posts: 2
Likes: 0
Received 0 Likes on 0 Posts
power was idle 6 seconds

After 100 seconds idle power they got stick shaker then copilot firewall the engines,after that captain said i got it ,copilot let it go all controls included throttles i guess it was to much trim captain needed both hands on the yoke then throttes came back to idle ,it passed another 6 seconds they realized power was idle..they firewall again but this was too late ....did anybody mention about this 6 seconds idle before.... i read it from turkish newspaper.....
HUN DRIVER is offline  
Old 7th Mar 2009, 00:46
  #1685 (permalink)  
 
Join Date: Mar 2009
Location: Istanbul
Posts: 9
Likes: 0
Received 0 Likes on 0 Posts
737 NG Synoptics Maintenance Manual
Synoptic Training Manual
For those of you who are also interested in how things work.
cargun is offline  
Old 7th Mar 2009, 01:13
  #1686 (permalink)  
 
Join Date: Aug 2005
Location: fl
Posts: 2,525
Likes: 0
Received 0 Likes on 0 Posts
If #1 RA sensed -8 ft for a while before glide slope intercept is it possible the retard and flair would not have happened until coupled on GS? That would explain the overshoot. It wouldn't explain why they crashed with an attentive crew.
bubbers44 is offline  
Old 7th Mar 2009, 01:14
  #1687 (permalink)  

Mach 3
 
Join Date: Aug 1998
Location: Stratosphere
Posts: 622
Likes: 0
Received 0 Likes on 0 Posts
I find it a contradictory document, but maybe the CAA will pay a little more attention to enforcing the conclusions of their own paper on the matter:

CAA Paper 2004/10: Flight Crew Reliance on Automation | Publications | CAA

My license was renewed recently in a single 4hr check.

It was merely a box-ticking exercise, the derived training value to me somewhat akin to our budget deficit.

Echoing the familiar sentiment these days, albeit with reference to another industry, this accident is also the product of regulatory failure.

I'll say it again,

"More training please."
SR71 is offline  
Old 7th Mar 2009, 01:21
  #1688 (permalink)  
BarbiesBoyfriend
Guest
 
Posts: n/a
Re the Dutch report.

Wrong!
No single RADALT failure could have the effect that the prelim report stated.

RADALTs always have comparators.

In the a/c that I fly you can even continue an autoand after a RADALT fail.

RADALTS are known to be unrelaible, are they not?

I disbelieve this notion about the TLs going to FI due to a single RADALT failure.
 
Old 7th Mar 2009, 01:25
  #1689 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,257
Likes: 0
Received 1 Like on 1 Post
Much discussion and speculation on ‘what’ happened or ‘what’ the crew did not do, but to learn from this accident we should consider – speculatively if necessary – the many aspects of ‘why’ things did or did not happen.
The technical aspects should evolve as the investigation progresses and they should be fairly simple, but the crew’s activities and thoughts might only be assumptions based on FDR and CVR data.

The initial approach appears to have been ‘crisp’, perhaps hot and high, but something which we all might encounter in normal operations; but for a training flight, the higher workload and need for good situation awareness – thinking ahead – could stretch the Captains mental capacity reducing attention resources to spot malfunctions or mistakes.
The erroneous RA triggered a ‘gear-not-down’ warning (there is no evidence that the crew or maintenance knew of previous problems, nor that they should have done).
Was the FO (PF) distracted by the gear warning, believing that he might have missed a call, a point of procedure, or misjudged the situation; i.e. did he think that he was at ‘fault’ for not lowering the gear. The Capt (PNF/PM), also surprised by the gear alert, commences the landing checklist or calls for a gear selection earlier than normal. Thus some of the crew’s attention is ‘elsewhere’ (all 3 pilots).
These activities and subsequent checklist action mask the RA fault. Who actually pattern-scans the RA, isn’t it more usual to make a spot check (RA live 2500', <1000’ ~ 3nm, 100 above, etc). Similarly who scans the FMA; do we only occasionally check for ‘expected’ changes or rely on flashing alerts to identify the unusual.

Thus the retard annunciation was probably not seen and the thrust lever movement could have been what was required in the situation – it was the expectation that the AT would continue to control speed. The FO may have reduced the airspeed demand as required by flap selection – most likely, thus the AT would move in the retard direction … everything, or at least most of the situation appeared normal.
The landing checklist was progressed by the Capt – a period where his capacity to monitor both the aircraft and the ‘under training’ FO is reduced, perhaps more than normal by the distracting gear alert, a the tight approach, late GS capture, and perhaps expecting but not seeing a dual AP FMA (trng purposes).
Hands on thrust levers? Not always possible when selecting flaps / gear or AP mode change, setting DH, pointing to checked items, etc.
The time line has moved well into the ‘100 sec’ period; flaps are selected and the aircraft is decelerating as expected, AP engaged, possibly the FD still indicating GS/LOC on the FO PFD. No warning flags, RA 1 was still indicating valid, although not showing the correct value – do we always perceive these indications. We have yet to learn if the fault was intermittent or not.

The role of jump seat pilot is not yet clear. Was he another FO under training, possibly to fly the return leg? Did he have a specific checking role; if so what was it; probably to observe/monitor the crew. Thus during the landing checks his attention might have been on the check list actions, possible reading a duplicate QRH. Could this pilot see all of the instruments - possibly not RA1 display? Why should he specifically look at the FMA, was he also confused by the gear alert? Latterly he could have sensed and seen low airspeed, but what do you say and too whom ... cultural aspects cannot be overlooked, particularly in this ex-military situation.

By the time that the Captain (possible the pilot with most workload) had understood the rapidly changing situation (deceleration ~ 3 kts /sec), the situation and feel of aircraft were non standard requiring even more attention.
This wasn’t a sim training stall on the approach. The aircraft was mis trimmed nose up by the AP, thus the feel of the stall recovery would be alien, not expected, a surprise. How do you perceive and then fly a mis trimmed aircraft; compare this with Airbus test flight accident thread.
There could have been need to apply a push force in order to ‘respect’ the stall waning – if indeed the aircraft ever recovered from the stalled condition before it hit the ground. Try flying accurately, smoothly with 30kts+ of mis trim force.

It may not be possible to verify any of the above, but we might learn from the issues and perhaps improve safety by considering what changes could be made – turning hindsight into foresight.

Do we fly smart/tight arrivals too often and too close to a safety boundary, thus removing some of the spare capacity for dealing with the non normal occurrence or particularly for a training flight?

Are we really well trained – sufficiently experienced in dealing with surprise, even with small abnormities do we manage our attention appropriately – do we practice this.

We could consider the role of an additional pilot on training flights; is s/he there to observe/learn or oversee/monitor the operation. Differing roles require different qualification or experience. It might be better to off-load the checklist reading from the PNF (Trng Capt) to the observer enabling improved PNF monitoring and time to ‘train’ the PF to monitor the flight path / automatics – an objective of the flight.

Do we really respect the stabilised approach criteria? How often is the 1000ft IMC stretched to … say 700 ft because that’s the cloud base, or even the 500ft VMC check point because we ‘will’ be visual? And who, or how often would we go-around?

Most of these fixes are aspects of organisational or operational systems thus they could be addressed with safety audits / TEM. This requires people (everyone) to think about their operations, not necessarily specific what ifs, but what margin there would be for any minor abnormality in a range of situations. We should ask if we are operating too close to the boundary of safety, too much in a tactical - a reactive ‘they wouldn’t make that mistake' role, as opposed to a strategic, proactive role where aspects of operations are thought through considering the limitations of human performance.
alf5071h is offline  
Old 7th Mar 2009, 01:36
  #1690 (permalink)  
 
Join Date: Jan 2008
Location: UK-at times
Posts: 16
Likes: 0
Received 0 Likes on 0 Posts
Pretty good analysis Alf.
Tied in with the previous report/speculation that 2 hands required for mis-trim, then TL's return to Flt Idle-again- and it very quickly becomes un-recoverable (Safta..).
I'd like to think readers/posters are starting to realise that the much quoted '100secs' of no TL movement wasn't the cue many believe it should have been.
Good point on role/usefulness of SFO in this instance as well.
+1
vino is offline  
Old 7th Mar 2009, 01:50
  #1691 (permalink)  
 
Join Date: Mar 2009
Location: USA
Posts: 18
Likes: 0
Received 0 Likes on 0 Posts
bubbers44 asked:

If #1 RA sensed -8 ft for a while before glide slope intercept is it possible the retard and flair would not have happened until coupled on GS?


So far, there is no indication that flare mode was ever active. Since the right FCC was doing the flying, the right radio altimeter, which was correct, was being used by the right FCC.

From what we have gathered, the autothrottle computer will enter retard mode when the autopilot is in single channel under these conditions:

27' or lower radio altitude
On G/S
Flaps > 12.5
737AvEng is offline  
Old 7th Mar 2009, 01:54
  #1692 (permalink)  
 
Join Date: Mar 2009
Location: USA
Posts: 18
Likes: 0
Received 0 Likes on 0 Posts
BOAC, I created a large post earlier today about the MEL you posted. When I went to post, it said it needed to be reviewed by the moderators. Hopefully it will be posted.

I was posting the NG MEL for autothrottle and it didn't match up with what you posted. Was your posting for the NG from your company MEL?

Still digging into the right rad alt logic for the autothrottle computer; it's definitely wired up to it!
737AvEng is offline  
Old 7th Mar 2009, 02:18
  #1693 (permalink)  
 
Join Date: Aug 2005
Location: fl
Posts: 2,525
Likes: 0
Received 0 Likes on 0 Posts
Before all of our automation we flew airplanes instead of monitoring systems. I have gone both directions and always feel the need to hand fly when going backwords in automation before going to older technology. The hands on flying skills fade away if not used on a regular basis. I have a feeling this was a big part of this crash. Nobody was paying attention to the basic airmanship required that day. I hope I am wrong but the report will probably explain why it all went wrong. This was a new technology airplane but basic flying skills are still required when what buttons you push don't accomplish what you want so you have to make it into a B727 again.
bubbers44 is offline  
Old 7th Mar 2009, 02:41
  #1694 (permalink)  
 
Join Date: Jan 2008
Location: North Yorkshire, UK
Posts: 2
Likes: 0
Received 0 Likes on 0 Posts
Rainboe, if you look closely, I think it is not the software developers or system designers but those who think they could do it better ("how hard could it be") who are suggesting the system should be changed.

As you say, anyone who has done system or software design for a fault tolerant system knows just how hard it can be to diagnose faults reliably. It's easy enough to say that a couple lines of code would have fixed this specific situation. But it is much harder to spot all the situations that wouldn't be fixed and would be created by the change.
As a software engineer in telecoms, where I deal with all manner of fault situations (but never with people's lives directly on the line), I appreciate how much effort must go into both identifying and dealing with all manner of fault scenarios for the automation being built into airliners.

I also very much respect the feelings of the posters on here that believe the slice of cheese that should have prevented this accident came with the pilot's names on it.

However, as a professional engineer, I'm horrified that such a simple fault (that RA#1 provided invalid data without a failure flag) caused the automation (AP and AT in combination, but mainly AT) to actively fly the plane at the ground. Not once, but a second time too (by pulling the throttles back again after the first crew response to the stick-shaker). If I were an engineer responsible for this area at Boeing, I'm pretty sure I'd feel some level of responsibility - just like any of the 3 pilots would, had they survived.

I'm absolutely not qualified to come up with an engineering solution - but I suspect it would be more oriented toward identifying that there was a potential problem, and announcing that to the crew, rather than adding more hardware & software to try to cope.
WWWombat is offline  
Old 7th Mar 2009, 03:10
  #1695 (permalink)  
 
Join Date: Jan 2008
Location: North Yorkshire, UK
Posts: 2
Likes: 0
Received 0 Likes on 0 Posts
I'd like to think readers/posters are starting to realise that the much quoted '100secs' of no TL movement wasn't the cue many believe it should have been.
I liked alf's post too.

I saw the graph that showed speed & position compared to the glideslope (post 1643 maybe 4 pages back), with data from OpenATC, but there hasn't been much talk about that.

If the data is to be believed, it shows the plane following the glideslope from 1000ft down to 600ft, with the speed only dropping below Vref around the same time that the plane drops through the cloudbase (700ft).

With the datapoint spacing said to be 15s, would that suggest the 15-20 seconds after coming out of the cloud would be where thrust ought to have kicked in - and where the pilots could have started to perceive the problem? (Either by the instrument scan, or the sensory perception of the noise/attitude)

Or would the AP have been dialling in more trim before this point, and *that* ought to have been the clue?
WWWombat is offline  
Old 7th Mar 2009, 03:16
  #1696 (permalink)  
 
Join Date: Jun 2003
Location: EuroGA.org
Posts: 13,787
Likes: 0
Received 0 Likes on 0 Posts
Apologies if this has been answered already but does this aircraft have the "trim in motion" annunciation after the trim has been running continuously for say 9 seconds?
IO540 is offline  
Old 7th Mar 2009, 03:43
  #1697 (permalink)  
 
Join Date: Mar 2009
Location: Istanbul
Posts: 9
Likes: 0
Received 0 Likes on 0 Posts
OpenATC

Would anyone like to comment on & analyze the OpenATC ADS-B track of TK 1951?

Could & should we assume this data as accurate & reliable?

If I read the data properly:
From 1925 feet (RA fail at 1950) to the ground 4 minutes.
From 800 feet (cloud base) to the ground 1 minute.

According to this data what do you think would be the critical minimum altitude for pilots to react & save the aircraft.

NOTE: I think those are barometric altitudes, so they must be converted. In another forum they calculated 1.625 feet as 2.025 feet, at 1.013.2 mb.
So the RA failure starts at 1625 feet (10.27.23) 3,5 minutes to crash.
METAR EHAM 251025Z 22011KT 3500 -DZ BR OVC007 05/04 Q1027 TEMPO 2500=

(1027-1013) x 30 = 420. 1625 plus 400? 2025ft close enough to 2000ft

Last edited by cargun; 7th Mar 2009 at 03:59.
cargun is offline  
Old 7th Mar 2009, 03:58
  #1698 (permalink)  
 
Join Date: Jan 2008
Location: US
Posts: 251
Likes: 0
Received 0 Likes on 0 Posts
Stall recoveries

Every six months for me (US Part 135 ops.) last time was in the aircraft next time will be in the sim. We don't practice stall recoveries from the scenario experienced by this crew though, perhaps we should.
MU3001A is offline  
Old 7th Mar 2009, 04:02
  #1699 (permalink)  
 
Join Date: Jan 2008
Location: UK-at times
Posts: 16
Likes: 0
Received 0 Likes on 0 Posts
Or would the AP have been dialling in more trim before this point, and *that* ought to have been the clue?
Yes-it would have to trim almost continuously once the speed decayed below Vref-but there were probably a lot of other distractions starting to creep in by then.
Cargun- according to Safta's experience in the -300 Sim, it isn't altitude related, but trim ie there will be a critical combination of NU trim and low airspeed from which a successful recovery is unlikely, if not impossible-particularly if the TL's close again and the recovery isn't 'by the book'
I imagine that with a well co-ordinated, pre-warned crew, both assisting on Flt Controls/TL's, and continuously trimming, there will be a recoverable IAS/Trim/Altitude-but impossible to predict without running in the Sim, and even that model may be inaccurate as you are well outside the design parameters (as per the jet upset model which is marginal at best)
vino is offline  
Old 7th Mar 2009, 04:23
  #1700 (permalink)  
 
Join Date: Jul 2000
Location: Thailand
Posts: 942
Likes: 0
Received 0 Likes on 0 Posts
Cargun, you mustn't let certain posters on here upset you. Answering in red will only rouse them further, so just ignore them/him, as most of us do.
Mods allow such angry and downright arrogant drivel from certain posters because it keeps up the interest level and provokes further postings.
You stick to your questions and read carefully the answers, but learn to filter out the dross from the sensible.
Just because one has 9000+ posts and twice as many hours doesn't make you infallible or even right.
I give this post about 45 minutes before it's deleted.
rubik101 is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.