Data Exchange Standard for Flight Operations - ATA e

Transcription

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
Markup
Language
e
3
Well formed and validated
Focus on information
meaning over presentation
Style/Formatting independent
Leverages Metadata
Aircraft Effectivity association
Content Reuse/Linking
Future OEM Exchange
Standard
Spec2300 is built using XML
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
–
4
E.g. MEL data fed into MRO system
Single Format for Data Import
OEM A
Document 1
OEM A
Document 2
OEM B
Document 2
OEM B
Document 1
Single Import
Process
Having a common
process to import all
OEM data reduces IT
costs and ensures
standard handling of
data across all fleets.
5
Airline
CMS
Flight Ops - XDoc Project
Revision review and importation
Manufacturer revisions
must be processed
intelligently
– Customized information
needs to be flagged. The
user can then choose to
accept the new content,
keep the old or further
customize
– All original content can be
updated with minimal
interaction from the user
FCOM
OEM
Revision
AOM
AOM
OEM
Content
Custom
Content
Change Decisions
Owner
Raise
Change
Request
Revised
AOM
6
Aircraft Configuration Variations
Documentary Units (DU)
Aircraft type
(eg. A319 or A320 or A321)
Installed
Equipment
DU
DU
DU
DU
DU
DU
DU
DU
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,
etc)
Revise
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
AOM
10
A330
AOM
B767
AOM
A320
AOM
EMJ
AOM
What does this mean for Flight Operations?
Single Source For Output
Repurpose data for different publication media
Web
StyleSheet
XML
Content
Source
Print
StyleSheet
EFB
StyleSheet
11
Context Relevant Navigation
Engine
Thrust
See Also:
Engine
Overtemp
See Also:
AutoPilot
12
See Also:
AutoThrust
See Also:
Go-Around
See Also:
Limitations
See Also:
Thrust
Reversers
See Also:
Company
Policy on
AutoThrust
See Also:
Reduced
Thrust
Take-Off
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
2
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
3
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
4
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
5
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
Dispatch Schemas
Dispatch
Item
CDL
Item
Dispatch
Procedure
System
Fault
General Schema
Front Matter
Limitations Schema
Dispatch
Locator
Limitation
Supplemental
Content
NonNormal
Procedure
Failure
Consequences
Approval
SubSet
Header
Performance
Annunciation
System
Description
CondCross
RefTable
PmStatus
ProductCross
RefTable
Exchange
Package
StatusList
DmStatus
Container
Glossary
Repository
Qualifier
Repository
Link Target
Repository
Package
Organization
Performances Schema
CabinEquip
Malfunction
Systems Schemas
Publication
Module
(Pm)
Approval Schemas
Procedures Schemas
Normal
Procedure
ApplicCross
RefTable
Substantiation Schema
Substantiation
Additional
Parameters
6
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
7
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
8
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.
9
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
10
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
11
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
12
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
13
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
14
Exchange Pack
A/C Program Y
OEM B
OEM A
Exchange Pack
A/C Program X
Exchange Pack
A/C Program Z
Common Exchange Interface
ATA 2300
Revision
impacts
Mixed fleet but…
+ Single data format
+ Single environment
Customization
environment
Airline
Data model
Configuration
management
Publication
tools
On ground
Consultation tool
EFB
EFB
EFB
15
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!
16
17
ATA e-Business Forum and
S1000D User Forum
June 2014 San Antonio, Texas, USA
Spec 2300:
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]
• 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
PM
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
Publication and Data modules are comprised
of two tightly bound XML documents:
•Linked by having the same “name”
•Status: metadata for the data module
•Name (PMC or DMC)
•Issue
•Variety of metadata like Approval
•Content: the actual XML content that
you expect
•Name (PMC or DMC)
•Issue
•Content (no rev markup, no
applicability, etc.)
S1000D
2300 DM Status
-Name
-Issue
-Approval
...
((
2300 DM Content
-Name
-Issue
~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~
S1000D DM Status
-Name
-Issue
-Approval
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
content info
 Applicability
 Reason for update
 Content revision markers
 Use xpaths to point into the
relevant parts of the content
XML module
 Content: Remains “pure”
 Has no rev markup, no
applicability, etc.
 Rendering requires both for
filtering, revision markup
DM Status
Applicable to N345D
Applicable to N345D
...
Revised per SB-1234
DM Content
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~
 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
MODEL
TAIL
LINENO
SERNO
SB-1234 SB-5678 EO-AN5
940-20
N123D
25914
123456
PRE
POST
INC
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
each
Product
instance
940-30
N211D
89174
148953
POST
NON
940-40
N400D
59174
150100
POST
INC
940-40
N401D
89471
150101
PRE
NON
Product
Crossreference
Table
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
Airline
OEM
Ops manuals
Fleet, S/N
Customization
(CMS)
authoring
validation
approval
publishing
- revision impact
- authoring
- approval
- publishing
Flight Manual,
MMEL/DDG,
FCOM/AOM, QRH
Envelop
Customized manuals
MEL, other
Approved manual
Fleet, S/N
Flight Manual,
MMEL
Envelop
approval
Authorities
(EASA, FAA, ..)
3
approval
Local
authority
On ground
consultation tool
(Ops manager,
Flight crew
training…)
Customized manuals
AOM/FCOM, MEL,
QRH,
Operator manual
Flight Manual
Fleet, S/N
OnOn
board/EFB
board/EFB
e-Viewer
e-Viewer
(maybe OEM
dependant)
June 24 2014
OEMs implementation perspectives

Different cases
1)
2)
3)


4
New authoring/publishing environment for a new
program
New authoring/publishing environment on existing
program
Existing authoring/publishing environment
Why implementing ATA 2300?
What can be done and how ?
June 24 2014
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
authoring
5
validation
approval
publishing
June 24 2014
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
S1000d
General features
Project Business Req
SGML/Manual
(Proprietary data model)
70
60
104,5
58,5
10
60
0
120
120
129
57
25
70
0
110
110
94,5
67
25
65
0
85
95
42
42
15
65
0
Publishing electronic
30
88
83
10
20
225
0
161
0
8
270
25
216
0
16
250
25
188
0
0
115
10
138
0
30
30
20
5
759
1038
943,5
537
Reqs_Planning,Research&Analysis
Reqs._Authoring
Reqs._Validation&Approval
Reqs._Publishing
Reqs._Data Management
TOTAL
6
ATA 2300
Types of Content
Content Models
Data Management
Authoring
Approval
Publishing Common
Publishing Paper
Reqs._Applicability Matrix

Modular
XML
(Proprietary data model
for Flight Ops)
Following steps: identification of discrepancies/issues, POC data,
guidance rules
June 24 2014
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 ?
7
June 24 2014
Keep an existing authoring/publishing
system

And make a final conversion
OEM
validation
approval
authoring
publishing
XML/SGML

It works !
–
–

From SGML monolithic proprietary DTDs
From XML modular proprietary data model
Minor issues
–
–
8
Transformation
proprietary data
model to ATA 2300
To solve with authoring/publishing system enhancements
Change requests
June 24 2014
Convert to ATA 2300

Conversions rules
–
–
–
–
–
–

Issues
–
–
–
–
–
–
9
(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 applicableinline 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)
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)
June 24 2014
And airlines/operators ?

Today only proprietary digital format
–
–
Dependant of OEM digital deliveries (when there is)
On board/EFB
Or pdf/paper
e-Viewer
Customization
(CMS)
OEM A
XML/SGML
- revision impact
- authoring
-approval
- publishing
Customization
(CMS)
OEM B
XML/SGML
10
- revision impact
- authoring
-approval
- publishing
(maybe OEM
dependant)
On ground
consultation tool
(Ops manager,
Flight crew
training…)
On board/EFB
e-Viewer
(maybe OEM
dependant)
On ground
consultation tool
(Ops manager,
Flight crew
training…)
June 24 2014
ATA 2300 ? Why ?

Developing a new CMS
–
And take advantage of OEM delivery (if any)
OEM A
XML/SGML
Customization
(CMS)
- revision impact
- authoring
-approval
- publishing
OEM B
XML/SGML

ATA 2300
–

e-Viewer
(maybe OEM
dependant)
On ground
consultation tool
(Ops manager,
Flight crew
training…)
Business requirements : specific for Flight Ops with 4 major OEM requirements
Fully adapted for eViewer applications
Neutral and standard




11
(maybe OEM
On board/EFB
dependant)
XML + Provide all the features

–
On board/EFB
e-Viewer
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”
June 24 2014
How to go….

First case: Wait for ATA 2300 OEM deliveries !
Customization
OEM A
XML
OEM B
XML
12
(CMS)
- revision impact
- authoring
-approval
- publishing
June 24 2014
How to go….

But it is also possible to start without OEM
delivery
–
Making conversions from OEM proprietary
publishing/exchange digital inputs

–
OEM A
XML
What is feasible as a conversion on the OEM side is feasible
on the airline side !
Author what is not delivered
Transformation
proprietary data
model to ATA 2300
Customization
(CMS)
OEM B
XML
13
Transformation
proprietary data
model to ATA 2300
- revision impact
- authoring
-approval
- publishing
June 24 2014
CMS to Viewer

Use ATA 2300 as the exchange data model between
CMS/Customization and e-Viewer
–
–
On board/EFB
Opportunity to different software providers
e-Viewer
(maybe OEM
Share common technologies Customization
dependant)
for the whole fleet
On ground
Also allow to support
consultation tool
(Ops manager,
“operator manuals” (not related to
Flight crew
training…)
any specific OEM/Program)
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
(CMS)
–
–
? Proprietary data format for OEM EFBs viewers ?
• Convert from ATA 2300 ? (to be studied)
14
June 24 2014
Implementation of ATA 2300 (CMS,
eViewer, …):Technical aspects

Many compliance with S1000d …but is not
S1000d
–
–
S1000D v4.1
Data management communalities



–

Consider using common technical framework !
Very specific (and business oriented) content
models
–
15
Modularity (with separated Status/Content fragments)
(Partially) Identification
Applicability management
Impacts mostly stylesheet
June 24 2014
The remaining question is….
WHEN?
16
June 24 2014
Thanks !
Bruno Chatel
Chadocs
bcha@chadocs.com
http://www.chadocs.com
+33 4 96 11 14 57
17
June 24 2014

Data Exchange Standard for Flight Operations - ATA e

Transcription

Similar documents

Rail Road FinalApproved NoLogo 13-11

Please use one form per client, send the filled booking form back to

Selling the Right Shock

Parts - Intelligrated

14766 MFGC 2300 2p spec.indd

www.xtgeo.com | info@xtgeo.com FLATIRONS™ Integrated Software

VS7000 PDA

Naso-Pharyngoscopes

OEM Group

425-5632 installation pdf