Articles
Name | Author | |
---|---|---|
Column – The World according to IT | View article | |
Case Study: The power of XML – for dynamic operation manuals on EFBs at TUIfly | Sebastian Franz, Referent Director, Flight Operations, TUIfly, and Klaus Fenchel, Managing Director, Ovidius | View article |
Case Study: Norwegian EFB Connectivity | Klaus Olsen, EFB Manager B-737, Norwegian | View article |
EFB Tablet Strategy: Apple iPad vs Microsoft Surface | Hank Putek Jr., 777 International Pilot & Training Committee Member, and Brian C. Tighe, Captain 767 & 757 and Deputy Chairman Training Committee, Allied Pilots Association | View article |
Case Study: Norwegian EFB Connectivity
Author: Klaus Olsen, EFB Manager B-737, Norwegian
SubscribeNorwegian EFB Connectivity
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.