EFB Glitch Airbus
Thread Starter
Join Date: Oct 2013
Location: Wengen
Age: 53
Posts: 380
Likes: 0
Received 0 Likes
on
0 Posts
EFB Glitch Airbus
U.K. Investigators Uncover Flight-Data Issue Involving Airbus
Pilots unintentionally altered some settings on an electronic flight-data calculator
An easyJet Airbus A319 took off from Belfast in June using all but the last 650 feet of the runway before becoming airborne, a significantly smaller safety margin than normal.
An easyJet Airbus A319 took off from Belfast in June using all but the last 650 feet of the runway before becoming airborne, a significantly smaller safety margin than normal.
British air-crash investigators looking into an incident last year involving an easyJet PLC flight have documented how a bug in an electronic flight-data calculator on many Airbus Group SE jetliners could lead to takeoff problems.
The potential hazard and steps to eliminate it were disclosed in a report released last week by Britain’s Air Accidents Investigation Branch.
Pilots of an easyJet Airbus A319 unintentionally altered some touchscreen settings on a computerized takeoff calculator -- called an electronic flight bag -- but failed to recognize the changes until after takeoff from Belfast International Airport last June, according to the report.
Investigators determined that as a result of the data confusion, the crew set engine thrust so that the jet carrying 161 people used up all but the last roughly 650 feet of the strip before becoming airborne, a significantly smaller safety margin than normal.
Airbus and easyJet participated in the investigation, agreed with its main conclusions and have taken steps to prevent a repeat of the incident.
There were no injuries and the jet wasn’t damaged, but the event highlighted the broader danger of pilots mistakenly entering the wrong takeoff parameters into such computers. Data-integrity issues and potential pilot distractions resulting in programming slip-ups prior to takeoff have long been identified as major hazards for all types of commercial aircraft, including models made by Boeing Co. and other manufacturers.
The AAIB report, which indicated European air-safety regulators and Airbus are pursuing various initiatives to reduce those risks, further highlights the work remaining to be done. Pilots typically double-check parameters before takeoff, but in the easyJet incident company rules didn’t require that specific safeguard. The AAIB previously investigated two other easyJet takeoff incidents in 2015 in which crews relied on incorrect computerized takeoff-performance data. Neither of those events resulted in damage or injuries.
Still, last week’s report emphasized the importance of each pilot cross-checking data entered into such electronic flight bags prior to takeoff. The report notes that Airbus has made some adjustments and is studying software revisions and other changes intended to catch pilot errors that can introduce incorrect data into such computers. One of the major changes was available to airlines prior to the Belfast incident, but investigators determined that easyJet hadn’t installed the updated software nor adopted Airbus’s recommendations regarding pilot cross-checking.
EasyJet is evaluating a number of procedural changes, according to the British report. And prompted by the Belfast incident, Airbus last October urged operators to catch data-entry mistakes by requiring “an independent computation made by both pilots” prior to the takeoff roll.
Also according to the AAIB, the European Aviation Safety Agency recently determined that when it comes to pre-takeoff data hazards, the “risk level and its trend need to be monitored continuously.”
Long before the June 2015 mix-up, numerous other airlines world-wide suffered a series of data-input problems prior to takeoff, some involving larger aircraft and more-hazardous incidents or accidents.
In March 2014, a US Airways Airbus A320 struck its tail on a Philadelphia runway after the crew rejected takeoff following a computer glitch caused by mistaken data input. The captain initially opted to try to become airborne despite the loss of critical speed measurements and an automated warning he didn’t understand. During the next several seconds, the captain commanded the nose of the plane to move sharply up and down three times, according to a National Transportation Safety Board report. The jet bounced on the runway, climbed to an altitude of 15 feet and then slammed back down, collapsing the nose gear, according to investigators. There were no injuries.
One of the most harrowing events occurred five years earlier in Melbourne, Australia, when the co-pilot of an Emirates Airline Airbus A340 mistakenly entered a takeoff weight into the electronic flight bag, or cockpit computer, that was 100 tons less than the plane’s actual weight. Calculations for engine thrust and takeoff distance were based on the erroneous weight data, which the captain also overlooked.
The jet initially failed to become airborne when the control stick was used to try to raise the nose and climb. The captain applied full power and then the four-engine jet, carrying 275 people and bound for Dubai, hit some lights and antennas at the end of the strip. It rolled past the paved runway for about four seconds before starting to noticeably climb, according to Australian investigators. It took the pilots five minutes to realize their computational error, and investigators also found significant damage to the underside of the fuselage. After dumping fuel, the plane landed back at the airport about an hour later without any injuries.
Pilots unintentionally altered some settings on an electronic flight-data calculator
An easyJet Airbus A319 took off from Belfast in June using all but the last 650 feet of the runway before becoming airborne, a significantly smaller safety margin than normal.
An easyJet Airbus A319 took off from Belfast in June using all but the last 650 feet of the runway before becoming airborne, a significantly smaller safety margin than normal.
British air-crash investigators looking into an incident last year involving an easyJet PLC flight have documented how a bug in an electronic flight-data calculator on many Airbus Group SE jetliners could lead to takeoff problems.
The potential hazard and steps to eliminate it were disclosed in a report released last week by Britain’s Air Accidents Investigation Branch.
Pilots of an easyJet Airbus A319 unintentionally altered some touchscreen settings on a computerized takeoff calculator -- called an electronic flight bag -- but failed to recognize the changes until after takeoff from Belfast International Airport last June, according to the report.
Investigators determined that as a result of the data confusion, the crew set engine thrust so that the jet carrying 161 people used up all but the last roughly 650 feet of the strip before becoming airborne, a significantly smaller safety margin than normal.
Airbus and easyJet participated in the investigation, agreed with its main conclusions and have taken steps to prevent a repeat of the incident.
There were no injuries and the jet wasn’t damaged, but the event highlighted the broader danger of pilots mistakenly entering the wrong takeoff parameters into such computers. Data-integrity issues and potential pilot distractions resulting in programming slip-ups prior to takeoff have long been identified as major hazards for all types of commercial aircraft, including models made by Boeing Co. and other manufacturers.
The AAIB report, which indicated European air-safety regulators and Airbus are pursuing various initiatives to reduce those risks, further highlights the work remaining to be done. Pilots typically double-check parameters before takeoff, but in the easyJet incident company rules didn’t require that specific safeguard. The AAIB previously investigated two other easyJet takeoff incidents in 2015 in which crews relied on incorrect computerized takeoff-performance data. Neither of those events resulted in damage or injuries.
Still, last week’s report emphasized the importance of each pilot cross-checking data entered into such electronic flight bags prior to takeoff. The report notes that Airbus has made some adjustments and is studying software revisions and other changes intended to catch pilot errors that can introduce incorrect data into such computers. One of the major changes was available to airlines prior to the Belfast incident, but investigators determined that easyJet hadn’t installed the updated software nor adopted Airbus’s recommendations regarding pilot cross-checking.
EasyJet is evaluating a number of procedural changes, according to the British report. And prompted by the Belfast incident, Airbus last October urged operators to catch data-entry mistakes by requiring “an independent computation made by both pilots” prior to the takeoff roll.
Also according to the AAIB, the European Aviation Safety Agency recently determined that when it comes to pre-takeoff data hazards, the “risk level and its trend need to be monitored continuously.”
Long before the June 2015 mix-up, numerous other airlines world-wide suffered a series of data-input problems prior to takeoff, some involving larger aircraft and more-hazardous incidents or accidents.
In March 2014, a US Airways Airbus A320 struck its tail on a Philadelphia runway after the crew rejected takeoff following a computer glitch caused by mistaken data input. The captain initially opted to try to become airborne despite the loss of critical speed measurements and an automated warning he didn’t understand. During the next several seconds, the captain commanded the nose of the plane to move sharply up and down three times, according to a National Transportation Safety Board report. The jet bounced on the runway, climbed to an altitude of 15 feet and then slammed back down, collapsing the nose gear, according to investigators. There were no injuries.
One of the most harrowing events occurred five years earlier in Melbourne, Australia, when the co-pilot of an Emirates Airline Airbus A340 mistakenly entered a takeoff weight into the electronic flight bag, or cockpit computer, that was 100 tons less than the plane’s actual weight. Calculations for engine thrust and takeoff distance were based on the erroneous weight data, which the captain also overlooked.
The jet initially failed to become airborne when the control stick was used to try to raise the nose and climb. The captain applied full power and then the four-engine jet, carrying 275 people and bound for Dubai, hit some lights and antennas at the end of the strip. It rolled past the paved runway for about four seconds before starting to noticeably climb, according to Australian investigators. It took the pilots five minutes to realize their computational error, and investigators also found significant damage to the underside of the fuselage. After dumping fuel, the plane landed back at the airport about an hour later without any injuries.
Join Date: Jan 2014
Location: N5109.2W10.5
Posts: 720
Likes: 0
Received 0 Likes
on
0 Posts
What sort of sensationalist source is this toff from?
There was no "Bug". There was no "glitch" in the software.
"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"
Join Date: Aug 2012
Location: United Kingdom
Age: 34
Posts: 948
Likes: 0
Received 0 Likes
on
0 Posts
If you've used this software on a touchscreen before, you'll know that it's a right pain to use. Sure you can implement a whole bunch of SOP fixes to guard against errors, but they need to make a piece of software that wasn't designed in 1990.
Thanks Goldenrivett, I've retracted my rant, I was looking at https://assets.digital.cabinet-offic...EZUH_01-16.pdf
I shall read the other one...
Skon, I use the Flysmart on iPad. I have even done the Airbus admin training course on it. I actually think it's very good compared to the Windows versions we had before.
I shall read the other one...
Skon, I use the Flysmart on iPad. I have even done the Airbus admin training course on it. I actually think it's very good compared to the Windows versions we had before.
Join Date: Oct 2011
Location: United Kingdom
Age: 39
Posts: 700
Likes: 0
Received 0 Likes
on
0 Posts
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."
Join Date: Jan 2014
Location: N5109.2W10.5
Posts: 720
Likes: 0
Received 0 Likes
on
0 Posts
Hi compressor stall,
You are welcome.
I gather the "anomaly" has only recently been recognised, but was probably responsible for the unintended selection of Full Length from all the Runways with the Lowest sort Number. (i.e. 03 Lisbon, 08 Luton, 07 Belfast).
You are welcome.
I gather the "anomaly" has only recently been recognised, but was probably responsible for the unintended selection of Full Length from all the Runways with the Lowest sort Number. (i.e. 03 Lisbon, 08 Luton, 07 Belfast).
We use iPads and Flysmart, and very good it is too - excellent in fact.
However, a potential problem is that data entry (of latest weather and TOM figures) takes a while to do and it is inevitably done after the loadsheet has been amended with LMC's and just before the doors are closed.
So there is real time pressure - especially with the all too common CTOT these days - a situation which is not consistent with careful data entry.
Airbus Flysmart SOPs state that on arrival at the aircraft we have to enter the estimated figures and run a take-off performance calculation. Then, we have to do it all over again; updating the weather and final loadsheet figures just after closing up.
We have all been bitching about this apparent waste of time (doing the first calculation), but I can now see that Airbus SOPs are designed to avoid the problems experienced in the situation in this report. By each of us running a calculation with estimated figures, entered during a 'quiet' period (yes, I know) of the cockpit preparation; reasonable performance settings will be used which would be enough to get safely airborne with. They will be in the right ballpark and the SOPs presumably have been designed to avoid serious problems associated with very quick and inaccurate data entries made under serious time pressure as we close up.
So I suppose I/we will have to stop bitching and just follow the Flysmart SOPs. I just wish they would explain WHY we have to do certain things.
However, a potential problem is that data entry (of latest weather and TOM figures) takes a while to do and it is inevitably done after the loadsheet has been amended with LMC's and just before the doors are closed.
So there is real time pressure - especially with the all too common CTOT these days - a situation which is not consistent with careful data entry.
Airbus Flysmart SOPs state that on arrival at the aircraft we have to enter the estimated figures and run a take-off performance calculation. Then, we have to do it all over again; updating the weather and final loadsheet figures just after closing up.
We have all been bitching about this apparent waste of time (doing the first calculation), but I can now see that Airbus SOPs are designed to avoid the problems experienced in the situation in this report. By each of us running a calculation with estimated figures, entered during a 'quiet' period (yes, I know) of the cockpit preparation; reasonable performance settings will be used which would be enough to get safely airborne with. They will be in the right ballpark and the SOPs presumably have been designed to avoid serious problems associated with very quick and inaccurate data entries made under serious time pressure as we close up.
So I suppose I/we will have to stop bitching and just follow the Flysmart SOPs. I just wish they would explain WHY we have to do certain things.
Yes, we each have a company iPad and do our own independant calculations, and then compare V speeds, Green dot, config, flex, with each other and the FMGC.
Join Date: Oct 2010
Location: 5° above the Equator, 75° left of Greenwich
Posts: 411
Likes: 0
Received 0 Likes
on
0 Posts
Yikes. Would kill the worms on my stomach for sure...
We use the FlySmart thingy on the iPad and other than taking care of where you're putting your finger it seems like a fairly straight process.
We have two iPads on the cockpit and each crewmember runs an independent calculation which then crosscheck for the same V-speeds and flex. We run two calculations only if it becomes necessary (if there was a LMC). We run the first one just after receiving the loadsheet (after which we need to have matching flex temp and V speeds, if not we crosscheck each other's inputs for errors until said numbers match). If there was a LMC, captain will amend loadsheet as necessary informing "plus/minus X pax" (pax weigh 100kg at our company so it's pretty straightforward) while FO corrects the FMGC numbers (I call my resulting number out loud so he can crosscheck with his number, though it isn't company policy) and after that run the second calculation. Captain will run his second calculation and we will need to have matching numbers again.
If "done by the book" this should be completed by the before start check, though due to the high-cycle/short turnaround nature of our operation, sometimes the last calculation gets done during pushback. But it gets done nevertheless.
We use the FlySmart thingy on the iPad and other than taking care of where you're putting your finger it seems like a fairly straight process.
We have two iPads on the cockpit and each crewmember runs an independent calculation which then crosscheck for the same V-speeds and flex. We run two calculations only if it becomes necessary (if there was a LMC). We run the first one just after receiving the loadsheet (after which we need to have matching flex temp and V speeds, if not we crosscheck each other's inputs for errors until said numbers match). If there was a LMC, captain will amend loadsheet as necessary informing "plus/minus X pax" (pax weigh 100kg at our company so it's pretty straightforward) while FO corrects the FMGC numbers (I call my resulting number out loud so he can crosscheck with his number, though it isn't company policy) and after that run the second calculation. Captain will run his second calculation and we will need to have matching numbers again.
If "done by the book" this should be completed by the before start check, though due to the high-cycle/short turnaround nature of our operation, sometimes the last calculation gets done during pushback. But it gets done nevertheless.
Thanks Uplinker.
It seems that Easyjet's SOPs are/were to use only one tablet, even though they had two. We don't use these things yet but in my view it would be completely unacceptable for the second pilot to merely "check" the inputs on the one device. It should be mandatory to have two units and the pilots do their own calculations, then compare. Data entry of any type is just too easy to mess up and not be picked-up.
It seems that Easyjet's SOPs are/were to use only one tablet, even though they had two. We don't use these things yet but in my view it would be completely unacceptable for the second pilot to merely "check" the inputs on the one device. It should be mandatory to have two units and the pilots do their own calculations, then compare. Data entry of any type is just too easy to mess up and not be picked-up.
Join Date: Jan 2014
Location: N5109.2W10.5
Posts: 720
Likes: 0
Received 0 Likes
on
0 Posts
It should be mandatory to have two units and the pilots do their own calculations, then compare.
Since you are not using EFBs yet, do you carry two performance manuals and do the calculations independently?
Fair-enough question, Rivett. No, we do not carry two performance manuals. FO Bloggs works out the numbers from the book and writes them on the Takeoff Data card. He then closes the book and chucks it on the coaming. When I'm ready, I open it at the page I reckon we should be using (eg packs off, wet, correct intersection) then with the card, find the flex temp we need. Then I start checking his work.
Join Date: Jan 2014
Location: N5109.2W10.5
Posts: 720
Likes: 0
Received 0 Likes
on
0 Posts
We use a similar method with the EFBs.
PM Bloggs enters the data (Runway, intersection, wind, temp, QNH, packs off, wet, etc) then does the Weight & Balance data entry on another page of EFB. PF Bloggs then cross checks the all the data entered before the calculations are run.
The software bug mentioned above, is due to touch screen technology being used on software initially designed for keyboard entry. I'm confident the proposed fix will prevent unnoticed runway changes (when only the wet / dry change was selected after the first calculation was run.)
PM Bloggs enters the data (Runway, intersection, wind, temp, QNH, packs off, wet, etc) then does the Weight & Balance data entry on another page of EFB. PF Bloggs then cross checks the all the data entered before the calculations are run.
The software bug mentioned above, is due to touch screen technology being used on software initially designed for keyboard entry. I'm confident the proposed fix will prevent unnoticed runway changes (when only the wet / dry change was selected after the first calculation was run.)
Last edited by Goldenrivett; 18th May 2016 at 13:09. Reason: extra text
Join Date: Aug 2007
Location: The Netherlands
Age: 67
Posts: 288
Likes: 0
Received 0 Likes
on
0 Posts
Goldenrivett,
Using one book and working the numbers each pilot individually is different from using one laptop (or EFB) and have one pilot glance over the inputs from the other pilot.
With a book, it is filled with numbers, but each pilot on his own finds the correct line with results. The results of the second man are compared with the results from the first man.
With one laptop, the second pilot starts with the numbers that were filled in by the first pilot. It is all too easy to NOT SEE that certain filled in numbers may be incorrect.
The correct way is to fill in your numbers on your laptop and only communicate the results. The results should be identical, if not, then investigate what caused the difference. Exactly as Capn Bloggs described.
As you noted correctly, the anomaly was not a glitch in the software, as in the way it calculated, it was "just" the fact that inadvertant multiple contacts with the touchscreen could change settings without the pilot being aware of the changes occurring.
Using one book and working the numbers each pilot individually is different from using one laptop (or EFB) and have one pilot glance over the inputs from the other pilot.
With a book, it is filled with numbers, but each pilot on his own finds the correct line with results. The results of the second man are compared with the results from the first man.
With one laptop, the second pilot starts with the numbers that were filled in by the first pilot. It is all too easy to NOT SEE that certain filled in numbers may be incorrect.
The correct way is to fill in your numbers on your laptop and only communicate the results. The results should be identical, if not, then investigate what caused the difference. Exactly as Capn Bloggs described.
As you noted correctly, the anomaly was not a glitch in the software, as in the way it calculated, it was "just" the fact that inadvertant multiple contacts with the touchscreen could change settings without the pilot being aware of the changes occurring.
Continuing on, in this incident, it appears that an inadvertent "bump" of the runway dropdown may have caused the problem. It is much less likely that the error would have been replicated had the FO done the planning on his laptop as well ie he would have had to bump the same dropdown, despite the bug in the software. The error would then have manifested itself in the figures comparison. Perhaps Airbus was worried enough about the robustness of the "concept" (read software/human failings?) that it suggested "independent" calculations, something that Easyjet elected not to do. To me, "independent" is either on separate machines then compared, or the same machine with all input values wiped and done again to compare with the first run.
Join Date: Mar 2001
Location: I wouldn't know.
Posts: 4,498
Likes: 0
Received 0 Likes
on
0 Posts
I thought independent calculations were the industry norm, especially after the emirates overrun with their airbus in melbourne.
In my opinion the iPad software is much better than the windows software we used before. Some options are rather well hidden, but still, the inputs and presentation is much better to work with.
In my outfit it was always two independent calculations. One with the preliminary figures (either preliminary acars loadsheet or OFP figures), which is necessary to get the engine out procedure and then program it into the secondary and subsequently brief it, and then a final one with the final acars loadsheet. The second one is of course easy to do, simply modify the take off weight, press calculate and wait a bit. That procedure hasn't changed really in the change from windows to ipad.
In my opinion the iPad software is much better than the windows software we used before. Some options are rather well hidden, but still, the inputs and presentation is much better to work with.
In my outfit it was always two independent calculations. One with the preliminary figures (either preliminary acars loadsheet or OFP figures), which is necessary to get the engine out procedure and then program it into the secondary and subsequently brief it, and then a final one with the final acars loadsheet. The second one is of course easy to do, simply modify the take off weight, press calculate and wait a bit. That procedure hasn't changed really in the change from windows to ipad.
Join Date: Oct 2010
Location: 5° above the Equator, 75° left of Greenwich
Posts: 411
Likes: 0
Received 0 Likes
on
0 Posts
I try to always get cross check from the odd pilot who is either leaving the calculations done to the last minute or forgot to tell me his data matches. I'm much too aware of the high possibility of either of us touching the wrong button/number/selection on the iPad. It's a potential serious mistake that should be easy to catch, if things are done properly
Originally Posted by Denti
The second one is of course easy to do, simply modify the take off weight, press calculate and wait a bit.
Escape Path, on the other hand, sounds like he is using two separate ipads...