,

. _

l 

I 

NASA/TM-2012-216007 

. N~ ./., . ~~...

!+ .. .... .' ';-. ' .. 

+ . 

Performance Data Errors in Air Carrier Operations: 

Causes and Countermeaures 

Benjamin A. Berman 

San Jose State University 

R. Key Dismukes 

NASA Ames Research Center 

Kimberly K. Jobe 

San Jose State University 

June 2012 
,

- - ---- - - --

NASA STI Program .. .in Profile 

Since its founding, NASA has been dedicated to • CONFERENCE PUBLICATIO . Collected 

the advancement of aeronautics and space papers from scientific and technical 

science. The NASA scientific and technical conferences, symposia, seminars, or other 

information (STI) program play a key part in meetings sponsored or co-sponsored 

helping NASA maintain this important role. by NASA. 

The NASA STI program operates under the 

auspices of the Agency Chief Information 

Officer. It collect ,organizes, provides for 

archiving, and disseminates NASA's STI. The 

NASA STI program provides access to the 

NASA Aeronautic and Space Database and its 

public interface, the NASA Technical Report 

Server, thus providing one of the largest 

collections of aeronautical and space science 

STI in the world. Results are published in both 

non-NASA channels and by NASA in the 

NASA STI Report Series, which includes the 

following report types: 

• TECHNICAL PUBLICATION. Reports of 

completed research or a major significant 

phase of research that present the results of 

NASA Program and include extensive data 

or theoretical analysis. Includes 

compilations of significant scientific and 

technical data and information deemed to be 

of continuing reference value. NASA 

counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manu cript length and extent 

of graphic presentations. 

• TECHNICAL MEMORANDUM. 

Scientific and technical findings that are 

preliminary or of specialized interest, e.g. , 

quick release report, working papers, and 

bibliographies that contain minimal 

annotation. Does not contain extensive 

analysis. 

• CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

11 

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from NASA 

programs, projects, and missions, often 

concerned with subjects having substantial 

public interest. 

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific and 

technical material pertinent to 

NASA's mission. 

Specialized services also include creating custom 

thesauri, building customized databases, and 

organizing and publishing re earch results. 

For more information about the NASA STI 

program, see the following: 

• Access the NASA STI program home page at 

http://www.sti.nasa.gov 

• E-mail your question via the Internet to 

help@sti.nasa.goY 

• Fax your question to the NASA STI Help 

Desk at (301) 621-0134 

• Phone the NASA STI Help Desk at 

(301) 621-0390 

• Write to: 

NASA STI Help Desk 

NASA Center for AeroSpace Information 

7121 Standard Drive 

Hanover, MD 21076-1320 

J 
NASA/TM-2012-216007 

Performance Data Errors in Air Carrier Operations: 

Causes and Countermeasures 

Benjamin A. Berman 

San Joe State University 

R. Key Dismukes 

NASA Ames Research Center 

Kimberly K. Jobe 

San Jose State University 

National Aeronautics and 

Space Administration 

Ames Research Center 

Moffett Field, California 

June 2012 

III 

~~- - -- -~ - - - ---- -- - -- -- - - --
L _____ _ 

Acknow ledgements 

Thi study wa supported by a grant to the National Aeronautics and Space 

Administration from the Federal Aviation Administration; Thomas McCloy, 

Program Manager. Thanks to Dan Herschler and Captain Kent Lewis for 

their helpful comments on an earlier draft of this manuscript. 

Available from: 

NASA Center for Aerospace Information 

7121 Standard Drive 

Hanover, MD 21076-1320 

301) 621-0390 

This report is also available in electronic form at http://www.sti.nasa.gov 

or http ://ntr .nasa.gov/ 

IV 

--- ----' 
Contents 

List of Acronyms and Definitions .. ... ........................................... ............... .................. ................. VI 

Executive Summary .. .... .. ..... ........... ............ ............ ....................................................................... . 

1. Introduction ............ ............ ......... .... ... ....... ...... .. .... ................. ................ .... .............. .... ............... 4 

2. Literature Review and Analysis ................ ... ....... .. ............................. .............. .............. ............. 7 

2. 1 Defining the Problem. ..... ...... .................... ....... ......... ........... ......... ..... .......... ................. ...... 7 

2.2 Errors and Outcomes .. ............................................... ............................ ............ ................. 7 

2.2.1 Laboratory of Applied Anthropology Case Review, Observational, and 

Survey Study ... .... . ....... ....... ........... ....... .......... ................... ... .......... . .. .......... .. .......... ... 8 

2.2.2 Australian Transport Saftey Bureau Case Review of Flight Crew Errors ................. 8 

2.2.3 Australian Transport Saftey Bureau Case Review of Ground Personnel Errors ....... 10 

2.2.4 Henriqson, Winsen, Saurin, and Dekker (2010) Case Review ........................... ....... 10 

2.3 Ideas about Risk Mitigation ..................................... ..................... ............... ............ ... ........ 11 

3. Method.............................. ............. .... ........... ........ ... ....... .. ..... .. ............. ... .. ...... ............... ............ 18 

3.1 Study Scope, Keyword Search , and Sampling .................................. .............. .. ................. 19 

3.2 Error Identification ... ...... .. ... .. .......................... ................................ ......... .......................... 20 

3.3 Variable Definition and Coding ........... ... .. ....... ...... ........... ............... ... .......... ........... ........... 20 

4. Results....... ................... ....................... ......... ... .................................... ... ............................. ....... . 26 

4.1 Information from Airlines... ............................. ............ .... ................................................... 26 

4.1.1 Counting/Weighing..... ..................................................... ........................ ...... .. ......... . 26 

4.1.2 Calculating ......... ... ... ............................. ... .................................................................. 28 

4.1.3 Flight Deck Data Entry .. .......... ............... ........................................ ........................... 28 

4.1.4 Errors .. ............................................................... ................................ ................ ........ 29 

4.1.5 Error Trapping................................... .. .............. ........... ............................................. 30 

4.1.6 Future Technologies and Procedures ...................... ...... ......... .................................... 33 

4.2 Summary of Proces Steps in Three Variants........ .. ................................................... ........ 34 

4.2.1 ASRS Case Analysis......... ................ ......................................................................... 36 

4.2.2 Locus of Error Reported ................................................................... .. ....................... 37 

4.2.3 Process Steps, Actors, and Types of Errors .. .. ........................... .... ............................ 38 

4.2.4 Fuel Load Errors .... ............... ....... ....................................... ........................... ..... ....... 46 

4.2.5 Laptop-Related Errors ......... .................................. .............................. .... .................. 46 

4.2.6 Error Trapping .. .. .............................. .................................. .............. ......................... 47 

4.2.7 Role of Incorrect Information ............ .. ............................. ............... ...................... .. .. 51 

4.2.8 "Trappability" of Error by Ideal Procedures/Systems ............................. .................. 51 

4.2.9 Role of Cognitive and Other Human Factors ............................................................ 52 

4.2.10 Consequences of Errors ............. .............................................................................. 53 

5. Discussion .......... ....... ......... ....... ..... ............ .. .. ..... ..................... ......... ..... . ........... ....... .. .. ..... ......... 56 

5.1 Locus, Process Step, and Types of Error ..... ......... .. .................. .......................................... 57 

5.2 Consequences of Errors................................. ........................ ............... .. ......... .. ................. 60 

5.3 Error Trapping..... ............ ..................... .. .................. ....... .. ................. ................................ 61 

5.4 Mitigation of Performance Data Errors ....... ........... .................. ......... .. ............................... 63 

5.5 Summary of Error Mitigations .. .. ........... ............. ..................................... ......... .................. 70 

6. References........ ............................... ............................ ......................... ..... ............ ...... ............ .... 75 

Appendix A. Aircraft Type... ............... .................. .. ......... .. ............. .. . ........... . .......... ... .. ................. 77 

v 
r 

 

I 

l 

Acronyms and Definitions 

AAIB .... .............. .. Air Accidents Investigation Branch of the United Kingdom 

ACARS .............. .. Aircraft Communications Addressing and Reporting System 

ACN ............. .. ...... accession number given to an incoming ASRS report 

AOC ..................... airline operations center 

ASRS ............ ....... A viation Safety Reporting System 

ATC ... ............ ...... air traffic control 

ATSB .... ........ ..... .. Australian Transport Safety Bureau 

BEA .. ................... Office of Investigations and Analysis for the Safety of Civil Aviation 

(Bureau d'Enquetes et d'Analyses pour la Securite de l'Aviation 

Civile) of France 

CDU ...... ..... ... .... ... control display unit 

CG ... ..................... center of gravity 

DGAC ............ ... ... Civil Aviation Authority (Direction Generale de I' Aviation Civile) 

of France 

EFB ...... ................ electronic flight bag 

EICAS ........... ... .... engine-indicating and crew-alerting system 

FAA ... ........ ....... ... Federal Aviation Administration 

FMC ..... ............ ... . flight management computer 

FMS ............... , .. ... flight management system 

GL W .................... gross landing weight 

GTOW .............. ... gross takeoff weight 

MCDU ... .. ............ multipurpose control display unit 

MEL ............. ........ minimum equipment list 

NLR .... ................. Netherlands Aerospace Laboratory 

NOTAM ..... ........ .. Notice to Airmen 

NTSB .. ................. National Transportation Safety Board 

PFD .. ... .. .......... ..... primary flight di play 

RTO .... ....... ..... .. ... rejected takeoff 

SOP ..... .............. ... standard operating procedure 

TOPMS ...... .. .. ... .. . takeoff performance monitoring system 

TOW ...... ............ .. takeoff weight 

TSBC .. ...... .. ......... Transportation Safety Board of Canada 

V -speeds ... ........... takeoff reference speeds 

VI speed ....... ....... decision speed for engine failure 

V2 speed .... ..... .... . takeoff safety speed for engine failure 

Vr speed .............. . rotation speed 

ZFW .. ... ................ zero fuel weight 

Vl 

--I 
Performance Data Errors in Air Carrier Operations: 

Causes and Countermeasures 

Benjamin A. Bermanl

, R. Key Dismukes2, and Kimberly K. lobe3 

Executive Summary 

Several airline accidents have occurred in recent year as the result of erroneous weight or 

performance data used to calculate V-speeds, flap/trim settings, required runway lengths, andlor 

required climb gradients. Only one of these accidents incurred fatalities, but the potential for future 

accidents with large numbers of fatalities prompted the French and the Australian aviation 

authorities to conduct reviews of the risks. In this report we consider and extend four recent studies 

of performance data error4 , report our own study of ASRS-reported incidents, and provide a broad 

set of countermeasures that can reduce vulnerability to accidents caused by performance data errors. 

Performance data are generated through a lengthy process involving several employee groups and 

computer and/or paper-based systems. Although much of the airline industry 's concern has focused 

on errors that pilots make in entering flight managment system (FMS) data , we determined that 

errors occur at every stage of the process and that errors by ground personnel are probably at least 

as frequent and certainly as consequential as errors by pilots. Although relatively few major 

accidents have yet been caused by performance data errors, our study suggests that more accidents 

are likely to occur unless existing measures to prevent and catch these errors are improved and new 

measures developed. 

Six kinds of error are of greatest concern: 1) ground personnel errors in obtaining, calculating, and 

entering weight data; 2) FMS data entry errors by flight crew; 3) errors made in checking against 

limitations; 4) flap and trim configuration errors, 5) fuel weight errors by either ramp personnel or 

pilots; and 6) errors by pilots using cockpit laptop performance computers and electronic flight bags 

(EFBs). Cutting across several of these six categories were errors made either by ground personnel 

or by pilots while manually entering data. 

Mo t of the errors we examined could in principle have been trapped by effective use of existing 

procedures or technology; however, the fact that they were not trapped anywhere in the chain of 

developing and applying the data indicates a need for better countermeasures. Existing procedures 

are often inadequately de igned to mesh with the ways humans process information and their 

associated vulnerability to error-and procedures often fail to take into account the ways in which 

1 San Jose State Uni versity. 

2 Ames Associate , NASA Ames Research Center, Moffett Field, California, USA. 

3 San Jose State University. 

4 We use the term 'performance data errors' to include both weight errors and other types of error that 

produce incorrect calculations of aircraft performance and/or incorrect setting of aircraft controls. 

1 
information flows in actual flight operations and the time pressures experienced by both pilots and 

ground per onnel. 

Because data entry errors are 0 prevalent, we suggest that airlines employ automated systems 

(feasible with current technology) that eliminate the need for manual data entry wherever possible 

in the process. For instance, this could include implementing automation to enter data by scanning 

passenger and cargo documents and eliminating the need to re-enter data by providing direct 

communication that allows sharing of data between the various computer systems. 

Without effective countermeasures, errors will inevitably creep into the data process because of 

human cognitive vulnerabilities and operational exigencies. Many error-trapping procedures fail 

because the various data checks all use tlie same source of data and thus produce the same 

erroneous output. To make error trapping procedures as effective and reliable as possible, they 

should be designed to validate the performance data process by using independent sources of 

information , data entries, calculation processes, and data transmission . To preserve the 

independence and maximize the reliability of error-trapping procedures, airlines should design and 

implement these procedures in enough detail to explicitly guide the personnel performing them; for 

example, specifying the form, displays, and control indicators to be looked at for verification. 

Airlines can further improve reliability by training personnel in methods to control rushing, to 

enhance deliberate execution of procedural steps, and to encourage deliberate review of status. 

An autonomous onboard weight-and-balance sensing sy tern-as an independent source of 

information-can serve as an effective cross-check for the weight and balance values derived from 

the performance data process. With the capability to update its calculations in real time, this 

technological intervention can effectively prevent errors caused by last minute load changes. 

Even with weight and balance verified by onboard sensing, subsequent calculations and manual 

data entries, such as performance speed parameters, flap settings, and trim settings, can introduce 

additional errors downstream in the process. These can be trapped by additional verification 

procedures, such as well-designed cross checks conducted by pilots and by technological systems, 

such as automatically uplinking calculated performance settings into the FMS and programming the 

FMS to cross-check the uplinked values with its internal calculations. Regardless what approach to 

verification is taken, weight and balance information-as well as performance parameters derived 

from this information-should be compared between independent sources. 

FMS interface design can be improved to prevent some types of data entry errors. For example, for 

those designs not already modified, it should be possible to modify FMS software so either zero fuel 

weight (ZFW) or gross takeoff weight (GTOW)-but not both weights-can be input by the pilots. 

Throughout performance data processes it is critically important for both ground personnel and 

pilots to resolve discrepancies identified during cross-checks of performance data. Airlines should 

inculcate this practice into operational culture and line norms by proceduralizing, training, and 

encouraging it. Discrepancy re olution procedures should establish thresholds for specific 

di crepancies, such as fuel weight, defining those that are acceptable and those requiring resolution. 

One cross-check that can be readily incorporated in airline procedures is a pre-departure 

compari on between the preliminary (flight-planned) and the final weight/balance data. This 

procedure is valuable because the preliminary data are based on seats previously booked by 

2 

I 

I 

I 

I 

~ 
,--

I 

passengers and cargo that the airline has planned to be loaded, while the final data are, in most 

cases, developed independently. However, the effectiveness of this procedure depend on 

discrepancies between these values being resolved before departure by independent verification 

(such as an autonomous onboard weighUbalance sensor) or by back-tracking through the entries and 

calculations of the individual load elements and correcting these previou steps in the performance 

data process. 

Some of the mitigation proposed in our study would require airlines to develop new procedures, to 

modify existing procedure to provide enhanced independence, or to specify existing procedures in 

greater detail so per onnel can be properly trained and then perform the procedures on the line 

effectively. Other mitigations would require enhanced technology , most of it already existing and in 

some cases already in use on some aircraft. All of these mitigations are achievable but some of 

them would require airlines to make significant investments (especially those operating aircraft 

with older FMS and databus communications sy tems). Cost-benefit analysis is beyond the scope of 

this study but the risks and potential consequences of peliormance data errors are substantial and 

the safety benefits of mitigating them are clear. 

The need for new measures should be considered in the light of changes in the national air transport 

system planned under the Federal Aviation Administration (FAA) NextGen program. Some aspects 

of NextGen , such as shifting responsibilities for control of flight path between air traffic control 

(ATC) and the flight deck, will probably not affect the kinds of errors discussed in this report; 

however, other aspects may increase vulnerability to performance-data errors if countermeasures 

are not applied. In particular, under NextGen the volume of air traffic is expected to increase 

substantially. Although some of this increased volume may be accommodated by reliever airports 

(under the multiplexing concept) existing major airports will handle more traffic, thus will launch 

more aircraft per hour. With more operations, more opportunities for performance-data errors will 

occur and personnel may have less time to detect and correct the errors; hence improved 

countermeasures will become more urgent. These countermeasures will also be crucial for reliever 

airports, which may have less experience with high volume operations. 

Under NextGen it is also envisioned that datacom will be used to transfer most information among 

the flight deck, ATC, and airline operations centers (AOCs). To the extent that these data 

communications are implemented in the current technology, which is largely similar to text 

messaging, typing and reading so many datacom text messages will greatly increase opportunities 

for errors, including load and performance data errors. Also, in this form of data communications, 

operators are prone to accept such text messages without critically checking values so the need for 

error prevention and trapping will increase. On the other hand, if the necessary data 

communications are highly integrated so the informational output of one sub-system, such as the 

airline's performance data system, flows autonomously to become the input for other sub-systems, 

such as NextGen enroute and approach metering and sequencing, then NextGen technology has the 

potential to serve as a mitigation for data entry error. 

3 

----"'---- - - - - - -- - - --

! I 
1. Introduction 

On October 14,2004, a Boeing 747 freighter operated by MK Airlines crashed while departing 

Halifax, Canada. On its previous flight the aircraft had departed from Hartford, Connecticut, at a 

takeoff weight (TOW) of 240,000 kilograms. The aircraft was then loaded at Halifax with 

additional fuel and cargo and the planned TOW for the departure from Halifax was 353,000 

kilograms. The crew used a laptop-based program to calculate the performance data for the 

departure, including values for takeoff reference peeds, also known as V-speeds-decision speed 

for engine failure (Vl), rotation speed (Vr) , safety speed for engine failure (V2)-as well as engine 

thrust, flap setting, and pitch trim. The laptop program used inputs by the flight crew for aircraft 

weight, runway , and weather to derive these performance numbers. The crew entered the Halifax 

runway and weather into the laptop computer but apparently the weights from the previous takeoff 

at Hartford remained active in the laptop program. Consequently, the laptop-calculated V-speeds, 

thrust values, and trim settings were for a much lighter weight than actual. The crew then 

apparently omitted company procedures for independent data verification and gross error checks so 

the error was not caught. 

Using the incorrect performance data, the crew attempted to rotate the aircraft to its takeoff attitude 

at a speed that was too slow for its actual weight. Such a takeoff rotation with insufficient airspeed 

can result in a transport aircraft such as the 747 entering a high-drag condition that can delay or 

prevent its climb away from the runway. Also, to mitigate engine wear, many takeoffs are 

conducted using reduced or derated thrust settings which are based on the power needed to lift the 

planned weight off the runway and through the required climb transitions. In the case of this 

attempted departure from Halifax, the calculation using the wrong weight resulted in lower-thanrequired thrust, compounding the effects of the early takeoff rotation and further delaying liftoff. 

Consequently, unable to climb, the 747 crashed just off the end of the runway, killing all seven 

aboard (Tran portation Safety Board of Canada, 2006). 

On March 20, 2009, an Airbus 340 operated by Emirates Airlines received substantial damage 

during an attempted takeoff from Melbourne, Australia, following a 100,000 kilogram error in the 

crew's entries to the laptop-based computer program. In this case, a pilot entered 262 tons instead 

of 362 tons in the TOW field of the laptop input screen. The airline's standard verification 

procedures did not catch the error. 

During the takeoff roll, t,he aircraft accelerated very slowly. Just before the end of the runway, the 

flying pilot rotated aggressively, striking the tail on the pavement. The aircraft continued beyond 

the runway surface and rolled through grass, clipped an airport structure, then slowly climbed away . 

There were no injuries, but thi accident was considered to be a close escape from catastrophe. 

Similar events occur, some narrowly escaping becoming accidents. One flight crew reported to the 

NASA Aviation Safety Reporting System (ASRS):5 

"The operations agent handed me the load sheet and I began to make the appropriate 

entries in the flight management computer and laptop [performance computer] ... we 

proceeded to push, start, taxi, and take off uneventfully. 

Once in the air, we received a radio call from operations telling us to revise our takeoff 

weight. .. the correct weight was actually 19,000 pounds heavier. We then realized ... the 

5 ASRS Reports 664643/664644. 

4 
operations agent had entered 33 pa enger into the computer versus the 133 passengers 

that we actually had. 

The plane took off fine, although the captain said it felt a little mu hy on liftoff...I can't 

believe that I missed this large error. I quickly scanned the form .. .I think part of the 

problem is that with the new computer-generated form, I have stopped looking for math 

errors like I did with [the] old form . This can create a false sen e of security ... on this 

flight, all three of us failed to catch a simple error and the check and balance we rely on 

broke down." 

Many opportunities for error occur when aircraft load data (e.g., weights offuel, cargo, and 

baggage) are processed to derive the aircraft performance information (e.g., required runway 

lengths, climb gradients over obstacles, and margins above aerodynamic stall) and the associated 

values for V-speeds, trim settings, and flap settings. Data processing is involved when gate and 

ramp personnel load passengers, baggage, and cargo; airline central offices and station facilities 

plan and control load; and pilots enter data into laptops and FMSs and calculate flap, trim, and 

cruise altitude values. Errors in these processes have resulted in fatal accidents (Halifax B-747), 

structural-damage accidents (Melbourne A-340), numerous incidents involving less serious 

damage, and a large number of reports by pilots to the ASRS. No passenger-carrying aircraft has 

been lost recently because of such errors, indicating that existing safety procedures and systems are 

at least partially controlling the risk, but the events that have occurred suggest the potential still 

exists for accidents with many lives lost. 

The purpose of this study is to identify the sources and kinds of errors in processing performance 

data in air carrier operations, including the failure of the involved personnel and systems to reliably 

trap and correct errors before producing adverse outcomes. Initially the focus of our research was 

directed toward errors made by pilots while entering weight data into FMS control display units 

(CDU/MCDU) in the cockpit. However, review of the literature and accident/incident data 

suggested that the sources of error and error-trapping failure are not limited to the FMS data entry 

actions of the flight crew but also frequently involve errors in data generation and performance 

calculations by airline operation center, central load planning office, or at the local station 

operations office personnel. 

Years ago, pilots made their own performance calculations based on the counts and weights of 

passengers, cargo, baggage, and fuel that were relayed to them by ground personnel. They added up 

the weights to derive takeoff and landing weights, consulted tables to calculate the aircraft's 

balance (center of gravity position), factored in the winds, temperature, and runway information, 

verified the calculated weight/balance against the aircraft's limitations with the help of tables or 

placards on the instrument panel, and obtained reference speeds, trim settings, and thrust settings 

from additional tables and graphs. They posted the V -speeds and thrust settings on handwritten data 

cards and perched them in view on the panel for ready reference and they also set moveable plastic 

"bugs" at the rim of the airspeed indicators. 

These processes are still used in some operations, but today these same functions may be performed 

by pilots using laptop computers that accept entrie of the individual components of aircraft weight 

( uch as counts of boarded passengers and the weights of cargo container loaded in underbelly 

bins) together with other entries about the runway and weather conditions to generate the V -speeds, 

trim settings, and thru t setting -verifying compliance with all of the aircraft's performance 

limitations along the way. Or these same functions may be performed by ground personnel in a 

5 
central load planning office or at the local station operation office with the performance speed and 

other data relayed to a cockpit printer or even uplinked directly into the FMS computer in the 

aircraft. This re-distribution of tasks among various flight, ground, and back-office personnel has 

simplified the tasks for some personnel but requires coordination and cross-checking among all the 

players to prevent and catch errors. Unfortunately, the overall system has become less transparent 

to users-making coordination and cross-checking more difficult. 

With these trends in mind, we broadened the focus of the study to include performance data error 

and error-trapping by all personnel and departments involved in the process of generating and using 

load and performance data. The Halifax and Melbourne accidents illustrate two possible outcomes 

of performance data errors but other adverse consequences are also possible. In this report we 

discuss examples of a broad range of potential consequences: 

• Premature rotation leading to tailstrike or inability to achieve liftoff 

• Inability to rotate due to mistrim 

• Inadequate thru t for runway length 

• Inadequate climb performance over obstacle 

• Inadequate performance in the event of engine-failure contingencies (both rejected takeoff 

and continued takeoff after engine failure) 

• Excessive fuel consumption or stall during cruise 

• Stall or hard touchdown during approach and landing 

• Instability during all phases of flight caused by excessive aft center of gravity (CG) 

• Structural damage (observable or hidden) from overloading 

We start by analyzing the sources and types of performance data errors, drawing upon an ASRS 

search, results from previous studies, and accident/incident investigations. We then examine the 

adequacy of airlines' performance data processes to trap these errors, using both currently 

employed procedures and systems and those that are potentially available in the future. We 

conclude by proposing measures to improve airline performance data processes by (1) reducing the 

occurrence of the e errors to the extent that is realistically possible and (2) increasing the 

effectiveness and reliability of error trapping so those errors that do occur will be caught and 

corrected before flights are exposed to risk. We focus especially on errors with potential to cause 

major adverse consequences. 

The need for new measures should be considered in the light of changes in the national air transport 

system planned under the FAA's NextGen program. Some aspects of NextGen, such as shifting 

responsibilities for control of flight path between ATC and the flight deck, will probably not affect 

the kinds of errors discussed in this report; however, other aspects may increase vulnerability to 

performance-data errors if countermeasures are not applied. In particular, under NextGen the 

volume of air traffic is expected to increase substantially. Although some of this increased volume 

may be accommodated by reliever airports (under the multiplexing concept), existing major airports 

will handle more traffic and thus will launch more aircraft per hour. With more operations, more 

opportunities for pelformance-data errors will occur, and personnel may have less time to detect 

and correct the errors; hence improved countermeasures will become more urgent. These 

countermeasures will also be crucial for reliever airports which may have less experience with high 

volume operations. 

6 
Under NextGen it i also envisioned that datacom will be used to transfer most information among 

the flight deck, ATC, and AOCs. To the extent that these data communications are implemented in 

the current technology , which is largely similar to text messaging , typing, and reading, so many 

datacom text message will greatly increa e opportunities for errors, including load and 

performance data errors. Also, in this form of data communications operators are prone to accept 

such text messages without critically checking value so the need for error prevention and trapping 

will increa e. On the other hand, if the necessary data communications are highly integrated so the 

informational output of one sub-system, such as the airline 's performance data system, flows 

autonomously to become the input for other sub-systems, such as NextGen enroute and approach 

metering and sequencing, then NextGen technology has the potential to serve as a mitigation for 

data entry error. However, when data are transferred autonomously, operators are prone to accept 

such inputs without critically checking values so the challenge and need for error prevention and 

trapping will increase under NextGen technology . 

2. Literature Review and Analysis 

In this section we review existing literature about performance data errors, focusing on problem 

definition, error causes and outcomes, and ideas about risk mitigation. In addition to several safety 

studies, we examined numerous investigative reports of accidents and incidents involving 

performance data errors. Rather than repeating the description of the events during these accidents 

and incidents, though, we only summaJize selected aspects that we drew upon in our own study. 

2.1 Defining the Problem 

Describing a Boeing study, Santoni and Terhune (2000) noted that airlines have experienced 

tails trikes , high speed rejected takeoffs, and other adverse outcomes when pilots used V-speeds that 

were lower than required by the actual weight of the aircraft and operating conditions. The pilots' 

use of these low V -speeds, in tum, were "caused by a variety of human errors that typically resulted 

from using an erroneously low value for gross weight or an incorrect flap reference setting when 

determining takeoff speeds" (p. 15). 

Santoni and Terhune listed examples of errors occurring throughout the performance data process 

that could result in these consequences. They evaluated the major Boeing aircraft types with respect 

to susceptibility to a significant consequence. For example, long-range aircraft with high fuel 

capacity (e .g., 747 and 777) could have a rotation speed error of as much as 36 knots-a very large 

error-if the ZFW value were substituted for the GTOW value or if weight were entered in 

kilograms instead of pounds. Also, the high-lift wing of the 757 was susceptible to a rotation speed 

error of as much as 25 knots if the wrong flap setting were applied. 

2.2 Errors and Outcomes 

Four recent studies-largely case-based-have identified problem areas in performance data errors 

and suggested mitigations. 

7 
I 

I 

2.2.1 Laboratory of Applied Anthropology Case Review, Observational, and 

Survey Study 

A research group comprising representatives of the French civil aviation authority (DGAC), 

accident investigation agency (BEA), and operational and human factors experts (Laboratory of 

Applied Anthropology , 2008) reviewed 12 performance data incidents worldwide from 1990 

through 2006 that were investigated by accident investigation agencies. The group also observed 

flight operations at two air carriers and surveyed pilot from these air carriers about their own 

experiences with performance data errors. The incident investigations revealed several types of 

performance data errors, including: 1) one instance of mistaken use of data from the previous flight 

(similar to the Halifax 747 accident); 2) two instances of substitutions of ZFW values for GTOW 

values during data entrie into laptop performance data computers (similar to the Melbourne A-340 

accident); and 3) additional erroneous data entries by pilots using laptop computers or Aircraft 

Communication Addressing and Reporting System (ACARS) data communications from the flight 

deck to a central load computer, resulting in transfer of incorrect information into the FMS . Only 

one error involved an incorrect keyboard entry into an FMS; this was an incorrect VI speed that a 

first officer entered during taxi and that was not cro s-checked by the captain . All of the other 

errors in this study occurred either earlier in the sequence-so the pilots were provided with 

incorrect data (or miscalculated it themselves)-or later in the sequence so the pilots used valid data 

incorrectly (e.g., setting the trim wrong). 

This study determined that "Half the [30] crews who responded to the survey ... had experienced 

errors in parameters or configuration at takeoff' (p. 67). Further, the study called attention to the 

roles of time pressure and late changes to performance parameters in these errors: 

"The real-time availability of the final weight information a short time before 

departure obliges the crew to perform a large number of tasks, inputs and parameter 

displays under strong time pressure .. .Time pressure and task interruptions are 

frequently cited in surveys as common factors contributing to errors. The 

observations showed that the crews' workload increases as the departure time 

approaches and that the normal operation actions of the captain were all the more 

disrupted .. . " (p. 67-68). 

Regarding pilots' ability to catch performance data errors by recognizing out-of-bounds values, 8 of 

the 30 surveyed pilots reported using this informal, non-procedural method. The study noted, 

however, that today's airline pilot no longer possesses a working knowledge of the orders of 

magnitude of the aircraft's performance parameters, making it difficult to recognize even a gross 

data error. The study suggested that training could improve pilot performance and further 

recommended that pilots be provided with a placard or display incorporating key values for a range 

of typical conditions. Still, this means of trapping performance data errors was evaluated as being 

"insufficient" (p. 43-44). 

2.2.2 Australian Transport Safety Bureau Case Review of Flight Crew Errors 

The Australian Transport Safety Bureau (ATSB) examined 20 international and 11 Australian 

takeoff accidents and incidents related to performance data errors over a twenty-year period 

(Hughes & Godley , 2011). This study was limited to errors made by flight crews; a companion 

study , discussed below , examined errors made by ground personnel. 

8 
I 

I 

L 

In the 20 international accident /incidents which were evaluated in the greatest detail , the ATSB 

found that: 

• Sixteen involved incorrect entry or calculation of weight parameters while another three 

involved incorrect entry or calculation of V -speeds. 

• Eleven involved the wrong datum being used, such as using ZFW instead of GTOW, using 

the GTOW from the previous flight, or entering the wrong fuel value. Another four events 

involved having the correct figure but entering it incorrectly. 

• Performance data documents (including load manifests and tabular or graphical references 

for weights and speeds) and laptop performance computers were the equipment most 

commonly involved in the errors. There were three instances of pilots substituting ZFW 

for GTOW while using a laptop, similar to the Melbourne A-340 accident. 

• Tailstrikes, collisions with terrain/obstacles, and reduced takeoff performance were the 

primary consequences of these errors; however, we note that the ATSB probably selected 

these accidentslincidents because of their potential seriousne s and thus a wider range of 

consequences may exist. 

This study highlighted the role of changing conditions in several of the errors that occurred in the 

20 events. Pilots were sometimes assigned runways different from the runways for which 

performance calculations were originally made; pilots sometimes received a revised load sheet with 

a changed TOW; and on occasion the normal method of obtaining performance data from 

dispatch/central load planning was not working so alternative means had to be used. 

Failures of monitoring and checking were the most common errors: "[t]hese involved crew actions 

associated with verification or cross-checking of takeoff data computations not being completed by 

the crew" (p. 64). The most common situational contributing factor involved pilots who had 

recently transferred from another aircraft type for which the erroneous weights/speeds would have 

been appropriate, thus limiting the pilot's ability to identify the erroneous values as being out of 

normal bounds. 

The ATSB examined failures in what it termed "risk controls" similar to what we call verification 

and error-trapping procedures and systems. Among these, the most common failures were related to 

automation systems and the crew procedures for using them. Examples of automation-related 

factors were: 

• "The system accepted mismatched values without challenge." 

• "TOW was the required input value for the aircraft communications addressing and 

reporting system [but] the ZFW was the required input value for the [FMS]." 

• "The system was configured in a way that prevented the crew from conducting a gross 

error check" (p. 68). 

• There was "no inbuilt function to alert the user that the values entered were unrealistically 

low or mismatched (compared with the values already calculated by the ystem)." 

• "The system reverted to the information entered for the previous flight" (p. 72). 

9 
-- ~-- -- --- .....-~ -- - -- 

Examples of procedural factors in the elTor were: 

• "Procedures did not specify who was re ponsible for calculating takeoff data' (p. 68). 

• "No procedures in place to compare or independently verify the takeoff performance 

parameter values with other sources, such as comparing the data entered into the laptop 

computer with that automatically calculated by the flight management computer." 

• "No requirement for the calculations made by one crewmember to be cross-checked by 

another crew member." 

• "No requirement to cross-check all of the takeoff performance parameters, for example, a 

cross-check of the V -speeds was required but not the aircraft's TOW." 

• "The roles and responsibilities of crewmernbers, including the third or relief pilot, were not 

clearly defined with respect to calculating and verifying takeoff performance calculations." 

• "No procedure in place for calculating takeoff performance data when the primary system 

used to conduct this task was unavailable" (p. 71). 

2.2.3 Australian Transport Safety Bureau Case Review of Ground Personnel Errors 

The ATSB evaluated aircraft loading elTors that occurred in Australia and were reported to the 

Bureau during a 7-yeru: period ending in 2010 (ATSB, 2010). While many of the events were 

related to incolTect securing of cargo (an OCCUlTence unrelated to our focus on performance data 

elTors), other events fell within the scope of our study. These included: 

• Unlisted cargo/baggage being loaded aboard (or not unloaded from a previous flight); 

listed cargo not being loaded (making the aircraft lighter than calculated, but potentially 

out of balance or trim). 

• IncolTect fuel loads. 

• Cargo/baggage being loaded in the wrong location (not adversely affecting weight 

calculations but with possible serious consequences to CG and trim calculations). 

• Loadsheet elTors such as listing the wrong number of passengers. 

• Receipt of a new loadsheet after takeoff. 

• Aircraft-specific parameters (such as basic operating weightlCG) incolTectly encoded in 

computer records and used for calculations. 

2.2.4 Henriqson, Winsen, Saurin, and Dekker (2010) Case Review 

Henriqson and colleagues summarized the outcomes of performance data elTors based on a review 

of 22 occurrences since 1991 (Henriqson, Winsen, Saurin & Dekker, 2010). The authors cautioned, 

"Rather than an exhaustive list of this type of event, the information for these databases was 

provided by legal authorities for public consulting and should thus not be considered as the total 

number of incidents during this period." With this caution, the study reported that: 

''Tail strikes followed by aircraft damage [with] no injuries to persons on board were 

the outcome of 45.45% (n = 10) of incidents. In 27.27% (n = 6), there was no 

technical or operational consequence . In 13.63% (n = 3), the safety margins were 

reduced, while in 9.09% (n = 2), the crews were able to reject the takeoff. Only one 

runway excursion happened. 72.72% (n = 16) were incidents with minor damages, 

and 27.27% (n = 6) were serious accidents." 

10 

--l 
2.3 Ideas about Risk Mitigation 

Santoni and Terhune (2000) made several suggestions for risk-mitigating procedures and systems: 

1) provide conect data to the flight deck (minimizing manual entries by ground personnel to control 

data entry enor ); 2) provide clear and unambiguous displays (recognizing the hazard of 

substituting one datum for another such as ZFW for GTOW); 3) recognize and establish procedures 

for coping with time pressure and out-of-sequence operations; and 4) implement reliable data 

verification procedures. 

Santoni and Terhune further suggested that, to improve verification, manual performance data 

processes should require independent calculations performed by different persons (pilots, 

dispatchers, and/or operations agents). Most automated processes still involve data entry, at least to 

the FMS on the flight deck , and this data entry step should require verification of the inputs 

between the two pilots. The authors suggested that data verification procedures can reduce the 

likelihood of untrapped enors by "several orders of magnitude" (p. 18). 

This study concluded with examples of best, good, and poor practices for several aspects of the 

performance data process. Suggested best practices in the areas of data verification and enor 

trapping included procedural requirements for pilots: 1) comparing the gross weight displayed in 

the FMS with a gross weight value calculated by ground personnel; 2) cross-checking V-speeds that 

have been manually calculated and entered by a pilot against those independently calculated by 

ground personnel, another pilot, or automatically calculated by the FMS; and 3) cross-checking a 

pilot's FMS entries by another pilot. 

Laboratory of Applied Anthropology (2008) highlighted the limited effectiveness of cross-checks 

and other enor-trapping procedures in mitigating performance data errors: 

"Even an input with cross check doesn't guarantee the absence of an error, as one of 

the studied incidents shows: the captain calls out the value to be input and confirms 

the input made by the [first officer]. However, the captain doesn 't read the 

appropriate value, so calls out an erroneous value and the verification of input is 

ineffective" (p. 31). 

They also pointed out that a cross-check must verify not only the values that have been entered into 

a display unit but also the inputs used to derive the entries. They concluded, "Observations showed 

that there was no [error-trapping] based on a comparison of the three principle media: the final 

loadsheet, the takeoff card or laptop, and the FMS" (p. 66). 

These researchers viewed an automated takeoff performance monitoring system (TOPMS) to alert 

pilots in real time about inadequate acceleration during the takeoff roll as the " ultimate barrier" (p. 

12) to adverse consequences from a performance data enor. This echoes the recommendations of 

the Transportation Safety Board of Canada (TSBC) from its investigation of the Halifax accident as 

well as earlier recommendations from the U.S. National Transportation Safety Board (NTSB, 

1982). Industry efforts to develop such a system date back at least 50 years, yet to date no such 

system is employed commercially. We evaluate the history, viability, and effectiveness of the 

TOPMS in the Discussion section. 

Hughes & Godley (2011) proposed several risk mitigation guidelines: 

"For airline , it is important to look at the ways errors can be introduced into the 

process and determine if the procedures currently in place prevent the e errors from 

11 

J 
occurring or provide ufficient opportunities for error to be detected . Procedures 

need to take into account the entire process and recognize that error may occur at all 

tages of pre-flight preparation." 

Ideally, procedure relating to the calculation and entry of takeoff performance parameters should 

take into account the following: 

• An independent calculation or cross-check of the takeoff performance data is conducted by 

another crew member. 

• Where possible, the data is verified using multiple sources. 

• When verifying the data , both the values used to make the calculations and the values that 

are calculated are checked. 

• There are procedures in place in the event the primary aircraft system used to calculate 

takeoff performance parameters is unavailable . 

• The role and responsibilities of all crewmembers are clearly delineated (p . 71-72). 

Henriqson , Winsen , Saurin and Dekker (2010) addressed the limitations of certain cross-checking 

procedures and their reliability in trapping performance data errors: 

"One way in which flight crews often cross-check data card values is through 

validation of each step of the procedure. In this case, the captain will check on the 

laptop all of the values inserted by the first officer, following the same steps used to 

perform the original takeoff calculations ... An analogy can be the mathematical 

validation of a simple product operation. For instance, if we type in a calculator' '2" 

"times" "3" "equals" (=6) and we wish to check the accuracy of this calculation 

(or the outcome), we do this by following the same procedure "2" "times" "3" 

"equals" once more. We rather cross-check the operation that leads to the "6" than 

the validity of the " 6" as the outcome, or the "2" and "3" as inputs. In this 

manner, when the captain is checking or typing the same values in the same order in 

the laptop or in the FMC, he is validating the process rather than the outcome, the 

[gross weight] or the takeoff speeds produced. This is why double cross-checking or 

parallel calculations are not independent and thus not fully efficient." 

In a symposium discussion of performance data errors, Jarvis, Todd, and Burian (2010) touched on 

means of making the trapping of errors more effective and reliable. They suggested that verification 

would become more of an "actual check" if the personnel were to perform their cross-checks 

without already "knowing the answer." Another way to enhance the effectivene s of error-trapping 

was "slowing things down" (p. 30). 

The Federal Aviation Administration (FAA) addres ed the difficulty of implementing automated 

error-trapping routines in some existing FMS models in a June 6, 2005, letter to the National 

Transportation Board responding to NTSB Safety Recommendation A-05-04 (FAA, 2005). The 

NTSB had recommended that the FAA: 

" .. . [r]equire Honeywell to modify its flight management system [FMS] software to 

prevent entry of airplane weights that would result in landing weights below ZFW or 

operating empty weight, and require all operators of airplanes with Honeywell FMS 

computers to incorporate this software modification" (NTSB, 2005). 

12 

-I 
The FAA responded, "There are a number of FMS manufacturers, each of which may have multiple 

FMS versions in their product lines. Each FMS version may have different safety vulnerabilities to 

data entry error that affect takeoff and landing performance information" (FAA, 2005). 

NTSB Safety Recommendation A-05-03 asked the FAA to: 

" ... [r]equire Honeywell to modify its flight management system [FMS] software to 

annunciate warnings to the flight crew when a takeoff reference peed is changed by 

a value that would impede the airplane'S ability to safely take off and require all 

operators of airplanes with Honeywell FMS computers to incorporate this software 

modification" (NTSB, 2005). 

However, the FAA replied on November 23, 2009, that: 

" ... many part 25 airplanes are equipped with Honeywell FMSs that do not compute 

takeoff speeds. Those systems can detect celiain erroneous entries. However, because 

there are no takeoff peed computational algorithms in the operational program 

software, a determination of "safe" speed by those FMSs is impractical. Because of the 

wide range in equipment and potential for errors at many points in the process of 

etting reference speeds, a single technical solution is not considered practical or 

effective in resolving these issues with current FMS installations" (FAA, 2009). 

NTSB Safety Recommendation A-05-05 , asked the FAA to: 

" ... [r]equire Honeywell to modify its [FMS] software either to inhibit manual entries 

in the gross weight field or to allow the takeoff gross weight to be uplinked directly 

into the FMS , and require operators of airplanes with Honeywell FMSs to 

incorporate this software modification" (NTSB, 2005). 

However, the FAA in its June 6, 2005, response to the NTSB replied, "For existing FMS 

airworthiness approvals ... operators already have policies restricting weight entries to ZFW 

only ... Therefore, it would not be necessary to retrofit the fleets to prevent gross weight entries" 

(FAA,2005). 

In a March 30, 2009, memorandum (FAA ANM-lll-09-006, 2009), the FAA provided guidelines 

for developers of newly certificated FMS to mitigate human error in pilots' interactions with these 

systems. These guidelines are not mandatory and the FAA has not proposed requiring modification 

of exi ting FMSs already installed and operating in the current airline fleets. 

In these guidelines the FAA stated: 

Also: 

"The FMS should not allow the flight crew to manually enter the airplane gross weight. 

Instead, the FMS should .. . calculate airplane gross weight from valid zero fuel weight and 

fuel-weight entries (or other similar logic), or...accept airplane gross weight entry through 

automated means, such as datalink or onboard weight and balance systems" (p. 2). 

"[T]he FMS (should) incorporate error detection based on typical weight entries. 

Should the takeoff peeds not be representative of typical performance, then an 

annunciation should be presented to the flight crew. For example, given a valid gross 

weight, flap setting, etc., the FMS could compare the takeoff-speed entries with a 

13 
representative range, and annunciate to the flight crew any entry exceeding that 

representative range" (p. 4). 

Further, in it evaluation of emergent technology, the FAA stated that an on board automatic weight 

and balance system "could interface with the FMS and transmit the measured airplane weights 

directly into the FMS" (p. 3). The potential role of on board weight and balance systems as a risk 

mitigation to performance data errors was extensively discussed in a 2007 survey of aircraft weight 

and balance incidents by Netherlands Aerospace Laboratory (van Es, 2007). This accident and 

incident case study revealed similar error types and underlying factors as the French and ATSB 

studies. Van Es concluded, "The majority (more than 90%) of weight and balance problems 

identified in this paper could be eliminated if there was a system available to the flight crew that 

would do an automatic onboard weight and balance assessment" (p. 20). 

Reviewing the history of these systems, van Es found that governmentJindustry efforts to 

develop an automatic aircraft weight and balance system went back to the 1940s but that an 

accurate and reliable system had not emerged from these efforts. As van Es reported , the 

NTSB recommended that the FAA spon or or develop such a system as a result of the 

January 8,2003, crash of a Beech 1900D turboprop at Charlotte, North Carolina; also, the 

French BEA stated in its report on the investigation of the December 25,2003, crash of a 

Boeing· 727 that: 

" ... erroneous estimates of [performance data) parameters are quite likely during 

operation. Onboard autonomous systems are, however, available and they give an 

indication of the airplane's weight and balance that is sufficient to attract the crew's 

attention in case of an abnormal situation" (van Es, 2007, p. 20). 

Accordingly, the BEA recommended that civil aviation authorities "ensure the presence, on new 

generation airplanes to be used for commercial flights, of onboard systems to determine weight and 

balance" as well as require the retrofitting of this equipment to existing aircraft when technically 

feasible (van Es, 2007, p. 20). 

Van Es described the general design of an automatic aircraft weight and balance system using axle 

strain gauges on the nose and main landing gear, along with measurements of the aircraft's attitude 

on the ground, to estimate the weight and CG of the aircraft. Design standards, including those for 

accuracy and reliability (see the discussion of FAA AC 20-161, below), have established 

demanding criteria if the automatic system i to serve as the primary source of weight and balance 

information (e.g., using the automatic system to replace the usual methods of building up the 

aircraft's total weight from the weights of the individual components such as cargo and fuel, and 

the aircraft's CG from the loaded positions of these individual weight components). These criteria 

for use as a primary system are the ones that have been difficult to design and implement; the 

Netherlands Aerospace Laboratory (NLR) noted , however, that automatic weight and balance 

systems exist on some transport aircraft types and are available as a secondary source of weight and 

balance data (van Es, 2007). Finally, van Es proposed that an alternative automated system could be 

one that would: 

"rapidly weigh and automatically track passenger and baggage weight and location 

data as passengers board aircraft. The rapid development in different technological 

advances such as hand-held devices and wireless bar code scanners indicate that it may 

be feasible to compile actual weight data and account for the weight location , which 

can result in a reliable calculation of actual aircraft weight and balance" (p. 22). 

14 

--. ---- ---
The FAA provided guidelines for onboard aircraft weight and balance system in Advisory Circular 

20-161 (FAA, 2008). In this document, the FAA conceived of the automated sy terns as replacing 

current methods based on calculating the weight and balance of the entire aircraft from the weights 

and locations of the individual load elements; as we have mentioned, this replacement would 

require high precision and accuracy. The Advisory Circular provides the levels of accuracy, 

reliability, and failure tolerance required for these automated systems to serve as the primary source 

of performance data as well as acceptable methods for installation and testing to obtain approval as 

well as for operating these systems in practice. 

In a June 15,2004, final report, the Human Factors-Harmonization Working Group of the FAA and 

Joint Aviation Authorities (HF-HWG, 2004) proposed that the FAA take regulatory action and 

provide additional guidance material to enhance the consideration of flight crew performance and 

error in the certification of all related equipment and fumi hings installed in newly certificated 

transport aircraft design. This would appear to include equipment such as laptop computers, EFBs, 

and FMS that is used in the performance data processes, including those for error trapping and 

discrepancy resolution. In response, on February 3,2011, the FAA published a Notice of Proposed 

Rulemaking seeking to establish 14 Code of Federal Regulations Part 25.1302. This proposed 

regulation states, in part (FAA, 2011): 

Flight deck controls and information intended for the flightcrew's use must: 

1. Be provided in a clear and unambiguous manner at a resolution and precision 

appropriate to the task. 

2. Be accessible and usable by the flightcrew in a manner consistent with the 

urgency, frequency, and duration of their tasks. 

3. Enable flightcrew awareness, if awareness is required for safe operation, of the 

effects on the airplane or systems resulting from flightcrew actions. 

Operationally-relevant behavior of the installed equipment must be: 

1. Predictable and unambiguous. 

2. Designed to enable the flightcrew to intervene in a manner appropriate to the 

task. 

To the extent practicable, installed equipment must incorporate means to enable the 

flightcrew to manage errors resulting from the kinds of flightcrew interactions with 

the equipment that can be reasonably expected in service. 

The FAA received comments on the proposed rule until April, 2011 . Final rulemaking is in a 

pending status. 

Three recent serious incidents related to performance data error, discussed below, were investigated 

and reported on by the Air Accidents Investigation Branch (AAIB) of the United Kingdom and 

provide additional information about air carriers' establishment and use of error-trapping routines 

in standard operating procedures as well as pilots' performance of these routines in practice. 

Airbus A330-243, G-OIMC, October 28,2008, Serious Incident Report (AAlB, 2009a). Unable to 

use their normal tabular method for determining performance data , the flight crew requested that 

the dispatch department perform the calculations. The captain provided the information needed by 

the dispatcher over the telephone and the dispatcher provided the takeoff performance data , 

15 
I 

I 

i 

I 

I 

including V -speeds, also by phone. The captain then handed the telephone to the first officer who 

independently obtained the takeoff performance data from the dispatcher. The two pilots compared 

the performance data and they were identical. 

For unknown reasons the dispatcher had used a GTOW of 120.8 metric tons rather than 210.2 

metric tons. The performance calculations based on the lighter weight resulted in a Vr speed that 

wa 26 knots slower than the proper speed. The aircraft experienced degraded climb performance 

and handling during rotation and initial climb. The captain perceived that the performance was not 

correct and he engaged full thrust for takeoff which helped the aircraft complete the takeoff and 

climb maneuvers safely. 

The investigators learned about several missed opportunities for checking for errors and catching 

the dispatcher's mistake. The system used by the dispatcher 

"was capable of calculating the aircraft's [best lift/drag] speed. The aircraft's [FMS] 

also calculates [this] speed independently of the performance figure provided by [the 

dispatcher] , and so this could be used as a gross error check, provided that the same 

takeoff parameters were input to both systems. [However], the function to calculate 

the [best lift/drag] speed had, for an unknown reason, been disabled on this 

operator's [dispatch-based] system and they had no procedure requiring the 

[dispatch]-generated ... speed to be passed to crews" (p. 3). 

Significantly, review of the flight data recorder data after the incident revealed that the aircraft's 

actual weight and CG were automatically sensed and calculated by the aircraft's on board 

equipment. The correct data were passed to the flight recorder for post hoc use by the accident 

investigators ,but not to the flight deck displays or flight crew. 

Airbus A340-642, G-VYOU, December 12, 2009, Serious Incident Report (AAIB, 2009b). The 

airline's performance data process involved the pilots entering aircraft weight and loading data into 

the ACARS for transmission to the central load planning computer, with performance weights and 

speeds returned to the flight deck (also by ACARS) , then manually transferred to the FMS by the 

pilots reading from the ACARS screen and typing into the FMS. There was a late change in the 

load and this disrupted the crew's preflight preparations and required them to obtain a new flight 

plan and delay their inputs to the ACARS system for transmission to the central computer. A pilot 

then mistakenly entered the aircraft's landing weight instead of its TOW into the ACARS, which 

caused the central load planning computer to generate incorrectly low V -speeds and reduced thrust 

values. The pilots discussed what appeared to be an abnormally low thrust value calculated by the 

central computer but they did not resolve the issue . The weight entry error was not detected in 

either the automated central functions or during the flight crew's entry and review of the data . The 

aircraft was rotated early and had inadequate airspeed and climb performance during the initial 

climb. Later, the pilots realized the error upon review of their ACARS inputs to the central 

computer. 

The investigation revealed that this airline had incorporated several error traps into its standard 

operating procedures (SOPs). The operator's SOPs required crews to request the performance data 

from the central computer, using the estimated weight, but to refrain from entering the centrally 

calculated V-speeds and other data into the FMS. Then, after the finalloadsheet was received, the 

actual TOW would be verified against the estimated value used for the performance data request 

before being entered into the FMS. 

16 
The SOPs also required the loadsheet procedures to be led by the captain and checked by the fust 

officer and the performance data request procedure to be led by the fir t officer and checked by the 

captain . According to the incident report, "Nine independent cross-check were built into the 

procedures including a requirement for the actual TOW to be written on the [performance data] 

printout alongside the TOW used for the calculation to provide a gross error check" (p . 2). 

However, as the AAIB observed: 

"The late change ... disrupted the usualloadsheet and performance procedures, which 

were conducted out of sequence. Because of the late change , the crew decided not 

to calculate an estimated takeoff weight for an initial [data] request, preferring to 

wait for the loadsheet to use the actual value. The landing weight entered in the 

takeoff weight field of the [data] request would have been acceptable as a takeoff 

weight on the Airbus A340-300, which the crew also flew. The operator considered 

that this might have been why the crew was not alerted to the error. Because no 

[data] was reque ted using an estimated takeoff weight, no gross error check could 

be made against the loadsheet takeoff weight" (p. 2)." 

Airbus A321-211, G-NIKO, April 29, 2011 , Serious Incident Report (AAIB, 2011). During preflight 

preparations, the captain mistakenly read the ZFW value on the load sheet as the TOW, transferring 

the incorrect figure to the navigation log as required by company procedures as well as vocalizing it 

to the first officer. Procedures then required the captain to compare this actual TOW value (which 

was incorrect) with the estimated TOW already printed on the log. However, he mistakenly 

compared with the estimated ZFW on the log, allowing him to believe he had satisfied this crosscheck. The captain then correctly entered the ZFW into the FMS (the FMS was designed to accept 

only the ZFW) so the FMS ' s internal weight and V -speed calculations would have been correct. 

Despite the correct data being in the FMS, procedures required the crew to enter the TOW into a 

laptop performance computer to obtain V-speeds and other performance data. In this case, the 

captain entered the incorrect TOW and obtained a Vr speed value more than 20 knots slower than 

the correct value for the aircraft's actual weight. The first officer was required to perform an 

independent calculation of the V -speeds using the laptop, with the two pilots comparing their 

results, prior to manually entering the' performance data into the FMS. The incident report does not 

detail whether this independent cross-check procedure was performed by the crew but the first 

officer had obtained the same incorrect value for TOW from the captain. The airline had established 

a final error-trapping procedure for the crew, prior to departure , to cross-check the best lift/drag 

speed calculation by the laptop (which would have been using the incorrect weight) against that 

calculated by the FMS (which had the correct weight and would have calculated a much faster 

speed). However, the pilots apparently omitted this procedure. 

During takeoff rotation the flying pilot noticed that the stick felt heavy and also that the flight deck 

display of minimum safe speed was increasing rapidly (this value is calculated by the FMS using 

angle-of-attack information that is only available in flight). In response, he reduced the aircraft's 

pitch attitude to gain airspeed more quickly. The aircraft climbed slowly but achieved a safe altitude. 

Finally, in the report of its investigation of the March 20 , 2009 , A-340 accident at Melbourne , 

Australia (ATSB, 2011), the ATSB provided a detailed description and analysis of multiple errortrapping procedures that the air carrier had established (similar to those identified in the above 

incidents). The investigators found that none of these procedures trapped the pilots' entry of an 

17 
inconect weight value into their laptop performance computer, which then propagated to incorrect 

V -speeds, premature rotation, tailstrike, and severely degraded climb performance. 

Con idering human factors related to the reliability of enor-trapping procedures, the ATSB 

determined that distractions during preflight preparations from competing operational tasks and 

interruptions by other personnel may have been factors in the pilots' failure to perform some of the 

procedural cross-checks. Further, the pilots' expectations that the calculated performance values 

would be conect may have been factors in their failure to catch the inconect value. In one of 

several instances in which the error could have been trapped , a cross-check between the weight 

value in the FMS and the corresponding value they had copied from the laptop to the company 

flight plan form, one pilot vocalized the inconect weight value that he read from the flight plan 

form but quickly "corrected" the value into a weight that was more consistent with their 

expectations and nearly matched that in the FMS (p. 81). The ATSB summarized: 

"the crew's non-detection of the enoneous takeoff weight entry in the EFB was 

multifaceted, and reduced the effectiveness of the procedural checks that could, 

individually, have detected the enOL It is possible for errors to pass undetected 

through various checks, which is why most procedures incorporate multiple 

independent checks to verify critical information" (p. 82-83). 

Considering the set of enor-trapping procedures as a system and its overall reliability and 

effectiveness, the ATSB stated: 

"The conduct of the takeoff weight comparisons within the takeoff performance 

error check, takeoff data check, and loadsheet confirmation procedure, within a 

relatively short period of time, may have been perceived by flight crew as redundant. 

Given that on the accident flight, the takeoff performance calculation was based on 

the final, and therefore unchanging weight figures, the risk that the three, close 

proximity checks might appear superfluous was heightened. That might explain to 

some extent why only the finalloadsheet confirmation procedure was completed . 

Standard operating procedures are typically designed on the basis that information 

flow into the cockpit is sequential and the procedures are conducted in a linear 

fashion based on this sequential information flow. Research has shown that the 

information flow into the cockpit during line operations typically does not follow the 

sequence upon which the procedures are based. This increases the likelihood that, 

following a distraction, the flight crew will re-enter a procedure at an inconect point. 

The sequence of delivery of information may also lead the crew to believe that a 

check is no longer required" (p. 86). 

This literature review reveals that many aspects of the problem of using incorrect load and 

performance data have already been examined, with largely consistent findings. Consequently, we 

decided to focus our own study on aspects not thoroughly explored previously. In the Discussion 

section we will draw upon both our own findings and these previous studies to propose practical 

ways to reduce vulnerability to errors and ways to mitigate the consequences of enors. 

3. Method 

To extend our knowledge of how airlines generate and use load and performance data , we contacted 

personnel from five airline (a regional turboprop operator, two large worldwide passenger carriers, 

and two large passenger carriers). These individuals helped us develop descriptions of the flow of 

information in the overall system, the specific step involved, and the persons who normally 

18 
perform tho e teps. The discussions also helped us identify error vulnerabilities, and procedures 

and equipment used to catch errors. 

To gain information beyond that provided by the accident and incident case tudies de cribed in the 

previous section, we also developed a database of related events from information in the ASRS. 

The ASRS is a voluntary U.S. system that allows flight crews, air traffic controllers, maintainers, 

flight attendants, and operations personnel to confidentially report issues regarding safety . The 

information provided in these reports cannot be used by the FAA as evidence for regulatory 

violations or sanctions. Further, personnel who provide an ASRS report receive immunity from 

sanctions that the FAA may assess related to a violation case (based on other evidence) for the same 

event as long as the violation was unintentional and did not involve an aircraft accident or criminal 

act. The ASRS received over 37,000 reports in the year 2QOO and over 48,000 in 2009 - the time 

period accessed for this study (J.B. Moya, ASRS, personal communication, February 15 , 2011 ). 

3.1 Study Scope, Keyword Search, and Sampling 

Our goal was to obtain event descriptions involving errors in entering , calculating , handling, 

transmitting, receiving, executing, and applying all of the data elements of aircraft weight, balance 

and performance information. We wanted to include procedures, actions taken or not taken by any 

person in the system generating or using this information. To obtain a large enough cross-section , 

we defined the scope for our data search as U .S. Part 121 (scheduled passenger and cargo) air 

carrier operations from January 2000 through October 2009. To obtain cases related to aircraft 

performance data, we searched the narrative and synopsis fields of all of the ASRS reports within 

this scope using the keyword search terms: 

• Weight OR Wt Or Bal% And Error 

• ZFW OR "Zero Fuel" 

• Rotat% AND (Weigh% OR Set%) 

• Vr 

• Laptop 

Note: The use of partial words and the H%" symbol in the keyword searches allowed 

the ASRS search engine to identify relevant cases despite variations in word endings 

in the database entries. 

These keyword-based selection criteria were not mutually exclusive (duplicates had to be 

eliminated manually) and not exhaustive of all cases within the ASRS database that would have 

been relevant to our study . However, from review of the reports obtained using these criteria, these 

selections appear to provide a reasonable cross-section of the performance data errors in the ASRS 

database . 

The ASRS accepts reports from a wide variety of personnel functions within the airline industry, 

although not from the load planning, load control, ramp , gate, and station operations personnel who 

perform most of the ground functions related to aircraft performance data. We specified the 

selection of this set of events to comprise reports provided by the following positions and job 

functions as defined by the ASRS: 

• Captain/Pilot flying 

• Captain/Pilot not flying 

• First Officer/Pilot flying 

• First Officer/Pilot not flying 

19 

--- .~-~------ -.--~-- --- - - ---- --~-- .---
• Flight Engineer 

• Company Dispatcher 

• Check pilot 

• In tructor 

A total of 1,116 ASRS reports met the keyword and reporter selection criteria. Review of those 

reports revealed that many did not actually involve performance data errors. Accordingly, one of 

the authors, an airline pilot, evaluated each report for relevancy, resulting in 246 reports after 

deleting duplicates. From this set, a random sample of 100 reports was selected as the database for 

statistical analysis. We used the remaining 146 reports that met the selection criteria to provide 

additional illustrative example in the ections that follow. 

3.2 Error Identification 

The 100 ASRS reports in the analytical sample were reviewed by one of the authors (an airline 

pilot) to identify discrete errors described by the reporter in the narrative and synopsis text sections 

of the ASRS report. The process of error identification was reviewed by another author (a human 

factor researcher) and the two authors used a discussion and resolution procedure to converge on 

and reach agreement on a total of 112 errors in the 100 cases. 

3.3 Variable Definition and Coding 

For each of the 100 reports in our database, we supplemented the data elements that the ASRS 

codes in its database (for a detailed list of these, see ASRS, 2012) with several of our own data 

elements or variables. One of the authors, an airline pilot, coded values for these variables based on 

review of the narrative and summary text of each ASRS report. 

The locus of error: classifies the place in the performance data process where the error occurred as 

being either among ground personnel performing functions external to the flight deck or the flight 

deck personnel (all of the latter were pilots in these cases). 

The subcategory of personnel: codes the ground locus of error, for those reports for which more 

detailed information was available, into central load planning (based at the airline's headquarters or 

one of its operational centers), station operations (an office located at the airport from which a flight 

departs or arrives), and ramp/gate personnel who process passenger boarding, process baggage and 

cargo loads, and service the aircraft at the station. 

The process step, actor, and type of error: identifies the place in the airline performance data 

process at which each error occurred. Based on our discussions with airline personnel and our own 

industry knowledge and experience, we first developed a list of the steps involved in generating 

performance data, transmitting them to the flight crew, entering them into the FMS, and setting 

flight deck controls based on these data. The process steps that we identified were: 

• Forecast load limitations (e.g., weight restrictions). This function is performed by ground 

personnel, usually several hours prior to departure time. It involves using the passenger 

pre-bookings, planned baggage count based on the number of booked passengers, 

anticipated cargo, the aircraft's ba ic operating (empty) weight, weather at departure and 

arrival stations, and predicted runway and other environmental factors to forecast the 

maximum allowable TOW for the flight and whether the planned load can be 

20 
, 

~ .. ---------

! 

accommodated. If not, the load will be adjusted as required through a weight restriction 

(maximum load value) being assigned to the flight. 

• Reviseforecasts based on changes in weather, temperature, runway,fuel requirements. 

Closer to the time of departure these factor that can affect the maximum TOW (and 

consequently the load that can be accommodated on the flight) must be reviewed for 

changes and any weight restrictions must be adjusted accordingly. For example, if the air 

temperature increases, the aircraft's engines will not develop as much thrust and its wings 

will not develop as much lift, therefore the load limit may have to be revised downward . . 

• Obtain actual cargo weights. Before departure time the cargo that is planned to be 

loaded aboard the flight is aggregated and separated from that assigned to other flights, 

usually in a facility that is remote from the ramp area where the aircraft is parked. The 

cargo is placed on carts, pallets, or inside containers as appropriate for the aircraft. 

These load units are weighed or the weight of each unit is summed from the weight of 

each cargo item included. The weights of the individual items are derived either by 

weighing them at the cargo facility or by using the weight of each package or container 

that is listed in its shipping papers (reflecting that the items were weighed earlier, such 

as at their point of origin). 

The cargo units that are to be loaded onto the aircraft are listed on a cargo manifest (paper 

form or computer file) that is tran mitted to the loading ramp either with the cargo itself or 

by other means. Individual pieces of cargo may be scanned before being containerized or 

placed in carts and the entire unit or container may be scanned to facilitate tracking. 

The total weight of cargo destined for each bin in the belly of the aircraft is transmitted 

(by manual entry on a form, manual entry in a computer, or automatically by the cargo 

load control system) to the ground personnel or pilots who will be using the cargo weight 

to derive the weight and CG (balance) of the aircraft. Passenger baggage may be 

aggregated, unitized, documented, and delivered to the aircraft in a similar way, although 

it is usually not weighed; instead, most airlines have approval to use an average weight for 

each piece of baggage so either at this point in the process or in the calculation step (see 

below) the total baggage weight is derived by multiplying the approved estimated average 

weight by the number of pieces. Baggage counts are also subject to last-minute changes as 

late-arriving passengers enplane, others miss their connections, etc. 

• Obtain actual passenger counts/weights. As passengers board the aircraft at the gate their 

boarding passes are collected; scanned, manually entered into a computer, or checked off 

a list to reflect actual boarding; and then reconciled against the list of booked passengers 

to verify that the passenger is boarding the correct aircraft. The total count of boarded 

passenger is transmitted (by manual entry on a form, manual entry in a computer, or 

automatically by the passenger boarding control system) to the ground personnel or pilots 

who will be u ing the count to derive the weight of the passengers. As with baggage, most 

airlines use an average passenger weight approved by the FAA so the total weight of the 

passenger load i derived by applying this approved estimated average value to the 

passenger count. 

• Calculate weight/balance values. Prior to takeoff, the aircraft's weight and balance values 

are calculated for use in subsequent performance calculations. If they are not 

automatically transmitted from the earlier functions of counting or aggregating the loads 

(see above), the individual components of the load (passengers, baggage, and cargo) are 

manually entered into a calculator, computer, or tabular reference by the ground personnel 

or pilots performing this function. The weight of these loads are added together with the 

21 
r 

basic operating weight of the aircraft to derive the ZFW of the aircraft. The weight of the 

fuel is derived from fuel quantity indicators and/or by multiplying the planned fuel load in 

gallon by the weight of fuel per gallon. The urn of the ZFW plu thi fuel weight (less 

the fuel weight planned to be consumed during taxi-out for takeoff) is the GTOW. For 

further performance-planning purpose, the projected gross landing weight (GLW) is 

derived by subtracting the fuel weight that is planned to be used from takeoff to landing 

from the GTOW. 

Similarly, each component of weight to be loaded aboard the aircraft is combined with information 

about its planned location on the aircraft to derive the CG position, or balance, of the loaded 

aircraft. Separate balance calculations are made for the aircraft's status at takeoff and landing (the 

difference being the burn off of fuel during the flight). Ground personnel or pilots perform the 

balance calculations using hand calculations, tabular references, calculators, or computers. The 

calculated weight and balance values are then entered manually, or automatically transmitted, to 

those persons performing the next steps of the process: 

• Verify weight/balance against performance limits. Prior to takeoff, the weight and balance 

values must be compared to the limitations that were established for safe operation of the 

aircraft by the aircraft manufacturer and certification authorities. Some of the relevant 

comparisons are the calculated ZFW against the maximum ZFW hmit (which provides 

safe margins for the aircraft structure, such as wing/body attachments and landing gear); 

calculated GTOW against the maximum GTOW limit (which constrains allowable TOW 

for the specific runway length, wind, temperature, and obstacles in the area to assure safe 

margins in the event of contingencies such as engine failure); calculated GLW against the 

maximum GL W limit (which provide safe margins for the structural load imposed by a 

hard landing); and calculated CG position against the forward and aft CG limits (which 

provides safe margins for aircraft stability and control). 

These comparisons may be performed by ground personnel or pilots u ing manual 

methods (e.g., comparing the calculated ZFW to a memorized maximum ZFW limit), 

automation (e.g., a computer program that accounts for the effects of winds and 

temperature on takeoff performance and checks the aircraft's climb gradient over prestored obstacle positions and heights for both all-engine and engine-failure 

contingencies), or a combination of these methods. Each calculated weightlbalance 

value must be re-checked against its respective limitation whenever a load element 

changes (e.g., last-minute addition of ten passengers in the aft section of the cabin) or 

an environmental factor changes (e.g., air traffic control assigns the flight to a different 

runway for departure). 

To prevent large workload increases from being imposed by very small changes, many 

airlines have established an allowable variance for changes below which the limitations 

need not be re-checked in order to streamline operations. To use this system, the airline 

reflects assumptions of additional weights of various load elements and locations on the 

aircraft in its performance calculations for the flight, providing an additional buffer to 

safety margins that can be used up to the limits of what was assumed in the calculations 

and informs its personnel of the thresholds beyond which the provided calculations cannot 

be used (e.g., no more than 110 passenger in the aft cabin or maximum allowable 

increase in GTOW of 12,000 pounds). (Airlines should be careful to emphasize to 

personnel that changes greater than threshold values must be re-checked, lest a cavalier 

attitude about re-checking in general emerge.) 

22 
• Calculate V-speeds, trim settings, engine thrust, and flap setting. Prior to departure , the 

calculated weightlbalance and the known environmental values are used to derive the 

information that the pilots need to apply to the upcoming takeoff: the V -speeds they will 

use to make the reject/continue decision for an engine failure during the takeoff roll (VI), 

rotate the aircraft at the proper time to provide the required runway and climb 

performance (Vr) , and climb safely in the event of an engine failure (V2); the trim setting 

for the horizontal stabilizer that will provide controllability during rotation/climb; the 

engine thrust value that will provide the required runway and climb performance (most 

takeoffs are performed with the thrust reduced below the maximum available from the 

engines to reduce aircraft noise and wear on the engines); and the flap setting that will 

configure the wing to provide the needed lift at the planned rotation and climb speeds. 

These values are obtained or calculated by ground personnel or pilots using tabular 

references or computers. 

• Transmit weight/balance, V-speeds, and control settings to the flight deck. If the values 

derived from the above calculations are not performed by the pilots, these data must be 

provided or transmitted to the flight deck prior to departure. This can be done by 

handing a paper form, such as a load manife t that includes these performance data, to 

a pilot before cIo ing the passenger entry door. Alternatively , it can be uplinked to a 

flight deck printer or an electronic display to be viewed by the pilots or, in some 

installations, uplinked directly to the FMS to be reviewed and accepted by the pilots 

without manual entry. 

• Enter weight/balance values into FMS. If the weight and balance data (e.g., ZFW, GTOW, 

CG location) are not uplinked directly into the FMS, they must be manually entered by a 

pilot who visually references the source for these data on the flight deck (e.g., printed load 

manifest, onboard laptop performance computer, or other display unit), locates each 

desired data element (e .g., ZFW) on the source document, then manually enters the same 

number into the FMS using its keypad (to enter the number in a scratchpad) and soft keys 

(to direct the number that was keyed into the scratchpad into the data field reserved by the 

FMS for that same data element such as the second line on the left-hand side of the FMS 

display, for ZFW). We note, and will discuss later, that some airlines' procedures require 

the pilots to enter the forecast weight data (see above) into the FMS early in the pre-flight 

preparations to facilitate FMS entries and calculations then override these values with the 

final weight data that are subsequently provided just before pushback or during taxi-out. 

• Enter V-speeds, trim settings, runway temperature,flap setting, etc., into FMS. Prior to 

departure, the pilots must use their source documents to enter the e data into the FMS a 

well. Some FMS are capable of internally calculating approximations to the V -speed 

values based on pre-stored data about performance as a function of weight and other 

variables. For these, depending on how the airline has established its procedures, the pilots 

are required to accept/reject the V -speed suggested by the FMS or override these 

internally generated values with manual keyboard entries . 

• Set bugs. On aircraft equipped with advanced FMS and electronic flight displays, the Vspeeds will be automatically marked on the airspeed displays for the pilots to call out and 

use during takeoff. Other aircraft may be equipped with "bugs" (adjustable internal 

pointers or moveable external plastic markers) that the pilots manually position around 

their airspeed dials to mark the critical V -speed values. 

• Set trim. Trim values received or calculated on the flight deck must be manually set on the 

aircraft' horizontal tabilizer by manually turning the trim wheel or operating electlic 

23 
trim switches. To do this the pilot visually references the de ired trim value reflected on 

the performance data source document and operates the trim control to match the trim 

indicator (a gauge, pointer, or digital display reflecting the actual position of the 

horizontal stabilizer) to the desired trim value. 

• Set flaps. Similarly, the flaps mu t be extended prior to departure to the etting that will 

provide the required takeoff performance as specified in the performance data calculations 

received or calculated on the flight deck. To do this the pilot visually references the 

desired flap setting reflected on the performance data source document and moves the flap 

control to match that setting, also cros -checking the flap indicator (a gauge, pointer, or 

digital display reflecting the actual position of the flaps). 

For each of these process steps, we identified the actors, or job functions, who might be involved in 

that step of the process (e.g., ramp agent, gate agent, central load planner, station operations agent, 

or pilot). The specific actor who performs each function varies depending on how each airline 

designs and implements its procedures and systems. (See Figures 1-3 in the Results section for a 

depiction of three variations in airline performance data system designs.) We then developed a list 

of the types of errors that might in principle be made by the actors in these process teps, reflecting 

our own knowledge of the process and discussions we held with airline personnel. The error types 

(e.g., failure to enter, erroneous entry, failure to cross-check) are descriptive . We attempted to be 

comprehensive, though of course we may have missed some steps in the process (at a very detailed 

level) and some types of error. For each error we coded the step of the process where the error 

occurred, the actor committing the error, and the kind of error. The matrix of process steps, actors, 

and error types reSUlting from this evaluation is provided in Table 3 in the Results section. 

Error trapping was coded for each error in several ways. An error was coded as having been 

trapped if it was caught and corrected before the flight was exposed to the risk generated by the 

error. For example, an incorrect flap setting was considered to have been trapped if the flaps were 

reset to the correct extension prior to takeoff, which is when an incorrect flap setting can lead to 

tailstrike, inability to climb, etc. . 

For those errors in the sample that were trapped, we identified and coded whether the trapping was 

performed by: 1) the actions of personnel who were following established procedures (procedural 

trapping); 2) the actions of personnel not specifically mandated by established procedures (nonprocedural trapping); or 3) the functions of technological systems as they automatically trapped 

errors or enabled personnel to trap them (technological trapping). 

To identify an upper boundary for the potential contributions of error trapping functions in the 

performance data processes, we also subjectively evaluated whether each error could have been 

trapped by procedural or technological interventions. For these latter two codings, one of the 

author performed an informed, subjective evaluation by considering the full range of current 

procedural cross-checks, verifications, and checklists as well as technological automatic errortrapping, warning, and alerting systems either known to be in current use or projected in the 

literature to be a possible future development. (We included only future systems that are in 

principle well within current technology capabilities-no far-out systems only generically 

envisioned.) The criterion for coding an error as "trappable" by procedural means was that anyone 

or combination of the current or potential procedures would have trapped the error if the procedure 

had been properly established and were reliably executed. Similarly, the criterion for coding an 

error as "trappable" by technological means was that anyone or combination of current or potential 

24 
----~---~~ 

systems would have trapped the error if these system were properly designed , functioned reliably 

in actual use, and operated properly and reliably by the personnel interacting with them. 

The role of cognitive and other human factors in these errors was evaluated subjectively by two of 

the authors (an airline pilot and a human factors researcher) using the case narratives and synopses 

for each report. The coding results were compared and any differences in coding were discussed 

until agreement was achieved. Coders decided whether any of the following contributed to the 112 

errors: the discrepancies related to the error not being salient to the persons involved; time pressure 

in the situation at the time of the error that was recognized by the persons involved; rushing; failure 

to cross check; disruption of a normal habit pattern, a normal habit pattern interfering with the need 

to perform an unusual action (habit capture); expectation bias; fatigue; momentary workload spike 

at the time of the error; distraction from other stimuli or events at the time of the error; prospective 

memory failure; failing to respond proactively; and confusion. 

We further evaluated each error as to whether the persons making the error had received incorrect 

information from an earlier step in the performance data process. For example, a pilot's entry of the 

wrong V -speed into the FMS was coded as being based on incorrect information if the V -speeds 

were calculated using incorrect weight values provided to that pilot by another person or an 

automated system. 

We made a separate evaluation for each error a to whether it involved late or revised perfo.rmance 

data. This was a subset of incorrect information. For example, a flight departed with the wrong Vspeeds because the final or revised weight was not received on the flight deck until after takeoff. 

Erroneous use of preliminary data was coded if the flight departed using the preliminary 

performance data for weights and/or V -speeds (produced during the flight planning process and 

sometimes used on the flight deck to streamline operations) rather than the updated performance 

data based on the final passenger counts, baggage counts, cargo weight, and other load elements. 

We evaluated the consequences of each error by coding each error into one of five categories, 

using an informed subjective projection of the actual potential effects of the performance error 

upon flight safety: 

• Major adverse consequences-coded to errors that resulted in aircraft damage (e.g., tailor 

fuselage strike on runway); handling/controllability problem (e.g., uncommanded pitch-up 

prior to Vr or difficulty rotating the aircraft at Vr); significantly reduced performance (e.g., 

aircraft lifted off near the end of the runway, climbed sluggishly, was unable to maintain 

safe minimum airspeed at the planned cruise altitude, or landed hard); or violations of 

aircraft structural or performance limitation leading to potential damage or reduced safety 

margins in the event of contingencies, such as turbulence or engine failure, that fortuitously 

did not occur on the subject flight. 

• Minor consequences that could have been major in other circumstances-coded to errors 

that had no actual major adverse con equences but given changed circumstances such as a 

shorter runway the consequences likely would have been major. 

• Minor consequences-coded to errors that we evaluated as having no likely major adverse 

consequences under all conceivable circum tances. 

• Trapped-coded to errors that were caught and corrected prior to the flight being exposed 

to the consequences of the error. 

25 

I 

I 

I 

I 

I 

~ 
• Linked to additional error-for those 12 cases in the sample in which we identified two 

distinct errors, the first error in the sequence was given this coding if the consequences in 

the case were not realized until the econd enor was committed. The consequences for the 

case were coded to and represented by the second enor in the sequence. 

4. Results 

4.1 Information from Airlines 

We talked informally with personnel from five airlines-a regional turboprop operator, two large 

worldwide passenger caniers, and two large passenger carners-to gain insight about their 

concerns about generation and use of incorrect load data and procedures to prevent and trap errors. 

The information from these discussions is summarized below. 

4.1.1 Counting/Weighing 

At one airline, a regional turboprop operator, a flight attendant provides the pilots with a passenger 

count by manually marking the occupied seats on the form and writing the total at the bottom of the 

form. The flight attendant is required to have compared this onboard count with the count provided 

by the gate agent, resolving any discrepancies before bringing the form to the flight deck. For the 

baggage and cargo weight values, "cargo planning" personnel provide the e data to the flight deck. 

The planned values are provided about 30 minutes plior to departure and an update of final values 

is provided about 10 minutes prior. 

At another airline, a large worldwide passenger carrier, the overall load control process flow begins 

with the gate agents scanning or manually entering the number of boarding passengers into a 

computer (depending on the station 's equipment). Under the automated system, the gate agents are 

required to reconcile the passengers who have checked in but not boarded: Are they wandering in 

the terminal or are they aboard the airplane without having been properly entered? The agents must 

resolve the issue. They eliminated the flight attendant's passenger count several years ago in favor 

of the reconciliation provisions of the new system. 

At this airline the cargo and baggage counts/weights are scanned or manually entered. This may be 

done miles from the aircraft in a remote cargo facility. Checked-in items are uplinked to a central 

load document, the "staging guide." This provides a payload value for dispatchers and load 

planners to use for flight planning purpo es. As part of the automation process the company 

established a cutoff time for accepting cargo and baggage, as opposed to the previous system in 

which they accepted baggage and cargo right up to departure time. This has been a great aid in 

reducing errors because it relieves time pressure and reduces the opportunity for error on the ramp. 

The cargo staging document that was prepared remotely is then printed at the ramp and the ramp 

agents are required to reconcile the items that are physically present on the ramp, prior to loading, 

by checking off each item on the list. A ramp agent will lose his job if he intentionally loads 

something that is not on the loading sheet. (We note that this is a strong incentive not to 

intentionally load items incorrectly to save time, but of course it does not prevent unintentional 

enors of this sort.) If an item on the sheet is not loaded, or if it is removed from the aircraft prior to 

departure, the computer system will not allow that item to be recorded as loaded on another aircraft 

until it is removed from the staging guide for the original flight. 

Reconciliation of actual load with documented load is accomplished by recording the bin number or 

marking a "hold off code" if the item is not to be loaded , including the reason it was withheld from 

26 
the aircraft (time, space, damage, etc). Then , the ramp per onnel can attempt to finalize the 

document on the computer terminal. The load is considered yalidated if all the asterisks by the 

individual item have been changed to bin numbers or hold off codes. The document cannot be 

finalized for flight release until this is accomplished. This process is much more organized than it 

used to be at thi airline. The computer checks all cargo related limits (bin weight limits, CG, etc.) 

and then it will let the ramp supervisor electronically sign the document. 

At another airline, a large passenger carrier, the process begins with a load planner in central load 

planning/dispatch producing a load plan for the lead ramp agent to use for loading the aircraft. 

When the warehouse accepts cargo it is weighed at that location. The weight is entered on a cargo 

manifest and the weight of the item is combined with weights of any other items on the cart to make 

up the cart weight. With the cart weights e tablished the station can then load the aircraft according 

to the load plan. If there is a change during the loading process-such as the captain deciding that 

more fuel is required, necessitating removal of some cargo to offset the weight of the fuel-the 

ramp agents can look up the weight of the cart(s) to be offloaded and adjust the load plan. 

The flight crew receives final numbers including the aircraft's basic aircraft operating weight plus 

accepted cargo. The lead agent then tallies the 'bag count (regular/heavy/gate-checked) and cargo by 

bin location using a handwritten form and radio§ the cockpit with. the counts. The lead agent calls 

the crew back with any changes after all doors have been closed. The passenger count comes from 

the gate agent. The flight crew enters the data (basic operating weight plus cargo weight, bag count, 

and passenger count) in a laptop performance computer and then finally enters the performance data 

(ZFW, V-speeds) in the aircraft' flight management computer (FMC). 

One captain from this company feels that having a direct voice connection from the ramp to the 

cockpit for the final numbers avoids the confusion and delay that can arise from working through 

an intermediary (such as central load planning or local station operations). It is possible, though , 

that an error could creep into the system as the bag and cargo numbers are passed from the agents 

doing the loading to the lead agent who provides there numbers to the cockpit. 

At another airline, a large worldwide passenger carrier, the pilots obtain the planned values for 

payload , ZFW, fuel load , and GTOW on the flight plan they receive from the dispatch 

department. There is a central load planning function that performs all of the performance 

calculations and generates a weight manifest document, including performance weights and Vspeeds, to the flight deck printer by ACARS prior to pu hback. The pilots are not required to 

reconcile differences between the planned weight values on the dispatch release and the final 

weight values on the weight manifest. 

At most stations the passenger count is produced automatically as a result of the passenger boarding 

documents being scanned at the gate. The pilots receive a passenger load reconciliation document 

via ACARS message to the flight deck printer. The procedure for flight attendants to perform a 

passenger count has been eliminated where this automated passenger-boarding control and 

reconciliation system is operational. At other stations, the flight attendants are required to provide 

the pilots with a passenger headcount. Where performed, the pilots are required to use the flight 

attendant count to make performance data adjustments but they are not required to reconcile 

differences between the flight attendant count and the one generated by the central load planning 

system as shown on the weight manifest. 

27 
I 

I 

4.1.2 Calculating 

At the regional turboprop airline, the pilots use a company-tailored handheld computer to enter the 

passenger counts and cargolbaggage weights and obtain aircraft weights/V-speeds. At another 

airline , one of the large international passenger carriers, the calculations are performed in the 

central load planning department/function. The central load planning computer must receive 

closeout messages from the gate and ramp before it can generate the final performance data for 

transmission to the pilots. The airline allows the flight to push back and begin taxiing while the 

clo eouts are being received and the final data are being prepared. 

Since 2005, this airline has been using an automated weight and balance system. It has 32 

automatic checks before it will allow the final weight form to be sent to the cockpit. These 

include checks of all load limitation and CG. Humans are not involved in the system except on 

an "exception basis" such as a fuel system minimum equipment list (MEL). The automated 

system would tum on a red flag for the load planner to read the fuel MEL and it would not allow 

the flight to depart until the load planner acknowledged the MEL with an electronic signature. 

There are no calculators involved in the central load planning process. Everything is done on the 

computers with no entries made by the load planners (though ramp and gate agents still make 

some manual entries). 

At one of the large passenger carriers, until recently the operations agent and ramp crew would 

produce a handwritten "load slip" that included the counts (heavy bags were counted as two or 

three bags). The paper slip was given to the pilots who used a laptop performance computer to 

complete the performance calculations. The pilots were expected to do a "logic check" (e .g., two 

bins worth of baggage should be about 1,500 pounds). The crews were aHowed to apply "wiggle 

room" to the counts; that is, plus/minus two passengers or 10 bags did not require recalculating 

the weights. 

In contrast, under this airline's revised procedures, the "wiggle room" was eliminated and a new 

calculation is now required whenever there are any load changes. The operations agents now enter 

the counts/weights reported by the ramp personnel into a computer input creen, producing a 

printed "loading schedule" for which the computer performs all math previously done manually. 

This program includes gross error-checking capable of catching some input errors, such as a cargo 

weight of 50,000 pounds that far exceeds the load limits of the aircraft. The load schedule is taken 

to the cockpit and handed to the crew. The form includes breakdowns for passenger, baggage, cargo 

and fuel weights, as well as the ZFW and GTOW. The pilots use the printed load schedule to enter 

both ZFW and GTOW into the laptop performance computer. The difference between these two 

weights should roughly match the fuel onboard. 

4.1.3 Flight Deck Data Entry 

At the regional turboprop operator the pilots transfer the performance data to the FMS by reading 

each datum off the handheld computer screen and typing it into the FMS CDU. The captain does 

the entries to the handheld computer then reads the values from its screen and the first officer does 

the FMS entries. 

At one of the large worldwide passenger carriers, three ACARS uplinks of performance data 

normally occur prior to takeoff. First is a planned weight manifest. The data on thi manifest are 

discussed by the crew while still at the gate. They enter the planned weights in the FMS and use the 

speed card on the back of the checklist to look up and enter V-speed . Second is a performance data 

28 

- 
I 

I 

I 

I 

l 

l 

I 

'----- -~ 

sheet, received before pushback, that reflect updated weights, u ually close to final weights. Third 

is the final weight manife t, normally received during taxi . Pilots are not allowed to take off 

without it. This document provides the ZFW and ZFW CG , both of which are entered in the FMS . 

The final manifest also provides GTOW, pas enger counts by zone, total soul on board, and the 

weight change from the forecast manifest to the final manifest. 

At another large worldwide passenger carrier, the performance data and V - peeds in most cases are 

uplinked directly to the FMS via ACARS . The pilots are required to accept the data uplink but there 

is no formal procedure for checking the uplink against the weight manifest or the planned data on 

the dispatch release. In some cases the uplink is not implemented and the pilots must manually 

enter data into the FMS using the printed weight manifest as a source. The data entry may be 

performed by either pilot. The other pilot is required to review the FMS entry for completeness but 

there is no formal cross-check or comparison between the data in the FMS and that on the weight 

manifest or dispatch release. 

4. 1.4 Errors 

One of the large worldwide passenger carriers had been experiencing problems with pilots 

sometimes taking off without having received the final weights. When this happened the pilots 

realized the error when the final manifest was printed out after takeoff. The mitigation implemented 

for this problem was to change the Before Takeoff checklist so the first officer was required to read 

the weight change number (forecast vs. final) out loud. This number was only available from the 

final weight manifest so it facilitated trapping the absence of the final weights. This eliminated 

almost all of the incidents of taking off without final weights. The few that remain have to do with 

quirky issues such as the crew doing a gate return to deplane a passenger and then forgetting to 

report the change in passenger count and request a new final manifest. 

The problem of receiving revised final weights after takeoff used to occur more frequently before 

the company implemented internal controls in the central load planning system that do not allow a 

flight to be closed out without the final weight inputs (see Error Trapping, below). The current 

central load process also does not require any manual entries but instead drives directly from the 

scanned baggage, cargo, and passenger count inputs. 

A senior load-planning manager at this airline noted that errors often happen during irregular 

operations. He also stated, "Process errors can just as easily cause a 20 ,000 pound error as a 10 

pound error." 

At one of the large passenger carriers, the most common error reported in a previously used load 

control system (which had involved agents manually adding the weight components to obtain 

GTOW) was a "10 ,000 pound fuel error." This wa a math error. It has been eliminated in the new 

system by having the computer do the computations. 

Another problem area of the previous system occurred when operations agents tried to work ahead 

by entering the planned or anticipated values for the weight components in order to pre-check for 

weight-limited flights . Sometimes they would then forget that the numbers in the records were 

planned values and didn't replace them with the final numbers. In the new, current system, the 

software automatically zeroes out any previous inputs when the final weights are being prepared. 

29 

l 

- -' 
--------------- ~_.- 

A captain at this airline related a personal experience: One day after reviewing the load schedule he 

had a feeling of "something's not right." He was flying an aircraft type variant that wa relatively 

new to him so he was not accustomed to the normal performance data values for that type. During 

rotation, with the first officer flying, the aircraft rotated but did not lift off. Fortunately, the first 

officer froze the pitch attitude instead of continuing rotation into a possible tails trike or angle-ofattack-prevented liftoff. Eventually the aircraft lifted off and climbed. Shortly thereafter the crew 

received a message that "the operations agent wants to speak with you." Then they were told to 

change their passenger weight to a greater number. It was a 25,000 pound error. 

At this airline under the revised, current load control system, the pilots still do not have access to 

the raw counts and values from the ramp, gate, and fuelers (e.g., they do not get a fuel slip). The 

main vulnerability of the current system continues to be the quality of the load schedule that is 

prepared from the raw data by station operations, which still depends on accurate entries by the 

agents, transmittal of information from ramp agents, through supervisors, to operations agents. 

Handwriting i still involved on the ramp and miswriting or misreading an entry is possible. 

The planned performance weights are provided to the operations agent and flight crews through 

the dispatch release. The company procedure requires that operations agents compare the planned 

and actual weights and if the difference exceeds 5,000 pounds the operations agent is supposed to 

contact dispatch to obtain a new fuel burn for the final weight and to provide this number to the 

crew. The reliability of executing this procedure depends on the conscientiousness of the operations 

agent. They are supposed to take action on a 5,000 pound discrepancy regardless of whether the 

final weight is less than, or greater than, the planned weight. It is not clear whether an aircraft 

loaded to significantly less than its planned weight would reliably prompt review and resolution by 

either operations or dispatch, which leaves the possibility that an apparent underload might actually 

result from a performance data error. 

4. 1.5 Error Trapping 

At the regional turboprop operator, as part of the "cargo planning" function that provides pilots 

with the baggage and cargo counts/weights, one agent cross-checks his work against that of another 

and both sign the form to take responsibility. This cross-check was implemented after previous 

events involving errors. The cross-check and "two-signature" procedure improved the situation. 

The two pilots cross-check the output of the handheld computer entries against the entries made in 

the FMS . This particular FMS model is not capable of internally generating V -speeds that 

potentially could be compared with the ones calculated on the handheld computer and manually 

entered in the FMS . . 

The captain receives a load planning sheet with the anticipated passenger, baggage, and cargo loads 

about 30 minutes before departure to use for planning the fuel; however, for the most part there is 

no procedure to compare these anticipated values with the final actual values later in the processwhich might help catch errors in the final numbers. However, a cross-check is performed with the 

cargo/baggage weight subcategories; about 10 minutes prior to pushback a ramp agent provides the 

captain an updated cargo load value which is mainly done to account for last-minute changes in 

baggage, such as gate-checked carry-ons. The captain compares this value with the one that was 

previously entered in the handheld computer from the load planning sheet. So there is an 

opportunity to compare the planned and actual weights for the cargo/baggage component of load. 

30 
We did not obtain information about this airline's procedures for detecting and resolving 

differences between planned and actual total load. 

At one of the large worldwide pas enger carriers, the lookup of data on the speed card (based on 

preliminary weights received from ACARS) is specifie~ to be done independently by the captain 

and first officer. The first officer looks up and enters the data into the FMS and the captain then 

verifies, including an independent lookup on the speed card. 

At this airline there is a check and verify procedure for entries in the FMS . At the gate, the first 

officer enters the preliminary data from the printed forecast weight manifest and performance 

sheets. During taxi-out when the final weight manife t is received the first officer states ''I'm going 

head-down" and then makes the required adjustments in the FMS. Then the captain verifies by 

cross-checking the entries shown on the primary flight display (PFD) against those in the FMS (this 

cross-check is capable of alerting the crew to a subset of errors, such as changing the departure 

runway without entering the associated revised performance data for the new runway. However, the 

captain does not cross-check the data·in the FMS against the data on the final weight manifest, 

which would be a more comprehensive cross-check capable of alerting the pilot to other errors. 

Also , at this airline pilots are upposed to review a weight change and, if it exceeds a stated value , 

call dispatch for a new flight plan or re-relea e. The call to dispatch is required for being both over 

and under the forecast weight. But if the final weight is les than the forecast weight, the dispatcher 

will u ually just say "You 're good to go." There is no requirement to resolve the reason for the 

difference between the forecast and the final weight. 

This airline eliminated the manual passenger count by the flight attendants about five years ago in 

favor of relying on the gate scanning process. The gate agents are responsible for reconciling the 

booked vs. scanned passenger counts as part of the closeout process. An audit during this change 

process showed that the gate counts were more accurate than the flight attendant counts. 

Pilots enter the fuel on board as displayed on the fuel gauges into the FMS. The direct entry of fuel 

by the pilots is designed to catch a fueling error in which the fuel on the aircraft does not match that 

shown on the final weight document. 

This airline recently implemented a robust system to catch errors in the loading and data calculation 

functions. The great majority of the errors caught by the system appeared to be too small to pose 

appreciable risk and were related to inaccurate passenger counts. In these, the closeout occurred so 

the flight could be released for departure, generating the final weight heet in the cockpit. Then, an 

agent manually re-opened the flight to correct the passenger count and this generated another 

closeout and revi ed final performance data. The automated error-trapping system is designed to 

notify the crew that their numbers are invalid and to expect and wait for revised numbers if the 

flight is re-opened for correction before the flight has taxied less than 50% of the planned taxi time; 

this would not be classified as an error and would be counted among the caught errors. However, to 

avoid the risks of generating a distracting message during takeoff roll, if more than 50% of the taxi 

is completed the system does not directly alert the crew but routes the "invalid weights" message to 

the flight's dispatcher. When the weights have been re-finalized, if the change is more than a half 

percent of the previous TOW, the new numbers are sent to the cockpit via ACARS. If less than that 

percentage change, the new numbers are sent to the dispatcher who can review whether the change 

31 
is significant with respect to limitations. In any ca e, if the flight take off with the uncorrected 

performance data this is flagged as an error by the system. 

This sy tern requires supervisors to investigate each error and if the error exceed the limit value to 

document the finding . As an example, a 60-pound cargo error was found to involve the ramp 

adding two bags after closeout. These supervisory investigations occur after the flight has operated 

so they cannot trap errors but may help prevent recurrence of error. 

These errors are being flagged because the airline is reconciling the data, mostly before departure 

but sometimes, in error, after departure. In comparison, before adopting this automation procedure 

the airline did not attempt to reconcile the loads until after departure on a regular basis. One person 

we talked with estimated that the typical discrepancy found after departure before the new 

procedure was adopted was 3,000 pounds. These errors were never reported because of a harsh 

reporting culture-one had to report each error to the vice president. It was suggested to us that 

other airlines that do not have an automated system such as this one are sending out flights loaded 

incorrectly without ever knowing about the errors. 

At one of the large passenger carriers a large discrepancy between the planned ZFW and actual 

ZFW will be flagged by the laptop by displaying an error message on the screen. However, the 

comparison is between the value that the dispatcher used for fuel/altitude planning and the actual 

weights. The dispatcher's planned weight value comes from an early estimate of the loads and there 

is no explicit coordination between the dispatch and the load planning functions for updating these 

estimates so the laptop's built-in comparison is not particularly good for catching loading or 

calculation errors. 

The laptop automatically checks that the laptop-generated ZFW is not more than 1,000 pounds 

greater than the dispatcher estimated ZFW and flags any discrepancies. If the laptop flags the actual 

ZFW more than 1,000 pounds greater than the estimated value, then the crew calls dispatch to 

confirm that the fuel load is adequate for the increased bum resulting from the heavier gross weight. 

One captain personally compares the planned vs. final numbers and if there is a big difference he 

makes sure that he understands why (fewer passengers, unanticipated cargo, etc.). However, there is 

no requirement for the crew to compare or think about it beyond the laptop alert. In one instance 

this captain received a fuel bum value that was 8,000 pounds instead of the 16,000 pounds he 

would normally expect for the trip being flown. This discrepancy took a lot of work to resolve; it 

turned out to be a gross performance data error. 

At another airline that this captain flew for previously, on one occasion the passenger count input 

by the crew was zero (or left blank) and as a result the flight had to do an air turnback at the 

midpoint of an ocean crossing due to inadequate fuel reserves to complete the crossing. He related 

that if thi error had occurred with his current airline's performance data system the laptop's 

automated error trapping function would generate a pop-up box asking the crew whether they were 

sure about the zero value for passengers. 

This airline uses a cut-off time to stop accepting cargo for a flight and this is effective in controlling 

the trickle-out of last minute cargo to the ramp. If accepted, cargo is not actually loaded on the 

aircraft, procedurally it must be delisted from the manifest. If it is not delisted prior to departure, 

thi error can be caught if the lead agent reports to the captain that a listed item was not loaded. 

32 

---- -- 
Also , it may be noticed if an unloaded cart is noticed sitting on the ramp and "someone" notifies 

station operation . 

If a weight is entered incorrectly, operations personnel reviewing the load can notice if a final 

weight (e.g., cargo, pa senger, or baggage weight) does not match the load plan. They are then 

supposed to ask whether the captain was notified . There is also a reporting mechanism in which 

discrepancies are supposed to be investigated. But all of this happens after flight departure or 

even after arrival . There i no procedural comparison of the final load numbers to the load plan 

that takes place prior to departure. There is no procedural reconciliation of any differences or 

apparent discrepancies. 

A senior cargo operations manager stated that some kind of pre-departure review of the final load 

against the plan and/or reconciliation would be useful. The best place to do this would be in the 

cockpit. Right now the flight crew is not given the load plan so they do not see the planned 

passenger, baggage, and cargo weights. Accordingly , they are inhibited from checking, questioning , 

and initiating reconciliation . Giving them the load plan would be an improvement. 

At another large passenger carrier, after the first officer enters the data in the laptop performance 

computer, the pilots perform a series of quality control checks that have been specified in the 

company 's SOPs. The captain checks specific items on the load schedule against what is displayed 

on the laptop , including the aircraft numberltype, and verifies that the components of the ZFW 

shown on the load schedule are not grossly in error (e.g., the passengerlbag weights are not zero). 

Then, during the Before Push checklist, the captain and first officer systematically step through the 

entries on the laptop and FMS (the entries have been formatted to look alike on both devices) to 

verify that the first officer transferred the data into the FMS correctly. 

One example of an error trapped by this system occurred when an operations agent forgot to 

enter any cargo weight. Thi was caught by the captain who saw zero for the cargo entry on the 

load schedule. 

The pilots also cross-check that the sequence number of the release matches that of the load 

schedule, signifying that the two are based on the same information. This catches potential errors in 

which either document may be revised without revising the other. As another cross-check, this 

airline's procedures require the crew to obtain a flight attendant customer count to check against the 

passenger count that the gate agents provide to the pilots. 

4.1.6 Future Technologies and Procedures 

One senior load planning manager we talked with would like to see items scanned as they actually 

enter the aircraft (using radio-frequency idenfification technology for the cargo and baggage). He 

would also like to see a fuel planning system that sends the fuel order directly to the fuel truck , 

perhaps even controlling the fuel valves automatically to avoid over-fueling (this is more of a 

cost/efficiency item than a safety item). 

He suggested that a flight planning system which accepts weight/balance inputs from the final 

weight documents and quickly recalculates performance would allow for more accurate planning. 

Currently , flights are planned early in the process, before the final weights are known , and as a 

result they have to include a buffer of up to several thou and pounds to account for weight changes 

33 
1- -

to the final. Updating the flight plans with the final weights would be more efficient for fuel and 

altitude planning. 

A senior cargo operations manager at another airline said that he would welcome a way to scan 

cargo both as it leaves the warehouse and as it is loaded on the aircraft if it could be done in a costeffective way. "The less manual handling the better." There would also be security and loss-control 

benefits. He also said that an aircraft that could weigh itself and automatically cross-check the 

weight and balance calculations would be a very welcome improvement. 

4.2 Summary of Process Steps in Three Variants 

Ba ed on these discussions with airline personnel , we developed a flow diagram of three variants of 

the performance data processes that are in current use by the air carrier industry (Figures 1-3). 

These three variants are not exhaustive of all of the performance processes that are in use but rather 

they are representative of some of the commonly existing combinations of procedures and 

technologies. We also used the information from our discussions with airline personnel to guide us 

in defining the process step, actor, and error type variables for our ASRS case analysis as we 

discussed in the Method section. 

Flight Crew 

Figure 1. Central load planning with station operations model. 

34 

I 

J 
Flight Crew 

Figure 2. Central load planning without station operations model. 

35 

-------
I 

r 

! 

Figure 3. Flight deck load planning model. 

4.2.1 ASRS Case Analysis 

Flight Crew 

(continued) 

Ninety-eight of the 100 reports selected for detailed analysis were submitted by airline pilots 

reporting on a specific flight segment that they flew and two reports were from dispatchers. This is 

consistent with the nature of the ASRS database in which the great majority of reports come from 

pilots who receive some degree of immunity from FAA enforcement action by submitting reports 

of incidents compromising safety. One hundred and twelve distinct errors were reported among 

these 100 flights. 

The reports provided adequate information to identify the type of operation for 97 flights, of which 

84 were passenger flights (Table 1). 

36 
Table 1. Operation Type 

Frequency 

Passenger 84 

Cargo 12 

Other repositioning 1 

Total known 97 

Total unknown 3 

Total 100 

Jet aircraft were operated in 91 flights. More than 13 aircraft types were involved (Appendix A); 

however, we do not have data on the relative frequency of operation of these aircraft types, which 

would be required to calculate relative likelihood of error among aircraft types. 

4.2.2 Locus of Error Reported 

Sixty-nine of the 112 reported errors were made by ground personnel performing functions external 

to the flight deck while the other 43 errors were made by flight personnel performing cockpit 

duties. Ground personnel errors were distributed among central load planning, station operations, 

and ramp/gate, with the latter being reported most frequently (Table 2). 

Table 2. Locus of Error External to Flight Crew 

Frequency Percent of All Errors 

Central load planning 12 17.4 

Station operations 10 14.5 

Ramp or gate 18 26.1 

Total known 40 58.0 

Total unknown 29 42.0 

Total 69 100.0 

Gate and ramp personnel error: 

" ... ramp had loaded a cart of freight weighing 1,700 pounds 

instead of a cart of freight weighing only 300 pounds." 

ACN 668967 

This subcategory of personnel was not available for 29 of the 69 errors made by ground personnel. 

37 

: 

J 
!---

Error made by unknown ground person: 

"Just after takeoff, the Captain told me that it feZt like he 

aLmost over-rotated and that the back pressure at takeoff was 

extremeLy light. About 10 minutes after takeoff, I noticed ... a 

new final weight manifest from operations sent to us 5 

minutes after we already departed! New zero fuel 

weight ... and new trim setting ." 

ACN 534159 

In this example, the report did not provide information about which ground person made the error 

that led to incorrect weight and trim values provided the flight crew before gate departure and 

corrected only after the flight had been exposed to risk during takeoff_ Although the reporter cited 

"operations" as the party from whom the incorrect information was received , this pilot did not 

specify the actual source of the error (which may have been ,for example, a miscount by a ramp 

agent that entered into the calculations made by the station operations personnel). 

4.2.3 Process Steps, Actors, and Types of Errors 

As described in the Method section, we developed a list of steps involved in the performance data 

process, the actors involved (depending on the way each individual airline established its processes 

and the technologies employed), and the types of error that might in principle be made in these 

process steps _ These are depicted in Table 3. 

38 
,

I 

f 

Table 3. Error Proce Steps, Actors, and Types 

Subtotal: Subtotal: 

Process Step Actor: Error Ground Flight Deck 

Locus Locus 

Forecast load limitations Load planning: Failure to produce forecast 0 0 (weight restrictions) for weight restriction. 

(subtotal=O) Load planning: Failure to disseminate 

0 0 weight restriction . 

Revise forecasts based Load planning: Failure to adjust for 

0 0 

on changes in weather, changed conditions 

tempeature, runway, Load planning: Failure to disseminate 0 0 fuel requirements changes. 

(subtotal=O) 

Obtain actual cargo Ramp: Weighing error. 0 0 

weights Cargo department: Incorrect transmittal of 1 0 (subtotal=15) waybill data to load control or ramp. 

Ramp/cargo: Data entry by omission of 1 0 scanning. 

Ramp/cargo: Counting error. 1 0 

Ramp/cargo: Data entry with incorrect 6 0 

weight value . 

Ramp: Failure to load/offload containers. 2 0 

Ramp/cargo: Data entry by erroneous 

1 0 container position . 

Obtain actual passenger Gate: Data entry error by failure to enter or 0 0 count/weight scan boarding passengers. 

(subtotal=3) Gate: Miscount of passengers. 1 0 

Gate/operations: Math error with total 0 0 

count or distribution . 

Gate/operations: Data entry error with 1 0 

passenger total or distribtuin . 

Load planning: Data entry or math error. 0 0 

Gate/operations/load planning: Late or 

omitted transmital of data to operations, 1 0 

load planning, or pilots. 

continued on next page 

39 
Table 3. Error Process Steps, Actors, and Types (continued) 

Subtotal: Subtotal: 

Process Step Actor: Error Ground Flight Deck 

Locus Locus 

Calculate Operations/load planning/pilots: Data entry 7 4 weight/balance error. 

(subtotal=20) Operations/load planning/pilots: Math 2 6 

error. 

Pilots: Failure to enter data in ACARS or 0 0 laptop. 

Crew: Failure to clear previous flight data 0 0 from ACARS or laptop . 

Gate/operations/load planning: Late or 

omitted transmittal of data to 1 0 

perations/load planning/pilots. 

Verify weight/balance Opeationslload planning/pilots: Use of 

agains performance incorrect runway, temperature , wind, or 3 1 

limits weights for inputs. 

(subtotal=13) Operations/load planning/pilots: Data entry 

error for runway, temperature , wind, or 0 0 

weights. 

Operations/load planning/pilots: Failure to 

update for changes in reunway, 0 5 

temperature, wind, or weights. 

Operations/load planning/pilots: Failure to 0 4 check limits. 

Operations/load planning/pilots: Failure to 

flag and correct violated limitation after 0 0 

checking. 

Calculate V -speeds, trim Operations/load planning/pilots: Use of 

settings, flap setting wrong runway, temperature , wind, or 2 1 

(subtotal=3) weights for inputs. 

Operations/load planning/pilots: Data entry 

error for runway, temperature, wind, or 0 0 

weights. 

Operatioins/load planning/pilots: Fail to 

update for changes in runway, 0 0 

temperature, wind, or weight. 

continued on next page 

40 
Table 3. Error Process Steps, Actor , and Types (continued) 

Subtotal: Subtotal: 

Process Step Actor: Error Ground Flight Deck 

Locus Locus 

Transmit weight! Operations/load planning/pilots: Error in 

balance, performance rreading, recording weight!speed/trim 0 1 

speeds, trim settings to data from source. 

flight deck Operations/load planning/pilots: Error in 

(subtotal=5) re-inputting, recording 0 1 

weight/speed/trim data from source 

Pilots: Failure to request data/uplink via 0 0 ACARS 

Pilots: Failure to ntice that data not 0 3 received prior to departure 

Enter weights into FMS Uplink data error (no person). 1 1 

(subtotal=6) Pilots: Error reading received/uplinked 0 1 data. 

Pilots: Failure to input final data. 0 0 

Pilots: Failure to indentify uplink error. 0 1 

Pilots: Data entry error. 0 1 

Pilots: Table lookup error. 0 1 

Input V-speeds, trim Uplink data error (no person). 0 0 

settings into FMS Pilots: Error reading received/uplinked 0 0 (subtotal=10) data. 

Pilots: Failure to input final data. 0 0 

Pilots: Failure to identify uplink error. 0 1 

Pilots: Data entry error. 0 0 

Pilots: Table lookup error. 0 0 

Set bugs Pilots: Failure to set bugs. 0 0 

(subtotal=l) Pilots: Error in setting bugs. 0 0 

Pilots: Cross-check error. 0 1 

Set trim Pilots: Data entry by failure to set trim. 0 1 

(subtotal=l) Pilots: Error in settring trim. 0 1 

Pilots: Cross-check error. 0 0 

Set flaps Pilots: Data entry by failure to set flaps. 0 1 

(subtotal=5) Pilots: Data entry by erroneous flap setting. 0 4 

Pilots: Cross-check error. 0 0 

Total 34 39 

41 
Seventy-three of the reports contained enough information for us to identify the functional step in 

which an enor was made in the process of generating, transmitting , and entering performance data; 

identify the actor (ramp/gate, station operations, load planning/control, or flight crew) making the 

enor; and characterize the type of enor. In Table 3 we populate the list of possible errors with the 

actual errors reported, the process steps in which the enors occuned, and the actors committing 

those enors. 

The process steps most frequently reported to have enors were obtaining actual cargo weights (15 

errors) , calculating weight and balance (20 errors), and verifying the weight and balance with respect 

to aircraft performance or limitations (13 errors). Note that these data do not reveal the relative 

frequency with which these errors actually occur because the probabilities of different enor types 

being reported is completely unknown . Here are examples from each of these three categories: 

Obtaining Actual Cargo Weights. The 15 errors in this step in the process were distributed among 9 

distinct types of enor. The most frequent category was enors made by ramp/cargo personnel as they 

entered the weight data (6 errors). A seventh entry enor involved omitting the scanning of cargo. 

Among these 7 data entry errors, we considered that several different functions might have been 

involved, depending on the various processes and technologies that the air carriers in our sample 

used for transmitting weight data from the loading ramp, for example: 

• Inconectly marking a load sheet to be passed to the flight deck. 

• Omitting or not making computer keyboard entries later to be printed in the 

operations office. 

• Not scanning cargo waybills. 

• Scanning containers previously marked with inconect weights, with the scanned 

information then being transmitted and u ed for calculations without further 

human input by a central load planning computer. 

However, these details were not available in the ASRS case nanatives for the cargo data entry 

enors. Here is an example of one of the enor narratives, showing the level of detail that was typical 

for an enor made by ground personnel as reported by a pilot: 

Obtaining cargo weights error: 

"The ramp had loaded extra bags and had not made the 

operations agent aware of the addition .. .An error of this type 

has definite potential to compromise safety." 

ACN 594017 

Calculating Weight and Balance. Among the 20 errors at this step in the process, the most common 

types of error were data entry enors made by ground personnel (7 errors) or pilots (4 errors) and 

math errors made by ground personnel (2 errors) or pilots (6 errors). 

42 
Data entry error by ground personnel: 

"The operations agent handed me the load sheet and I began to 

make the appropriate entries in the FMC and [laptop ' 

peljorrnance computer] .. . We noticed and commented that we 

were really light and were going to take off like a rocket ... Ollce 

in the air, we received a radio call from operations telling us to 

revise our takeoff weight ... The correct weight was actuaLLy 

19,000 pounds heavier. We then realized the numbers added up 

correctly but the passenger weight was extremely low ... The 

operations agent had entered 33 passengers into the computer 

versus the 133 passengers that we actually had ... The plane took 

off fine, although the captain said it felt a little mushy on liftoff. 

But had we lost an engine on takeoff at that heavy weight and at 

that altitude, we may not have been able to stay airborne. " 

ACN 669643 

Data entry error by flight crew: 

"in his haste, the first officer entered the adjusted weight unit 

for 25 passengers in zone 2 instead of the 24 we actually had 

on board." 

ACN 675274 

Math error by ground personnel: 

"At pltsi!back, I noticed that the takeoff weight appeared to be 

very light for a B737-700 ... 0n takeoff, the aircraft felt heavy at 

the computed speeds, so I rotated and allowed the aircraft to 

fly off at the speed it needed. This appeared to be about 10 

knots faster than computed ... The first officer double checked 

the load manifest andfound that there was a 10,000 pound 

error on the zero fuel weight. I entered the correct zero fuel 

weight into the flight management computer. Thefirst officer 

radioed back to [the departure station] to check their 

paperwork. The coordinator stated that the operations agent 

had already found and corrected her mistake." 

ACN 585778 

Math error by flight crew: 

"We were running late . I was rushing through paperwork. On 

the load manifest, I made a calculation error and wrote in the 

wrong landing weight." 

ACN 479900 

43 

-- --- ----- -- -- 

I 

_._ ... _-.J 
,

- -- - I 

I 

I 

Verifying Weight/Balance Against Performance Limits. Among the 13 errors at this step in the 

proce s were tho e that involved entering the wrong data for weights, wind , runway, or 

temperature , etc. (4 errors of which 3 were made by ground personnel), not updating for changes in 

these parameter (5 errors, all by pilots), and not checking calcul ated performance against 

performance limits (4 errors, all by pilots). 

Entering wrong data: 

"The takeoff and performance data received from our company load 

planners specifically contained the statement advising us to 'expect a 

departure on Runway 34R,from intersection Q' .. lt is customary that 

when an intersection takeoffis defined ... there is also a corresponding 

runway takeoff analysis, based on the specific intersection takeoff 

point ... indicating maximum takeoff weights for the runway intersection 

takeoff point...bat not in this case! ... We had only been issued a full 

length runway analysis ... 1 learned that although the air carrier uses a 

central load planning system the local stations have some authority 

over selected weight and balance entries ... Simply put, the station told 

us to expect one thing, but gave itS information for another, a 

potentially fatal error in this case .. .There are other problem areas 

too .. .For example, if the runways are wet with standing water, and I ask 

dispatch to show [performance datafor] a contaminated runway, the 

reply I get is that they cannot, because the station is not reporting it!" 

ACN 547346 

Not updating for changes: 

"We completed our load manifest paperwork and were closing the 

main cabin dOO1'for pushback when ramp personnel advised us that we 

were going to have more passengers. The new passengers trickled out 1 

and 2 at a time ... we did not realize that extra passengers put us 

overweight. We did not discover this error until cruise when I started to 

prepare the landing data for our approach." 

ACN 667514 

Not checking against limits: 

"While preparing the weight and balance form for our flight.. 1 failed 

to recognize that we would be taking off over au/' landing structural 

weight. This is ... calculated by adding the plannedfuel burn-oJfto the 

landing structural weight [limit] .. After we pushed away from the gate, 

we found the error, however, we did not exceed any aircraft limitations 

by running the APU for the entire flight, flying at a lower altitude than 

originally planned and using jlaps 9 degrees earlier than normal... 

Contributing factors include the rush to push the flight on time, having 

more passengers than originally expected, and the fact that our weight 

was less than [maximum] aircraft takeoff stmctural weight (easier for 

me to overlook thefact that we were over pLanned landing .. .limit}.·' 

ACN 573981 

44 
Entering Data in the FMS. One of the main indu try concerns leading u to conduct this study was 

flight crews inadvertently entering wrong data into the FMS. Five errors were reported that 

involved the proces of entering data in the FMS; however, only one of these was a pure keyboard 

entry error, while the other four resulted directly from an error that the pilots had made reading, 

manipulating, or checking the data as they made the keyboard entries (looking up information on 

the wrong reference card , misreading data that they had received, not identifying an error in the data 

that had been uplinked to the flight deck). These errors are summarized in Table 4. 

Table 4. Errors Involving FMS Data Entry (n=5). 

ACN Description Contributor( s) 

530341 Flight crew entered incorrect fuel Fue1er underfueled aircraft by 3,000 pounds 

weight into FMS despite correct but provided pilots with the planned 

weight displayed on fuel gauges (incorrect) amount on the fuel form. Pilot 

(checked gauge but saw the expected verifying fuel by looking at gauge then 

value rather than actual value). "saw" the expected value-not the one that 

was really in the tank and on the gauge. 

615939 Given a runway change during taxi- Company paperwork provided temperature 

out, flight crew entered the incorrect in degrees Farenheit but the FMS required 

"assumed temperature" for reduced- Celsius for input. 

power into FMS, resulting in long 

takeoff roll. 

632164 First officer mistakenly entered ZFW Pilots were new to the aircraft type,so not 

in the FMS input box for GTOW, familiar with typical weights and speeds. 

resulting in poor performance in 

takeoff and cruise. 

710246 Input planned weights into the FMS Ground personnel did not send final weights 

instead of final weights during the prior to or during taxi-out and flight crew 

Before Takeoff Checklist. did not notice. 

790465 Crew input weights/speeds for Crew mistakenly used a printed speed card 

100,000 pounds less than actual for 270,000 rather than the aircraft's actual 

weight into the FMS, resulting in poor weight of 370,000 pounds as their reference 

takeoff and climb performance. source for FMS inputs. 

45 

--------. ~ 
Setting the Flaps. Although it was not reported as frequently, setting the flaps to the wrong position 

(4 instances) had very serious consequences. 

Flap setting error: 

"1 had run the numbers in the [latptop peJjormance computer J 

and it required a flaps 15 degrees [setting for takeoff}, best 

case gave only 21 feet of stopping distance [in the event of 

rejected takeoff]. We briefed the flaps 15 deg takeoff, but with 

my mind on other things, when the captain calledfor [the 

usual] flaps 5 degrees (habit patterns) after engine start, I 

didn't catch it and tracked the flaps to 5 degrees. Neither of us 

caught the mistake. On takeoff roll approaching the 2,000-feet 

remaining mark, I saw the captain pulling back on the yoke. 

We had set trim at 3.5 units and it was a long pull. That was 

when it hit me that we hadn't set the flaps to 15 degrees as 

required by the [laptop performance computer]. We cleared 

the fence at the departure end and the rest of the climbout was 

uneventful. When we ran the numbers on the way to our next 

city, we found we were over 4,000 pounds too heavy for aflaps 

5 degree takeoff." 

ACN 625930 

Our ASRS cases also included a single instance of the extremely serious error of not extending the 

flaps at all. This occurred when the pilots omitted the entire Before Takeoff checklist, including the 

steps of both setting and checking the flaps, and it was caught by activation of the aircraft's takeoff 

configuration warning system. 

4.2.4 Fuel Load Errors 

Nine errors by ground personnel and pilots in loading , documenting, entering, and verifying fuel 

loads occurred, cutting across (and included in) the process step, actor, and error type results 

described in the previous section. Because airlines may use different procedures to account for the 

fuel load than they use for the payloads of passengers, cargo, and baggage, we reviewed the ASRS 

case sample for events specifically related to fuel (Table 5). 

46 
ACN 

529324 

804855 

530341 

538960 

605400 

703116 

582934 

587708 

779098 

Table 5. Errors Involving Fuel Loading, Documentation , Entry , 

and Verification (n=9) 

Description 

Ground per onnel provided fuel weight value missing the 1 in the 100,000 column , 

resulting in 100,000 pound error and leading to tailstrike . 

Load manifest from ground personnel omitted trailing zero from fuel weight value, 

resulting in 100,000 pound error and speed decay in cruise. 

Fueler underfueled aircraft by 3,000 pounds but provided pilots with the planned 

(incorrect) amount on the fuel form. Pilot verifying fuel by looking at gauge then 

"saw" the expected value-not the one that was really in the tank and on the gauge. 

Load manifest from ground personnel missing trailing zero in 10 ,000 pound fuel 

weight, resulting in 9,000 pound error. 

Pilots did not properly account for ballast fuel, led to exceeded max ZFW limitation. 

Pilot made 10,000 pound math error while adding fuel weight to the ZFW (for 

entry into the FMS). 

For performance data calculations, pilot used fuel value that had been discussed 

earlier instead of the fuel load actually aboard the aircraft, 

Fueler mistakenly substituted fuel loads for two different tanks, resulting in 

incorrect CG calculation. 

Fueler misfueled the aircraft; pilot noticed the misfueling and intended to correct 

the situation but forgot to do so, resulting in nose-heavy takeoff. 

4.2.5 Laptop-Related Errors 

Based on the involvement of laptop performance computers in major accidents and incidents, we 

reviewed the ASRS case sample for laptop-related events. There were no events involving the 

specific errors that were causal to the Halifax and Melbourne accidents; i.e., data entry errors 

comprising failure to enter the new flight's performance data leading to mistaken use of the 

previous flight's data, and mistaken entry of the ZFW value into the GTOW field of the laptop. In 

one instance, a pilot entered a weight value from the wrong line of the load manifest into the laptop, 

obtaining an incorrect projected landing weight from the laptop that led to the flight departing 

overweight. In another, a pilot entered the incorrect variant of the aircraft type into the laptop , with 

no adverse con equence. In third ASRS case, the laptop equipment apparently malfunctioned (after 

being cold-soaked) and although the pilots entered the data correctly the laptop's outputs were 

erroneous; these incorrect performance parameters were not caught by the pilots, resulting in 

uncommanded pitch-up and a high speed rejected takeoff (RTO). There were additional ASRS 

cases in which the pilots obtained incorrect counts and weights from earlier steps in the 

performance data process and then entered these into the laptop, but the laptop technology was not 

related to these errors or failure to catch them. 

47 
4.2.6 Error Trapping 

Only 20 of the 112 error were trapped before becoming consequential. This datum may not reflect 

the actual effectiveness of en"or trapping in the popuLation of all flights; trapped errors are probably 

far less likely to be reported than error that become con equential, but, on the other hand, errors 

that never became apparent to the pilots (and thu could not have become the subjects of ASRS 

reports) are probably less likely to be trapped than those known to the crews. (An example of the 

latter would be a calculation error made by ground personnel that the pilots do not notice.) These 

two biases are in oppo ite directions and the net effect cannot be determined. 

Error Trapping Failures. An error was coded as one of the 92 that was not trapped if it was not 

identified, caught, and corrected before the flight was exposed to risk. For example , a baggage 

counting error that was identified by someone on the ground might be considered to have been 

trapped by the person catching the error. However, if revised performance data were not passed to 

the flight crew before departure then the flight would still have taken off with the incorrect data and 

therefore been exposed to possible tailstrike, failure to lift off, or inadequate climb performance 

over obstacles. Consequently, this error cannot be considered to have been successfully trapped. 

Overall, the ASRS reports contained little information about the specific error-trapping procedures 

used by the airlines, especially in ground functions. The reports also contained little information 

about why errors were not trapped, especially in the ground functions. 

However, in 12 of the 100 flights the pilot making the report provided adequate information not 

only about the performance data error that occurred but also about why the error was not caught. In 

these 12 reports we were able to identify breakdowns in verifying data and in noticing , reconciling, 

. and correcting discrepancies and we coded these aspects as additional errors. These additional 

errors provide some insight into error trapping failures. The primary errors that were not trapped, 

and the reporter's explanations of not trapping them, are summarized in Table 6. The insights 

provided by these reporters about their experiences with error trapping failure are evaluated in the 

Discussion section. 

48 

------. " 
ACN 

530341 

710246 

675274 

742390 

483680 

662092 

779098 

793424 

Table 6. Enor-Trapping Failures Described by Reporter 

Primary Performance Data Error Error-Trapping Failure Description 

Fue1er underfueled the aircraft by 3,000 Pilots looked at the fuel gauges to verify 

pounds, but entered the planned the fuel onboard but saw the expected 

(greater) fuel amount on the fueling value rather than the (lesser) actual value. 

record given to the flight crew. 

Ground personnel did not send final Running late and time-pressured by a 

weight data at the normal time during quick takeoff clearance, pilots did not 

taxi-out. notice the absence of final weight data and 

took off without them (mistaking a 

weather printout for the final weight 

printout in the dark cockpit). 

First officer made a mistake with the Captain did not catch the enor while 

weight and balance calculation. reviewing the data, attributed to being late 

and rushing. 

Ground personnel sent loading data for Pilots missed "red flags" of being 25,000 

previous day 's flight. pounds under planned weight, runway data 

being flagged as "preliminary ," and 

inconect data on data printout header. 

Assumed that what came over the printer 

would be for their flight. Rushing and did 

not take the time to resolve the "red flags." 

Load planning and dispatch sent Pilot's math enor (affected by rushing for 

incorrect weight and balance data on-time) prevented catching the original 

allowing aircraft to be overloaded by error until re-Iooking at the math during 

10 ,000 pounds. taxi-out. 

Confusion among load planning Given the same confusion , flight crew 

personnel and flight crew during an departed without final weight data under 

irregular operation led to ground the mistaken impression they had obtained 

personnel not providing timely final adequate data. 

weight data. 

Fueler neglected to add fuel to tail tank Pilot noticed the discrepancy, intended to 

and load planning did not check planned contact dispatch to resolve it, but was 

against actual fuel distribution among distracted and forgot. Aircraft was very 

tanks. nose-heavy on takeoff. 

Payload planning by ground personnel Pilots noticed, but did not resolve, an 

omitted passenger and cargo weights. automated warning on their final weight 

data that the flight was more than 10% 

over its planned weight, then experienced 

high fuel burn in cruise and had to divert to 

refuel. 

continued on next page 

49 

l 

I 

i 
Table 6. Error-Trapping Failures Described by Reporters (continued) 

ACN Primary Performance Data Error Error-Trapping Failure Description 

481650 Ground personnel provided performance Rushing due to being late, pilot did not 

data based on the wrong aircraft notice the error until cruise. Aircraft 

number. numbers looked similar and this error by 

ground personnel is unusual/unexpected . 

537000 Ground personnel omitted the jumpseat Influenced by the gate agent's statement 

occupant from the performance data that the passenger count was "exactly 

calculations. right," the pilot did not catch this omission 

(which could have been identified by 

review of the paperwork). 

726238 Gate agent provided incorrect passenger Airline 's procedure also included a 

count (5 rather than 45) for pilots to use passenger count by the flight attendants but 

for performance data calculations. the pilot did not verify the gate count 

against the flight attendant count. 

585778 Station operations agent made a 10,000 Pilot had checked some of the agent's math 

pound math error in adding the adding fuel weight to the ZFW to obtain 

passenger, baggage, and cargo weight takeoff gross weight but did not check the 

components to the aircraft's empty components of ZFW until noticing 

weight to obtain ZFW. degraded takeoff performance. 

Effective Error Trapping. Of the 20 errors that were trapped, 18 were trapped by persons (16 by 

flight crew and 2 by station operations personnel) and the remaining two were trapped by systems 

or automation. 

Effective error trapping by flight crew: 

"Aircraft fuel load called for all main tanks full, plus upper 

and lower aux tanksfull,plus 12,400 pounds inforward aux 

and 6,200 pounds in tail tank. Fuel slip and company weight 

and balance showed the proper fuel load, butfueler put 6,200 

pounds in forward aux and 12,400 pounds in tail tank. We 

were right at maximum structural takeoff weight. Had we not 

noticed the error, possible tail strike on takeoff or worse if 

center of gravity had been aft of controllable limits." 

ACN 587708 

50 
Effective error trapping by technological systems: 

"Due to this bustle, we never accomplished the Before Takeoff 

checklist. When the captain (pilotjlying) pushed the thrust 

levers forward, we got the configuration warning. I put the 

flaps to our takeoff setting and wh.en they reached their 

position, we continued our takeoff. At rotation, much to my 

chagrin, I realized that we indeed forgot the checklist." 

ACN 631420 

Thirteen of the 18 reports of errors trapped by personnel contained enough information to evaluate 

the role of procedures in trapping the error. Pilots were the ones performing the successful trapping 

all 13 of these errors. Only two of the 13 errors were trapped as a specific result of the pilots 

executing SOPs such as checklists and prescribed cross-checks. The other 11 errors were trapped by 

the pilots performing additional cross-checks on their own initiative and resolving suspicious or 

inconsistent performance data. This non-procedural error-trapping is exemplified by the following 

case of a pilot going beyond the SOPs to resolve a feeling of uncertainty after receiving unusual 

results from an ACARS-based pelformance data system that had evidently provided an incorrect 

uplink for technological reasons: 

Non-procedural error trapping by flight crew: 

"[Passenger and baggage count} was entered into ACARS and 

an error response came back that the aircraft was 2.1 forward 

out of trim. I rechecked this because this was odd to have this 

result from a normal aircraft loading .. 1 just could not believe 

this and I called dispatch ... We agreed to use the center of 

gravity calculator and do the weight and balance by hand. This 

resulted in a center of gravity trim of7.8, well within limits ... We 

had similar issues with this ACARS' results [on the next 

flight} ... that included a VI speed of -35. Now this is obviously 

an erroneous number, but what if ... this ACARS had generated a 

VI of 122 and a VR of 124 instead ofa silly number like -35 ... [a 

normal VI and VR would have been 145 and 146f. This could 

have generated takeoff numbers that could lead to an aircraft 

prematurely rotating and stalling .. Maintenance h.ad us reset 

the A CARS circuit breaker and the [datalink communications 

radio f. .. circuit breaker and the problem was resolved.l have 

flown this aircraft for years and the numbers coming out of the 

ACARS were not making sense." 

ACN 777532 

This extra level of scrutiny and effort to resolve discrepancies, though not specifically mandated by 

the SOP, is an important safeguard that apparently draws upon pilots' knowledge and prior 

experience to sense when computed performance data are out of reasonable bounds for the specific 

aircraft and operation. We examine the effectiveness and reliability of this kind of experiencebased, ad-hoc error trapping in the Discussion section. 

Among the ASRS reports that met our selection criteria but were not randomly selected to be 

included in our sample was the following illustration of issues affecting the reliability of 

51 
technological error-trapping interventions a they are used in actual practice. We continue our 

examination of this issue in the Discussion section: 

Failure of technological error-trapping system as used in practice: 

Aircraft center of gravity loading became suspect when we received 

"stabilizer green band" EICAS advisory message. The airplane did not 

like the center of gravity setting and hence, the trim setting for the 

weight and balance as received in the final manifest during taxi out. 

The flight manual procedure simply leads you to call maintenance after 

sternly telling you "do not take off!" Maintenance is spring-loaded to 

simply assume it is an aircraft sensor error, and then to defer the 

system. We called dispatch immediately ... to confirm that, yes indeed, 

the airplane truly was loaded with a center of gravity this far forward. 

Our concern was that perhaps the plane had been loaded incorrectly 

(with afurther aft center of gravity, as it usually is on these flights at 

those weights .. .) and that the warning system was working correctly. 

We felt the pLane (weight compression sensors on the landing gear that 

detect a center of gravity) was perhaps telling us the truth, as it was 

intended to do, and warning us that the center of gravity was not as we 

were being told by operations and load planning .. Perhaps the plane 

really was loaded more aft than reported. Until we could get that 

mystery solved, or until maintenance could confirm the weight/balance 

detecting system was in error, malfunctioning, or inoperative, we were 

not ready to accept a simple deferraJ and takeoff-and perhaps get a 

surprise pitch-up or inability to rotate for takeoff Do you see our 

problem? We didn't know if the plane was telling llS the truth, or ifload 

planning was correct and the plane was wrong. We eventually ... taxied 

back to a gate for confirmation from those who loaded the plane and 

from maintenance as to what had transpired so that we could make a 

decision to either defer and take off, or start opening cargo holds to see 

just where the cargo was loaded .. .upon return to the gate, the station 

manager insisted her cargo loaders did in fact load the plane as 

reported-with a 15% center of gravity ... and she was not going to open 

cargo holds to check. She had apiece of paper signed by the cargo/bag 

loaders and that was all the proof she needed. I felt this was kind of an 

in-your-face-captain attitude, "we're telling the truth, now take the 

plane and go fly" was the impression J was getting. Bottom line: 1) the 

plane, and the pilots, were not comfortable with such a 'forward center 

of gravity;" 2) the flight manual procedure would lead one to believe 

the problem is always a maintenance problem-an error in the center 

of gravity sensing system-and not perhaps a true cargo/fuel/bags 

loading problem and an incorrect center of gravity reported to the crew 

by load planning .... " 

ACN 678751 

S2 
r-

-- ---- -'~- " 

I 

r 

! 

I 4.2.7 Role of Incorrect Information 

In 77 of the 112 errors, the pilots received incorrect information from ground personnel for use in 

the cockpit in making inputs to an FMS, laptop performance computer, data table , etc. Pilots' use of 

that incorrect information was not per se coded as a separate error, unless the ASRS report revealed 

a specific , additional mistake by a flight crew member such as omitting a required cross-check or 

verification. However, when the pilots did not identify the erroneous data as such, this was coded as 

failure to trap the error. Sixty-four of the 77 errors in received information were not trapped. 

In 34 of the 112 errors, the pilots received revised performance data after takeoff-too late to set 

flap/trimlY -speeds correctly for takeoff and ensure adequate performance (if the correct data 

required different settings from the incorrect data). These 34 instances are a subset of the 77 cases 

of pilots receiving erroneous information from ground personnel. Receipt of corrected performance 

data after takeoff usually alerted the pilots to the problem, enabling them to mitigate the associated 

threat for the remainder of the flight. In eight of the 112 errors, the pilots mistakenly used 

preliminary load data instead of final data that became available before takeoff. 

4.2.8 "Trapability"of Error by Ideal Procedures/Systems 

For 91 of the 112 errors, the case narrative provided adequate information for an informed, though 

subjective, assessment of whether SOPs ideally executed might have trapped the error (see Method 

section). Our analysis suggests that 88 of these 91 errors could in principle have been trapped. 

There was adequate information for III errors to allow us to consider whether these errors might 

have been prevented by technological systems, including automation, either already in existence or 

likely to be available in the near future. We found that 107 of these 111 errors likely could have 

been trapped, in some cases by systems already available on some aircraft or in the devices some 

airlines use in load preparation and in other cases by systems/devices that could be employed in the 

near future. The Discussion section provides examples of how well-designed and executed 

procedures and technologies might have prevented many of these errors. 

4.2.9 Role of Cognitive and Other Human Factors 

We performed an informed , though highly subjective, analysis of the ways in which cognitive 

factors and other human factors might have contributed to the 112 errors. Twelve distinct factors 

were identified and the frequency with which they contributed to errors is shown in Table 7 

(multiple codings of factors were made for some errors). Discrepancies not being salient, time 

pressure, rushing, and failure to cross-check were the factors most frequently contributing to errors. 

53 
. . -.--- --~~ 

TabJe 7 . Role of Cognitive and Other Human Factor in Errors (n-112) 

Factor Frequency Example 

Discrepancy not salient 22 Ground personnel substituted empty weight for ZFW 

(22,000 pound error); V-speeds, rotation forces, descent 

gradients, pitch attitudes, and thrust settings seemed a bit 

abnormal but only recognized in hindsight after a hard 

landing prompted close review of the load sheet. (ACN 

558282) 

Time Press ure 22 Flight crew received final weights as the aircraft neared 

the runway and they were cleared to line up and wait. 

While rushing the final calculations, the first officer made 

a 10 ,000 pound error in adding the actual fuel onboard to 

ZFW for input into the FMS. (ACN 703116) 

Rushing 20 Flight crew felt time pressure from ground crew's desire 

for on-time departure and rushed to push back in order to 

beat adverse weather; contributed to not noticing fuel load 

error in paperwork. (ACN 538960) 

Not cross-checking 19 Flight crew did not catch their own mistaken substitution of 

ZFW for GTOW and was not "in the habit" of checking the 

calculated against the planned GTOW, which would have 

caught the error. (ACN 632164) 

Expectation bias 16 During check of thrust rating indicator, thrust was actually 

set to Climb but "mind's eye" saw the usual Takeoff 

setting. (ACN 854320) 

Disrupted/disruptive 13 Flight crew recognized that performance calculations 

habit pattern called for an unusual flap setting, briefed this correctly, 

but out of habit set the usual (incorrect) flap setting. (ACN 

625930). 

Distraction 11 Final weights arrived during taxi-out and flight crew was 

distracted communicating with ATC; contributed to 

failure to notice that actual weights had increased 

significantly above planned weights. (ACN 668766) 

Not being proactive 10 Flight crew suspected overweight aircraft based on 

sluggish takeoff performance; they compensated well 

during takeoff but did not recognize or act on the 

implications for landing. (ACN 795525) 

Fatigue 8 "Tired and somewhat fatigued" from four-day trip with 

extended duties and early wake-ups, the pilot did not 

notice that the performance data received on the flight 

deck printer was for the previous day' flight, which was 

25,000 pounds lighter. (ACN 742390) 

continued on next page 

54 
Table 7. Role of Cognitive and Other Human Factors in Errors (continued) 

Factor Frequency Example 

Workload spike 7 Flight crew did not catch incorrect fuel value while 

rushing to input a newly received flight plan into the 

FMS and complete the before start checklist. (ACN 

530341) 

Prospective memory 6 Flight crew planned and briefed an unusual flaps-20 

takeoff, but after 45 minute delay, during taxi-out, 

called for and set the usual flaps-8 setting. (ACN 

842662) 

Confusion 4 Runway construction NOT AM provided length of the 

closure, requiring the dispatchers and crews to 

calculate the runway available; confusion about this 

led to overweight landing. (ACN 488866) 

4.2.10 Consequences of Errors 

Information was adequate to evaluate consequences of all 112 errors. Major consequencesincluding actual damage , handling/stability problems, significantly reduced performance, and 

violation of the aircraft's limitations-resulted from 16 of the errors. Another 59 errors led to 

minor consequences that could have been major if circumstances such as runway length or weather 

had been different and 5 other errors led to no worse than minor outcomes in any likely 

circumstances. Twelve errors led to an additional error and 20 errors were trapped , preventing any 

adverse outcome . 

Evaluation of Errors Having Major Adverse Consequences. The 16 errors having major outcomes 

are described in Table 8. 

55 

J 
Table 8. Error Having Major Adverse Consequences (n=16) 

ACN Performance Error Consequence 

558282 Ground personnel omitted passenger Hard landing. 

and cargo weights from gross weight 

calculation . 

669783 Ground personnel provided incorrect Exceeded aircraft structural limitation . 

baggage/cargo weight data. 

529324 Ground personnel provided fuel weight Tailstrike during takeoff. 

of 13 ,100 rather than 113,100 pounds, 

resulting in a 100,OOO-pound in error. 

585397 First officer's math error on CG Uncommanded pitch-up during takeoff 

calculation caused crew not to detect roll below VI. 

aircraft loading aft of CG limitation. 

580459 Ground personnel failed to reflect Uncommanded pitch-up during landing 

heavier-than-normal bag weights in flare and also during taxi-in. 

performance calculations. 

632164 First officer entered ZFW in the GTOW Sluggish takeoff/climb and airspeed 

line of the FMS CDU, resulting in a decay with stall buffet in cruise. 

39,000 pound error. 

472646 (Flight crew surmised that) passenger Airspeed decay and stall buffet entering 

and/or baggage weights provided by holding pattern at cruise altitude. 

ground personnel were incorrect. 

804855 Fuel weight entered by ground Airspeed decay in cruise. 

personnel as 12,000 rather than 120,000 

pounds, resulting in 108,000 pound 

error. 

695467 Ground personnel used weights marked Inadequate takeoff and cruise 

in kilograms on cargo boxes as weights performance. 

in pounds; units not marked saliently on 

load plan. 

580202 Ground personnel provided incorrect Aircraft exceeded structural weight 

weight value for forward bin load. limitation and aft CG limit for two 

flights. 

540556 Cold-soaked laptop performance Un commanded pitch-up during takeoff 

computer produced incorrect pitch trim below VINr speeds followed by highvalue. speed RTO. 

672308 Ground personnel delay in providing Pushback and taxi-out while exceeding 

final weight closeout. aircraft structural limitation , requiring 

gate return and inspection. 

continued on next page 

56 

I 

- ------ J 
rI 

I 

L .. _ 

Table 8. Errors Having Major Adverse Consequence (continued) 

ACN Performance Error Consequence 

658615 Dispatch did not identify an aircraft- Exceeded aircraft structural limitation. 

specific difference in the cargo 

compartment weight limit and the 

crew's laptop performance computer did 

not reflect that limit. 

625930 Flight crew, distracted by operational Long takeoff roll, out-of-trim condition 

and non-operational concerns and during rotation. 

subject to habit capture, calculated 

performance data requliing an unusual 

flaps-IS takeoff but set flaps to the usual 

5 degrees; 4,000 pounds overweight for 

the flap setting actually used. 

854320 Flight crew misread thrust rating Long takeoff roll, inadequate 

indicator during preflight preparation performance during initial climb . 

and took off using climb rather than 

takeoff thrust. 

793424 Ground personnel provided incorrect Inadequate performance at planned cruise 

passenger and cargo weights, resulting altitude, fuel over-burn during cruise 

in 40 ,000 pound error. requiring an intermediate fuel stop. 

By definition, none of these 16 errors was trapped. However, we determined that 11 of these errors 

could have been trapped by well-designed operating procedures- ground in some cases, cockpit in 

others-carefully followed (report narratives were not sufficient to evaluate four of the 16 errors). 

Further, eight of the 16 errors could have been trapped by a well-designed autonomous aircraft 

weight/trim sensor system (if used appropriately, of course). Another six errors might have been 

trapped with existing or potential automated error checking functions in ground computers and 

flight deck FMS systems. . 

Cognitive/Human Factors Associated with Errors Having Major Adverse Consequences. Among 

these 16 errors with major consequences, most of the cognitivelhuman factors contributing to less 

consequential errors also played a role (Table 9). 

57 
Table 9. Role of Cognitive and Other Human Factors 

in Major Outcomes (n=16) 

Factor Incidence Among 

the 16 Errors 

Di crepancy not salient 6 

Time pressure 2 

Disrupted habit pattern 2 

Workload spike 0 

Fatigue 2 

Expectation bias 4 

Distraction 2 

Pro pecti ve memory 1 

Rushing 3 

Not being proactive 3 

Not cro -checking 4 

Confusion 0 

5. Discussion 

The goals of this study were to analyze how errors are made in generating and using aircraft 

performance data (weight and balance, with associated performance speed, thrust, and aircraft 

configuration values) and to identify measures to reduce errors and consequences of errors. This 

analysis covered the entire chain of steps from collection of raw load data, transmission of data 

from one party to the next, computation of aircraft performance, comparison to aircraft and runway 

limitations, entry into aircraft FMSs, and setting trim and flap controls. We were able to draw upon 

four recent studie that examined accidents and incidents involving incorrect aircraft performance 

data (Australian Transport Safety Bureau, 2010; Hughes & Godley, 2011; Laboratory of Applied 

Anthropology, 2008; van Es, 2007) and upon investigation reports of specific accidents and 

incidents. We extended these studies in two ways: 1) collecting and analyzing ASRS reports; and 2) 

collecting information from airlines about the procedures by which performance data are generated 

and provided to flight crews. We then analyzed the cognitive and procedural factors contributing to 

error vulnerability and at the end of this section of our report we propose a wider range of measures 

to reduce these errors than has previously been published. 

From our literature review, we suspected that the small number of actual accidents resulting from 

use of incorrect performance data might be only the tip of an iceberg and that these accidents did 

not differ in kind from far more frequent incidents not ending in accidents-in other words, 

happenstance circumstances such as runway length determined whether incorrect performance data 

caused an accident. Our analysis of ASRS incident reports supports this view: The structure of 

incidents closely resembled that of accidents involving incorrect data. Further, some of the 

incidents in our ASRS et clearly exposed the flight to increased ri k . 

58 
L 

--- ----

Airlines employ multiple safeguards to prevent and to catch data entry errors and in recent decades 

only a few fatal accidents

6 have been reported to result from these errors- which suggests that these 

safeguards are fairly effective. However, our review suggests that the risk of fatal accidents of 

pas enger-carrying airliners is appreciable unless existing safeguards are enhanced. 

In this section we attempt to draw together findings from our literature review, discussions with 

airline personnel, and our analysis of ASRS data. Readers should keep in mind that many biases 

influence reporting of incidents to ASRS; therefore , we cannot infer from our ASRS sample 

conclusions about the relative incidence of events in the overall population of line operations. For 

example, we cannot infer which type of error are most common or which types of aircraft are most 

commonly involved. However, the incident descriptions in these reports provide insight into what 

kinds of errors occur, where they occur, and how they might be prevented or at least caught. Only 

two of the reports in our sample came from ground personnel (consistent with the overall ASRS 

database , which consists predominately of reports from pilots); thus, these reports provide much 

more detailed description of error circumstances in the cockpit than in ground preparation of 

performance data. 

5.1 Locus, Process Step, and Types of Error 

Consistent with findings from previous studies (e.g ., ATSB , 2010, van Es, 2007; see the Literature 

section), more than half of the performance data errors in our ASRS sample were made in ground 

functions such as central load planning , ramp, gate, and station operations. Thus, the industry 

should direct attention to vulnerabilities throughout the performance data processing flow rather 

than focusing only on the flight crew's actions, procedures, and equipment. 

Airlines differ in various aspects of how load information is generated and transmitted, calculations 

are performed, and data are entered into systems (not just the FMS). We identified three of the most 

common procedural structures airlines use to generate and apply load and performance data 

(Figures 1-3). Each of these structures can, in principle , work effectively-but in reality, errors 

occur from time to time at every step of the process in each. 

We rolled ASRS reports of errors into six clusters. The four most frequent clusters were also ones 

associated with substantial risk of adverse outcome: 1) ground personnel errors in obtaining, 

calculating, and entering weight data; 2) FMS data entry errors by flight crew; 3) errors made in 

checking against limitations; and 4) flap and trim configuration errors. A fifth cluster, fuel weight 

errors by either ramp personnel or pilots, was a cross-cutting category of errors identified from 

among the errors in the first two clusters. A sixth cluster, errors by pilots using cockpit laptop 

performance computers, was less frequent in our ASRS sample but equally important based on its 

role in accidents and serious incidents. 

Ground Personnel Errors in Obtaining, Calculating, and Entering Weight Data. These errors led to 

serious adverse outcomes, including a hard landing, exceedence of aircraft structural limitations, 

airspeed decay and stall buffet in high altitude cruise, flight diversion due to excessive fuel burn in 

cruise, and un commanded pitch-up during landing flare . Most of these errors involved incorrect 

data entry, either when using a keyboard and computer entry screen or when handwriting on forms 

passed from one person to another. 

6 Transportation Safety Board of Canada, (2006); National Transportation Safety Board (2004); National 

Transportation Safety Board, (1998). 

59 
1--

One of the airline load-planning specialists with whom we discussed this issue told us that his 

airline had automated the calculation of weight and balance (as a central load planning function), 

taking the human element out of the math and reducing the number of data entries in the 

calculation proce s by automatically transferring counts and weights for passengers, bags, and 

cargo that had been entered in the gate and ramp areas into the central computer. This is good, but 

the system remains vulnerable to entry errors in the gate and ramp functions that provide the 

counts and weight inputs. 

FMS Data Entry Errors. Only five errors in our ASRS sample involved the specific process step 

and error type of flight crews entering data into the FMS. Nevertheless, we examined these five 

errors closely (Table 4) because FMS input errors have been a particular industry concern and FMS 

data entry often occurs after weight values have been checked and verified, thus introducing new 

opportunities for errors close to gate departure when further opportunities for error trapping are 

limited. Four of these errors occurred as the pilots manipulated, processed, or checked information 

to be entered into the FMS: 1) not converting temperature units (ground systems provided 

Fahrenheit but the FMS required entry of the data in Celsius); 2) not noticing a discrepancy 

between the fuel gauges and fuel load data that ground personnel had incorrectly entered on the 

load sheet form, and consequently entering the incorrect data; 3) not noticing that ground personnel 

had not sent the final performance data to the flight deck, and then mistakenly entering the planned 

performance data in the FMS; and 4) using an incorrect data table to obtain FMS inputs (using the 

table that had performance data for an aircraft weighing 270,000 pounds, when the actual weight 

was 370,000 pounds). 

These four errors were classified as FMS data entry mistakes because the pilots committed them as 

they performed manipulations, calculations, or cross-checks that the company procedures required 

them to accomplish while making FMS entries. However, the errors actually occurred before the 

pilots' fingers reached the FMS keyboard to enter the data. The Laboratory of Applied 

Anthropology (2008) study also found that most errors in FMS data entry were not keystroke errors 

by pilots but errors in preparing data for entry. In many cases, the flight crew were provided 

erroneous data but failed to use standard procedures for checking data; in other cases the flight crew 

made errors in manipulating correct data. 

The fifth FMS data entry error in our sample occurred when a pilot mistakenly entered the ZFW 

into the input field for the GTOW, resulting in a weight error of 39,000 pounds, quite large for a 

narrow-body aircraft. Using the erroneous weight, the FMS calculated V-speeds, engine thrust, and 

maximum allowable cruise altitude; consequently, takeoff and climb performance were sluggish, 

airspeed decayed, and stall ~uffet began in high altitude cruise. The same type of error was at the 

heart of several serious incidents previously discussed (A TSB, 2011; Laboratory of Applied 

Anthropology, 2008; AAIB, 2011). 

Errors Made in Checking Against Limitations. In several errors, the performance data process 

produced valid weight and balance values for the aircraft, but then failed at the step of checking the 

calculated values against the limitations of the aircraft~e.g., maximum structural weight for taxiing) 

or against the specific takeoff conditions (e.g., the maximum weight that provides adequate climb 

performance over obstacles in the event of an engine failure). These errors included: 1) using the 

wrong inputs for weights or for performance parameters such as winds, runway, or temperature; 2) 

60 
I 

I not updating for changes in these parameters; and 3) simply not checking to see whether a 

limitation was being exceeded, given correct weight/balance and environmental data. 

Even though in most cases these errors did not cause overt consequences, such as structural damage 

or impaired control of the aircraft, the aircraft was caused to operate outside its tested and approved 

envelope, could have received unrecognized damage , and had reduced safety margins for dealing 

with events such as engine failure . For example, in our ASRS sample a delay by ground personnel 

in providing accurate final weight data led to an aircraft pushing back and beginning its taxi-out 

while exceeding the maximum allowable weight for taxiing . The violation was discovered by 

ground personnel before takeoff and the aircraft was contacted and returned to the gate. However, 

the limitation had already been exceeded and the maintenance inspection that followed found 

damage to a part of the landing gear. 

Flap and Trim Configuration Errors. Some of the most serious errors occurred at the very end of 

the performance data process. The pilots, according to self-reports, recognized before pushback 

from the gate that the performance data required them to use a flap setting that was unusuaL 

However, when the time came to extend the flaps to the setting for takeoff-sometimes much 

later, depending on the airline 's procedures and on taxi delays-these pilots reverted to habit and 

set the flaps to their usual setting instead of the required setting, a phenomenon called "habit 

capture ." In one example, the pilots calculated performance data requiring an unusual flap setting, 

15 degrees, but later set the flaps to the usual setting of 5 degrees. The flight was 4 ,000 pounds 

overweight for the flap setting that they actually used. The result was a long takeoff roll and an 

out-of-trim condition during takeoff rotation. Further, if the flight had experienced an engine 

failure during the critical moments of takeoff, it may not have been able to clear all of the 

obstacles in the path of the departure. 

These habit capture errors are distinct from failing to extend the flaps at all, an extremely serious 

error, which also occurred once among the 112 errors and was caught by the takeoff configuration 

warning system. 

Fuel Weight Errors by Ramp Personnel and Pilots. Our ASRS sample included nine errors related 

to fuel loading, documentation, entry, or verification . Two of these were errors of more than 

100,000 pounds-one resulting in a tailstrike on takeoff and the other in airspeed decay at high 

altitude cruise. The ATSB (2010) found similar errors in its survey of accidents and incidents. 

Because fuel accounts for a significant percentage of the weight of an aircraft at departure, 

particularly for long range flights, errors in loading fuel and in recording and communicating fuel 

weight from the ramp to the flight crew can be a serious problem. Another concern is that fuel 

loading , recording, transmission, and entry are often separate from the procedures used for other 

weight elements (such as passengers and cargo) and thus may not be included in the verification 

procedures established to catch errors in these other weight elements. 

Our cases included examples of pilots performing required cross-checks (e .g., verifying the loaded 

fuel weight shown on the fuel gauges against the flight planned fuel weight) but failing to note a 

discrepancy-apparently expectation bias led them to see the planned/requested value instead of 

what the fuel gauges actually showed. Other fuel errors were subtle and easy for pilots to overlook; 

for example, a fuel handler inadvertently swapped fuel loads in two fuel tanks-the total fuel 

weight was correct but the CG was seriously off. 

61 
Errors by Pilots using Laptop Performance Computers. In our ASRS sample these errors involved 

pilots making incorrect entries into the laptop-either through their own errors or through receiving 

erroneous information - and incorrectly operating the laptop, all of which resulted in using 

incorrect performance data. The consequences of the e errors were minor; however, they po e a risk 

of seriou adverse consequences, as revealed by several accident investigations. The specific data 

entry errors that occurred in the Halifax and Melbourne accidents were also seen in the incidents 

reviewed in Laboratory of Applied Anthropology (2008): one instance of the pilots mistakenly 

using all of the performance data from the previous flight and two instances of the pilots entering 

the ZFW value into the entry field for the GTOW. Three additional entry errors involving 

substitution of ZFW for GTOW during laptop entries were reported in A TSB 2010. 

5.2 Consequences of Errors 

The magnitude of performance data errors in our ASRS sample ranged from small-a few 

pas engers miscounted on a widebody aircraft, amounting to a trivial percentage of the GTOW -to 

very large-more than 100,000 pounds, comparable to the errors that caused accidents. The 

consequences of the e errors ranged from none at all to tails trikes that produced aircraft damage or 

difficulty controlling the airplane during takeoff or landing. Some of the events in our sample were 

similar to those that caused the Halifax accident (use of the previous flight's performance data , 

although not in a laptop) and several other event were similar to the Melbourne accident (a 

significant error in entering weight was transferred to the FMS and used to calculate V -speeds). 

Most of the errors in our sample were of low consequence, which is consistent with what we 

learned from airline personnel: small errors in performance data are relatively frequent in routine 

operations. All of this is consistent with a pyramid picture in which tragic accidents such as Halifax 

are very rare; events without injury or substantial damage but which could have become accidents 

in different circumstances are more common, and events unlikely to cause accidents are far more 

common. Given that it is not feasible to catch all errors, the key questions are: 1) to what extent are 

the generation and detectability of errors with substantial potential for causing accidents similar to 

the generation and detectability of more trivial errors; and 2) how feasible is it to catch almost all 

serious errors, regardless of whether trivial ones slip through? 

An airline performance data manager told us, "The same processes that lead to a 20 pound error can 

lead to a 20,000 pound error." This is true in many respects-for example, consider data entry 

errors: Omission of an entire weight element (such as passengers), numeric transpositions, and 

finger slip errors can be major as easily as minor. 

The numerous errors involving performance data corrections sent to the crew after departure are 

mostly minor. The correction for last minute added/subtracted passengers and bags is typically a 

small percentage of total weight and does not alter performance significantly in most cases. 

(Indeed, if the pilots had not received these small corrections they probably would not have noticed 

any effect on performance.) 

One airline expert pointed out that the frequency of performance data errors reported may partially 

be a function of the airline having a sophisticated system for detecting errors, correcting them, and 

alerting pilots to the revised data; the same errors can pass through less advanced systems unnoticed 

unless there is a highly negative outcome, such as a tailstrike. An airline with a good system may 

appear to have more errors than an airline with a poorer system in which few errors are identified, 

but an effective program can provide insight into the ways errors are generated and lead to methods 

62 
for error-trapping. What we don 't know, can hurt us. This expert's airline established a system for 

notifying pilots of performance data corrections only if the correction (1) exceeded an error 

percentage threshold and (2) could be sent to the flight deck prior to departure . This system 

intentionally suppressed small corrections and ones that might interrupt the pilots during the actual 

takeoff roll. 

A small number of the errors in our sample apparently involved complete failures of the airline's 

system to transmit final weight data to the flight crew on the particular flight. This kind of failure is 

quite serious because it increases the risk that pilots will mistakenly use the preliminary data as 

final data in the FMS7 and the risk of using the previous flight's data (the cause of the Halifax 

accident). Some of the failures to provide final weight data were caught by the pilots but workload 

and distraction during taxi-out undercut pilots' ability to catch these ·failures. 

5.3 Error Trapping 

Only 20 of the 112 errors in our ASRS sample were caught; however, this should not be taken as an 

indication of error-trapping effectiveness of the overall system. Pilots would not be aware of errors 

trapped before data reaches them and pilots are more likely to report their own errors they did not 

immediately catch in order to obtain immunity from FAA action provided by ASRS. However, it is 

noteworthy that of the 15 errors which were trapped and for which we had enough information to 

determine how they were trapped, only two were trapped by systems/automation and two were 

trapped by execution of SOPs. The other 11 were trapped by pilots who sensed that something was 

amiss and went beyond SOPs to resolve the uncertainty ." This suggests that "non-procedural" error 

trapping is important and we will return to this in the subsection on Mitigation . 

We determined (subjectively) that the great majority of the errors in our ASRS sample could in 

principle have been trapped if personnel at each step in generating and using load/performance data 

had followed SOPs as intended and if the SOPs were fully established and well defined. Similarly, 

we determined that the great majority of these errors could, in principle, have been caught by 

technological systems either generally available on airliners or currently feasible but not in 

widespread use. Given that most of these errors could in principle have been caught, why were they 

not? In examining that question , we must keep in mind that neither our ASRS data nor the several 

studies discussed in the Literature section allow one to determine what percentage of errors are 

caught among the millions of airline flights taking place every year. The industry needs this 

information to fully evaluate the effectiveness of existing procedures and technology; nevertheless, 

our study sheds some light on the issue. 

Conceivably , the vast majority of errors are actually caught and we are seeing only a relatively 

handful that slip through ; however, our analysis and our discussions with airline personnel suggest 

that enough errors slip through to pose appreciable risk of major accidents. Our analysis suggests 

that existing error-trapping procedures sometimes fall short for five reasons: 1) many opportunities 

for error occur along the chain of generating and using load and performance data for the millions 

of flights that occur annually; 2) existing procedures do not address all of those opportunities and in 

some cases create additional opportunities; 3) some aspects of procedures are not well aligned with 

the real-world aspects of flight operations; 4) procedures do not fully take into account human 

7 Apparently , some airlines require pilots to enter the preliminary data in the FMS , theoretically to save time 

by completing the fli ght deck set-up with the preliminary data and then updating only if the final data are 

different. 

63 
I -

I 

._

performance characteri tics and limitations and do not provide adequate guidance to human 

operators; and 5) the error-trapping potential of automated ystems has not yet been fully exploited. 

We discuss these reasons mainly with examples from the flight deck because that is where we have 

the most information; however, the principles apply equally to ground procedures. 

Many Opportunities for Error. Multiple steps of recording, entering, and calculating data occur 

before pilots enter resulting data into the FMS and errors may occur at each step (Table 3). 

Safeguards are required for each step but this could lead to a very large and cumbersome checking 

system. Fortunately, however, it is possible to reduce the number of steps as we discuss in our final 

section on Mitigation. 

Existing Procedures Do Not Address All Opportunities for Error. One widely-used and appropriate 

error-trapping procedure requires one pilot to check the actions of another. But if the two checks are 

not fully independent they will fail if based on a common error. For example, a procedure may 

specify that the captain and first officer independently derive V -speeds from a table, but if both 

pilot enter the table u ing the weight values incorrectly calculated by the first officer then the 

speeds they obtain from the table will both be wrong. Similarly, all of the procedural verification by 

station operations, load planners, and pilots can be undone by a prior paperwork error on the ramp. 

Further, although all airlines have a procedural check that the flaps are extended before takeoff, thi 

procedure may not specify checking that the position to which the flaps were set is indeed the 

setting required by the final weight manifest. 

Some procedural aspects can increase vulnerability to error. For example, entering preliminary 

weight and performance data into the FMS increases the risk of using incorrect data if the final data 

are not received or not noticed during taxi-out. The risk is further exacerbated if SOP allows or 

requires pilots to start taxiing before final data are received and entered-a practice frequently 

reported in our ASRS case sample. 

Poor Alignment of Procedural Checks with Realities of Actual Flight Operations. Procedures are 

often written rather idealistically, as if human operators are performing tasks in a vacuum one at a 

time without interruption, with the information needed for each task being available when needed. 

The reality is that operators often must juggle multiple tasks concurrently, are often interrupted, and 

are not provided information when they need the information. Late changes in taxi instructions, 

departure runways, and departure routings force pilots to re-do performance calculations and data 

entry at a time when they are busy with other tasks. This conflict between the ideal and the real 

contributes to many errors and undermines the effectiveness of error-trapping procedures 

(Loukoupoulos, Dismukes, & Barshi, 2009). 

Updated information sometimes arrives too late to be acted on. For example, ground personnel may 

perform a discrepancy resolution procedure and discover an error but the corrected information may 

not reach the flight crew until after takeoff. Ground procedures directed at resolving discrepancies, 

according to our airline sources, seem to be more oriented to paperwork reconciliation than to 

getting information to the flight in time. 

Procedures Not Well Matched to Human Performance Characteristics and Limitations. In both 

previous studies and in our ASRS data we found examples of pilots executing error-checking 

procedures but doing so inadequately or incompletely. For example, in some cases we suspect 

"looking without seeing," in which the individual looks at an item to be checked but does not see 

64 
that something is wrong (Dismukes, Berman , & Loukopoulos, 2007). Looking without seeing may 

occur because the individual does not gaze at the item long enough to fully process the information, 

which is exacerbated by time pressure, and by expectation bias. This bias occurs in part because the 

item checked is correct the vast majority of the time. Individuals may also not notice a discrepancy 

because it is not visually salient; for example, in one ASRS case in our sample the pilots took off 

without having received final performance data , mistakenly using a weight manifest form that had 

remained in the cockpit from a previous flight and not noticing the incorrect date and flight number 

in the small print on the form. Several occurrences of failures in what is called "prospective 

memory" occurred; for example, a pilot noticed a discrepancy and intended to resolve the 

discrepancy later when he had a free moment. But the pilot became busy with last minute 

preparations for takeoff and forgot to go back to the discrepant item. 

Time pressure, rushing, distractions, interruptions, and disruptions contributed to inadequate 

execution of error-checking procedures (Table 7). We suggest that airlines do not provide enough 

guidance to personnel on how to manage the pressures nor do they provide explicit guidance on 

resolving discrepancies-how much discrepancy is acceptable and how to resolve unacceptable 

discrepancies. Some procedures fail to specify pilots should look at and what to verbalize when 

performing a cross-check. We will discuss these issues in more detail in the Mitigations subsection. 

Airlines often fail to explain to pilots why redundancy in checking procedures is necessary and, in 

fact, checking procedures may be cumbersome to execute under time pressure and multitasking 

demands. This, coupled with expectation bias, may lead to inappropriate streamlining and lax 

execution of procedures. 

Automation Capabilities Not Fully Exploited. Automated systems can greatly reduce opportunities 

for human error and can flag errors, but many systems in current use do not go as far as they could. 

For example, all airliners have takeoff configuration warning systems that warn crews if flaps are 

not set but most of these systems do not alert the crew if the flaps are set to a position inconsistent 

with the performance data in the FMS. Also, some older FMSs do not internally calculate V-speeds 

and trim settings, requiring pilots to input this information manually with attendant opportunity to 

error and not providing the opportunity to catch errors by comparing the performance data 

calculated earlier in the process to the values internally generated by the more advanced FMS. 

In the next section we draw upon previous studies and develop our own suggestions for numerous 

ways that error trapping procedures and automated systems could be improved. 

5.4 Mitigation of Performance Data Errors 

In this discussion we focus on the six clusters of performance data error that our ASRS case study, 

results of other studies, and findings of accidentlincident investigations suggested to have the 

greatest risk of serious adverse consequences: 1) ground personnel errors in obtaining, calculating, 

and entering weight data; 2) FMS data entry errors by flight crews; 3) errors made in checking 

against limitations; 4) flap and trim configuration errors; 5) fuel weight errors by ramp personnel or 

pilots; and 6) errors by pilots using laptop performance computers. For each of these clusters of 

error we evaluate two risk mitigation paths: 1) reducing the occurrence of the errors; and 2) 

enhancing the reliability of detecting and correcting the errors once they have occurred. 

Mitigating Errors by Ground Personnel in Obtaining, Calculating, and Entering Weight Data. 

These errors can be reduced by eliminating manual data entries (whether on forms or computer 

65 
keyboards) whenever possible. For example, automatically scanning passenger boarding documents 

at the gate can provide a passenger count to the weight and balance computing system without 

manual intervention, which is prone to error. Similarly, cargo and baggage can be scanned as it is 

loaded on the aircraft, thereby minimizing manual entries and providing an independent 

confirmation of count and scans done earlier in the process, such as at the cargo facility.8 

These errors can be further reduced by having performance data subsystems exchange their data: 

the ramp data-entry system should transmit its counts to the central load-control computer rather 

than simply generating a printout for central load personnel or pilots to hold in their hands and use 

to manually re-enter the data into their own systems. Likewise, the output of load calculations 

(whether from a central computer or flight deck laptop computer) should be uplinked directly to the 

aircraft's FMS to eliminate manual data entry at that stage. 

One procedural means of trapping errors made during the ground functions is to compare the 

preliminary values for TOWs (and subcategories such as ZFW, passenger weight, etc.) that are 

generated during the flight planning process with the corresponding final weight values. This 

comparison can be done by ground personnel or by pilots whenever the final load calculations have 

been completed. The advantage of this comparison is that the preliminary weights are based on prebookings and planned fuel loads while the final weights are calculated independently. Some airlines 

have implemented this comparison but others have not. 

Further, our case data and discussions with airline personnel suggest that this comparison procedure 

can be incomplete even when it has been established in the SOP. For example, several airlines 

established a threshold discrepancy value between the preliminary and final weights that requires a 

response by the pilots, most often contacting dispatch for a new flight plan that includes 

recalculation of the fuel requirement for an aircraft that is heavier than preliminarily planned. 

However, the airlines using this procedure did not require pilots to act on the discrepancy if the 

final weights were less than the preliminary weights. This was probably because, from a dispatch 

perspective, the predicted fuel burns in the flight plan and preliminary load planning data for a 

heavier aircraft would always be adequate for an aircraft that is actually lighter than planned. 

However, it is precisely this condition - a calculated final weight being less than the preliminary 

weight-that might signify that the final weight or its components were incorrect. For example, the 

weight of the passenger load could have been inadvertently omitted altogether from the 

calculations, as occurred in some of the ASRS reports. In order for the comparison of preliminary 

vs. final weight to be an effective trap for this error, discrepancies in either direction must be 

resolved. 

Our discussions revealed that airlines routinely attempt to resolve load discrepancies but apparently 

the norm is to do so after gate departure, frequently only after takeoff and even after landing. This 

practice does not fulfill the role of mitigating risks from performance data errors. We suggest that 

preliminary weights be compared to final weights and discrepancies resolved before departure and 

that this be universally established in performance-data SOPs until the equivalent enor-trapping 

8 We note, however, that an automated system relying on scanning requires back-up procedures in case 

equipment malfunctions. We found errors that occurred when personnel were forced to revert to back-up 

procedures with which they were unfamiliar. Airlines should treat using back-up procedures as a potential 

risk, anticipate the need for their use, and enhance their reliability by training personnel on them. 

66 
function can be reliably performed using other procedures or systems.9 Once a discrepancy has 

been identified, resolution might take the form of placing gate departure on hold and then 

backtracking through the loading processes until verifying whether mi sing weight was, in fact, 

aboard the aircraft, and data calculation re-done if necessary. Resolution might also be 

accomplished by manually checking items on the load sheet for gross errors such as a completely 

missing passenger count. However, a note of caution: We stress that preliminary load data should 

not be entered into the FMS where they might be mistaken for final data. 

We suggest that airlines should establish formal procedures for discrepancy resolution, establishing 

and training specific methods (e.g., how to re-check basic performance data such as passenger 

counts to identify the source of a discrepancy , who to contact for assistance, how to obtain an 

independent, third "tie-breaker" calculation). Because subtle cognitive forces such as expectation 

bias and "looking without seeing" tend to undermine discrepancy detection and resolution, airlines 

should actively train and check formal procedures so that they become norms. Training should 

explicitly inform individual operators about the rationale for independent checks and the ways 

independence can be unwitting undermined. 

Error trapping through technological means can be effective at several steps in the performance data 

process vulnerable to errors by ground personnel. Some errors can be caught early in the process, 

for example, by programming a central load-planning computer to automatically flag omission of 

an entire weight category. However, this approach can miss catching even some gross errors that 

can have serious consequences because weight values normally vary over a wide range (e.g., 

correct fuel weights for the same aircraft may range between 40,000 and 250 ;000 pounds). 

There has been long-term government and industry interest in developing and fielding an onboard 

TOPMS, which in principle could detect and flag any significant weight discrepancy affecting 

performance (NTSB, 1982; ATSB, 2009). This system uses inertial reference sensors to measure 

acceleration during the takeoff roll. An aircraft loaded more heavily than reflected in its 

performance calculations would accelerate more slowly than expected. Slower-than-expected 

acceleration could also result from deficient engine thrust, runway contamination, and other 

factors-regardless of the reason, if the aircraft does not accelerate properly it may not perform 

adequately for the particular runway and obstacle clearance. Of course, to be effective and to avoid 

introducing additional risks, the TOPMS would have to provide its warning early enough in the 

takeoff roll to give the pilots substantial time to react and reject the takeoff while still at low speed. 

Some of the stumbling points in developing a practical TOPMS are (1) obtaining comparison data 

of expected acceleration performance for all aircraft weights and environmental conditions and (2) 

determining proper error tolerances for sounding the alarm for significant performance deficiencies 

but avoiding false alarms or unnecessary warnings during the critical takeoff maneuver. Also, even 

though an effective TOPMS would be valuable, it would provide its warning at a critical high 

workload period-which is not the most desirable approach. It would be far better to develop a 

system to alert pilots before takeoff. We are not aware of any current effort to field a TOPMS. 

Another extremely valuable technological approach to error trapping is to have the aircraft 

autonomously sense its weight and CG. Several current transport aircraft types are equipped to 

9 We recognize that this may slightly delay some flights but we feel that the improvement in safety is well 

worth the cost until reliable but faster and/or less expensive technological means of error trapping can be 

implemented. 

67 
derive their weight from train gauges attached to the three landing gear assemblies. The CG can be 

derived by triangulating from the known location of the landing gear on the fuselage. For example, 

some Airbus model are equipped to calculate aircraft weight and currently include these data 

among the parameter that are stored for accident investigation (flight data recorder) and for flight 

operations quality assurance (quick access recorder). Some Boeing models are equipped to sense 

aircraft weightlCG and warn the crew if the aircraft's pitch trim is set outside the expected bounds 

for the CG location . 

The technology for aircraft weight and CG sensing is not complicated. Theoretically, such a system 

could substitute for all of the performance data processes currently used to determine aircraft total 

weight from individual load components. The FAA and other authorities have issued standards for 

approval of these ystems as primary sources of weightlCG data. These standards, though, are 

difficult to meet because reliability and accuracy would have to be extremely high; without 

independent verification, any errors in the aircraft weightlCG sensing system would be difficult to 

catch and could have major adverse consequences. We are not aware of any efforts by an airline to 

implement such a system as the primary source of weight and balance data. 

However, the autonomous aircraft weightlCG sensing system may be more viable and more readily 

implemented as a secondary source of data; that is, as a valuable cross-check for performance data 

calculations rather than as a substitute, as suggested by the NLR (van Es, 2007). Such a system 

would alert to discrepancies between its own sensed values and those derived from the performance 

data process and entered in the FMS. The latter calculations would remain the primary and 

controlling values. An acceptable margin of difference would have to be established beyond which 

the cause would have to be determined or the performance data processes would have to be 

thoroughly re-checked at all stages to verify their accuracy. We suggest that the tolerance for an 

acceptable discrepancy could be expressed as a percentage of weight but it would be reduced as an 

aircraft structural or operating limitation were approached. Used in this secondary, error-trapping 

role prior to pushback, the only apparent downside would be the risk of false alarms causing 

excessive re-checking of the primary data. Overall, this would be an excellent system to catch large , 

serious errors in weight/CG data. 

Although automated systems can be highly valuable in preventing and trapping errors, they do 

come with some drawbacks that must be dealt with. If a system has more than a very few false 

alarms, human operators tend to discount its warning . Our ASRS case data included an example of 

this tendency in which disregard of an inadequately reliable automated "green trim band" warning 

became institutionalized among in the procedures and practice of both the pilots and maintenance 

technicians of an airline. Operators also tend to develop "automation complacency" (Parasuraman 

& Manzey, 2010), especially if the system's workings are not transparent, and they unwittingly 

relax their own error-checking procedures. Research is required to devise ways to counter these 

reactions to automated systems; in the meantime, training and procedures should explicitly address 

the vulnerability. 

Mitigating FMS Data Entry Errors by Flight Crews. These errors occur near the end of the 

performance data process, often in a period of significant distraction, interruption, and high 

workload on the flight deck just prior to push back from the gate. Further, some airlines require 

pilots to make or cross-check FMS data entries during taxi to the runway, an even more demanding 

period that increases vulnerability to error. Airlines can reduce vulnerability to error in FMS data 

entry by establishing procedures requiring that pushback be made only after final performance data 

68 
have been received, entered, and verified on the flight deck. Further, airlines can provide ground 

personnel and pilots with training and encouragement in controlling rushing and enhancing 

deliberation. 10 

One form of FMS data entry error of particular concern has been substituting ZFW for GTOW, 

prompting the NTSB to recommend (in Safety Recommendation A-aS-OS; see FAA, 200S) 

modifying the FMS system software so that it will accept entry of only one of these two weights: 

ZFW. The source for data entry to the FMS-Ioad manifest or laptop-also would have to display 

only that one weight to the pilots. Some , but not all, FMS were modified as a result of these 

recommendations. Occurrence of this error in our ASRS sample, with serious adverse 

consequences, suggests that this modification should be completed for all aircraft. An autonomous 

weight and balance sensing system, coupled with discrepancy resolution procedures, would also 

address this form of error. 

For the many FMS in current use that are not capable of internally calculating V -speeds and trim 

parameters based on weight data , the pilots have to manually enter at least some of these 

parameters from the source (load manifest or laptop display). Pilots are vulnerable to error in 

making the entries which can result in inadequate aircraft performance. The best way to prevent 

these errors is to automatically uplink both the weights and V -speeds directly to the FMS. The 

source for this uplink is the central load-planning computer in existing installations but it is 

possible that the capability could also be developed for laptop performance computers to be 

directly linked to the FMS. 

Procedural cross-checks also help with error-trapping. To make these procedures as reliable as 

possible, we suggest that airline SOPs should specify the crewmember who challenges and 

responds to each performance value entered and should specify the data source to be consulted in 

making the cross-check. For example, in cross-checking V -speeds the SOP might specify: first 

officer reads VI, Vr, and V2 from the PFD and the captain confirms these values by looking at and 

reading from the load manifest. 

Because error-trapping procedures are not perfectly reliable, they should be supplemented by an 

independent means of verifying parameters. For those advanced FMS that are capable of internally 

generating V -speeds, airlines should take advantage of this capability by requiring pilots to crosscheck the FMS's internally generated values against those derived from an external source (load 

manifest or laptop performance computer calculations shown on its display). The external source 

will consider all of the variables in calculating the parameters while the FMS internal calculations 

may not so the FMS should be considered the secondary source for a gross error check. Even this 

cross-checking between internal and external sources is incomplete , because both depend on the 

same weight inputs; hence weight should also be independently verified, ideally by an autonomous 

weight and balance sensor system. 

While pilots are entering performance data into the FMS, they have an opportunity to assess 

whether these data are in the normal range for the type of aircraft, drawing upon their previous 

experience with normal values under the conditions for the current flight. When pilots notice that 

parameter values seem to be out of normal range, they may be prompted to track down the apparent 

discrepancy and discover an error in the data . This informal or "non-procedural" error-trapping can 

10 Rushing , in response to high workload and time pressure, contributes to many forms of error and 

vulnerabili ty to accidents (Loukopoulos, Dismukes, & Barshi, 2009 , p. 129). 

69 
catch errors made during FMS data entry as well as tho e made earlier in the process. Of the 20 

errors trapped in our ASRS sample, 11 were trapped by this informal proces . ATSB (2010) and 

Laboratory of Applied Anthropology (2008) cited similar examples. 

Non-procedural error-trapping is probably most effective at catching large errors, which are the 

ones most likely to have serious consequences; however, it cannot work in all circumstances. Pilots 

new to an aircraft type are not likely to have a "gut feel" for appropriate performance data. Also , 

pilots operating large, long-haul aircraft (especially more than one variant of the same aircraft type) 

over a variety of routes encounter a wide range of fuel loads and payloads and a correspondingly 

wide range of V -speed and trim values. Thus, the weight information given these pilots may be 

within the range they normally encounter but still quite wrong for the current flight. 

Nevertheless, pilots may benefit from training about the performance parameters that are typical for 

their aircraft and operations, especially if the aircraft is used in a relatively narrow range of 

operational conditions. Although non-procedural error-trapping is not sufficiently consistent and 

broadly applicable to be a primary defense against error, the number of cases in which it has saved 

the day suggests that it is worthwhile for airlines to help pilots develop and use this informal 

defense mechanism. 

Mitigating Errors Made in Checking Against Limitations. Airline safety depends on operating 

within approved limitations and not compromising the associated performance guarantees and 

safety margins for handling contingencies. To mitigate errors involving violations of limitations, 

many of the checks of parameters against the limitations can be automated. Release of final 

performance data to the flight deck can be inhibited until this check is completed for systems using 

a central or station-based process. Laptop performance computers can, and usually do, flag 

violations of limitations; however, some early model laptops do not flag violations saliently. (Some 

simply lock their displays without alerting the pilots that a violation had been detected .) 

Last minute changes pose a special challenge. Whenever there is a change in a load weight, count, 

or position on the aircraft, there must be a corresponding recalculation of all associated 

performance data with a recheck of limitations. Late changes and untimely notification and 

recalculation resulted in many of the errors in our ASRS sample, although these changes are 

typically smalL However, in the case of violation of a limitation, even a small percentage error may 

place the operation outside the approved envelope and compromise safety margins. Further, a 

change in external variables-such as runway, wind, and temperature-may also cause a flight to 

exceed a limitation. Systems for checking limitations and coping with changes should be designed 

to detect and adjust for all of these factors. 

Mitigating Flap and Trim Configuration Errors. Habit capture errors, in which the pilots set flaps 

to the normal position instead of the position required by unusual conditions, are quite difficult to 

trap reliably with existing procedures. Pilots who make these errors may follow prescribed crosschecking procedures but forget that they had planned for an unusual setting by the time they set 

the flaps (especially if flaps are set during taxi) and revert to the setting used in thousands of 

previous flights. 

Vulnerability to these habit capture errors can be reduced to some extent by a combination of 

training and modifying existing procedures. Airline should explicitly train pilots about 

vulnerability to habit capture when atypical flap settings are required . Pilots may want to use 

70 
personal techniques to remind them to use the atypical setting-for example, creating a salient cue 

such placing an empty coffee cup over the flap handle. Checklists can be modified to require a 

cross-check of the required (atypical) flap etting as shown in the performance data against the 

actual flap setting and pilots should be informed that this cross-check is as important as the 

traditional cross-check of the flap selector against the flap indicator. Details of the cross-check 

should be specified explicitly in SOPs and training (e.g., "When you repeat 'flaps fifteen' you 

should read that number from the load manifest paperwork"). 

Technological measures can also help trap these errors. On some aircraft the FMS can sense the 

actual flap setting and in this case the flap setting required by the performance data process can be 

entered into the FMS (preferably by automatic uplink). Then, when the pilots set the flaps, the FMS 

can determine whether the setting is correct and alert the pilots if it is not. 

Trim setting errors can be trapped using similar technology . The CG value from the performance 

data calculations would be uplinked or manually entered into the FMS, which would compare this 

value to the actual CG location sensed by an autonomous weightlbalance-sensing system. The FMS 

would automatically check the sensed position of the horizontal stabilizer trim, and if it differed 

from the required position , alert the pilots. 

These enhanced automatic cross-checking functions would require updating many current FMS 

systems and for many aircraft would require adding databus communication between control 

surface position indicators and the FMS. We suggest that these improvements, though not cheap , 

would significantly improve trapping of the e serious errors and reduce vulnerability to accidents. 

Mitigating Fuel Weight Errors by Ramp Personnel or Pilots. These errors require special attention 

because they can be quite large , amounting to a substantial percentage of GTOW. To reduce these 

errors, airlines should provide fueling, operations, and flight crew personnel explicit training about 

the ways in which fuel errors can occur. Also, airlines should review the procedures used by all of 

these personnel and develop specific cross-checks that provide reliable error-trapping capability. 

Beyond this, with the fuel loading, weight calculations, data entries, and verification procedures 

often separated by time , place, and employee group from those of the other weight components, an 

autonomous aircraft weight and balance sensor system may be the most effective error-trapping tool 

for this error of serious potential consequence. 

Errors by Pilots using Laptop Performance Computers. Many of these errors can be discovered 

through procedural cross-checks and verifications between: 1) the values on the data source for the 

pilot's laptop entries (usually a load manifest that is handed to the crew or received on the flight 

deck via ACARS); 2) the weight and count values shown on the laptop display after data entries are 

complete; and 3) the calculated performance parameters (V-speeds, etc.) entered into the ultimate 

flight deck destination (speed bugs, flap and trim settings, etc). We found that many airlines have 

e tablished such procedures; for example , one pilot reading from the laptop display and the other 

pilot cross-checking the FMS display. 

However, as we have discussed, the effectiveness of these cross-checks is sometimes compromised 

in actual practice . Effectiveness is best accomplished if airlines design the procedures to be very 

specific about what each pilot looks at, cross-checks, and verbalizes in performing the task. 

Training should be equally specific to ensure that habits are established and norms are set for the 

procedures to be performed as designed. 

71 
Because procedures are not perfect error trap , additional countermeasures are needed, such as an 

autonomous weight and balance sensing system. However, while this system would help catch 

errors involving weight/count entries and weight calculations, it would not trap errors involving 

the laptop program's outputs of the other performance parameters (i.e., V-speeds, flap settings, 

etc .). These output errors can be addressed by the measures previously discussed under FMS data 

entry errors. 

5.5 Summary of Error Mitigations 

Table 10 summarizes our suggestions for strategies for reducing and trapping performance 

data errors. 

Table 10. Summary of Mitigation Strategies for Errors with Major Consequences 

Error Cluster Key Vulnerabilities Error Reduction Error Trapping Strategies Strategies 

Errors by ground Manual data entry. Scan loads as they are Compare predicted to 

personnel with boarded. final performance data. 

weights/counts. 

Last minute Link sub-systems so Cross-check with 

changes. data are passed independent counts. 

automatically. 

Cross-check with 

autonomously sensed 

weight/balance. 

Non-procedural gross 

error checks by pilots. 

Resolve discrepancies 

revealed by all above. 

Errors with fuel Manual data entry. Train ground and Cross-check with 

weights. flight crews about autonomously sensed 

these vulnerabilities. weight/balance. 

Inadequately Non-procedural gross 

developed error checks by pilots. 

procedural crosschecks. 

Lack of salience of Resolve discrepancies 

cues to error. revealed by all above. 

continued on next page 

72 
TabJe 10. Summary of Mitigation Strategies for Errors with Major Consequences (continued) 

Error Cluster Key Vulnerabilities Error Reduction Error Trapping Strategies Strategies 

Errors by Manual data entry. Train pilots on Establish and train 

pilots using managing workload and detailed procedures for 

laptop distraction. cross-checking manual 

performance entries and transfers. 

computers. Man ual transfers of Automatically uplink Cross-check with 

laptop outputs into input data to laptops and autonomously sensed 

subsequent data entries. downlink output data weighUbalance 

from laptops to FMS . (effective for weight 

errors only). 

Inadequately developed Cross-check of V -speed 

procedural cross-checks. and configuration 

parameters between 

laptop calculations and 

internal FMS 

calculations. 

Last-minute changes. Non-procedural gross 

error checks by pilots. 

Resolve discrepancies 

revealed by all above . 

Errors by Manual data entry. Train pilots on Establish and train 

pilots with managing workload and detailed procedures for 

FMS data distraction. cross-checking manual 

entries. entries and transfers. 

Mistaken substitution of Standardize on either the Automatic cross-check 

ZFW/GTOW values. ZFW or the GTOW of FMS weight entries 

entry. with autonomously 

sensed weighUbalance . 

Inadequately developed Eliminate the other field Automatic cross-check 

procedural cross-checks. from the source data and of V -speed and 

FMS input screen. configuration 

parameters between 

manual/up linked FMS 

inputs and internal 

FMS calculations. 

Last-minute changes. Automatically uplink Non-procedural gross 

, input data from central error checks by pilots. 

computers or laptops to 

FMS. 

Suppress pushbackuntil Resolve discrepancies 

all performance data revealed by all above. 

entries are completed 

and cross-checked. 

continued on next page 

73 
Table 10. Summary of Mitigation Strategies for Errors with Major Consequences (continued) 

Error Cluster Key Vulnerabilities Error Reduction Error Trapping Strategies Strategies 

Errors in Manual data entry. Train pilots on Establish and train 

verifying data managing workload detailed procedures 

against and distraction. for cross-checking 

limitations. manual entries for 

performance data 

including runway/ 

environmental factors. 

Inadequately developed 

procedural crosschecks. 

Last-minute changes in Suppress pushback 

load data or runway until all performance 

/environmental data. data reconciliations 

are completed and 

last-minute corrections 

provided to pilots. 

Alerting to limitation Provide salient 

violations not alerting to limitation 

adequately salient on violations on computer 

some computer displays. 

displays. 

Errors by pilots Habit capture of Train pilots about Automatic crossin setting flap unusual flap setting by these specific check between 

configuration. the usual one. vulnerabilities. required flap/trim 

settings as uplinked to 

the FMS and the 

actual settings on the 

wing and stabilizer. 

High workload during Establish and train 

period between procedures to specify 

receiving the required the cross-check 

flap setting and between actual 

extending the flaps. configuration and 

required configuration 

as shown on a source 

document. 

Extended time delay 

between receiving the 

required flap setting and 

extending the flaps. 

74 
The risk of serious adver e consequences from these errors warrants efforts to improve SOPs and 

develop technologies for error trapping. Performance data errors can be reduced, to some degree, by 

procedures and technology that minimize manual data entry. SOP cross-checks and verifications 

can be defined, trained, and inculcated into line norm so as to provide and maintain independent 

verification of data entries. Informal "gut checks" and heuristics pilots sometimes use to identify 

out-of-bounds performance data can catch some errors, especially gross errors that may have the 

highest consequences, but such ad hoc efforts are not reliable enough to depend on. Some airlines 

have established a network of redundant and overlapping procedural cross-checks to improve the 

overall reliability of error-trapping," but as the ATSB noted in its investigation of the Melbourne 

accident, too many overlapping cross-checks can cause confusion and undercut human operators' 

perception of the importance of each individual procedure. 

What is essential in airline procedural improvements? Probably the two most essential points are 

(1) make discrepancy resolution a ·norm in line operations (supported by procedures and training) 

and (2) recognize and account for the challenge of the last-minute changes that are inherent in 

line operations. 

On the technology side, the most reliable, effective, and independent means to trap weight errors 

from most sources would be an autonomous onboard weight and balance sensing system. Such a 

system is feasible with current technology and would provide a secondary source to verify weight 

and balance and to identify and resolve discrepancies. Beyond trapping weight and balance errors, 

though, additional cross-checks are required to ensure that performance parameters are correctly 

displayed in the FMS and set in the flap selector, trim control, and engine thrust selector. Existing 

technology could be applied to automate most of these final cross-checks by enabling the FMS to 

sense flap and trim positions and to compare the V -speeds that the FMS receives from the 

performance data calculations with those from its internal calculations. 

The airline industry is fortunate that performance data errors have not yet caused accidents with 

large numbers of passenger fatalities, yet our review suggests this potential exists. The FAA's 

proposed new regulatory standards for considerations of flight crew performance and error in the 

design of aircraft equipment would, if promulgated as a final rule, address many of the relevant 

issues in a generic sense for new aircraft designs. However, older designs still in airline service 

would also have to be retrofitted with similar equipment or compensating actions taken to achieve 

the same risk controls. Our analysis, which draws upon several previous studies, presents a range of 

specific measures the industry can take to substantially reduce the potential for such accidents. All 

of these mitigations are achievable but some of them would require airlines to make significant 

investments (especially those operating aircraft with older FMS and databus communications 

systems). Cost-benefit analysis is beyond the scope of this study but the risks and potential 

consequences of performance data errors are substantial and the safety benefits of mitigating them 

are clear. Continued research and development can help by evaluating the effectiveness of the 

mitigations we suggest and by creating new approaches to mitigations-possibly at lower cost. 

The importance of these mitigations will grow as NextGen is implemented and the volume of flight 

operations increases, which will in turn increase the volume and tempo of operations required to 

prepare aircraft for flight. This greater volume will increase the number of opportunities for 

performance-data errors and the increased tempo will make it more challenging to trap errors before 

they become consequential. Also, with most information transmitted via datacom, opportunities for 

II See AAIB, 2009b and AAIB, 2011 incident reports; ATSB (2011) Melbourne accident report). 

75 
error will increase because operators are prone to accept messages without checking content 

critically . 

Planning and research for NextGen should address this crucial aspect of flight preparation that 

occurs before aircraft begin to taxi. The mitigations described in Table 10 are all applicable to both 

current operations and NextGen operations. In particular, increasing the use of automation - with 

appropriate safeguards-to generate and transmit load and performance data will support the 

increased volume and tempo anticipated under NextGen . 

76 
6. References 

Air Accidents Investigation Branch (2009a). AAlB Bulletin: 1112009 (G-OJMC) 

(EWIG2008/l 0108). Hampshire , United Kingdom: Air Accidents Investigation Branch. Air 

Accidents Investigation Branch (2009b). 

Air Accidents Investigation Branch (2009b). AAlB Bulletin: 1212009 (G-VYOU) 

(EWIG2009112104). Hampshire , United Kingdom: Air Accidents Investigation Branch. 

Air Accidents Investigation Branch (2011 ). AAlB Bulletin: 1212011 (G-NIKO) (EWIG2011104129). 

Hampshire , United Kingdom: Air Accidents Investigation Branch . 

Australian Transport Safety Bureau (2009). Tailstrike, Melbourne Airport, Vic., 20 March 2009, 

A6-ERG, Airbus A340-54I (AO-2009-012). Canberra: Australian Transport Safety Bureau. 

Australian Transport Safety Bureau (2011). Tailstrike, Melbourne Airport, Vic., 20 March 2009, 

A6-ERG, Airbus A340-541 (AO-2009-012). Canberra: Australian Transport Safety Bureau. 

Australian Transport Safety Bureau (2010). Aircraft loading occurrences July 2003 to June 2010. 

Australian Transportation Safety Bureau Research and Analysis Report AR-2010-044. 

Aviation Safety Reporting System (2012). ASRS Database Items: An outline of the ASRS taxonomy. 

Retrieved from http://asrs.arc.nasa.gov/search/dbolldatabaseitems.html. 

Dismukes, R.K., Berman, B.A. & Loukopoulos, L.D . (2007). The Limits of Expertise: Rethinking 

Pilot Error and the Causes of Airline Accidents. Ashgate Publishing Company. 

Federal Aviation Administration (2005). Letter of June 6,2005, from Marion C. Blakey, 

Administrator, Federal Aviation Administration, to Mark V . Rosenker, Acting Chairman, 

National Transportation Safety Board. 

Federal Aviation Administration (2008) Advisory Circular (FAA AC 20-161). Retrieved from: 

http://www .airweb .faa .gov /Regulatory%5Fand %5FGuidance%5FLibrary/rgAd visoryCircul 

ar.nsf/0/3bf81a7d4b07ddb886257427005781 a6/$FILE/ AC%2020-161.pdf 

Federal Aviation Administration (2009). Certification of Flight Management Systems. ANM-111-

09-006. Retrieved from http://www.faa.gov/aircraftlair certldesign approvals/transport/ 

Cert U pdate/Edi tion21-3 O/medialEdition27 .pdf 

Federal Aviation Administration (2011).1 4 CFR Part 25 Installed Systems and Equipment for Use 

by the Flightcrew. Federal Register, 76(23),6088-6092. 

Henriqson, E., Winsen, R., Saurin , T. A. , & Dekker, S.W.A. (2010). How a cockpit calculates its 

speeds and why errors while doing this are so hard to detect. Cognition Technology Work, 

13(4), 2l7-231. 

Hughes, K.L. & Godley , S.T. (2011). Take-off performance calculation and entry errors: A global 

perspective. (Research and Analysis Report AR-2009-052). Australian Transport Safety 

Bureau: Canberra. 

77 

- --- .. . 
Human Factors Harmonization Working Group (2004). Flight Crew Error / Flight Crew 

Performance Considerations in the Flight Deck Certification Process, June 15,2004. 

Retrieved from httQ:llwww.researchintegrations.com/hf-hwg/final-re12ortlhfhwg-finalreport-2004-mainbody .pdf 

Jarvis, S., Todd, M., & Burian, B. K. (2010). Data Entry Error Workshop. Ninth International 

Symposium of the Australian Aviation Psychology Association. 

Laboratory of Applied Anthropology. (2008). Use of erroneous parameters at takeoff (No. DOC 

AA 556/2008). Paris: Laboratory of Applied Anthropology. 

Loukopoulos, L. D. , Dismukes, R. K ., & Barshi, 1. (2009). The multitasking myth: Handling 

complexity in real-world operations. Burlington , VT: Ashgate. 

National Transportation Safety Board (1982). Safety Recommendations A-82-152 through -169. 

Retrieved from htt12://www.ntsb .gov/doc1ib/reclettersI1982/a82 152 169.pdf 

National Transportation Safety Board (1998). Uncontrolled Impact with Terrain, Fine Airlines 

Flight 101, Douglas DC-8-61 , N27UA, Miami, Florida, August 7,1997. Aircraft Accident 

Report NTSB/AAR-98/02. Washington , DC. 

National Transportation Safety Board (2004). Loss of Pitch Control During Takeoff, Air Midwest 

Flight 5481, Raytheon (Beechcraft) 1900D, N233YV, Charlotte, North Carolina, January 8, 

2003. Aircraft Accident Report NTSBI AAR -04/0 1. Washington , DC. 

National Transportation Safety Board (2005). Safety Recommendations A-05-03 through -07. 

Retrieved from httQ://www.ntsb.gov/doc1ib/recletters/2005/A05 03 07.pdf 

Parasuraman , R. & Manzey , D.H. (2010). Complacency and bias in human use of automation: 

Attentional integration. Human Factors, 52(3),381-410. 

Santoni, F. & Terhune, J. (2000). Erroneous takeoff reference speeds. Aero, 11 (July), 15-25. 

Retrieved from http://www.boeing.comlcommercialJaeromagazine/aero l1/erroneous.html 

Transportation Safety Board of Canada. (2006). Reduced power at take-off and collision with 

terrain, MK Airlines Limited, Boeing 747-244SF 9G-MKJ, Halifax International Airport, 

Nova Scotia, 14 October 2004 (A04H0004). Quebec , Canada: Transportation Safety Board 

of Canada. 

van Es., G. W. H. (2007). Analysis of aircraft weight and balance related safety occurrences. 

(Report NLR-TP-2007-153). National Aerospace Laboratory NLR: Amsterdam. Retrieved 

from http://www.skybrary.aero/bookshelf/books/ 1149.Q4f 

78 

---.. ---- --
Appendix A. Aircraft Type 

Aircraft Frequency 

Airbus 320 Series 11 

Boeing 727 4 

Boeing 737 35 

Boeing 747 6 

Boeing 757 4 

Boeing 767 7 

Boeing 777 6 

Boeing/Douglas DC-lO 1 

BoeinglDouglas DC-8 2 

Embraer Regional Jet 2 

Boeing/Douglas MD-ll 1 

Boeing/Douglas MD-80 Series 6 

Canadair Regional Jet 6 

Turboprop (various) 9 

Total 100 

79 
l 

Report Documentation Page Form Approved 

OMB No. 0704-0188 

The public reporling burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing dala sources, 

gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 

collection of information, including suggestions for reducing this burden, to Department of Defense, Washington Headquarters Services, Directorate tor Information Operations and 

Reports (0704·0 188), 1215 Jefferson Davis Highway, Suile 1204, Arlington, VA 22202·4302. Respondents should be aware that notwilhstanding any other provision of law, no person 

shall be subject to any penalty tor failing to comply with a colleclion of informalion if il does not display a currently valid OMS control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YY) 12. REPORT TYPE 3. DATES COVERED (From - To) 

01-06-12 Technical Memorandum 

4. TITLE AND SUBTITLE Sa. CONTRACT NUMBER 

Performance Data Errors in Air Carrier Operations: Causes Sb. GRANT NUMBER 

and Countermeasures 

Sc. PROGRAM ELEMENT NUMBER 

6. AUTHOR(S) Sd. PROJECT NUMBER 

Benjamin A . Berman, R. Key Dismukes, and Kimberly K. Se. TASK NU MBER 

lobe 

Sf. WORK UNIT NUMBER 

031 102.02.01.35.11 IB.l2 

7. PERFOR MING ORGANIZATION NAME(S) AND ADDRESSES(ES) 8. PERFORMING ORGANIZATION 

NASA Ames Research Center REPORT NUMBER 

Moffett Field , California 94035-1000 TH-092 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10, SPONSORINGIMONITOR'S ACRONYM(S) 

National Aeronautics and Space Administration NASA 

W as hington , DC 20546-0001 SPONSORING/MONITORING REPORT NUMBER 

NASAITM-20 12-216007 

12. DISTRIBUTION/AVAILABILITY STATEMENT 

Unclassified- Unlimited 

Subject Category: 03 Availability: NASA CASI (301) 621-0390 Distribution: Nonstandard 

13. SUPPLEMENTARY NOTES 

Point of Contact: Key Dismukes, NASA Ames Research Center, MS 262-4, Moffett Field , CA 94037 

14. ABSTRACT 

Several airline accidents have occurred in recent years as the result of erroneous weight or performance data used to 

calculate V-speeds, flap/trim settings, required runway lengths, and/or required climb gradients. In this report we 

consider 4 recent studies of performance data error, report our own study of ASRS-reported incidents, and provide 

countermeasures that can reduce vulnerability to accidents caused by performance data errors. Performance data are 

generated through a lengthy process involving several employee groups and computer and/or paper-based systems. 

Although much of the airline indUStry 's concern has focused on errors pilots make in entering FMS data, we determined 

that errors occur at every stage of the process and that errors by ground personnel are probably at least as frequent and 

certainly as consequential as errors by pilots. Most of the errors we examined could in principle have been trapped by 

effective use of existing procedures or technology ; however, the fact that they were not trapped anywhere indicates the 

need for better countermeasures. Existing procedures are often inadequately designed to mesh with the ways humans 

process information . Because procedures often do not take into account the ways in which information flows in actual 

fli ght ops and time pressures and interruptions experienced by pilots and ground personnel , vulnerability to error is 

greater. Some aspects of NextGen operations may exacerbate this vulnerability . We identify measures to reduce the 

number of errors and to help catch the errors that occur. 

15. SUBJECT TER MS 

Performance data errors; FMS errors; Countermeasures, 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION 18. NU MBER 19a. NAME OF RESPONSIBLE PERSON 

OF OF STI Help Desk at email: ABSTRACT PAGES 

UU 88 heJp@sti .nasa.gov 

a. REPORT I b. ABSTRACT c. THIS PAGE 19b. TELEPHONE NUMBER (Include area code) 

U U I U (443) 757-5802 

Standard Form 298 (Rev. 8-98) 

I 

1 _ _ _ 
1

.-~ -~ .

I 

--I I 

I I 

-- . --- ~