On 1 August 2014 a Qantas Airways Ltd. (Qantas) Boeing 737-838 aircraft (registered VH-VZR and operated as QF842) commenced take-off from Sydney Airport, New South Wales. The flight was a scheduled passenger service from Sydney to Darwin, Northern Territory.
While the aircraft was climbing to cruise level, a cabin crew member reported hearing a ‘squeak’ during rotation. Suspecting a tailstrike, the flight crew conducted the tailstrike checklist and contacted the operator’s maintenance support. With no indication of a tailstrike, they continued to Darwin and landed normally.
After landing, the captain noticed some paint was scraped off the protective tailskid. This indicated the aircraft’s tail only just contacted the ground during take-off.
What the ATSB found
The ATSB found the tailstrike was the result of two independent and inadvertent data entry errors in calculating the take-off performance data. As a result, the take-off weight used was 10 tonne lower than the actual weight. This resulted in the take-off speeds and engine thrust setting calculated and used for the take-off being too low. As a result, when the aircraft was rotated, it overpitched and contacted the runway.
The ATSB also identified that the Qantas procedure for conducting a check of the Vref40 speed could be misinterpreted. This negated the effectiveness of that check as a defence for identifying data entry errors.
What's been done as a result
Qantas has advised that, in response to this occurrence, the Central Display Unit pre-flight procedure has been modified. This modification requires that, after the take-off data has been compared/verified by both flight crew, they are to check the ‘APPROACH REF’ page and verify the Vref40 speed.
In addition, Qantas also advised that the Flight Crew Operating Manual was amended to include a check that the take-off weight in the flight management computer matched that from the final loadsheet. This check was also to ensure the take-off weight from the final loadsheet was not greater than that used for calculating the take-off performance data.
Data input errors can occur irrespective of pilot experience, operator, aircraft type, location or take-off performance calculation method.
Effective management and systems can significantly reduce the risk of data input errors. Good communication and independent cross-checks between pilots, effective operating procedures, improved aircraft automation systems and software design, and clear and complete flight documentation will all help prevent or uncover data entry errors.
The application of correct operating data is a foundational and critical element of flight safety, but errors in the calculation, entry and checking of data are not uncommon.
Data input errors remain one of the ATSB’s top safety concerns for the travelling public. More information is available from the ATSB’s SafetyWatch initiative.
On 1 August 2014, at about 1034 Eastern Standard Time a Boeing 737-838 (B737) aircraft, registered VH-VZR (VZR) and operated by Qantas Airways Ltd. as flight QF842, commenced take-off from runway 34L at Sydney Airport, New South Wales. The flight was a scheduled passenger service from Sydney to Darwin, Northern Territory. The flight crew consisted of a captain, who was the pilot flying and a first officer, who was pilot monitoring.
The flight crew reported gusty conditions for take-off. During the take-off, the aircraft was rotated at the calculated rotation speed of 146 kt. After the aircraft had reached FL110, the crew turned off the seatbelt sign. At this stage, they received a call from the cabin crewmember seated in the rear galley, reporting that they had heard a ‘squeak’ during the rotation. The flight crew levelled VZR at FL280 to discuss the issue with the cabin crew and conduct the suspected tailstrike checklist. The captain was referencing the head-up guidance system (HGS) during the take-off and recalled seeing the ‘dumb bell’ symbol appear (which is the tailstrike pitch limit), however it did not appear to come into proximity of the aircraft reference symbol (which indicates the aircraft’s pitch).
After a discussion with the operator’s maintenance watch personnel, and given that the aircraft had pressurised normally and was not displaying any indications of a tailstrike or associated damage, the decision was made to continue the flight to Darwin. The flight progressed normally and landed in Darwin at about 1423 Central Standard Time.
After the passengers had disembarked, the captain conducted an inspection of the tail skid of VZR and noticed some paint damage and scrape marks, however the cartridge containing the sensor for a tailstrike was still intact. This indicated that the tailskid had only just contacted the runway during the take-off. The captain phoned the operator’s duty captain to report the damage.
During a follow up phone call, the flight crew were asked to check the take-off performance figures calculated on their iPad and used to conduct the take-off in Sydney. During this check the first officer noted that the take-off weight entered into the on-board performance calculation tool on the iPad was incorrect and was 10 tonne lower than the actual take-off weight. The weight entered into the iPad tool was 66,400 kg instead of the actual weight of 76,400 kg. This resulted in the take-off speeds being calculated as V1 145 kt, VR 146 kt and V2 149 kt instead of V1 152 kt, VR 155 kt and V2 158 kt and a selected temperature of 51° instead of 35°. This reduced the take-off thrust setting from 93.1 per cent N1 RPM to 88.4 per cent. The lower speeds and higher temperature were subsequently entered into the aircraft’s flight management system and used for the take-off from Sydney.
The captain had over 10,000 hours flying experience, including about 1,800 hours on the B737. The captain was free of duty for the two days prior to 1 August 2014. They reported their sleep as normal and did not report any fatigue-related concerns associated with the occurrence flight.
The first officer had over 10,000 hours flying experience, including about 7,000 hours on the B737. The first officer was also free of duty the two days prior to the occurrence flight. While the first officer reported their sleep was broken some of the nights leading up to the occurrence, they also reported their sleep the night prior as being ‘fine’ and that they felt normal on the day of the occurrence.
Observations from the Sydney Airport automatic weather station were recorded every half hour. The surface weather conditions recorded at 1030 were a temperature of 19 °C, wind direction of 310 at 10 kt, QNH 1007 hPa, with no cloud below 5,000 ft and visibility greater than 10 km. There was a note on this observation that from 1030, there would be moderate to severe turbulence below 5,000 ft.
Flight management system
The B737 has a flight management system which includes two flight management computers (FMC), which provide performance and flight path guidance to the crew, amongst other functions. During the pre-flight preparation, normally the first officer enters the aircraft’s zero fuel weight (ZFW) into the FMC. The FMC then adds the ZFW to the fuel on-board to calculate the take-off weight and Vref40 speed. The Vref40 speed is the reference speed for flaps 40 and is used to schedule flap retraction during the climb. This provides the mechanism for an independent check of the take-off weight.
After calculating the take-off speeds and thrust setting using the on-board performance calculation tool (OPT), the flight crew then enter these details into the FMC. The entered speeds and thrust setting are to be compared to the output from the OPT before being used for take-off.
Head-up guidance system
The B737 has a head-up guidance system (HGS) fitted on the captain’s side. The HGS overlays various flight parameters and navigation data over the captain’s outside view. This enables the captain to access, among other parameters, aircraft speed while maintaining their view of the runway.
During rotation, the aircraft tail strike pitch limit symbol will appear when the aircraft is approaching the tail strike angle. As well as the tail strike pitch limit indication, the aircraft reference symbol is also displayed and if the two symbols come in contact, a tailstrike has probably occurred (Figure 1).
Figure 1: Tail strike pitch limit symbol (dumb bell) and aircraft reference symbol as displayed on the HGS
Source: Qantas Airways Ltd. (Qantas)
On-board performance calculation tool
The flight crew used the on-board performance calculation tool (OPT) located on the company supplied iPad to calculate the take-off performance data. The OPT was developed by the aircraft manufacturer and was the same system the operator had used on the previous electronic flight bag laptop prior to the iPad. The crew reported their experience with using the OPT as being about 4 years on both the laptop and iPad.
The OPT has a data entry screen which allows the flight crew to select the appropriate airport, runway, conditions and configuration for take-off (Figure 2 – with take-off data used for the departure from Sydney). The OPT requires the selection of the aircraft registration prior to this point, to ensure the take-off data generated is accurate for that particular aircraft.
Figure 2: Take-off data entry screen in the on-board performance calculation tool for VHVZR showing the erroneous take-off weight (66,400 kg)
The OPT also gives a temperature (51 °C in Figure 2, above) to be entered in the FMC to reduce the take-off thrust from the engines. This allows the aircraft to use a lower engine setting (N1) for take-off, which improves engine reliability. The OPT takes into account the runway length and weight in determining this value to ensure the aircraft can take off within the runway distance available and maintain the required obstacle clearance during the subsequent climb.
Figure 3 shows the OPT data for the correct take-off weight of 76,400 kg. Of note is the difference in the take-off speeds, but also the temperature (51°C v 35°C). The lower temperature for the higher weight is indicative of the need for greater engine thrust for the take-off. This, in part, is due to the runway length and obstacle clearance requirements as noted above.
Figure 3: Take-off data entry screen in the on-board performance calculation tool for VHVZR showing the correct take-off weight (76,400 kg)
The OPT has numerous outputs that allow crew to send or view the take-off speeds and relevant information. One of these is the ‘bug card’, which displays the weight entered, the take-off speeds, flap setting and engine %N1 value (Figure 4). This feature presents this information in a similar format to the informal systems used by flight crew prior to the introduction of electronic flight bags. It also allows the crew to easily view all relevant information for take-off.
Figure 4: Bug card showing the correct take-off weight (76,400 kg) and speeds
Flight crew operations manual procedure
The flight crew operations manual (FCOM) procedure for initially calculating the take-off data in the OPT tells crew to use the take-off weight (TOW) from the provisional loadsheet and add 500 kg. This addition of 500 kg is to allow for small last minute changes to the final TOW, without the need for the crew to recalculate the take-off data unless the change is greater than 500 kg. This is a standard industry-wide technique adopted by operators to reduce the risk of errors during recalculation.
The procedure then calls for the crew to enter the ZFW into the FMC to calculate the TOW and Vref40. It is at this point that the take-off speeds are required to be verified, and the Vref40 speed is to be crosschecked between the FMC value and that previously calculated by the OPT. These values are required to match, with an allowable tolerance of +/- 1 kt to the Vref40 speed. Once the final loadsheet is received, the crew then enter the revised ZFW and other data into the FMC.
If there are no significant changes between the provisional and final loadsheets, then the crew are not required to revise the figures in the OPT based on the arrival of final loadsheet. This is due to the fact that 500 kg was added to the provisional loadsheet figures to allow for last minute changes. As there were no significant changes on the occurrence flight, there was not requirement to revisit the OPT at any stage prior to take-off. However, the purpose of the Vref40 check was to identify any discrepancy between two independently calculated TOWs in the OPT and FMC and despite the lack of changes to the loadsheet, this check could still identify the error.
On the night of 20 March 2009, an Airbus 340-541, registered A6-ERG and operated by Emirates Airlines as flight EK407 sustained a tailstrike and overran the runway on take-off from Melbourne Airport, Victoria. During the overrun, the aircraft struck a localiser antenna, damaging the antenna and part of the airframe. The tailstrike resulted in significant damage to the tail of the aircraft.
The ATSB found that the accident resulted from the inadvertent use of erroneous take-off performance parameters, including speeds and thrust setting. Those erroneous parameters were the result of a take-off data entry error which resulted in the incorrect take-off weight being entered into the electronic flight bag during the pre-flight preparation.
In support of this investigation, the ATSB undertook a research study titled Take-off performance calculations and entry errors: A global perspective. This study reviewed the factors involved in a number of accidents and incidents in the 20 years leading to 2009. That report indicated that the accident involving A6-ERG was just one of many occurrences involving the use of erroneous takeoff performance parameters across a range of aircraft types, operators, locations and types of operation.
On 22 November 2011, during pre-flight performance calculations at Melbourne Airport, the crew of a Qantas B737-476 aircraft, registered VH-TJL, inadvertently used the full length runway 16 distance to calculate the take-off performance figures despite planning a runway 16/taxiway Echo intersection departure. Neither crew identified the error, which produced inappropriately high take-off reference speeds. During the take-off run the crew realised there was inaccuracy in the figures and elected to continue the take-off, rotating the aircraft below the calculated rotation speed (VR).
The error was attributed to the Electronic Flight Bag (EFB) menu structure defaulting to the full runway length. As a result of this incident, Qantas advised that they have modified the EFB to require a positive selection of the runway length.
On 14 October 2013, the crew of a Virgin Australia Airlines B737 aircraft, registered VH VUC, were preparing for a scheduled passenger service from Darwin, Northern Territory to Melbourne, Victoria.
In preparation for the flight, the first officer (FO) prepared two take-off data cards (TODCs), one for a runway 11 full length departure and another for an intersection departure from taxiway ‘Bravo 2’ (B2). The data for a full length departure was entered into the flight management computer (FMC). Due to delays in using the full length of the runway, the crew elected to depart from the B2 intersection. The FO reprogrammed the FMC with the take-off performance data previously transcribed on the TODC for that departure and subsequently cross-checked by the captain.
After take-off, the crew noted that the TODC for the full runway length departure was visible on the centre pedestal, on top of the intersection departure TODC. The crew discussed whether the takeoff from the B2 intersection was conducted based on the take-off performance data for a full runway length departure. While the crew were unable to determine what data was used, in the interests of safety, the event was reported.
The operator conducted an investigation into the incident and identified that the aircraft departed from the runway 11 B2 intersection using the take-off performance data for a full length runway departure.
Data entry errors when programming an electronic flight bag or flight management system are not uncommon (PARC/CAST Flight Deck Automation Working Group 2013). They are usually detected by the flight crew before there is any effect on the aircraft’s performance or flight path. On rare occasions, programming errors can lead to problems with the aircraft’s flight path or performance, and on very rare occasions contribute to aircraft accidents.
This analysis examines the various human performance factors identified during the investigation as having influenced the flight crew’s actions and ability to detect the erroneous data.
Data input error and error detection
There were two independent data entry errors related to this occurrence, which together negated the error check designed to catch a data input error. One involved the captain, who recorded the zero fuel weight (ZFW) and fuel load on a notepad in order to derive the take-off weight (TOW). It was during this calculation that the leading ‘1’ was dropped from the fuel figure, resulting in a TOW of 66,400 kg. This figure was then entered into the captain’s on-board performance tool (OPT) to derive the take-off speeds and engine setting.
The second error occurred when the first officer entered the take-off weight into their OPT. While the first officer reported correctly adding the ZFW and fuel figure to get a TOW of 76,400 kg, the weight entered into the OPT was 66,400 kg. This was likely the result of a transposition error when entering the figure into the OPT. A transposition error occurs when an individual inadvertently swaps two adjacent numbers or letters while speaking or writing down a value or word. In this case, it is likely the intended ‘7’ was entered as ‘6’. As the two derived TOW figures of 66,400 kg matched when the crew compared them, the error was not detected.
An observational study of airline operations examining error detection and recovery noted that ‘less than half the errors committed by crew were actually detected’ (Thomas, Petrilli and Dawson 2004). A number of factors may have increased the likelihood of the crew not detecting the error on this occasion.
As the OPT optimises engine performance for take-off, the speeds will vary for various runway length and weight configurations. This means it is possible to see the take-off speeds used during the occurrence, which were based on a TOW of 66,400 kg, for a TOW of 76,400 kg on a different runway. This makes it difficult for crew to develop a ‘rule of thumb’ or conduct a ‘sensibility’ check on the data as the same TOW will give varying speeds based on location and environmental conditions. As a result, the awareness of the crew in relation to an expected OPT output for a certain weight is not an effective defence for identifying a data entry error.
Additionally, the recent experience of the captain was such that a TOW around 66 T was not unusual and was consistent with recent sectors flown. As such, this figure alone was not enough to trigger the captain that there may have been a data entry or calculation error.
Flight crew operations manual procedure
The flight crew operations manual (FCOM) contained a procedure for conducting a check of the Vref40. This procedure called for the Vref40 speed to be ‘verified and compared’ but did not specify by which method this was to be done. This could lead to flight crew individually checking the figure instead of verbally checking it between them. On this occasion, the crew reported conducting an independent, individual check of this figure without discussing it.
The FCOM procedure for checking the Vref40 speed between the OPT and FMC calculated figures was to ensure that this figure was within +/- 1 kt. The captain reported that it was normal for crew to focus on the last digit of the Vref40 speed to ensure it was within this tolerance. In addition, on this flight, the captain had just set the V2 speed of ‘149’ on the mode control panel for indication on the primary flight display, before moving attention to the FMC for this check. The FMC was displaying the (correct) Vref40 figure of 149 kt, while the OPT calculated Vref40 speed was 139 kt. It is likely that the combination of verifying the last digit of the two figures, both of which were ‘9’ and the proximity of setting ‘149’ to checking ‘149’ negated the effectiveness of this check for the captain.
Expectancy is a factor which can influence how and where people look for information (Wickens and McCarley 2008). Expectancy can be influenced by such things as habit, salience, event rate (how often something occurs) and relevance, among other factors. The first officer reported conducting the Vref40 check and missing the difference between the OPT and FMC figures. Similarly to the captain, the first officer was also checking that the last digit was within tolerance as they had seen the figure vary by 2–3 kt previously and did not realise that a 10 t change in weight would result in a 10 kt difference in the Vref40 speed. This focus on the last digit, combined with an expectation that any error would be apparent in the last digit, reduced the effectiveness of this check.
From the evidence available, the following findings are made with respect to the data entry error and tailstrike involving a Boeing 737-838, registered VH-VZR that occurred at Sydney Airport, New South Wales on 1 August 2014. These findings should not be read as apportioning blame or liability to any particular organisation or individual.
Safety issues, or system problems, are highlighted in bold to emphasise their importance. A safety issue is an event or condition that increases safety risk and (a) can reasonably be regarded as having the potential to adversely affect the safety of future operations, and (b) is a characteristic of an organisation or a system, rather than a characteristic of a specific individual, or characteristic of an operating environment at a specific point in time.
- During the take-off, the aircraft was rotated at a speed about 10 kt lower than required for the aircraft's actual weight, which was sufficient to overpitch the aircraft, resulting in a tailstrike.
- During the calculation of the take-off weight, both the captain and the first officer made independent inadvertent errors in their calculations, which resulted in the same, but incorrect, weight figure being used to calculate the take-off speeds.
- The Flight Crew Operating Manual procedure for crew comparison of the calculated Vref40 speed, while designed to assist in identifying a data entry error, could be misinterpreted, thereby negating the effectiveness of the check. [Safety issue]
Safety issues and actions
The safety issues identified during this investigation are listed in the Findings and Safety issues and actions sections of this report. The ATSB expects that all safety issues identified by the investigation should be addressed by the relevant organisation(s). In addressing those issues, the ATSB prefers to encourage relevant organisation(s) to proactively initiate safety action, rather than to issue formal safety recommendations or safety advisory notices.
All of the directly involved parties were provided with a draft report and invited to provide submissions. As part of that process, each organisation was asked to communicate what safety actions, if any, they had carried out or were planning to carry out in relation to each safety issue relevant to their organisation.
The initial public version of these safety issues and actions are repeated separately on the ATSB website to facilitate monitoring by interested parties. Where relevant the safety issues and actions will be updated on the ATSB website as information comes to hand.
Flight crew operating manual procedure for Vref40 check
Proactive safety action taken by Qantas Airways Ltd.The Flight Crew Operating Manual procedure for crew comparison of the calculated Vref40 speed, while designed to assist in identifying a data entry error, could be misinterpreted, thereby negating the effectiveness of the check.
Safety Issue No: AO-2014-162-SI-01
Sources and submissions
Sources of information
The sources of information during the investigation included:
- the flight crew of VZR
- Qantas Airways Ltd. (Qantas)
- the Civil Aviation Safety Authority (CASA).
Performance-based operations Aviation Rulemaking Committee/Commercial Aviation Safety Team Flight Deck Automation Working Group 2013, Operational use of flight path management systems. Available from www.faa.gov
Thomas, MJW, Petrilli, RM & Dawson, D 2004, ‘An exploratory study of error detection processes during normal flight operations’, Proceedings of the 26th conference of the European Association for Aviation Psychology, Lisbon, Portugal.
Wickens, CD, & McCarley, JS 2008, Applied attention theory. CRC Press, Boca Raton, FL, US.
Under Part 4, Division 2 (Investigation Reports), Section 26 of the Transport Safety Investigation Act 2003 (the Act), the ATSB may provide a draft report, on a confidential basis, to any person whom the ATSB considers appropriate. Section 26 (1) (a) of the Act allows a person receiving a draft report to make submissions to the ATSB about the draft report.
A draft of this report was provided to the flight crew of VZR, Qantas, and CASA.
Submissions were received from the flight crew of VZR, Qantas and CASA. The submissions were reviewed and where considered appropriate, the text of the report was amended accordingly.