Guidance for the Paperless Cockpit

One of the interesting applications of the Electronic Flight Bag (EFB) is electronic documents. Electronic documents allow aircraft operators to amend manufacturer’s flight operations manuals based on operator's policies and procedures and publish these manuals in electronic formats such as Adobe® Portable Document Format (PDF) and XML. Examples of these manuals are:

• Flight Crew Operating Manual (FCOM)


• Quick Reference Handbook (QRH)


• Flight Crew Training Manual (FCTM)


• Minimum Equipment List (MEL)


• Fault Reporting Manuals (FRM)


• Weight and Balance Manual


• Dispatch Deviations Guide

US Federal Aviation Administration (FAA) Advisory Circular (AC) 120 76A “Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices” specifies the design and technical criteria for the approval of the human/machine interface of EFB systems. The following is an excerpt of the EFB Operational Evaluation and Approval Job Aid used by FAA inspectors for electronic documents functionalities:

• Is there a training program on how to display and interact with electronic documents? Is it adequate?
  
• Can the crews find the material they are looking for?
  
• Is the information organized in a way that makes sense to the crews?
  
• Is the information arranged in a consistent way on the screen so that the crews know where to look for specific types of information?
  
• Is it obvious when text is out of view? Is it easy to bring that text into view?
  
• Can the crew tell where they are in relation to the full document?
  
• Can the crew tell where they are in relation to the section of the document they are currently viewing?
  
• Is the text of the document easy to read on the screen?
  
• Is white space used to separate short main sections of text?
  
• Is high priority information especially easy to read?
  
• Are tables readable and usable?
  
• How are especially long and complex tables handled?
  
• Are figures readable and usable?
  
• Can the entire figure be viewed at one time?
  
• Can the crew zoom in to read details on the figure?
  
• Is it easy to move quickly to specific locations (e.g., to the beginning of a section, or to recently visited locations)?
  
• Are active regions (e.g., hyperlinks) clearly indicated?
  
• Is it easy to move between documents quickly?
  
• Is it easy to tell what document is currently in view?
  
• Is there a list of available documents to choose from?
  
• Can crews search the document electronically?
  
• Is the search technique adequate?
  
• If animation is supported, does the crew have adequate control over it?
  
• Can the crew start and stop the animation as needed?
  
• Is there a text description of the animation that describes its contents (so the crews know its contents without running the segment)?
  
• Is printing supported? If so, is it adequate?
  
• Can crews select a portion of a document to be printed?
  
• Is the hard copy usable?
  
• Can the crew terminate a print job immediately, if necessary?
  

These criteria have been developed as the result of research into human factors in the use of electronic documents in EFBs by the Human Factors Division of the Office of Aviation Programs at the Volpe National Transportation Systems Center. Knowing these criteria in advance can help an aircraft operator in preparing for approval. However, I believe that operators can benefit from a more detailed set of specifications in regard to the interface to electronic documents. Section 6.3.1 of the S1000D standard provides rules and guidance for the look and feel, and printed output from an Interactive Electronic Technical Publication (IETP). Section 6.4.1 defines a functionality matrix for IETPs to be used as an aid for defining requirements for S1000D projects. The functionality matrix leverages the US Department of Defense (DoD) long experience in defining class 1 to 5 IETMs with military specifications MIL-PRF-87268 and MIL-PRF-87269. For example, in the area of searching, the S1000D functionality matrix provides very detailed guidelines that go beyond the simple criteria "Can crews search the document electronically?" and "Is the search technique adequate?". The matrix breaks down searching functionalities into:

• Full-text search
  
• User-defined Boolean search
  
• Search across multiple databases and files
  
• Context search
  
• Keyword search
  

Publishing EFB electronic documents in XML provides many benefits over the Adobe® PDF format. Key enabling technologies for XML-based EFB electronic documents are: ISO Schematron, XSLT, XSL FO, XLink, XPointer, XInclude, and XQuery. For quality assurance, the electronic documents application should be subjected to rigorous unit testing and functional testing before its release to flight crews. A content management system can help an operator by providing features such as workflow routing, versioning, document locking, access control, and full audit trail of modifications made to documents.

The Air Transport Association (ATA) has adopted S1000D as the next generation aircraft digital data standard and there is already a very close collaboration between the ATA and the S1000D TPSMG to harmonize commercial aviation technical data requirements with S1000D. That collaboration should be extended to electronic documents for EFBs to allow aircraft operators to leverage and influence the development of the S1000D IETP functionality matrix for better guidance on creating the paperless cockpit.

The Business Value of XML

What exactly is the business value of XML and its related technologies such as XML Schema, ISO Schematron, XForms, XSLT, and XQuery? Let's review three use cases where XML adds real value.

The first use case is software configuration and metadata. Java EE Frameworks such as Hibernate, Spring, Struts, and JSF use XML for configuration and metadata. Unfortunately, not all Java EE developers understand the value of configuring their application with XML as opposed to Java annotations. There is currently a backlash against XML with some developers complaining about what they call "XML hell". These developers prefer to keep configuration and metadata closer to the code itself using Java annotations. Newer Java EE frameworks such as the JPA (Java Persistence API) and Struts 2 provide annotation capabilities which are very popular with developers. I personally believe that this is a trend in the wrong direction. Annotations are certainly convenient for developers, but not necessarily to end users of your application. With XML configuration, end users of your software who are not programmers can achieve a certain level of customization on their own by simply editing an XML configuration file in a text editor without importing your SDK in an IDE and compiling Java code or hiring a Java EE developer to do it for them. As a software buyer, when deciding between two competing products, I would choose (everything else being equal) the one that allows me to do some customizations with simple XML files. Developers can reduce the verbosity of their XML configuration files by using techniques such as inheritance, overridable default values, and preferring the use of attributes over child elements for example. A compromise could be to make the annotations overridable with XML configuration.

The next use case is data exchange across organizations. Two example applications that are currently delivering real value are UBL and NIEM. XML vocabularies such as UBL and NIEM define common semantics and data structure trough data dictionaries and XML schemas respectively. In addition, they can specify certain business rules that can be enforced with the use of an assertion-based schema language such as ISO Schematron.

Developed by OASIS, UBL (Universal Business Language) is an XML vocabulary for the exchange of business documents such as invoices, purchase orders, and receipts. In Denmark, the government has mandated the use of UBL invoices for all public-sector billing. The result is over 100 millions euros in savings every year. The Swedish government estimates that it can save 440 millions euros with the adoption of UBL for electronic commerce. Please note that these initiatives involve not only big government and Fortune 500 companies, but hundreds of thousands of SMEs (small and medium size enterprises) as well.

NIEM (National Information Exchange Model) developed by the U.S. Department of Justice and the Department of Homeland Security is an XML vocabulary for the exchange of information between government agencies. For example, it allows law enforcement agencies to quickly exchange information. Law enforcement agencies use heterogeneous applications called RMS (Record Management Systems) and XML data is the bridge between them because it is vendor neutral, cross-platform, and supports structured data of arbitrary complexity. XSLT 2.0 as a generic XML transformation language can play an important role here as well. As an example, an RMS system can export raw XML data which can then be mapped to a NIEM compliant XML Schema by performing an XSLT transformation. If a legacy RMS system can only export CSV (comma-separated values)text files, XSLT 2.0 can up-convert the CSV into a NIEM compliant XML document. It is possible to process XML with a traditional programming language such as C# or Java. However, the problem is the "impedance mismatch" between the type system of these programming languages and a type system based on XML (such as the XML schema type system). Some developers will find XQuery easier to use than XSLT (probably because of its SQL-like syntax) for processing XML data. In addition, XSLT 2.0 and XQuery are declarative processing languages (they describe the "what" as opposed to the "how") and are therefore accessible to many non-programmers.

The last use case is knowledge management in general and content management in particular. In the new global knowledge economy, the most important asset of an organization is its intellectual capital which is acquired and developed by its knowledge workers. That intellectual capital is often captured in documents such as blogs, wikis, emails, PowerPoint presentations, podcasts, engineering drawings, architecture diagrams, ISO 9000 quality manuals, installation and troubleshooting procedures, Microsoft Word documents containing requirements and design specifications, various corporate forms, etc. These mission-critical documents are often dumped into shared network drives. They are not managed with the same rigor and cannot be queried as the data contained in your CRM and ERP systems. The main reason is that these documents represent unstructured data as opposed to the well-structured relational data stored by the RDBMS on which your ERP and CRM systems sit. In some industries, the need to bring content under control is driven by regulatory compliance. In any case, organizations shouldn't wait until their most valuable employees leave before they start thinking about managing their knowledge assets. That's where an enterprise content management system (CMS) and an enterprise portal come into play.

XML goes beyond tags, taxonomy, and content categorization to provide fine-grained content discovery, query, and processing capabilities. With XML, the document becomes the database. First, using XML schema, you can constrain and validate the structure and data types of the content of your business documents just like you do with a relational database schema. Using XForms, you can provide a user friendly interface for your end users to contribute XML content by presenting them with a regular HTML form. Once the content is captured as XML, it can be stored in a native XML database. With XQuery, the native XML database allows you to perform structured queries on the content (as opposed to just full-text or metadata search). XQuery also allows you to assemble content dynamically (for example, build two distinct training manuals for two different configurations of your product from a single source). You can use XQuery to query both relational (from your ERP and CRM systems) and XML data sources and aggregate the results. With XSLT, you enable content adaptation for cross-media publishing (print, web, and wireless) from a single source.

If you decide to manage your product technical documentation with XML, there are standards that can help. The DITA (Darwin Information Typing Architecture) specification is very popular with computer software and hardware documentation. The S1000D standard is designed to support mission critical maintenance and operation documentation in industries such as aerospace, defense, automotive, oil and gas, heavy equipments and machinery, and power generation.

Organizations that have a strategy for managing their knowledge assets using XML and related technologies will have a definitive competitive advantage in today’s economy.