CMS Integration with M&E Systems

Author: Thanos Kaponeridis, President & CEO, AeroSoft Systems

Subscribe

CMS Integration with M&E Systems

Thanos Kaponeridis, President & CEO, AeroSoft Systems considers the opportunities and challenges encountered when two systems work together

There is a distinction between the two terms used for engineering systems in aviation. M&E systems are for airlines with MRO facilities (or not) and are focused on compliance and utilization tracking. MRO systems are more for third party operations, focused on the detailed execution process but in particular in managing the logistics of utilizing human and capital resources in an MRO environment. A good M&E system has a lot of MRO functions. Some vendors claim their product does it all; others have specific variations of their products to meet these needs. There are also suppliers that are strictly MRO oriented and do not offer the functionality required for airline compliance.

In a similar way, content management systems requirements are also different for M&E/airlines and pure MRO companies and systems. Again some M&E systems suppliers say they do it all so that you don’t need a separate CMS: others recognize that integration with a pure CMS is essential.

This article is going to consider what is insufficient about today’s CMS integration with M&E and why. It will cover what more can and should be done if we are to improve things substantially and truly exploit the potential of both domains: but first, an indictment of the regulations which historically have driven M&E systems. A couple of paradigms will recur: one is my favourite pigeons and pigeonholes analogy (data and data entity relationships) and the other one is the SportsCasters in the industry.

THE HISTORY OF INTEGRATION – OR NOT

Our core business processes have not changed since the 1960’s when the original B747 was first being built and operated. But, there is a choice: you can continue ‘integrating’ M&E Systems with CMS the way you did in the late 1980s, essentially by attaching electronic ATA-100 look-alike objects, and continue printing and signing off with pen on paper, then claim you have CMS and M&E integration. Then you can go back to scanning those paper records and re-indexing them for future search and retrieval. If .PDF means ‘electronic data’ to you then you’re fantasizing about moving to Mobile platforms. And if your application is Client Server, the Cloud will only bring you Thunderstorms. Interestingly, mainframe applications are more suitable to move to the Cloud with a browser front end and the logic at the back end. On the other hand, pure client server applications may be easier to move to a mobile app and then the Cloud back end. A browser front end does not constitute a mobile application.

I applaud the initiatives of IATA in PAO, the Paperless Aircraft Operations. When I got into IT 40 years ago we already knew the ‘Office automation will create the paperless office’ slogan. Since then we’ve learned that the paperless office will come the day after the paperless toilet. Look at the paper generated in the above process.

A LIFE GROWING WITH IT
During my career, I have been labelled an ‘enfant terrible’ but here is how I earned that reputation. After a bachelor’s degree in Engineering, where I was programming using punched cards, I went on to obtain a Master’s in Ergonomics, following which my first job was designing a Nuclear Power Station’s Control Room. After that, I returned to university and a Computer Ergonomics’ job to design the first system which aimed to move University of Toronto students migrating away from punched cards to interactive editors in learning their computer science courses and languages. My next role was as a consultant at Gartner Group Canada where I was doing the analysis and research, and hands-on technical consulting while the SportsCasters were doing the presentations. SportsCasters are those people that have terrific show presence (gravitas) and can talk about a subject with force and confidence, and graphs and so on while they have no idea whatsoever about the technical details or their feasibility. I’m old school on this and believe that, if you haven’t done the job you shouldn’t be talking about it.

My entry into the aviation industry was in January 1992 with Bombardier Regional Aircraft. I managed the design and implementation of the systems which produced the CRJ and Q Series aircrafts’ Digital Technical Manuals migrating from non-SGML systems to SGML systems. This got me into the ATA EMMC Text and Flight Ops working Groups, building the elements of iSPEC2200 and SPEC2300 standards. However, after Bombardier, I succumbed to the realization that I cannot work for others; so I established Aerosoft Systems in 1997.

MSG3 AND BEFORE – A KEY COMPONENT IN M&E APPLICATIONS

This is not a course in MSG3 (Maintenance Steering Group 3 – Maintenance Review Board – MRB). However it is important to highlight the major aspects of MSG3 which, in effect, should drive the functionality of the M&E Applications out there. The standard pre-dates even 1980: the original B747 launched in 1966 had design work ongoing since 1960, and MSG1 was issued in 1968. And, yes, the latest aircraft introduced into production in 2016/2017 are still based on MSG3 although the standard has had many revisions, the latest being in 2012. So M&E systems are built around compliance with that process.

NEW IDEAS ON AN OLD FOUNDATION WILL WORK BUT NOT WELL

There are advancements in our industry: almost everybody is building interfaces to data that’s coming out of the CMC (Central Maintenance Computer) on aircraft for input into M&E Systems. However, this requires intelligent parsing before it can be driven to a Symptom/Cause troubleshooting and associated maintenance event planning and execution using an M&E system that was architected a long time ago. There’s nothing wrong with maintenance systems that are built around the ancient regulations but there are opportunities today where we can do very intelligent or AI- neural networks based troubleshooting and analyzing real time information. When a device operates outside of two or three standard deviations from the norm and you perform this tracking and analysis as incremental work on top of MSG3 based maintenance, it’s difficult to save money. The savings will only materialize when the aviation world (Regulators, OEM’s and Operators) is convinced to progress to the next level of regulations. This will allow you to do only CMC data based maintenance and use intelligent trouble shooting systems that will seriously improve unscheduled maintenance costs.

WHY DO WE NEED M&E SYSTEMS?

We need M&E Systems to ensure compliance and because DMC (Direct Maintenance Cost) is a major part of DOC (Direct Operating Costs) and slight variations in it can make the difference between profitable vs bankrupt operations, all else being equal (aircraft types, age, route plan and so on). However, for an airline, M&E is there to primarily prove compliance: the efficiencies you strive for should be a secondary consideration.

So how did M&E Systems come about? Did some group of wise thinkers get together with a white board and start designing one based on some well thought out data model and process model? No; M&E Systems were built as derivatives of previous systems where they were managing financial data or inventory data or tracking engine performance; or they were built within the IT department of a single airline from which a commercial product was developed but still reflecting essentially the business processes of that originating airline. Over time, they got retro-fitted and migrated across technology platforms but nothing has been internally built against a perfect data model and process model. So, retro-fitting these applications over time, then claiming that they can also support CMS in their architecture is, at best, disingenuous

Here’s the issue; when you change applications from one version to the other, I go back to my pigeon and pigeonholes paradigm… the pigeon being data and the pigeonhole being where it belongs. Some people saw the same pigeons being managed in an inventory system and in aircraft configuration so they started that way. However, even the same pigeons might not fit in the same pigeonholes in a different system. The problem is that the relationships of pigeons/data in an original system are not what’s required in an M&E system. If you don’t get the data model, the process model and the entity-reference relationship identical, it’s very difficult to move data from one application to another. So, by adapting and adopting the systems over time, the systems start looking like cauliflowers.

WHERE DID CMS COME FROM?
While M&E Systems were established as essential to Airline MRO operations, CMS were originally  built by/for manufacturers and were only considered 20 years ago by the very large and profitable operators. Manufacturers were using content management systems before we had SGML and XML and they were using relational databases to manage chunks of content as they were authoring them with applications like Interleaf (Quicksilver) and FrameMaker before it was bought by Adobe. OEM’s rapidly moved to SGML after 1989 with SPEC2100, later renamed iSPEC2200, (incorporating ATA-100 and .PDF). While the standards were supposed to be built by the Airlines and be dictated to the OEMs, in fact they were driven and dictated by Boeing, Airbus, and Bombardier, Embraer to a lesser extent, and pushed to the airlines to accept them. A more novel initiative in re-writing Flight Ops documents (from the original FCOM stuff) emerged as airline driven but eventually SPEC2300 ended up the same way. The politics of standards bodies are immense!

I was at the ATA meeting when Mr. Richard Higgins VP Customer Services of Boeing (at the time) added / voted .PDF into iSPEC2200 as an ‘acceptable delivery / compliance’ to the spec: imagine, .PDF as an electronic form.
S1000D was adopted by ATA in May 2006, as the new generation standard (and there are huge variations between Rel 3.0 / B787 and 4.0 / C-Series and 4.1 / A350) but with the exception of these aircraft, all other commercial aircraft were and are still being built with documentation authored in iSPEC2200, not S1000D.

CMS companies also originated by adapting file management systems (original Documentum), text search engines (roots of Enigma), etc. to evolve their systems. The real CMS innovations came out of the SGML and XML editor companies of old like Balise (roots of Dynatext/Dynaweb), SoftQuad (grandfather of XMetaL), ArborText (Epic and other technologies), XyVision, OpenText, Omnimark and open source contributors like James Clark.

A new system might not offer a new outcome

Many initial M&E systems were built to move operators away from their CardX systems used to track component history. Later, others used the Year 2000 problem to rebuild and re-engineer their architecture. And when you re-engineer – in essence a migration from System 1 to System 2 is re-engineering – you can’t just map the data; you have to sort out your pigeons , your pigeonholes, the precise definition of your pigeons but most importantly the ‘relationships’ of pigeons. So not only the data model but the entity reference model and the process model have to be mapped correctly. That is why many organizations, convinced by SportsCasters to change systems, “They’re both on Oracle so moving is easy”, make the decision on the costs of visible license fees and hardware platform and then spend three to 5 years migrating systems, never admitting what they lost in internal resource costs and only to end up with something very similar or worse. Publicizing such projects would be a career limiting admission. Some companies have in fact stopped such stillborn projects and reversed their original decisions.

The right system for the job

Do Job Cards not have a special place in your heart? When you perform the above steps within the capabilities of an M&E system and adjunct systems you go through nightmares, costs, time delays and errors. M&E systems were transaction based systems in their design; to keep records, build relationships across those records and then to have that data reported. They were not built to manage real time digital content change. CMS systems, on the other hand, were built from the outset to do that, to be able to parse data against a known structure, validate the errors and be able to transform that data from one logical or physical structure to the other

EFFECTIVITY
SBs as issued by the OEM’s are ‘MSN specific’: yet when they arrive at the airline they have to be drilled down to the rotable component and serial number as this has most likely moved across various MSN/tails.

Effectivity for OEMs is tail based and, as readers will know, that has very little meaning because components flow across tails in airlines. So the first thing when an SB arrives is to see what rotable component (or assembly/subassembly) and serial part numbers it impacts and then go and see to which tails those serial numbers are really attached. One of the things that a CMS system needs desperately is compliance to SBs because only then can the system show the effective task or sub-task. Therefore SB compliance will be taken at the component level at the airline (say an engine and landing gear) and then translated to the MSN that actually now has that component; and then it has to be parsed against the long MSN based effectivity which is in the OEM manuals.

Effectivity, as authored or distributed within SGML and XML content by OEMs is absolutely not humanly parsable information. All that needs to be filtered out to show the mechanic only the effective task or sub-task for the tail that they’re working on based on SB compliance. Incredibly, there are major M&E systems on the market that cannot build fleet-wide SB compliance; they can only build tail wide SB compliance.

The passage of time does not always mean progress

I don’t want to spend a lot of words on the history of the systems but I’ve certainly lived the reality from the early 1990’s. Today we do have some systems that print from XML source in the CMS to PDF because the M&E system on the other side demands to just receive that and tag on top of it the MPD plus visit specific data and then print it to a specific printer at the workplace to get the job signed-off physically with a blue pen! As such, all we are doing is just replacing the paper with a PDF version of the same thing. Progress is not to digitize/scan a printed PDF and attempt to re-index when you have started with XML intelligence in the content management system.

THE CHANGING DIVISIONS OF BUSINESS FUNCTIONS

There is an optimum division of business function to be allocated from MRO to CMS. In the early days, because there was only M&E, all the functionality and all the business processes were commandeered by the M&E system but now a lot of it has to be given up to the capabilities that CMS systems can truly provide. Some M&E Systems have just recently begun attempting to import Initial Parts Load from an XML IPC dataset. What’s ironic is that the IPC is generated from a database at the OEM, it is not hand-authored in XML and that schema would be even easier to transform to the M&E’s model.

So the areas which M&E systems owned under their functionality which simply did not belong there are JobCards, MPD, EO, Delivery of work-packages to any platform / environment and being able to receive compliance in digitally signed off content, and so on. And let’s not forget conversion of systems or introduction of new aircraft: the famous spreadsheets the vendors ask you to fill out which can they then use to import to their own internal data structures with inevitable several rounds of failures.

SO, WHERE DO WE GO NOW?

So, given all of the above, the next question has to be where should we go and what should we do next in the process of systems and business process evolution in integrating CMS with M&E systems? I have a few ideas as to what is needed and what the various players in our industry should do.

Job Cards must be in CMS as derivative documents from AMM; MPD/MRB – not distinct non-standard documents. Job Cards will have their COC’s to be managed in CMS. EOs in XML should be assembled by pulling together the appropriate sections of SBs and then pulling in the task or sub-task (from AMM) that will make the complete EO; that will insert it back into a workpackage. CMS must print/deliver workpackages to output devices: printers, mobiles, tablets, and capture compliance/sign-off (digital signatures) and feed it back to M&E. Data captured either as PIREPS or MAREPS should also be captured in an intelligent XML structure because that makes their availability to natural language search of that database and comes up with system cause relationships to assist in troubleshooting.

Workpackages themselves should be in a schema such that they can be transferred from an airline to a third party MRO and then be received back in a digitally signed-off form; it shouldn’t be necessary to print material to send it to a third party MRO. I believe the establishment of ATA SPEC2500 and S5000F are essential steps of progress in this domain. Now let’s see how long the major M&E suppliers’ can claim compliance to these standards.

Component Manufacturers should also supply their data either in iSPEC2200 or S1000D and not PDF or MS Word files. This enables the dovetailing of such content and applying STCs to special business processes or special usage of aircraft that have been converted, say, from passenger to cargo.

The answer is not necessarily to go with the giants of ERP’ (aka SAP, Oracle, IBM) to get the best possible solution in our industry.

Users should evaluate their vendor in terms of… where do they come from, where are they going, what have been their successes and what have been their recent failures. And, when you select your mobile strategy, do not do so on emotions or to please your CEO who owns an iPad; you really have to pick it in combination with what your M&E supplier expects and what your CMS supplier expects. It’s not possible to have a mobile strategy selected by one and enforced on the other because you cannot have this concept of end-to-end digital sign-off of a card that takes its compliance from the M&E system but remains as a permanent record in the CMS system for later auditing and so on.

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. Since starting at Bombardier Regional aircraft in 1992, Thanos has built up his aerospace and aviation experience where he managed the development of the iSPEC2200 compliant digital document systems for the CRJ and Q400. 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.

AeroSoft Systems Inc.
AeroSoft Systems Inc. was established in Toronto Canada and has an office in Austria, and technical resources in USA/Miami, UK and Denmark. With maintenance paying customers of up to 20 years standing, operating over 1000 aircraft serviced globally in the Americas, Europe, Africa and Asia, Aerosoft products have been installed and used by over 50 airlines/MRO’s over the past 20 years and customer/product loyalty dates back to the early 1990’s.