The Value of Back Office Integration - Paperless Flight Bagifs.aero/res/EFB BOI Survey by IMDC, Aviation Consulting Group.pdf · Electronic Flight Bag (EFB) technology has been a

IMDC EFB White Paper 1

The Value of Back Office Integration

Electronic Flight Bag (EFB) White Paper

Andrew Kemmetmueller

Managing Consultant


Executive Summary

Electronic Flight Bag (EFB) technology has been a topic of discussion for airline Flight

Operations departments for over a decade. During this time, both the scope and the

opportunity of an EFB project have changed radically. Originally developing out of a

desire to eliminate paper from the cockpit via charts and manual automation, EFB has

morphed into a general automation tool. With this increased functionality, however,

comes additional complexity which has become a point of emphasis for several airlines.

As a basic “Information Technology (IT)” system, an EFB is typically defined as a

computer in the cockpit. However, as with most IT systems, the unit on the aircraft is

linked directly or indirectly to a ground system (core) which provides a common

application database and support for the components in the aircraft. As airlines add

disparate applications from multiple vendors, there is commonly a need to integrate the

applications on the ground in what is called a “back office.”

The combined list of benefits resulting from the integration of the EFB back office is the

topic of this industry white paper. The information provided in this white paper has been

collected by IMDC through a variety of interactions with airline Flight Operations and IT

staff. The most significant source is the 2010 EFB Survey performed by IMDC which

captured, through an industry survey, the current status and desires of over 60

commercial airlines. The combination of this data is the first in the industry, and allows

IMDC to provide this report to the community.

We hope that you enjoy this report!

Andrew Kemmetmueller

Managing Consultant


Sponsored By:

Table of Contents

Executive Summary ......................................................................................................................... 2

1. EFB Back Office Overview ....................................................................................................... 4

1.1. EFB Database (or Data Repository) ................................................................................ 7

1.2. Configuration Management System ................................................................................. 9

1.3. Communication Management ........................................................................................ 11

1.4. User Dashboard/Interface .............................................................................................. 14

1.5. Security/Encryption ........................................................................................................ 15

2. Back Office Integration- The Essential Glue ........................................................................... 17

2.1. Data Storage and Sharing ............................................................................................. 19

2.2. User “Portal” .................................................................................................................. 23

2.3. Software Loading ........................................................................................................... 25

2.4. Common Security .......................................................................................................... 28

3. Quantifying Back Office Integration ........................................................................................ 30


1. EFB Back Office Overview

As airlines begin a project for Electronic Flight Bag (EFB), many understand the need

to focus on the hosted, or back office, components of the system. As a client/server

architecture in most cases, the EFB requires a central database and application

management to function properly.1 This back office enables core management of the

system, allowing the airline to reduce management overhead, ensure proper

compliance for regulatory certification, and efficiently manage content located on the

electronic device. The industry consensus today is for an EFB architecture with a

back office that supports remote cockpit-based clients and develops an ideal system

for expanded growth in the future.

The EFB back office consists of a number of components, each important in its own

right to the viability of the system. These components include management functions

for the various applications on the EFB, as well as the distribution system for the

units.

1 Some Class 1 EFB programs are basic laptops without any back office system. In these cases, the computer is simply reimaged to update the unit, and there is no electronic version control of the units.


Figure 1- EFB Back Office Components

This section will identify and define those primary elements of an EFB back office

which are common across airline programs. In every case, IMDC has identified

multiple options from suppliers, which can be confusing to the decision maker in

the airline. For example, IMDC has identified over 20 different communication

management software systems for EFB in the marketplace.

Although regulation has focused extensively on the components of an EFB

system installed on the aircraft, there are some areas of the back office which do

impact governmental approval. In particular, the ability to validate the installed

software on individual units is a paramount concern based on feedback from

airlines in the survey. It should be noted that attention to the back office is likely

to increase once the number of installations increases; the familiarity of such

systems will increase the number of questions from the FAA and other

authorities. As such, there should be a reasonable expectation that systems will

need to undergo some element of change in the future to meet new regulations.

Although this section includes components of a back office which are most

common to airline programs, it is not an exhaustible list. Each program develops

Communica)on Management

Security/Encryp)on

Database Version Management

Administra)ve Interface


a unique combination of applications, hardware, and operational procedures

which creates its own back office implementation. However, it is clear that these

components provide the foundation for the additional functionality.


1.1. EFB Database (or Data Repository)

Essential to all EFB programs is a database where the relevant electronic data is held for

eventual distribution to the aircraft system. In some cases this is called a “repository”. In

many EFB programs, however, the complicated nature of the system results in many

disparate databases where much of the same information is captures multiple times.

As a component of the EFB system, the database is relatively simple in its responsibility.

It is designed to hold data for one or more applications which would use that data at some

point in the future. The database, however, does have some key aspects which impact

the development of strategy for the overall program:

+ Is the database designed with a naming convention which provides future

incorporation of use by other applications from different vendors?

+ Is the database using a proprietary security protocol, which impacts the ability for

automating inputs/outputs to the database and the use of the database by third

parties?

+ Is the database set up in a format which will allow for advanced searches or

queries to the dataset in order to achieve better results?

+ Are there any protocol translation issues for data prior to entering or leaving the

database in order to support future applications?

The database is ultimately the core of any

EFB system, and can provide a number of

opportunities to improve efficiency in the

overall architecture. In over 75% of

researched airline programs, there are two

or more non-harmonized EFB applications

which require a database. In these

programs, the databases contain essentially

the same data, but in very different formats.

In other words, most airline EFB programs have overcome database incompatibility by

partitioning the EFB by application. This results in a number of databases supporting the

EFB, which typically overlap considerably. As most EFB programs rely on the addition of

future applications to the system, having a database architecture which can consolidate all


data into a single repository for all applications has value and benefit to the airlines. This

may not be the first priority for most programs, as evidenced by the current design, but

ultimately will play a leading role in the ongoing success of the program.

With the current ARINC 840 framework not addressing a standard database format,

vendors have been primarily left to develop their own, which optimizes the needs of their

specific application or set of applications. From the airline side, the EFB is to this point still

considered a “stand-alone” system, which is not connected into other systems to a degree

where IT or other organizations would be concerned about database formatting.

Over time, given the foundational aspect of the database on long term success for an EFB

program, IMDC anticipates that airlines will drive the community to develop a standard

database format or architecture. This would allow multiple applications originating from

different vendors to jointly share the database.


1.2. Configuration Management System

Configuration management is one of the most discussed elements of an EFB system.

Given that the EFB is designed to reduce costs to an airline in large part through

automated distribution, it is not a surprise that this is the case. The supplier community

has likewise viewed this component of EFB to be a strategic differentiator which can

improve their market share. The results are mixed in that the competition in developing

configuration management systems has resulted in a fair amount of development, but the

implemented systems are fairly basic.

The initial purpose of a configuration management system is to electronically support the

proper loading of new data on the EFB in the aircraft. The system usually provides the

following capabilities to support a certified EFB system2:

+ A “client” (EFB) and “server” (Host) which are components of the same application

and interface with each other

+ A means to assign data to a single device, aircraft, subfleet, or fleet of aircraft

+ A user “dashboard” or graphical user interface (GUI) which allows for simple

viewing of EFB configuration statistics

+ A client capability which is able to report on the current configuration of the

relevant EFB and/or applications contained on the device

+ A log which is presentable and allows airline to meet audit requirements

In a recent survey, IMDC noted that there were over 20

configuration management systems in the EFB

marketplace. These systems tend to be closely tied to

the system integrator of the project, or to the primary

application supplier. The resulting mixture of systems

has varying priorities. Those provided by chart

application providers, for example, tend to focus on

delivering large files and security. System integrators

tend to work towards a system which will support

multiple applications from different developers, but are

still quite basic in functionality. 2 A configuration management system is associated with Class 2 and Class 3 EFB systems. Although with notable exceptions, Class 1 installations do not regularly use a configuration management program. In the case of Class 1 EFBs, the software is usually removed and reimaged. This process is not tracked or logged with a central system for accounting.


In this area, the new systems by Boeing and Airbus are presenting both opportunity and

issues for airlines. As the airframers move to automate software part delivery to their new

aircraft such as B787, B747-8, and A350, there is a divergence away from common

operational practices in the industry, particularly when considering third-party configuration

management applications. In other words, both Boeing and Airbus have clearly indicated

that software part distribution for the aircraft will not utilize an outside supplierʼs

configuration management system, either for an EFB or other technology.

This position is not in and of itself threatening to the development of strong EFB

configuration management systems. However, both Boeing and Airbus have invested

considerable effort into EFB programs over the last decade, and this development has

overlapped with the software loading discussed in the previous paragraph. The lack of a

clear model for integrating the airframer system with third party applications is creating

confusion among many airlines who wish to adopt only partial components of the airframer

programs in the short-term.

For many suppliers, the concept of configuration management is exclusively for a single

application and therefore is optimized specifically for this case. The configuration

management software is also either closely related to, or incorporates, communications

management. Although not identical, the two systems are linked and require cooperation

which is often made easier by joint development.

Although configuration has not presented many airlines

with issues to date, this is due primarily to a lack of full

implementation in most instances. Airlines have yet to

determine the scope of this aspect of an EFB due to the

fact that current installations continue to rely on manual

loading of data via USB or alternate media. Those EFB

projects which have included connectivity have identified

configuration management as a principal concern moving towards advanced operation.

The most threatening issue related to configuration management is the requirement by the

Federal Aviation Authority (FAA), as well as others, to be able to demonstrate current

configuration of the EFB at any time. This requirement is based on current practice for

pilot flight bags and manuals. The audit for paper processes is expected to continue

electronically.


1.3. Communication Management

As with the closely related configuration management, communications

management is an important element of advanced EFB systems and is

foundational to proper business and operational savings for the airline. Although

communication management is not a new issue for airlines, the complex

applications and increased data volume requires the airline to consider non-

traditional forms of communication, such as Wi-Fi or cellular data, as a means to

pass data from the aircraft.

A communication management system typically consists of an important client

residing on the aircraft EFB, and a central management server where the airline

administration can adjust the priorities and settings of the system. The system is

software, but does control access to a number of different hardware systems.

Communication management systems for EFB are being developed from three

primary supplier groups. First, those companies which have been integrated into

the communication supply

chain, such as SITA and

ARINC, have developed and

are still developing

communication management systems which are applicable to the EFB market.

The second supplier group is the airframers, who have built advanced

communications infrastructure into their new generation of aircraft and have

consequently taken a vested interest in the management of these systems. It is in

a third and final group, however, that the strongest impact on the future of the EFB

market can be found. .

The final group developing in the EFB market is a group of companies which are

moving to a wider market presence as a system integrator. This group of

companies includes several companies in the application or software development

sector, but also includes those from a hardware background as well. These


system integrators are combining the importance of communications with the

management of the overall system.

Communication management systems are foundational in providing a conduit with

which the airline can pass data to and from the onboard EFB. As advanced EFB

programs connect into the aircraft system, they provide a path to systems such as

VHF datalink, Satcom, and HF datalink. As the EFB is typically the largest volume

of traffic, airlines view the need for a communication manager as critical to

managing costs and achieving benefits. The following are a list of the highest

priority elements of an airline EFB communication management system:

+ Ability to identify which

communication options are available to the

EFB at any given moment

+ Prioritize access to the

connectivity based on user-defined access

controls

+ Manage any security

requirements of the communication links

As a foundational system, communications

management is identified as the single most important issue for airlines who do

not have an EFB system today.3 With the expected growth in number of

applications and data volume, airlines universally anticipate that communications

will play a major role in the success of their program.

As with configuration management, the airframers are playing a key role in the

development of this area of EFB programs. Both Boeing and Airbus have

developed components of their new systems to manage communications for the

aircraft. While these components provide airlines with a management capability

that is very strong, they are nonetheless still specific to aircraft type, and not

3 IMDC 2010 EFB Survey


universal in operations., The polarization by OEM is leading to general

disappointment over the universal connectivity management which airlines

ultimately desire.

Airframers and other suppliers are trying to develop a common interface through

the work conducted in the Aviation Electrical Engineering Committee (AEEC)

Aircraft Ground Information Exchange (AGIE), a part of ARINC 840, and Manager

of Air-Ground Interface Communications (MAGIC). Both committees are led and

managed by Airbus and Boeing staff. To date, the specifications have made

progress in committee, but airlines have commented that any operational use of

the current discussion is still an indeterminate distance in the future. It should be

noted that although participation includes many suppliers, the preponderance of

the industry is not involved and therefore not contributory to any common

standard.

Airlines maintain that Communications Management is seen as their primary issue

of concern with EFB programs. . As airlines continue to integrate EFB into their

operations, it is expected that communications management will become an

increasing impact on business cases and priorities.


1.4. User Dashboard/Interface

The user dashboard is an underwhelming, but integral, element of the airline

program. It can impact, in a direct manner, the airlineʼs ability to recognize the

cost savings associated with automating the flight deck through an EFB.

Available from every supplier, the dashboard is designed to provide an EFB

administrator on the ground with a tool which will allow easy support of the overall

program. This may be limited exclusively to configuration management, but may

also extend fully into the operations to include communications/messaging,

dispatch and dynamic flight operations data, and a “temperature gage” which

provides an indication of the real-time status of the overall program.

Given that the dashboard is offered by all vendors, airlines do struggle with the

aspect of using a single login/site for general administration. For example, one

Asian airline is forced to login and use five dashboards to enter and recover data

based in a single EFB. This is due to a general lack of integration between

vendors on this component. Cost/benefit for the suppliers does not currently

support this effort, but will likely have an impact on the airlines in the medium-term

given the increasing effort involved with system administration through multiple

interfaces.

For airlines, this foundational component is a direct driver into their cost

reductions. Most airline programs are justified with some component of cost

savings based on the reduction of personnel involved in paper processing and/or

delivery to the aircraft. To manage this process electronically, an EFB

administrator uses a dashboard (interface) provided by their supplier to collect,

process, load, and recover data from the EFB on the aircraft. The more

dashboards required to manage the EFB, the more personnel are required to

administer the system.

In Section 2, IMDC will further outline the costs and benefits associated with the

user dashboard component of the system.


1.5. Security/Encryption

Although not directly a component of an EFB system, security is an overarching

aspect of an EFB program which provides the last of the foundational items in this

paper. Security has been virtually ignored by most airlines who are more focused

on achieving basic certification and pilot training. As paper-based systems did not

require security per se, there is no real driver to focus attention in any significant

amount on this aspect of a program.

The exception to this in major programs is with

communications. In these cases, there is an

effort by the airline to enable some reasonable

form of encryption to protect the data from

accidental or malicious distribution. This is

particularly the case when there is a wireless

distribution involved using Wi-Fi.

Security is an essential component of the EFB program primarily to protect the

integrity of the data being delivered to, and recovered from, the aircraft. Most

programs do consider the data delivered to the aircraft to be more important, but

there is currently an increasing awareness that the data recovered from the

aircraft is growing in significance as EFB assumes a more important role in

maintenance operations.

Unfortunately, there is a lack of industry efforts to address security for the EFB in

general. Volpe is actively working to promote discussion of the issues related to

EFB security, but no concrete solutions have been promoted to date for

operations. AEEC is attempting to address this in the specifications, but much of

the effort continues to be on the communications level of the system. Security

considerations for EFB include:

+ Single sign-on or secure sign-on for pilots in the cockpit

+ Biometric and/or other secure tool (SmartChip)


+ Access control for EFB administrators

+ User activity, logging, and trend alerting when a user is not conducting

typical functions

+ External source validation and restrictions

+ Packet encryption

+ Source/destination validation on cockpit unit

As an increasing amount of flight data is sent electronically, there will be a

growing need to verify the data is from a trusted source and valid for the EFB in

question. With the conglomeration of multiple suppliers in a single EFB, the

element of security quickly can become complex as the airlines address the

question regarding which system to utilize for security. There does not currently

appear to be a strong and certain answer to this question.

It is expected by many airlines that security will be an area where the FAA and

other regulatory bodies will drive significant changes in current programs. Airbus

and Boeing are both investing considerable effort into this aspect of the EFB to

meet certification efforts for new aircraft platforms. The difficulty is the lack of

direction provided by any regulatory agency today instructing airlines how to meet

security requirements. This is likely due to the fact that the FAA and others have

prioritized other aspects of EFB programs (such as Lithium-Ion batteries).

Ultimately, security will have a reaching impact on the design and operation of

EFB programs globally. The implementation of security will be both a challenge

and opportunity for airlines in the near future.


2. Back Office Integration- The Essential Glue

As Section 1 indicates, there are a number of EFB components which are foundational to the

success of a program. However, many of these components are not integrated in current

EFB projects, nor are there any strong industry initiatives close to doing so. The end result is

typically a composite of multiple applications developed by various suppliers which are not

designed to communicate and pass data between each other.

In most cases, these disparate applications have overlapping functionality, such as version

control and user interface, which requires airlines to make a decision about operational

preferences. It is becoming increasingly important to airlines that they consider the close

integration of their many EFB applications in order to best recognize their cost savings on the

program.

In this sense, the integration of the back office is the important “glue” which holds the system

together. Not only is the impact felt in the obvious areas of cost savings, but also impacts

ancillary aspects of the program such as training and pilot satisfaction. By implementing a

comprehensive system where data is shared, delivered communally, and managed centrally,

the airline is able to not only operate an efficient EFB system, but also plan proactively for the

future knowing that implementation of new applications minimally affect the current

operations.

Standardization is important to the integration of the back office, but the current efforts are not

at a point where industry is beginning to utilize the recommendations. Without

standardization, airlines are left alone to push suppliers to work together to support a single

platform back office. System integrators are advocates for this effort in many programs, but

the airline is still the principal driver for the most part. In time, the standards will undoubtedly

be adopted which should assist with integration. Before then, those airlines who seek to

integrate the back office will likely have a competitive advantage in their EFB program.

This section will address those items airlines have indicated provide the most value in a back

office integration. This list is not comprehensive, but provides a prioritized list of subjects

which are industry-relevant to the current market. As with all technology, this list may differ

for each airline, and change rapidly over time. Currently, , this list represents the aggregated

interest of a substantial group of airlines.



2.1. Data Storage and Sharing

One of the key advantages commonly cited by airlines as a benefit to electronic

documentation is the ability to share data across various forms. For example,

data from the flight plan regarding fuel loads, trim settings, and other items are all

applicable to the performance applications used by the crew to adjust the aircraft

prior to takeoff and during flight. With paper processes, this information is usually

posted in a location by the crew member and referred to frequently during

operations.

With the transition to an EFB, it is not uncommon for

the airline to have a flight plan application supplier who

is different from their performance or chart provider.

The result is that the procedures to utilize data can

become more onerous on the crew than the paper

process replaced. In fact, more than one airline has

observed pilots continuing to write and post the data

on a piece of paper.

On average, airline EFB programs incorporate applications which require data

from three suppliers. The number of suppliers is actually growing with new EFB

programs. Although this may be passed through a system integrator, or as a

subcontractor to a primary application supplier, it is common even in these cases

to have a lack of integration in databases for the program. This means that there

are multiple databases holding the same information which do not share the data.

In addition to the increased support issues, there is another problem with the

potential disparity of data due to the update cycles.

Each database is designed to accept data from an outside source, or “pull” data

during a particular interval. Because each database is optimized to support its

own particular application, there is no incentive to create a regular or standard

timing for this process. Particularly in systems which pull data, there is a very

real potential that there may be varying ages of the same data within different


databases of the EFB. Predominantly with data such as weather or airport

conditions, this could lead to different calculations stemming from different data.

Within the EFB, these calculations are not visible to the crew, so they are not

aware of the differences when the outputs are presented to them.

Beyond the safety of the system due to such issues previously mentioned, there

are a number of other operational issues related to multiple databases:

• Increased data center space and power requirements for server hardware

• Increased application programming interfaces (APIs) with data supplier

may cause problems

• Different database schema requires larger support team for the airline

• Increased troubleshooting issues related to conflicting reports from

different applications

• Additional development, cost, and support for the configuration

management system of the EFB

By integrating the applications to a single database, there is less potential for

system cost overruns on the installation, as well as improved efficiency in the use

of data for the system. The add-on impact of an integrated database is likely a

reduced time and effort to certify the initial and updated systems over the life of

the project.

As the integrated database provides substantial benefits, it is clear that the

following are listed by airlines as key to the launch and use of an EFB system:

• Single database provides easier (and less expensive) path for

enhancement and additional applications

• Reduced technical support requirements

• Opportunity to become more competitive on subsequent request for

proposals (RFP) related to new or renewed applications


IMDC has identified that a small number of airlines have identified this component

as essential to their future EFB projects, but that a number of airlines are still not

viewing an integrated database as essential to their project. However, when

pressed by IMDC on the roadmap for integrating future applications into the EFB,

the database integration becomes far more important for these airlines.

From the supplier side of the market the value

of an integrated database appears muddy. In

many ways, having a proprietary database is a

form of rebid “protection” which makes the

replacement far more difficult (and costly) if

they are removed. On the other side, suppliers

understand that a standard, integrated

database can serve their interests as well as

they can build their applications to particular specifications, and direct their

development resources to other areas. In particular, new entrants are becoming

more enamoured with the concept. System integrators are also strong proponents

of such integration, as it falls to their effort to connect the applications if this does

not already exist.

Aircraft manufacturer programs are also disparate in their implementation of

databases. In fact, there are cases in new aircraft programs, where the airframer

has multiple databases to support only their own systems. The integration done

to combine such databases is not available to third parties, meaning that any

airline launching a new non-OEM application on the EFB will be faced with either

a lack of integration, or unknown costs to integrate. Airlines with deliveries of

these new aircraft are currently unclear as to the impact this will have on

recognizing the full benefits of the program.

Ultimately, the integration between applications and a single database has

stimulated growing momentum, and in time will become the standard approach. ,.

In the interim, airlines are the driving factor in this shift as suppliers are not


interested in pushing this aspect ahead. It is unclear the impact of being a “first

mover” on the airline side in this regard.


2.2. User “Portal”

The concept of a user “portal” is one of the most advanced areas of IT.

Particularly in client/server applications where there is a strong need for

configuration management of multiple, and often varied, clients. EFB is a very

typical example of this type of technical architecture, where there is a benefit to

developing a portal in which the end user is able to self-administer the system.

Reflecting the strength of the case for the portal, virtually every EFB application

developer, hardware provider, or system integrator has developed a portal for their

component(s) of the EFB system. Unfortunately, due to the lack of an industry

standard, suppliers have developed proprietary approaches to a portal for their

own products, and are not integrated between applications today.

IMDC defines the portal as a web-based user

interface which provides the system administrator

and other personnel at the airline to self-manage the

EFB system. The portal is often called a

“dashboard” by many suppliers. The majority of

airlines who have an EFB system in operation are

faced with using multiple portals to support their

operations today. This is identified as a clear issue

with a lot of frustration by several large airlines.

Integration of applications into a single portal is far more complex, however, than

integrating a single database. A number of issues can be roadblocks to such

integration:

• Not all applications are relevant to the same staff administration Delete

period (E.g. maintenance data is not of concern to doc publishing)

• Simply “viewing” the information is not enough, and having control over

the applications from the portal is an intellectual property issue


• Applications may be developed in different languages, using different

protocols

• Applications are designed to present data differently to the user;

Integration forces a more harmonized approach to this aspect

(delete the period at end and add semi colon in the middle of sentences

Although airlines indicate they believe the above list is not insurmountable, there

is a daunting effort required to push suppliers to work together in this manner.

Airframers have been aggressive in their promotion of a corporate dashboard, or

management console, for their systems which are being marketed to support third

party applications. Movement in the market, including published presentations

and reports, indicates a desire or incentive for the market to move towards a

single user interface for the program.

The single largest issue for integrated user dashboards is the ownership of the

application. In the market, most suppliers view their system as the one which

should control the user experience. This is as much about branding and corporate

image as functionality. The result is a vague consensus in the market about

integrating user dashboards, but a lack of movement towards any standards.

System integrators are perhaps in better position to provide such capability (as

being removed from the software process). However, resolution is not anticipated

in the near future.

Until the industry resolves to a single interface, airlines expect to have to “login” to

multiple portals to manage their EFB programs. This is, to most airlines,

manageable with the current application load, but will become unwieldy with any

significant increase in EFB content. Airlines are not indicating any specifications

in their system designs which drive suppliers to this singular approach either. It is

expected that economics of system management will ultimately drive this aspect

forward.


2.3. Software Loading

Software loading is an EFB topic that already takes a disproportionate amount of

attention from an airline when determining their system design. As the delivery of

new software to the aircraft can be the single biggest issue, airlines necessarily

focus on this issue when working towards systems. The IMDC EFB Survey 2010

indicated that software delivery is the largest issue for airlines who do not have an

EFB program, but are considering one.

The issues with software loading are complex, but do improve if there is a

consolidated, integrated system providing the capability. Issues with software

loading include:

• Additional burden on the airport line maintenance staff to conduct the

software loading if no wireless service is available

• In-person software loading is only about 80% effective, and there are

compliance concerns when involving time-sensitive material in the

software load4

• Limited availability of the EFB to a system for software loading and lack of

Wi-Fi or other network coverage

• Appropriate authentication and network prioritization standards are

implemented

Out of necessity, suppliers have independently developed software loading

capabilities which are proprietary to their applications. This has created a

number of options, many of which are very difficult to extend to third party

requirements. In many cases, the software is designed for a single network

system (such as Wi-Fi) which limits the usability for other applications.

The primary integration point for software loading is between the communications

platform and the EFB system manager. For most current systems, this 4 Research in the Flight Operations Quality Assurance (FOQA) market indicates that there is approximately 20% data lost during the software (down)loading process. This is due to various factors including media damage, lost devices, and incorrect procedures.


integration is assumed to be a basic TCP/IP transaction, with little additional

need to concern the software with managing additional capabilities. However,

with most EFB programs, there is a desire to utilize multiple communication paths

with the EFB. This may include Wi-Fi, cellular, Satellite, or Wi-MAX. Each of

these systems incorporates aspects which affect the software loading abilities of

the software on the EFB.

The other major aspect of software loading involves the need to load the software

on the EFB in two phases. The first phase is the delivery of the software to the

EFB hardware. The second phase is the transition of this software onto the

active system, replacing or adding to the current software load. As a system

which requires operational approval from the regulator, there is no option to load

software in a single phase. This introduces unique issues for integrating software

loading:

• Prioritizing which software to load first is an issue that is not addressed in

proprietary systems

• Most software companies have developed their own means to complete

the second phase, which are disparate in their operation

• Validation of the software load is usually required to pass back to the

original application host on the ground

• The applications must be in a consistent language, or use metadata to

“wrap”

System integrators and airframers have both spent considerable effort on

software loading. Both market “open” systems which are able to support

integrated software. The issue, however, is the lack of interest in spending time,

effort, and resources on the work when airlines have yet to demand this. Until

airlines have sufficiently moved forward with wireless networking, there is little

reason to expect pressure on the suppliers to act on integrated software loading.

This adds both cost and uncertainty to the airline program, but not so much as to

cause inactivity.


The industry is moving forward with the definition of standardized software

loading through ARINC 840. Both the AGIE and MAGIC groups are working to

define a standard which applies to the industry. Boeing and Airbus both play

prominent roles on these committees with an eye on how to integrate such

standardization into their programs. However, both have developed proprietary

systems which are being promoted to airlines as the best options today.

Overall, there is historical precedent for integrated software loading, and it

appears to be more of a commercial than technical hurdle to overcome prior to

the market resolving this issue. Airlines are not pushing the situation as the

availability of wireless systems remains a difficulty in their programs. Eventually,

the confluence of wireless availability and the increased number of applications

will drive airlines to press this matter.


2.4. Common Security

In recent studies, security is virtually an afterthought with many airlines in

developing their EFB programs. Security for an EFB program focuses on three

key aspects: the database, communications, and user identification/access

control. Most applications have enacted one or more of these security functions in

their software, but are not taking a standardized or uniform approach with other

industry suppliers. In fact, many are marketing their security as “better” than

others due to their lack of standardization.

As applications developers are forced to develop their own solutions for security,

airlines are growingly faced with incompatible applications on the EFB. For

example, there are programs which require separate authentication for logging

into the EFBand logging into the performance application. Airlines have also

indicated that some proposals have indicated this would potentially be the case to

access messaging traffic or use an electronic logbook. The increased burden on

the flight crew due to this requirement disrupts the value of the EFB and can

potentially cause user rejection of the system. This access control integration can

be done with minimal disruption to the market, but requires an investment in the

airline community to encourage such effort.

Communication security integration is closely linked to the integration of the

configuration management and software loading of the system. By having a

single application responsible for the communications to and from the EFB, it is

naturally set with a single security operation. Without this being the case, there is

no aviation standard which can be cited for the airline, and the applications are

disparate in their implementation.

Database security is the most difficult to address. Security for the database

applies not only to the database itself, but also to the input of data into the

database (both from the EFB client and the external applications). Because many

software suppliers are naturally cautious about any online access into their

software, there are natural barriers to cooperation in this regard.


Airlines do have some areas where there is a definite push for standardization..

The following are industry concepts which airlines have indicated have been, and

continue to be, moving forward:

• Single Sign-on which integrates all user authentication into a single entry

• Public-key Infrastructure (PKI) implementation for wireless security and

software loading;Most common implementation is secure socket layer

(SSL)

• Use of standard firewalls and other entry-point security systems

A conglomeration of security due to the complex collection of applications on the

EFB will only add to airline management and support costs. This develops into a

natural push by the airlines to move towards a standard. This pressure is

expected to build as the number of applications from different suppliers grows

over time.


3. Quantifying Back Office Integration

As with many components of an airline EFB program, integrating the back office

must be exposed to business case criteria which identifies the benefits and cost

savings such action would provide. Without a positive business case, integration

would not withstand the internal airline scrutiny and chances would be minimal for

actual implementation.

Another commonality with many EFB applications is the prominence of “soft” benefits

in the integration case. Soft is typically used to describe those benefits which do not

translate easily to a direct cost savings, but rather have an impact on another

function which in turn will recognize the benefit. Soft benefits are very difficult to

justify within an airline and have traditionally been discounted with most EFB

programs to date.5

The main impact (and the approval for the business case) of back office integration

becomes evident once the airline has achieved a certain critical mass of applications

on the EFB. If these applications operate independently, there is a point at which the

maintenance and support of the different applications will cause the airline to

determine that it is cost-justifiable to promote an integrated back office.

Although IMDC has made efforts to collect a quantified case from airlines for back

office integration, there are some difficulties which make an industry figure difficult:

• Each airline uses a different model for quantifying soft costs. This creates

issues when developing an industry perspective

• In most airlines interviewed, the lack of focus on integration means that there

are no internal calculations on the cost or benefit; In other words, the airline

has not considered integration at a level where quantifiable benefits are

explored

5 The IMDC EFB Survey identified that airlines are failing the business case for EFB in large part due to the lack of direct, quantifiable benefits from the program. Management has not given sufficient weight to the soft benefits to overcome the lack of hard benefits, hence a delay in program launches.


• Most airlines are cautious about releasing specific business case data as

confidential in nature

• Due to varying priorities, the subject of “back office integration” can vary,

thereby skewing the financial data

It is clear through interviews that airlines agree there are cost savings and benefits to

integrating the back office. However, it is more important to note that airlines are

consistent in believing that such integration is essential for EFB to make the “step

change” to a more complex, comprehensive solution. As noted by several airlines,

the back office integration is necessary to achieve the ease of operation necessary to

meet the business case for other components of EFB.

Direct cost savings are achievable through back office integration, but are usually not

noted by the airline:

• Reduced data center costs due to reduced hardware installed

• Reduced application costs as suppliers share development in key areas

• Reduced system operating costs as the application overlap allows single

person support from the airline

• Reduced maintenance costs for the system

• Anticipated reduced costs to add applications

Airlines have also listed the following primary soft costs associated with the

integration of the back office:

• Improved data integrity

• Better human factor conditions for the flight crew

• Reduced bandwidth and communication requirements

• Improved timeline for regulatory certifications

The additional airlines deploying EFB technology should increase the ability to collect

and verify the quantifiable benefits of aspects like back office integration. A


necessary period of active pressure on the suppliers is expected to be able to

achieve these benefits in the long run.

The active involvement of the airline is part of the scope of an EFB project which is

rarely addressed during the development phase. Airline projects have rarely

included any market intelligence component, or active research role, which would

ensure that the airline is acting on, and maintaining, sound practices with the

technology selected. Given the immature status of the EFB industry, there are many

areas which are unresolved, including how applications will integrate in the back

office. Even airlines who have launched successful programs have indicated

concern that their existing technology will be overcome or made irrelevant due to a

rapid change in industry dynamics.

After having considered the value of back office integration airlines emphasize that

the value to the overall program can be a substantial impact to the final cost of the

program (including installation and operational costs). Although specific values

cannot be stipulated, it is expected that these airlines can value the benefit of such

integration high enough to place it as their highest operational priority over the next

two years.

Suppliers are, for the most part, not assisting airlines in defining the quantitative

benefits of this capability. Given the soft nature of many benefits, suppliers have

been hesitant to push the issue with airlines. However, many suppliers are

convinced that full benefits are not recognizable until integration occurs. It appears

that suppliers are willing to work with airlines directly on this business case, but will

not volunteer or proactively push for this model without encouragement from the

airlines.


4. Summary

The integration of the back office in an EFB appears to be of interest to most airlines, but

relatively low priority in current projects. This is due in part to the lack of support

resources in the airline during evaluation and installation periods of EFB projects. Most

airlines anticipate that integration will be necessary to fully achieve the benefits they

expect from the EFB program, but cannot focus on it from the beginning of installation.

The vendor community is taking a mixed approach to this issue. Most suppliers are not

pursuing an integration strategy, or else they simply market their ability to integrate

without any action. This includes airframers who have been pursuing a financial

compensation for third party software integration. System integrators are making a

strong push for this aspect of EFB programs, in part due to their involvement in the

integration process. Few software providers have marketed an “open platform” (another

description for integrated back office) as a value to airlines.

As IMDC monitors the EFB marketplace, the back office integration appears to be an

area of significant focus in the near future. The AEEC committees are expected to pay

more attention to related functions as they proceed with developing standards for EFB.

Vendors and airlines will work together as the number of applications increase to

develop efficient means for applications to coexist. Finally, flight crew will be pushing for

integration as their workload increases and functionality suffers during their daily

operations.

Ultimately, airlines that adopt a proactive stance on back office integration are expected

to have an improved EFB cost model and an improved opportunity to expand

functionality. As with all technology, the flexibility of the system to adaptation is crucial

to the extended serviceability for the end user. Back office integration should provide

airlines with a longer EFB service life, lowered operation costs, and improved workflow

for the cabin crew.


Flight Focus – The Company

Flight Focus commenced operations in 2007 and has steadily increased its resource base over the ensuing period to reach a total staffing resource pool of approximately 125. Our staff are engaged in a wide range of activities directly related to the design, development and delivery of the Flighty Focus PLATFORM™, including hardware and software design and development, manufacturing and maintenance, and optional Flight Dispatch services.

Flight Focus is a flight operations solutions and services provider for the global aviation community, headquartered in Singapore as a privately held company. Flight Focus commenced operations in 2007 to design, develop and produce the Flight Focus PLATFORM™ as an end-to-end, customised solution for airline use.

Whilst headquartered in Singapore, Flight Focus has further office locations in Indonesia (Jakarta and Bandung) and in Kuala Lumpur, with satellite offices located in Shanghai and Curacao (Caribbean).

Flight Focus primary business is to provide risk free and customised flight operations solutions that lead to savings and efficiencies almost immediately via enabling streamlined and lean operations.

With our well-defined global delivery model, Flight Focus provides the shortest time-to-market and lowest cost-of-ownership for establishing a complete paper free integrated electronic workflow between the cockpit and the ground.

Flight Focusʼ quality policy adheres to the highest standards of practices and processes described in international quality and safety standards. We deploy customised engagement models for our customers to maximize efficiency of information flow, design, delivery and support.

Flight Focus General Information

Flight Focus Pte Ltd Tel: +65 6419 5299 17 Changi Business Park Central 1 Fax: +65 6783 3718 #06-09 Honeywell Building Singapore 486073 Website: www.flightfocus.net

Documents

The Value of Back Office Integration - Paperless Flight Bagifs.aero/res/EFB BOI Survey by IMDC, Aviation Consulting Group.pdf · Electronic Flight Bag (EFB) technology has been a