ATA e-Business Forum
Bill Cunningham
Boeing
Flight Operations Digital
Data Lead
william.d.cunningham2@boeing.com
Bruno Chatel
Chadocs
Consultant
bcha@chadocs.com

 Each OEM delivers Flight Operations data
using proprietary formats
◦ May differ from one airplane program to another
program for an OEM
◦ Mix of structured and unstructured formats
 XML, SGML
 Published data (e.g. PDF)
◦ Proprietary data models…
 …and tools
◦ No shared basic concepts

 Need specific/separate systems to manage Flight
Operations data for each OEM/program
 OEM manuals
◦ Airlines often need to customized OEM manuals
◦ Airline also publish in-house manuals (SOPs) that often
cross or combine fleets from multiple OEMs
 Airline manuals may require specific airline proprietary
formats/tools
 Configuration management and other transversal
requirements : no opportunity to use same level or
technology
 Industry publishing solutions providers can convert
multiple OEM FO data into a single structure, but this
is costly and often involves compromise
 Mixed fleet  High cost

 Receive data from OEM
◦ Fleet manual
 Calculation of revision impacts
 Add Airline customized data
 Publication
◦ Fleet manual
◦ A/C manual (single-tail)
 Deliver to crews
◦ Onboard : EFB, Paper
◦ On-Ground: Paper, Computers, Tablets, Intranet
 Training
 A standard exchange model for Flight Operations
data will allow airlines complete all these tasks
with a single system.

 What is it ?
◦ Common vocabulary
◦ Common data model
◦ Common data types and data organization framework
◦ Common exchange package technology (based on XML)
◦ Each data provider uses the same language to deliver FO
data
 What it is not !
◦ No standardized manual organization
◦ No standardized authoring philosophy, constraints
◦ No standardized content !
◦ No standardized publication process
◦ No standardized style sheets

 What do we deliver: Flight
Operations data types,
manuals
◦ Data-centric approach
 Data modules are marked-up
based on the content, not the
organization of the manual
◦ Additional data definitions are
provided to organize and publish
DM into logic documents

 Flight Operations data will be delivered as a set of
XML files
◦ Data Modules
 Technical content
 DM Status
◦ Publication Modules
 Organization for Publication
 PM Status
◦ Data management XML documents
 External objects, such as graphics and multimedia are
delivered as separate files and referenced in the
technical content DMs

 Separate XML fragments
 Status => metadata
related to content
◦ Applicability
◦ Revision data
◦ Metadata (approval/subset
info, tdm, qualifications,
policy references, data owner…)
 Different lifecycles
 Opportunity to exchange only
status or content separately
(incremental delivery)

 Provisions for complete or incremental
exchange
 Revision data
◦ Status Information
 New, Changed, Applicability change, Unchanged
◦ Reason for update
 Technical or Editorial
 Deleted, Moved, Textual content
◦ Revision marks
 Add, Modify, Move, Move and Modify
 Revision data is delivered in the DM Status
XML Fragment

 ACT, PCT, CCT : cross reference tables
◦ Based on S1000D
◦ Defines the products (aircraft table) and the conditions (list of Airplane
Modifications/Service Bulletins)
 Applicability statements
◦ Statement that gives the applicability for 1 DM or a specific element
 Which products (aircraft), with conditions or not ?
 If needed, associated with a formula of technical
criteria
◦ In the DM status
 Can define inline applicability (using XPATH to
address the element in content)
 Container/alternates
◦ Different DMs of the same subject for
different configurations (applicability)
are called alternates
◦ Alternates are grouped in “interface”
DM called container.

 General purpose
◦ Repositories allowing data factorization, provided as data
modules
 Repository types
◦ Glossary
 Set of definitions for abbreviations referenced in content
◦ Qualifier (dispatch, avionic contexts)
 Business qualification of content such as
 Impacts on performance of a dispatch condition
 Limitations on landing capabilities due to a dispatch condition
 Code of data received from avionics systems allowing to index an
alert for a procedure
◦ Link target summary
 Set of resolved links targets information
 Allows resolution of links to data outside of an exchange
package

 Are found in the spec :
◦ Information Layers
 Three layers are available – Need to Know, Nice to Know, Expert
Knowledge
◦ TDM
 Temporary data module
◦ Major event
 High priority for a set of data
◦ External applications
 Opportunity to reference external applications (such as
Performance applications) from the content
◦ Subset
 Identification of a set of data modules, part of a bulletin (OEB,
OMB)
◦ Metadata related to a DM
 Phase of flight, crew qualification, policy references, data owner

 An exchange package is composed of a set of objects
◦ DM (content and status), PM (content and status), External
objects (graphics & multimedia)
 The Exchange Package
Status List provides
◦ the package content,
with related status
◦ the list of deleted
resources
 Delivery can be
Complete or
incremental
◦ Only changed resources
are delivered

Common Exchange Interface
ATA 2300
OEM A
Exchange Pack
A/C Program X
Exchange Pack
A/C Program Y
OEM B
Exchange Pack
A/C Program Z
Airline
Revision
impacts
Customization
environment
Data model
Configuration
management
Publication
tools
Mixed fleet but…
+ Single data format
+ Single environment
On ground
Consultation tool
EFB
EFB
EFB

 Version 2011.2
 Spec + XML Schemas
 All business requirements for FCOM, MMEL,
DDG, AFM, QRH
 Developed by FOIG
◦ OEM participants
◦ ATA e-Business Program
◦ Airline participants
◦ XML publishing industry vendor participants and
consultants

 The group holds quarterly face-to-face meetings
 Web and phone conferences are held regularly to
monitor and progress the work between face-to-face
meetings
 Members are assigned action items to work
between meetings
 New participants are needed and always welcome!

 2012/2013 : consolidation, proof of concepts
◦ General analysis of all data types
◦ New requirements
◦ Schema Simplification and Consolidation
◦ Spec rewriting/reorganization
◦ Planning for the Future

Questions?
Thank you for attending our
session!