White Paper: EFB latest developments and what’s next?
Author: Klaus Olsen, EFB Admin ServicesSubscribe
Klaus Olsen, EFB Admin Services shares his considerable experience of EFB integration and connectivity
THE CHALLENGES FOR EFB TODAY
Many of the discussions about this subject today are around the integration of various functions within the EFB, collaboration between various departments and the need to protect data – cybersecurity has become a very important part of the EFB (figure 1). In this, both employees and the company will have specific goals and these goals will all need to be met if any cybersecurity system is to avoid impeding work, and secure the safety of company data and information.
Any EFB solutions management and security program will need to both enable users and protect data (figure 2.1 and 2.2).
In order to stay secure, it is definitely necessary to have an MDM (Mobile Device Management) solution to control the devices in the business. Microsoft has the Intune application which is one of the best but also one of the more cumbersome; so, depending on your needs, I’d also suggest looking into solutions like Mirador or kandji if you have a straight iOS solution. But, come what may, businesses have to secure their devices.
We’ve mentioned collaboration between different parts of the organization (figure 3) with people nowadays talking about integrating Techlog and much else besides.
It’s important to try to put it all together in one application rather than the need to open seven different applications that don’t even speak to each other. Today, it’s possible to do quite a lot more than just download the flight plan. Within the flight plan there is practically all the information that is needed to pre-populate all the other applications that are being used whether that’s eTechLog, Charts App or others; there’s really no need to go into a separate application and put in the aircraft registration or the route; it should be done automatically and as integrated as possible.
I’ve been working in the EFB sector for nearly fifteen years. Some of you might remember the EFB at the bottom right of figure 4, the old NavAero C2 solution which was marketed as a portable solution but it did weigh quite a lot and was not easy to replace on a turnaround.
During the past decade, the industry has evolved quite a lot; these days it will be an iPad or a Windows tablet which can be replaced in less than a minute.
The EFB needs to be secured and that depends on the kind of data that is going on to the EFB. If QAR data is being downloaded then there should always be a zero-trust approach to security with no pilot access to the data being captured. There needs to be end-to-end encryption, for the transfer and checksum to ensure that there is no corruption of data, and, preferably, compression. Nowadays, typically, the EFB will integrate with a cellular or Wi-Fi network (needs to be secured by the airline). The risks are mostly in the EFB as a secured unit and depending on whether you have an aircraft attached or pilot attached EFB, which means, if the pilot takes the EFB with him when he leaves the aircraft, he also takes the data gathered on that EFB including all the documents and flight plans. It could be sensitive information, so how do you ensure that those documents are kept secure and inaccessible to other parties? If there is a reporting system, the pilot usually takes it back to the hotel where he’ll connect to the hotel’s Wi-Fi which the most insecure transmission possible without any kind of VPN or similar, it is very easy for data to be stolen unless it has been secured.
The biggest cyber security threat, unfortunately, is from the pilots. Typically, a pilot going from, say, Stockholm to Dubai will have five or six hours just cruising when he will be fiddling with the EFB, playing around. I recall one incident a couple of years ago, where a pilot figured out how to set up a wireless network through the EFB and to share that with the entire crew. What he didn’t consider was that he had also created a Wi-Fi that all the passengers could see and which therefore posed a big threat.
Ensuring data integrity
Data integrity and security needs to be at many levels. Data encryption and checksum helps protect and secure the device and there are further layers that can be added to that. Device authentication takes us back to the MDM solution and that is absolutely necessary or you’ll be in trouble today. Make sure there is a secure link from air to ground with protection to ensure that there is no ‘man-in-the-middle’ attack. Remember the incident cited above where the pilot had set-up a wireless network but there are also a lot of EFBs that connect to the on-board Wi-Fi today which you might think would be secure but, whether you use on-board Wi-Fi or Bluetooth to transmit data between the EFBs, that will be an unsecure channel that you open and, if there’s a fifteen years old hacker onboard, he’ll have a lot of time on his hands to figure out a way to become that man in the middle and intercept all the data being sent over that network. Cybersecurity is very important.
Even though there are a lot of intelligent solutions available they need to be combined with human expertise. You can buy the most expensive software in the world to keep your systems safe but there will always need to be a human element to ensure that it’s really secure. That is the key to success where cybersecurity is concerned. In fact, there is an entire cyber security model that can be followed:
threat intelligence & Human Expertise = Success.
We mentioned above, the integration and automation of some tasks and the use of the wireless QAR to transfer files. A lot of airlines don’t have that solution but would probably like to have some kind of automation to make sure that files are being sent securely and safely without too many people being in those processes (figure 5).
So, there are several solutions that can be used today to automate the sending of QAR files, AHM data if the airline doesn’t have automated tasks to do that or wireless QAR.
Another integration that we mentioned was the electronic Tech Log (ETL). There are a lot of suppliers who require a separate device for the eTechLog but I cannot see any reason for that. All vendors are able to produce CSV files, XML files that can be integrated into an existing EFB as is shown here in figure 6 where all the items and the due dates, etc. can be listed.
OPERATING AN INTEGRATED EFB IN PRACTICE
[[This next section will need to have a visually different format and appearance to distinguish it from the main speaker’s copy.]]
Here is a short video presentation by Captain Johan Bergsee of Novair on how Novair operates and integrates their EFB on the FDS iOS EFB. The video is self-explanatory but we’ve added a transcript to save you from having to take notes.
Where I start when I check-in for flight, I select and download the flight that I am performing today and, from the main interface, I can perform all the tasks that I’ll be doing during the whole day, despite the fact that different applications specialize in different functions.
So, for example, in this application, I go through the briefing package, I check the NOTAMs, I check the weather and I can bring up the passenger briefing. But, if I go to the Chart application, which is better at showing the route and the approach plates, you can see that it has pre-populated my Chart application with the flight number, the voucher destination and the active route, and any alternate airports.
This application is better at showing charts than the main application, so therefore its task is to perform that. This can be done with Lido and Jeppeson as well but last time I checked, with Jeppeson, you have to pay extra for their service of opening up the possibility of transferring data to their application. And, with what’s happening in the upper left corner, I’ll get back to the main interface and this is common throughout all applications on the iPad.
An example of a not so good integration is with Performance and Mass & Balance. Here, the big vendors, Airbus and Boeing, do not let third-party providers send them any data other than that which is already in place and used by themselves. So, if I go to the Take-off Performance application, I have to fill this in and am not able to send them over to that application. There are smaller Performance software providers that can do this, that allow data sharing which will give a better experience for the pilots. So, as long as the big players have private APIs, there is some opportunity here for those smaller suppliers to provide a better overall experience and take market share.
I also want to show you and example of exactly the kind of integration that we’re looking for.
During winter operations or winter conditions, when applying anti-ice fluid, it is an EASA requirement to note the type of fluid and the hold-over time somewhere in the instrumentation and the documentation of the flight. In our company, we do it on the flight plan, the operational flight plan. So, here, I can select the fluid that we use (I have generic fluids and some brand specific fluids that we use within the company). I select one of them and then, by a tap of this button and I go to a specific application that specializes in calculating hold-over times. The fluid is already selected, so all that I have to do is select the weather, the actual temperature and the concentration of the fluid, and I will get a result. In this application, I can also set a timer that will warn me when the hold-over time has expired, and the result from here, the two hours, will be noted on the flight plan which it is, at the tap of this button.
Another example is for station information. Having company specific information for a company’s different destinations is the task of another App: however, this application that manages the flight plan knows which airports I’ll be going to; so, I can select the airport for which I want more information, tap on it and it takes me to the other application that shows the information about this airport. If, for example, I want to know which de-icing provider we have at that airport, I can find that here; or the fuel provider, I can also find that here and, once again, upper left corner to come back into the main interface.
There are more examples of what we can integrate here: Mass & Balance, Reports and TechLogs, for example. But the point is that one application cannot do it all in the best way for every company. There are a few big airlines that can influence the functionality of the biggest software providers products, but there are also thousands of smaller companies, like Novair, that look for exactly what we have shown here. Integration between smaller and specialized applications. Therefore, we pledge to all software provider to allow data sharing in some way. For example, with public APIs and, what I mean by public APIs is, at least, a documented way, a free-of-charge way to sharing data.
In that presentation, Johan touches on something really important, the sharing of information. As he says, Boeing has APIs to push and pull information to and from other applications. Airbus has them so do all the eTechLog providers, so it shouldn’t really be that hard to get some kind of data sharing between applications to save time. If a pilot can save four or five minutes from just going back and forth between different programs and entering manual information, he can be ready to depart five minutes earlier, if he’s lucky.
Obviously, something that’s very important is the connectivity. Back in the early EFB days I remember that there was manual offload of the EFB with no connectivity at all; then came 3G, then 4G and now there is a connected wireless Internet on board, there are connections through satellites and the importance of getting the latest data has become more and more urgent. So, if you are doing some sort of flight optimization or fuel saving, maybe looking into tankering to save money, especially nowadays with high fuel prices, you need accurate information when you land.
For connectivity, I regard GigSky (figure 7) as one of the best providers in my experience over several years.
They have the option to fine-tune your needs. For instance, at Gatwick Airport at Gates 1 to ten, there is only one operator with a signal and that’s GigSky. So, then users had to manually go through the list of providers with GigSky and select based on location. But at these gates we wanted one provider while, on the other side of the airport, we wanted the other provider. This is not something that all operators can do.
EMPOWERING AIRLINE AND TRAVEL REBOUND
Talking about empowering airline and travel rebound there are some things on which we need to focus (figure 8).
Enable productivity with artificial intelligence, align partnerships around a new digital ecosystem and drive platform interoperability across the Cloud continuum. Cloud has become key when it comes to EFB with all of the necessary data now stored in the Cloud so, again, the need to secure that data is really, really high.
NEXT STEPS IN EFB CO-OPERATION
At EFB Admin Services, we work closely with Microsoft and other suppliers supplying a range of services such as EFB administration role under ORO.GEN.205, or we’ll undertake special projects to look at the EFB operation, to help fine tune it, to program it to the user’s needs including help with connectivity and the like.
Security is a main focus: a lot of new devices are in the pipeline, as you’ll know, and it will probably be necessary to replace the EFB every three years now because of a new model and/or a discontinued model. We aim to work closely with partners to ensure a quality and tight integration. It’s really time that the big vendors opened up, shared their APIs so we can create more seamless EFBs than we had before.
Unfortunately, the perfect EFB does not exist so we need to take the best pieces that are out there, put them together and integrate them as closely as possible.
Klaus has more than 15 years of EFB Administrator experience, earlier with Norwegian Air and now for a handful of airlines, including new start-up Flyr. He has a background of nearly two decades as an IT operations manager, and is a cyber security certified engineer. A main contributor to EFB development with software, hardware and connectivity providers, Klaus is never afraid to look at and implement new technology if it seems beneficial for more effective operations and a safer cockpit.
EFB Admin Services
EFB Admin Services Int. delivers EFB Administrator services, has decades of experience in the airline industry, and has had the EFB Administrator role in multiple airlines, AOCs and models under both EASA and FAA regulations. Highly experienced in both portable and installed EFB, EFB Admin Services can arrange airport connectivity over Gatelink or airport Wi-Fi, private 5G nodes, etc. and can assist with training EFB Manager/Administrator, and other Flight Operations staff.