How to start an EFB Project- PART I

The Electronic Flight Bag (EFB) Concept

The EFB concept is, in fact, a concept that evolved in the early 1990’ties when FedEx in the USA introduced a Performance Laptop computer to carry out take-off and landing performance calculations. As laptop computers got more powerful and new hardware tablet units were introduced in the following years, this facilitated more modules could be installed, and it sparked a new era of software application development from several aeronautical software and service vendors. The first Chart Viewer/Route Manual app was deployed by Continental Airlines in the USA in 2009 in cooperation with Jeppesen.

Initially, the EFB apps were all Windows-based. Still, with the birth of the Apple iPad in 2009, the introduction of EFB units became more feasible because the unit price of the iPad set a new standard for reducing hardware costs. It opens up the possibility of deploying personal EFB units that remain with the flight crew at all times rather than incorporating aircraft-assigned units that remain mounted in the aircraft and where the Crew does not have access to the units until arriving physically in the cockpit.

Early on, the EFB apps available only covered one function, i.e., a Performance app, a Chart Viewer app, or a Reporting app covering a specific Report type. Still, with the birth of the stronger hardware units around 2005, several European EFB vendors decided to develop a concept called an “EFB Platform solution.” An EFB Platform solution can include several integrated and interconnected modules and offers the Crew a seamless workflow process from pre-flight through a post-flight phase, where it covers multiple module functions and reporting functions within the same application. The advantage of an EFB Platform is that it dramatically reduces the number of EFB apps installed and unifies the pilot’s workflow process, as the pilot can stay within the same EFB Platform application for 70 – 90 % of the time, depending on the actual set-up composition.

Why do we need an EFB?

The basic reasons why you need an EFB are the following:

a) Most Aeronautical chart vendors no longer provide Paper based subscriptions, so airlines have a prerequisite requirement to certify a hardware unit and an electronic Chart Viewer app solution and make it available to their crews – an electronic chart solution will reduce weight and provide update simplicity compared to manually printed charts which need to be updated physically which carries both weight penalties and distribution cost penalties and require a significant amount of person-hours to update physically.  

b) All commercial operators are required that all aircraft manuals and company documents be available in the cockpit to the Crew. Incorporation of a Document Library app facilitating that all the aircraft and company documents are digitally available to the Crew on an EFB tablet will avoid 10 – 25 kg of documents carried per aircraft and avoid running a complex physical paper update process. 

c) Many Airline operators prefer to implement a Take-Off and Landing Performance app, which facilitates electronic Performance calculations in the cockpit and requires certifying an EFB tablet for cockpit use. This way, they provide an electronic application and avoid the more cumbersome use of Performance Gross Weight Chart PDF tables from which the pilot must interpolate between aircraft weight, temperature, and other parameters to retrieve correct performance data.

The more advanced reasons why you need an EFB to digitalize the cockpit are related to one or more of the following requirement areas:

• Pre-flight reporting, including Fuel uplift process along with pre-flight checks
• Processing of Ground-Based DCS Loadsheets in a digitized workflow 
• In-app M & B/eLoadsheet module distribution to airports and handling agents
• In-flight reporting incl. Delays & De/Anti-icing reporting, RVSM checks 
• In-flight Electronic Flight Planning eOFP/EFF eFuel/eTime reporting module
• Post-flight reporting, including customized reporting items
• eReporting (security checks & ad hoc Report types)
• eTechlog reporting incl. MEL & Defect Reporting
• Cabin Crew EFB (Doc Library & eReporting forms & checks for Cabin)
• Loadmaster’s M & B Application (Cargo operators) 

What is an EFB app-based solution?

An EFB app-based EFB solution is one where the functionality is spread out in different software apps, which typically cover only one main function each. Examples of EFB apps: 

• Chart Viewer/Route Manual app
• Performance app
• eReporting app
• Document Library app 
• M & B broadsheet app
• Flight Briefing app
• Electronic Flight Planning EFF/eOFP app incl. In-Flight reporting
• Journey Log Pre- & Post-Flight reporting app
• eTechlog app
• Cabin Crew app
• Scheduling/crew planning/Duty Roster app
• Message app

In some cases, EFB apps overlap each other in functionality, so at times, it can be quite demanding to find out which apps to match and choose if your EFB strategy is built up around EFB apps.

The problematic aspect of an App based EFB structure is that the apps do not include a common back-office portal that interconnects, controls, and gathers all the data from all the various reporting apps in one place, nor do they integrate with each other, nor are they connected to one central database.  

So, by choosing an app-based EFB structure, the airline operator is sort of “without a central IT infrastructure solution” and will have to use individual portals provided for each app, if at all supported. This means that the IT structure tends to be fragmented and a lot more complex to manage as data flows are not centralized, and this is one of the reasons why most airlines get stuck with too many different apps in use, which keeps them busy. This is because they have not realized the advantages of an EFB Platform solution in time and are struggling to find resources to take the steps towards implementing an EFB Platform solution to reduce the number of apps used. One aspect that typically delays the process of considering and taking steps towards implementing an EFB Platform solution in airlines is that change in the Crew’s work routines can be a comprehensive task to get through on both the pilot and management sides.

On top of the above issues comes the need for managing Back-end IT system integrations to connect your Flight Planning system, Scheduling/Crew planning system, Load planning system, Maintenance system, and other in-house systems to the EFB app-based structure. As an EFB app-based structure does not include a common back-office engine solution, it means most airlines get stuck with using some apps and Paper in combination as the structure itself prevents them from easily establishing a fully digital cockpit reporting environment – it simply gets too complex, too difficult or outright impossible to manage IT integrations in general when operating with an App based EFB system solution.

What is an EFB Platform solution?

An EFB Platform solution is one where the functionality of the app provided is flexible and modular and where data flow between the multiple optional modules is fully integrated and interconnected within the same app while at the same time featuring the same User Interface design.  

In an EFB Platform solution, the multiple/optional modules are incorporated into a Menu-controlled and fully integrated workflow. This provides the Crew with a common, more effective, and fully seamless workflow as the pilot can stay within the same app for the majority of tasks to be performed, which increases simplicity, speed, and precision while enhancing flight safety.

An EFB Platform has the technical advantage that pre-flight, in-flight, and post-flight reporting generally can be incorporated into a more customized workflow, where the most advanced EFB platforms, such as EFBOne, in fact, enable the EFB Administrator of the airline, to configure, optimize, and deploy new reporting functions throughout the app locally – without needing any development efforts in-house or from IFS. EFBOne is the first EFB Platform solution on the world market, which contains the technology to bring EFB App management to the fingertips of the EFB Administrator. 

An EFB Platform solution can typically reduce the number of apps used in the cockpit to, ideally, one platform covering all functions but is typically set up with one main EFB app (the EFB Platform solution) and 2 – 3 side apps such as Chart Viewer and Performance app as preferenced by the airline operator which is then integrated with the Platform solution with Launcher functions and data import/export functionality. An app-based EFB structure can easily cover 15 – 20 different apps where none of them are interconnected nor integrated, and they lack a common back-office engine from where all data are managed and automatically stored. Using 15-20 different EFB apps will, in most cases, lead to the fact that the briefing time and data entry time needed by the Crew exceeds the time it takes to run everything in a fully paper-based environment.

By incorporating an EFB Platform solution, crews will be able to complete the Briefing process and planning/calculation and reporting processes and save 60 – 90 % of the time compared to running a paper-based reporting process. This will enable the airline to reduce crew check-in time by 10-20 min per check-in as well, and the briefing time will be significantly reduced by 20-30 min due to data being imported from ground systems and the inter-connected data flow between the module functions facilitate a much better-concentrated overview for flight briefing data and the fact that the pilot will never have to enter the same info twice. The most important advantage is that by running a fully digital cockpit reporting workflow, the airline will have access to all flight data and report data in their network, which can be exported into multiple back-end IT systems wherever needed.

Why don’t we just create our own EFB solution in-house?

Several airlines have tried to create an in-house EFB solution, tempted by the fact that in-house IT personnel convince management it can be done as they find it interesting to play with new technology and to develop an application. The arguments are that “we can do it much better ourselves than an outside vendor” and that “we will save costs as we won’t have to pay an outside vendor for a solution.”

The fact is that an EFB solution created in-house gets much more expensive to run and maintain on a mid-to-long-term basis compared to buying a solution from an outside vendor, as all development costs and maintenance costs will have to be absorbed by just a single airline.

As in-house development is often done by one or only very few persons, there is a significant risk that when they leave the company, their know-how goes with them. Then it becomes difficult to maintain the in-house EFB solution on a longer-term basis or outright impossible to develop/revise the solution when future reporting requirements (i.e., FAA or EASA EFB rule changes) or further module development is needed, and the airline is then forced to seek a new solution from an outside vendor and then faces to re-do the EFB project.

To sum up, the Electronic Flight Bag (EFB) is a digital revolution that started in the early ’90s, transforming flight preparation and operations from paper-based processes to seamless electronic applications. Originating from FedEx’s Performance Laptop, the EFB evolved, notably with the introduction of the iPad in 2009, making it more feasible and cost-effective. EFBs transitioned from singular functional apps to integrated platforms, offering an array of interconnected modules. Benefits of EFBs include weight reduction from eliminating paper charts and manuals, streamlined cockpit workflows, and digital reporting. The EFB Platform solutions, such as EFBOne, take this integration further, reducing the multitude of apps and centralizing data, thereby saving time and enhancing flight safety. While some airlines may be tempted to develop in-house EFB solutions, the long-term feasibility, costs, and maintenance complexities suggest that relying on specialized external vendors can be more beneficial and sustainable.