The Strengths And Weaknesses Of The Boeing Laptop Tool
BLT stands for a bacon, lettuce and tomato sandwich, but for the average airline crew it’s also a Boeing Laptop Tool. It was designed to make flight crews’ lives easier, by streamlining the procedure for calculating takeoff data.
We’re not sure whether any Failure Modes, Effects and Criticality Analysis (FMECA) was ever carried out on this new cockpit instrument when it entered service. However, it’s beginning to look as if there should have been.
That said, despite a few built-in software tricks and traps, the output errors are usually induced by humans, either through ignorance or inadvertence. Before casting any aspersions on the tool itself, let’s examine the historical context of the BLT.
On Oct. 14, 2004, MK Airlines Flight 1602, heading for Spain, careened off the end of Runway 24 in Halifax Nova Scotia and burst into flames at around 4:00 a.m., killing all seven aboard (tinyurl.com/2otppv and ASW July 10, 2006).
The Transportation Safety Board (TSB) of Canada determined that an inadvertent carry-over of 9G-MKJ’s lighter weight for takeoff from Bradley (on its prior leg into Halifax) had made its way into the BLT’s performance calculations.
This development occurred unnoticed, when the First Officer switched from the weight and balance program to the takeoff performance calculation. That duff figure was around 110t lighter than the 747’s actual weight of more than 350t for the Halifax departure.
When the freighter headed off down the darkened runway at an early hour and a much reduced thrust, neither the pilots nor the flight engineer picked up on their sub-standard acceleration.
As they ran out of runway lights, a very late application of maximum power, an excessive rotation and a dragged tail were insufficient to save the aircraft from overrunning and losing its tail upon striking an earthen berm in the overrun. The TSB after that accident made numerous recommendations on the uses of BLTs. They mostly revolved around the old maxim of “garbage in/garbage out” and the capacity for software to suck in irrelevant or aged data.
Nobody has yet come up with a means for stopping the input of patently incorrect data. If a figure is outrageously in error by some degrees of magnitude (say, too many zeros), then of course the computation will likely exceed the laptop tool’s software parameters and throw up an error message. But if the error is just large enough to make a significant difference in a takeoff calculation, well, that won’t necessarily be so.
On Dec. 10, 2006, a Boeing 747-400 registered F-HLOV and operated by Corsair, was being prepared for departure from Paris (Orly Airport) for a long-haul flight to the Antilles. A technical carry-forward due to a problem with the “Fuel Scavenge Pump” in the center tank required a quantity of 1,6 T fuel to be considered non-usable. At around 0930 local, the aircraft was ready to go with 563 passengers and 15 crew.
The crew, having filed their flight-plan, arrived at the aircraft 1 hour and 10 minutes before takeoff. The battery of one of the BLTs was completely discharged. The first officer, operating the flight, decided to use the second BLT, also on battery. During cockpit preparation, the first officer noted the presence of a fault message on the hydraulic system. The attending ground-crew confirmed that the fault was already being addressed.
At the time of the calculation of the takeoff parameters, the commander indicated to the first officer that the zero fuel weight (ZFW) figure should be increased by 1.6 T, as well as the takeoff mass calculation (TOW). He then inserted the updated ZFW in the FMS. By using the TOW, the first officer determined the takeoff parameters by use of the BLT.
He then gave the laptop to the commander who began checking the data inserted. Presumably, also due to a low battery state, the BLT defaulted at that point to its Suspend/hibernate mode. The commander passed it back to the first officer who inadvertently rebooted it, causing an erasure of the previously inserted values.
During this period, the commander was also discussing the hydraulic malfunction with the ground mechanic. During the new data insertion in the rebooted BLT, the commander entered in error the ZFW in place of the TOW. The value inserted in the BLT was thus 242,3 T instead of 341,3 T. The commander then replaced the speed values calculated by the FMS with those generated by the BLT, without carrying out any “reasonableness” (i.e., credibility) check on those values.
The first officer subsequently checked there was agreement between the values derived by the BLT and those now showing on the FMS screen, i.e. for any transcription error (only).
The commander recalls being astonished, at the time, by the size of the generated temperature value and the consequent value of the reduced thrust and he made known his doubts to the copilot. The First Officer dismissively attributed the values as being justified by the unusually high barometric pressure (QNH) and the low ambient temperature. The crew decided on a “rolling takeoff” (not lining up and setting a preliminary reduced thrust on the brakes).
This fast getaway served to disguise any early realization that the aircraft’s acceleration was overall abnormally weak. Approaching V1, runway remaining was looking a mite sparse so the Captain began having doubts about their calculated takeoff speed values. He therefore decided to delay slightly on the FMS advertised “rotation” speed of 127 kts and communicated that.
At 132 kts, the copilot began his rotation and at once detected an unfamiliar sluggishness in the aircraft’s response. He slowly increased the attitude to eventually reach 13 degrees nose-up. At this point, the stick-shaker briefly kicked in. The copilot reacted by decreasing the pitch attitude while applying maximum takeoff power. The attitude was maintained between 11 degrees and 12 degrees nose-up.
Speed increased to reach 166 kts with their passage over the upwind threshold at a height of around 35 ft. A runway vehicle saw smoke during their rotation and informed the control tower. It communicated this information to the crew and simultaneously indicated to them that a runway inspection would be carried out.
Once the gear had retracted, the crew, suspecting a problem in their calculated speeds, decided to increase all flap retraction speeds by 20 kts. The initial climb was flown manually until the retraction was complete.
The runway inspection turned up metal debris and a tell-tale scrape-trace about 80 meters in length. Climbing through Flight Level 180 (18,000ft), the crew was informed by the departure controller of the runway evidence. The crew stopped their climb and requested a descent to FL100. A tail-strike was assumed, although no crew member perceived any shock or scraping.
The TAIL STRIKE checklist was carried out. The captain decided to return to Orly after dumping fuel to landing weight. ATC proposed a visual inspection by a nearby Mirage fighter. Its pilot noted extensive scrape-marks along the lower aft fuselage extending up to (and including) the damaged auxiliary power unit (APU).
The BLT uses computation software to ascertain takeoff parameters and it replaces paper-based derivation of the data. The calculation process integrates real environmental conditions (temperature, wind, QNH, runway contamination) and takes into account inoperative items being carried under the authority of a permitted list (the Minimum Equipment List, or MEL).
Separately, the FMS calculates, starting from the ZFW inserted by the crew and deriving its additive weight data information from the fuel sensors, the speeds required for takeoff. However, the FMS calculation does not take into account certain parameters, such as the QNH. This is why the Corsair procedures recommend use of the BLT: the commander inserts the speeds calculated by the BLT over the top of those produced by the FMS and the copilot checks that they were correctly entered.
The BEA (the French version of the NTSB) found the incident was due to the use of the ZFW in place of the TOW for the calculation, following a laptop “handling error” having required a new data capture. The subsequent non-detection of the abnormal values in the BLT’s calculated results made it all inevitable.
After the event, the Flight Safety Department of Corsair proposed the following safeguards:
1. The BLT must be connected to the aircraft’s electrical supply on the ground to limit shutdowns;
2. Sterile cockpit procedure to be in force during this phase of pre-flight preparation (no third parties);
3. Prescribe a method for double-checking weight and balance data by comparing the data provided for the input figures through reference to their loadsheet;
4. Add to standard operating procedures a method for validating parameters inserted in the BLT and the subsequent insertion of output data into the FMS;
5. Crew review of their takeoff weight in the takeoff pre-brief;
6. During Line Oriented Flight Training (LOFT), use of the BLT in the simulator syllabus; and
7. Following the calculation, a review of the basic operating range parameters of the aircraft.
Transcription is just part of the problem. Not to sound cynical, but it’s a good bet that we haven’t heard the last of BLT-inspired tail-first hiccups.