PDF documents comprise the majority of service and parts information, yet it is difficult for IT systems to extract data from a PDF file. This limitation negatively impacts parts and maintenance operations for all industries; this post addresses the impact on aviation, but in future posts we’ll look at other industries beyond aviation.

The Role of Task Cards

Task cards (or “job cards”) are documents containing detailed instructions that guide aviation technicians as they perform maintenance on airframes, engines and components. Task cards are critical to ensuring fast, accurate maintenance and regulatory compliance. Task cards may be physical (paper) or virtual (electronic) documents, depending on the business process of the airline or third-party maintenance shop (MRO). Each task card contains the information (parts, procedures, tools, skills, etc.) necessary to work on a specific piece of equipment (by tail-number/serial-number) and must be signed-off when the job is complete.

PDF Maintenance Documents

The parts and procedures defined on task cards are based on OEM maintenance manuals but also include airline best practices, in the form of customer originated changes (COCs) or customer supplements. The ATA (Air Transport Association) recommends that these OEM maintenance manuals use SGML or XML as the data format; however about seventy percent of the manuals currently in use are PDF. (Component maintenance manuals, which make up a high percentage of the serviceable items on an aircraft, are provided almost entirely in PDF format.) This is a problem for maintenance organizations because SGML and XML are highly-structured formats that simplify data extraction; however, the lack of structure in PDF makes it difficult to convert the text into task cards.

Another issue is that OEMs update aircraft, engine and component manuals on a regular basis (typically quarterly), and often specify different parts and procedures for individual aircraft tail-numbers (or equipment serial-numbers). To ensure accuracy, each new OEM revision must be compared to previous maintenance manuals and combined with the relevant COCs and supplements before being converted into updated task cards. With so much PDF data being modified so frequently, airlines and MROs have difficulty synchronizing technical content for maintenance planning and execution.

PDF Limitations

Aviation maintenance manuals and parts catalogs are broken down into tasks/subtasks and assemblies/parts, which are readily understood by engineers and technicians. Regardless of the data format used for this information (SGML, XML, PDF, etc.), end-users will see little difference. It is when a software system (ERP, EAM, MRO, etc.) tries to utilize this data that the limitations of PDF become clear.

Maintenance manuals that use SGML or XML employ special identifiers that call out tasks, subtasks, parts and other relevant information. These data elements (TASK, SUBTASK, PNR, etc.) allow text within SGML/XML files to be recognized and utilized by other business and IT systems. PDF, on the other hand, is a linear stream of text without any content identifiers or embedded data elements (only formatting rules and a few metadata fields). As a result, for an IT system to extract data from a PDF file it must first search the document and the results must be interpreted to identify the proper information. This is a slow, error-prone process that eliminates the benefits of automation. To effectively use PDF, maintenance organizations are forced to cut-and-paste the necessary data from PDF into whatever planning and inventory systems they are using. To make PDF useful for maintenance automation, the SGML/XML data elements that are missing from PDF must be “inserted” in a way that allows it to act more like the other, richer data formats. Only then can the maintenance organization realize the potential of fully integrated IT systems.

Overcoming PDF Limitations

Enigma has the ability to overcome the limitations of PDF documents, processing them in a way that enables this relatively flat file format to act almost like SGML and XML data. Enigma’s tools enrich PDF files, allowing them to be leveraged by maintenance planning and execution processes, like automatic generation of task cards. With PDF data comprising well over half of the airframe, engine and component documentation, airlines and MROs are finding Enigma’s PDF tools to be critically important to improving maintenance productivity, accuracy and compliance.

To learn more about how Enigma enhances PDF, download our fact sheet, "Putting PDF to Work – Making PDF Data Interactive."

IT systems can help companies respond to maintenance emergencies. To highlight my point I’m using the situation at Southwest Airlines (SWA) as, in the wake of Flight 812, they work to address the problem of aluminum fuselage skin fatigue on their Boeing 737-300 aircraft. While I don’t know the details of how SWA and Boeing are responding to this situation, I imagine a lot of people are working long hours looking for ways to preserve safety and minimize the economic impact.

According to the National Transportation Safety Board (NTSB) the aircraft in question was in compliance with maintenance requirements, so this is not something that SWA did wrong. In fact, Boeing engineers recommended the 737 fuselage be inspected once every 60,000 take-off and landing cycles. Since SWA 737s average 6 flights per day that means an inspection every 10,000 days, or about once every 27 years. (The aircraft that suffered skin failure had only 39,000 cycles on it.) Boeing recently issued a service bulletin (SB) to change the inspection limit to 30,000 cycles (13.5 years). However the Federal Aviation Administration (FAA) has gone further, issuing an emergency airworthiness directive (AD) mandating that older 737s be inspected every 500 cycles, at least until the cause of the problem is known. For SWA, that means every 83 days almost 80 aircraft must be taken out of service to undergo electromagnetic inspection of the fuselage. For a company that runs a lean organization, changing the maintenance interval on an essential piece of equipment from once every 27 years to once every 83 days is a really big deal.

This raises a question for every owner/operator of capital equipment, “Does your IT system help you respond to maintenance emergencies?” Not every service bulletin or maintenance revision represents an emergency. However, real emergencies are unpredictable and it’s hard to know which pieces of information will be needed to resolve one. So perhaps a better question would be, “Is the information in your IT system accurate and complete?”  Since you don’t know when the next emergency is coming, and you don’t know what information will be required, it’s important that reliable maintenance and parts data is always available.

The first challenge to maintaining accurate and complete service and parts data is that different suppliers provide technical content in different formats. This makes it difficult for information to flow seamlessly across various IT systems. For maintenance departments, the time and cost required to standardize document types and data formats (e.g. S1000D, ATA 2200, PDF, etc.) can be substantial. However, during a maintenance emergency these costs are irrelevant as planners, engineers and mechanics need immediate access to all applicable parts and service information to fix the problem. In the case of an airline, the required data may come from Boeing, Airbus or any one of over 300 suppliers. (The situation is similar in other industries.) Since safety carries such high implications (both moral and economic) finding a way to resolve the issue of multiple formats, while providing complete and accurate service and parts information, is imperative.

The second challenge to maintaining accurate and complete service and parts data is the rate at which it changes. During a recent asset management conference I took an informal poll and found that maintenance planners believe about half the information in their maintenance planning and inventory systems is out-of-date. That’s not surprising because the work involved to cull through all the technical documentation and update the IT systems can be overwhelming. (Anyone who works with mission-critical databases will tell you that keeping them accurate can be a full-time job.) Technical information changes so frequently that many companies simply wait until the next scheduled maintenance, or until something breaks, to update the maintenance and parts data. (Even then, information rarely gets updated in all databases.) However, this approach leaves a company ill-prepared to meet the demands of an emergency.

Since regularly managing multiple data formats and updating multiple databases appears to be cost-prohibitive, but the cost of an emergency appears to be even higher, what should a company do? The answer is to automate. New and revised information needs to be automatically extracted from updated documentation (maintenance manuals, parts catalogs, etc.) and loaded into the various databases. This activity can be automated, occurring whenever documents are received from the OEM/supplier. Enigma’s InService Revision Manager processes updates, in multiple formats and at any frequency, to keep IT systems accurate and complete, which provides value far beyond the aviation industry.

If you have a maintenance or parts database that never seems to be up-to-date, you may be closer to a problem than you realize. Anyone that’s involved in the day-to-day scramble of equipment maintenance, or has lived through the turmoil of an emergency, knows that reliable information is critical to making good decisions. Enigma has the technology to ensure you’re prepared.

In my previous post (The New Flying Fortress) I suggested that the way Boeing and Airbus deliver technical data is unsuitable for modern day maintenance systems. This post describes how OEM data formats limit the airlines, forcing them to treat maintenance planning (ERP/MRO) and maintenance execution as separate worlds. The difference is like getting a vinyl record album when all you own is an iPod.

Part of the problem with OEM data is historic; the maintenance manuals for many older fleets were not created according to AMTOSS standards. But the main problem is that OEMs designed their systems as a standalone/closed environment.

How can you tell if a technical document is standalone (i.e. for reference only)?

PDF format — When OEMs deliver manuals in PDF, they're telling airlines they don't care about business productivity. PDF  is of limited use for integration, automation or e-commerce.  In fact, PDF is designed to behave, quite literally, like electronic paper.

1.  
   1. Scanned PDF displays text as a raster image, like a picture, so that a person can read it but a computer cannot. Optical character recognition (OCR) may convert the raster to computer text but conversion accuracy raises valid concerns for highly regulated industries like aviation and there is very little automation possible.
   2. Standard PDF allows cut/paste and search/extract of specific text strings, allowing some level of automation, but the result will be a customized solution that must be closely monitored and maintained.

For example: Most airlines receive Boeing MPD (maintenance planning document) in PDF format.  However, they create this document using sophisticated tools and could easily publish it in a more usable format such as SGML, XML or MS-Excel spread sheets (like Airbus does).

Structure, layout and presentation — OEMs often design their technical content for printed paper, not for computer displays. Such an approach means that the maintenance information can be easily understood by mechanics but presents a greater challenge for computer systems. On paper it may look good, but a deeper look at the data reveals:

1. Inconsistency with the ATA spec—yet it still prints properly
2. Missing data tags—important information that isn't properly marked
3. Fragmentation—related information marked as separate topics

OEM maintenance data that comes in PDF format or that has inconsistent design cannot be easily linked to the airline's ERP system. Without this integration, maintenance accuracy, efficiency and costs, will suffer.

As an example, inventory management and forecasting is critical to an airline. One of the most important features of ERP/MRO is the management of parts, tools, equipment and resources. In the ERP system airlines need to have:  master configuration, parts list, alternative items and important part attributes such as position, symmetry, interchangeability, priority and serialization.

Having the illustrated parts catalog (IPC) as a paper document may be handy when standing next to the aircraft, but it doesn't help much when planning maintenance and inventory.  What is really important is to know the correct parts beforehand and to understand which parts can be used in each location. In that sense, even if the OEM's IPC is delivered in SGML/XML (not PDF) it is still for reference only. Here are a few examples of the problem:

1. Alternative item group (AIG)—Alternate parts can be inferred from the documentation, but it is not provided in the actual part data. Explicit references to alternate parts are sometimes included, other times they're only mentioned within the text, or they may only appear in the PNR (the part index section of the IPC).
2. Interchangeability information—In this case Boeing claims to have adopted the Airbus attribute, but they're not using it. It appears in the document type definition (DTD), that specifies how computers should interpret various tags, but it has never been added to the data itself. Airbus is slightly better, but still this information is often missing. One might assume that the master configuration interchangeability is always one-way, but when you get to the unit configuration it is hard to tell.
3. Position, symmetry, priority—All behave in the same manner.

When airlines request the original structured information they can get it...sometimes. (Maybe if they're a really big customer.) But the IPC is an example of a larger problem of data quality and consistency that holds true across all the maintenance manuals. In an industry that operates some of the world's most sophisticated machines, and has some of the highest safety concerns, the documentation strategy of Boeing and Airbus is sending the cost of maintenance into the stratosphere.

Will the OEMs ever provide data in a format that ties into the airline's MRO/ERP and improves maintenance and planning? Or will they try and force airlines to use proprietary applications that don't?  Today, mechanics are getting aircraft information off the equivalent of a record player, when what they really need is an iPod.

Deciding what to do when an OEM changes the maintenance procedures is a tremendous burden for many airlines. For most MRO modifications, choosing whether to adopt the new procedures is left up to the airline.

The industry hoped that by implementing XML/SGML documentation standards, smarter change management systems would emerge. And, with varying degrees of success, they have. (I’ve discussed this in a previous blog post, “Change Management for Aviation Data”.) But a lot of airline and OEM documentation exists in other formats, with PDF representing the largest share of this content. Unfortunately, PDF makes automated reconciliation more difficult than with XML. However, we find that with just a tiny bit of planning (and some smart software) there is no reason for PDF content to cause you trouble.

Many purists are quick to react to PDF content with condescending ‘legacy system’ labels. The normal response seems to be, “You’ve got PDF data? Too bad. You’ll have to deal with it manually until you replace the entire system with XML content.” As a software engineer, I understand the desire to deal with only one type of data, in a clean, structured format. But this idealism cannot withstand the realities of today’s industries, especially for airlines where the lifecycle of the equipment, and therefore the maintenance documentation, is very long.

Before describing how to implement change management on PDF content, let’s first recall the reasons change management is required: Airlines often modify the OEM maintenance manual to incorporate best practices, accomodate special needs, or include customized parts information. As a result, when an OEM revises the manual, airline personnel must:

1. Identify all the changes/conflicts between the OEM version and their own
2. Decide if the airline-generated content is still relevant in light of the OEM update
3. Choose whether to accept, reject, or edit the new OEM content
4. Then, and only then, distribute the updated airline content as the new version

In the days of paper-only distribution, change reconciliation was the #1 cause of delays in adopting new content, sometimes requiring more than 12 months to complete. Combining structured content, like XML, with Enigma 3C® Revision Manager has cut revision management from months to hours, by automatically incorporating changes wherever appropriate, and providing side-by-side comparisons for all potential conflicts. Conflict identification can occur at any level of granularity. (I.e., often a large task is split into many subtasks, and an OEM change to subtask 1 does not necessarily conflict with airline customizations on subtask 4.) When presenting the side-by-side comparison, areas of text that require review are highlighted and color-coded for fast comprehension and decision making.

Enigma’s intelligent revision management can also be applied to PDF content, allowing for granular comparison and update of PDF-based documentation. This means that PDF documents don’t need to be replaced wholesale; rather, specific PDF pages within larger documents can be reviewed and approved individually. When displaying conflicts, pages are still displayed side-by-side, with color-coded highlighting to guide the reviewer to each decision point. As PDF content often lacks metadata, we have also implemented smart file management for versioning and filename control, using Documentum® (or any popular document management system).

PDF content is viable and reliable for any maintenance environment—for airlines or any other industry. This is not to say that PDF is better than XML, which is an industry standard, but rather that PDF is more than a legacy format and should be treated as such. With the right software, reconciling changes in PDF maintenance content is a snap.

In response to our recent blog post titled, “The Future of Airline MRO Technology”, we received an interesting comment, which I’d like to address here. The assertions that were made in that comment have been underlined. (Please note, these are only the major points on which we disagree. Perhaps in a future blog we will address the additional disagreements as well.)

Do all OEMs make it difficult to use their data? No. The original blog post focused on Boeing and Airbus because they claim to be helping airlines by offering restricted/proprietary software solutions for a very low cost (sometimes free). Boeing and Airbus try to convince airlines that the best way to receive regular maintenance updates is to use these proprietary solutions. We disagree with this assertion. However, unless an airline is big enough to pressure Boeing and Airbus to give them usable MRO content (SGML), the only way to get it is to pay extra. Many small to medium-sized airlines have little purchasing power over Boeing and Airbus and so are forced to give away a key MRO advantage because they can’t afford the additional charges. The engine OEMs typically author their content in SGML and then publish it in PDF format. Airlines can often get the engine PDF content for free but again, they have to buy the SGML. The reason aircraft and engine OEMs obstruct access to usable MRO content is to protect their aftermarket parts and services revenue. (Airlines tell us it’s more about protecting parts revenue than service revenue but either way we’re all getting stuck with a higher bill.)

Isn’t MRO really the airline’s problem? It’s true that airlines have legal responsibility for the quality of maintenance on their aircraft but there are many examples throughout history where the responsibility and ability to comply with a law don’t go hand in hand. In this case, since the airlines have a hard time getting usable MRO content it makes compliance more difficult and drives up maintenance costs and delays. The fact is, aircraft data is so complex and so inconsistent that huge IT efforts are needed to operate an airplane safely and most of the problem is created by the OEMs trying to guard their profits against third party suppliers.

Why isn’t software-as-a-service (SaaS) the answer? If there’s an empty buzzword in aviation MRO it’s “software as a service.” Suggesting that SaaS is a superior option to fully integrated enterprise software is interesting but incorrect. Various outsourcing initiatives have been attempted over the last 20 years with the result that technicians must often rely on data that is 3-9 months old which, in some cases, results in maintenance errors, dangerous situations and costly (FAA) fines. Our customers tell us that for aviation MRO, the SaaS model has resulted in inefficiency, inconsistency and higher costs.

Many airlines modify the MRO content because they know better than the OEM how to operate and maintain their aircraft. (That’s why they’re certificated by the FAA.) The SaaS model of sending this customized information to a third party vendor, who then provides an electronic application that sits outside their network and doesn’t integrate well with all the other in-house systems is basically saying “let’s stick with the status quo.” (i.e., the stand-alone business processes used in MRO for the last 20 years should work for the next 20 years.) Airlines are trying to become more efficient and more profitable; therefore, they must integrate maintenance operations with other enterprise systems. How else can planners dynamically generate job cards? How else can inspectors use digital sign-offs? How else can engineers automatically update aircraft status and configuration? How else can technicians issue non-routine job cards (from the flight line)? Should the airlines continue doing business the way they have for the last 20 years until they go out of business?

To make a long story short, airlines are smarter than this. They understand total cost of ownership and they understand that the benefits of integrating the MRO content (manuals, IPC, job cards, COC and SB) with configuration, inventory, scheduling, etc. will create significant efficiencies in personnel, parts and uptime. The key to greater maintenance efficiency, consistency, quality, safety and compliance is access to usable MRO content. This is what is essential for the airlines’ survival.