It is well known that the volume of paper-based technical manuals,
engineering drawings, and documentation associated with any complex
amalgamation of weapon systems (e.g., a ship) can be measured
by the tonnage. Converting these documents from paper to an electronic
form has been shown to reduce (a) cost in producing the documents,
(b) storage requirements, and (c) cost of maintaining and updating
the electronic form once it has been converted.
ManTech has been contracted through the Integrated Data Environment
(IDE) contract to design a standards-based approach for legacy
data conversion to Electronic Technical Manuals (ETM)/Integrated
ETMs constructs. This type of approach would help avoid the proliferation
of electronic formats and would facilitate data interchange among
dissimilar automated systems. The result of this design has taken
the shape of a Concept of Operation to be used by Conversion Services
in the Department of Defense (DoD). This conversion service concept
document will address the general conversion processes involved,
techniques used, specifications and standards that may be required,
possible risks involved, how to provide a projected cost for a
conversion project, and other requirements associated with the
conversion effort.
The goal is to define what general conversion processes and support
activities would be required for a conversion service, and how
they would function. The term process or processes
is defined as a series of progressive and interdependent steps
by which an end is attained. In this case, the end attained
will be the completed ETM/IETM system.
This document has been written so that it can be easily adapted
to any technical manual conversion project. The conversion processes
have been designed so that no matter what types of data the user
starts with and what type of ETM/IETM is desired, the general
conversion process steps are the same. The only differences between
processes of the different class requirements are how the
process is accomplished, not what the process is.
Section 2, Conversion Services Support Activities, defines
the management and personnel requirements, Quality Assurance (QA)
and Configuration Management (CM) roles, and the costing matrix
and pricing charts that could be used in determining the projected
conversion project cost.
Section 3, Conversion Process, describes the actual conversion
processes that would need to take place to ensure a complete and
high quality ETM/IETM system when delivered to the customer.
The focus of the concept will be on conversion constructs that
enable users to browse through text and graphics information using
hypertext hot-spots; and to gain interactive presentation of maintenance
information through the use of dialog-driven displays.
The following questions will be answered upon the conclusion of
this effort:
The primary objective for any conversion service is to provide
a top quality product from an economically, highly automated environment.
To achieve this objective several supporting activities must
be in place. Below are the plans of managing such a service,
and the quality and configuration controls that should be in place
prior to any conversion project.
Detailed plans for the supporting activities should be provided
at the start of each conversion project. These detailed plans
would be tailored to the specific conversion project and include
the specific contract requirements requested by the customer.
This management plan provides a summary of the conversion service
organization, process management philosophy, and the plans for
cost control. The management staff in conjunction with the quality
assurance and configuration control personnel will work together
to ensure that each conversion project is managed in the most
efficient fashion to produce a high quality product for the customer.
The project organization will be a closed loop, business engineering
approach that provides the flexible yet disciplined organization
to manage cost, schedule, and quality. It will also provide for
management and reporting progress on each of the processes within
each project.
This type of structure enhances communications between the customer
and conversion service team, and provides a single point of managerial
control. This structure will allow the conversion service to
effectively utilize the experience and talents of all team personnel.
An added value of this type of organization structure is that
it facilitates effective daily interchange of information relating
to the individual processes. This availability of information
will enhance the project's productivity and quality.
Because of today's requirements for reducing cost and time and
because every conversion project will be different, each conversion
project will require detailed planning. Each assigned conversion
project manager will develop and maintain a sound road map leading
to the delivery of the product within cost and schedule and at
the highest standard of workmanship.
Figure 2.1.2-1 presents the overall approach to planning and management
of a conversion project.
As the initial analysis process is executed and further guidance
is received from the customer, detailed plans will be developed
for each step within the conversion process, within each individual
conversion project. These plans will provide two advantages:
Maximization of Resource - As the steps
within a process are completed, resources will be immediately
assigned to other related areas, thus avoiding waiting for work
and enhancing the skill utilization.
Enhancement of Productivity - The rapid
transition of personnel to new work immediately upon completion
not only enhances the productivity, but also provides a built-in
risk reduction asset. For example, when a step is completed ahead
of schedule, the flexibility enables the managers to assign knowledgeable
personnel to those more complex processes. Conversely, if a process
requires additional resources or surge support, it can be easily
provided.
By combining project planning, resource management, and productivity
goals, the management can more efficiently manage each project
in the parallel execution environment without reducing quality.
To be successful, a business, must employ highly qualified and
motivated personnel. Besides the project manager who must maintain
an in-depth knowledge in the ETM/IETM environment, several key
areas of support must be filled with highly skilled personnel.
All personnel assigned to a conversion project should, at a minimum,
maintain a basic knowledge in ETM/IETM design and requirements.
Figure 2.1.3-1 provides the basic skills required for each
job category. Notice that many of the job categories required
the same skills. This demonstrates the maximization of resources
and enhancement of productivity that was described above.
An accounting system that will comply with the cost/schedule control
systems criteria required by the contracting agent will be selected
to provide work progress as well as cost, schedule, and technical
performance data in a timely, valid, and audible fashion.
Within this accounting system, each conversion project and its
individual processes will be assigned unique identifiers for cost
accumulation purposes by the conversion service accounting department.
This will allow the project manager to readily determine cost
on each individual conversion process and on the overall project,
thus permitting quick and accurate budget comparisons (projected
cost to actual cost) to identify trends and implement any needed
corrective actions for current and future conversion projects.
The Quality Assurance Plan briefly describes the QA activities
associated with the conversion, development, and delivery of all
ETM/IETM projects. The goal of the QA team is to ensure that
the products are consistent with design requirements, adhere to
all specifications and standards that apply to the system and
its environment, and that all contract requirements have been
met.
QA will ensure that the conversion of legacy data, development
of ETM/IETM systems, software, and hardware products developed
for the customer comply with contractual requirements, specific
task directives, user needs, and the system engineering standards
and practices of the project. This plan briefly describes the
procedures for the audit/evaluation and reporting of the development
activities for deliverable and interim deliverable products, as
well as for evaluation of management and planning. QA will also
participate in audits, reviews, and development configuration-control
committees.
The QA team will be responsible for ensuring performance of the
ETM/IETM system prior to delivery. The QA team will report system
status and performance assessments to project management in conjunction
with, but independent of, system conversion team design and development
status reporting. The QA team's relationship to other organizational
elements is shown in Figure 2.2.2-1.
QA begins with the detailed task planning process. Figure 2.2.3-1
provides an overview of the quality control process. QA will
analyze each Statement of Work (SOW) task to identify the quality
guidelines, controls, and review processes that will be applied
by each conversion process within each individual SOW task. Once
identified and assessed for applicability and suitability, these
quality criteria will be applied to the conversion project leader
and each member of the conversion work team. The quality criteria
(as modified for each conversion project and conversion process)
will include:
Routinely, QA will not limit quality checks to the product. QA's
task planning will include cost and schedule, specific productivity
goals, responsiveness to the clients, and professional performance
by employees, plus the accuracy, timeliness, and scope of the
team's progress reporting. In short, the QA process would be
a full Total Quality Management (TQM) effort and applies to each
employee and the total scope of the conversion effort.
The QA team will be formed from internal staff contingent on the
specific QA methodology and criteria established in the QA planning
process. Reviewers will be assigned by name and required to review
the applicable standards. A typical review checklist applicable
to an ETM/IETM deliverable is shown as Figure 2.2.3-2.
QA's reviews are scheduled during the task planning process at
specific completion points (i.e., Content Conversion; Tag
and Link processes; and Validation, Verification, and Acceptance)
and always include a final pre-delivery QA review of the entire
product. The number of reviews will be determined by the complexity
of the conversion project as a whole, the specific processes,
the functional requirements and ending ETM/IETM system, and the
results of the preceding review. Should the review indicate serious
failure in the quality, additional reviews may be scheduled (1) to
ensure that corrective actions have been taken and (2) to
ensure that no new quality failures have occurred. Corrective
action may also include counseling, additional training, or replacement
of individuals.
With the proposed cancellation of MIL-Q-87270, the validation
of ETM/IETMs has been left to the performance specifications MIL-M-87268
and MIL-D-87269. However, several items within MIL-Q-87270 should
still be considered when developing and implementing a validation
plan for ETM/IETM systems. Some of those items are listed below.
a. Titles and identification numbers (when available) of all deliverables to be validated.
b. Schedules for validation steps.
c. Cognizant contractor organization and personnel responsible for accomplishing the validation effort.
d. Site locations, support equipment, facilities, test equipment, materials, contractual end items, and tools required during validation.
e. General characteristics relating to skill level of target audience type personnel to be used in validation of procedural Technical Information (TI).
f. Identification of next higher assembly(ies)/system(s) required to support the effort.
g. Associated TI recommended for concurrent or consecutive validation.
h. Special safety precautions.
i. Any special environmental requirements.
j. Record keeping system to be used in validation.
k. How validation of procedures is to be accomplished.
l. A proposed fault simulation list for use in validation of troubleshooting procedures.
m. Approach to evaluation of usability of the ETM/IETM as generated by the conversion service; specifically, establishment of the adequacy and accuracy of information access procedures, and identification of any potential man machine interface problems involving effective use of the ETM/IETM on the Customer specified Electronic Display Device (EDD).
n. Application of results of tests performed during the validation process to the correction of deficiencies.
o. When required by the contract, a technical approach to validation of the ETM/IETM Database, differentiating between computer supported technical procedures (e.g., automated checking routines) and those to be carried out by humans (e.g., reading and comparing database entries with external data).
p. When required by the contract, a technical approach to validation
of any automated ETM/IETM compilation process.
When transforming or converting Technical Manual (TM) or ETM data
to a format that does not comply with the IETM specifications,
a validation plan that contains all of the above elements may
or may not be necessary, depending on the specific contractual
requirements. In any case, however simple or complex the validation
process is expected to be, the creation of a comprehensive and
concise validation plan is certainly a good idea. Some of the
more important elements that a validation plan for converted ETM
data may ultimately need to address are:
The first element that is suggested for a validation plan is certainly
the most important. The technical information must be valid.
How the conversion service chooses to validate the converted
data depends not only on the automation involved and the similarity
of the presentation, but also on how much confidence the conversion
service has on its own conversion methodology.
The second element is important because the EDD that is used in
the field may have a smaller screen size, the screen may be of
a lower resolution, and it is important to note that these two
simple factors may ultimately be much more of a hindrance to the
technician than using a paper manual. It is also important to
recognize that size, weight, and connectivity requirements may
cause additional problems for the technician.
The third element that the validation plan should address is the
valid operation of the view packaging process (if one is used).
The view-packaging process in this sense refers to the extraction
of particular maintenance tasks from a central ETM/IETM database
to perform maintenance (i.e., similar to selecting an appropriate
manual or work-package). The important thing here is to ensure
that the ETM/IETM data are exported properly and that there is
a sound methodology for handling the inevitable broken links that
will occur as a result of extracting only subsets of the ETM/IETM
database.
The view-package extraction process described above brings to
mind the concept of extracting ETMs from an Integrated Weapon
System Database (IWSDB). Although integrated environments are
generally desirable, they can create difficulties for validation.
Some members of the Tri-Service Working Group (TSWG) indicated
that validation problems could arise if all ETM data are extracted
from various disparate databases at presentation time. In short,
in terms of validation, stand-alone ETMs, where the ETM data can
be strictly controlled, are favored.
The Configuration Management Plan establishes the plans for CM
to use during the development of all ETM/IETM items, which may
include technical manuals (paper or electronic), computer software
(developed or Commercial OffTheShelf (COTS)), hardware,
and associated documentation.
The purpose of the Configuration Management Plan is to define
guidelines and responsibilities for administering the CM of all
converted data, application software, hardware, and supporting
documentation throughout the project life-cycle. This may also
include the storage of pre- and post-converted data for the customer.
This plan will ensure complete and accurate correlation between
converted data, software, and descriptive documentation to facilitate
pre- and postdelivery maintenance by conversion support
personnel. All changes to data, application software, and associated
documentation will be formally controlled in accordance with the
Configuration Management Plan.
Configuration Management ensures that converted data, software/hardware
products, and accompanying documentation to be delivered to the
customer are maintained under configuration control and are consistent
with design and contract requirements. This will provide the
scope of effort to coordinate and maintain life-cycle configuration
management support on all conversion projects. CM guidelines
are also provided for use by project team members as needed.
The responsibilities of CM include:
The developmental configuration composed of all established baselines
is affected by two types of development:
The CM team will maintain all project baselines including Project
TM Data Baseline, Project Product Baseline (i.e., QA tested),
and a Customer Release Product Baseline (i.e., tested and customer
accepted). Figure 2.3.2-1 shows the baselines designed for
all conversion projects and, in general, the directory structures
of data and software configuration items under configuration control.
The Project TM Data Baseline will contain the electronic version
of the technical manual. These data could come in two ways:
either in electronic form from the customer or in electronic form
that has been scanned, converted in-house, and content reconciled
by QA. Either way, this electronic form will be the ground floor
baseline for the conversion project. The naming convention used
for these directories will include the individual project name,
then either text or graphic indicators.
Under the Project TM Data Baseline directory will be separate
directories containing the text files and the graphic files.
These are kept separate because they are processed differently
when creating an ETM/IETM system.
The Project Product Baseline will be the completed ETM/IETM data
(Standard Generalized Markup Language (SGML) and/or database)
and conversion software used in any automated processing. Before
the data or software is admitted to this baseline, it must pass
all browser testing, system QA, and validation/verification testing.
The Project Product Baseline, in all likelihood, will become
the source for in-house service bureau installation of the ETM/IETM
system.
Under this directory structure, CM will control the final product
ready for acceptance testing and any conversion software developed
during the conversion project.
The Customer Release Product Baseline is established upon successful
completion of the delivered ETM/IETM system and full system acceptance
by the customer. This baseline includes the TM tagged data and
all associated files and software that would be required to maintain
the system.
The purpose of configuration control is to regulate changes to
the project configuration items. The initiation of a proposed
change is a coordinated effort between project teams, the customer,
the quality control manager, and the configuration manager. Configuration
control is exercised over those changes that have an effect on
the baseline of any configuration item. The control procedures
include an active status detailing what the proposed change is,
where it is in the corrective-action cycle, and specifically what
has been done.
Change Proposals constitute a change in any of the project baselines
and may be initiated at any time by the customer or by the conversion
staff. Any changes proposed will include identification of the
configuration item, technical description of the change, how the
change improves the configuration item, need for the change, and
requirements impacted in accomplishing the change.
System design, data structure, and/or user documentation may be
affected by change proposals and must be researched when the impact
on the total system is assessed. All change proposals require
thorough assessment to determine full impact on the TM data, conversion
software, and the ETM/IETM system. An impact assessment will
be completed for each proposed change as assigned by the project
leader. This assessment will include identification of the units
affected, procedures that are candidates for change, benefits
that accrue, estimated cost, duration of making the change, urgency
for making the change, impact on current workload/delivery schedule,
and recommendation for disposition.
All change proposals will be approved by in-house management and
the customer prior to incorporation.
Formal reviews will be conducted at appropriately scheduled intervals
in the conversion project life-cycle. Configuration management
members will participate in all formal and informal reviews and
walkthroughs that will be conducted to evaluate the content of
the design, mapping, data conversion, linkings, and validation
processes for compliance with Government and/or customer-mandated
requirements and standards, as well as to assure adherence to
the conversion service internally established guidelines for ETM/IETM
system development.
Preparation for all deliveries will be initiated well in advance
of the scheduled delivery date. In concert with the conversion
team, QA personnel will prepare test scripts and checklists, and
CM personnel will monitor progress on all components of the projected
delivery. Prior to the delivery, all materials will be assembled
for the final check by CM and QA. Through advanced planning,
careful organization, and full team work of all conversion team
members, deliveries of superior quality ETM/IETM systems will
be made on schedule.
Before the first letter of a technical manual can be converted
into a selected ETM/IETM system, the conversion service must provide
the customer with a projected cost for the entire conversion project.
The following paragraphs will describe what must take place to
provide that projected cost.
To develop an accurate price on any conversion job, the conversion
service personnel must have a full understanding of the task at
hand. They must understand the functional requirements for the
target system and the type of data they will be working from.
A costing matrix has been designed so that it may be used for
any type of conversion project. Appendix A contains this matrix.
When reviewing and/or completing the cost matrix prior to the
start of the conversion process, some areas will be filled out
by the customer and other areas will be filled out by the conversion
service staff (which areas will rely on the knowledge of the customer).
Completing the costing matrix will not take place until after
the preliminary document analysis process (3.3). In some cases,
it may not be completed until after the software and Data Type
Definition (DTD) selection processes (3.4) have been concluded.
The first of three pages of customer information is self-explanatory.
These pages provide the conversion service with customer information
such as addresses, phone numbers, and Points Of Contact (POC).
It also provides the service with customer projected start and
stop dates and standard/specification requirements that may be
required. In turn, the conversion service will give the cost
matrix a Project Number (PN). This number will allow the staff
to track the costing effort and conversion job by a single number.
This number will be used in the cost/schedule control system
used by management and the accounting system.
The source media and electronic source data section will be completed
by the customer. This information will provide the conversion
staff an early feel for what they will be working from. This
information must be accurate because it will be used in determining
the projected conversion cost.
The delivery media information will be provided by the customer,
also. The conversion staff may aid in this decision if a more
cost efficient delivery media can be used. This information must
be accurate because it will be used in determining the projected
conversion cost.
It should be noted that the decision of input and out media may
cause the conversion service to purchase additional hardware and/or
software, or to go to an outside vendor to accept and complete
the given project. The issue of cost for these items will be
listed as separate line items on the pricing chart.
The information provided through the answers in this section will
give the conversion service staff a look and feel for the conversion
project as a whole. The customer should be able to complete this
entire section. If the customer is unable to complete any part
of this section, the conversion service staff will provide the
additional help required to complete it. The answers given in
this section must be accurate because they will influence the
projected conversion cost.
The information provided through the answers in this section will
provide the conversion service staff with the detailed requirements
and specifics for the conversion project. The customer and the
conversion service staff will complete this section together.
Determining who will supply the necessary information will be
decided by the knowledge of the customer. Answers to some of
the issues will not be determined until after the preliminary
document analysis process (3.3) and possibly the software and
DTD selection process (3.4). The answers given in this section
must be accurate because they will heavily influence the projected
conversion cost.
A pricing chart will be completed when all of the necessary information
has been included in the costing matrix. The pricing chart will
contain a line item listing with Unit Costs, Unit of Measurement,
and Estimated Units per line item. Space will also be available
for any additional line items that may need to be included apart
from the original list (e.g., software and hardware purchases).
The bottom line will provide the customer a projected cost for
the conversion project. An example of a blank pricing chart is
provided in Appendix B.
This chart has been designed using Microsoft Excel spreadsheet
software so that the calculations will be done automatically.
This will also allow the conversion service to either use its
own unit costs and/or adjust the unit costs when necessary (i.e.,
hourly rates, rates for the conversion of tables, lists, graphics,
or text). The line items Total will be derived by multiplying
the Unit Cost by the Estimated Units. The Projected Cost Total
line item will be the sum of the Total column.
It should be understood that the pricing given in the pricing
chart will be based on the limited TM samples provided by the
customer, functional requirements defined, and the information
provided in the costing matrix. Should any of this data vary
or demonstrate an impact on the design or the conversion process
steps, the projected cost would need to be re-evaluated. These
changes may cause a work slow down or even a stoppage until re-adjustments
have been made and customer approval has been given.
Conversion from one type of data to another that complies with
both the CALS standards and the IETM specifications is neither
a simple nor an exactly specifiable process. The primary difficulty
stems from the fact that this process essentially requires the
extraction of more detail from less. Another difficulty is that
because of the high rate of change and technical innovation in
the computer hardware and software industry, most of the different
Types or Classes of electronic technical manuals are now and likely
to remain somewhat broadly defined. These broad definitions,
in fact, make it very difficult to specify a single set of specific
conversion steps that could be used to go from one data type to
another, and at the same time be applicable for all instances
of those particular data types.
When considering converting between Types or Classes of paper
or electronic technical manuals, the conversion process is much
more than simply a set of procedures for data translation. The
conversion process must begin with an in-depth evaluation of the
Type or Class of technical manual that is most suitable, both
functionally and economically, for the system that it is to be
created for. The economical considerations are very important
because, depending on the desired target data type, there can
be significant differences in the level of expertise, the amount
of time, and hence the cost required to carry out the conversion
process. It is important to note that when converting to non-page-based
electronic formats, even if the desired target data type consists
of SGML files, the conversion service must consider how that data
will be both authored and presented.
It is important to understand before any conversion processes
take place that the philosophy of "one size fits all"
does not apply in the ETM/IETM world. Every system has the possibilities
of being different due to the functional requirements established
by the customer, the data being converted, the environment the
system will be used in, and the end-user's knowledge and capabilities
using it.
The alternative to establishing precise conversion procedures
for all different implementations is to define a general approach
that deals with those aspects that does not depend on the format
of the data or the electronic presentation system that is used.
After detailed analysis, it has been determined that no matter
what types of data the user starts with and what type of ETM/IETM
system the user desires, the general conversion process steps
are the same. The only differences between processes of the different
class requirements' is how the process is accomplished,
not what the process is.
This section will discuss a general approach to legacy data conversion.
Figure 3.0-1 demonstrates the flow of what must take
place in any conversion project. The following paragraphs will
describe each process block of the diagram and in general terms,
how the steps within each must take place in order to design,
convert, and implement any ETM/IETM system. Where specific processing
is required due to the selection of functional requirements, that
information will be described in more detail.
The first step in the conversion process is to determine all
functional requirements for the ETM/IETM system. Functionality
can range from modest use of raster scanned documents to integrated
databases that are paired with expert systems. One must consider
all of the factors and attributes required before selecting the
highest level of functionality possible to meet the users' requirements
within cost constraints. When considering conversion between
paper and electronic technical manuals, the conversion process
and a conversion plan are much more than simply a set of procedures
for data translation. The conversion process must begin with
an in-depth evaluation of the classification of technical manual
that is most suitable, both functionally and economically, for
the system that is to be created. The economical considerations
are very important because, depending on the desired target, there
can be significant differences in the level of expertise, the
amount of time, and the cost required to carry out the conversion
process. It is important to note that when converting to non-page-based
electronic formats, even if the desired target consists of SGML
files, the conversion service must consider how that data will
be both authored/converted and presented.
The decision on what type of functionality to select has critical
impact on the following:
The range of solutions for digitizing and electronically presenting
TM data is expanding at an increasing rate. To deal with this
problem, basic functional requirements have been defined and tagged
into ETM/IETM classifications. The following paragraphs describe
the basic functional requirements for ManTech's ETM and IETM classes.
The Classes are defined in fairly broad, general terms that necessarily
overlap. They facilitate discussion of options and differences,
but they are insufficient to serve as a basis for contractual
use. This process of identifying functional requirements should
be made without referring to the below set of class definitions.
Naval Surface Warfare Center (NSWC) Port Hueneme has developed
an Integrated Electronic Technical Manual Process Plan (IETMPP).
This plan was initiated to ensure that all programs use a comprehensive
approach and standard methodology to create or convert to digital
TMs with electronic display devices. This plan contains a section
that aids the program manager in selecting the most appropriate
and economically affordable ETM/IETM system. It is recommended
that the customer consult Sections 2-4 of the IETMPP before
determining the basic functional requirements of ETM/IETM for
the project.
Paper Only (a TM data type, not an ETM data type).
This data type is a non-SGML electronic page turner that consists
of pure raster. This is the next logical step above a paper document.
It is the cheapest method to convert legacy data to data that
can be stored and accessed electronically. The raster scan must
be at a resolution appropriate for human readability and comprehension.
With this data type, it is simple to assign a page number to
each page image and provide links from the table of contents and
index. This data type would be desirable either for older systems
that will soon be discontinued or for systems that rarely need
to be serviced. Black and white raster page images can be stored
using Consultative Committee on International Telegraph and Telephone
(CCITT) 4 raster (MIL-R-28002). Gray-level or color raster page
images must be stored using raster primitives in Computer Graphics
Metafile (CGM) files; they cannot be stored using MIL-R-28002.
Table 3.1.2-1 lists the requirements for Type MA+ data.
| Type MA+ Data | Fixed Length Electronic Page Image Technical Manual |
| Display Media | Electronic. |
| Data Primitives | Graphics (CCITT 4 or CGM). |
| Data Organization | Electronic replica of paper manual.
Recognition of page numbers, index entries, and table of contents. |
| Dynamics | Access pages via intelligent index. Limited use of hotspots. |
| Data Format | Raster scan of paper pages. |
This data type is simply an electronic page turner that was constructed
with SGML. This is the next logical step above a raster page
turner. The important difference between this and the raster
page turner is that because the text is now in SGML, things such
as word searches, automatic indexing, and other text processing
algorithms can be executed on the data. After completed, formatting
information can be applied with a Formatting Output Specification
Instance (FOSI) for either electronic or paper presentation as
listed in Table 3.1.3-1.
| Type MB Data | Fixed Length Electronic Page Technical Manual |
| Display Media | Electronic. |
| Data Primitives | Text.
Tables. Graphics (Initial Graphics Exchange Specification (IGES), CCITT 4, CGM). |
| Data Elements | SGML tagged ASCII text. Limited format tagging. Structure tagging (chapters, sections). No content tagging required. No Hypermedia/Time-based structuring language (HyTime) required. |
| Data Organization | Redundant elements. Integrated and/or non-integrated files. Format information may be applied with a FOSI. |
| Dynamics | Limited hyperlinking via the presentation system (not authored in). Non-interactively authored; viewer may provide text processing capabilities. Displayed pages can be printed. Static graphics with or without hotspots. |
| Data Format | Possibly SGML files. Possibly Compiled SGML/FOSI files (e.g., Postscript). |
Type MB+ functionally is a hypermedia document that may be either
page-oriented or frame-oriented. From a conversion standpoint,
Type MB+ can be created by simply taking a regular Type MB SGML
file and augmenting it with hyperlinks/hotspots. The hyperlinks
may be implemented through the use of SGML's IDREF/CONREF to ID
pointing facility, or through HyTime hypermedia links. This is
the next logical step to increasing the utility and information-richness
of a document. The display of Type MB+ data does not have to
remain page-based. If all page breaks and references to pages
are removed from the Type MB data, then an SGML/HyTime compiler
could be constructed such that each chapter or section could be
represented in one window (frame) with scrolling capabilities
as listed in Table 3.1.4-1. Implementing the hyperlinks
would require some comprehension of the TM content, but domain-specific
experts would not be required. Note that HyTime coordinate and
quantum-based addressing is not recommended for hyperlinking of
text here, because of the possibility of updates and changes to
the original SGML file.
| Type MB+ Data | Electronic Hypermedia Technical Manual
Possibly fixed-length pages Possibly frame-based Possibly an electronic scrolling document |
| Display Media | Electronic. |
| Data Primitives | Text. Tables. Graphics (IGES, CCITT 4, CGM). Audio. Video. Processing. |
| Data Elements | SGML tagged ASCII text. Limited format tagging. Structure tagging allowed. No content tagging required. HyTime-compliant hypermedia links preferred but not required. |
| Data Organization | Redundant elements. Integrated and/or non-integrated files. Format information may be specified with a FOSI. Traversement through troubleshooting trees and diagnostic data with hyperlinks. |
| Dynamics | Extensive use of hotspots and hyperlinks which are authored in: Displayed windows can be printed. Non-interactively authored with an interactive hypermedia presentation system. Text, Tables, and Graphics may appear in the same or in separate windows. Static graphics with or without hotspots. |
| Data Format | SGML files. |
This is very advanced and significantly different from the previous
type. This is the first data type that is strictly system and
task-oriented. It will require organization of technical manual
data into a system, sub-system, sub-assembly hierarchy with the
appropriate tasks and all associated information for each. This
data type is basically an SGML instantiation of MIL-D-87269 that
is valid for all maintenance levels and also allows for less content-intensive
tagging. One of the key features that separates this type from
the previous types is the logical NEXT function. Logical NEXT
allows for efficient authoring of alternative information (i.e.,
unit level tasks versus intermediate level tasks) and rule-based
diagnostics. Depending on the format of the original, correct
placement of Type MC tags may require full comprehension of the
TM content as well as domain-specific experts. Table 3.1.5-1
lists the functional and data requirements for Type MC.
| Type MC Data | Frame-Based Electronic Hypermedia Work Package |
| Display Media | Electronic. |
| Data Primitives | Text.
Tables. Graphics (IGES, CCITT 4, CGM). Audio. Video. Processing. |
| Data Elements | SGML tagged ASCII text. Frame tags and embedded scripting tags (e.g., IF-THEN) used for presentation. Minimum requirements are basic set of system and task-oriented content tags as in MIL-D-87269. Tagging of descriptive, procedural, part, and troubleshooting information as in MIL-D-87269. Limited format tagging. Content tagging as in MIL-D-87269 to the extent desired. HyTime-compliant hypermedia links. |
| Data Organization | Redundancy reduced to the extent possible. Traversement through troubleshooting trees and diagnostic data with context-dependent filtering capabilities rather than hyperlinks. Alternative information authored in using context-dependent filtering capabilities. |
| Dynamics | Context dependent filtering. Dialog-driven interaction and branching. Interaction functions per MIL-M-87268 to the extent possible. Extensive use of hotspots and hyperlinks that are authored in. Displayed windows can be printed. Interactively authored and displayed with an interactive hypermedia presentation system. Text, Tables, and Graphics may appear in the same or in separate windows. Logical NEXT and BACK function. Runtime variables maintained in a state table at presentation time. Dynamic and/or static graphics with or without overlays and hotspots. |
| Data Format | SGML files. |
This is specification-compliant IETM data that does not necessarily
consist of SGML files. The ETM data objects are authored to and
are accessed through either a relational or an object-oriented
database. Although this data type may not necessarily consist
of SGML-tagged objects, the database information should be named,
attributed, and hierarchically structured as described in MIL-D-87269.
This data type is appropriate for creating and maintaining data
that will be required by multiple, interrelated ETMs and IETMs.
As in the Navy Class 4 IETM definition, the data elements that
will constitute a particular IETM are extracted, compiled, and
formatted to create a "View Package" run-time version
of the database that can be processed for display (in accordance
with MIL-M-87268) by suitable presentation system software. An
important issue in terms of CALS-compliance here is that a system
utilizing Type MC+ data should be capable of importing and exporting
its ETM/IETM data as tagged SGML files (similar to Type C) so
that different authoring/editing/viewing systems with unique databases
can easily share/exchange data. Table 3.1.6-1 lists the
Type MC+ requirements.
| Type MC+ Data | Specification-Compliant IETM |
| Display Media | Electronic. |
| Data Primitives | Text.
Tables. Graphics (IGES, CCITT 4, CGM). Audio. Video. Processing. |
| Data Elements | Fully attributed database structure per MIL-D-87269.
Content-specific layer developed using the generic layer in MIL-D-87269. Authored to a favorite DataBase Management System (DBMS). |
| Data Organization | Redundancy reduced to the extent possible.
Traversement through troubleshooting trees and diagnostic data with context-dependent filtering capabilities rather than hyperlinks. Alternative information authored in using context-dependent filtering capabilities. |
| Dynamics | Context dependent filtering.
Dialog driven interaction and branching. Interaction functions per MIL-M-87268. Interactively authored and displayed with an interactive hypermedia presentation system. Logical NEXT and BACK function. Dynamic graphics with overlays and hotspots. |
| Data Format | No restriction on database format.
May or may not have SGML import or export capability. |
It is feasible to incorporate supplementary functional capabilities
to the basic ETM/IETM system. Once the user has determined the
basic requirements for the system, (e.g., data formats, tagging
requirements, etc.) the user may want to include such items as
interactive diagnostics and Logistics Support Analysis Record
(LSAR) data. These additional requirements should be defined
prior to any conversion or system development. However, these
additional capabilities can be linked into the ETM/IETM at a later
date.
One system of recent delivery to the Navy is the Phalanx Integrated
Maintenance System (PIMS). This system has been classified as
a basic class 2 (using the Tri-Service Working Group ETM/IETM
Classifications) with additional capabilities of a higher level
(Integrated Diagnostics System, Integrated Maintenance System,
and links to the 3M Database). This is an excellent example of
crossing ETM/IETM class boundaries to design a complete system.
It is important to note that as the user increases the functional
capabilities of the ETM/IETM system, the user also increases the
time involved, thus increasing the total cost of that system.
The IETMPP contains a long list of factors that should be considered
when developing an IETM system. The following are only a few
of those factors that will aid in the development and implementation
of an appropriate IETM system:
Samples of the document, whether paper or electronic, will be
required at the onset of any conversion project. This is necessary
in order to accurately gauge the quality and complexity of the
product being converted. These samples will be used in the preliminary
document analysis process, DTD development/selection, and mapping
process. Those processes are described in the following paragraphs.
The samples should include, at a minimum, examples of text, graphics,
tables, and any other unique items contained within the document.
A major component in the conversion process is determining the
quality of the data being converted. The quality will have an
impact on the conversion process by way of time, skills, and software
required to convert the data into a suitable format for ETM/IETM
development. The end resulting factor for the quality of the
initial data will aid in the determination of the final conversion
schedule and cost. Note that the poorer the quality, the more
time is required for conversion, and thus the higher the cost.
Complexity can be measured by the number and kind of mappings
required for a conversion project. A mapping is the relationship
between composition codes in the original document and SGML tags
in the converted document. Complexity can be considered an essential
portion in determining cost for a conversion project and calculated
by the number and complexity of the mappings. Section 3.3,
Preliminary Document Analysis, and Section 3.6, Define Mapping
Source to Target DTD(s)/Schema(s), discuss the mapping requirements
in more detail. Note that the more complex, the higher the cost.
The preliminary document analysis process is the activity that
will identify, analyze, and address all issues involved with the
document design. This process will provide the understanding
of all uses of the information contained in the document and identify
all components of information needed to support an organization
in order for it to complete its mission. The conversion team
will consider all of the end-user's needs and the level of detail
required during this process.
The preliminary document analysis process will include analysis
of a representative sampling of the document information that
was gathered in the previous process (3.2 Gather Samples of Paper
and Electronic TM Data). This may include scanning printed pages
to check quality, reviewing composition and processing documentation,
editorial style manuals, database definition documentation, internal
and external standards, and possible interviews with authors,
editors, subject experts, and technical staff from the original
composition departments or organizations. This process will also
separate the TM data into reusable work packages that will be
stored in the database, with aid from the subject experts, if
it is required through the functional and/or contract requirements.
During the document analysis sessions, several questions should
be asked to determine the structure, content, and order of the
document and aid in the selection of the DTD and system software.
These questions will be directed to the subject experts and end
users (if different from the experts). Questions about the document
should include the following:
Questions about the design of the system should include the following:
Another output of the preliminary analysis process is the pre-processing
for manually entered data. If hard copy will be the source of
the conversion effort, and if it has been determined that the
quality of the document is not high enough for the scanning thus
causing the decision for manual entry of the document data, here
is where the pre-processing of the data will be accomplished.
This step will include both text and graphics. This step consists
of marking up a hard copy of each work package developed during
this phase to indicate what information would be inserted into
the database.
The graphics pre-processing involves assigning control numbers
to graphics such that they could easily track the resultant files.
It also requires a technical writer to circle and label those
graphical elements that would be included in the database and
those elements that would be ignored.
The text pre-processing involves marking up the paper manuals
to indicate the appropriate elements that the paper information
belonged to and also the text that would be deleted. The text
pre-processing also involves establishing text to graphic links.
After the graphics are broken up and named in the graphic pre-processing
step, the technical writer will indicate on the text manual where
the associated links to graphic elements should be placed.
The results of the preliminary analysis may include any combination
of the following: a preliminary selection of a DTD or a draft
DTD, textual descriptions of the structure of the document and
elements, graphic diagrams structure and elements, link specifications
between document elements and graphic elements, sample marked-up
pages, and/or sample tagged data.
At this point of the conversion process, several major decisions
will be made. The selection of the DTD or Schema used in the
creation of the ETM/IETM in conjunction with the authoring and
viewing software is dependent on the results from the Determine
Function Requirements (3.1) and the Preliminary Document Analysis
(3.3) processes.
Selecting DTDs and designing Schema(s) are processes that are
independent of each other. DTDs are required to describe the
document model where the Schemas describe the content data model.
DTDs will be used in all ETM/IETM system designs. Schemas will
be used only if the functional requirements of the system direct
the data to be stored in a database environment. Usually, a database
is used only in the higher classifications of IETMs.
As defined in "The SGML Implementation Guide" by B.
Travis and D. Waldt, a document type definition is "Rules,
determined by an application, that apply SGML to the markup of
documents of a particular type" and "the set of SGML
declarations that describes the document model."
When making a decision on the DTD, one must understand the issues
behind either selecting an existing general-purpose DTD, developing
one in-house, or customization. Several general-purpose DTDs
already exist in today's market place. Some are industry-specific
applications such as those used by the DoD or Air Transportation
Association (ATA), and others that are more generic in nature
are intended to be used by any type of publishing organization.
The David Taylor Model Basin (DTMB) maintains an electronic repository
of DTDs and SGML tags and constructs for re-use by Navy activities
in implementing digital technical manual applications. The following
DTDs can be retrieved from the Navy CALS DTD Repository:
FOSIs for the first two DTDs are currently being refined for use
with ArborText Adept Publishing Software. The World Wide Web
(WWW) Uniform Resources Locator (URL) address for the Navy CALS
DTD Repository is: http//navysgml.dt.navy.mil/repository.html.
Other non-Navy DTDs are also available on the WWW for public
use.
Before selecting a general purpose DTD, the conversion service
will need to consider the following issues:
If it is determined that the selected DTD will fit the desired
purpose of the ETM/IETM system and it will be supported by the
selected software used in the design, conversion, and display
of the ETM/IETM, the appropriate DTD has been selected.
If a general purpose DTD is close but not quite adequate for the
desired outcome, then customization will be the next option to
consider. Customization of a DTD is a common step in developing
an ETM/IETM system. The saying of "one size fits all"
does not apply in the ETM/IETM world. Customizing aids in achieving
processing efficiency and reduces the amount of design work required
up-front.
Several existing conversion projects have taken this approach.
The LM2500 Gas Turbine project used the MIL-M-28001B DTD as a
baseline and then modified it to generate a smaller subset to
allow for rapid, low cost conversion. Then when creating view
packages using the database data, they used subject experts to
create an IETM DTD using a small subset of tags from the MILD87269
DTD. The F-16 Integrated Maintenance Information System (IMIS)
conversion project used the MIL-D-87269 DTD with very little modification.
Designing a DTD from scratch can be very costly to develop depending
on the complexity of the DTD. Before considering this option,
the conversion team will look at existing DTDs for selection with
possible customization in order to save time and money.
A schema is a description of an entire DataBase (DB) structure
that is used by the DBMS to maintain a DB. The design of the
schema can be either relational, object oriented, or other, depending
on the design of the system and, to a lesser extent, the class
of the IETM. It should be noted that DTDs and additional software,
either developed internally or COTS, would be needed to import
and export instances of the data to/from the DB.
Currently, there are three entities that can be placed together
to complete a system. These entities are the DB, the presentation
system, and the importing/exporting system.
In one type of configuration, the DB and presentation system are
used together. The presentation system would directly access
the DB to present the ETM. This means that a DTD would not be
needed, nor would an external SGML file. The database and presentation
entities would be dependent on each other. Therefore, the presentation
system would not have the ability to use a generic DTD or external
SGML files.
Another type of configuration would consist of a DB and an importing/exporting
system. The importing/exporting system would access the DB to
pull out the requested data needed to generate the SGML file(s).
A DTD would be needed to form these files and, in turn, would
be needed for the targeted presentation system. In theory, the
SGML files could be produced for any DTD selected. This theory,
however, has not been proven as of yet. It would be possible
to design an importing/exporting system such that a SGML file
could be produced for a parent DTD and its child's.
An additional feature of the second configuration is that data
could be placed into a DB via the importing/exporting system.
The importing/exporting system would use a specific DTD to break
down the corresponding SGML files. This again, would be hard
to implement unless the DTD was a child of a certain parent DTD.
A multitude of COTS products is available that are relevant to
the creation, display, and conversion of electronic documentation
of many kinds. Complete conversion of a technical manual to a
different level requires the ability to author, present, and transform
data. A complete conversion package must have all three of these
capabilities.
When selecting products for use in any given project, one must establish a list of requirements. Those products that have at least one of the properties given in the list of requirements should be identified as candidate products. To establish a list of requirements, the user considers a base set of standards, specifications, and other documents that may be either useful or necessary in creating an electronic manual (or converting one). A set of requirements for use during the evaluation period should be extracted from these documents. Table 3.4.2-1 contains the base set of military specifications, Table 3.4.2-2 contains the set of military standards and handbooks, Table 3.4.2-3 contains miscellaneous government documents, Table 3.4.2-4 contains relevant non-government documents, and Table 3.4.2-5 contains the set of requirements that would be the bases for COTS product selection. At this point, it is useful to note that all the selected requirements in Table 3.4.2-5 have narrow, well-defined interpretations, except for MILM87268 and MIL-D-87269. These two specifications make it necessary to look beyond normal "CALScompliant" tools and consider other, more general, COTS hypermedia systems.
| TITLE | NUMBER |
| Manuals, Interactive Electronic Technical: General Content, Style, Format, and User-Interaction Requirements for | MIL-M-87268 |
| Database, Revisable: Interactive Electronic Technical Manuals, for the support of | MIL-D-87269 |
| Digital Representation for Communication of Product Data: IGES Application Subsets and IGES Application Protocols | MIL-D-28000 |
| Markup Requirements and Generic Style Specification for Electronic Output and Exchange of Text | MIL-M-28001 |
| Requirements for Raster Graphics Representation in Binary Format | MIL-R-28002 |
| Digital Representation for Communication of Illustration Data: CGM Application Profile | MIL-D-28003 |
| Manuals, Technical; General Style and Format of (Work Package Concept) | MIL-M-81927 |
| Manuals, Technical: General Style and Format Requirements | MIL-M-38784 |
| Quality Program Requirements | MIL-Q-9858 |
| Drawings, Engineering and Associated Lists | MIL-D-1000 |
| TITLE | NUMBER |
| Automated Interchange of Technical Information | MIL-STD-1840B |
| Contractor Integrated Technical Information Service (CITIS) | MIL-STD-974 |
| Abbreviations for Use on Illustrations, Specifications, Standards, and in Technical Documents | MIL-STD-12 |
| Engineering Drawing Practices | MIL-STD-100 |
| Definition of Terms for Automatic Electronic Test and Checkout | MIL-STD-1309 |
| Logistic Support Analysis | MIL-STD-1388-1 |
| Logistic Support Analysis Record, DoD Requirements for a | MIL-STD-1388-2 |
| Human Engineering Design Criteria for Military Systems, Equipment and Facilities | MIL-STD-1472 |
| Quality Assurance Terms and Definitions | MIL-STD-109 |
| Marking Technical Data Prepared By or For the Department of Defense | MIL-STD-1806 |
| Defense System Software Development | DoD-STD-2167 |
| Defense System Software Quality Program | DoD-STD-2168 |
| Automated Data System Documentation | DoD-STD-7935 |
| Department of Defense Continuous Acquisition and Life-cycle Support Program Implementation Guide | MIL-HDBK-59 |
| Directory of DoD Engineering Data Repositories | MIL-HDBK-331 |
| Technical Manuals | MIL-STD-361 |
| System/Subsystem/Subject Number (S/S/SN) Numbering System | MIL-STD-1808 |
| Work Breakdown Structures for Defense Materiel Items | MIL-STD-881 |
| TITLE | NUMBER | SOURCE |
| Information Security Program Regulations | DoD 5200.1-R | Department of Defense |
| Industrial Security Manual for Safeguarding Classified Information | DoD 5220.22-M | Department of Defense |
| TITLE | NUMBER | SOURCE |
| DoD Liaison Recommendation for Hazardous Materials Warnings in Technical Data | Aerospace Industries Association (AIA) PUBS-119 | Aerospace Industries Association |
| Information Technology Hypermedia/Time-based Structuring Language (HyTime) | International Organization for Standardization/ International Electrotechnical Commission (ISO/IEC) IS10744:1992 | American National Standards Institute |
| Information Processing - Text and Office Systems - SGML | ISO 8879 | American National Standards Institute |
| Document Style Semantics and Specification Language (DSSSL) | ISO 10179 | American National Standards Institute |
| Information Processing Systems - Computer Graphics - Metafile for the storage and transfer of picture descriptive information (CGM) | ISO/IEC 8632:1992 | American National Standards Institute |
| TITLE | NUMBER |
| Manuals, Interactive Electronic Technical: General Content, Style, Format, and User-Interaction Requirements for | MIL-M-87268 |
| Database, Revisable: Interactive Electronic Technical Manuals, for the support of | MIL-D-87269 |
| Digital Representation for Communication of Product Data: IGES Application Subsets and IGES Application Protocols | MIL-D-28000 |
| Markup Requirements and Generic Style Specification for Electronic Output and Exchange of Text | MIL-M-28001 |
| Requirements for Raster Graphics Representation in Binary Format | MIL-R-28002 |
| Digital Representation for Communication of Illustration Data: CGM Application Profile | MIL-D-28003 |
| Information technology - Hypermedia/Time-based Structuring Language (HyTime) | ISO/IEC IS10744:1992 |
| Information Processing - Text and Office Systems - SGML | ISO 8879 |
| Document Style Semantics and Specification Language (DSSSL) | ISO 10179 |
| Information Processing Systems - Computer Graphics - Metafile for the storage and transfer of picture descriptive information (CGM) | ISO/IEC
8632:1992 |
Care must be exercised when selecting tools from different companies
to fulfill the needs conveyed by the desired functional and contract
requirements. It is important to note that not all tools can
work together and not all tools support the use of SGML in the
same way (different features are supported, etc.).
Conformance validation testing simply refers to measuring the
degree of conformance of a particular system with its design specification
requirements through the use of test procedures and evaluation
techniques. Passing a conformance test ensures quality products
only to the degree that the design specification requirements
ensure quality products. In other words, conformance tests are
only as good as the requirements specifications for which they
are based. Because the IETM specifications contain some ambiguities
and because test suites (due to practical limitations) almost
always represent less than an ideal set of test cases, passing
a conformance test does not always guarantee that the IETM will
work in the real world. However, striving to adhere to an evolving
set of "core" requirements is a natural method for progress.
It is important that IETM deliverables be tested for conformance
to the IETM specifications (MILD87269, and MILM87268)
because of the highly critical and complex nature of the IETM.
Poorly constructed IETMs can jeopardize human safety, reduce
operational readiness, and lead to excessive end item support
costs. Conformance to the IETM Specifications ensures compatibility
among implementations. IETM Conformance Escort (ICE) provides
developers and/or acquisition managers a way to measure conformance
of IETM deliverables to these specifications; and as a result,
it aids in the evolution of the IETM specifications and resulting
products.
The purpose of ICE is to demonstrate a structured and modular
methodology for the following functions:
This software was designed in support of the Office of the Secretary
of Defense (OSD) CALS Office for the DoD CALS Integrated Data
Environment Project. Contract Number: DAAB1094-D-0503-0048.
To successfully carry out a conversion project, the conversion
team must determine an exact mapping for every unique item that
will change when going from the source to the target. This mapping
must be done at the very beginning. If the authoring and presentation
systems were properly selected after carefully studying the results
from the Preliminary Document Analysis (3.3) phase, then there
should be no significant surprises during the mapping stage.
Note that the mapping should not be confined to paper analysis.
Every unique mapping instance should be identified and manually
performed using the authoring system, and then its appearance
should be verified using the presentation system. In any case,
the mapping process must, at the very least, provide detailed
guidelines on all the information constructs identified during
the Preliminary Document Analysis process (3.3).
This mapping process will reveal the ultimate complexity of the
conversion project. Table 3.61 lists the five principal
kinds of mappings and their associated complexity.
| Mapping | Relative Complexity |
| 1 to 1 | Low |
| many to 1 | Low |
| 1 to many | Medium to High |
| 0 to 1 | High |
| 0 to many | High to Unsolvable |
An example of a 1 to 1 mapping would be converting all <item>
tags to <step> tags. An example of a many to 1 mapping
would be converting all <item>, <step>, and <p>
tags to <para> tags. A 1 to many example would be the reverse
of a many to 1 and is obviously more difficult because it may
not be apparent which <para> tags should become <p>
tags, etc. The 0 to 1 and 0 to many mappings mean that the source
document contains no tags for information that is required to
be tagged in the target document. A good example given by Data
Conversion Laboratory (DCL) of a 0 to 1 mapping that may be easily
solved is the tagging of part numbers. In this case, a dictionary
of part numbers would have to be created and then the entire document
would have to be searched for each instance of those part number
strings. Each one that is found could be tagged as a <part>.
More difficult examples of 0 to 1 mappings include words that
are placed into an index. According to DCL, automation of this
kind of index conversion will result usually in about 70% to 90%
accuracy in normal documents. The 0 to many mappings are the
most difficult and may require significant amounts of processing
and/or manual intervention.
Conversion of ETM Types and Classes from lower levels to more
information-rich levels can be considered highly complex in terms
of the conversion process, because it will obviously involve a
lot of 0 to 1 and 0 to many mappings. If all authoring and presentation
systems were the same price and had a similar user base, then
the cost of the conversion project would be based principally
on the mapping between the source and target DTDs. In other words,
converting from Type MB to Type MC may be no more expensive than
converting to MB+, depending on the DTDs that are used. It is
also interesting to consider mapping from Type MA data. After
scanning in the graphics and either using Optical Character Recognition
(OCR) or retyping the text, the cost of converting to Type MB
or MB+ may not be significantly different from going to Type MC;
it just depends on the requirements of the target DTD. Some Type
MB documents that are destined for paper output, in fact, require
a lot of content tags. These content tags are applied when the
author wishes to use a FOSI or DSSSL and apply special formatting
instructions to the data (i.e., put it in bold faced 18 point
font).
After a detailed analysis of both the source and targets has resulted
in a comprehensive set of mapping guidelines for all the necessary
information structures, the next step is to determine who will
perform the mapping. It is recommended that a conversion service
bureau be contacted to assist with this planning. In other words,
it must be determined which mapping procedures can be performed
in house and which procedures should be performed by the larger
conversion service bureau. Conversion service bureaus maintain
a wide variety of conversion software tools that they sometimes
modify as necessary to carry out conversions. They have the most
experience in determining which software tools and what mix of
manual and automated effort will provide the most cost-effective
solution to the conversion problem at hand.
After carrying out the initial mappings and deciding who will
carry out which parts of the conversion, the remaining phases
consist of implementation and quality assurance.
This is the first step in conformance validation by QA and represents
the logical model of IETM deliverable components that may be isolated
for testing. This first layer (Data Structure Design)
involves validating the developed and/or selected content specific
layer for the IETM. Layer 0 follows the Content Data Model (CDM)
approach from MIL-D-87269, and focuses on defining and/or developing
a Content Specific Layer for the IETM from the resource templates
(architectural forms) provided in the Generic Layer. The
IETM Conformance Test and Validation Requirements Report,
January 19, 1996, contains the specific validation approach for
this Layer 0 Conformance Validation.
Legacy technical manual data can exist in two categories: the
data that exist only on paper and the data that exist in some
electronic form. To get data into an electronic format, the paper
data will require two levels of processing: text data capture
and graphical data capture. Decisions made during the preliminary
analysis and mapping phases may significantly affect the initial
data capture and/or conversion process. Even when mapping to
an exceedingly simple DTD, difficulties may be encountered because
it is likely that not all the information constructs will be identified
in the preliminary analysis phase (3.3). If all these issues
were handled during the mapping phase, the groups carrying out
the conversions are likely to require less consultation with the
ETM system implementors.
If the legacy data is in an electronic format such that the text
is accessible in an ASCII format, then the data capture phase
for text is not necessary. If the graphical images used are in
a suitable electronic format, then the graphical data capture
will not be necessary. These electronic file formats will become
the Project TM Data Baseline and controlled by the Configuration
Management Team. Paragraph 3.14 Tag and Link through the
conclusion of the general conversion process section will describe
how remaining processes, necessary for the generation of an ETM/IETM
system, will be performed.
In order to create an ETM/IETM, the technical data must exist
in some usable electronic form. If the data currently reside
in paper form, scanning/re-entering and OCRing must be performed.
Paragraphs 3.9 Scan/Re-Enter TM Data through 3.12 Did
Contents Convert Correctly will describe how the processes for
electronic conversion will be performed.
There are several options to get information that resides on paper
into an electronic format, including using a large Conversion
Service Bureau, Scan/Converting the TM data, or Manually Re-entering
the TM data. Each of these options has its advantages and disadvantages.
The decision on how to transfer the paper information into digital
should be made during the Preliminary Document Analysis phase
(3.3). The reasoning behind this decision will be based on such
items as quality and quantity of the existing data, project budget
and time, the availability of hardware/software and experienced
personnel, and possible required formats needed for further processing.
As stated above, conversion service bureaus maintain a wide variety
of conversion software tools that they sometimes modify as necessary
to carry out conversions. They have the most experience in determining
which software tools and what mix of manual and automated effort
will provide the most cost-effective solution to the conversion
problem at hand. Conversion Services should be contacted for
estimates on scanning and possible basic tagging work for all
large volume conversion efforts.
Several commercial conversion service bureaus are available in
today's market place. They all advertise the ability to convert
from any format to any format including SGML. The three most
widely known conversion service bureaus are Docucon, DCL, and
Gateway Conversion. However, these bureaus cannot provide the
advance system interactively or integration that the higher IETM
classifications are designed for.
The Navy currently has two mature conversion service facilities
in place for electronically indexed page images (Class 1/MA+)
ETMs. One is managed by the NAVSEA Data Support Activity (NSDSA)
and the other by Naval Air Systems Command (NAVAIR) Technical
Services Facility (NATSF). The Navy recommends that any legacy
hard copy TM should be forwarded to these sites for conversion
if a (Class 1/MA+) is desired.
NAVSEA has scanned virtually all of the 71,000 existing hard copy
TMs that are used to support the ship library requirements. NAVAIR
has scanned about 90,000 TMs. NSDSA and NATSF can assist in determining
whether required TMs have already been converted and whether the
configuration of the TM is up-to-date. These scanned images are
also used as the source data for Technical Manual Publish On Demand
System (TMPODS) that provide hard copy manuals without the need
to store excesses or dispose of obsolescent material.
To get data into electronic format, the paper will require two
levels of processing: text data capture and graphical data capture.
Text data capture is carried out in two ways: the text can be
either retyped in by hand (sometimes called rekeying) or scanned
into a raster format.
Scanning captures hard copy data into a system using a high-resolution
digital camera. The scanning process produces a digital file
called a raster image. Scanners come in all shapes and sizes,
and with many different capabilities. A scanner should provide
the following options at a minimum:
Graphical data capture from paper pages is carried out simply
by scanning the technical manual pages, separating the figures
from the rest of the page image (cropping), and storing the figures
in separate raster files. At this point, no attempt should be
made to remove callouts or decompose graphics into primitives.
These things are better done during the authoring phase with
a suitable authoring system.
A disadvantage to scanning will be in relation to the quality
of the original paper-based document. If the paper-based document
is in poor condition, the scanner may not be able to produce an
adequate camera image for the conversion software. The conversion
software depends greatly on the quality of the scanned data.
Non-uniform pressures, fabric inked-ribbon and ink-pad weave,
ink exhaustion from ribbons or pads, dirt and other sources of
character distortion from the original paper document may result
in large variations of printed characters. Also, spots and smears,
and uneven toner from duplicating machines may produce enormous
variations in the character shapes. The results of the conversion
can be either highly accurate or highly inaccurate. For this
reason, during the preliminary document analysis phase (3.3),
samples will be scanned to determine the quality, and the results
will be used in deciding the best way to get the paper-based data
into the system.
As pointed out in 3.9.2 Scan TM, the accuracy of scanning/converting
technical data could result in an enormous number of errors.
The quality of the paper document will play an important role
in the decision of scan versus re-enter. Before re-entering begins,
a general pre-processing step should be performed on both the
text and graphics in the paper manuals. This step consists of
marking up a hard copy of each work package by hand to indicate
what information would be inserted into the database. The work
packages and pre-processing should be accomplished during the
preliminary document analysis phase (3.3).
There are two ways to re-enter the text portion of the document:
Re-Enter text using a text editor or Re-Enter text using the
selected authoring software. Re-entering the text using a text
editor would generate ASCII files for further processing in the
Tagging (Automated and Manual) processes. Re-entering the text
using the selected authoring software would allow the entering
of appropriate tags simultaneously. The work packages developed
in the preliminary document analysis process (3.3) would be used
in either case. There are advantages and disadvantages for either
option.
Text Editor
Advantage:
Creating an ASCII file that when placed under CM will become the Project TM Data Baseline
Easier to verify the converted data prior to tag/links entry
Disadvantage:
Extra steps will be required for tagging after the data has been entered
More time, thus more cost
Authoring Software
Advantage:
Text and the tags/links are entered simultaneously
Visual display validation are available with most authoring software
tools
Disadvantage:
Correcting the data with tags/links included can be very difficult
No ASCII baseline
The decision on how the data will be entered should be made carefully
and should be made upon conclusion of the preliminary document
analysis process (3.3).
Re-authoring graphics includes using a graphic editor to re-draw
the graphics. This allows the editors to change text size, callout
arrow sizes, and break up the graphics that had more than one
detail per page so that they can be displayed more clearly and
on separate screens. This will also allow the graphics to display
on a small, low to medium resolution display device. Re-authoring
should also decrease the file size and decrease the amount of
time it would take to display.
The process of converting the scanned raster data into a vector
file can take on many forms. OCR for text is the use of opto-electronic
devices to obtain an electrical representation of printed characters
on paper. These electrical representations are then manipulated
in such a way as to generate computer images that can be analyzed
and each image assigned a character. Symbol Recognition for graphics
is similar to OCR where symbols from a database are used in the
conversion of the raster graph to a vector format.
Once the paper-based data have been scanned into a raster format,
computer character recognition will be performed. The OCR software
will perform character recognition algorithms on the scanned raster
text and output an ASCII text file. This process uses prototype
symbols and alphanumeric characters that have been stored in a
database for each symbol or character that has been identified
on the original paper-based document for comparison. Note that
it is not possible to achieve 100% correct character recognition.
Non-uniform pressures, fabric inked-ribbon and ink-pad weave,
ink exhaustion from ribbons or pads, dirt and other sources of
character distortion from the original paper document may result
in large variations of printed characters. Also, spots and smears,
and uneven toner from duplicating machines may produce enormous
variations in the character shapes. A text editor will be used
by a data entry person for character clean up and by QA for verification
to insure complete and accurate recognition.
Automated text recognition with OCR packages is not always the
most cost effective solution. The ability of OCR packages to
recognize characters depends on the quality, consistency, font,
and font size of the characters. Depending on these characteristics,
the results of OCR can be either highly accurate or highly inaccurate.
Even an accuracy of 99% can equate to 1 mistake per every 100
characters; if each word on average contains 5 characters, this
equates to 1 misspelled word out of every 20. This would obviously
result in an enormous number of errors in an entire technical
manual (including errors in part numbers). It is not uncommon
for a conversion service bureau to find it more cost effective
to manually retype in text instead of scanning and OCRing it.
This step in the conversion process may not be applicable if plans
for automated graphic conversion software include inserting tags
and links and developing call-outs. In this case, this step will
be bypassed and the conversion team would progress to the Tag
and Link processes.
There are several ways to recognize the symbols, lines, and text
within a graphic. This decision depends on the end result the
user is trying to achieve. Symbol recognition software may be
used to recognize the different types of symbols involved and
line tracing software to simply trace the lines connecting the
symbols. The decision of how to process the scanned graphic should
be made in the preliminary document analysis (3.3) and selecting
software phases (3.4) of the conversion process.
Full content reconciliation of newly converted technical manual
information can be a long, arduous, and expensive process. However,
it must be performed at this point before continuing with the
conversion project. This would include performing validation
by either direct letter to letter match or if work packages were
developed during the preliminary analysis process (3.3), the newly
reconstructed digitized data is consistent with the original packages
designed.
The term Validation in this process is defined as a conversion
service QA performed process in which the data that constitutes
the digitized baseline is compared in detail against the approved
source (paper) to ensure that the converted data is electronically
duplicated accurately in all respects and that it conforms to
all basic requirements stated in the contract.
The term Content Reconciliation is then `defined as validating
that the digitized parts, elements, and complex of parts within
the text and graphics are consistent or congruous with the original
hard copy data.
Determining the degree to which the digitized data are consistent with the original source data may or may not be difficult and clearly depends on both the source and newly developed baseline. Unfortunately, no currently established standards, handbooks, or procedures can validate the digitized data with the source at this point of the conversion process. However, basic QA techniques do apply at this phase. Table 3.111 lists some examples of basic validation processes that should be performed at this junction. Section 2.2 Quality Assurance Plan describes these in more detail and discusses other QA actions that will take place through-out the conversion project.
| Process | Procedure |
| Spell Check | Validating that the textual data for both graphics and text are correct. |
| Character Recognition Check | Validating that the OCR process was performed correctly in the text. |
| Symbol Recognition Check | Validating that the symbols on the graphics were correctly recognized and processed correctly. |
| Format Check | Validating that the digital format generated after the scan and/or converting processes is in an acceptable form for the selected automated conversion and authoring software. |
If at any point during the validation process an error is detected
and is verified as an error, the conversion effort will stop and
return to the point of the original conversion process (Scan,
OCR, or Editor) to make the necessary corrections. Upon completion,
content reconciliation must begin again to ensure that the corrections
made did not impact any other data.
The second layer, Layer 1, validates the authoring system to ensure
that it has the capability to encode information according to
the hierarchical data structure, semantic rules, and attributes
as defined in the content specific layer from Layer 0. The authoring
system must also conform with both ISO 8879 (SGML), and applicable
modules of ISO 10744 (HyTime), as
specified by MILD87269. Additionally, the authoring
system must provide the capability to include the required content,
style, and linkages and intelligence as specified by the IETM
specifications. The IETM Conformance Test and Validation Requirements
Report, January 19, 1996, contains the specific validation
approach for this Layer 1 Conformance Validation.
Conversion from an electronic file format to a tagged electronic
file format may involve the steps of manually tagging the file;
the use of COTS auto-tagging software; and/or the use of in-house,
customized, conversion software. The next step depends on how
the files were originally processed and what the final ETM/IETM
system will be.
Using an auto-tagger, writing conversion code, manually tagging
the data by hand, or any combination of the three, will probably
all be used, in a conversion project. There is neither a defined
order nor a defined limit on how many times these steps can be
used. In fact, the COTS auto-tagging products on the market today
do not provide the technology to do a complete conversion to any
of the upper class constructs. Therefore, some sort of intervention
either manually tagging and/or writing conversion code will be
needed to complete the tagging process.
Note that in most circumstances, the work required to customize an auto-tagger versus writing conversion code directly in C is about the same. This is important to know because conversion programs written in general purpose programming languages such as C are much m