Upload
hoangkiet
View
220
Download
0
Embed Size (px)
Citation preview
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