The Evolution of the Information Model

Organizing Structures

In the paper publishing world within DND, the Materiel Operations and Maintenance information used "Manual Type" as the major organizing structure for the information. The DND CALS Information model emerged from a project for Low Level Air Defense (LLAD) to analyze these manuals and develop a content oriented DTD from which these manuals, and subsequently other publications such as electronic books and IETMs could be developed.

The focus of the modelling effort was on producing a content oriented DTD along the lines of the J2008 initiative rather than a presentation oriented DTD such as the US CALS 38784 DTD.

Each manual type was specified by a formal D-Specification. The D-Specifications listed the general content of each manual type, while the C-specification indicated how this information should be presented. Document types included in the analysis were:

Duplicate information across manual types was identified and rationalized. Remaining information was organized into a hierarchical equipment breakdown structure (EBS). For example, information which was descriptive material about the entire equipment belonged at the highest node of the EBS, while descriptive information about a sub-component, belonged lower in the hierarchy.

The DND CALS DTD Version 1.02 illustrated below was fractal in the sense that the same information content could be provided as required at any assembly node in the EBS hierarchy. Note that in this release, publishing artifacts such as front and rear matter still remain in the model to support publishing requirements.

DND CALS DTD Version 1.02a

One area which received attention was the apparent dual equipment breakdown structure in this model. The Illustrated Parts List (IPL) which was part of the recursive assembly structure was in itself a recursive assembly breakdown structure. Indeed, even in the list of parts in a callout for a sub-assembly, the Lockheed notation utilized identified connecting parts, and sub-component parts. This notation represented the lowest level equipment breakdown structure in the information. It became evident that these were presentation artifacts only, and there was a need to capturing the underlying information content independent of how it might be presented.

In examining many existing manuals it also became apparent that these two structures were not equivalent. There were components in the IPL which had no descriptive information associated with them other than simple part number, name quantity, and supplier information. Conversely, there was descriptive material about "assemblies" which were not physical assemblies per se. For example, in an aircraft, the hydraulic system "assembly" would have significant maintenance information, yet would not have a single part number (being a collection of subsystems and connections between subsystems).

Choosing the IPL as the template for the EBS tended to result in a very sparsely populated tree structure, with the majority of "assemblies" having only minimal part information. This created significant problems for human navigation of this sparse tree in electronic form, and the production of standard paper CFTO output.

On the other hand, the IPL and indeed the very structure of the information in the manuals is typically an output component of a Logistics Support Analysis (LSA). The LSA defines and optimizes the logistic support requirements for the equipment.. In particular, all significant repairable items (i.e. system, subsystem, assembly, subassembly) are identified. Typically three types of assemblies are identified: physical; functional; and abstract.

A physical assembly is the equipment or any of its sub-assemblies. A functional assembly is identified like a physical assembly for repair and maintenance purposes, although the functional assembly may not have a part number. A hydraulic system is a good example. Hydraulic lines which may be part of a fuselage from a physical point of view, are considered to be functionally part of the hydraulic system from a repair and maintenance point of view. Abstract assemblies can be used for components such as a training module. They also provide a convenient placeholder within the equipment breakdown structure for additional information about an assembly at any level.

The level of repair analysis identifies the type and extent of support required for all repairable items. In addition, all troubleshooting, remove and replace, repair, servicing alignment and adjustment, functional test and checkout, inspection, calibration, and overhaul are decided as well. Since each of these will require textual description, supporting diagrams and other material, the LSA can indeed be considered to be a "preliminary plan" for document component preparation.

The Version 2.0 release of the DND CALS DTD incorporates feedback from multiple field trials in various military sectors (Army, Navy, and Air Force). Functionality has been added and revised. All publishing artifacts have been removed and the content has been arranged under the following major organizing structures.

DND CALS DTD (Assembly) – Version 2.0

In the above, the removal of Front and Rear are obvious examples of publishing artifact removal. Other examples of publishing artifact removal were less obvious.

Troubleshooting information was originally modelled as a standard CALS table, as that is how it is usually published. In Version 2.0 the troubleshooting information (part of service) is modelled as a hierarchy. The information for troubleshooting usually contains: a problem or symptom; possible sources for each problem or symptom; and how to resolve the problem for each source. A hierarchy is clearly the most natural structure for this information. The transformation of this tree structure to a standard CALS table model for paper publishing would have to be addressed somewhere in the overall architecture.

The IPL itself was considered to be a publishing artifact as well. The IPL content is a collection of annotated drawings with associated callout lists. IPL content is now organized under the "descript" element as paired diagrams and callout lists.

SubTrees and Building Blocks

An objective of the publishing architecture is to enable the assembly of subtrees of instances of one DTD (the content-oriented DTD) into instances of another DTD (the presentation-oriented DTD) where those subtrees are valid in both contexts. We will now examine the evolution of these subtrees.

The following represents a key subtree used in Version 1.02a of the DTD.

DND CALS DTD Version 1.02a - Paragrp subtree

The "paragrp" model included the constructs to support hazard paragraphs ( dangers, warnings, cautions), bilingual text (English, French), special paragraphs (examples and notes), as well as lists and figures. By Version 2.0 the structure had been enriched, and the various types of structures specifically named.

DND CALS DTD Version 2.0 - Module Subtree

In Version 2.0, the concept of a building block was introduced to further support re-usability.. Both Module and Task in the above diagram are examples of building blocks. The generic form is:

Building Block Structure

Building blocks are major sub-trees which are typically re-usable text. For example, a maintenance task such as removal of a cover from piece of equipment will immediately precede any task which repairs some equipment behind the cover, and hence will be re-used many times. In a publication, the text to remove the cover need only be authored once, occur once in any particular instance, and be referenced from all other maintenance tasks.