Experiences of an implementation   Table of contents   Indexes   XML vocabularies for insurance &, travel
 

An approach for e-doc using XML technology

Estève, Caroline
 
 Caroline  Estève
 Project manager
 Aerospatiale Matra Lanceurs
 France 
Saint Medard en Jalles
Aerospatiale Matra Lanceurs,  Avenue du général Niox - BP 11
Saint Medard en Jalles   Cedex 33165 France
Phone: +33 (0) 5 56 57 37 38 or +33 (0) 5 56 70 56 38 Fax: +33 (0) 5 56 57 34 68 or +33 (0) 5 56 70 59 13 email: caroline.esteve@lanceurs.aeromatra.com web site: www.aeromatra.com
 Biography
 Caroline Estève — As an engineer and project manager in AEROSPATIALE MATRA LANCEURS, Caroline Estève has been involved for eight years in different information systems projects, dealing with air command and control, definition data, system and mechanical synthesis data, logistics and documentation data.
 She is now in charge of the electronic documentation of a major military project, responsible for both the specification and setting of methods and tools, and for the realization of the e-doc of the system.
 AEROSPATIALE MATRA LANCEURS STRATEGIQUES ET SPATIAUX is a 100 % subsidiary of the Aerospatiale Matra group. Its role is to design, develop, test, produce and integrate civil and military launchers, space transportation and atmospheric re-entry vehicles and elements of orbital infrastructure. The Aquitaine plant has gained a unique experience in developing and integrating complex systems (MSBS), in atmospheric reentry (ARD, Huygens...), in composite materials (wound tank for launchers and satellites, reinforcement rod for the Airbus A 330-340, thermal protection...) and in test facilities (EDEN).
Vinesse, Laurent
 
 Laurent  Vinesse
 Project leader
 Eurodoc-Sofilog
 France 
 Nantes 
Eurodoc-Sofilog,  Nantes  Cedex 3
9, rue Alfred Kastler - BP70754
 44307 France
Phone: +33 (0) 240 252 510 Fax: +33 (0) 240 252 452 email: laurent.vinesse@eurodoc-sofilog.com web site: www.eurodoc-sofilog.com
 Biography
 Laurent Vinesse — As an engineer and project leader in IT services, Laurent Vinesse has been involved in SGML/XML-based documentation, stand-alone and WEB, applications for eight years in the fields of Patents, Defense, Libraries, Automotive, Aeronautics. He is in charge of new technology choices and development within the Technical Management department of EURODOC-SOFILOG.
 EURODOC-SOFILOG is a global documentation service provider, mainly involved in the following industrial fields : energy, aeronautics, defense, railway transport. EURODOC-SOFILOG has been investing in SGML, XML and associated W3C recommendations to produce, store and distribute interactive technical documentation for industrial accounts.
 Abstract
 A technical e-doc application has been developed in a prospective approach for a sub-system being part of a global military program. To reduce the global possession cost of the technical users documentation of this program, whose 100 000 pages and 10 000 illustrations will have to be maintained for more than 25 years, it was decided to give up costly paper standards. The aim of the prototype now developed is first to validate the e-doc production automated process, and secondly to propose the users an ergonomic e-doc application, he could react on to improve the specifications of the future global e-doc system.
 This paper aims at presenting this SGML/CGM project for technical e-doc in the context of the functional needs and the immediate benefits XML and its companion standards brought to it.
 The scope of the project is to cover illustrated parts catalog, descriptive, maintenance documentation, including all needed sets of associated logistics and technical data (task duration and level, spares, manufacturer).
 The project lead to the development of an e-doc database being built from the input technical data linked to the documentation items. The e-doc database uses a lightweight database engine. It is calculated from input data and linked to documents using an SGML-aware transformation engine.
 

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 .
 
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.
    •  

    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 .
     
    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.
    •  

    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 .
     
    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 beeasily, 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 .
     
    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 is an hardcopy of the illustrated part catalog.
     
    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 is an hardcopy of the maintenance manual window.
     
    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.
     

    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.
     Acknowledgements
     We thank very much :
     
  • All the AML team (Jean-Yves, Christian, Alain, Serge, Claude, Henry …)
    •  
  • All the ES project team (Stéphane, Thomas, Solène, Isabelle)
    • for their active and efficient involvement in this project.
    Experiences of an implementation   Table of contents   Indexes   XML vocabularies for insurance &, travel