So what did happen to the Emirates A340-500 at Melbourne

Apologies for the lack of posts – I’m on holiday, However, I’ve been given what seems to be a plausible version of events in the Emirates A340-500 tailscrape at Melbourne, which tallies with earlier rumours. To the best of my knowledge there’s still no official statement on all this so I’ll caution that this below is strictly unconfirmed.What I’m told is that the first officer entered a digit 2 instead of a3 when entering the take-off weight in the laptop that the crew uses -resulting in a selection of a weight 100t less than the actual.



The FO was flying and when the aircraft failed to lift-offfollowing rotation the captain took over, selected TOGA with nosuccess, and finally lifted off on a third rotation. The aircraft thenhit an obstacle and actually began descending as a result, but finallyclimbed away.

Following a 14 hour deadhead flight to Dubai some time later, the captain was taken to his office and soon resigned.



Thedevil’s in the detail of course, but the fact is that there have nowbeen numerous examples of data misentry – some resulting innear-disaster, many going unreported – particularly on less-criticalnarrowbody operations.

Here’s an early one that I happen to be particularly familiar with:

SAS probes procedures after close call on take-off

Kieran Daly, London (03Sep99, 12:16 GMT, 759 words)

SASis reviewing its cockpit procedures after a Boeing 767 came close tocatastrophe on take-off when the crew used the wrong aircraft weightfor its performance calculations.

The captain of the Tokyo-bound 767-300ER aborted take-off at Copenhagen after rotation when he realised something was wrong and managed to stop inside the length of the airport’s 3,570m (11,713ft) runway 22R from a speed of around 140kt (260km/hr).

The aircraftsuffered a minor tailstrike and burst tyres and it has since beenestablished that the crew had entered the aircraft’s zero fuel weight(ZFW) instead of its gross weight – about a 65t difference.

SAS, whichrecently changed its procedure for calculating take-off speeds -switching from using a hand-held computer in the cockpit to the use ofthe ACARS (aircraft communications addressing and reporting system)datalink to have the final calculation performed elsewhere – is nowtrying to see if there is a way to reduce the chance of a repetition.

A senior Captain involved in the review tells ATI:”This happened to a very experienced professional colleague of mine. Myfirst thought was that if this can happen to a solid fellow like thisthen it can happen to anyone. So we have to look into it and see whatwe can do.”

Another SASofficial – director of flight operations in Denmark, Fleming Jeppsson -relates how in the 24 August incident the co-pilot was conducting thetake-off and rotated the aircraft at the calculated speed (VR).

Jeppsson says: “The take-off data computation was based on far too low a take-off weight. So that gave a very, very low V1, V2, and VRand when the rotation was performed it did not give the desiredresults. The aircraft over-rotated and there was a tailscrape althoughit turned out to be not bad enough to warrant changing the skid.

“The captainrealised that something was wrong and told the co-pilot to lower thenose. All the indications told him to carry on, which is what they aretold to do, but he realised something was wrong and he aborted thetake-off.”

Remarkably theaircraft suffered only a scraped tailskid and three of four tyres burston the left main landing gear, requiring the tyres and brakes to bereplaced. Jeppsson says some passengers did not immediately evenrealise anything was amiss.

The SAS captain explains that since implementing ACARS some six months ago, SAS‘procedure on the 767 fleet is for one pilot to enter the data for thecalculations into the flight management system datapage and for bothpilots to verify the inputs and the results.

The data enteredcomprises the aircraft’s actual gross weight as passed to the crew, thewind, temperature, altimeter setting and runway condition. That is transmitted via ACARS to SASoperations’ department and, within about 20s, the calculated flapsetting, full thrust, derated thrust if possible, and speeds aretransmitted back and printed out in the cockpit.

Before the introduction of ACARS, the SAS767 fleet was using hand-held “take-off calculators” in the cockpit tocalculate the same data – a major advance on the paper charts used byairlines for decades.

The SAScaptain says: “The charts gave us very exact but very conservativefigures so the calculator was a great step forward and ACARS is evenbetter. I don’t think I would want to revert to the old system.”

Because the oldchart system required the use of very conservative assumptions itactually constrained the loads that aircraft could carry at marginalairports, meaning the switch to computed solutions had a direct effecton operating efficiency.

Both SASofficials confirm that, although the Swedish investigation authoritiesare examining what happened, there is no question that it was the crewthat made the error and not the operations staff.

Jeppsson says:”As soon as we identify the weak area then my idea would be toimmediately correct it. But we don’t want to change a procedure oranything like that until we know exactly what we want to do.

“We have sent amessage to pilots to say that obviously this is a grey area to put itmildly. It seems like something very basic but clearly it can happen.”

What is certain is that SASwould be extremely reluctant to reduce the use of ACARS itself – it hasbeen a hugely enthusiastic user of the system and datalink programmemanager, Bjorn Syren, publicly identified its role in take-offcalculations as “a big success” at an ARINC symposium in May.

Source: Air Transport Intelligence news

, , ,

12 Responses to So what did happen to the Emirates A340-500 at Melbourne

  1. Jeffrey Sooter April 8, 2009 at 3:43 pm #

    A similiar accident happened to a Pan Am 747 taking off from San Francisco on July 30th 1971. The plane struck the pier at the end of the runway supporting the approach lights. What happened here was the V1 and V2 were calculated for a runway length of 9500 feet vice 8500 feet. Unknown to the crew, was the starting line for 01R had been moved to keep jet blast off a nearby freeway/highway. The plane did return back to San Francisco making a belly landing with 210 lives being saved.

  2. Rob McConachie April 9, 2009 at 12:08 am #

    Increasing automation in the cockpit does seem to make it easy for finger trouble at the FMC to become a serious safety issue, if unchecked.

    Shouldn’t we be reviewing the wisdom of derated take-offs from the point-of-view that a valuable safety margin is being willfully eroded?

  3. Paul April 10, 2009 at 10:39 am #

    Another notable case was MK airlines at Halifax: http://aviation-safety.net/database/record.php?id=20041014-0

    It seems to me that the numbers are too often not checked (by the other pilot) and no logic check is performed on the resulting speeds. Computers are a great tool, but garbage in is still garbage out.

  4. john Newton April 11, 2009 at 9:03 am #

    According to Wikipedia the TOGA switch on take off only selects the power selected on the computer-not full power.
    The captain selecting TOGA would have only given him the power that his lower all up weight selected.
    Wikipedia could be wrong

  5. Kieran Daly April 11, 2009 at 10:20 am #

    The issue of how reasonable it is to expect pilots to intuitively pick up on incorrect weights and speeds is very interesting. I’m not an air transport pilot but like the commenters above, I’ve always found it surprising that these errors go through. Pilots that I have discussed this with have expressed similar views.

    However, the fact is that it keeps happening and it’s a fundamental feature of safety programmes that there is no future in simply saying that a phenomenon should not happen. If it does, then it does, and we need to work on a solution other than getting cross with those who make the error.

  6. blakkekatte April 12, 2009 at 6:33 am #

    Quote “the crew had entered the aircraft’s zero fuel weight (ZFW) instead of its gross weight – about a 65t difference”.

    Quote “Both SAS officials confirm that, although the Swedish investigation authorities are examining what happened, there is no question that it was the crew that made the error and not the operations staff”.

    How could the operations staff NOT realise something was seriously wrong when asked to base calculations on an empty aircraft. One of the most basic checks in any system is a reasonableness check to see if the outputs make look sensible. The system clearly allowed the entry of poor information and there was no basic checks on how sensible the inputs were.

    The system should be anticipate that pilots will sometimes make errors. The system and the operators should have processes in place to reduce the likelihood that those errors will produce catastrophic results.

  7. Numbnuts April 12, 2009 at 7:24 am #

    I never worry about entering a code. I just git in`er an go. Foot flat to the boards, me head out the window to hear the sweet sound of those big engines on “full noise”. Awesome! If in doubt, give `er plenty of Juice and hang on! Best of luck. Numbnuts

  8. John Charlton April 12, 2009 at 9:09 am #

    This has happened before – e.g Singapore Airlines B747 departing Auckland International March 2003. Could the satic compression of the main undercarriage shock absorbers be used to estimate the load as a reality check for the entered take-off weight?

  9. WiseWords April 12, 2009 at 7:50 pm #

    Just remember : To err is human but to really screw things up, you need a computer.

  10. Old - not Bold April 13, 2009 at 12:43 am #

    Interestingly, my airline has been using ACARS RTOW calculations for several years. We have also suffered instances of ZFW being entered iso the ATOW. This lead to a change in the display and procedures for the ACARS RTOW entry page.
    We now have to enter BOTH ZFW and ATOW and the system comes up with a caution message if there is a significant difference between the ACARS ZFW and the FMS Init B page ZFW to make you check again to see that there isn’t an error.
    We are also required for one pilot (PF) to enter the weights and the other pilot (PM) to check the inputs and only the latter pilot can push the “send” button. Personally, I always wait for the Loadsheet to come through to enter the weights from that reference rather than use the “Final ZFW notice” that we use for our fuel adjustments since it is not unusual for the Loadsheet ZFW to be different to the Final ZFW notice. This prevents having several ACARS RTOW calculations on the centre pedestal and picking up the wrong one.

    On the matter of the intuitive/ Rule of Thumb cross check for the V speeds, it should be noted that there are a wide range of values dependent upon the flap configuration chosen. Normally, we allow the ACARS RTOW system to default to the Optimum setting. Only in exceptional cases do we have to force the system to use a particular flap setting. This can lead to some significant differences when different flap settings are generated. I have yet to be able to generate “rule of thumb” figures to check against the V speeds generated for a particular runway and weight.
    Interestingly,when I select a zero wind component and look at the reciprocal, identical length runways for the same weight and climate conditions, the V2 speeds differ by a few knots. In Perf A, I was told that the V2 speed is only dependent on the WAT limits and thus independent of the runway UNLESS the increased V2 speed technique for a second segment obstacle is used.

    Hope this helps –
    Old – not Bold

  11. X AC April 14, 2009 at 6:46 pm #

    I remember we had a couple of 345 s at Air Canada and they operated on YYZ HKG. This necessitated a MTOW used and even in winter the pilots would use the longest runway available and even then the climb was no screaming hell. A 340 s as a general rule of thumb climb like the proverbial brick outhouses and use an awful lot of runway to do this.

  12. Peter Bore April 18, 2009 at 2:09 am #

    The problem is well described by Bayes’ Theorem which, in these circumstances, could be characterised as follows.

    Assume that pilots are 99.9% accurate in entering take-off data and assume that they always check the data and that their checking is also 99.9% accurate. (That second figure may be optimistic since humans are good at making the same error twice). In one million flights, incorrect data would be entered 1000 times. 999 of these errors would be discovered during the checking process but one aircraft in a million would still be at risk from incorrect take-off data. (There are about 20 million departures per year). Some of these errors would be detected and managed during the take-off run particularly if runway length was not a limiting factor.

    Given that humans (and computers) will always make errors the best that can be done is multiple checks preferably using data from different sources,

    In this case that could have been very easily achieved. All that the aircraft’s computer needed know was some very basic information such as the flight time (say16 hours with reserves) the hourly fuel consumption (8 – 9 tones per hour as far as I can determine from the data I can find) and the empty operating weight (170,000 kg). Even if the aircraft had zero payload, with an entered take-off weight of 280,000 kg (ie 100 tonnes less than MTOW of 380,000 kg) it could not have been carrying more than 110,000kg of fuel. This would have given it an endurance of 12 – 14 hours (ignoring take off and climb consumption).

    The computer might reasonably have asked, “Are you sure?”

Leave a Reply