(Part 2)

In an industry full of standards Thanos Kaponeridis, CEO & President, AeroSoft Systems Inc. considers the challenges of electronic data interchange

In the previous issue we considered some of the underlying causes of a seeming inability to integrate the various M&E and CMS systems that we use. In this issue we’ll consider some specific matters and some thought processes that might just take us forward to the more integrated environment that people have been seeking for decades. However, to begin with, we have to say, the process is complicated which is both a challenge and a block to true standards-based CMS and MRO systems evolution. Let’s consider a couple of examples to illustrate what I mean.

Toolbox vs pure iSPEC2200 or S1000D

Say you start making your COCs in Toolbox, then extract the collection (for a Boeing 777 it would be iSPEC2200, in the case of a Boeing 787 it would be edits to the data modules in S1000D). If you extract them in SGML or XML, such content does not parse against the iSPEC2200 DTDs or S1000D Rev 3.0. So, when you’re looking in Toolbox and considering what content you can extract directly from it, you will have to do work to actually make it comply with the open standards established by ATA. Take the Service Bulletin, for example: we had a case in the last few months. It’s now at about revision 9 of the DTD and, accidentally, one of our customers inserted a revision 4 service bulletin in SGML. Unfortunately, there’s a slight difference between the two: in rev4, effectivity was quoted as text in a para; in rev9 it’s quoted as table data. The result is that we have an application build looking for a new table that isn’t going to find it inside a para.

Consider the MTCM: Boeing has an MTCM and so does Bombardier but they’re not the same structure and MTCM per se is not part of iSPEC2200. An Airbus customer would say, ‘what’s an MTCM?’ because they have an MPD/AMM and have to create Task Cards. FIM and FRM are separate documents in Boeing but go as a single TSM in Airbus. Why do we need an MTCM if an MPD contains the AMM references for each MID? In a perfect world, an MTCM is really a document that comes together by the intelligent combination of the MPD/record data with the AMM/detailed instructions, contained in AMM tasks. And, just to compound the confusion, the XML delivery of MPD from Boeing (for B767/757) is missing key sections which are included in their .PDF version? Ditto the Excel/XSL version: but, if you don’t catch that and deal with the data individually, you don’t have a fully compliant environment established.

And these are just references to the situation with the large OEMs who are very versed with the standards and processes. How about the 16,000 or so CMMs – the lower tier manufacturers in the manufacturing supply chain – how many of them have adopted or use any of the above standards? How many have moved beyond MSWord and .PDF, the lowest common denominator in this world of small suppliers.

Typical challenges to MRO/CMS integration

Here’s a challenge: you have an older MRO system – sort of middle of the road because it even allows you to author and edit job cards in SGML. However, you’ve decided you’ve got to replace it and you’ve shopped around and sourced a state-of-the-art current MRO solution, one of the market leaders today. You had (in the legacy system) the top part of the task card (mostly MPD and visit specific data) and the bottom (detailed instructions and data capture during the visit) and now you want to migrate to a CMS integrated with your state of the art MRO.

What you’ll find is that you’re purchasing iSPEC2200 digital data subscriptions from the OEM’s, but you also want to keep the task cards that you’ve authored, especially your in-house task cards from your initial MRO system, and you only want to introduce the MTCM for the standard scheduled interval tasks. A heck of a lot of data conversion is involved with this situation where we’re talking about state-of-the-art MRO and CMS systems as well as original data that, in parts, was in SGML and in others as records in a relational database. And yet, you’ve been let to believe that it might be more straightforward since, after all, the legacy MRO, the ‘new’ MRO and the CMS all have Oracle underneath!

Old mentality and outdated processes

In reality, low cost MRO shops expect to receive paper printed task cards (or .PDF which they print in their facility). They execute them then sign them off on paper and return them in boxes of paper: so there needs to be a capability to scan them and do indexing and OCR or ICR conversions as the only remaining alternative to link them to transaction oriented MRO or CMS systems, modern systems that would otherwise accept true open digital data.

The same goes for the old 8130/EASA Form 1: most are printed and filled and signed by hand – then scanned for linking with or attaching to transaction oriented systems. Everybody is hung up on where do we put their logo and signature column or box on job cards (totally locked on the page/print paradigm) without understanding the concept of linking the approval event and its audit trail to the information unit. They need to ask, how do you do conditional intelligent branching in a job card where you read, observe a condition on the aircraft or component and then execute this path versus the other when undertaking the maintenance? And how do you capture all that information and feed it back to the MRO system or have it directly authored into the MRO system; or architect job cards that truly capture ‘part off/part on’ information during the visit but also inspection data in a comprehensive manner and relate it back to the MRO system so that the data can flow among the different systems at the airline vs their 3^rd party MRO supplier?

Data Conversion – claims versus reality

In aviation we have had an incredible array of standards for many years so you can pick any, many or all of them and yet you cannot, at the push of a button, move electronic data, for example, from one MRO system to another, even though they’re almost all on Oracle! You cannot move a complete Maintenance program or job card work-package with its associated scheduling (the emphasis again is at the push of a button) from one airline to a 3^rd party MRO facility, complete the work, capture the findings and accomplishment authorizations and return the package to the originating airline. And if you want to move all of the parts information, what if the old system used 25 digits to capture part numbers while the new one uses 20? Get XML to solve that one and then bring in 20 years of history and then you’ll be able to say to yourself that you’re ready to take compliance on the new system.

Even in the CMS industry, where we take absolute pride in abiding by standards, have you ever tried to migrate Jouve (ex-ITG/Flatirons+Corena now) to Enigma? Have you tried moving data from Corena S1000D to TechSight? Or maybe IDMR to TerraView? What do you think it would take to move a mature fleet database with five to 10 years history (as some these systems are older than that) with substantial local content and associated ‘audit history/workflow meta-data’ to move across these systems?

In every system implementation the biggest challenge by far is the data conversion – and proving that you in fact have all the data correctly migrated after the process. Various workarounds are often used such as converting minimalist amounts of current data and keeping the history in a dormant version of the legacy system – this is often required for SOX compliance.

Building bridges between different systems is a complex endeavor so here are some hypothesizes that might be presented to you.

Hypothesis 1: You can move an electronic/intelligent set of Job Cards from one MRO system to another (at the push of a button), process them and return them to the original MRO. We’re talking about a round trip in which the airline sends it to the MRO; the MRO accomplishes the work and sends them back, with all the customization that the airline wanted in the first place.

Hypothesis 2: You can (at the push of a button) move complete maintenance data records from one MRO system to another, process them and return them to the original MRO.

Hypothesis 3: XML makes data interchange easy, transparent and pushbutton plus you can edit XML data like MSWord.

All of the above are at best ‘marketecture statements’!

Hopefully I’ve convinced you that there are some difficult questions to ask in assuming the above and that serious due diligence needs to take place to validate these claims… which are absolutely not true. In saying that, I’ve just spread FUD, an acronym from the bad old days (fear, uncertainty and doubt). Typically, vendors that don’t have solutions usually do that; spread fear, uncertainty and doubt. But let’s look at what the regulators are saying; this (figure 4) shows some results from an FAA study carried out in 2012 and it’s worth considering. The bottom line is what’s important, that there is technology and software and processes but that they’re under-utilized across the industry.

Figure 4

Figure 5

The next chart (figure 5 above) provides a snapshot of what the study concluded about the distribution of the root causes of technical documentation issues based on a statistical sample. The most important recommendation of the workshop that produced these statistics was that “the industry has to make more use of the available software technology and know-how that already exists which is not [currently] being fully exploited to solve the issues.”

The paradox of our industry

We take too long to build Standards – even though we’re copying them from others (iSPEC2200 came out of CALS, S1000D from AECMA). We also take too long to develop them to our own versions and then we take too long to adopt them and adapt them. We keep changing them and we watch the world go by while other industries bring forth revolutionary standards and technologies which do amazing things that we wished we could do. And we are stuck. We have a lot, yes, there is SPEC2000, iSPEC2200, S1000D, SPEC2300 to potentially make the electronic data interchange between OEM’s and airlines and MRO’s and amongst end-users of the data, transparent and easy. We have Electronic Signature and we even have nose-to-tail communications on aircraft and communications from aircraft to the ground with ACARS/ARINC CMC protocols for data capture and transmission from aircraft to ground. Yet the encoded values for such protocol data streams for various errors and fault conditions on the aircraft are totally different across aircraft types even from the same OEM. So you require different intelligence to analyze the codes from a 737 and a 757 and a 767. Yet we fiercely defend our standards.

A healthy data interchange environment

Let me digress a little – it is relevant. The company that actually enabled XML editing within MSWord in 1994 was i4i and that’s the technology whose patents, ultimately today, gives you .docx. After that, i4i specialized in the Medical industry and participated in work on the HL7 standards, an application level interface; it’s built on the ISO Layer 7 interconnect model and its application to application interface. That’s because you can’t go to one doctor and then change your doctor or hospital next week and not be able to have your data totally move from one place to the other or say ‘well, we need a lot of conversion’ or ‘we’re going to lose some of your information’. But that’s the kind of answer that we accept in the aviation industry. So, you say, ‘so what?’

The ‘what’ is that, in aviation, we need an application level interface that we haven’t even come close to developing. The existing standards that we have, as we use them, do not allow for transparent moves of data at the push of a button for the round trip as I described above. Establishing such a ‘product independent’ data interchange in our industry will make the playing field level and will allow buyers to make their choices according to true ‘product features and functions’ and not because “I bought a plane where they use ’ABC MRO‘ so I’ll install ABC MRO in my company!

GLOSSARY OF TERMS

AECMA (Association Européenne des Constructeurs de Matériel aérospatial/ European Association of Aerospace Manufacturers)

AMM (Aircraft Maintenance Manual)

CMC (Central Maintenance Computer)

CMS (Content Management System)

COC (Customer Originated Changes)

DTD (Document Type Definition)

FIM (Fault Isolation Manual)

FRM (Fault Reporting Manual)

ICR (Intelligent Character Recognition)

MID (Maintenance Instruction Document)

MPD (Maintenance Planning Document)

MTCM (Multidimensional Trellis Coded Modulation)

OCR (Optical Character Recognition)

SOX (Sarbanes-Oxley Act)

TSM (Troubleshooting Manual)

Contributor’s Details:

Thanos Kaponeridis: President and CEO AeroSoft Systems Inc.

Thanos Kaponeridis is the founder of AeroSoft Systems Inc. established in Toronto Canada in 1997. He has brought AeroSoft from a start-up through organic and inorganic growth to become a unique niche player in the M&E Systems marketplace with their two MRO products of DigiMAINT and WebPMI plus DigiDOC (CMS). Thanos has built up his aerospace and aviation experience since engaging at Bombardier Regional aircraft in 1992 where he managed the development of the iSPEC2200 compliant digital document systems for the CRJ and Q400. He was a long-standing member of the ATA/EMMC/TICC eText and FOWG since 1994 in the development of digital document standards. Prior to Bombardier, Thanos was an accomplished IT/IS senior consultant with his own practice and prior to that with the Canadian subsidiary of Gartner Group, offering strategic and tactical planning of IT/IS to multi-national corporations. Mr. Kaponeridis holds a Bachelor of Applied Science from the University of Toronto in Industrial Engineering and a Master of Science from the University of London (UK) in Ergonomics / Human Factors.