John Christian Paulshus, Head of Business Development Operational IT Solutions at Norwegian sets out the experience after running EFB on the entire fleet from Q1 2010

Project start-up
In 2005, we initiated a project to consider and, if appropriate, introduce an EFB (electronic flight bag) to Norwegian. The scope of the project was to investigate and identify sources for improving business, identify the related costs, and make a cost-benefit analysis. Some of the questions raised were to consider whether use of an EFB could:

• Increase revenue through increased Payload;
• Reduce paper hardcopy and revision requirements;
• Reduce some keying labour/administration;
• Reduce the maintenance/engineering burden;
• Improve and ensure operational control during expansion;
• Reduce the workload during turnaround;
• Improve fuel control and statistics;
• Save engine life time;
• Improve safety;
• Create value added information for operations.

Our first consideration had to be which type of installation would best suit the needs of Norwegian. The table below shows how the three classes of EFB available differ from one another.

DETERMINING CLASS I, II OR III?

As per FAA AC 120-76A & JAA (JAR-OPS)

Class I has the benefit of being the cheapest and most quickly implemented of the three alternatives and it would be sufficient to cover some of the issues, for example saving engine life time. On the other hand, it cannot be used in all phases of flight, it must be stowed away, may have problems with power and charging, may more easily get physically lost or stolen and cannot be expected to be fit for all issues.

Class II can be used in all phases of flight. It is easily accessible without being a nuisance. It can communicate through 3G and facilitate complex functionality. A Class II device, ideally, never leaves the aircraft.

Class III is the most expensive alternative. It is potentially locked to the CPU at delivery, and performance and hardware upgrades may prove difficult. There are also questions regarding its communication capability – for example use of 3G, may be restricted.

Norwegian decided to implement a Class II solution, with some spare Class I units for special cases (dry lease, delivery flights, etc.) We selected a NavAero system for testing; it was was one of the first EFB class II systems available with an STC for our aircraft. Then we had to wait… and wait, for the STC (supplementary type certification). You may wonder how hard it can be to get an STC. From our experience it’s potentially a real issue but you shouldn’t try to establish a project time schedule without it.

To ensure proper control, the project was divided into phases.

Phase 1
Phase 1 ran from the first Quarter of 2009 until the first Quarter of 2010 with an evaluation process, following implementation of EFB across the entire fleet.

Phase 1 Scope:

• Implement the project using a structured approach of scoping, planning, implementing and evaluation.
• Implement the fleet-wide installation of hardware, EFB Class II, and 3G based communication equipment.
• Design procedures for EFB use with the related training programs and activities.
• Identify and process documentation suitable to be presented in an electronic format.
• Implement EFB applications supporting work processes related to:
  • Performance;
  • Mass & balance – loadsheet;
  • Charts.
• Implement a functional EFB portal/content management server.
• Secure authority approval.

Phase 1 Scope, reinvented.
By the time that the STC was finally approved, we were already at the beginning of 2009, and the CO₂ tax regime for EU and EFTA countries (most European countries) had been decided on. Because 2010 was the first test year for the EU emissions trading scheme (ETS) annual emissions and ton per kilometer reporting, the handling of EU ETS data was subsequently incorporated in the Phase 1 scope. The software that was to be deployed on the EFB was the same software already used for handling performance related activities, M & B and charts, so only required slight adaptation for EFB use.

Phase 1 Planning
The plan was to test the NavAero product over three months and that was successfully completed with specific targets and design requirements set up for areas covered by the different applications. Importantly, software applications suppliers were helpful in adjusting the functionality of their standard applications to fit the special requirements of the EFB environment. We looked around the market for standard software applications that could meet not only the Phase 1 needs, but also most areas where EFB could be used; then a GAP analysis was undertaken to identify areas requiring development, either internally or by the suppliers. Finally, procedures and training material were produced.

One of the things that we discovered was that, if you are breaking new ground, you should share your vision with your suppliers so that you can work together on a system that supports the changed work processes (don’t pave old roads, build new highways). If you are implementing a work process already supported by standard systems, think carefully before you ‘customize’ it.

Phase 1 Implementation
Procedures were publicized, and training was delivered. These included the EU ETS functionality, which was covered by an internally developed report, and EFB versions of standard applications. The EFB portal (content management system) was implemented and the use of EFB received authority approval in August 2009.

Phase 1 Evaluation
There were some challenges to be overcome. For instance, at the outset, some of the crew regarded using the EFB as a hassle. However, quite quickly this changed as they became more accustomed to EFB procedures than paper based routines. Also, we realised that we had to differentiate between what updates could be handled through 3G and what must be handled through physical media. For instance, some software application updates, such as for charts, require large data transfers which is most reliably achieved using a USB memory stick rather than by transmission over 3G. Another important question was, how to handle the hardware. After all, only the brackets are aircraft parts: the displays and the CPUs can be logistically treated any way you want. From our experience, we would recommend involving the technical department and, in particular, the logistics department.

It wasn’t all challenges; we identified some areas that would clearly benefit from operating the EFB. On the performance front we found that derating engines during take-off helps to achieve longer engine lives. Also, the paper loadsheet was replaced with an electronic loadsheet. When ground storage of the electronic loadsheet was confirmed, the paper version did not need to be filled out. One thing we did learn was that we needed an improved strategy for updating applications and data.

Phase 2
Phase 2 ran from the second Quarter of 2010 and was a natural extension of the preceding phase 1. Most of the planned issues identified in the scope were achieved with software deployed in the first Quarter of 2011, but some remaining issues, such as weather information, are still in the test phase, for release during the third Quarter of 2011.

Phase 2 Scope.

• Increased process support, including pre-population of data.
• Adding EFB Software for the following areas:
  • Extended reporting for, among other things,  ground handler monitoring;
  • Extended document library;
  • Weather information, to deliver more updated information;
  • Flight plan data for information, pre-populating and Q&A issues.
• More specific CMS (content management system) control.
• Better methods for updating applications and data.

Phase 2 Planning
An API (application programming interface) was provided by the flight planning system supplier for displaying data which the shell supplier used for showing the actual GUI (graphical user interface) with weather and flight plan information. The EFB portal implemented changes to fulfil the needs for structuring the EFB information and to keep control over the EFB updates. It was planned that applications would mainly be updated through use of ‘images’ which could easily be deployed. Before deployment the images had successfully passed the test stages.

Again, it was decided that updates of application data should be through USB sticks for large amounts of data and through 3G for smaller amount of data. Report formulaes were planned, developed and tested internally.

Screenshoot, EFB Shell. The pilots main menu.

Screenshot, reporting fuel on departure. Remaining fuel is registered in the landing report part

Screenshot, EFB Admin Portal, Syncronisation status. The software and the data must be up to date. This screen is available only to EFB Portal users.

Screenshot, EFB Admin Portal, electronic transferred loadsheets. The electronic loadsheets are the primary source. The paper version is not needed when the electronic loadsheet is confirmed transferred to the EFB content management server.
This screen is available only to EFB Portal users.

Phase 2 Implementation
New versions were implemented using ‘images’ of the hard disk. SMEs (subject matter experts) tested each area before procedures and training material were updated.

Phase 2 Evaluation
The operation is now running smoothly and the planned goals for phase 2 have been achieved.

Project Summary
Evaluation of Initials Goals
The extent to which the program has met the initial goals set for it?

• Increased revenue through increased Payload. There is no conclusive information to suggest that revenue has increased through increased payload.
• Reduced paper hardcopy and revision requirements. Certainly the amount of paper has decreased. Two of three sets of documentation have been removed from the aircraft, and paper handling, such as loadsheets, and fuel reporting, has become electronic.
• Reduced some keying labour/administration. EFB reduces the need for double keying of data.
• Reduced maintenance/engineering burden. This issue will be handled with the introduction of electronic tech log.
• Improved and secured operational control during expansion. Operational control has been improved through immediate electronic feedback and reporting.
• Reduced workload during turnaround. Pre-population of fields, automatic calculations and reduced paper handling all contribute to reduced workload during turnaround.
• Improved fuel control and statistics. Electronic registration automatically provides quality checks for validity of data.
• Improved engine life. EFB delivers the possibility to set engine operational parameters that would be virtually impossible to manage manually.
• Improved safety. Information is more easily accessible so is more likely to be accessed and applied.
• Generate value added information for operations. The report information creates possibilities to monitor crew related events, flight incidents and handler performance.

Conclusion
As things stand, we had estimated the payback time for the project to be 10 months and that has been close to the actual payback time achieved. The EFB has played a key role in collecting data for EU-ETS, and there is a continuous program being implemented to improve functionality and ensure better data quality.

For the future, we plan a number of phased developments including in-flight broadband through satellite which is already installed on six aircraft. By the end of 2012, it is planned that all aircraft will have in-flight broadband installed and there are further plans to connect the EFBs to this broadband. Beyond that, we are working towards a number of enhanced functionalities including an electronic tech log, offline incident reporting, cabin reporting and reporting training events. We also plan to add in crew roster changes and confirmations, fuel and service requests (airborn) and video surveillance as the new system evolves.

Based on our experience, there are a few things that we would recommend to others considering implementing an EFB. The first question to ask is ‘do the benefits apply to our company?’ A fleet of 737 Next Generation aircraft has a lot to gain regarding engine performance, while a fleet of 737 Classic may have little to gain by implementing performance software. You also need to ask, can your company realize the potential gains? What is the benefit in measuring ground handler performance if it is not related to a penalty or a bonus? Lastly, but very importantly, does your company have the resources to implement and support an EFB solution? Even though the EFB will free resources within the company, by eliminating the need of double keying or making document publicizing easier, the freed resources will most likely not possess the skills needed to support the EFB solution.

For more information, these aer the suppliers that we used 

Application	Supplier
Performance	Navtech
Mass & Balance	Navtech
eCharts	Navtech
Weather/Flight plan info	Flight Deck Software AB and Airsupport
Shell	Flight Deck Software AB
EFB/Content management server	Flight Deck Software AB
Hardware EFB class II	NavAero
Report module (Tidy cockpit)	Norwegian

A brief company specific time-line for the installation of EFB in Norwegian