29

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?

Community
  • 1
Simon
  • 31,213
  • 4
  • 141
  • 163

4 Answers4

15

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.

Federico
  • 32,559
  • 17
  • 136
  • 184
ratchet freak
  • 27,428
  • 5
  • 79
  • 143
  • Shouldn't they have backup iPads and/or paper charts? – Keegan Apr 29 '15 at 09:00
  • @SpongeBob the iPad is meant to prevent the waste of paper that updating the paper charts pose. And what can affect one iPad can also affect another (especially when it's not often used like a backup would be). – ratchet freak Apr 29 '15 at 09:03
  • 6
    I do not understand why this answer has been downvoted: it answers the questions and does not contain mistakes. What's the problem? – Federico Apr 29 '15 at 09:20
  • 5
    @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. – Simon Apr 29 '15 at 09:56
  • 1
    @RedGrittyBrick: No, but a bad weather diversion on a coast-to-coast flight already puts you in potential range of hundreds of airports. – MSalters Apr 29 '15 at 11:32
  • 1
    @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. – Federico Apr 29 '15 at 12:34
  • @Federico To be fair, that's kind of saying "because that's just the way it is" which is not a great answer ;) – Simon Apr 29 '15 at 13:03
  • @Simon, actually my point was that the question, imho, is not well posed, if you want to know how the ipads got through certification you should reword it, or the answer to how they got into the loop is and remains they passed the certification process – Federico Apr 29 '15 at 13:17
  • @Federico My question is clear I think but please do edit if you think it could be improved - Are they MEL items? Does anyone know what's really going on here? – Simon Apr 29 '15 at 14:07
  • 3
    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? – raptortech97 Apr 29 '15 at 14:34
  • @raptortech97 The short answer appears to be yes, or at least that the FAA is prepared to approve a process which uses an iPad in lieu of paper charts. – Nigel Harper Apr 29 '15 at 15:21
  • @NigelHarper Thanks. I'm literally shocked by this. I can only assume that the FAA will be reviewing the certification. I get that there isn't much of a safety risk since not having charts does not mean that a safe diversion and landing is not possible but does add a very weak link into an otherwise strong chain. In particular, I smiled when I read this - the app proved “extremely stable” during testing. In the “unlikely” event of a software crash, he says, it takes but a moment to get them running again. Clearly not. It's a consumer device, on second thoughts, why am I shocked? – Simon Apr 29 '15 at 15:53
  • @Simon note that the wired.com article is from 2011. – ratchet freak Apr 29 '15 at 15:58
  • 1
    @raptortech97 I have added an answer with information regarding certification and contingency procedures for you which explain some of your questions here in the comments. – Lnafziger Apr 29 '15 at 16:14
14

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

Lnafziger
  • 58,886
  • 39
  • 242
  • 423
  • 2
    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, – Simon Apr 29 '15 at 17:50
  • 1
    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 (http://www.cbsnews.com/news/pilots-grounding-american-airlines-without-strike/). 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. – user662852 Apr 29 '15 at 18:45
  • 2
    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. – kasperd Apr 29 '15 at 19:23
  • 1
    @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. – Lnafziger May 01 '15 at 01:01
4

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.

gnasher729
  • 149
  • 2
  • 2
    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? – SentryRaven Apr 29 '15 at 13:24
  • 1
    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. – Simon Apr 29 '15 at 14:10
  • 1
    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. – kasperd Apr 29 '15 at 14:16
  • @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. – gnasher729 Apr 29 '15 at 14:42
  • 1
    @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. – gnasher729 Apr 29 '15 at 14:46
  • @gnasher729 They are using a software stack, which is not designed to the same standards as the rest of the plane. Whether it has vulnerabilities or not is really not part of the question. It is however very relevant to the question what the consequences are if such a vulnerability exists. Can security be jeopardized by an attacker who can place corrupted data on both devices with the data being constructed in such a way that it is not immediately obvious that it is corrupted? – kasperd Apr 29 '15 at 14:57
  • That's close. The data actually did update, but one of the new records conflicted with an old record, locking up the application. For some reason, as far as I can understand from some involved, it locked up the whole device forcing them to reload the application stack. – SOCPilot May 06 '15 at 16:56
4

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.

SOCPilot
  • 161
  • 1
  • 5
  • 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. – Lnafziger May 01 '15 at 01:05
  • Agreed theoretically. It's probably the way that we have implemented it, but many of the issues still remain. – SOCPilot May 01 '15 at 01:31
  • 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. – Simon May 01 '15 at 07:10
  • 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). – SOCPilot May 06 '15 at 16:56