Incorrect weight and speed data can be potentially deadly, and multiple defenses against such human error can be breached, especially when aircrews are hurried or distracted, and when the computer accepts erroneous data without an error check, rather like a word processor without a spell checker.
What a difference a digit makes in this case of a March 12, 2003, tailstrike on takeoff at Auckland, New Zealand. By entering a “2” instead of a “3” in the bug card, the takeoff weight (TOW) was too low by 100 metric tons. On the basis of this transcription error, 247 tons instead of 347 tons, the first officer manually calculated takeoff V-speeds and thrust setting for takeoff. These values were excessively low for the airplane’s actual weight.
The captain then entered the incorrect manually calculated V-speeds into the flight management computer (FMC), ignoring the substantially higher V-speeds and the higher thrust setting it had computed and was displaying. These higher speeds were based on the correct TOW the captain had entered into the FMC from the load sheet. Rather than reconciling why the V-speeds on the bug card and on the FMC display were so different, the bug card speeds were inserted into the FMC, which accepted them.
The multiplied errors were never caught before takeoff, and the crew found itself trying to get airborne below stall speed.
Result: a tail that dragged spectacularly in a cloud of smoke as the airplane struggled to break contact with the ground and climb into the sky. The crew of Singapore Airlines (SIA) Flight SQ286 was able to get airborne and, fearing a fire in the tailcone, complete an emergency return-to-field greatly overweight landing, the nine-hour planned flight from Auckland, New Zealand, to Singapore by this time all but forgotten.
The airplane was out of service, under repair, for weeks. The transposed digit led to an unsafe takeoff that could have ended with an airplane careening off the runway, greatly endangering the 369 passengers aboard and, in this case, millions of dollars in repair costs.
The cockpit crew was faulted mightily in the post-event investigation for not catching the weight error. There is a larger issue: whether FMC designs have kept pace with the demands placed on them and, more specifically, whether their built-in defenses are adequate to catch erroneous data inputs, warning unsuspecting aircrews that their pre-takeoff calculations may be seriously in error. The tailstrike at Auckland was not the only one in recent years to have resulted from incorrect data entry.
Details of events leading up to the tailstrike at Auckland were revealed in the recently released report of New Zealand’s Transport Accident Investigation Commission (TAIC). The TAIC inquiry shows how crews under time-pressure may be prone to distraction and mistakes, and how even multiple lines of defense can be breached.
The crew consisted of the captain and two first officers – the second of whom will be referred to as the relief pilot. As an example of how one safety problem can affect another, the captain noticed that 4.5 tons of fuel was loaded into the center wing tank, although a minimum of 7.7 tons was required to ensure that the pumps were covered in fuel (a minimum fuel quantity designed to prevent an explosion of flammable vapors).
Adding the fuel delayed departure. Fuel weights had to be adjusted and the load sheet modified. Upon receipt of the final load sheet, the captain called out to the first officer certain items, including the airplane’s zero fuel weight (total airplane weight without fuel) and the TOW (total weight with fuel and payload). The first officer duly entered these values on the bug card, calculating from it the necessary thrust and speed settings for takeoff.
In the process, though, the first officer did not catch that he’d marked down on the bug card a TOW that was 100 tons below that written on the load sheet.
Per procedures, the captain then entered the thrust and speed values calculated by the first officer into the FMC. The captain later told investigators that he checked the zero fuel weight (ZFW) and TOW displayed by the FMC and found them in agreement with the values on the load sheet, from which he’d entered them into the FMC. The FMC calculated its own takeoff speeds, and the captain did not notice that they were significantly higher than the ones provided by the first officer (which were based on a TOW 100 tons lower than it should have been). Rather, he entered the thrust setting and speeds provided by the first officer, basically over-writing the FMC. Despite the significant difference in speeds, the FMC accepted the lower values.
Enter related factors – the departure delay and the power of distraction. The relief pilot, who normally would cross check the bug card and computations, did not do so, being occupied at the time explaining the departure delay to Singapore Airlines’ station manager at Auckland.
With the captain as pilot flying (PF), the first officer called “rotate” as the airplane reached 130 knots on its takeoff run. With insufficient speed to generate lift, the airplane remained on the ground, dragging its tail on the tarmac for a good 1,500 feet and veering to the right before finally becoming airborne in ground effect.
The stick shaker activated, warning of imminent stall as the airplane began its struggle into the sky. The captain ignored it, regarding it as a spurious activation. Three seconds after stick shaker activation, the pilots received an auxiliary power unit (APU) fire warning. The APU is located in the tailcone, and when the tailcone was dragging on the runway, the damage to the fire wire loop triggered the APU fire warning in the cockpit.
With an emergency declared, the airplane climbed slowly to about 1,000 feet. The correct V2 speed (172 knots) was not achieved until 64 seconds after lift off, when the aircraft reached this altitude. Had an engine failure occurred during the period – which is why V2 is calculated – the airplane probably would have been lost. Given the warning of a fire in the damaged tailcone, the crew prudently decided not to dump fuel and made an overweight landing.
The indelible impression left on the airplane and on the runway also left an indelible impression in the minds of witnesses. For example, the tower controller advised the crew of “a lot of smoke” when the airplane rotated.
After the damaged airplane landed, the cockpit voice recorder captured this telling exchange among the three pilots, dealing apparently with the TOW:
Captain: “Should be a three.”
First officer: “Take-off weight?”
Captain: “Yeah.”
Relief pilot: “Gosh – I should have checked it.”
The TAIC report addressed a number of salient issues:
The captain had recently transitioned from the Airbus A340, for which the typical rotate speed is around 138 knots. This value is pretty close to the incorrect rotate speed of 130 knots calculated by the first officer for the accident flight on the B747-400.
|
The Crew of SIA Flight SQ286
|
|||
|
Item
|
Captain
|
First Officer
|
First Officer (relief pilot)
|
| Age |
49
|
34
|
38
|
| Total flying hours |
12,475
|
1,309
|
6,302
|
| Hours in type (B747-400) |
54
|
223
|
3,386
|
| Comments: Captain and First Officer total time in B747-400: 54 + 223 = 387 hours First Officer held a commercial pilot license but had not attained hours for a transport pilot license, tests for which he had passed. He met SIA requirements to be “experienced” on type. Source: TAIC | |||
Both the captain and first officer were relatively inexperienced on the B747-400, with a total of less than 400 hours between them.
SIA procedures prohibited the pairing of two inexperienced pilots together. Among its criteria, experience in time was defined as 100 flying hours and ten sectors. The captain, with 54 hours, was making his eighth flight as B747-400 pilot in command. Since he was inexperienced on type, he was paired with a relatively junior first officer who had more experience on type. The two pilots were backed up by a very experienced relief pilot with more than 3,300 hours in the B747-400.
Some additional comments, not addressed in the TAIC report, are in order. The captain was relatively new to the B747-400 but had more than 5,600 hours in the A340, in which he would have seen take-off weight figures regularly that were closer to the erroneous figure transcribed by the first officer. It is well known that during times of stress (center fuel tank minimum quantity error, in this case) people revert to their original or predominant training, experience and understanding. It is also conceivable that having spotted one mistake, the crew became slightly oblivious to spotting the other.
For those flights where a relief pilot was necessary, SIA had “no specific assigned duties.” Tasks assigned were at captain’s discretion. This is the second time this situation has been remarked upon in an accident report. The Aviation Safety Council of Taiwan noted the absence of specific third pilot duties in its investigation report of the fatal Oct. 31, 2000, takeoff crash on a closed runway of SIA Flight SQ006 at Taipei (see ASW, May 6, 2002).
All three pilots had completed the airline’s crew resource management (CRM) training. Yet the TAIC found a want of good CRM: “Because the captain did not respond correctly to an impending stall condition as the airplane became airborne, and because the two first officers did not exercise good CRM, a loss of control could have occurred.”
At the time of the Flight 286 tailstrike accident, aircrews were not required to reconcile V-speeds on the bug card with those calculated by the FMC. After the accident, SIA changed its procedure, calling for an additional reconciliation and recalculation if bug card and FMC V-speeds differed by three knots or more.
In a test on another SIA B747-400, TAIC investigators found that the FMC would accept incorrect speeds without challenging them.
As a consequence, the simple transcription mistake meant the resulting TOW error breached six levels of defense:
First defense breached: the captain did not verify the TOW on the bug card.
Second defense breached: FMC computed V-speeds were discounted. As the TAIC report noted, “They knew they were on a direct flight to Singapore with a planned flight time in excess of nine hours with a planned fuel burn over 100 tons.”
Third defense breached: “From simple cognitive reasoning and subtracting 100 from 247, the result gave a landing weight at Singapore significantly less than the empty weight of the airplane itself,” the TAIC observed (emphasis added). “Even though the delay was only about 13 minutes, it could have been sufficient to pressure the pilots to unconsciously hurry through their procedures to minimize the time loss,” the TAIC report surmised regarding the absence of simple cognitive reasoning.
|
A Digit Discrepancy
How a transcription error led to incorrect thrust and speed data for takeoff |
||||||
|
Item
|
Load sheet data
|
Bug card data
|
What should have been3
|
FMC data displayed
|
Override data
|
Data used for takeoff
|
| Zero fuel weight (ZFW) |
231 tons
|
231 tons
|
—
|
231 tons4
|
—
|
—
|
| Fuel weight for the flight |
116 tons
|
116 tons
|
—
|
—
|
—
|
—
|
| Takeoff weight |
347 tons
|
247 tons1
|
347 tons
|
347 tons5
|
—
|
—
|
| Thrust setting (EPR) |
—
|
1.342
|
1.41
|
—
|
—
|
1.34 (-0.07, or 5%)
|
| V1 |
—
|
123 kts2
|
151 kts
|
145 kts6
|
123 kts
|
123 (-18 kts)
|
| VR |
—
|
130 kts2
|
163 kts
|
158 kts6
|
130 kts
|
130 (-33 kts)7
|
| V2 |
—
|
143 kts2
|
172 kts
|
174 kts6
|
143 kts
|
143 (-29 kts)
|
| Terms: ZFW: Zero fuel weight, i.e., total airplane laden weight w/o fuel. EPR: Engine pressure ratio, a measure of thrust V1: Take- off decision speed VR: Rotate speed V2: Initial climb out speed Footnotes: 1 First officer’s transcription error of 100 tons 2 Resulting engine power and speed thresholds 3 Values that should have resulted had correct weight been entered on the bug card 4 Captain entered ZFW from load sheet 5 FMS-produced TOW equaled TOW on the load sheet 6 Calculated by FMS on another aircraft using same weights and settings as on the accident flight Comments: Errors in bold. The incorrect V2 speed used for takeoff was 8 kts below stalling speed. The airplane did not achieve the correct V2 speed of 172 kts until it reached an altitude of 1,000 feet more than a minute after liftoff. Source: TAIC | ||||||
Fourth defense breached: the relief pilot did not verify the entries on the bug card. Recall that in the midst of the delayed departure, he was conversing with the station manager. As the TAIC report said, “Time pressure could have contributed to the pilots’ non-detection of errors.”
Fifth defense breach: the operator’s inadequate procedures, which did not require bug card data to be reconciled against FMC-generated V-speeds. In other words, a potential fifth line of defense did not exist.
Sixth defense breach: here, too, a potential line of defense in the FMS itself was missing. The system would accept mismatched V-speeds and some erroneous gross weight entries without challenging them. The TAIC report said, “Had the FMS been programmed to challenge, or in certain cases not accept, erroneous or mismatched entries, then a valuable final defense against incorrect entries would have existed.”
In light of these findings, the TAIC’s safety recommendations fell into two main areas of action:
To manufacturer Boeing [NYSE: BA]: Implement software changes to ensure that weight and V-speeds that are mismatched by a certain percentage are either challenged or prevented.
Boeing responded, telling the TAIC it is looking at whether “such new features should be included in new FMS installations.” In its response to the TAIC, Boeing cautioned about the potential for nuisance warnings. “We are, however, exploring the possibility of checking that the manually entered VR speed is not significantly lower than the FMC- calculated value,” Boeing added. “It appears that narrowing the check in this manner may produce the intended safety benefit.”
To Singapore Airlines: (1) Establish procedures to ensure independent verification of all essential take-off data, (2) reaffirm that safety should not be compromised in the face of delays, (3) introduce similar errors in recurrent training for pilots to discover, and (4) develop guidelines for use of the third pilot when one is aboard an aircraft designed for two-pilot operation.
The airline has advised the TAIC that items (1) through (3) have been accomplished, and item (4) is in development.
Another tailstrike incident involving an Air Canada A330 on takeoff at Frankfurt the year before is almost an identical predecessor to the 2003 tailscrape involving the Singapore Airlines event at Auckland. Together, the two cases suggest that automation without discrepancy checking can be an insidious hazard.
It is time for a larger and serious look at obsolescent FMS design, the use of bug cards and their potential to inject error, the lack of standardization for takeoff calculations and the barren fruit of CRM training, argues Captain Timothy Crowch, an experienced international airline pilot. He has commented trenchantly in this publication previously about the insidious nature of fatigue (see ASW, July 30, 2001).
Crowch concedes that he brings a flight crew member’s bias to the table, but he maintains that the critical pre-flight phase is precisely the point where latent conditions can be fed into the system, and to be lodged therein, unchallenged by the machine and unnoticed by a crew, diligent or distracted. Crowch believes that a “radical overhaul” of man- machine integration is in order.
(ASW note: the full TAIC report may be viewed at http://www.taic.org.nz/aviation/03-003.pdf)
Bug card
A specific reference card pilots use to list essential take-off and landing information. The “bug” refers to the small markers that appear on the cockpit airspeed readout.
A Predecessor Tailscrape on Takeoff
Air Canada A330 tailscrape on takeoff June 14, 2002, for a flight from Frankfurt to Montreal.
An almost identical accident to Singapore Airlines at Auckland, this one involving an A330 twinjet, in which automation without discrepancy checking also is revealed as an insidious latent hazard. From the Transportation Safety Board (TSB) of Canada accident report (extracts):
At 0752, the flight crew received the initial load figures from the aircraft communication addressing and reporting system (ACARS), indicating an estimated takeoff weight of 222.7 metric tons … A reduced take-off thrust setting … was planned.
The take-off speeds, provided to the crew by the ACARS, were inserted into the multipurpose control display unit (MCDU) by the pilot not flying (PNF), seated in the right seat. The following speeds were inserted: decision speed (V1) 156 knots, rotation speed (VR) 157 knots, and takeoff safety speed (V2) 162 knots.
Either during the push back from the gate or during taxiing, the PNF reinserted the final load figures and takeoff speeds into the MCDU. By mistake, the PNF typed a V1 speed of 126 knots instead of 156 knots. Just prior to taking off, the pilot flying (PF) read the speeds off the MCDU as 126, 157 and 162. Neither pilot noted the incorrect V1 speed.
The MCDU is designed to display an error message if the data are out of range or not formatted correctly. In the case of takeoff speeds insertion, the message will appear only if the speed inserted is below 100 knots.
In the majority of A330 takeoffs, the V1 and VR spread is in the range of one to two knots … In this occurrence, the PNF called “V1” as the speed reference index approached the “1” and called “rotate” almost immediately after … rotation was initiated 24 knots below the calculated VR of 157 knots.
The aircraft tail struck the runway surface at a pitch attitude of about 10.4 degrees nose up.
The early rotation was induced by the erroneous V1 speed. It could not be determined why neither the PF nor the PNF noticed the unusually large spread between V1 and VR … It is possible that the PNF did not notice the discrepancy at that time because, having entered the data himself, he heard what he expected to hear. (ASW comment: Pilots do not tend to analyze data that will later be presented for action, therefore this “review” of the takeoff data tends to be unproductive. What might be productive is an MCDU/FMS design programmed to reject/highlight or just “flash for a confirming second ENTER action” any data at or beyond a set boundary. It is ironic to reflect that if the numbers had been extracted from a graph and entered on a yoke-mounted TOLD card – take-off [and immediate] landing data – the error would have been more apparent on that two-dimensional graph.)
This class of error is known as a substitution error, where a character that was entered is substituted with erroneous information … It was not possible to determine the exact etiology of the sub-stitution error in this occurrence; however, it is possible that the number “2,” which is located directly above the number “5” on the keypad of the MCDU, was accidentally hit.
In this case, the take-off speeds were crosschecked prior to reaching the takeoff position on the runway, but the accuracy was not validated. (For the full TSB report, see http://www.tsb.gc.ca/en/reports/air/2002/A02F0069/A02F0069.asp)