Bill Cunningham, Boeing Bruno Chatel, Chadocs 2012 ATA eBusiness Forum, October 22-24, 2012, Applicable Standard: ATA Spec 2300 Topic: Flight Operations Digital Data Abstract: This will be a joint presentation given by Bruno Chatel of Chadocs and Bill Cunningham of the Boeing Company. The presentation provides an update on the current status of ATA Specification 2300, as of Release 2011.2 and the schema consolidation effort that the FOIG is undertaking for CY 2012. It includes background on why the FOIG is creating a unique specification for flight operations data. It also provides information on some features of data management using XML concepts in the current release. Historically, every airplane maker developed proprietary tools and software to create and deliver flight operations data to their airline customers. They created unique data structures and system architecture to support their data and documents. Airlines need to purchase and maintain multiple customization and publishing systems and environments for their fleets. Airlines have asked for a common data standard for flight operations documents. This standard would allow them to set up a single interchange system for flight operations, regardless of airplane model or manufacturer. The ATA Flight Operations Interest Group (FOIG) works to develop data structures and standards that support data interchange for flight operations documents. The results of their efforts are published as ATA Specification 2300. The purpose of Spec 2300 is to provide a concise set of information standards and guidelines for the management, configuration and interchange of flight operations technical data. Based on XML standards, Spec 2300 uses advanced modular organization of data, giving opportunity for a progressive data exchange protocol. It uses a data-centric approach, focusing on defining individual data objects, known as data modules that represent a unique piece of technical content. Each data module has it own life cycle, revision and configuration management. In addition to the technical mark-up of individual data modules, Spec 2300 contains detailed sections on data management, applicability management, meta-data, revision management and publication management. When implemented Spec 2300 will provide interchange mechanisms that are non-proprietary, software / hardware independent, integrity checked, secure and self-verified.

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

2.  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

3.  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

4.  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.

5.  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

6.  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

7.  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

8.  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)

9.  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

10.  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.

11.  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

12.  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

13.  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

14. 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

15.  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

16.  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!

17.  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

18. Questions?
Thank you for attending our
session!