ATA Spec 2300, implementation perspectives. Who, why, what, how… When? Bruno Chatel

Bruno [email protected]

ATA Spec 2300, implementation perspectives.

Who, why, what, how… When?

San Antonio, June 24th 2014

June 24 20141

mailto:[email protected]

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 June 24 2014Bruno Chatel ([email protected])

Flight Ops data.. Global process

June 24 2014Bruno Chatel ([email protected])3

OEM

authoringvalidation

approvalpublishing

Ops manuals

Fleet, S/N Customization(CMS)

- revision impact

- authoring

- approval

- publishing Flight Manual,

MMEL/DDG,

FCOM/AOM, QRH

Envelop

On board/EFB

e-ViewerLocal

authority

On ground

consultation tool

(Ops manager,

Flight crew

training…)

Authorities

(EASA, FAA, ..)

Flight Manual,

MMEL

Envelop

Operator

Airline

approval approval

Customized manuals

MEL, other

Approved manual

Fleet, S/N

Customized manuals

AOM/FCOM, MEL,

QRH,

Operator manual

Flight Manual

Fleet, S/N

On board/EFB

e-Viewer(maybe OEM

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

authoringvalidation

approvalpublishing

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

Following steps: identification of discrepancies/issues, POC data,

guidance rulesJune 24 2014Bruno Chatel ([email protected])6

S1000d ATA 2300

Modular

XML

(Proprietary data model

for Flight Ops)

SGML/Manual

(Proprietary data model)

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

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

It works !

– From SGML monolithic proprietary DTDs

– From XML modular proprietary data model

Minor issues

– To solve with authoring/publishing system enhancements

– Change requestsJune 24 2014Bruno Chatel ([email protected])8

OEM

authoringvalidation

approvalpublishing

Transformation

proprietary data

model to ATA 2300

XML/SGML

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


Customization(CMS)

- revision impact

- authoring

-approval

- publishing

On ground

consultation tool

(Ops manager,

Flight crew

training…)

On board/EFB

e-Viewer(maybe OEM

dependant)

OEM A

XML/SGML

Customization(CMS)

- revision impact

- authoring

-approval

- publishing

On ground

consultation tool

(Ops manager,

Flight crew

training…)

On board/EFB

e-Viewer(maybe OEM

dependant)

OEM B

XML/SGML

ATA 2300 ? Why ?

Developing a new CMS

– And take advantage of OEM delivery (if any)

ATA 2300

– 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”


Customization(CMS)

- revision impact

- authoring

-approval

- publishing On ground

consultation tool

(Ops manager,

Flight crew

training…)

On board/EFB

e-Viewer(maybe OEM

dependant)

OEM A

XML/SGML

OEM B

XML/SGML

On board/EFB

e-Viewer(maybe OEM

dependant)

How to go….

First case: Wait for ATA 2300 OEM deliveries !


OEM A

XML

OEM B

XML

Customization(CMS)

- revision impact

- authoring

-approval

- publishing

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

XML

OEM B

XML

Transformation

proprietary data

model to ATA 2300

Transformation

proprietary data

model to ATA 2300

Customization(CMS)

- revision impact

- authoring

-approval

- publishing

CMS to Viewer

Use ATA 2300 as the exchange data model between

CMS/Customization and e-Viewer

– Opportunity to different software providers

– Share common technologies

for the whole fleet

– Also allow to support

“operator manuals” (not related to

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

? Proprietary data format for OEM EFBs viewers ?

• Convert from ATA 2300 ? (to be studied)


Customization(CMS)

On ground

consultation tool

(Ops manager,

Flight crew

training…)

On board/EFB

e-Viewer(maybe OEM

dependant)

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

[email protected]

http://www.chadocs.com

+33 4 96 11 14 57


Technology

ATA Spec 2300, implementation perspectives. Who, why, what, how… When? Bruno Chatel