Klaus Olsen, EFB Administrator, Norwegian outlines Norwegian’s extensive EFB project and decision to develop its own EFB solution

Norwegian first started the EFB project around ten years ago, at a time when there were hardly any vendors that could provide the software the airline was looking for; so it was decided very early on to build our own. We have several AOCs (Air Operator Certificates) as the airline operates not only out of Norway (2 AOCs) but also in the UK, Ireland and Argentina. Having said that we decided to build our own EFB solution in cooperation with a company, FlightDeck Software in Sweden (http://www.flightdecksoftware.se/),  who have more or less been Norwegian’s in-house developers from the start and they’ve been efficient, good at tailoring the software to meet Norwegian’s needs.

Before going any further, I’ll give readers a brief explanation of how the Norwegian EFB has been built (figure 1).

As you can see, at the bottom of the figure, is a graphic representation of the EFB. Everything is done over cellular connectivity; we use local Wi-Fi where possible at the airport as well as on-board Wi-Fi where that can be utilized. Cellular connectivity is through GigSky and some 80% of connectivity is over LTE/4G.

We also have a pretty good overview of usage by country (figure 2) so it’s easy to keep track of the costs and usage.

There are pros and cons for both sides of the decision as to whether to build your own EFB or buy a ready-made commercial solution.

Build your own software in-House

The biggest benefit of building in-house is the level of customization that can be incorporated which is not always so easy when using a commercial, off-the-shelf vendor. We also felt, at Norwegian, that building in-house gave us greater control with developing customized software that could make the interface more familiar and easy to use. Also, building in-house means that the team doing the job will be of your choosing and gives the airline access to knowledgeable support, at first hand from the people who built the solution: as against a commercial vendor taking, perhaps, two or three quarters before they could deliver the software updates that the airline might want. That was very important to Norwegian. But, of course, building your own EFB isn’t all pros.

The cons of doing it in-house include that the in-house developers might lack knowledge, expertise and wider market experience to create sophisticated software capable of handling the tasks required by the airline. That said, if only basic software is required, that might not be an issue. Also, adapting to new platforms that might be encountered in the future could be difficult because technology is constantly evolving, as readers will be well aware.

Commercial software

Among the pros for commercial software is the fact that it has the benefit of being extensively tested. In comparison when you build your own tailor made EFB solution it will require you to take a more active role in the development and testing process.

Commercial software will also be in use with other customers which provides the vendor with the experience to be able to carry out a quicker, smoother integration. Furthermore, you can expect a relatively fast deployment from purchase to installation, allowing the airline to save time and get back to what is important for an airline because, again, commercial software has already been tested.

However, on the con side, commercial software can accrue high support and maintenance costs and, in order to address any technical issues, you’ll be at the mercy of a vendor who sets and can change the price of service. That could also be true of an in-house development but the waiting period for support is something that Norwegian quickly discovered when we went out and looked at vendors; and we concluded that we wouldn’t have the time to wait for any updates that we wanted as we would have been tied to the vendor’s release plans which could have ended up costing time and slowing operations.

Figure 3.1 shows how Norwegian’s EFB software layout looked in 2014.

[[INSERT SLIDEs 8 AND 9 HERE If this can be one of the wider columns so that the figures are not too small but putting them side by side will better illustrate the point than in full size, one under the other]]

   

And figure 3.2 shows how it looks in 2018. So, in four years, the main change was the logo in the center. Well not quite because a lot of what happened took place in the background. First of all, Norwegian has never paid excessive attention to appearance, the way it looks; for us it has been more about the functionality. There could be a lot of graphics to make things look super nice but that has never been a priority: the number one priority has been functionality (figure 4.1). That’s why, even though it appears that only the logo and a couple of bits of text have been changed, the reality is that everything in the background was revamped during that time to suit the airline’s and pilots’ needs.

Figure 4.1

Norwegian has a very extensive EFB portal that has also been built by FlightDeck Software. It ensures a high-level of operative control under heave growth, especially towards the authorities. The portal is developed with several needs in mind; easy retrieval of reports and data when requested or during investigations.

We gather all data in order to identify trends that might benefit efficiency of the operation, and of course to increase security and quality.

All access in the portal can be set and defined for each user on various levels. There are admin users, there are supervisors, there are specific users that might only need access to the QAR (Quick Access Recorder) files to ensure that the QAR files have been pushed from the EFB to the server. This is also a very easy way to show the authorities how the airline manages full control over the access to EFB data.

The same is true for pushing various files out to the EFBs which can be managed on either an AOC (Air Operator Certificate) level, on an aircraft level or on a refined aircraft level, i.e. 737NG or 737MAX or 787. It’s even possible to send program updates to the EFB, again selecting just one aircraft or all the aircraft or just a type of aircraft.

The system can also pull a lot of files from the EFB. Sometimes it’s necessary to access log files in order to troubleshoot as to why the system might not be working as it should. We can simply browse through each and every document, have it sent to a specific email or a group email to troubleshoot what might be the problem with a specific EFB or a group of EFBs.

In the same way, configuration files can be sent out. As was mentioned at the start of the article, Norwegian has up to five AOCs which means that, in theory, we have five different EFB set-ups because each authority requires different settings: for instance, one AOC might require one or two different parameters than another AOC. So we can easily send out all the configuration files to the EFBs. We can also select, quite quickly if an aircraft is moving between AOCs (say between Norway and Ireland), to send new configuration files to ensure that the EFBs are configured to the correct AOCs at all times.

There are QAR files being pushed through to the EFBs: one EFB is in charge of pulling all the QAR files and sending them to the server using a small device called Web FB which can be set up with a router feature so that the EFB connects to the QAR device or to the Web FB device and fetches all the QAR data from that. It pulls it into the EFB and, through an automatic sync process, sends it to the server. Plus we can easily select each and every report in the admin portal or send it to the authorities if needed. On the server you can also download QAR files directly for specific aircraft if you wish.

We have very good control over with what or how often the EFB connects (figures 4.2 and 4.3) using color coding.

Everything in green indicates devices that have been in touch with the server in the past 24 hours. When a device on this screen changes to orange, it’s up 72 hours and if it changes to red that indicates that it’s been more than 3 days since it has been in contact with the server, so we will see that there is a problem with connectivity and we can troubleshoot appropriately.

There is also something called ‘Sync Files’ and Sync Doc’, programs that run automatically in the background. As long as the EFB client is connected, it will connect with the server, try to look for updates, try to look for new settings, send QAR files, send reports, etc. and trace files. All reports are sent to the server before take-off to ensure full control if there is a problem with the load sheet or with the performance, it can be checked while the aircraft is airborne without the need to wait until it is on the ground again to connect and send the reports: everything is sent before take-off.

I’d like to give you a brief walk through of how we use the Norwegian EFB. The pilot would first have opened 3G but, as the screenshot (figure 5.1) shows at the bottom left, it’s already connected, flashing yellow and green. So, in this case it’s connected to the wireless network at the airport or the onboard wireless network.

What the EFB first does is connect to the server, look for any updated files and, if there are updates, it starts pulling them down. Next, the chart software is started; Norwegian uses Jeppesen charts. The pilot goes into the system, enters his call sign and then, automatically loads his route; in this case, a rather long route from Stewart(SWF) up to Bergen(BGO) in Norway (figure 5.2).

This flight is being operated with a B737MAX and the next action for the pilot is to go into the flight plan viewer, again a direct connection with the EFB server which fetches all the flight plans that are available for the next 24 hours (figure 5.3).

In this particular case, there is only one flight plan available so that is selected but there is also the option to read flight plans for other aircraft if needed. The pilot goes into the flight plan, enters taxi fuel, take-off fuel (this flight needs a lot of fuel) and goes into the SIGN module where red items are mandatory actions, the yellow are optional and the green just indicates that the item has been actioned (figure 5.4).

 

Now, going to the next piece of software, Tidy Cockpit, also developed in-house, there is the possibility to set various take-off mass if the aircraft is a 737NG (with the 737MAX it is set so the pilot is not able to change that). They select ‘pilot flying’ and ‘pilot monitoring’ to make sure all the reports are typed correctly, set the remaining fuel on the aircraft (in a lot of cases that is already set when they take the aircraft over) enter the required fuel, the fuel provider and fuel ticket number before setting the actual uplift. There are a lot of security measures here; so, if a wrong number is selected or entered, the system will tell the pilot, who is then able to correct it. The fuel report is sent direct to the server and everything is available (figure 5.5).

 

Going, then, into Performance, the pilot sets the correct airport, selects runway conditions and temperature and then goes into the Mass & Balance section. Pretty much everything is pre-populated so the pilot just needs to enter the Pax, including how many children and infants are on-board. It’s also possible to change the catering with several catering configurations and to move the catering back and forward in order to get correct weights. There will be bags in the hold but, as Norwegian is a low-cost operator, most passengers prefer carry-on, cabin baggage; nevertheless there will be hold bags plus some mail. The pilot calculates everything, gets their envelope and submits it all to the server. Again, the pilot needs to sign-off the load sheet using their employee ID and a set PIN code which can be altered by the crew themselves. After a few seconds there is a notification that the load sheet has been sent to the server (figure 5.6).

The next stage is the take-off data, select the runway, perform the calculation and it’s pretty much good to go (figure 5.7).

Going back to the main menu and into our flight planning software again, the final pieces of the RVSM (Reduced Vertical Separation Minimum) checks can be done. Then departure ATIS (Automatic Terminal Information Service) which turns everything green as soon as it is selected. It’s also possible, at this stage, to enter some miscellaneous information if needed. Furthermore, on one of Norwegian’s AOCs it is mandatory to make sure that all notices have been read by all crew, so the Captain needs to confirm that and, again, sign with his PIN code. Finally, it’s a matter of saving and submitting to the server (figure 5.8).

Again, there is a confirmation that all data has been sent and the pilot can go back into the report software, if there were a couple of issues before take-off (no power available, no ground handler available…). The same is true for arrival and what kind of landing was performed, say Cat 3, what kind of approach, say RNP (Required Navigation Performance). It’s pretty much up to each airline as to what input they want on their report; this is specifically tailored to Norwegian’s needs

Back, again on the main menu. There is also a temperature correction program that is very much used nowadays, especially in Europe with all the variations in wind and snow conditions. Users can go into the system to read previous load sheets if they wish or need to; they can also send them directly to their email or to the handler’s email or get a print out through ACARS (Aircraft Communications, Addressing and Reporting System). The notepad facility is more or less an email program for quick notes that allows users to send emails within the Norwegian system or to a pre-defined group such as Catering, MOC (Maintenance Operations Center), etc. (figure 5.9). Again the pilot needs to sign with his employee ID. There’s a pop-up saying that the email has been sent but, if it was not connected at that time, the message would simply stay on the EFB until there was connectivity when it would be automatically sent.

Brightness can be adjusted through the software as well as by the buttons on the side of the EFB. Documents are handled by Vistair DocuNet (figure 5.10). Here all the AOCs are combined, something that you wouldn’t typically see in an aircraft where you would normally have only the documents for that specific AOC but whatever the pilot needs can be found here. There’s also a document browser that holds documents specific to the aircraft in question.

This is pretty much how the software works. As you see, we have an admin button on the side where users can actually exit the EFB Shell and go into Windows for maintenance reasons or rename the EFB if it needs to go on another aircraft. It’s also possible to put in information such as the SIM Card or some part numbers, the module allows that as well.

That’s pretty much how the EFB is set up; as I said, we’ve done this ourselves from day 1 but it’s still not a cut and dried case; it’s quite hard to definitely conclude whether to buy or build. Of course, ultimately, it all depends on the airline’s needs. As I’ve said, Norwegian started out ten years ago when there was really no option to buy the software off the shelf. We had to start somewhere so we started building and have continued with that process ever since. The IT department at Norwegian wishes to be a part of this program but Flight Support is not sure how necessary that might be. As with the whole project, there are pros and cons from involving the IT department. There are times when we, in the EFB Administration, would like to have IT on board for IT specific tasks that we cannot do for ourselves: so we hope in the future to get IT more involved than they are today.

If we were starting today with many EFB solutions available on the market, would we make the same decision as was made ten years ago? The answer is ‘Yes’ and ‘No’. We would probably buy the basic software from a vendor who had already developed content, features and functions that weren’t available ten years ago and would fit 60-70% of our needs; but we would still like to have the ability to tailor the solution to Norwegian’s specific needs so that would be a mixed decision.

In the end, whether to buy or build all depends on the operation, what they are looking for, what are their needs in regards to tailoring. So, rather than giving a definitive answer as to whether an airline should build or buy I’d rather leave the choice to readers with, I hope, this article giving them some idea of how Norwegian did it for ourselves.

Klaus has been in charge of the EFB systems in Norwegian or nine years, coming from a background as IT operations manager for Norwegian Financials Daily. He is well known for his work ethic, which is often referred to as 24/7/365. He is also a main contributor to why Norwegian is a pioneer in the EFB field, and never afraid to look at, and implement, new technology if it seems beneficial for more effective operations and a safer cockpit.

Norwegian is a low-cost airline, the largest airline in Scandinavia, and the eighth largest airline in Europe by passenger numbers. The fleet of around 150 aircraft includes Boeing 737-800s, 737 MAX and 787 Dreamliners with an average fleet age of just 3.7 years, one of the youngest and greenest fleets in the world. In 2015 Norwegian was named the most fuel-efficient airline on transatlantic routes by The International Council on Clean Transportation (ICCT).