CMS: Afterthought to MRO/IT – until now

“MRO/IT ≠ CMS – They’re not competitive, they’re complementary equal partners in Compliance andcomplementary, equal partners in Compliance and should be agnostic of each other in implementation / integration.”integration.

MRO/IT Frankfurt, July 13,14, 2011Thanos Kaponeridis, President and CEO,

AeroSoft Systems Inc.

Preface

• Factors contributing to CMS taking front-row-centre in 2011row centre in 2011

– Early 2011 economic forecast better than 2010, 2009, 2008…

– Price / performance, technology and standards maturity

– Major integration projects “BoB/ERP MRO/IT with CMS: announced and or goingMRO/IT with CMS: announced and or going live

– Integration points defined (much more needs to be done!)

AeroSoft SME: With 2 MRO/IT plus one CMS system – we

– Changing boundaries (Change Authority for Compliance and ultimate record keeping and in what ‘format’)

hold a unique place

Forces which kept CMS as afterthought

• Parts cost ‘more dollars’!• Compliance is taken from MRO/IT ‘System’• Compliance is taken from MRO/IT System

– But what if you’re using the wrong Job Card / AMM / MPD revision!• Cost / Complexity of legacy – initial SGML solutions

C l d i i t h l i d t d d• Complex domain in technologies and standards• Confusion about ‘standards’ and the term ‘electronic manuals’• “Paper rules OK” still in many places!• MRO systems have managed Paper Manuals and CD/DVD’s ‘like

spare parts with mods’….• MRO/IT systems ‘claiming they do it all – no need for separate CMS y g y p

systems

TOC / LEP

• AeroSoft’s historical perspective in CMSAeroSoft s historical perspective in CMS• MRO/IT managing Job Cards / MPD ‘circa 1980-2000)• Roots of MRO and CMS and why MRO≠CMS

Why we need BOTH MRO/IT and CMS• Why we need BOTH MRO/IT and CMS• Why MRO/IT can’t be CMS• What does a CMS must have and ‘do’• Why do we need BOTH MRO/IT and CMS• Areas of integration• The changing ‘boundaries’ or (change authority) data and controle c a g g bou da es o (c a ge aut o ty) data a d co t o• AeroSoft’s offering overview: DigiDOC

AeroSoft’s Historical Perspective

• AeroSoft was born out of Digital Technical Content authoring and publishing systems development for aircraft OEM (1992-1997; CRJ, Q400, ATA/eText/FOWG) we did not just jump on bandwagon!ATA/eText/FOWG) – we did not just jump on bandwagon!

• Initial experimental product in 1996/97: Automatic job card generation with AMM, IPC, MPD served on Internet

• Economic realities lead to one MRO/IT acquisition (1999) and another inEconomic realities lead to one MRO/IT acquisition (1999) and another in 2004

• AeroSoft implemented ‘MRO/IT’ based ‘job card and other manuals management within our applications…

• DigiDOC acquired in 2008• MRO/CMS Integration well defined in 2009• Key CMS prospect development 2009-2010• Welcoming Icelandair (ICE) Technical Services – June 2011

Our Customers have included

MRO/IT attempting “CMS work”

• MRO/M&E Systems were established before CMS– Timeframe 1985-2005

• 1st generation ‘dumb screen’• 1st generation dumb screen• 2nd generation ‘client server’ / RDBMS• 3rd generation 3-tier, Browser/Web Server

– “PARTS” & Dollars orientation– Aircraft Configuration– Maintenance Planning / optimization– Maintenance Production monitoring / reporting– Compliance monitoring / reporting– Initial Data Load (once and only once!)– “Reports” and ‘Spreadsheets’ only export– Edit Job Cards in “Record Fields with ‘limitations’

• Attach ‘OEM content as is’ from known locations/DVD’s

– Build an ‘SGML/XML’ editor into the picture!

CMS and link to ATA •ATA iSpec 2200 Overview:

http://www.spec2000.com/presentations/andreass.pdf

– 1975-85: “Tech Doc was issued per ATA Spec 100 ‘Paper Manuals (initial B747 in 1970 was filled with one set of typewritten documents)

• And it was being authored on mainframe systems with ‘two pass’ systems imbedding formatting codes and text

1990: Early deliverables from SPEC2100 (few DTD’s in– 1990: Early deliverables from SPEC2100 (few DTD s in ‘progress’)

• Major OEM’s doing Tech Writing with Interleaf / Frame– 1995: OEM’s doing SGML authoring Publishing on1995: OEM s doing SGML authoring, Publishing on

own/proprietary viewers• Major OEM’s doing Tech Writing with Interleaf / Frame

Historically• CMS

Image management systems (Before that!)– Image management systems (Before that!)• Scan, store image, ‘index’ some information

– Document Management Systems (Before)!• File management systems for ‘Files’g y

– Content Management Systems • Information in structured ‘content units’ for ‘re-purposing’ in different views, platforms,

and re-use in different content and context yet the ‘information units’ are held in one placeplace

– They relate to ‘OEM information about ‘Parts, Configuration, Procedures, Compliance, Operations, Training

– AMM, IPC (!), MPD (!), MTCM, WDM/SSD, CMM, SRM, EIPC, EMM,….FCOM/QRH/AFM..….

Technical Content is everywhere

MRO/IT and CMS functional allocationManage

HOW TO DO data:

MRO requests on-line

•View of technical contents•Print of work packagesThe WP request comes as an XML file •Revision Load OEM manuals including

TRs•Modify procedural and product data (locals)•IPC could be updated with alternate parts specified by MRO•Create procedural and product data•Service Bulletins

MRO does:

•Production planning, •Stock management (provisioning)R ll ti

•The WP request comes as an XML file•Airplane modification status and compliance records•SB applicability

Manage

WHAT TO DO data:

•Revision Load OEM MPD (maintenance

DigiDOC

•Resource allocation•Finance and invoicing•Approvals

MRO System

DigiDOC will transfer packages of

•MPD Data•Parts data (including full parts lists)•No provisioning

e s o oad O ( a e a cePlanning Data)•Modify OEM MPD data (locals)•Create local MPD items•Including AD items•Local mods /SBs

Manage

•Rotables•Warranty•Manage affected airplanes

No provisioning•Information module list (URLs)•Selected anchors ATA2200•DML for S1000D•On-demand compiled Work Packages•Service Bulletins•Compliance data (e.g. defects)DigiDOC request MRO for on-line display•Spares availability

COMPLIANCE DATA:

•Store scanned Job Cards with sign-off•Retrieve compliance data through interactive Job Cards.

Spares availability•Spares ordering

M&E Documentation Systems come from?

• Classic M&E system trying to do “CMS”!

– Job Card Systems” managing M&E Records with references to ATA100 printed manuals….

– Managing printed manuals / revisions as ‘parts’– ‘Re-authoring Job Cards within ‘records oriented

data structures’ (but having an SGML editor attached!))

– Linking / ‘pouring’ OEM ‘content’ into the ‘instructions area of “M&E managed skeleton

– Claiming “SPEC2000” parts and parts transaction compliance if possible or desirable and claimingcompliance – if possible or desirable and claiming more than published standard!

MRO / ERP features that don’t fit CMS!

• Data Model and Process model is ‘different’ (not ‘wrong’ just different) from CMS– Correct for Parts, Dollars, Inventory …. very incorrect for ‘SGML, XML, CGM

structured information• ATA iSPEC2200 CSDD has a Data Model but it is safe to say NO MRO/IT SYSTEM

was implemented using it!• Initially loaded from OEM supplied ‘lists (IPC MPD BOM) for ‘new aircraft butInitially loaded from OEM supplied lists (IPC, MPD, BOM) for new aircraft but

– Must be loaded and maintained from actual ‘as maintained’ aircraft configuration after that!

• At best MRO/IT systems try to comply (in part) to SPEC2000• Client / Server architecture most popular delivery/installed platform• Mostly built with 4GL tools / Client Server implementations using “RDT/Citrix” to

extend over Web.– Few: Java C++ NET XML COBRA “VM” “Browser”Few: Java, C++, .NET, XML, COBRA, VM , Browser

• Essential design principle : Each Part is unique and can only be used ‘in one place’ – Systems take ‘pride’ on the “DBA/Parts Master” type single/controlled method of

definition of ‘parts’ before they can be used etc. etc.

Basic building blocks of CMS– Information UNITS are REUSED and REFERENCED all the

time in many views/transformations – managed from a ‘common source)“CMS” Repository (Effectivity Management Revisions– “CMS” Repository (Effectivity Management, Revisions management, workflow, revision, structure validation, local content management….)

• Underlying with an XML-DB, OO-db or RDBMS (?) – “Editor”(s) for different data types (SGML/XML “CGM” ) but– Editor (s) for different data types (SGML/XML, CGM …) but

also managing other popular proprietary structures (.DOC, .XML, .PPT, …MSProject, MSACCESS….) Job Card Editors that generate XML

– “Bridge”(s) between ‘editors’ and ‘repository’ – no ‘ties to g ( ) yspecific products

– “Validation” of DTD/Schema in ‘importing/exporting– “MRU” level editing/re-use (not Page or Document …but Task,

Subtask, Note, Caution/Warning, illustration …..– Online ‘viewing’/management environment– “Publishing engine(s) for various outputs (“WEB” …- including

mobile technology, .PDF, “CD/DVD”, PAPER (yes!)…)– “Viewers” for different ‘content types’ – graphics, animation!– Interface / API to “M&E” (the ‘Good Old Parts, A/C config,

limits ‘systems’)

CMS and ATA

• Their roots come from an aircraft / engine OEM perspective• iSPEC2200 most prevalent standard (in terms of a/c flying today)• iSPEC2200 most prevalent standard (in terms of a/c flying today)

– What’s “misunderstood most” about iSPEC 2200?• It includes .PDF!• Effectivity Model• Revision Model• IntREF / XREF validation• INTERCHANGE STANDARD NOT SUITABLE FOR AIRLINE/MRO INTERNAL USE

and RE-USE!

• S1000D will eventually take over (4.1+…) • Fundamental concept: Information should be based on a common

‘source’ but re-used (and transformed) from that source as often as ( )it is suitable and must be capable to be ‘augmented’ in a controlled manner

Key CMS Features not in MRO/IT• Any XML / SGML editors and CGM editors but also Custom Job Card or MPD Editors

(drag and pull front end / XML generated at back end compliant to DTD or Schema)• Management of OEM Revisions, Local Changes/COC, TR’s, Airline Approved Final g g pp

Revisions• Anchor Management and Searching• “Change Authority Audit Trail”

Minim m Re isable Unit• Minimum Revisable Unit• Attaching ‘non XML/SGML’ to structured documents (SB’s, AD’s in .PDF or MSWord..• Resolving effectivity to MSN or Component for the viewed content• Audit trail to get back to ‘any revision’Audit trail to get back to any revision• Synchronizing revisions across manuals to specific aircraft configuration• Forcing (intentionally) different revisions of specific manuals to specific tails and / or

enginesS• Electronic Signatures

• .PDF support (with XML conversion or without!)• Publish to ‘anywhere’ – Web, Mobile, EFB, “DVD”..Your IETM / IETP• Support multi-TerraByte data stores• Support multi-TerraByte data stores• Web 2.0, W3C, SOAP, SOA, CORBA, iSPEC2200, S1000D, DITA

Why both MRO/IT and CMS are essential

• Information (managed by CMS) must be linked to Parts and to actions / transactions performed on parts (or airframes, engines)“Eff ti it ” d “A li bilit MSN C t l l SB• “Effectivity” and “Applicability: MSN, Component level, SB accomplishment – ALL KEPT by MRO/IT yet essential in communicating back to CMS to ‘render correct information

• Initial Parts Master Load: CMS can do an excellent job intoInitial Parts Master Load: CMS can do an excellent job into MRO/IT from IPC!

• Parts Revision Load: CMS can do an even better job!• MPD ‘load’, mapping to AAMP and revision impact analysis: CMS , pp g p y

territory• Authoring “MRU’s” and direct ‘re-purposing’ of CONTENT – CMS• Managing WorkPackages – MRO/IT territory, yet “Correct detailed

instructions must come from CMS”• Compliance / Accomplishment ‘sign off’ – must be taken at both

MRO/IT and CMS (which can ‘keep permanent electronic signed off Job Cards!)off Job Cards!)

M&E CMS Myth Busters

• “You don’t need a separate Digital Content Management System”– “We have an add-on” module and an XML editor that does the job!We have an add on module and an XML editor that does the job!– No difference between M&E/MRO ‘s “document management” vs.

dedicated CMS• Airline CMS can operate independently of your M&E System• “One software package ‘fits all sizes/needs’ of airlines MRO ”• “Airline M&E and 3rd party MRO / CMS needs are the same”• “We (Airline, MRO, Low-cost Supplier) can build it better / cheaper ‘in-

house’”house– Real cheap – we have low / ‘outsourced’ labor rates

• “Single vendor can develop ‘all integrated elements’ from scratch”• “A‘Large Single Supplier’ to obtain the best M&E/CMS solution”• ATA iSPEC2200 is ‘out of date’ - YOU NEED S1000D compliant

Systems• YOU should/must CONVERT iSPEC2200 to S1000D

(1) Revision load process. This first part

(2) Revision load –impact analysis. This second step helps the user to make proper actions on what to load

CMS Steps

DigiDOC working repository area

loads the data into the repository and produces applicable reports which can be manually used but also used the impact /boeing/boeing/757/MPD/MI structure

actions on what to load and also to resolve potential conflicts.

43

Data organized and aligned with the data in the working repository area:

revloads/boeing/boeing/757/MPD/rev21-MI structure

analysis tool.

revloads/boeing/boeing/757/MPD/rev21-MI structure

/boeing/locals/757/MPD/MI structure3

Original OEM data converted to an interim quasi XML

The second step is to align data so it looks like format and structure within the working repository area. In this way it becomes possible to the revision loader to make the load as well as making the impact analysis, so the user can resolve conflicts if any.

2Original OEM data converted to an interim quasi XML structure including binaries like gfx, pdf, word, etc.

XML-originals/boeing/boeing/757/MPD/rev22.xml

The first step in the loading process is just to

Original OEM data as received. Examples are:

originals/boeing/boeing/757/

The first step in the loading process is just to convert things into a format which is applicable to the format of the same data within the working repository. In most cases it means data is moved into an XML structure potentially including some binaries like Word, JPG, etc.

1originals/boeing/boeing/757/MPD/rev22-MS-EXCEL

originals/boeing/boeing/757/TC/rev11-PDF

Data Loading and Validation

• The one point MRO/M&E ISV’s agree: Data Conversion is the costliest / riskiest part of an implementation– Many (M&E / MRO) suppliers don’t ‘price it’ or ‘assume it’ – They’re glad it’s only done ‘once in the beginning’– They don’t have to ‘export their data in standard format!

• The only way to have a ‘new system’ accepted in Production is to prove that it manages ‘clean / correct data’ (even if you have to fix the previous-legacy system’s errors!).Do not assume because “Boeing or Airbus” have sent you an SGML• Do not assume because “Boeing or Airbus” have sent you an SGML instance, that the ‘data is correct or perfect’?!

• CMS leaves vendors no choice: YOU HAVE to convert incoming iSPEC2200 ‘interchange’ format to local/airline re-usable/deployableiSPEC2200 interchange format to local/airline re usable/deployable formats and validate all along – As often as every 30 days for TR’s and EVERY 90 days for full revisions for each doc type and each aircraft type….!

All System suppliers have same cost basis

• … therefore can offer similar pricing

• 100 man-years development of ‘one system’ has a cost base of $10Million – this must be recovered in a reasonably short period to meet investor demands and liquidity

• You can ‘beg borrow or steal IP’ and copy / re implement with• You can beg, borrow or steal IP and copy / re-implement with newer tools…’!

• You can ‘promise to write the software/solution at real cheap (outsourced) rates specific for that airline(outsourced) rates specific for that airline

OR

• You can legitimately purchase and license IP / technology (at opportune times) and continue improving, integrating and advancing

Our Partners & ISVs

• AeroSoft over the years has developed key alliances and work / share programs with the leaders in aviation technology and systemsshare programs with the leaders in aviation technology and systems.

AeroSoft’s Integrated Solution

Financial

Onboard devices linking to data

bus and transmitting to

ground

Flight Operation S t

System

AeroBUY

System

Line Maintenance

DigiPLAN

DigiMAINTor

WinPMI / WebPMI

DigiDOC

DJMData

Data

DigiDOCEngineering Services Line Maintenance

Engineering ServicesProductionCustomersData loaded

from OEM

IE GUI

from OEM

Data loaded Synchronization

Authors Browser

CD ROM

Web Browser

Data loaded from customers

SynchronizationScan Module

CD ROM Module

Data loaded -other

M&E System

DigiDOC Server

Online IETP and paperOnline IETP and paper

DigiDOC Document FlowView Official documents - Only

Boeing, Airbus, Bombardier, etc

AMM, IPC, MPD, SB, TR’s

P bli h f di t ib ti

OfficialJob Cards and documents for Production / Line / Workshop

Airline In-house Documents

Supplements

Publish for distribution

Supplements

Airline In-house Library

Information

MRO System Link to MRO System

Manage, Review

Authored y Link to MRO SystemDocuments

DigiDOC Customer Originated Changes

Click Button t t t L lto start Local

Edit

DigiDOC Operator Maintenance Requirements

MS Load

MR Revision Management

Maintenance Requirements

Create # Gen Maintenance ProgramsMS Load

CollisionAnalysis

Create

V lid t

Update

# Gen

A

View

Maintenance Programs

Validation

Validate

Archive Export

Approve

Regulators…

OEM MPD

Rev n <XML>

OEM OEM MPD

Rev 2 MS Excel

Planning / Job Card A li ti

OEMMPD

Rev 1

Applications

DigiDOC Review, workflow of MPD changesAuthoring Area: MPD classificationFolders below are virtual folders, which gather MPD items based upon different cirterias. The user has in this example clicked the ”REV – unclassified” folder, which then is presented in the right frame.

This MPD is a newly loaded ITEM from the OEM. The changes are high lighted so it becomes easier for the user to classify the ITEM. The classifications in this case are named APPL (Major and N/A (minor) The ”pink” bar in the official

This button shows a preview of all data within the ITEM, see next page..

N/A (minor). The pink bar in the official version indicated that the previous version was classified as APPL.

DigiDOC Mod Status integration with M&E

DigiDOC API Link from M&E System

• Integrating with the Mod Status in M&E System

DigiDOC Interactive Viewer

DigiDOC Multimedia support• We have plug-ins supporting formats that cannot be natively rendered by a

browser – like “IsoView “

DigiDOC technology implemented at

Thank you very much!

• WWW.AEROSOFT.AERO

• WWW.AEROSOFTSYS.COM

• For the eJournal whitepaper go to:– http://www.aircraftit.com/MRO/eJournals.aspx

• Check out the flash version• Check out the flash version