KLM B738 at Amsterdam on Jun 10th 2018, takeoff with erroneous takeoff data

Last Update: May 19, 2022 / 18:51:53 GMT/Zulu time

Bookmark this article
Incident Facts

Date of incident
Jun 10, 2018



Flight number

Munich, Germany

Aircraft Registration

Aircraft Type
Boeing 737-800

ICAO Type Designator

A KLM Boeing 737-800, registration PH-BXG performing flight KL-1797 from Amsterdam (Netherlands) to Munich (Germany) with 7 crew (captain, first officer under monitoring and a safety pilot in the cockpit) and 182 passengers, was taxiing for departure from runway 09, beginning of the runway (taxiway N5, 3460 meters/11350 feet takeoff distance available), when ATC queried whether they could also depart from N4 (2460 meters/8070 feet takeoff distance available). The crew declined, the takeoff data were entered into their FMS. While taxiing to intersection N5 winds changed sufficiently so that the crew could accept N4. The aircraft entered the runway at taxiway N4, commenced takeoff and became airborne just about 176 meters/570 feet short of the runway end. The aircraft climbed out to safety and continued to Munich for a landing without further incident.

The Dutch Onderzoeksraad (DSB) complained: "Despite the fact that there was a failure to achieve the predicted performance during takeoff, the involved flight crew did not file an Air Safety Report (ASR) about this occurrence. By the end of August 2018, the operator became aware of the incident. The Aircraft Condition Monitoring System (ACMS) data revealed the exceedance of the “low threshold crossing height” parameter. Although the incident was captured by the Flight Data Monitoring (FDM) program a few days after its occurrence, the incident was believed to be invalid, as many events are. It was put aside for further analysis. The analysis took place in the last week of August, and showed the incident to be valid. This occurrence was consequently classified as a serious incident."

The DSB released their final report concluding the causes of the serious incident were:

Direct cause

The serious incident was caused because the aircraft accelerated too slowly to the incorrect takeoff speeds in relation to the available runway length. This was the result of using erroneous takeoff data, based on the wrong intersection.

Operational factors

The crew had planned an N5 intersection takeoff. They were not able to comply with Air Traffic Control’s request for an N4 intersection takeoff due to performance requirements.

Having heard new wind information, the crew reconsidered and determined an N4 intersection was possible which would reduce the delay. New takeoff performance calculations were completed during taxiing out just before lining up the aircraft for takeoff.

Because the initial intersection had not been changed into the actual intersection in the data necessary for the performance calculation, erroneous takeoff data were generated.

The changed data and the output of the performance calculation were neither checked nor cross checked, although this is included in the procedures. Time pressure and the division of tasks of the three-man cockpit had influence on the occurrence of the incident.

Operator’s procedures do not require the aircraft to be stopped when new takeoff performance calculations have to be made during taxiing out. Some other operators do have included this requirement in their procedures.

The erroneous takeoff performance data resulted in an effective runway length that was 1,034 metres less than the length used for the calculation. In case of an aborted takeoff at V1 the aircraft would have been unable to stop on the runway. In the event of an engine failure after V1 there would have been insufficient runway length remaining to accelerate the aircraft to the minimum V2 speeds. This all resulted in reduced safety margins during the takeoff.

Despite some training, the crew did not recognize the need to add more thrust when the end of the runway approached and therefore did not add thrust. Not adding thrust in these situations has been identified in other earlier investigations.

Organizational factors

The process of independent performance calculation and crosschecking should be independent of crew composition as well as the timing of the calculation.

Operational pressure caused the crew to choose for an unplanned, last minute change in runway intersection. As other cases of this operator show, it was not an isolated event, nor a new phenomenon. Although the existence of operational pressure was already signalled in 2017, it still appears to exist.

The serious incident was not reported by the crew to the operator nor were the flight recorders secured.

Although mentioned in the internal report of the operator, no actions were taken to raise awareness of the importance of reporting and securing flight recorders following a serious incident.

Two other, similar, serious incidents were not reported to the Air Safety Investigation Authorities by the operator. This excluded the possibility of an independent safety investigation.

The known problem of takeoff data performance occurrences Over the past, several takeoff incidents have occurred. Despite developments, no technical solutions are yet available to prevent this. Therefore, the solution must be sought in operational measures. Changing takeoff data during taxiing is a critical process and deserves full and undivided attention of flight crews. Continuing taxiing precludes this, as the majority of related incidents have shown.

The DSB analysed:

Reduced safety margins

The takeoff information that was used for the Lintop calculation, mentioned intersection N5 for takeoff instead of N4. The takeoff data calculated by Lintop was loaded into the FMC without being checked by either the captain or the first officer. Therefore the thrust setting was based on the assumption that the available runway length was 1,064 metres (the difference between the two intersections) longer than it actually was.

As a result of the reduced takeoff thrust application, the engines produced the thrust required for a runway with a TODA of 3,494 metres, resulting in a slower acceleration than needed. This explains why the aircraft became airborne at the very end of the runway. The speed at which the takeoff could still be safely rejected (V1 154 kts) was based on these erroneous data. Calculations afterwards showed that the correct V1 should have been 143 kts in the current conditions. The actual rotation speed VR, as calculated was 157 kts, while the correct VR should have been 144 kts.

During the investigation, the aircraft manufacturer calculated that the aircraft would have been unable to stop on the runway in case the takeoff had to be aborted at V1. Due to the slower than required acceleration of the aircraft during the takeoff roll, the aircraft reached the calculated V1 further down the runway with insufficient runway length remaining to stop the aircraft within the confines of the runway.

In the event of an engine failure after V1, there would have been insufficient runway length remaining to accelerate the aircraft to the minimum V2 speeds.

The risk of the aircraft reaching the end of the runway without being able to become airborne, would have been significant. This all resulted in reduced safety margins during the takeoff.

Last minute changes and time pressure

On every flight, regardless of aircraft type, the takeoff performance calculation has to be conducted. In their procedures, both the operator and Boeing stress the importance of an independent takeoff performance calculation by each crewmember as well as crosschecking both results. This also applies to last minute calculations in case of a runway change or changing weather conditions. The most important safety net to avoid takeoff performance errors will be removed if this procedure is not followed.

Cross checking of the new data by the captain and the first officer was not done for several reasons. The captain did not crosscheck the takeoff performance data because the time between changing and inserting takeoff data into the FMC and lining up on the runway was very short and ATC-instructions followed in quick succession. Further was the captain’s attention aimed at monitoring the first officer and he omitted the crosschecking procedure due to the perceived time pressure. The acting first officer was focused on aligning the aircraft on the runway without paying attention to the changed takeoff performance parameters. The first officer trusted and relied on the two other, experienced crewmembers to have correctly processed the new Lintop calculation.

As it turned out, assumptions were made by all crewmembers, resulting in three different situational awareness states, which were a direct precursor of the incident. The safety pilot trusted and assumed more or less that the captain would check the new performance, while inserting it into the FMC, and the captain omitted the crosschecking procedure due to the perceived time pressure. This resulted in the newly entered data not being checked by anyone, although the procedures do require doing so, hence the entry error for the performance calculation went unnoticed.

One of the factors that played a role was that the crew continued taxiing after they had accepted the intersection change. The captain had indicated to ATC that they could also accept an intersection takeoff from N4, before the outcome of the performance calculation was received, based on his experience while they were taxiing. While his estimation proved to be correct, it precluded any risk evaluation by the crew.

Continuing taxi while the crew had accepted, or requested, a runway or an intersection change resulting in new takeoff data, was also the case with the other occurrences of the operator.

It is known that continuing taxiing puts a great strain on the principle of cross checking new data, as time pressure and distractions are present or lurking. This kind of erroneous performance errors in general are less likely to occur when the aircraft is parked during the preflight procedure.

The likelihood of errors by entering changed data while taxiing can be reduced by stopping the aircraft before entering the new data. Some European operators have included this as an obligation in their manuals or checklists, however this is not the case with this operator.

During the completion of this report, Skybrary published a video with information to avoid erroneous takeoffs after changes of the initial takeoff data. Amongst other things it is advised to perform planning, performance calculations, cross-checks and re-briefings without rushing and with the aircraft stationary.

The interviews made clear that all the crewmembers felt unsure about their specific role in this LFUS-flight and what exactly their crew duties would be.

The composition of the crew and the division of tasks of the three-man cockpit during this flight also had influence on the occurrence of the incident. The captain gave his attention to the first officer. This accounts for the fact that the safety pilot took care of the new takeoff performance calculation. The captain relied entirely on the experience of the safety pilot. Due to his full attention to the first officer, the confidence in the safety pilot and the self-imposed time pressure, the new takeoff data was not checked.

According to the safety pilot omitting the intersection alteration might be caused by two reasons. He was not used to act as a safety pilot, having a different task at a different seat, and changing two items is exceptional for him because usually only the intersection will change while the wind remains the same.

The crew had not prioritized the first officer’s learning experience in executing operational tasks in relation to a safe and resilient operation of the flight, but instead was trying to minimize the delay.
Aircraft Registration Data
Registration mark
Country of Registration
Date of Registration
flhAklib Alp Subscribe to unlock
Airworthyness Category
Legal Basis
The Boeing Company
Aircraft Model / Type
ICAO Aircraft Type
Year of Manufacture
Serial Number
Aircraft Address / Mode S Code (HEX)
Maximum Take off Mass (MTOM) [kg]
Engine Count
Nhhnqmhhkifimjb c hqmcmgfpkqqf qlq Subscribe to unlock
Engine Type
Incident Facts

Date of incident
Jun 10, 2018



Flight number

Munich, Germany

Aircraft Registration

Aircraft Type
Boeing 737-800

ICAO Type Designator

This article is published under license from Avherald.com. © of text by Avherald.com.
Article source

You can read 2 more free articles without a subscription.

Subscribe now and continue reading without any limits!

Are you a subscriber? Login

Read unlimited articles and receive our daily update briefing. Gain better insights into what is happening in commercial aviation safety.

Free newsletter

Want to know more and stay ahead? Get our free weekly newsletter and join 5596 existing subscribers.

By subscribing, you accept our terms and conditions and confirm that you've read our privacy policy.

Send tip

Support AeroInside by sending a small tip amount.

Related articles

Newest articles

Subscribe today

Are you researching aviation incidents? Get access to AeroInside Insights, unlimited read access and receive the daily newsletter.

Pick your plan and subscribe


Blockaviation logo

A new way to document and demonstrate airworthiness compliance and aircraft value. Find out more.

Virtual Speech logo

ELITE Simulation Solutions is a leading global provider of Flight Simulation Training Devices, IFR training software as well as flight controls and related services. Find out more.

Get updates

Never miss an article from AeroInside. Subscribe to our free weekly newsletter and join 5596 existing subscribers.

By subscribing, you accept our terms and conditions and that you've read our privacy policy.

AeroInside Blog
Popular aircraft
Airbus A320
Boeing 737-800
Boeing 737-800 MAX
Popular airlines
American Airlines
Air Canada
British Airways