Caroline Estève

Laurent Vinesse

1. The past
2. The goal
3. The prototype
   1. Overview
   2. Neutral format input data
   3. Data preparation
   4. Consultation software
   5. Prospective
4. The future
5. Acknowledgements

The past

The users documentation of the last military launcher, done between 1980 and 1995, was very heterogeneous in its presentation and production process. It was mostly realized according to AIR 106 paper standard. A small part complies with the ESM 56/60 (IT 88805) standard and was integrated in a e-consultation system. Lastly, the software description documentation was an e-doc based on information from the software production tools. The "paper process" was based on :

• 1. The analysis of all the paper documentation made during the whole development of the product (specifications, definition, maintenance manual, user's manual …) by the many different manufacturers. This documentation used to be very different from a manufacturer to another.
• 2. The partial or total rewriting of the documentation, following the imposed standards,
• 3. The illustrations realization, on e-media or on papers,
• 4. The realization of documentation mock-ups,
• 5. The subcontracting of data acquisition, editing and distribution.

The process is illustrated in Figure 1.

Figure 1 . Process formerly applied

As known by everybody, this process had major drawbacks :

• Important paper volumes (several m3 for the whole weapon system),
• Different consultation means,
• At least 2 different data acquisition,
• Complex realization process,
• Information duplication in different tomes,
• Long realization and updating cycles,
• Realization at the very last time, when all the development information is over,
• Specific tools use, which generated important tools logistic support costs.

Previous

Table of Contents

The goal

The main challenge for M51 user's documentation is to divide its realization cost by two. In order to do so, some solutions are considered :

• Maintenance policy simplification,
• Number of pages reduction (re-use of some parts, description manual simplification, less LR1-Level of Repair- and LR2 operations …),
• Use of structured and modular e-documentation,
• LSA (Logistic Support Analysis) and Documentation process integration.

The structured and modular documentation and associated realization process is already used or will be soon used by most of the military projects and by most of the involved manufacturers so as to reduce the preceding drawbacks.

The new process leads to an upstream movement of some tasks. As a matter of fact, the manufacturer is now totally responsible for the user's documentation dealing with the product he provides. The splitting and organization of tasks has to be re-thought. The tools and ability needed by each actor of the process also mostly change.

The expected process is illustrated in Figure 2.

Figure 2 . Expected process

The important expected savings in realization and maintenance costs are due to the following advantages of the process:

• No paper volumes (the user only prints what he needs, if he wants),
• Only one data acquisition,
• Easy and fast updating,
• Longer documentation realization period,
• Homogeneous and ergonomic consultation means,
• Use of ISO norms and of standards,
• Use of ready-to-use commercial or public domain tools.

Previous

Table of Contents

The prototype

Overview

A prototype was made in 1999 and 2000 in order to :

• Test the e-documentation realization process :
  • Process automation,
  • No data modification from the data acquisition by the manufacturer, to the delivery of the e-doc to the system users,
• Test the users' reactions to e-doc.

The so made e-documentation deals with the description manual, maintenance manual and illustrated parts catalog of a 65 tons handling device.

The global process that was held, is illustrated in Figure 3.

Figure 3 . Global process

The experience we already have by this prototype can be detailed as follows :

• We need tools which are ˙:
  • simple and ergonomic,
  • cheap and easy to distribute,
  • integrated (LSA records, Data modules, Interactive Illustrations, edition),
  • with on line help and with writers guidelines,
• We have to precisely organize the process from the bid to the product (and its e-doc) approval,
  • writing comprehensible and simple, technical and contractual specifications,
  • preparing a bidding evaluation grid,
  • making tools formation modules,
  • identifying and training potential subcontractors, able to realize LSA and e-doc,
  • training AML engineers responsible for the products realization,
  • organizing and automating the validation of data,
  • …
• We still need standards dealing with the logistic support and users' documentation data organization, which can be easily, industrially and cheaply implemented.

The following sections focuses on development of the e-doc data preparation and consultation software, stressing out (on the technical side of things) the benefits of using neutral industrial encoding formats.

The overall data preparation and consultation software architecture is illustrated in Figure 4.

Figure 4 . Data preparation and consultation software architecture

Neutral format input data

At the beginning of the process are the data. The documentation items are stored in a production system and encoded in state-of-the-art neutral format : SGML for textual data, TIFF, CGM, JPEG for graphical data. Technical data, LSA related, are stored in a production DBMS and exchanged as raw ASCII files.

In the pre-XML life, there was numerous and certainly good arguments to justify encoding of document data into neutral standardized format e.g. SGML for text. However, the general feeling was that the gap between rough data and its consumption by end-user, through a published form, was a kind of technical challenge.

Knowing this, a lot of potential SGML users did not dare to move forward into a fully structured text approach. Now with XML, we benefit from core tools, free and integrated in the most common desktop environments. Moreover, the ability to transport and manage well-formed documents avoids to oversize the consultation part of systems with DTD-aware software.

In this given context, one key choice is to transform SGML documentation modules input their well-formed XML equivalent.

Data preparation

The data preparation is a batch process which takes input data set and transforms it into a human-consumable form. The data input is read from a flat file system without any direct connection to the production system. The whole data preparation is written using a SGML/XML-aware scripting engine.

SGML documents are transformed into XML documents enriched with technical data required for interactive consultation. Transforming is done without any major structural modification, other than adding technical data and refining the granularity of information. Typically front-matter parts are extracted from master TOC to get an independent modules. Thanks to strong SGML/XML filiation, this is a straightforward process. Graphical files are linked to technical data in order to provide interactive graphic navigation through CGM vector files.

From a template database file, a lightweight database is populated using the ODBC connectivity of the SGML/XML-aware scripting engine. This database holds :

• Product top-down breakdown,
• Meta-data associated to each product node,
• Links to XML transformed modules,
• Links to graphical modules with reference to parts illustrated on each graphic,
• LSA data as list of suppliers, spare parts, consumable...

The mapping between input and output structures is described in an XML file. This makes parsing of this configuration file easier. The data preparation is a fully automated batch process. It checks global consistency of data, including SGML instances validity. In case of success, it just produces an output database ready for consultation.

Consultation software

The consultation software is designed as a windows multiple document interface application, providing support for the various manuals and LSA data list.

The backbone of the e-doc application is an interactive illustrated parts catalog based on product top-down breakdown, it uses a CGM hotspot-activated viewer synchronized with a treeview fed by technical data. It appears to be a major trend for coming years that technical e-doc should be based on interactive illustration. Additional specific printing features have been developed since the desired paper output model is nomenclature oriented.

The Figure 5 is an hardcopy of the illustrated part catalog.

Figure 5 . Illustrated part catalog on screen

The e-doc application makes intensive use of standardized XML-aware Internet viewing technology embedded into a customized application. Due to the requirement of managing a multiple windows interface and special search requirements, the decision has been made not to implement a simple browser-based application.

Maintenance and descriptive manuals are viewed on-the-fly as XML fragments using XSLT as the transformation process to a presentational HTML structure and CSS as a way to refine the dressing of this structure. In order to provide a fully interactive dynamic page, what is actually generated as output is more than simple HTML, but a combination of DHTML/DOM and Javascript. This is used for expandable TOCs and for module contents as well. The default layout and formatting semantics model is the HTML one (autowrapping and scroll mode), doubtless the most appropriate for screen reading. CSS media-sensitive features allow to generate different presentational structure when output is paper.

The Figure 6 is an hardcopy of the maintenance manual window.

Figure 6 . Maintenance manual on screen

The links between different parts of the documentation are activated when useful, taking advantage of underlying strength beyond SGML/XML structuring :

• Between illustrated part catalog and maintenance manual,
• Between documents and LSA data,
• Between illustrated part catalog and LSA data,
• Intra and inter manuals.

The application is also able to search and retrieve documents or articles based on keyword search, and to manage bookmarks, users annotations and consultation log information.

Prospective

As a conclusion, the wide-spread adoption of Internet technologies and XML has brought tools from the mass market that are potentially unlimited in term of presentation. These tools leverage the potential of structured textual data to build truly interactive e-doc. Today we can develop more efficient and cheaper e-doc than five years ago.

At the time when the technical choices were made (summer 1999), a number of XML companion standards were still in an uncertain situation. Knowing the huge success of XML, we were confident that things would evolve in a positive way and reach broader adoption in tools. This occurred as expected.

As these lines are written, a number of evolutions are still in progress to streamline the e-doc production :

• Full implementation of XSLT at the level of W3C recommendation in desktop tools,
• Full implementation of CSS1-2 in desktop tools,
• Development of SVG, and associated viewing engines, as fully XML-compliant and embedded 2D graphical vector format,
• Development of XSL FOs for sophisticated printing features,
• Development of XML-native lightweight database engine using XQL or other XML-aware request syntax.

If it is currently heard that XML development is driven by e-commerce for its larger audience, it remains extremely pertinent to use it for technical e-doc. Furthermore, it benefits to industries which have already invested in SGML.

Previous

Table of Contents

The future

By 2003, we have to specify, realize and implement a complete Logistic Information System, able to help acquisition, checking, management and modification of the following data :

• Logistic support analysis data,
• Data modules for user's manual, maintenance manual, description manual,
• Illustrations for all manuals and for illustrated parts catalogue,
• Publication and delivery data,
• Consultation data.

This LIS also have to implement all needed interfaces, such as with PDM, CAD…

We expect that XML and all associated technology and tools will greatly help us to achieve this end.

Previous

Table of Contents

Acknowledgements

Previous

Table of Contents