ATA Spec

Data Exchange Standard for Flight Operations
ATA e-Business Forum

and S1000D User Forum
June 23-25, 2014

San Antonio, Texas
Agenda
 Using ATA Spec 2300 To Deliver Richer
Documentation to your Operations– James Baron, Air
Canada
 Flight Operations Data Exchange using ATA Spec 2300
– Bill Cunningham, Boeing
 Spec 2300: Common and Unique Design Features –
Gary Mayer, FlatIrons Solutions
 ATA Spec 2300, implementation perspectives. Who,
why, what, how… When? – Bruno Chatel, Chadocs
Questions & Answers
– Time will be provided at the end

of the presentations for Q&A.
Using ATA spec2300 To Deliver Richer
Documentation to your Operations
James Baron
Manager, Document Management & Control
Air Canada – Flight Operations
james.baron@aircanada.ca
What is a Richer Document?
2
How do we get there?
Xtensible
e
Well formed and validated
Focus on information
meaning over presentation
Style/Formatting independent
Markup Leverages Metadata
Aircraft Effectivity association
Content Reuse/Linking
Language Future OEM Exchange

Standard
Spec2300 is built using XML
3
Operational need for Spec2300?
Growing complexity of the source information
– Aircraft Configuration Variances
Regulator imposed requirements that revisions are:
– Timely,
– Accurate and
– Source compliant
Avoid significant increase in staff levels
– Facilitate Review and Identification of Changes
Single standard for data received from OEMs
– No need for having multiple processes for handling or converting multiple different sources of
information
– Single set of tools for capturing and integrating source document changes
Make content meaningful and relevant
Uniquely identify and associate content down to paragraph level
Data in the manuals can be used to populate information in other systems
– E.g. MEL data fed into MRO system
4
Single Format for Data Import
OEM A OEM A OEM B OEM B

Document 1 Document 2 Document 2 Document 1
Single Import
Process
Having a common
process to import all
OEM data reduces IT
Airline
costs and ensures CMS
standard handling of
data across all fleets.
5 Flight Ops - XDoc Project
Revision review and importation
Manufacturer revisions FCOM
must be processed OEM
Revision
intelligently AOM AOM

– Customized information OEM
Content
Custom
Content
needs to be flagged. The Change Decisions
user can then choose to Owner
accept the new content,
keep the old or further
customize Raise
Change
– All original content can be Request
updated with minimal
interaction from the user
Revised
AOM
6
Aircraft Configuration Variations
Documentary Units (DU)
Aircraft type
(eg. A319 or A320 or A321)
DU DU DU DU
DU DU DU DU
Installed
Equipment
DU DU DU DU
DU DU DU DU
SB or MOD status
7
Tech Writer’s Time Breakdown
Page Oriented Formating
Publish (LEP,
TOC, EOR, Revise
etc) Content
Pagination
Format
Content
8
Tech Writer’s Time Breakdown
Content Editing with Publishing Engine
Revise
Content
Gainined Time
Validate
Published
Output
9 Flight Ops - XDoc Project

What does this mean for Flight Operations?
Inter-manual References and Links
Common content can be linked together to avoid the

need to maintain the same information in multiple places
MEL
Preamble
B777 A330 B767 A320 EMJ

AOM AOM AOM AOM AOM
10
What does this mean for Flight Operations?
Single Source For Output
Repurpose data for different publication media
Web
StyleSheet
XML Print
Content StyleSheet
Source
EFB
StyleSheet
11
Context Relevant Navigation
Engine
Thrust
See Also: See Also: See Also: See Also:

Engine Auto- Thrust Reduced
Overtemp Thrust Reversers Thrust
Take-Off
See Also: See Also: See Also: See Also:

AutoPilot Go-Around Limitations Company
Policy on
Auto-
Thrust
12
Questions?
Thank you
13
Flight Operations Data Exchange using ATA Spec
2300
Bill Cunningham
Chairman
ATA Flight Operations Interest Group
william.d.cunningham2@boeing.com
The statements contained herein are based on good faith assumptions and are to be used for general information purposes only. These statements do not constitute an offer, promise, warranty or
guarantee of performance.
Copyright © 2014 Boeing. All rights reserved. 1

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 customize OEM manuals
• Airlines also publish in-house manuals (SOPs, Route Manuals, etc.) 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
Publishing industry solutions providers can convert multiple
OEM FO data into a single structure, but this is costly and often
involves compromise
Mixed fleet  High cost

Version 2014.1 (Released June 2014)
Spec + XML Schemas + Sample Data
All business requirements for flight
operations including: FCOM, MMEL,
DDG, AFM, QRH, FCTM,
FAM/CCOM, WBM
Developed by FOIG
• Airlines participants
• OEM participants
• XML Publishing Industry Vendor
participants and Consultants
• A4A/ATA

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 modules that can be
arranged into 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 logical documents Data Management
Schemas
Technical
Technical Content
Content Schemas
Schemas
Publication
ApplicCross
Dispatch Schemas General Schema RefTable
Module
(Pm)
Dispatch CDL Supplemental
Item Item Front Matter
Content
CondCross
PmStatus
Dispatch System RefTable
Procedure Fault Limitations Schema Approval Schemas
Exchange
Dispatch SubSet ProductCross
Limitation Approval Package
Locator Header RefTable
StatusList
Procedures Schemas DmStatus Container

Normal NonNormal Failure Performances Schema
Procedure Procedure Consequences
Performance
CabinEquip Glossary Qualifier
Malfunction Repository Repository
Systems Schemas Substantiation Schema Link Target Package

Repository Organization
System Substantiation
Annunciation
Description
Additional
Parameters

Flight Operations data will be delivered a set of XML files
• Data Modules
• Technical content
• DM Status
• Publication Modules
• Organization for Publication
• PM Status
• Data management XML documents
• Status Lists
• Cross Reference Tables
• Repositories
External objects, such as graphics and multimedia are delivered as

separate files and referenced in the technical content DMs

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
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
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
External applications
• Opportunity to reference external applications (such as Performance applications) from
the content
Software Parameter
• Used to identify content in a DM that can be mined for input into an application

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 Organization file describes the
physical organization of the exchange package
The Exchange Package Status List provides
• the package content, with
related status
• the list of deleted
resources
Delivery can be Complete, Revised Only
or Partial*
*All XML content and only
changed external objects

Highlights for Revision 2014.1
• Added data definitions for
• FCTM
• CCOM
• WBM
• Added Software Parameters mark-up
• New Sample Data sets for Dispatch Data and QRH

Two complete Exchange Packages are included with Revision 2014.1
• Dispatch Data (DDG)
• Quick Reference Handbook (QRH)
Each Exchange Package includes an Exchange Package Organization

file, Exchange Package Status List, Cross Reference Tables,
Repositories, Publication Modules & Status fragments, Content Data
Modules and Status fragments, and External Objects & Images

Exchange Pack Exchange Pack Exchange Pack
OEM B
OEM A
A/C Program X A/C Program Y A/C Program Z
Common Exchange Interface

ATA 2300
Revision
impacts Mixed fleet but…
Customization + Single data format
environment + Single environment
Data model
Airline
Configuration
management
Publication
tools
On ground
Consultation tool
EFB
EFB
EFB
The purpose of the ATA-FOIG is to provide a forum for
exchanging ideas, discussing challenges, recommending
enhancements and developing aviation industry consensus for
electronic flight operational data exchange specifications.
The group holds from two to four face-to-face meetings per year
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!

ATA e-Business Forum and
S1000D User Forum
Spec 2300: June 2014 San Antonio, Texas, USA
Common and Unique

Design Features
Gary Mayer
Flatirons Solutions, Inc.
TS/X S1000D
Chief Architect
Gary.Mayer@FlatIronsSolutions.com
©2014 Flatirons Solutions, Inc. All rights reserved.

Agenda
Spec 2300 resources
Module structure: combined vs. separate metadata and content
Applicability: understanding and using this very general model

Spec 2300 resources

Spec 2300 resources
Documents assembled from three kinds of objects:

Publication Modules: PM
•for organizational/structural parts
•chapter, section, subject levels
•titles, but no other content
Data Modules: DM
•for actual content
•procedures, checklists, limitations, etc.
•text, tables, graphics
Media Resources: ICN
•Pictures, illustrations and charts
•Multimedia – 3D models/animations, video
Publication Modules
Publication Modules [PM] PM

• TOC defining
hierarchal organization
for data modules
• Very close to S1000D
Publication Modules
• Build a hierarchy like
chapter, section,
subject in iSpec 2200
• Titles and links, but no
other content

Publication Modules
<pmEntry pmEntryType="Document">
<title>Dispatch Deviations Guide (DDG)</title>
<pmEntry pmEntryCode="0" pmEntryType="Section">
<title>Preface</title>
<dmRef>
<dmRefIdent>
<dmCode modelIdentCode="ABBE2300" systemDiffCode="A"
systemCode="00" su
<language countryIsoCode="US" languageIsoCode="en"/>
</dmRefIdent>
. . .
<pmEntry pmEntryCode="2" pmEntryType="Section">
<title>Master Minimum Equipment List</title>
<pmEntry pmEntryCode="0" pmEntryType="Chapter">
<title>Preamble</title>
<dmRef>
<dmRefIdent>
<dmCode modelIdentCode="ABBE2300" systemDiffCode="A"
systemCode="00" s
</dmRefIdent>
</dmRef>
</pmEntry>
<pmEntry pmEntryCode="21" pmEntryType="Chapter">
<title>ATA 21 - Air Conditioning</title>
<dmRef>

DataModules
Data Modules [DM] – the real content with many types:

Approval, Dispatch, Limitations, NonNormalProcedure,
NormalProcedure, Performance, Substantiation, SystemDescription. . .

<dispatchItem numberInstalled="1" optionalConfigurationIndicator="true">
<title>Autopilot system</title>
<placard>

<para>Put an AUTOPILOT SYSTEM INOPERATIVE placard on the FLIGHT CONTROL panel.</para>
</placard>
<dispatchCondition repairInterval="C">
<normalDispatchCondition numberRequired="0">
<remark>
<proviso>
<para>Except where enroute operations or approach procedures required its use,
may be inoperative provided Altitude Alerting System is operative.</para>
<note>
<para>Autopilot is required for <abbreviation glossaryItemId="RVSM"/>
operations.</para>
</note>
</proviso>
</remark>
</normalDispatchCondition></dispatchCondition></dispatchItem>

Module structure
 Combined vs. separate metadata and content

Separate XML metadata and content documents
2300 DM Status
Publication and Data modules are comprised -Name
of two tightly bound XML documents: -Issue
-Approval
•Linked by having the same “name” ...
•Status: metadata for the data module

•Name (PMC or DMC)
•Issue
•Variety of metadata like Approval
(( 2300 DM Content
))
•Content: the actual XML content that -Name
-Issue
you expect ~~~~~~~~~~~~~~~~~~
•Name (PMC or DMC) ~~~~~~~~~~~~~~~~
•Issue
S1000D DM Status
•Content (no rev markup, no -Name
-Issue
applicability, etc.) -Approval
S1000D
Content
~~~~~~~~~~~~~~~

<dmStatus dataProducer="oem" issueType="new"
<dmIdent>
<dmCode modelIdentCode="ABBE2300" systemDiffCode="A" systemCode="22"
subSystemCode="1" subSubSystemCode="2" dispatchItemExtensionCode="010-0000-000"
assyCode="01" disassyCode="01" disassyCodeVariant="A" infoCode="12C" infoCodeVariant="A"
itemLocationCode="A"/>
</dmIdent>
<issueInfo issueDate="2013-12-25T09:30"/>
Applicability of the
<dmContentIssueInfo issueDate="2013-12-25T09:30"/> content module
<approvalInfo approvalRequired="yes"/>
<applicCrossRefTableRef ... Applicabilities
<applic id="app-001"> <assert applicPropertyIdent="lineNbr" for parts of the
<inlineApplicGroup content
<inlineApplic path=“/dmodule/content/dispatchItem/dispatchCondition[2]”
<assert applicPropertyIdent="lineNbr" applicPropertyType="prodattr“
Identifies
<reasonForUpdate id=“A123456”><para>Correct error on the condition changed parts
<contentRevisions> of the content
<change changeType="modify" reasonForUpdateRefIds=“A123456”
path=“/dmodule/content/dispatchItem/dispatchCondition[2]”
</dmStatus>

 Status: Has both status and DM Status

content info Applicable to N345D
Applicable to N345D
 Applicability ...
Revised per SB-1234
 Reason for update
 Content revision markers
 Use xpaths to point into the
relevant parts of the content DM Content
XML module ~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Content: Remains “pure” ~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Has no rev markup, no ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~
applicability, etc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
 Rendering requires both for
filtering, revision markup

 New paradigm
 Unique approach
 Not in iSpec 2200 or S1000D
 Systems development needed to create or import
 Supports changing applicability via status module
without changing/redelivering content module
 Exchange Standard
 Data may be delivered as Spec 2300
 EFB’s may require Spec 2300
 Internally an OEM’s or operator’s system may
manage the data is a different way

Applicability
 Understanding and using this very general model

Applicability
 Applicability table defined via 3 modules
Applicability Cross-reference Table Condition Cross-reference Table
ACT: Static characteristic columns CCT: Dynamic config columns
Product MODEL TAIL LINENO SERNO SB-1234 SB-5678 EO-AN5

Cross- 940-20 N123D 25914 123456 PRE POST INC
reference
Table 940-20 N124D 25741 123457 POST POST INC
940-20 N125D 14891 123458 POST PRE INC
PCT: 940-30 N210D 19471 148966 POST INC
Row for 940-30 N211D 89174 148953 POST NON
each
Product 940-40 N400D 59174 150100 POST INC
instance 940-40 N401D 89471 150101 PRE NON
This portion like iSpec 2200 EFFXREF

Basic Building Blocks
 ACT: Applicability Cross-reference Table
 Defines “columns” for persistent product attributes (e.g. msnbr)
 CCT: Condition Cross-reference Table
 Defines types of conditions
 Configuration: Service bulletin, EO
 Situational: Weather (“in icy conditions”), operating region
 Define instances of those types (e.g. SB12335)
 Configuration conditions also define product “columns”
 PCT: Product Cross-reference Table
 Defines product instances in terms of the above
 Condition state defined here, not in the modules
 Thus can be updated dynamically with condition (e.g. SB) status
 Filtering of Content
 Select a product instance and all “cell” values used to filter
 Query
 Compose arbitrary logic based on product attributes and/or condition
status

Assert Statement
 Purpose is to mark which parts of the document

content are applicable to which product instances
 Simple language for writing Boolean expressions
 Base construct is assert
<assert applicPropertyIdent=“TAIL“
applicPropertyType="prodattr“
applicPropertyValues=“N345D|N366D|N412D"/>
 Evaluates to TRUE or FALSE
 TRUE for aircraft tails N345D, N366D or N412D
 FALSE for all others
 Allows arbitrary text - always considered TRUE
<assert>in icy conditions</assert>

Assert Statement
 Simple iSpec 2200 effect

<effect effrg="004099 214265"/>
 Spec 2300/S1000D equivalent

<applic>
<assert applicPropertyIdent=“cec“
applicPropertyType="prodattr“
applicPropertyValues="004~099|214~265"/>
</applic>
 The effrg directly corresponds to the values for the

assert
 May display as:
Applicable to: 004-099 or 214-265

Evaluate Statement
 Use Boolean evaluate statements to build more complex
statements:
<applic>
<evaluate andOr="and">
<assert applicPropertyIdent="tailNumber"
applicPropertyType="prodattr"
applicPropertyValues=“N345D|N366D|N412D"/>
<assert applicPropertyIdent=“SB12345"
applicPropertyType=“condition"
applicPropertyValues=“POST"/>
</evaluate>
</applic
 Evaluates to TRUE or FALSE
 This is TRUE for aircraft tails N345D, N366D or N412D
and when SB12345 is POST for the aircraft
 PCT may indicate if an aircraft is PRE or POST and filter
the content – e.g. filter if it is PRE in this case

Applicability Statements Marking Content
 Each applic starts with one evaluate or assert

statement
 Each evaluate:
 Has two or more assert and/or evaluate statements
 Can nest to nay depth
 Can construct quite complex logical expressions
 Precisely define relationships between multiple SBs
 Any assert that does not explicitly evaluate to FALSE is
considered TRUE
 i.e. Hide content only when positively determined

Applicability: Conclusion
 Flexible, Highly Configurable Capability

 Nearly identical to S1000D applicability scheme
 You define all the table columns and what they
mean
 Applic statements written and evaluated using
completely standard methods
 Thus behavior is always the same in all systems

Conclusion

Spec 2300 Design: Conclusion
 Modular structure similar to S1000D and some

OEM flight ops formats
 Very detailed flight ops semantics
 Some new, novel concepts like separate status
and content modules
 Some familiar S1000D concepts like
applicability
 Requires unique system support

Questions

ATA Spec 2300,
implementation perspectives.
Who, why, what, how… When?
San Antonio, June 24th 2014

Bruno Chatel
bcha@chadocs.com
1 June 24 2014
ATA Spec 2300… Ready ?
 Yes
 Cover all the business domains for Flight

Operations
 XML Schema consolidation
 XML samples
 And now?
It is time for implementation…
Who ? Why ? What ? How ?
2 Bruno Chatel (bcha@chadocs.com) June 24 2014
Flight Ops data.. Global process
Operator
OEM Airline
Ops manuals
Fleet, S/N Customization
(CMS)
validation
authoring publishing
approval - revision impact
- authoring
Flight Manual, - approval
MMEL/DDG, - publishing
FCOM/AOM, QRH
Envelop Customized manuals Customized manuals
MEL, other AOM/FCOM, MEL,
Approved manual QRH,
Flight Manual, Fleet, S/N Operator manual
MMEL Flight Manual
Envelop Fleet, S/N
approval approval On ground

consultation tool OnOn
board/EFB
board/EFB
Authorities Local (Ops manager, e-Viewer
e-Viewer
Flight crew (maybe OEM
(EASA, FAA, ..) authority training…) dependant)

OEMs implementation perspectives
 Different cases
1) New authoring/publishing environment for a new
program
2) New authoring/publishing environment on existing
program
3) Existing authoring/publishing environment
 Why implementing ATA 2300?

 What can be done and how ?

New authoring/publishing environment
for a new program
 New program development
– Triggers new Flight Ops documentation
– Opportunity to develop a new authoring/publishing
environment
– Choice of a data model
 To support business requirements
 To deliver digital data
– Allowing development of digital delivery and e-Viewer
OEM
validation
approval

Airbus Helicopters case study
 Choice of a data model standard for the system
– Detailed study to choose data model
– Assessment of different data models
 General requirements
 Project business requirements
Modular
XML SGML/Manual
S1000d ATA 2300
(Proprietary data model (Proprietary data model)
for Flight Ops)
General features Types of Content 70 120 110 85

Content Models 60 120 110 95
Data Management 104,5 129 94,5 42
Authoring 58,5 57 67 42
Approval 10 25 25 15
Publishing Common 60 70 65 65
Publishing Paper 0 0 0 0
Publishing electronic 30 88 83 10
Project Business Req Reqs_Planning,Research&Analysis 20 8 16 0

Reqs._Authoring 225 270 250 115
Reqs._Validation&Approval 0 25 25 10
Reqs._Publishing 161 216 188 138
Reqs._Data Management 0 0 0 0
Reqs._Applicability Matrix 30 30 20 5
TOTAL 759 1038 943,5 537

 Following steps: identification of discrepancies/issues, POC data,
guidance rules
New authoring/publishing environment
for an existing program
 Same expected value added !
 But.. need to manage legacy….

– Re-author….
 It is not only a technical issue….
 It may impact changes in the content
– Take advantage of advanced features
– Digital data oriented/data centric approach
 It
impacts the published manuals
 Full Re-Approval of manuals ?

Keep an existing authoring/publishing
system
 And make a final conversion
OEM
validation
approval
XML/SGML
Transformation
proprietary data
 It works ! model to ATA 2300
– From SGML monolithic proprietary DTDs
– From XML modular proprietary data model
 Minor issues
– To solve with authoring/publishing system enhancements
– Change requests
Convert to ATA 2300
 Conversions rules
– (if applicable) Break monolithic manual/breakdown in PM and DM
– Generate Cross Ref Tables DM for applicability declaration
– (if applicable) Manage repositories DM (glossary, avionic/dispatch qualifiers, link
target)
– Manage revision marks and applicability statements (DM and -if applicable-
inline applic)
– Technical content transformation (translate proprietary structure to ATA 2300
DM content)
– Generate Data Management features (Exchange Package Status List, Package
Organization, Sub Set if any, TR/TDM, Delivery Scope / revised only / partial)
 Issues
– Applicability in the PM to propagate at DM level
– Identification: PMC/DMC creation (SNS, InfoCode)
– Persistent IDs
– Applic revision marks
– Some applicability computation / declarations
– Some issues in matching technical content model : this could come from very
different avionics/cockpit design (example: alerting system)

And airlines/operators ?
 Today only proprietary digital format

– Dependant of OEM digital deliveries (when there is)
– Or pdf/paper On board/EFB
e-Viewer
Customization (maybe OEM
(CMS) dependant)
OEM A - revision impact On ground

XML/SGML
- authoring consultation tool
-approval (Ops manager,
- publishing Flight crew
training…)
On board/EFB
e-Viewer
Customization (maybe OEM
(CMS) dependant)
OEM B - revision impact On ground

XML/SGML
- authoring consultation tool
-approval (Ops manager,
- publishing Flight crew
training…)

ATA 2300 ? Why ?
 Developing a new CMS

– And take advantage of OEM delivery (if any)
On board/EFB
OEM A e-Viewer
XML/SGML Customization (maybe OEM
On board/EFB
(CMS) dependant)
e-Viewer
(maybe OEM
dependant)
- revision impact
- authoring
OEM B -approval
XML/SGML - publishing On ground
consultation tool
(Ops manager,
 ATA 2300 Flight crew
training…)
– XML + Provide all the features
 Business requirements : specific for Flight Ops with 4 major OEM requirements
 Fully adapted for eViewer applications
– Neutral and standard
 Don’t be totally dependent on a specific proprietary format (linked to a solution provider)
 Can uncorrelate CMS, e-Viewer, … with different software providers
 Insure common data found, share a view for a mixed fleet (consistency)
 Allow also to manage “operator manual”

How to go….
 First case: Wait for ATA 2300 OEM deliveries !
Customization
OEM A (CMS)
XML
- revision impact
- authoring
-approval
OEM B - publishing
XML

How to go….
 But it is also possible to start without OEM

delivery
– Making conversions from OEM proprietary
publishing/exchange digital inputs
 What is feasible as a conversion on the OEM side is feasible
on the airline side !
– Author what is not delivered
OEM A
Transformation
XML
proprietary data
model to ATA 2300 Customization
(CMS)
- revision impact
- authoring
OEM B Transformation -approval
XML proprietary data - publishing
model to ATA 2300

CMS to Viewer
 Use ATA 2300 as the exchange data model between
CMS/Customization and e-Viewer
– Opportunity to different software providers On board/EFB
e-Viewer
– Share common technologies Customization (CMS)
(maybe OEM
dependant)
for the whole fleet

– Also allow to support On ground
consultation tool
“operator manuals” (not related to (Ops manager,
Flight crew
any specific OEM/Program) training…)
– Take advantage of ATA 2300 enhanced features for dynamic

eViewer (applicability/filtering, interactive/cascade graphics,
tickable procedures, layers, external applications)…. And work
in progress for integration eLogBook
? Proprietary data format for OEM EFBs viewers ?

• Convert from ATA 2300 ? (to be studied)

Implementation of ATA 2300 (CMS,
eViewer, …):Technical aspects
 Many compliance with S1000d …but is not
S1000d
– S1000D v4.1
– Data management communalities
 Modularity (with separated Status/Content fragments)
 (Partially) Identification
 Applicability management
– Consider using common technical framework !
 Very specific (and business oriented) content

models
– Impacts mostly stylesheet

The remaining question is….
WHEN?
Thanks !
Bruno Chatel
Chadocs
bcha@chadocs.com
http://www.chadocs.com
+33 4 96 11 14 57

ATA Spec

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ATA Spec

Hochgeladen von

Copyright:

Verfügbare Formate

Data Exchange Standard for Flight Operations

ATA e-Business Forum

June 23-25, 2014

– Time will be provided at the end

Language Future OEM Exchange

OEM A OEM A OEM B OEM B

intelligently AOM AOM

9 Flight Ops - XDoc Project

Common content can be linked together to avoid the

B777 A330 B767 A320 EMJ

Single Source For Output

Repurpose data for different publication media

See Also: See Also: See Also: See Also:

See Also: See Also: See Also: See Also:

Copyright © 2014 Boeing. All rights reserved. 1

Copyright © 2014 Boeing. All rights reserved. 2

Configuration management and other transversal requirements:

Copyright © 2014 Boeing. All rights reserved. 3

Copyright © 2014 Boeing. All rights reserved. 4

Copyright © 2014 Boeing. All rights reserved. 5

Procedures Schemas DmStatus Container

Systems Schemas Substantiation Schema Link Target Package

Copyright © 2014 Boeing. All rights reserved. 6

External objects, such as graphics and multimedia are delivered as

Copyright © 2014 Boeing. All rights reserved. 7

Revision data is delivered in the DM Status XML Fragment

Copyright © 2014 Boeing. All rights reserved. 8

Copyright © 2014 Boeing. All rights reserved. 9

Copyright © 2014 Boeing. All rights reserved. 11

Copyright © 2014 Boeing. All rights reserved. 12

Copyright © 2014 Boeing. All rights reserved. 13

Each Exchange Package includes an Exchange Package Organization

Copyright © 2014 Boeing. All rights reserved. 14

A/C Program X A/C Program Y A/C Program Z

Common Exchange Interface

New participants are needed and always welcome!

Copyright © 2014 Boeing. All rights reserved. 16

Common and Unique

©2014 Flatirons Solutions, Inc. All rights reserved.

Spec 2300 resources

Module structure: combined vs. separate metadata and content

Applicability: understanding and using this very general model

©2014 Flatirons Solutions, Inc. All rights reserved.

©2014 Flatirons Solutions, Inc. All rights reserved.

Documents assembled from three kinds of objects:

Publication Modules [PM] PM

©2014 Flatirons Solutions, Inc. All rights reserved.

©2014 Flatirons Solutions, Inc. All rights reserved.

Data Modules [DM] – the real content with many types:

©2014 Flatirons Solutions, Inc. All rights reserved.

 Combined vs. separate metadata and content

©2014 Flatirons Solutions, Inc. All rights reserved.

•Status: metadata for the data module

©2014 Flatirons Solutions, Inc. All rights reserved.

©2014 Flatirons Solutions, Inc. All rights reserved.

 Status: Has both status and DM Status

XML module ~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Has no rev markup, no ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

©2014 Flatirons Solutions, Inc. All rights reserved.

©2014 Flatirons Solutions, Inc. All rights reserved.

 Understanding and using this very general model

©2014 Flatirons Solutions, Inc. All rights reserved.

Product MODEL TAIL LINENO SERNO SB-1234 SB-5678 EO-AN5