SGML - Made SIMPLE   Table of contents   Indexes   Getting to XML from HTML
  Gallagher  James A 
  Wood  Chris 
 

Tornado F3 Conversion of Publications Data to AECMA 1000D - A Case Study

 

Abstract:

  TheRAF (Royal Air Force) have traditionally supported their in-service fleet exclusively with either hard-copy publications or microfiche. This is changing. Recently placed contracts for the Attack Helicopter, EuroFighter 2000 and the Replacement Maritime Patrol Aircraft mandate electronic delivery of Descriptive, Maintenance, Parts Catalogue and Training publications data. This data is destined for delivery toLITS (Logistics Information Technology Strategy) (The RAF’s Logistic IT System).LITS is being developed by the RAF and IBM to receive and electronically distribute this data in an SGML-based Data Module form as defined byAECMA 1000D and theUK (United Kingdom) Def-Stan 00-60.
  In order to prove the capability ofLITS and also to prove the contractors capability to deliver coherent Modular data, theRAF is sponsoring a series of "Proof of Concept" initiatives. One such initiative is the Tornado F3 Conversion Project
 This project is scoped to include over 60 000 pages of Technical Manuals (including Descriptive, Procedural and Parts Catalogue data) for conversion from its current production methods and specifications to SGML-based Data Module production and delivery.
 The project will challenge Consultants, Applications Developers, Authors, Editors and Document Conversion specialists to deliver this data in a new form and structure whilst continuing to support the operation of this front line Fighter Aircraft.
 

Introduction

  The Technical Publications Function within British AerospaceBAe (British Aerospace) Military Aircraft supports the in-service operation of advanced Aircraft Systems, including Tornado, Hawk (many variants; many customers), Harrier I and II and other smaller projects. We are currently preparing publications data in SGML and we are developing and utilising SGML-based database systems to support the introduction into active service of the Tornado GR.4 variant, Eurofighter 2000 and Nimrod 2000 aircraft. To do this, we operate from 3 sites, employing over 200 publications specialists and approximately 20 Applications developers.
  This paper describes a project we are currently involved in with UK Ministry of Defence to convert the majority of the Tornado F3 (Air Defence Variant) publications suite from its hard copy book-based format (produced to aUK MoD (Ministry of Defence) specification,AvP70 (Specification for Air Technical Publications) ) to an SGML-based data module concept complying with the rapidly developing European Aerospace Documentation SpecificationAECMA 1000D.
 

Tornado F3

 The Tornado F3 was introduced into service in 1985, and is a long-range all-weather air defence/interceptor, additionally performing air-defence of the UK’s maritime fleet.
 The total support documentation suite for which British Aerospace has responsibility comprises approximately:
 
  • 17 000 pages of Aircraft Maintenance Manuals (Topic 1)
    •  
  • 20 000 pages of Modification Leaflets (Topic 2)
    •  
  • 25 000 pages of Illustrated Parts Catalogues (Topic 3)
    •  
  • 8 000 pages of Aircraft Repair Manuals (Topic 6)
    •  
  • 4 000 pages of Maintenance Diagrams Manuals (Topic 10)
    •  
  • > 350 Pages of Cross Servicing Guides (Topic 12B)
    •  
  • 1 000 pages of Air Crew related publications (Topics 14,15 and 16)
    •   The Air Crew publications are generated byRAF Handling Squadron (who are the Publications Authority for these publications) from source data supplied byBAe . Also included in the F3 publications suite, there are over 60 000 pages of Equipment Publications, generated by our equipment suppliers. These are outside the scope of this contract, and therefore of this presentation.
     The conversion contract in total covers over 70 000 pages of documentation.
     

    The Customer

      As stated earlier, our customer for this contract is theUK Ministry of Defence, who are active members of theAECMA standards community and who over the past few years have developed a strategy for the progressive conversion of 'Legacy Data' from whatever form it currently exists in to SGML-based data for electronic delivery in line with their Logistics Information Technology Strategy (LITS ). During 1995 and 1996, they undertook a 'Proof of Concept' (POC ) study to satisfy themselves that the data conversion task for legacy information was both possible and affordable. Additionally, thisPOC (Proof of Concept) was used to generate a series of metrics which could be applied to contractors - such as BAe - when evaluating conversion contract submissions. They presented a paper on this subject at CALS Expo ’96 and are represented at this Conference.
     

    The Contract

      As stated earlier, the contract deals with the conversion of in excess of 70 000 pages of highly technical publications data from its current standards to SGML-based Data Modules complying withAECMA 1000D. Once the data is in Data Module form, we then need to deliver the data to the Customer, ultimately the User in the form of Interactive Electronic Technical Manuals (IETM), probably incorporating HyTime techniques. The conversion task covers data which is being used daily to support a front - line operational aircraft, whose publications suite is by no means frozen. So maintaining the airworthiness of the publications data - and therefore of the aircraft itself - is a major consideration in this project. If any technical data is changed during conversion, then because of the sensitive nature of the data and its airworthiness implications, a re-verification exercise would need to be undertaken. One thing which must not be forgotten is that whilst the conversion is being performed, we must retain our capability to deliver the books in their existing hard-copy form.
     

    'As is'

      The phrase'its current standard' hides a multitude of sins. Consider that aircraft of this type have an in-service life of over 30 years. The Tornado F3 first became operational in 1985, and therefore since then, the publications suite has undergone continuous improvement and update. Many different publishing techniques have been used over the years to perform this function, including Phototypesetting; Word Processing (using various Mac-based and PC-based applications);GML (IBM’s Generalized Markup Language) etc. for text and many graphics packages for illustration production. Common production techniques were not viable, given the wide range of Publication types, until SGML came along. However, the decision to migrate all the textual data to SGML (and as much illustration data as possible toCGM (Computer Graphics Metafile (ISO 8632)) was not an easy one to make, as it involved a significant amount ofDTD (Document Type Definition) and Applications Development work, author/illustrator re-training and blind faith that what we were doing was justifiable in productivity and business terms. Fortunately, we had been able to obtain a reasonable amount of SGML andCGM knowledge on other Projects, so it wasn’t quite a 'leap in the dark'. Nevertheless, it was a major decision to make.
     The style of documentation currently in service use for Tornado F3 is in accordance with AvP70. This specification defines particular styles of documents, as follows:
     
  • Aircraft Maintenance Manuals (approx. 140 off) each containing Descriptive, Servicing, Testing, Remove/Install and Maintenance Procedures.
    •  
  • Modification Leaflets which describe how to perform a modification to an aircraft or its equipment in service.
    •  
  • Illustrated Parts Catalogues, which contain a complete item-by-item breakdown (hierarchically arranged in tabular and illustrative form) of the Airframe.
    •  
  • Aircraft Repair Manuals, detailing in-depth airframe/skin repairs.
    •  
  • Maintenance Diagrams Manuals which contain complete Aircraft wiring and harness information in diagrammatic form and other smaller document types.
    •  These are essentially books, delivered in hard copy and microfiche form.
     

    AECMA 1000D

     The initial post-conversion deliverable is a full set ofData Modules (DM). A data module is a self-contained unit of data for the description, operation or maintenance of an air vehicle, airborne engine, airborne equipment or support equipment. The unit of data consists of an Identification and Status Section and a Content Section, and is produced in such a form that it can be input into, and retrieved from a database using a data module code (DMC) as the identifier.
     The DMC is a 17-character alphanumeric code identifying the type and applicability of the information in a data module, enabling it to be input to and retrieved from a database.
     A full maintenance procedure is obtained by concatenating a series of DM into a complete task description.
     

    The Conversion Task

     Information Codes defined in the AECMA 1000D specification identify the type of information contained within the data module - servicing, examination, failure reporting, repair, removal and installation, storage etc. However, because of the arrangement of AvP70, the information in the books cannot be automatically mapped directly into AECMA 1000D. This operation requires a detailed understanding of the technical content of the data.
     Once this is done, the source data had to be converted into AvP70 style SGML, to allow the establishment of a firm basis for full conversion. We did this using in-house and sub-contract personnel, utilising a number of SGML-editing tools and our own DTD. Again, this part of the task ought not to be underestimated. I have stated before that the data we are converting has existed for several years. It has been produced by a relative multitude of authors and Quality Assured by lots of Customer representatives each of whom has his or her particular method of applying the specification. By definition, the use of SGML, controlled by a DTD tends to produce much more rigidity in its application of the specification. Therefore, it is was possible to do some automatic conversion, however some manual intervention was required, followed by a final technical quality check.
     The first task in the conversion process is to define a full set of DMC’s. This has two purposes:First, it allows the software engineering team to begin the database design, and secondly, it allows the author team to define the alternative DMC cross-references for insertion into the text. (There are cross-references within and between each Topic.)
     The database was constructed to contain publication 'fragments', known as text modules. This was identified as having 2 main advantages:
     
  • It allowed the author to work with small amounts of text at a time, and
    •  
  • it generated the first stage of conversion from AvP70 to AECMA 1000D.
    •  However, it did mean that when the DTD was applied to the book fragment, it had to be associated with a 'Set-up File', whose intrinsic purpose was to "trick" the DTD into believing that a part of the document complies with the overall book structure.
     The action of splitting the complete book files into fragments was performed as part of the data analysis task, to ensure that as much cognisance of the AECMA 1000D information codes was taken. Following the completion of the data analysis activity, a "hybrid" DTD was generated, based on the AvP70 DTD, but with the addition of AECMA1000D tags and data structures where appropriate. This DTD was used to place additional tags into the source data, such that the application of "output DTD’s" to the data was sufficient to establish the structure of the output data in its required form,EITHER AvP70OR AECMA 1000D.
     

    Other Issues

     Major considerations during the Conversion Task Design analysis, were the management of the different issue states of the books and the Data Modules, combined with the consideration of differing revision cycles.
     Most crucially, consideration had to be given to the data users. These were tradespersons who are employed not for their computer literacy, but for their engineering skills in Aircraft System maintenance. Therefore the design of the deliverable has to be as intuitive as possible, probably making use of intelligent graphical interfaces, created by the conversion of illustration files to CGM where appropriate, to ensure the simplest and most rapid access to the servicing data required. This in turn has a significant impact on the source data.
     

    Conclusions

     Some significant conclusions have been drawn during the progress of this conversion task:
     
    1. Conversion from AvP70 structure to AECMA 1000D is possible, but is not automatic.
    2. Performing in-depth data analysis pays significant dividends in the conversion process, influencing DTD design, database design and overall approach.
    3. Output requirements have major implications on source data.
    4. The source data is the most valuable asset. It must be treated with care.
    5. Reductions in the overall amount of data required can be achieved, as moves are made to increase data re-use.
     

    ACKNOWLEDGEMENTS

      BAe gratefully acknowledges the encouragement and far-sightedness of members of theRAF ; in particular, Dennis Hoyland for his pioneering work withAECMA , and John Ponting, who in other circumstances would have been co-presenting this paper.
     

    BIBLIOGRAPHY

     
  • [All the World’s Aircraft] Jane’s
    • SGML - Made SIMPLE   Table of contents   Indexes   Getting to XML from HTML