The Value of Back
Office Integration
Electronic Flight Bag (EFB) White Paper
Andrew Kemmetmueller
Managing Consultant
IMDC EFB White Paper
1
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
IMDC EFB White Paper
2
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 IMDC EFB White Paper
3
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.
IMDC EFB White Paper
4
Communica)on Management Administra)ve Interface Security/
Encryp)on Version Management Database 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
IMDC EFB White Paper
5
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.
IMDC EFB White Paper
6
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
IMDC EFB White Paper
7
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.
IMDC EFB White Paper
8
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
2
following capabilities to support a certified EFB system :
+
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.
IMDC EFB White Paper
9
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.
IMDC EFB White Paper
10
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 nontraditional 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.
IMDC EFB White Paper
These
11
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
IMDC EFB White Paper
12
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.
IMDC EFB White Paper
13
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.
IMDC EFB White Paper
14
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)
IMDC EFB White Paper
15
+
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.
IMDC EFB White Paper
16
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.
IMDC EFB White Paper
17
IMDC EFB White Paper
18
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
IMDC EFB White Paper
19
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 EFB White Paper
20
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
IMDC EFB White Paper
21
interested in pushing this aspect ahead. It is unclear the impact of being a “first
mover” on the airline side in this regard.
IMDC EFB White Paper
22
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
“dashboard” by many suppliers.
often
called
a
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
IMDC EFB White Paper
23
•
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.
IMDC EFB White Paper
24
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.
IMDC EFB White Paper
25
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.
IMDC EFB White Paper
26
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.
IMDC EFB White Paper
27
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.
IMDC EFB White Paper
28
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.
IMDC EFB White Paper
29
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.
IMDC EFB White Paper
30
•
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.
IMDC EFB White Paper
31
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.
IMDC EFB White Paper
32
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.
IMDC EFB White Paper
33
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
17 Changi Business Park Central 1
#06-09 Honeywell Building
Singapore 486073
IMDC EFB White Paper
Tel: +65 6419 5299
Fax: +65 6783 3718
Website: www.flightfocus.net
34