Easyjet A319 at Belfast on Jun 25th 2015, EFB computes takeoff performance for different runway than entered

Last Update: May 12, 2016 / 15:31:21 GMT/Zulu time

Bookmark this article

Photo of Easyjet G-EZAA, Airbus A319 — Easyjet G-EZAA, Airbus A319 (Photo credit: Anna Zvereva / Flickr / License: CC by-sa)

Incident Facts

Date of incident
Jun 25, 2015

Classification
Report

Airline
Easyjet

Flight number
U2-186

Departure
Belfast Aldergrove, United Kingdom

Destination
London Luton, United Kingdom

Aircraft Registration
G-EZAA

Aircraft Type
Airbus A319

ICAO Type Designator
A319

An Easyjet Airbus A319-100, registration G-EZAA performing flight U2-186 from Belfast Aldergrove,NI to London Luton,EN (UK) with 156 passengers and 6 crew, was preparing for departure from Belfast's runway 25, the captain (33, ATPL, 7,400 hours total, 4000 hours on type) used his electronic flight bag (EFB) to compute takeoff performance data commencing takeoff on runway 25 from intersection B selecting flaps 1+F and wet runway although the runway was dry, the captain was anticipating the weather would deteriorate until departure. The captain subsequently decided, to permit the first officer a clearer view of the EFB, to remove the EFB from its stowage and placed it on his table. The first officer noticed that the computation used TOGA/Full power. As the runway was dry the crew agreed they could use FLEX takeoff. The commander selected the runway to dry using the drop down menus and computed the performance now received a reduced takeoff thrust FLEX performance as expected. The crew made a gross cross check of the received data verifying the green dot speed and engine out acceleration altitude, but did not cross check the entire set of data.

The aircraft taxied to runway 25 and entered the runway via taxiway B. From that point the end of the runway is not visible due to a "hump" in the runway. The aircraft commenced takeoff and was accelerating through 115 KIAS (V1 130 KIAS) when the end of the runway became visible. The commander assessed that there was insufficient distance available to stop the aircraft and decided to proceed with the takeoff being satisfied that the remaining distance was sufficient to continue takeoff, rotate and become airborne with the current FLEX takeoff settings, which he decided to stick with in order to not distract the first officer (pilot flying). The aircraft became airborne about 200 meters before the runway end.

After the aircraft had climbed to safe altitude the crew acknowledged that something had been wrong with the takeoff performance data. Later into the flight the captain reconsulted with the EFB and was surprised to find runway 07 selected in the drop down box.

The UK AAIB released their bulletin concluding the probable causes of the serious incident were:

The incident was caused by the use of incorrect takeoff performance data. The data was most likely calculated using Runway 07 instead of Runway 25B. The most likely reason for using Runway 07 was an involuntary runway selection by an anomaly within the EFB software which went undetected by the crew. They did not conduct an independent check of the selected runway when their recollection was of changing only the runway condition.

Operators have been informed of the anomaly and the EFB software will be corrected in future standards.

The commander recognised the limited stopping distance available just before V1 but the potential seriousness of the event is highlighted by the theoretical result of a runway overrun at 75 kt if the takeoff had been rejected at that stage. A number of international, European and national initiatives are underway to consider and address the safety risks posed by using erroneous takeoff performance parameters.

The AAIB analysed:

The data input and output data to / from the EFB could not be recovered. The commander confirmed, when consulting the takeoff performance page of the EFB after takeoff, that Runway 07 was selected. When comparing flex temperature and V speeds recorded on the QAR with those calculated for a dry Runway 07 takeoff, it is highly likely that Runway 07 was that used to calculate the takeoff performance.

The reason for the selection of Runway 07 could not be confirmed but would have required some physical contact with the EFB’s rwy drop-down menu. Given the flight crew recollection of initially confirming Runway 25B selection and then only changing the runway condition field, it is probable that the change to Runway 07 was involuntary and due to the runway selection anomaly highlighted during this investigation. The crew commented that they were unaware of this anomaly and thus felt there was not a requirement to crosscheck all the data entered in the EFB for a second time.

The aircraft manufacturer recommended that both flight crew perform individual computations and then crosscheck each other’s. The operator elected not to adopt these procedures, stating that they preferred their SOPs which had been refined to their specific operational requirements over the 12 years of using EFBs and this approach had been accepted by the UK CAA.

The EFB did not record the method by which the runway has been selected (on-screen keyboard, drop-down menu or involuntary default to the lowest number). As a result, even if the takeoff performance data had been recovered, the reason for the Runway 07 selection would not have been known.

To reproduce this runway selection anomaly required physically touching the screen which could have been inadvertently achieved by the glance of a hand. The risk associated with using touchscreen input devices which are on all the time is that any inadvertent touch of the screen by a conductive source may change a field on the screen.

The EFB operational approval process did not test for this anomaly although AMC 20-25 does have generic HMI requirements. This highlights the need for detailed guidance to those performing an operational approval.

The manufacturer confirmed that the EFB version the operator was using was ‘not optimised for touchscreen’ but was unaware of the anomaly before this event. They have confirmed that the next software version will correct it.

The AAIB reported that a safety action was taken by the software vendor: "The EFB software manufacturer has confirmed that the anomaly will be corrected in the L6.0.x version of FlySmart."