Aircraft IT Operations – July / August 2014

Aircraft IT Operations – July / August 2014 Cover


Name Author

Case Study: Norwegian EFB Connectivity

Author: Klaus Olsen, EFB Manager B-737, Norwegian


Norwegian EFB Connectivity

Klaus Olsen, EFB manager B737, ops flight support, Norwegian, outlines the challenges of connectivity for Class II EFBs – including 3G and Gatelink connectivity.
At Norwegian, we have very small resources within the Flightsupport department, dedicated to the EFB operations full-time, but between us, we have refined the product over time in order to get the best, and most effective, solution possible for our flight operations.
Our first EFB system was introduced in 2008, when we installed the t•Bag C2 system from navAero. We still have this technology installed in the majority of our aircraft fleet (about 85 airplanes) but that number is set to change over the coming months. And even though we are replacing the navAero system with Panasonic Toughpads MKII, the former has done an exceptional job in those six years they have been in service.
All new aircraft acquired by Norwegian since September 2013 are being equipped with the Panasonic Toughpad MKII, and we currently have 16 aircraft operating with the new system, which is supplied courtesy of Scandinavian Avionics. Highlights of the Panasonic tablet are a control panel at the bottom of the Toughpad, and a standalone USB port, which can be used to charge phones or tablets without interfering with operations on the EFB.
Figure 1: Panasonic Toughpads are entering the Norwegian fleet for use as EFBs

Changing systems
Very early on in our EFB program, we decided that we would update and maintain the system only through 3G communications. We had to undertake a thorough test of all the possible operators, in order to find the one with the best coverage, roaming partners and price.
We soon found out that the ‘best price’ element would have to be dropped because, in 2008, there were many providers that could give decent communication services at a low price. However, when it came to roaming outside Scandinavia, the bandwidth was cramped, and we could not get the updates in the amount of time we needed, if we got any connection at all; low price meant low quality in this instance.
We ended up signing up with Telenor as our main provider, committing to a supply contract in 2009. The telecommunications company offered great coverage, was located in most of the countries that we flew to, and, when we went 100% paper-free in 2012, it meant we had to rely on good, stable connectivity to make sure the crew could download their flightplans, documents, chart updates, etc.
The other factor we had to contend with for any of the operators we considered was a rapid increase in price. A high demand for ground connectivity equals higher costs, which meant we, in 2013, had to undertake another set of tests for different operators. This scenario caused a major headache in the organization, and in our department.
Choosing a technology partner
We tested big players such as T-Mobile, Vodafone, Telenor and more, again, but many of them were offering GPRS-only, which is not ideal when it comes to EFBs. We also had to plan in our pretty short turnarounds – about 25 to 30 minutes – and during that time, we needed to organize our flight plans, and get new documents, etc.
Another issue we encountered from time to time was the “blind spots” on a few airports, were certain gates were impossible to get connection, while other operators worked fine on these spots, but fell through on other parts. What we needed was something that would work no matter what, or where….and at a reasonable cost!
To this end, we were helped by a contact at DAT (Danish Air Transport) who told us about GigSky – a Danish-based company – and we began a trial with them, late in 2013. What really intrigued us was that GigSky was focusing on data connectivity, while many others were offering voice solutions with data attached. We weren’t interested in voice on the aircraft, as all we needed to do was to update our EFBs!
GigSky proved perfect with coverage in more than 114 countries, and it benefits from 100% national roaming, meaning that you get a choice of roaming partners at each location. What we experienced – especially with Telenor – was that for different gates, there was actually a full blackout with no signal. With GigSky we are juggling between operators and we can get coverage wherever we are.
We rely on 3G connectivity, which means we have 24/7 status of all the EFBs on our fleet. We have the ability to see when they were last online, what kind of software they are running, and what chart database they currently have. Figure 2 shows how the EFBs are colour-coded, according to their contact with the main system. The ones in green are those that have been in communication with the server in the last 24 hours; the yellow ones have been in contact in the past 25 to 72 hours; and the red EFBs are items that need action as there hasn’t been communication for a long while.
Figure 2: Norwegian’s EFB admin portal, indicating the communication status with the connectivity system

Additional communication tools
Another important system we use when monitoring our EFBs is TeamViewer. As well as the components in operation, we have a spare pool of EFBs at all of our main hubs – including Copenhagen, Stockholm, Helsinki, London and also Spain – but since we are a small team, we cannot rely on training all of our technicians, because that would be too time consuming and require a lot of resources.
So, as a result, each of our clients has TeamViewer installed, and admins can connect to the EFBs using a secure server with an encrypted password. When in the system, we are able to define the user groups, and access can be made via IP addresses, which can make the connection to the EFBs. Making it a highly secured solution.
Whenever an EFB is stranded in Dubai, for example, and it gets a Jeppesen error, or the SQL server has crashed, or the database becomes corrupted, as long as they can get online, they can call and tell us what the issue is. Someone at our end can then connect, and take full control of the EFB onboard. From here, it is possible to complete file transfers, undertake general maintenance, and troubleshoot ongoing issues. Therefore there is no need for a technician to go out to the aircraft on the remote base, and the EFB will, in most cases, be ready to go in as little as 30 minutes.
We also have a high level of documentation control by being online 24/7. If we have a software inspection, and one of the crew says a document is missing, we can connect to their EFB through TeamViewer and upload it. Or, if we need to, we can connect to our server, define the aircraft registration or group that is missing the information, and they will get it as soon as they synchronize with the system.
Mass calculations
We also operate with variable take-off mass levels with the 737s, so by using the systems, we have a complete overview of what aircraft is set up with what take-off and landing mass, and how long it has been running in that configuration.

Figure 3: The EFB admin page allows admin users to monitor all of Norwegian’s EFBs

It is the same situation for load sheets – every pilot has to send one before take-off,  which means we instantly get it through our server, and we can watch it, or send on, through to the people that need to see it. In this situation, we do not have to wait until the plane comes back to the ground, and for the pilot to take his documents into the crew room or hotel to perform a synchronization. All of our EFBs are airplane-attached, and we synchronize at each stop, which means synchronizations up to 20 times a day can occur.

Using the EFB, we go online, and a line at the bottom of the screen tells us when the unit we are working with was last synchronized. The first thing operators do when they get to the aircraft is to perform a sync, and get the documents needed, find the mass and balance data that is required, and then go through a pre-defined list of tasks. These include a synch/update, where the client gets any documents, procedures, notices, etc. that have been updated since the last synchronization.  This is done quickly over 3G. Then a status report is sent from that specific EFB, including a list of the documents it contains, to the server.

We start Jeppesen Flight Deck Pro because we need it to be running before we can start our flight plan, which is to get it pre-populated. The flight plan are fetched straight from our crew briefing system, and all flight plans for the following 24 hours for that aircraft that are being operated, in that time period, gets downloaded. The crew then go in and select what flight plan they need. The system also allows you to check waypoints, with remaining and used fuel, etc. – including taxi and take-off fuel levels. On the display the mandatory fields are default as red, the non-mandatory are yellow, but as soon as you put the numbers into the fields, they turn green.

Pre-flight checks

A series of checks is carried out – using the red, yellow and green numbers. Notes are added here, and then the user signs it off with a five-digit pilot code. Then you save and submit which connects to the server, and sends the filled-out flight plan to our back-office.

When the pilot gets to the cockpit page they will already have the FMS routing, flight number, and crew fields pre-populated, and they can then enter their desired take-off mass. There is also an option of doing a recalc if needed.

The system shows remaining fuel and planned ramp fuel, and we select the fuel supplier used at that location, and enter the fuel ticket number for accounting. We also note the actual uplift, and then make sure the numbers, are correct before sending the reports to the server.

The need for manual input is minimal; we can pull almost everything from our flight plan in XML, and pre-populate it to the different programs that we use. Even the enroute charts gets pre-populated with all the waypoints, TOC, TOD, etc., saving us valuable minutes of manual punching.

Our current software is a combination of in-house development and excellent XML, PDF & document solutions from Flight Deck Software AB, that have put us in the front seat in regards to how the EFB is being utilized today!

We have also tested Gatelink connectivity for our 737 EFBs, but hit a few roadblocks that made it a bit complicated. The concept is that the EFB sends a request attached to its certificate.

  • The airport receives, recognizes it as a NAS request, and forwards the request to NAS’ Radius servers for authentication.
  • The Radius server responds with their certificate, and the EFB verifies and compares to its local certificate.
  • When the authentication process has been successful, the airport puts the unit in the correct VLAN, and communication can take place after IP address have been assigned.

As this process worked great on the 787, but needed adaption to the 737 (attached device vs removable device (Class3 vs Class2)), was the unit-specific certificates was Boeing issued and very hard to reproduce. And as a removable device, when having an issue, is quickly replaced with a new device rather than fixed on-site, the handling of the certificates proved to be challenging. Currently we are only using it on the 787s where we have no 3G at all.

All is ready for Row 44-to-EFB connectivity on our 737s, but not implemented in a large scale yet. The business case for this is ongoing as we speak, and tests shows that stability varies and therefore makes it hard to rely on as a stable connectivity source.

We have learned a lot through our first 6 years of using EFB’s and flying “paperless” and we have changed our focus from selecting a EFB hardware & STC provider to investing in AC infrastructure with full flexibility for the future when it comes to selecting EFB device.  Today’s solution with Scandinavian Avionics gives us full freedom of EFB tablet solution at a sensible low cost.  This meaning that in 3 years we may see either the 12” Surface Pro 3 or a 12” iPad! With more and more software development in html5 it might not make much of a matter if you run Windows, Android or iOS in the future, but as for now we are sticking to Windows 8.1 fuelled EFBs.

We will evaluate again in 1-2 years when we select our next EFB hardware unit.

Company Biography

Norwegian is the second largest airline in Scandinavia, and third largest low-cost carrier in Europe. Headquartered at Fornebu, outside Oslo, it employes 3,000 people at various locations around the world.

The airline has bases at Oslo Gardermoen; Bergen; Stavanger; Trondheim; Stockholm Arlanda; Copenhagen Kastrup; Helsinki Vantaa; London Gatwick; Alicante, Malaga, Las Palmas, Tenerife (Spain), Barcelona, New York, Miami and Bangkok.

Norwegian has 392 routes to 124 destinations, and has 500 flights a day. In 2012, it carried 17.7 million passengers. It offers flights to attractive destinations tailored to both the business and leisure segments to and from all its bases in Scandinavia.

Contributor’s Details: 

Klaus Olsen, EFB Manager B-737, Norwegian

Klaus Olsen is currently EFB Manager B-737 at Norwegian Air Shuttle. He has 18 years’ experience as an IT operations manager, and as head of IT security for Norwegian Financials Daily, PC Magazine, Kapital, Hegnar Media and many other titles.

Described as a hands-on problem-solver with high work-ethic, and even higher pace of work, Klaus is also outspoken and creative, as well as a constructive listener. Often mistaken for being ignorant and frequently socially incompetent, he boasts a sense of humor that few seem to grasp. Despite this, openness, seriousness and quality do tend to be key elements in all his activities.

Klaus, who started the EFB project in Norwegian Air Shuttle in 2009, has a number of certifications and fields of expertise including: EFB software and hardware; SSCP; MCSE and MCP; Quality Assurance; IDS/IDP; and web security.

Comments (0)

There are currently no comments about this article.

To post a comment, please login or subscribe.