16 Nov 2015 - The ATSB have issued their final report into the tailstrike on take-off of 737-800 VH-VZR on 1 Aug 2014.
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.
*** Updated 17 Jan 2017 ***
On 1 August 2014, at about 1034 Eastern Standard Time1 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 Time2. 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.
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 VH-VZR 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 VH-VZR 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.
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 cross-checked 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.
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.
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.
Flight crew operating manual procedure for Vref40 check
Safety issue description: 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.
Proactive safety action taken by Qantas Airways Ltd. Action number: AO-2014-162-NSA-004 Qantas Airways Ltd. (Qantas) has advised that the Central Display Unit pre-flight procedure has been modified as follows. After the take-off data has been verified and compared by both flight crew, they are to check the ‘APPROACH REF’ page and verify the Vref40 speed.
Current status of the safety issue Issue status: Adequately addressed Justification: The action by Qantas provides an additional defence to address the risk associated with this safety issue.
Additional proactive safety action taken by Qantas Airways Ltd. Although no safety issue was identified by the ATSB, Qantas Airways Ltd. advised they also took the following additional safety action: The BEFORE START procedure (FCOM V1 NP 21.32) has been modified; after receipt of the final load-sheet [crew are to] “Check the take-off weight generated by the FMC [Flight Management Computer] against the take-off on the Final Load-sheet for reasonableness. Verify the take-off weight is not greater than that used to calculate the take-off performance data”,...