Why you should insist your MRO Software is standards compliant

Author: Kenneth N. Jones: Director of Electronic Data Standards, ATA e-Business Program

Readers will be aware of the plethora of data that informs today’s workplace and how big data can bring advantages, if it is used correctly. We also know about tablets, the increasing mobilization of information and its added benefits. But I want to address a different set of problems and some ways to mitigate those problems.

A changing market

The market is changing and it is not just technology driven. Previously, most development was carried out in-house. OEMs did their own development and the standards that did exist were related to information going from the manufacturer to the operator. There weren’t the huge number of third-party companies that there are today and information was largely exchanged on a lot of paper or its equivalent (microfilm, microfiche, etc.).

Today, there is a lot more maintenance handled by different third-party specialists. There are still a lot of disparate systems but new systems are being introduced and airlines are merging with these different systems. Even when the new systems arrive, they don’t necessarily cover everything the airline, operator or MRO needs. Some airlines are adopting a ‘big bang’ approach, putting everything on a single ERP system, while others are taking the ‘best of breed’ approach using different software packages. As we make changes to IT systems, safety is always our highest priority, so changes are made very carefully.

With rapidly changing operator environments, there is a real need to manage change. As new systems meet and have to work with old systems, there is a growing need to integrate. A common issue for many companies is how to integrate their various systems. Whether due to mergers, bringing on new systems, or simply the desire to have the most recent and updated information available on all platforms, organizations need integration capabilities.

The management of sharing

And, with the changing environment, there are more partners who need to share information. Whether getting maintenance information back from suppliers, sharing operational reliability and safety information, or whatever the case, there’s a need for ‘controlled’ sharing. Each party needs to know that they’ll be able to easily enter shared information and will need to confirm issues such as identity, whether information has been changed since it was created, and other security related issues.

Big data is also a big subject today, but with more information there also more need to distill it and work out ways to get to it. And, of course, solutions must be cost effective.

Standards can’t solve all problems or answer all questions but there are some problems with which they might be able to help.

ATA e-Business Program

Figure 1

Figure 2

In answering the question, “what are the business cases for standards?” here are a few business cases where the implementation of industry standards can improve efficiency, time and/or costs.

To improve turn-around times, identify non-value added administrative times within the process. Standards help increase quality and reduce costs with capabilities such as RFID, electronic Authorized Release Certificates, advanced shipping information, etc.

To implement a new Electronic Technical Log onboard it is important to know how it can interface with the operator’s maintenance system and whether data will have to be manually entered or if the systems will be able communicate.

There’s also the issue of records management, as leasing becomes increasingly prevalent. It is a big cost and a lot of work for lessor audits or when transferring aircraft records. People will want to know how to define what they are doing and how that compares with competitors.

Other business cases might include investing in portable maintenance tools to improve maintenance efficiency with RFID and electronic technical data or the ability for reliability data exchange and metrics to benchmark reliability against others in the industry. And, of course, it should all be done with a high level of security.

The Standards

Let’s look a little more closely at the standards starting with Spec 2000, a 40 year old standard for purchase orders. It is a proprietary format that requires both sender and recipient to know the format/rules for each of the fields, but it has been used successfully to order parts for many years and is still used by many companies because it works well. Like many information exchange groups, the ATA e-Business Program went to XML later on, delivering similar information but using XML tags. Another area of Spec 2000 is parts identity – the standards help to identify parts using the serial number in a standardized and machine readable manner. Readers may have heard of RFID in which information can be encoded. Spec 2000 defines how terms are used; even if the way they’re identified differs from technology to technology (e.g. within an RFID tag vs. a bar code, vs. an EDI message). In every case, the data field can be defined in an understandable format – for example, a manufacturer’s part number won’t be confused with the airline part number.

Another area of improvement is in receiving. Today, typically when the part arrives in the business, packages are opened, parts inspected, paperwork reviewed, serial numbers checked, data is entered in the operator’s system, etc. All of this involves time-consuming manual steps. Using the new Electronic Authorized Release Certificate standard in place of paper 8130-3/EASA Form 1, allows companies with more tools to detect fraud, routine errors, and do so in an automated manner, even before the ordered part arrives.

All of that’s good for processing, for databases and for archiving, and it allows buyers to pre-process some information. But, at the end of the day, there’s still the quality function to be satisfied, so what else can you do? You can apply a style sheet to the XML to see the form in a similar format to that which has always been used, which streamlines the use by the quality inspectors. Standards help to improve efficiency, cut turn-around times, get things out quickly to where they’re needed to be used by resolving any issues even before the item has left the seller’s premises.

We also referred to logbooks and a lot of companies are considering putting a logbook in the cockpit. There are lots of good products doing different things so the question is how to standardize something without standardizing the look and feel of different products in a competitive environment that’s changing to meet customer needs.

Most logbook systems have information about the flight, maintenance information about what faults have arisen and the facility to later confirm that the fault has been dealt with. Some operators use the logbook to store fuelling and servicing records. So we have defined an XML structure to depict all of those things and all of the typical information that would be associated with them. Users will want to get logbook information to the maintenance system, to make sure that deferrals are addressed and don’t want to have people re-inputting data. That leaves two choices: a custom approach; take information and get your developers to find ways of getting it into your systems; or use the same company for the logbook as for the maintenance system.

The ATA e-Business Program e-Logbook standard allow users to make the best of both worlds; to get the best logbook product that meets their needs and still electronically communicate with the maintenance system. That’s how standards work, focusing on standard common information objects, defined in such a way and tagged in such a way that they can be understood by consuming systems. Also, we allow a standardized way to extend the specification. Everybody wants their own special things and, as long as the receiving system knows that’s an extension, it can be handled in a custom manner or ignored. That’s an example of why a software provider should consider being industry compliant and a buyer of logbook products should consider that as a feature.

RFID

Readers will have heard about RFID, and there are a few different use cases that we have discussed in our group. The easy one to envision is that users don’t have to take off panels to check the contents of the cockpit and cabin. That’s fairly easy but there are cases that also envision portable information that goes with the part.

We’ve already looked at how important it is to share information, but what information should be shared? The high memory RFID specification considered by some companies puts key information about the part’s life onto the part itself so it isn’t necessary to be connected or have access to the system to check status. Standards applied to the information held on the RFID will help it to be compatible with other systems, whether the information is originally from the OEM in the permanent section or added by the airline into a re-writable section of the RFID (including where mechanics can make notes on the part) and, importantly, a record of what has been done to the part. RFID tags are not yet widespread and, as yet, RF as a method of information exchange is not superfast so, even though there’s a substantial amount of information associated with certain major components, storing all of it on the part isn’t yet a practical approach. But, the key events in a part’s life (e.g. when was it overhauled, when was it pulled off) can be stored on the part.

• Aircraft Status / Out of Service– has the aircraft been pulled out of service or has ownership changed?
• Hours, landings and cycles – rudimentary data about what’s happened to the aircraft during the month.
• Delays and cancellations, and whether they were for maintenance reasons.
• Logbook records – faults, write-ups, deferrals and fixes.
• LRU removals – which parts were removed, how many hours were on the aircraft when the parts were removed and what parts were correspondingly installed? It can help build a picture of the aircraft’s lifecycle and a record of parts being removed too often.
• Shop findings – was the reason for removal confirmed and what was done to the part in the shop.
• Scheduled maintenance – the biggest and most recent reliability dataset is feedback data as to what was found during scheduled maintenance; which tasks and jobs were done and what were the non-routine findings.
• Which Service Bulletin and Mods were installed?

Although many of these were developed from a reliability perspective, there’s a lot of possible re-use that we’re looking at, such as using similar data sets for maintenance history records.

Managing and mitigating risk with digital data

The key issue with electronic data is mitigating risks. The traditional risk with digital data is how can it be changed or data altered, even accidentally; who produced the data; what system, which person; who signed it and what confidence is there that that was really who signed. ? Also, electronic data can be easily digitally copied and reproduced. Those are typical risks associated with digital data.

Information exchange is often from one organization to another. So, what is the digital security risk mitigation path? To confirm the data hasn’t been changed or altered; to understand for sure where it came from and, if necessary, who signed and approved it and, we ultimately want the right information getting to the right people in the right place.

Public Key Infrastructure is a commonly used methodology using private and public keys that are widely used in finance. One of the big factors is ensuring signatures, so we have digital certificates used for digital signatures. Spec 42 has defined different policies that organizations can employ in terms of how strong the digital certificates used are. If you have you checked someone’s identification, have seen them in person, and have looked at their qualifications, the confidence in the digital certificates can be higher. There’s a variety of levels. So, if you’re implementing digital signatures using certificates and then you want to change to some other trading partner, you still need confidence with the signatures of the new company. As long as they follow the right policies as defined in Spec 42, confidence is raised. A lot of the focus of the specification was on what policies you need employ.

Operators are already very good about identity management because of the access issues with aircraft, line maintenance and airports. A lot of the cost in setting up digital certificate policies is really an HR infrastructure cost and so from an operator perspective that cost already exists in just getting badges.

For smaller companies though, there are other options, including third-party companies able to do audits, meet face-to-face if that is the need, look at licences and give clients various levels of certificates. There is U.S. Federal Bridge, a government-to-government version of certificate policy exchange and Certipath, an industry defined bridge that allows, for example an audit to be done to say, ‘yes, Boeing, Airbus… we can exchange information and trust each other’s digital certificates.’

The ATA e-Business Program is working with IATA because, with more electronic information out there, it is becoming increasingly important to have confidence in the data; so IATA’s working on an industry-wide initiative for companies to implement compliant digital certificates. Additionally, we are looking into non-PKI based digital security for business cases where that may be appropriate.

Regulation

We also hear a lot about regulatory issues. Certainly in some parts of the world there are bigger barriers to get acceptance of digital signatures but EASA, FAA and some of the equivalent authorities have already accepted digital signatures based on digital certificates in certain areas.

Putting it all together

Figure 3

Figure 4

Figure 5

Exchanging reliability information – whether an MRO sends a shop findings report in Spec 2000 format or for participating with the big airframe makers and their reliability analysis programs, using the standard simplifies for all. Even for internal use, collecting and managing the reliability data in an industry standard format can add benefits by helping companies see all the areas of reliability data collection that they may not have previously considered.

But in all this, what is standardized? Airlines have been maintaining reliability programs for years, of course; what takes time and effort to standardize is getting information with a little more intelligence than just some text field as to what happened. For example, analysing and agreeing with industry partners on the codification to use to identify parts in a machine readable and understandable method… ‘why was a part removed or what were the findings?’ It’s more than just writing text; it’s tagging it.

We’ve also covered electronic aircraft records, an existing project that we’re working on. In today’s environment, there are high manual review costs associated with aircraft transfer due to the records being moved today in paper (or scanned paper). With thousands of aircraft being transferred annually, these costs add up. By moving to a more fully electronic method of transferring the records, operators and leasing companies have a big opportunity to increase efficiency.

With the long life-cycle of aircraft, the number of electronic records that are available for a 25 year old aircraft is probably lower than the new aircraft where information is highly electronic. So ATA e-Business Program is developing a hybrid path. The group has so far identified information that’s typically maintained in databases, where there’s a lot of it and where it’s probably going to need to go into a consuming system. We’ve identified the top six sets of information exchange that typically occur at an aircraft transfer – the Airworthiness Directive status, the repair damage charts, service bulletin / modifications (which ones have been implemented), the last maintenance done, which maintenance is in work, next due and, of course, the tracked items (LLPs, HT items) – the exact information about every component on that aircraft and its status. We’ve also defined an electronic ‘crate’ that has metadata about other possible data sets.

As far as possible future standards are concerned, we have integration projects about using RFID in the logistics process as most of our other RFID cases have been on the maintenance side.

• Next generation supply chain / order administration.
• Electronic Aircraft Transfer Records.
  • Electronic Aircraft Status Record.
  • Electronic AD Status.
  • Electronic Repair / Damage Chart.
  • Service Bulletin / Modification Status.
  • Last Done / MIP / Next Due Record.
  • HT / LLP.
• Integration for logistics / RFID for logistics.
• Electronic job / task card sign off.