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

Part 1: What causes the problems and where does it come from?

During twenty two years in this industry I’ve lived and worked through many developments and, as a sector, we’ve encountered more than a few challenges. Experience lends a long-term perspective to evolutionary changes and developments; to view challenges and solutions in the whole, from outset to the present day. This article draws on my own experience to review those challenges over the years and consider what solutions might be applied with a particular focus on examples from the past twelve to 24 months.

In this first part, I’ll expand a little about where and how I gained my experience and how that followed developments in IT. We’ll also consider some of the obstacles, identify some of the challenges, and pose some of the questions that will need to be tackled to achieve true systems integration.

Changes and developments in IT

As with many people in IT, my career started on dumb terminals; though I’d hate to think that anybody’s mechanics might be using those devices today. Anybody who recognizes the top row in figure 1 (above) either has a very good memory or their systems are totally outdated. We’ve been through many generations and developments since then. My first ‘portable’ computer was a 512K Macintosh, carried in a little backpack, but I had to move to PC technology in 1990 when the business world moved to that technology. In 1992 I joined Bombardier and, in the process, also became a member of the, at that time, ATA EMMC/TICC Text Working Group, which later became eText. I was also a member of the Flight Operations Working Group. So, for several years, I participated directly in the development of data interchange standards before founding AeroSoft in 1997. Now, of course, after many generations of technology, we’re working with mobile platforms and their like. As an example of how far things have progressed, the USB stick I carry in my wallet today has a capacity of 64GB… more memory than all the computers in North America when I went to university in 1972; and that was two years after the B747 started operating commercial flights.

Hardware, user interfaces, development language… the whole sector, has changed significantly over the years but the fundamentals of computer science, process modelling and data modelling (data types) have not changed at all. You could have written a very good assembler 30 years ago and you can write some appalling C++ and Java today: having a RDBMS engine does not make you a data modeler nor does it make you a domain expert; and XML is not going to get you out of the data mess by itself simply by putting two little brackets (<start /end>) around things. Most importantly, mechanics still have to look at a PageBlock or an IPC set of pages (graphic and parts facing each other) to execute maintenance on an aircraft. They can’t parse a CSDB extract of data modules (in S1000D parlance); some other programs have to do it.

Life isn’t always simple and nothing can beat experience

There are certainly MRO and CMS vendors with very credible, recognized products in our industry for which they should be proud; while there are other vendors that not only extend themselves either in their MRO or CMS capabilities but also make incredible claims. Working on Bruce Lee’s dictum that ‘simplicity is the key to brilliance’ they simply claim that ‘Because of <XML> you can move the data from one system to another automatically’; whereas, as we will see further on in this paper, it’s rarely that simple. HL Mencken’s words might be more apposite; ‘There is always an easy solution to every human problem – neat, plausible, and wrong.’

This white paper should help you perform better due diligence in your selection process before making major decisions as to which vendor’s solutions you acquire.

In the Software Vendor community we try to be creative in making solutions appear easy, affordable and attainable through rapid implementation plans: it is called the law of survival. After I’ve given a presentation, other vendors often ask whether I really have to tell audiences it’s that complicated; after all, ‘we’re trying to sell systems here.’ But there is no point in taking a ‘feel-good’ line for its own sake.

I value the views of CEO’s and executives in airlines and MROs, after all they sign the payments and the contracts… but they’re often far removed from what goes on in the trenches; from reality. In our small company we don’t have that luxury. We’re exposed to the realities with which I want to inform this paper – realities grounded in experience; not based on surveys, focus groups, interviews with executives or literature searches but on real implementation experience in digital data deployment in aviation over the past 22 years. What is more, the most striking examples are based on work within the last twelve to 24 month period.

Things change – when is it really a standard?

The B747 first flew in 1970 and its tech manuals were typed on an IBM Selectric. I worked next to one of its tech writers in 1992 and they were so glad when they progressed to Mainframe based ‘two-pass’ systems to edit those manuals. Today, 42 years later, the B747-8 is delivered with iSPEC2200 SGML or .PDF or Toolbox. There was no Microsoft in 1970 and, in around 1981, the first version of Word ran on an operating system called Xenix. Imagine using Word 8.1 to try and open a Xenix based document. Had someone committed to a de-facto or de-jura standard like that, imagine the problems there would have been over the years as software evolved.

Framemaker is also a very popular authoring tool, built initially around 1985 for the Aegis OS on Apollo Computers and then for Solaris on Sun machines. Only through luck in subsequent years (its acquisition by Adobe) does it enjoy its prominent position today. Yes, today you can have Release 12 Framemaker XML editing but you can’t magically create structure where one did not exist. I mention this for those in Flight Ops who prefer this tool. When Framemaker was launched it competed unfavorably against the then market leader, Interleaf, which had been around since 1981 and used LISP in managing/enforcing structures to very large documents. At Bombardier, in 1992, we built a complex content management system (CMS) called ‘EPS’ (Electronic Publishing System) with reusable and shareable content based on Interleaf and an Oracle database. For your information, the ‘per seat’ costs of this environment was above $100K (of 1992 dollars). But I doubt whether anybody today is using Quicksilver, Interleaf’s last version after the various owners that acquired that product. So anybody with legacy Interleaf applications will be keen to get out from them. But today we need to ask, will there be an Adobe Acrobat (originally out in 1991) ‘Release 42’ by 2045 when the A350 will have been flying for 30 years? Incidentally, Adobe significantly changes the internal structures with each release – and any programming code built to work with it also has to be changed.

Delivering technology versus ‘standardization’ and ‘value adding’

When someone tells you they have an application that runs on iOS 7.0 and that they will soon have it on Windows and Android, they’re actually telling you they‘re going to re-write it, with all that entails, because a proper iOS 7 application will not use architecture that could let it work as a native Windows or Android application; and the same is true going the other way.

And saying ‘it works on a browser’ does not make it a local application on any mobile platforms. So, another vendor might say that their application works on any device that supports a browser; but using an expensive mobile platform strictly as a browser requiring continuous real time network connection is of little value and hardly makes use of the intelligence on that device. It’s much better to use a local application running with network protocols that do the necessary synchronization and updates. Rather than adopt fanatical positions about hardware boxes, it’s important to query your suppliers to determine how effectively their solution will fit with your mobile strategy as that strategy evolves to take advantage of changes and improvements in technology and products.

Other vendors will push Cloud based M&E or CMS for which there is merit, but cloud technology won’t help in remote places where the Cloud might not be so accessible. More importantly they fall short in explaining how the various in-house applications (financials, MRO, CMS, etc.) and cloud based systems will interface and how the airline or the regulator will accept the Cloud as the only source of data validation and compliance integrity. Certain architectures were built assuming abundant and freely available LAN speeds up to 1GB in moving data between servers or between server/client infrastructures. Attempting such links ‘over the Cloud’ is simply a disaster in performance and costs.

There are other server based solutions (in IETP) that are superior to, say, self-contained applications that can be written to a DVD and delivered. But then, in locations where communications are ineffective, DVD based self-contained solutions still work, while they still carry the disadvantages when it comes to synchronization and updates.

The answers are not perfectly clear but below is a favorite subject which is often presented as an ‘either-or’ solution when it should be a ‘both’ solution.

If you have followed the industry news, why has a prominent vendor who was proclaiming ‘convert iSPEC2200 to S1000D’ (and even converting S1000D to iSPEC2200!) in fact acquired another recognized and established vendor that has much superior S1000D technology and supports the ‘hybrid in parallel’ architecture?

As recently as September 2013, Boeing updated the B757 from rev17 to rev18 to include regulatory compliance tags (highly desirable for referencing compliance documents with other manuals but missing so far). However, if you had systems that were parsing the DTD as it came in and used XSLT/XSLFO transformation to create HTML and .PDF styles, they stopped working and you had to take measures to accommodate the new structure and display that structure and its change management and so on.

Some proclaim that XML is all you need to go from one environment to the other but I’d ask, what XML? Unstructured; well-formed; DTD compliant; schema based; using X-paths or based on X-forms?.. XML is made to look like a universal pipe that expands and contracts as needed but it is misleading to assume it is that way.

http://www.ataebiz.org/forum/2011_ata_e-biz_s1000d_forum/9-Transforming_iSpec2200_to_S1000D_V1.0_Mayer.pdf given in Montreal at ATA eBiz in 2011 and, if you understand it, you’ll be well on your way to understanding the complexities of transforming iSPEC2200 to S1000D. The bottom line is that it cannot be done algorithmically. SME hands-on intervention is required for some aspects of it. And it’s a one-way thing; not a round trip process. So it’s not the case that you have to have two systems: what you need is a system that can accommodate the two data streams according to their structures and deal with them accordingly, as opposed to convert each revision as they come in.

Hanging on to control of data

Now we come to the gorilla in the room; what I call the OEM Data Fortresses.

OEMs are not really interested in releasing digital data; and the reason is obvious. On the one hand they are acquiring software companies who deal with digital data; but they’re not really trying to get into the software business. They’re using the software and the digital data to provide end-to-end total services, especially for the smaller operators, because they realize that there’s not much margin in selling the airplane anymore (or selling the paper to the lessors); the income and the margin lies in controlling it over its entire maintenance life cycle. So, if they can generate one-stop shopping where users can go for all the programs, all the data that they need, including execution of maintenance and engineering services, that’s where they’re going to make their money, that’s why there is intentional controlled release of this digital data.

Consequently the OEM’s have their in-house solutions… Boeing – ToolBox; Airbus – Air@Nav; Bombardier – Navigator. So in spite of all the open standards we have today, airlines now ask of MRO software vendors: do you interface with Toolbox?.. to Air@Nav?.. to Navigator?.. to Embraer CD?.. as opposed to asking about compliance with open standards.

Last but not least, OEM’s like Boeing refuse to issue digital data collections based on the complete MSN range of aircraft in a model. Instead they issue ‘customized ranges’ for the MSNs purchased by each operator. Consequently an MRO provider often is forced to keep 7-10 versions of AMM, IPC, etc. because each is for a separate MSN range depending on the original purchaser for which it was produced and who is servicing their aircraft at this MRO. Similar challenges occur when an operator acquires some aircraft originally built for a passenger airline (say Delta) then modified for cargo; then they supplement their fleet with aircraft originally acquired by another passenger carrier (say Qantas). You can’t even imagine what the different ‘digital data collections’ look like and the variances in effectivity models, COC/STC tagging, and revision tagging. But it is all ‘digital data’.

Now superimpose on that the OEM’s view of MPD and TaskCard model (with the tags allocated for items such as Interval) and how the classic ‘MRO System’ used to manage the interval(s) per their phased / allocated packages …. But it is all ‘digital data’…..

Coming in Part 2