Case Study: Modern workflows to publish Operation Manuals on EFBs

Author: Torsten Machert, Managing Director, EasyBrowse GmbH, and Lutz Kohlert, Office Coordinator Postholder Operations, Germania

Subscribe

Modern workflows to publish Operation Manuals on EFBs

Just getting a manual on-screen is not enough say Torsten Machert, Managing Director, EasyBrowse GmbH and Lutz Kohlert Office Coordinator Postholder Operations, Germania

At a recent airline conference we happened to be part of the following conversation:

“I’m very pleased; we’ve finally managed to get our manuals onto iPad.”
“Now, that is interesting; how did you manage it?”
“It was quiet easy: we opened the manuals in Microsoft Word and saved them as a PDF. Then we made them available for our pilots and cabin crew to be able to download them onto their devices.”
“How many manuals will that be?”
“Not more than ten.”
“And, how can users find the information they need? How do they search across all the manuals and how do you manage the amendment process?”
“Well, that wasn’t on our agenda: the plan was simply to make our manuals available on mobile devices.”
“What then are the additional benefits as compared to the printed manuals?”
“They can now be used on a tablet… and that was the plan.”

Subsequently, and over a glass of beer, we were thinking that it really is a pity that the people who had put their manual ‘onto iPad’ had failed to implement the complete paradigm shift that electronic versions of a manual are able to offer. In particular, we were thinking of all the great new features that could be provided to pilots and cabin crew; features such as…

• Fast access to the required information based on the semantics of that information;
• Powerful and fast search capabilities across all manuals;
• Easy-to-implement automatic updates of manuals and specific parts of them;
• Dynamic content delivery based on aircraft models and/or tail numbers;
• A library or collection of manuals rather than individual files.

… to mention at least the most important ones.

This article discusses the features that make a manual on EFB or Tablet more useful by providing a set of powerful features and functionality. It will also deal with the prerequisites to implementing a workflow that is able to produce high-end EFB apps and to make the entire process more efficient, more reliable and predictable. We’ll do this by summarizing the lessons we learned during the implementation of a complete new workflow at the German airline Germania.

Interestingly, the main objective was not to make the manuals available on an EFB or Tablet platform. Implementing a well-defined workflow to prepare and manage the manuals is, in fact, the prerequisite for an output into nearly all publishing channels and on nearly all devices. Also, when we started the project in 2007 nobody had a clue what an iPad was; so the objective could not have been to make the manuals available on this device. And, who knows what operating systems and what hardware we will be using in five or ten years’ time? We had more far reaching and comprehensive objectives that were, in our opinion, more important than simply supporting a specific device.

The new workflow was designed based on an analysis of the existing processes which revealed that, for a start, existing tools were not able to support the workflow in such a manner as to be able to meet the following requirements:

• Full traceability of all actions;
• Shorter revision cycles;
• Strong version control;
• Re-use of information;
• Effectivity management;
• Status management;
• Translation management;
• Publishing into different channels.

Management of information

The vast majority of airlines are still using a filing system to store and manage their manuals. In that, they ignore the limitations of file based systems in terms of access control and revision handling. It is not easily possible to retrieve useful information such as ‘who did what; when and why’. The way a file based system stores meta data along with the documents is not suitable for providing the technical means to support proper traceability. The versioning of information depends on the discipline of the users. It requires the user to manually create new revisions of manuals and/or chapters by saving the file using a different file name. Conventions for file names can be agreed but it is up to the user to obey those rules or not.

In our project there was no doubt that the entire documentation process must be based on a CMS. The term CMS has two meanings. A CMS is a Component Management System. Rather than storing and managing documents, i.e. files, a CMS manages entire manuals along with the chapters and subchapters of which the manual is comprised. A CMS can also be a Content Management System. That means that it stores the information but without any indication as to how that information is being rendered. This feature is useful when it comes to publishing processes that serve different channels like paper output for different paper formats (A4 and A5) and electronic publications. If the source information is not agnostic as far as its presentation is concerned then every process that has to produce different presentations of the same information will fail.

Using a Content Management System requires that the data format is changed. The only data formats that allow for a presentation agnostic storage of information are those based on SGML/XML. These formats also provide some other interesting and important features:

• They are independent from operating systems and tools;
• XML allows the production of aircraft or fleet specific manuals;
• XML is prerequisite to being able to publish information into different channels – and even into those which will emerge in the future;
• The nature of an XML based data format helps authors to create consistent manual structures.

As strong version control, automatic versioning and re-use of information are basic features of a CMS we were able cope with some of the most painful limitations of the existing process.

A complete paradigm shift

From a process point of view it sounds so easy: buy a CMS and your problems are gone. However, the implementation of a CMS is challenging for the subject matter experts who have to contribute content and work with the new tools. What they experienced in the Germania case was a double paradigm shift. Rather than storing their files in the file system they had to learn to work with a tool that seemed to reduce all degrees of freedom. But that was the plan. A CMS takes full control: it manages the workflow and allows the user to do only those things that they are allowed to do. Everything is tracked: any action is locked and can be reproduced. What initially sounded like a lack of freedom was finally perceived as a welcome support of the daily work.

The other paradigm shift was regarding the way documents are prepared. Instead of using the well-known and familiar Microsoft Word, the sponsors were now ‘forced’ to use tools that reduced the remaining freedom to write manuals and, more importantly, that required them to learn new tools and new techniques to write manuals. It is important to understand that it is necessary to allow time for a learning curve. At the outset it will take longer to prepare manuals. The experience that we gained is that the process of writing and amending manuals will be significantly shorter once the authors are acquainted with the process and the tools. And today nobody wants to go back to the pre-XML era.

Legacy data migration

The implementation of a CMS based workflow also has to take into account that there will be a huge number of legacy documents. The question is, ‘how these documents can be converted to XML?’  To cut a long story short; even if it were technically possible to convert a Word document into XML, we would never try to do it again. The quality of the Word documents, in terms of their consistency and structure, prevents an automated data conversion. Migrating legacy data means also re-structuring them. Our attempt to migrate them automatically revealed the lack of consistency. The manual conversion was a time consuming process but resulted not only in a better quality of manuals but also it allowed us to prepare the manuals for dynamic content delivery which is an on-the-fly delivery process on an EFB that allows the pilot to reduce the information and render only the information that is applicable to the aircraft with which he is flying.

Paper output

Thanks to XML, paper output can be provided with some new and important features:

• The process of creating a PDF is completely automated;
• The PDF contains features like a list of actual changes – a list of revisions that are automatically created by the publishing process;
• Pieces of information that have been amended during the current revision process are marked up with a revision bar;
• The PDF-output exists in two different formats: one PDF file that contains the complete manual and one PDF file that contains only the pages that have been amended.

Electronic publications

During the implementation process in question, Germania introduced EFBs and, with the new CMS and the XML based document process, we were well prepared to deliver the manuals to the new hardware.

However we felt that it was not enough to bring just the PDFs onto the EFBs because that would have meant that we had failed to leverage the power of XML on those devices. Finally we were faced with another paradigm shift. Using manuals on an EFB offers new features to access the required information. Rather than working with a single manual or a single file, users now have access to the full library of manuals. This consists not only of the manuals that are being produced by the airline but also of all the OEM manuals. In our case the goal was to produce an EFB publication that was composed of the Germania manuals available as XML files, Boeing documentation delivered as PDFs and Airbus documentation, also delivered as XML files.

Fast information access

Regardless of the number of manuals and the amount of material involved, an electronic manual must allow for fast, easy and reliable access to the required information. This is paramount as fast information retrieval is a safety related capability. Let’s hope that a pilot never has to open several PDF files to find the information he needs at exactly that moment because, if you have ever worked with large PDFs you’ll know how cumbersome this process can be. Providing access to the information based on its semantics means that we don’t need to do a full text search if we have to know what to do when, for instance, the landing gear does not properly lock.

Specific indices will help to access the required information within a second.

Updating manuals

The old-school way of updating manuals on an EFB or Tablet requires the amended PDFs to be downloaded and typically those PDFs are complete manuals. It’s in the nature of a PDF based process that an existing manual has to be replaced by the new file regardless of the number of pages that have been updated. To accelerate the update process and consume less bandwidth an EFB or Tablet app must support incremental updates. The tools we use are able to produce a complete data package or an incremental update package with the complete package being uploaded to the Intranet while the incremental update packages go onto the EFBs

Dynamic content delivery

Airlines that operate a fleet of different aircraft models (and/or aircraft with different model configurations) provide manuals that contain information regarding all aircraft. It is left up to the pilot to understand which piece of information is applicable to the aircraft he is flying. From a safety point of view this is not acceptable: the risk that he could use the wrong information is too high. A modern EFB app will allow the information to be filtered dynamically and on-the-fly. The airline can still produce manuals that contain everything that they know while the pilot is able to ‘produce’ his specific manual depending on the tail number of the aircraft in which he is sitting.

Summary

Introducing a new workflow based on XML and a CMS is a challenging process both for the vendor and the airline. However, there is no alternative and the results are more than convincing:

• The process is completely traceable.
• The revision management is independent from manual interventions or actions.
• We are able to deliver the content into different formats and channels.
• The revision cycles have been significantly reduced.
• Thanks to XML, we are prepared to meet future requirements in terms of new hardware and operating systems.
• The EFB helps us to reduce fuel consumption by 4.5 tonnes per aircraft per year.

TORSTEN MACHERT
MANAGING DIRECTOR, EASYBROWSE GMBH

Torsten Machert is Managing Director of EasyBrowse GmbH. He is specialized in the conception and implementation of workflows based on SGML and XML. Core themes of his work are such varied industries as aviation, defense, engineering and publishing. In recent years he has been focusing on developing industrial processes for the creation of powerful electronical publications and their distribution.

LUTZ KOHLERT
POSTHOLDER OPERATION, GERMANIA

Lutz Kohlert has an engineering degree in thermal engineering. He started his career in aviation in 1991 at Lufthansa Service and joined Germania as Chief of Traffic one year later. In 2003 he became Assistant to the Manager of Airline Operations and was appointed Office Supervisor of Airline Operations in 2006.