The DEF STAN 00-60 Document Architecture

DS0060 establishes a uniform approach to the procurement, format, transfer medium and maintenance of electronic documentation (ED). The underlying principle of DS0060 document management is the central retrieval and generation of technical documentation from a set of data modules. A data module is defined as:

A self-contained unit of data for the description, operation or maintenance of an air vehicle, airborne engine, airborne equipment and support equipment. The unit of data consists of an identification and status section and contents section and is produced in such a form that it can be input into and retrieved from a database using the data module code as the identifier.

Storage

Input

New Data Legacy Data

Add DMC

Author DMs User Requirements

Mediation

Audit

Scan Paper Check OCR Split into DMs

OCR Add DMC

Audit Screen Print Braille ...

User Authentication User

Interaction

Search Resolution

Figure 3-1: The Overall DEF STAN 0060 Document Process

The data module forms the lowest level of document abstraction. Each data module is marked with a unique code that identifies its role in describing some piece of defence equipment. In order to share and reuse the document information across software applications and computing platforms, The Standard Generalised Mark-up Language (SGML) is recommended as the document storage format.

DS0060 recognises two high-level document phases: the consistent creation of individual data modules (the input stage) and the construction of a selection of data modules into a final publication (the output stage).

The final publication, to be viewed by the end-user, is called an Interactive Electronic Technical Publication (IETP). An IETP is a technical manual (maintenance, user, training, operations, etc.) prepared in digital form on a suitable medium, designed for electronic screen display to an end-user, and possessing the following characteristics:

• A move away from paper-based presentation of information to modular display.

• A move towards display on PCs and laptops

• A move towards interactivity in providing procedural guidance, navigation directions and supplemental information.

• A move towards multimedia

• A move towards providing a variety of paths to the right information

The overall publication process of a publication (or manual) from a set of data modules is shown in figure 3-2. It shows a collection of data modules stored according to some classification (storage) scheme and retrieved and published for a purpose according to a publication scheme. The publication scheme provides a restricted view on the entire collection of data modules, and results in an Interactive Electronic Technical Publication (IETP) for a particular purpose. In order to build a collection of ’self-contained’ data modules

Storage Scheme

stored according to

Data Modules retrieved according to

Publication Scheme Publication

defines rules for provides a view on

- models

Figure 3-2: An Overview of the IETP Publication Process

into a useful publication (IETP) a number of levels of abstraction are developed by DS0060; these are shown in figure 3-3 and explained below.

Data Module (DM) Layer

A Data Module (DM) is a document file that holds a ’self-contained’ unit of data describing a particular operation on a particular piece of defence equipment. Each DM is an SGML file that strictly conforms to the DS0060 data module document type definition (DTD). Each DM consists of a title, a ’status and identification’ section and document content. The status represents the security classification and issue number of the data module, and can be disregarded for the purposes of this thesis. The identification section is, however, of significant importance, codifying the document content with respect to the MoD equipment range. The identification code is formally known as the Document Module Code (DMC) and is discussed later in this chapter.

Data module header (DMH) layer

A Data Module Header (DMH) is defined for each data module in the database. The DMH is the only point of access to its corresponding data-module, provides both a wrapper of abstraction and entry points into the DM’s contents. The DMH may contain any of the following:

• A generated table of contents (TOC) for each data-module

• A glossary for all tagged terms used within the DM

• Access links to different points within the DM content.

IETP

DM1 DM2 DM3 DM4

List of Effective Data Module Headers

DMH1 DMH2 DMH3 DMH4

TOC LOI GLOS PROC

Data Module Data Module Header Views

Figure 3-3: The DEF STAN 00-60 Storage Model

A DMH can be dynamically generated from a data module when it is first entered into the database and can also be manually extended. Entry to DMs is only granted at certain points to ensure that the reader does not miss essential document content such as warnings or cautions. This is an obvious concern for a document system that delivers safety-critical information that must not be ignored by the user.

List of Effective Data Module Headers (LOEDMH) layer

The LOEDMH serves two purposes: it provides a catalogue of all the DMs in the database and a switching mechanism for linking public identifiers to system identifiers. The separation of the public identifier from the system identifier is a valuable concept, allowing a data module to be referenced from any of the higher layers without the need to refer to the physical file location.

’Views’ layer

The views layer, also known as the output specification, contains an abstraction of the DMs required to form a particular publication. It is at the views layer that all relevant DMs are extracted from the database and arranged for publication. The views layer provides the end-user with a variety of paths to the right information via a method that best suits the current purpose. Figure 3-3 shows a number of typical views:

• The TOC (Table of Contents) view does not specify a subset of DMs to extract and publish, but does specify mechanisms for ordering and displaying the DMs contained within the database. Only at the TOC level is there an awareness of a required ordering. Early recommendations for the TOC view go no further than suggesting an ordering identical to that of the corresponding paper-based publications.

• The LOI (List of Illustrations) view extracts all illustration DMs from the database and orders them in some way. As with the TOC view, early recommendations merely recreate the structure of equivalent paper-based publications.

• The GLOS (Glossary) view recommends the extraction of all glossary entries from the database and their subsequent ordering. Technical documentation inherently contains a number of specialist terms which are conventionally defined in a separate glossary. The GLOS view provides the recommendations for building that glossary.

• The PROC (procedural) view is a complex view that retrieves DMs relevant to a specific task. There exists a PROC description for each task that an engineer may need to perform, which gathers together documentary and illustrative materials into a single publication. The PROC view hints at the possibilities for document reuse: a single DM may be referenced in

more than one procedural view. A paper-based equivalent contains high levels of duplication to ensure that all printed procedures contain all the required information.

Interactive Electronic Technical Publication (IETP) layer

An IETP is a collection of DMs relating to a pre-determined topic, aimed at being viewed by the end-user.

The lightweight IETP layer contains publication-specific information such as a generated table of contents and the current publication status. Access to a publication is recommended strictly through the IETP layer, which provides access to all the DMs within the specified publication.

3.2.1 The DS0060 Document Module Code

The document module code (DMC) is the central mechanism with which to identify the purpose of each data module. The structure of this 32 character enterprise-specific alphanumeric code is shown in figure 3-4. In order to identify the applicability of a DM to a specific piece of defence equipment (type and model), a model identification code (MIC) (13 characters) is provided. A new MIC is used whenever a new type, model or variant is thought to necessitate establishment of a separate database. To qualify the model identification code a single character material item category code specifies which of the tri-service categories the MIC applies to - one of ’ship’, ’electronic/automated software’, ’aircraft/missile’, ’surface vehicle’ or ’ordnance’.

The Standard Numbering System (SNS) provides a system/sub-system/sub-sub-system breakdown of the equipment identified by the MIC. Where a sub-sub-system does not provide a sufficiently low level of

Information Figure 3-4: The DEF STAN 00-60 Document Module Code (DMC)

breakdown the system difference code (SDC) enables differentiation across parts of the same sub-sub-system. The Disassembly Code (DC) is a two character alphanumeric code that identifies the breakdown of an equipment assembly. As such it both allows an identification of equipment parts and suggests a procedural ordering for equipment disassembly. The DC highlights the way in which a particular code can describe either the equipment or a process on that equipment, depending on the context of the user at the time.

Outside the scope of the current DMC but worthy of note are the additional zoning and access codes that assist in referencing assemblies, access panels and doors within data modules and technical publications. The DMC focuses on functional breakdown of military equipment, but these functional breakdowns may not be of particular use to a mechanic who is looking at a physical embodiment of that equipment. Zoning provides a standardised alternative index into relevant data modules by supplying a physical breakdown of a piece of equipment. Such an alternative view of the equipment is valuable, providing a variety of paths to the right information.

To this point all parts of the DMC describe the decomposition of the equipment it services. The Information Code (IC), however, is used to denote the type of information in the associated data module.

The identification of both product and process is valuable in facilitating retrieval of information fit for a work-based purpose. A general description of a car tyre, for example, is ineffective in trai ning the reader how to change that tyre. The IC encodes the way in which the DM content describes an operation on the equipment identified elsewhere in the DMC. Once fully defined for a particular data module, a DMC describes the low-level part it describes (product) and how it describes that part (process).