29
$\begingroup$

I was amazed to read this which implies that a software failure on iPads caused departing flights to return to the gate.

I used to be an avionics engineer up until a point before the current generation of consumer electronics and now develop "field" apps for phones and tablets. I know two things to be true.

  1. Consumer phones and tablets of all persuasions used in field applications have nowhere near the reliability of certified avionics. I own an iPad, amongst many other devices, and it does not get close to six nines reliability (as do none of my other consumer devices). In particular, since the latest iPad updates over the last year or two, it's been quite buggy.

  2. The hardware is not designed and built to the standards required for avionics and, without appropriate hardware, the software cannot be to aviation standards either.

I know that these devices have been certified for use and I know why and what they are used for but I thought they were only convenience devices. It seems that they have become part of the safety chain.

Are they MEL items? Does anyone know what's really going on here?

Improve this question
$\endgroup$

4 Answers 4

Reset to default
15
$\begingroup$

iPads are used so the flight charts and manuals are electronic instead of the old phonebook that had to be printed and distributed every few months.

This means that without it the pilot has no up-to-date copy of the flight chart of the airport where he is trying to land which is a safety issue.

Improve this answer
$\endgroup$
14
  • 6
    $\begingroup$ I do not understand why this answer has been downvoted: it answers the questions and does not contain mistakes. What's the problem? $\endgroup$
    – Federico
    Apr 29, 2015 at 9:20
  • 5
    $\begingroup$ @Federico I'm not sure it does answer the question (however, should not be downvoted). My question is effectively how has a piece of consumer electronics got into the safety chain. I understand why they are used and what for but clearly, there is a weak link. $\endgroup$
    – Simon
    Apr 29, 2015 at 9:56
  • 1
    $\begingroup$ @RedGrittyBrick: No, but a bad weather diversion on a coast-to-coast flight already puts you in potential range of hundreds of airports. $\endgroup$
    – MSalters
    Apr 29, 2015 at 11:32
  • 1
    $\begingroup$ @Simon how has a piece of consumer electronics got into the safety chain, well, you said that you know that these devices have been certified for use. that's how. $\endgroup$
    – Federico
    Apr 29, 2015 at 12:34
  • 3
    $\begingroup$ So if the iPad fails in flight, the pilots don't have the charts necessary to fly the plane? Does that mean the iPad has been certified under avionics standards? $\endgroup$
    – raptortech97
    Apr 29, 2015 at 14:34
14
$\begingroup$

Everything that you say in your question is correct, and to address your reliability concerns, as part of certification the FAA requires certain hardware testing (EMI testing, decompression testing, etc.) of any EFB, including the iPad. They are not however, certified to the same standards as avionics, because a failure of an iPad does not create the same safety issue as other certified parts.

Beyond the testing for certification, there is required testing by the certificate holder before any update may be applied at the end user level, and part of the approval process requires written contingency procedures that are approved by the FAA for use in the event of a failure of the iPad(s).

Typically, at least two are required in the cockpit for dispatch unless the paper equivalents of all electronic documents that they are approved for are available (charts, operations manuals, AFM's, flight logs, etc.). If they failed prior to takeoff, this is likely why they returned to the gate. There are contingency procedures for an in-flight failure of a single iPad, and for failure of all iPads on board. These are written by each applicant but typically require "anticipated information" to be manually recorded from the working iPad, or using another source (FMS, ATC, data link, internet, satellite phone, etc.) to get the information if they both fail.

The FAA has a ton of guidance/requirements available for those wanting to use COTS hardware for EFB's. Also keep in mind, that using an iPad as an EFB is only a few years old, but EFB's have been used much longer than that. Typically in the past, a Windows based tablet computer was used (talk about reliability issues), and the procedures so far have worked quite well. I don't know of a single accident caused by an EFB failure.

Whether or not the iPad is on the MEL depends on the class of EFB that it is certified as. If it is certified as "carry on" equipment, then it is not required (other than by company policy) so will not be on the MEL. If it is "installed/mounted" in the aircraft, then it may be listed in the MEL.

For lots more information, see:
AC 120-76C - Guidelines for the Certification, Airworthiness, and Operational Use of Electronic Flight Bags

Improve this answer
$\endgroup$
4
  • 2
    $\begingroup$ Thank you. The best answer so far. I am not concerned about reliability, not having charts and so on is not safety critical the fact that hundreds (thousands) of customers were inconvenienced, some no doubt financially, due to reliance on a piece of COTS is what amazes me. Anyway, thanks again, $\endgroup$
    – Simon
    Apr 29, 2015 at 17:50
  • 1
    $\begingroup$ Prior to the US Airways - American merger, 2012 or so, American pilots would return planes to gates over maintenance issues where they had the discretion to do so, as a form of work stoppage in their ongoing collective bargaining negotiation (cbsnews.com/news/…). Whether this indicates a return to labor trouble or not, it may be more precise to say the pilot elected to return the plane to the gate based on the iPad event. Having experienced a 3 plane change at the time in Ft Worth, "customer inconvenience" is not the issue. $\endgroup$
    – user662852
    Apr 29, 2015 at 18:45
  • 2
    $\begingroup$ Does that mean that if a 0-day vulnerability is found in iOS, those aircraft will have to keep using the vulnerable version until they can get approval to upgrade to a version without the vulnerability? Does the contingency plan assume the pilots know there is a problem with the devices? If an attacker were to compromise the devices they could present the pilots with corrupted but realistically looking data. $\endgroup$
    – kasperd
    Apr 29, 2015 at 19:23
  • 1
    $\begingroup$ @kasperd There are multiple, redundant sources of information involved, and no single point of failure should create a major hazard, including this. The aircraft navigation databases, the charts, and ATC all need to be on the same page, and if there are conflicting sources of information, they will be resolved using the other sources. To answer your first question though, any new version has to be evaluated (although not as extensively as the initial version) so most likely they would revert to procedures that assume iPad failure (use paper) until a good version is available. $\endgroup$
    – Lnafziger
    May 1, 2015 at 1:01
4
$\begingroup$

Nobody knows exactly what happened, but as far as I can understand the limited information available, this is what happened:

These iPads are used to carry map data that the pilot needs, and which used to come in the form of forty pound of paper. That data needs to be updated from time to time, and it is supposed to be updated through WiFi automatically when the pilot is in the cockpit at an airport.

That automatic update didn't work for some reason. The pilot found that the map data wasn't up-to-date and therefore wouldn't take off. Instead he took the iPad and carried it into the airport, where the map update worked without problem and then he took off with an iPad with good map data, with a delay.

So it seems that this was highly inconvenient, but not a security risk, assuming that the pilot used his checklist as he should. And the co-pilot had exactly the same problem with a second iPad, and fixed it the exact same way by carrying it to the airport. So it is unlikely to be a problem with that iPad.

PS. These iPads can be connected to power in the cockpit, so there is no fear that their battery power would run out.

PS. Both pilot and copilot have an iPad, and they really only need one, so you could count that as backup. I read (but I have no idea if it is true) that there is supposed to be a third set of the maps for the airplane as well, so one set for pilot, copilot, and airplane each.

Improve this answer
$\endgroup$
7
  • 2
    $\begingroup$ Hi gnasher, welcome to Aviation.SE. Do you have citation for the automatic update via WiFi at airports statement above and the accounts of what happened? $\endgroup$
    – SentryRaven
    Apr 29, 2015 at 13:24
  • 1
    $\begingroup$ I don't believe that this is the case. All of the reports I've read (and of course, none of which can be relied upon) indicate that is was a software failure. Anecdotal quotes from the pilots suggest that the "screens went blank". Nor did I suggest any kind of security issue. However, the need to return to the gate suggests that they are indeed MEL items, if they are not, then why return? Since they failed for all pilots, the point about having 2, or 3 (or 20) onboard is moot since the software failed. $\endgroup$
    – Simon
    Apr 29, 2015 at 14:10
  • 1
    $\begingroup$ Such redundancy only helps as long as shared fate can be avoided. What would the consequences be if a security exploit allowed an attacker to feed identically but corrupted data to both devices through WiFi? The only hardware needed to perform such an attack would be a laptop, which many passengers carry on the plane. A passenger could unknowingly have picked up a piece of malware, if the passenger got the malware from a rogue access point located close to the gate, it might even be possible for an attacker to target specific flights. $\endgroup$
    – kasperd
    Apr 29, 2015 at 14:16
  • $\begingroup$ @SentryRaven: It's a conjecture. But it is consistent with the fact that they had a problem while in the cockpit, which was fixed by taking the iPads into the airport. $\endgroup$
    – gnasher729
    Apr 29, 2015 at 14:42
  • 1
    $\begingroup$ @kasperd: It is probably quite easy to interfere with WiFi (stop it from working). Could happen by accident, if someone on board has a computer with broken WiFi that transmits all the time. But if the developers were not completely stupid, then the updated data would have to be encrypted, signed, or both, and making the device accept forged data should be impossible. $\endgroup$
    – gnasher729
    Apr 29, 2015 at 14:46
4
$\begingroup$

Many of the answers here are excellent in general. Maybe I can help flesh out some of the details.

My understanding is that American had issues with the application from Jeppesen through which they distribute the charts used to navigate. In this case I believe it was the airport diagram for DCA which conflicted with an earlier version on the iPad. This caused the iPad to unexpectedly crash and the app had to be deleted and reinstalled to fix the issue (a common fix on the iPad). This is a bunch of data to download all at once, especially by multiple pilots over a wi-fi connection. I suspect that increased the delay. (Source plus personal accounts) This is the electronic equivalent of every affected pilot spilling coffee on their entire set of charts and manuals at the same time. As others have said, if you don't have manuals and charts, you legally can not leave. That's the core reason why these planes had to return to the gate.

We use the same app (didn't have this issue that I know of) and the same hardware. It has a lot of benefits for the pilots and the airlines. However, in addition to the concerns that Lnazfiger raises, there are a bunch of others especially when the COTS product is the iPad which was never designed for enterprise use. This creates a bunch of issues

  1. Apps and data can be pushed out onto the device without solid testing
  2. iPad has no backward compatibility with OS changes and the user can control OS updates. This often breaks the apps being used if they aren't yet updated to the new OS. The company can't prevent this
  3. The user has immense control over the ecosystem, opening it up to risks, threats and user introduced instability
  4. These systems weren't designed for this kind of data or these applications and, until recently, Apple approached the implementation of these devices on an enterprise basis as if they are simultaneously selling thousands of consumer iPads. My understanding is that as sales drop off, they are starting to look more at enterprise deployments but they wanted little to do with the carriers originally.
  5. The application ecosystem must be tested by the carrier to ensure that there aren't conflicts between apps and data. Apple does a nice job of separating apps but that doesn't mean issues don't or can't occur.
  6. Some of the companies producing these apps are not originally software firms (e.g. Jeppesen, WSI, Boeing.) Some do a great job but I know that my experiences with the same Jeppesen app aren't stellar. Nothing this way, but I've had issues I consider sloppy.

Of course, these same risks present opportunities for enterprising software engineers and it's improving as the market improves but all of the risks and these are still present. At the same time, the benefits still outweigh the risks. I suspect that companies like Boeing and Jeppesen having their name in the press attached to issues like this will be pressed to fix any issues quickly.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Some of the issues that you bring up here can be solved by the use of MDM quite effectively, and indeed I have used it to control updates, etc. rather than allowing the pilots to update this when they feel like it. $\endgroup$
    – Lnafziger
    May 1, 2015 at 1:05
  • $\begingroup$ Agreed theoretically. It's probably the way that we have implemented it, but many of the issues still remain. $\endgroup$
    – SOCPilot
    May 1, 2015 at 1:31
  • $\begingroup$ I know from painful experience that no MDM I am aware of can prevent the user from applying OS updates. It's part of the providers strategy and they expose no mechanism to 3rd parties to prevent them. $\endgroup$
    – Simon
    May 1, 2015 at 7:10
  • $\begingroup$ Which is unfortunate in an enterprise setting. I understand that there are ways around it (don't know much detail) but the cure can be worse than the disease). $\endgroup$
    – SOCPilot
    May 6, 2015 at 16:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .