It was a terrible wipe-out accident, in which the Boeing 747 freighter experienced a tail scrape on takeoff, ran off the end of the runway, collided with an earthen berm capped with concrete, and came to rest in pieces and in a fiery heap about 1,200 feet farther on. None of the seven persons aboard the MK Airlines plane survived the crash, which happened in October 2004 at Halifax International Airport in Canada.
The Transportation Safety Board (TSB) of Canada recently issued its report of the crash. It was a reduced power takeoff, and it was attempted by a crew that had been on duty for over 20 hours. Fatigue may well have played a role in the crew’s not catching a weight error in the takeoff calculation, and in not noticing that their speed was too slow at rotation to get airborne. If they had successfully completed their takeoff and flown to their final destination at Luxembourg, they would have been on duty for over 30 hours.
The flight was a "grand tour," as it were, from Luxembourg to Windsor Locks, Conn., to Halifax, then on to Zaragoza, Spain, and finally back to Luxembourg. To be sure, the crew could cat-nap en route, but as the report of investigation noted, "Crew fatigue, combined with the dark takeoff environment [at Halifax], likely contributed to a loss of situational awareness during the takeoff roll."
Consequently, the investigators said, "the crew did not recognize the inadequate takeoff performance until the aircraft was beyond the point where the takeoff could be safely conducted or safely abandoned."
The TSB report cites numerous instances where patently incorrect data had been entered into the flight management systems (FMS) of various aircraft, leading to some very close calls.
Wendy Tadros, the acting chair of the TSB, said inputting errors are a "pervasive problem" worldwide. "We believe we need an additional line of defense-a mechanism to catch the unexpected errors," she said.
Accordingly, the TSB recommended a takeoff performance monitoring system for all transport category aircraft to alert crews to a difference between expected and actual takeoff performance. The TSB did not indicate exactly how that monitor should be designed, as the job of a safety agency is not to outline the specifics but rather to indicate the need.
Avionics Magazine has, however, in this column, indicated what forms such a monitor might take. Recall the discussion of a nighttime runway overrun and damage to an Emirates A340-600 that necessitated a return to landing at Johannesburg, South Africa (see April 2006, page 51). The takeoff monitor could take the form of a single-digit display adjacent to the airspeed indicator. It would illuminate at a specified trigger distance, perhaps after, say, 3,000 feet of wheel spin. If the display shows the numeral zero, in white, the takeoff is nominal. If it indicates +1 in a green color, then the airplane is lighter than expected, the air is more humid, or the temperature has suddenly dropped. In any event, the crew can safely proceed with the takeoff.
If the light shows -1 in amber color, the airplane is heavier than expected. In fact, the light could progress, depending on the severity of the situation. For example, -2 in amber would indicate a situation that would warrant the crew’s immediate attention and, say, -5 flashing in red would warrant a decision to abort the takeoff while there is still time to do so.
This decision aid would add technological logic to what the pilot presently does instinctively: monitor the progress of the takeoff run and determine whether it "feels" right or not.
The display would be programmed to simply disappear once the nose-gear oleo extends upon rotation.
To be sure, it helps if the crew inputs the correct takeoff weight into the FMS. The MK Airlines accident reveals an insidious source of error: the Boeing Laptop Tool (BLT). The TSB report bluntly said the crew’s misunderstanding of the BLT for calculating takeoff performance led to the accident. Specifically, the crew unwittingly transferred and used weight data from the aircraft’s previous flight from Windsor Locks while calculating the performance criteria for the takeoff at Halifax. The obsolete data misled the crew to derive incorrect thrust settings and critical speeds for takeoff. As a result, the aircraft failed to lift off after rotation.
The BLT was passed to MK aircrews as just another tool, the use of which was to be learned at home via self-study. That course of instruction did not adequately caution aircrews that the BLT was capable, when the user switched between the weight and balance (W&B) and the performance modules, of carrying invalid or stale data from the W&B module into the performance module. It would do that unseen and without warning, i.e., quietly grab the last entered figure from the W&B module, when the performance module is opened. This is what happened. The dummy weight imported into the performance module corresponded to the previous flight, which was much lighter.
This meant that the takeoff performance calculations (reduced power engine pressure ratios, rotation speed, etc.) would be totally invalid, because they would be based on incorrect weight.
None of the MK crew performed a gross error output check, so they did not catch the mistake.
The solution would be to amend the software so that a mandatory or willful importation of a figure from the W&B module would be required. For example, a pop-up message instructing crew members to "Click box to import W&B module data," or "Leave box unchecked to enter your own verified all-up-weight figure and center-of-gravity."
With the BLT, it seems that a new "gotcha" was unwittingly introduced. An accident was bound to happen sooner or later. With the MK Airlines accident, it happened sooner.
It should be mandatory to subject laptop tools, and their software in particular, to the same robust validation required of flight control software. At the end of the day, both are equally capable of killing. And with incorrect weight used for the performance calculations, the takeoff performance monitor display suggested above would be rendered invalid, too.
The irony of this case is that if the airplane had been heavier on the way into Halifax, the crew would have gotten away with their subsequent takeoff. It took the crash to reveal the subtle interplay of software and human errors. To play on the garbage in/garbage out aphorism about calculators and computers, in this case it was garbage in, accident out. The complete TSB report of the MK Airlines accident may be viewed at www.tsb.gc.ca/en/reports/air/2004/A04H0004/a04H0004.pdf.