Ken Jones, Director Electronic Data Standards, ATA e-Business Program explains how implementation of industry standards can improve efficiency and reduce costs

The ATA Business Program has been managing standards since the ATA numbering was developed back in the 1950s but it’s not just an airline program; there are 120 companies participating across the range of manufacturers, software providers, operators, MROs, lessors and so on. Since our prime goal is exchanging information across various business functions it’s important to have all stakeholders engaged.

The issues on which we’re trying to focus might be familiar to readers, with topics such as paper and PDF moving to electronic being exactly the issues on which ATA is working. In spite of many companies implementing maintenance IT systems, particularly when moving from one company’s system to another’s, when, for example, an airline decides to use sub-contracted maintenance, there tend to still be PDFs: maybe there’s not physical paper but it’s effectively paper. Our goal at ATA is to create actual data standards with which systems can make decisions and about which they can do things. We seek to cut costs, improve efficiency, increase quality and all those mission objectives with which readers are familiar.

Figure 1 shows some of the main stakeholders and the information exchanges that are the focuses of ATA e-business Program (ATA) standards. As you can see, it covers everything from the manufacturer to the operator including the technical information, setting out the maintenance program and procedures, parts catalogs and so on. And then, after delivery, the feedback of information such as reliability or the exchange of information on purchasing parts. It also includes operators exchanging information with MROs and, more recently, even exchanging information with lessors or with the next operator of an aircraft. So there’s actually quite a wide range of information exchange system to system; some of them are internal systems such as electronic log books with operators needing to transfer information from a log book system by one provider to a maintenance system by a different provider. ATA sets out to develop generic industry standards to facilitate that kind of operation.

Some of the topics on which I’m going to focus in this article include the MRO IT side, especially some new standards that the ATA is working on and have recently published. Also, we’ll take just a quick look at the different specifications; and one point that I’m going to emphasize is that, when you are implementing an MRO IT system, talk to the MRO IT provider about what standards they support and how they support those standards: be specific; there are some general specification numbers such as S1000D, iSPEC2200 focusing on technical information exchanged from the manufacturer, and then, after the fact, there are a number of SPEC2000 standards focused on ongoing business information exchange. Figure 2 illustrates the range of standards specified by ATA. Spec 2000 Procurement Gen 2.0, Spec 2000 Electronic Work Package have recently been released, and Spec 2400 Allowable Configuration release is imminent.

Potential buyers of IT don’t just want to ask whether the IT provider supports, say, SPEC2000; they’ll need to drill down. If they’re interested in a product to support an electronic log book exchange with an MRO IT system, they should get their MRO IT vendor to show how they have implemented that, if at all.

So, let’s look at a couple of use cases.

Preparation of maintenance for outsourcing

Instead of sending a big stack of PDFs with the tasks, the work packages and work orders that the MRO then has to re-input to their own IT system, one of the issues on which ATA is focused is exchanging that information electronically. If the MRO has an IT system and it’s different from the customer’s IT system, neither party wants to pay for a custom integration nor bear the cost of the inefficiency of all of the re-input and re-entry. So, as more and more companies are tracking their maintenance in their internal IT system, this is just the next phase to allow them to get the large MROs involved in the process. However, rather than give them passwords and have them log in to the operator’s IT system, which generates a set of issues in itself, if both parties support the ATA Data Exchange Standard, work packages and work orders can be sent out electronically and the accomplishment data can similarly be sent back electronically.

The techlog

The airline might have a logbook that they bought from the airframe manufacturer or a third party in an endeavor to get a ‘best of breed’ product; but they still need that logbook to talk with their maintenance IT system: they don’t necessarily have to be from the same IT provider. So the logbook standards don’t focus on the look and feel, that’s proprietary, but on the things that all logbook systems do such as tracking a fault and information about the fault, tracking closing maintenance actions, tracking deferrals and tying them to various flights: some might track other information such as fuel loads or servicing.

ATA has brought a group of these various stakeholders together to look at typical existing practices, existing products or even paper logbooks; the group maps all the fields and tries to come up with a set of requirements that will facilitate the exchange.

Procurement

SPEC2000 procurement has been around for nearly fifty years, having been developed in the days when IT transmission costs were high which meant that it was compact and didn’t do some things. ATA recently published a new procurement specification that will allow mapping to better reflect typical ways of doing business today.

Aircraft transition

This covers aircraft moving into and out of service, returns to lessors, transfers to new operators, etc. Last year, ATA published Spec 2500, a major specification with data sets to support those processes. When I say ‘electronically transferring aircraft’ it’s not just about tagging PDFs, although that’s a big part of it; but it’s about AD Status, parts tracking, LLPs (Life Limited Parts), hard time components, the maintenance program, the ‘last on / next due’… All of that kind of information, if you’re implementing Spec 2500 standards, will be in an IT format and in such a way that the recipient can load it into their systems, can start their internal clocks and bridge to their maintenance programs with a lot less need for re-entry and human intervention. The idea of reducing manual data entry, allowing for systematic quality checking, allowing for electronic linking to the original maintenance documentation, all help cut the time and labor involved in an aircraft transition. Major lessors were a big part of this project.

e-BUSINESS STANDARD

So just to be clear, the focus of an ATA e-Business standard is to identify whatever fields facilitate an individual business process; the ones that everyone always needs, the ones that are needed under certain conditions or the ones that are just optional, i.e. some systems and some companies might want some fields while others might not want them. ATA specifies all of that and then focuses on the business processes around that exchange. Finally, it’s the technical formats. Most recent information exchange uses XML because it tends to be easier for systems to digest but there are others such as RFID; encoding data on a tag is different from just putting a load of XML out there. This article is not about XML but there are technical reasons why that has become a preferred format in recent years.

Figures 3.1, 3.2 and 3.3 focus on business exchange. These are meant to be typical relationships between the data flows and ATA e-Business standards.

Figure 3.1 illustrates component repair. For example, when the part is removed, it might be tracked in the logbook, sent to the internal shop to determine whether it can go out after repair, in which case, you might use a SPEC2000 format to process a repair order, then send the part out. There might be bar-coding or RFID tagging involved so the serial numbers and part numbers can be tied back to the system to reduce the information exchange; when the MRO repairs it and sends it back again you’d use the RFID or the shipping labels to electronically receive the part, record the time and, perhaps, generate an electronic authorized release certificate, a Form 1 or 8130-3.There are different specifications focusing on various pieces of that kind of exchange.

Another area already mentioned is the electronic logbook where the fault might occur in the air and there be information exchanged with the ground system (figure 3.2): the electronic logbook specification can be used. When the aircraft arrives, some of the specs covered above could be used to track parts removal and the new parts. All that can be logged in to the IT system; the user might even have used an older specification for provisioning data to help determine which components to keep where in their inventory system.

One further area relates to chapter 11 reliability data (figure 3.3) focused on information exchange; there’s a lot of it going on to support reliability programs. So, a typical large operator’s reliability program is going to involve collecting data from any number of areas; it’ll be, for example, faults, log books, the flight system – what flights are scheduled, what kind of delays and cancellations occurred – and then tracking various component issues into the shop, coming back with ‘was the reason for removal confirmed, was it a ‘no fault found’?’ Then there’s maintenance as well with the scheduled maintenance; what were the findings, how many findings were there, can that kind of data be used to increase intervals and things like that? So, again, chapter 11 uses formats to support the exchange of that kind of information in an industry consistent manner. This is not about proprietary issues; how the data is analyzed, how partners work with each other, which data is exchanged, that is always up to the individual companies and trading partners: ATA’s focus is on what kind of formats are used for the exchange, detailed definitions of those fields and how users can benefit from implementing it.

The reliability working group is interesting because, while it might at first seem just a group of fields to automate the exchange, of course, when you’re sitting in the room over the years and focusing on all the different data you can collect, other benefits become apparent such as: does the reliability system collect those fields, if not, why not? Maybe there’s benefit to be gained. So there are other benefits than just the information exchange from implementing the standards.

I’ve already mentioned the next generation supply chain and order administration project looking to deliver multi-line Purchase Orders, better shipment information, and more control by buyer as to what seller can change. So I won’t go over that ground again. Below are just a few more details of some of the key projects mentioned.

Aircraft Transfer records

ATA brought together in one room a couple of the largest lessors in the world along with some manufacturers and operators and software providers, and we looked at the ICAO and IATA lease return lists, which have, typically, 120-130 data sets that are exchanged. The group highlighted which ones lend themselves to a tagged electronic format. We came up with six data sets that actually support many more than six requirements, and we devised electronic versions:

• Electronic aircraft or engine status.
• Electronic Airworthiness Directive (AD) status – everybody tracks these and has to prove that they are in compliance and the electronic version can be applied to an aircraft, to an engine or even to major components.
• Electronic repair or damage status – a lessor or recipient taking delivery is going to walk around the aircraft to assure themselves that any noticeable damage has been addressed and how; but even with major repairs that aren’t visible, this format allows for the exchange of all of the documentation such as ‘what was the repair?’ ‘was it permanent? and, if not, what are the re-inspection intervals and when should a permanent repair be expected?
• Electronic Service Bulletin (SB) and Modification status, i.e. what SBs or modifications have been done.
• Electronic ‘Last Done/ Next Due Maintenance Status’, what is the current status of every item in the entire maintenance program whether it’s airline customizable or a typical MPD (Maintenance Planning Document) manufacturer item; when was it last done, what is the current interval, when is it expected next to be due? Of course the new operator of the aircraft will have their own maintenance program but the fact that this data is available electronically makes the bridge between systems much more efficient.
• Installed Component Status, Which tracks Time Controlled Components (TCC) Life Limited Parts (LLPs) and any other tracked component… This records serial number, all of the appropriate hours / cycles data, and relevant information such as last overhaul, time remaining, etc.,  all in an industry standardized manner. This particular status data is also useful for the airframe and engine manufacturers at initial delivery, i.e. if the data is going to be tracked in a certain way the user will want to get it in the door when they first receive an aircraft or engine so that serial numbers are ready, zero time hours and cycles are ready to load into the operator’s and/or MRO’s maintenance system electronically.

Configuration management

Typically the IPC (Illustrated Parts Catalog) or IPD (Illustrated Parts Data) is a configuration management tool for the allowable configuration. But what users found was that that is really geared towards the line maintenance technician, not a system to system comparison. So we’re developing a new specification for the allowable configuration to support a user’s system to compare the current ‘as flying’ ‘as maintained’ configuration with an electronic allowable configuration; not so much to support the line maintenance to replace and install – the IPC or IPD are perfectly good for that – but to do a system-wide comparison to identify any outliers that might need some additional research.

Warranty update

We’ve updated an Spec 2000 Chapter 14, an electronic warranty claim specification in 2018. The objective is to facilitate automated warranty claim submittals.

Authorized Release Certificate

Spec 2000 Chapter 16, which is an XML based electronic format approved by FAA, EASA, Transport Canada and others for exchange of electronic 8130-3 or Form 1 data in an industry standard format, is expected to be updated by mid-summer..

Engine reliability data exchange

The ATA e-Business Program reliability group is focusing on engine reliability in particular; what is unique about engines and what fields need to be tracked to better support the engine reliability analysis.

Regulatory acceptance

A common question about some ATA standards is ‘will the regulators accept it?’ In general, across the board, the answer is ‘yes’ but, of course, there are caveats; it’s necessary to have a local maintenance program approved and, if the plan is to change from one methodology to an electronic version, there are going to have to be approvals for the change of the maintenance program. But generally there’s guidance out there, at least within some of the major regulatory authorities, to support electronic signature and digital signature, to support electronic record keeping and to use some of these kinds of tools.

There’s lots of change going on and there’s huge amounts of data flowing so our goal within the standards community is how to improve efficiency. This can be implemented piece by piece, it’s not an all or nothing scenario: any one of the specifications referred to here could be implemented alone to achieve an incremental improvement. All in all, I’d encourage readers’ participation in the ongoing development of the standards and adoption of the standards.

With over 30 years of aviation industry experience, Ken Jones joined A4A’s ATA e-Business Program in 2002 and is currently Director of Electronic Data Standards managing cross-industry electronic data exchange standards development. Previously, he served as Director of Data & Integration at Cordiem, a collaborative B2B aviation industry solutions provider, and spent over 18 years at Continental DataGraphics, a Boeing company. He has both a BA in Economics and a Master’s in Business Administration from UCLA.

ATA e-Business Program

The ATA e-Business Program is where the global commercial aviation industry collaborates to create standards for information exchange to support engineering, maintenance, materiel management and flight operations. For over fifty years, the commercial aviation industry has worked together through a joint international effort to establish specifications for improving business processes and information exchange. The over 120 members include airlines, lessors, aerospace manufacturers, distributors, suppliers, repair agencies, software providers and consultants

Airlines for America (A4A), formerly the Air Transport Association (ATA), was the first and remains the only trade organization of the leading U.S. passenger and cargo carriers. The organization works collaboratively with airlines, labor, Congress and the Administration and other groups to improve air travel for everyone. It also vigorously advocates on behalf of the American airline industry as a model of safety, customer service and environmental responsibility and as the indispensable network that drives our nation’s economy and global competitiveness.