# INTERACTIVE ELECTRONIC TRAINING MANUAL (IETM) GUIDE

## First Edition

## September 1999

**PUBLISHED BY THE**

**DEFENSE SYSTEMS MANAGEMENT COLLEGE PRESS**

**FORT BELVOIR, VA  22060-5565**

For sale by the U.S. Government Printing Office

Superintendent of Documents, Mail Stop:  SSOP, Washington, DC  20402-9328

**PREFACE**

The rapid integration of Interactive Electronic Technical Manuals (IETMs) into military workspaces throughout the Department of Defense has created a void in the otherwise comprehensive instruction provided to students at the Defense Systems Management College (DSMC). The swift pace of IETM development in the 1990s by each of the Services made preparation of a single guide on the subject a daunting task.  We on the staff at DSMC wanted to provide a useful instructional tool and reference, but did not want to hinder the reader’s understanding of the subject by providing outdated material.

We have designed this Guide primarily for use in DSMC courses and secondarily as an aid to acquisition managers. The text initially assumes little familiarity by the reader with IETMs. After presenting fundamental material, the text addresses issues of immediate concern to the acquisition manager from both the DoD and Service perspective.

DSMC will strive to make this a useful instructional resource and reference. Comments and recommendations relating to the overall text, Service specific information or technical developments are solicited.  You are encouraged to mail such comments to us on the pre-addressed tear sheet located at the back of this Guide.****

**Paul T. McMahon**

**Department Chairman**

**Principles of Program Management**

CONTENTS

Page

Prefacei

**CHAPTER 1  INTRODUCTION**1-1

1.1Objective1-1

1.1.1Background1-1

1.1.2Scope1-2

1.1.3Organization of the Guide1-2

1.1.4Roles and Responsibilities1-3

**CHAPTER 2  BENEFITS OF IETMS**2-1

2.1Introduction2-1

2.2Introduction of IETMs2-2

2.3Military IETM Studies2-2

2.4Maintenance Improvements2-3

2.5Fault Reporting and Fault Isolation Improvement2-4

2.5.1Reduction in False Alarm Rate2-4

2.5.2Increased Fault Isolation Success Rate2-4

2.5.3Fault Isolation Time Reduction2-5

2.6Maintenance Procedure Improvements2-5

2.6.1Reduced Maintenance Time2-5

2.6.2Reduced False Removal Rates2-6

2.7Greater Effectiveness of Inexperienced Technicians with IETMs2-6

2.8Improved Personnel and Equipment Safety2-6

2.9Reduction in Cycle Time for Reporting Technical Manual Discrepancies2-6

2.10Reduction in Technician Time Required for Maintenance Reporting2-7

2.11Features of IETMs that Improve Maintenance2-7

2.11.1Access to Technical Information2-7

2.11.2Greater Display Effectiveness Due to Multimedia Technology2-7

2.11.3Integration of IETMs with Other Management Information Systems2-7

2.12Improvements in Life-cycle Support2-8

2.12.1Reduction in Time and Errors for Technical Information Updated/

Modifications2-8

2.12.2Reduction in Costs of Technical Information Printing and Publishing2-8

2.12.3Reduction in Storage Space Required for Technical Information2-9

2.12.4Reduction in Shipping Costs2-9

2.12.5Automation and Integration of Logistic Support Technical Information2-9

2.12.6Supply Support2-9

**CHAPTER 3  CLASSES OF IETMS**3-1

3.1IETM Definitions3-1

3.1.1Class I - Electronically Indexed Pages Images3-1

3.1.2Class II - Electronic Scrolling Documents3-1

3.1.3Class III - Linearly Structured IETMs3-2

3.1.4Class IV - Hierarchically Structured IETMs3-2

3.1.5Class V - Integrated Database IETMs3-4

CONTENTS (Continued)

Page

**CHAPTER 4  ACQUISITION OF IETMS**4-1

4.1Introduction4-1

4.2IETM Acquisition Process Phases4-1

4.2.1Phase 1:  Develop an IETM Concept of Operations (CONOPS)4-1

4.2.2Phase 2:  Develop Procurement Package4-2

4.2.2.1Sample List of IETM Deliverables4-2

4.2.3Phase 3:  Distribute Procurement Package and Evaluate Contractor

Response4-3

4.3Phase 4:  Acceptance and Testing of IETM Products4-5

**CHAPTER 5  PRE-IETM DEVELOPMENT ISSUES**5-1

5.1Introduction5-1

5.2GCO Development Process5-1

5.3About the Tool5-2

5.4The GCO Process5-2

5.5Generator Process5-3

5.6Selection of IETM Functionality5-4

5.7Concept of Operations (CONOPS) Acquisition and Support Planning Process5-5

5.8Role of the CONOPS5-5

5.9Inclusion in the Statement of Work/Objectives (SOW/SOO)5-10

5.10CONOPS Development5-11

**CHAPTER 6  CLASS CONVERSION MODELS AND PROCESSES**6-1

6.1Introduction6-1

6.2Conversion Decisions6-1

6.3Legacy Conversion Processes6-3

6.3.1Raster Conversion Process6-3

6.3.2Service Conversion Efforts6-3

6.3.3Class II Conversion Model6-3

6.3.4Class III Conversion Model6-5

6.3.5Class IV Conversion Model6-6

6.3.6Class V IETM Migration6-8

**CHAPTER 7  THE FUTURE OF IETMS**7-1

7.1Introduction7-1

7.2Objective of the Study7-1

7.3Goal for the Architecture7-2

7.4Technical Approach7-2

7.5Overview of the Architecture7-3

7.6JTA Compliance7-3

7.7JIA Use of Internet and World Wide Web Technology7-3

7.8Proposed Requirement Documents for Implementation of the Architecture7-4

7.8.1Object Encapsulation and Component Interface Technical Description7-6

7.8.2Server and Data-Base Interface Technical Description7-7

7.8.3Browser Technical Description7-7

7.8.4Electronic Addressing and Library Model Technical Description7-8

CONTENTS (Continued)

Page

7.9Basic JIA Operational Flow Diagram7-9

7.10Benefits of Employing the Architecture7-9

7.10.1Benefits from the User Perspective7-9

7.10.2Benefits for the IETM Developer7-12

7.10.3Benefits to the DoD IETM Distribution Infrastructure7-12

7.11Architecture Types7-12

7.12Characteristics of Architecture Types7-13

7.13Elements of Diagrams for Architecture Types7-15

7.14Pilot Programs7-18

APPENDICES

Page

**APPENDIX A  SGML, HTML, XML AND IETM SOFTWARE**A-1

A.1IntroductionA-1

A.2SGMLA-1

A.2.1BackgroundA-1

A.2.2DTDsA-2

A.2.3FOSIs and StylesheetsA-3

A.3SGML and HTMLA-5

A.4SGML and XMLA-6

A.5SGML and PDFA-7

A.6Developing and Editing Software - Class II and IIIA-8

A.6.1ASCII EditorsA-8

A.6.2ADEPT*EditorA-9

A.6.3FrameMaker+SGML (FM+SGML)A-10

A.6.4IADSA-11

A.7Developing and Editing Software - Class IVA-12

A.7.1TechSightA-12

A.7.2QuillA-13

A.7.3Advanced Integrated Maintenance Support System (AIMSS)A-14

A.7.4Joint Integrated Maintenance Information System (JIMIS)A-15

A.8ParsersA-16

A.8.1SPA-16

A.8.2OmnimarkA-16

A.9IETM Viewing SoftwareA-17

A.9.1Advanced Technical Information System (ATIS)A-17

A.9.2AcrobatA-17

A.9.3InfoAccess (IA)A-18

A.9.4DynaTextA-19

A.10SGML Database ManagersA-20

**APPENDIX B  CALS PHILOSOPHY**B-1

B.1IntroductionB-1

B.2CALS (Continuous Acquisition and Life-cycle Support)B-1

B.3SECDEF PolicyB-2

B.4DOD InstructionsB-2

B.4.1PlanningB-2

B.4.2SolicitationsB-2

B.5InfrastructureB-3

B.5.1Existing Defense SystemB-3

B.6JCALSB-3

B.6.1TM System FunctionsB-4

B.6.1.1ManageB-4

B.6.1.2AcquireB-5

B.6.1.3ImproveB-5

B.6.1.4PublishB-5

**APPENDICES (Continued)**

Page

B.6.1.5StockB-5

B.6.1.6DistributeB-6

B.7TM Process FunctionsB-6

B.8Common IETM StandardsB-7

B.8.1Document Interchange StandardsB-7

B.8.1.1MIL-STD-1840, Automated Interchange of Technical 

InformationB-7

B.8.1.2MIL-PRF-28001, Markup Requirements and Generic Style 

Specifications for Electronic Printed Output and Exchange of 

TextB-7

B.8.1.3MIL-PRF-87268, General Content, Style, Format, and User 

Interaction Requirements for Interactive Electronic Technical 

ManualsB-8

B.8.1.4MIL-PRF-87269, Revisable Database for Support of Interactive

Electronic Technical ManualsB-8

B.8.1.4.1IETMDB Generic LayerB-9

B.8.1.4.2Architectural FormsB-9

B.8.1.4.3NodesB-9

B.8.1.4.4LinksB-10

B.8.1.4.5IETMDB Organizational Level Content LayerB-10

B.8.2Graphics Interchange StandardsB-10

B.8.2.1MIL-PRF-28002, Requirements for Raster Graphics Representation 

in Binary FormatB-10

B.8.2.2MIL-PRF-28003, Digital Representation for Communication 

of Illustration Data:  CGM Application ProfileB-11

B.8.3Product Data Interchange StandardsB-11

B.8.3.1MIL-PRF-28000, Digital Representation for Communications of 

Product Data:  IGES Application Subsets and IGES 

Application ProtocolsB-11

**APPENDIX C  IETM AND TRAINING STRATEGIES**C-1

C.1IntroductionC-1

C.2Integrated/Interfacing Training Strategies and IssuesC-1

C.2.1StrategiesC-1

C.3Logistic Organization ChangesC-2

C.3.1Concurrent Development of Technical Logistic Information and TrainingC-3

C.3.2Interface Versus Integration of Training and IETMsC-3

C.3.3Life-cycle Configuration Management and Update ConsiderationC-4

C.3.4Field Interface and ResponsibilitiesC-5

C.3.5Mutual FunctionalityC-5

C.3.6MigrationC-5

C.4Interactive Courseware (ICW)C-6

C.4.1ICW DefinitionC-6

C.4.2Introduction and BackgroundC-7

**APPENDICES (Continued)**

Page

C.4.3ICW Production and DisplayC-7

C.4.3.1ICW ProductionC-7

C.4.3.2Display Software/Hardware and User NeedsC-8

C.4.4IETM - ICW InterfaceC-8

C.4.4.1Comparison of Categories of ICW with Classes (I-V) IETMC-9

C.4.4.2ICW and IETM Commonality and DifferencesC-9

C.4.5IETM - ICW Interface ScenariosC-11

C.4.5.1Concurrent IETM and ICW DevelopmentC-11

C.4.5.2Development of ICW Using an Existing IETMC-11

C.4.6ICW SpecificationsC-11

C.4.6.1Requirements DefinitionC-11

C.4.6.2IETM - ICW Interface Specifications DevelopmentC-12

C.4.6.3Government Specifications - ICW StandardsC-12

C.5IETM Interface DecisionsC-12

C.6Training Impact on CONOPS DevelopmentC-13

**APPENDIX D  AIR FORCE IETM INFORMATION**D-1

D.1Air Force StrategyD-1

D.2Air Force Conversion EffortsD-3

D.3Air Force IETM Display EquipmentD-4

D.3.1Joint Integrated Maintenance Information System (JIMIS)D-4

D.4Online ResourcesD-5

D.5Acquisition Classroom InstructionD-6

D.5.1Course AbstractD-6

D.5.2Digital Data Acquisition Course OutlineD-7

D.6Software LicensingD-9

D.7Air Force DTD RepositoryD-9

D.8AF Points of ContactD-11

**APPENDIX E  NAVY IETM INFORMATION**E-1

E.1BackgroundE-1

E.2Compatibility with ATISE-1

E.3Data Conversion EffortsE-2

E.4Navy IETM Display EquipmentE-3

E.5Development ResourcesE-4

E.6Classroom InstructionE-4

E.6.1Authoring Instructional Materials (AIM)E-4

E.6.1.1Introduction to AIME-4

E.6.1.2AIM System DescriptionE-5

E.6.1.3AIM and AIM IE-6

E.6.1.4AIM IIE-6

E.6.1.5AIM-IETM Automated InterfaceE-6

E.6.1.6AIM ImplementationE-7

E.7Training Integration Management Software (TIMS)E-7

E.7.1BackgroundE-7

**APPENDICES (Continued)**

Page

E.7.2ObjectivesE-7

E.8Software LicensingE-7

E.8.1Navy CALS DTD RepositoryE-8

E.8.2AvailableE-9

E.9Access to the Navy DTD RepositoryE-10

E.9.1World Wide Web (WWW)E-10

E.9.2Anonymous FTPE-10

E.9.3E-mailE-10

E.9.4Telephone or MailE-10

E.10CD GuidelinesE-10

E.11Points of ContactE-11

**APPENDIX F  ARMY IETM INFORMATION**F-1

F.1IETM StrategyF-1

F.2Digital Conversion EffortsF-1

F.3IETM Display Equipment (SPORT)F-2

F.4Development ResourcesF-3

F.5Software LicensingF-5

F.5.1Interactive Authoring and Display System (IADS)F-5

F.6Army SGML Registry and Library (ASRL) for DTDsF-5

F.7Army Points of ContactF-6

**APPENDIX G  USMC IETM INFORMATION**G-1

G.1IntroductionG-1

G.2USMC PolicyG-1

G.3Digital Conversion EffortsG-1

G.4Development ResourcesG-2

G.5USMC IETM Acquisition Policy and DTD GuidanceG-2

G.6USMC Point of ContactG-2

**APPENDIX H  SAMPLE IETM CONCEPT OF OPERATIONS FOR THE**

**SAGITTARIUS SYSTEM**H-1

H.1System IntroductionH-1

H.2System AttributesH-1

H.2.1Complexity of the SystemH-1

H.3Configuration VolatilityH-1

H.4Classification and SecurityH-1

H.5Expected Service LifeH-1

H.6Number and Deployment of SystemsH-2

H.7Number of IETM UsersH-2

H.8Quantity of DataH-2

H.9Quality of DataH-2

H.10Consolidation of Subject MatterH-3

H.11Maintenance LevelsH-3

H.12Training LevelsH-3

H.13Manning RequirementsH-3

**APPENDICES (Continued)**

Page

H.14Existing Government and Contractor InfrastructureH-3

H.15IETM Implementation ScheduleH-4

H.16Urgency of Information UpdateH-4

H.17SecurityH-4

H.18Display Hardware, Operating Systems, and Networks to be Used for ATIS

Compatibility Aboard ShipH-4

H.19Environmental Conditions and IETM Display HardwareH-5

H.20Display Hardware Maintenance and SupportH-5

**APPENDIX I  ACRONYMS AND ABBREVIATIONS**I-1

**APPENDIX J  LIST OF SOURCES**J-1

LIST OF FIGURES

PAGE

Figure 3-1.Graphical Representation of IETM Classes3-2

Figure 4-1.IETM Acquisition Phase4-1

Figure 4-2.IETM Acquisition Process Model4-4

Figure 5-1.GCO Development Process5-2

Figure 5-2.IETM Functionality Determination Model5-6

Figure 6-1.IETM Conversion Process6-2

Figure 6-2.Class I IETM Conversion Process6-3

Figure 6-3.Class III IETM Conversion Process6-6

Figure 6-4.Class IV IETM Conversion Process6-7

Figure 7-1.Flow of IETMs Through the JIA7-11

Figure 7-2.Elements for Architecture Types C1 and C27-16

Figure 7-3.Elements for Architecture Type S17-17

Figure 7-4.Elements for Architecture Type S27-17

Figure A-1.Military Manual StructureA-2

Figure A-2.SGML Tree ExampleA-4

Figure A-3.HTML Display within Internet ExplorerA-6

Figure A-4.Electronic Page in Adobe Acrobat ReaderA-8

Figure A-5.Abortext’s ADEPT*Editor InterfaceA-9

Figure A-6.FrameMaker+SGML Authoring EnvironmentA-11

Figure A-7.IADS ReaderA-12

Figure A-8.TechSight ViewerA-13

Figure A-9.Quill21 SystemA-14

Figure A-10.AIMSS ViewerA-15

Figure A-11.JIMIS ScreensA-16

Figure A-12.Adobe’s Acrobat ViewerA-18

Figure A-13.GUIDE Reader (InfoAccess)A-19

Figure A-14.DynaText BrowserA-20

Figure A-15.Texcel’s Information ManagerA-21

Figure B-1.Digital Product RelationshipB-1

Figure C-1.ISD System and ICW SubsystemC-8

Figure C-2.Creating ICW Using an Existing IETMC-11

Figure D-1.Sample Screens from TO CBT CourseD-6

Figure F-1.Army IETM Display EquipmentF-3

LIST OF TABLES

PAGE

Table 3-1.IETM Classes3-5

Table 7-1.Proposed IETM Architecture Types7-15

Table 7-2.JIA Pilot Programs7-18

Table C-1.ICW Categories of InteractivityC-10

Table D-1.Production Status of Air Force TOs (July – November 1998)D-2

Table E-1.Cost of ConversionE-2

Table E-2.Licensing in PlaceE-8

Table E-3.Available Subject Matter ExpertsE-11

# CHAPTER 1 INTRODUCTION

**1.1Objective**

This document is designed to be the primary desk reference for acquisition personnel who will be required to acquire, develop, deliver and/or manage IETMs now or in the future.  It incorporates the status of existing/planned DoD and Service unique policy guidance, discusses current and projected technologies related to the production of IETMs, analyzes the relationship between IETMs and training, and addresses delivery vehicles including the World Wide Web (WWW). 

**1.1.1Background**

An emerging area of technology that has rapidly gained acceptance throughout all branches of the military is the acquisition, development, deployment and sustainment of electronic technical documentation and associated multimedia elements. The explosion in popularity of the Internet has produced an insatiable appetite for near real time information needs. The demand by todays computer literate society is for electronic media, not paper copy. Faced with shrinking defense budgets, weapon system managers have turned to one small corner of the information spectrum to meet its technology needs. The Interactive Electronic Technical Manual (IETM), first conceptualized in the1980s, became a reality by the early 1990s. In just the past few years, advances in computing power, increased functionality in IETM delivery software, portability of computers and reduced IETM development costs have paved the way for a successful electronic documentation delivery and sustainment program.

Simply put, an IETM is a technical manual that is prepared (authored) in digital form on a suitable medium, by means of an automated authoring system.  It is designed for an electronic-window display to a user and in most cases possesses the following three characteristics: 

· The format and style of the presented information are optimized for window presentation in an electronic form, either on a desktop PC, laptop PC, or other portable electronic display device.  And, is designed to assure maximum comprehension.  That is, the presentation format is "frame-oriented" not "page-oriented.”

· The elements of technical data constituting the IETM are so interrelated that a user's access to required information is facilitated to the greatest extent possible, and is achievable by a variety of paths.

· The computer-controlled IETM display device can function interactively (as a result of the user’s request and information input) in providing procedural guidance, navigational directions, and supplemental information.  It can also provide assistance in carrying out logistic-support functions supplemental to maintenance.

Not all IETMs fit the three criteria stated above.  IETMs can range from raster scanned images to sophisticated database management systems using expert systems and diagnostics. Using a strict definition of IETMs, some digitized manuals should be referred to as Electronic Technical Manuals (ETMs). The term electronic technical manual (ETM) generally describes all combinations of technical manual data in digital formats, stored in optical or magnetic media, and viewed through electronic display devices. To avoid confusion, the more commonly used term, IETM, will be used throughout the *DSMC IETM Guide* to describe all forms of digital technical manuals (TMs). 

By the mid to late 1990s, pilot programs emerged that coupled IETMs with multimedia training elements. The combination of electronic documentation with a multimedia editing and delivery system established the building blocks necessary for an Electronic Classroom (EC) environment. Armed with these technologies, military trainers now had the opportunity to develop more effective classroom instruction that could be extended into the field and reused. CD ROMs containing entire technical manuals and lesson guides can now be provided to the user for just-in-time (JIT) refresher training upon returning to their duty station. The use of these Electronic Performance Support Systems (EPSS) where (IETM technology is integrated with training programs) provides the capability to improve individual performance and reduce costs. When implemented properly, streamlining of the training pipeline can be accomplished.

**1.1.2Scope**

The *DSMC IETM Guide* is a guidance document that does not establish policy or procedures. Many IETM requirements are Service specific and have been identified within the *DSMC IETM Guide* for further investigation by the IETM acquisition manager. This guide should be used as a starting point for IETM development efforts and include consultation with the appropriate Service’s IETM points of contact (identified in the Appendices) for further information and guidance. Due to the dynamic environment surrounding this subject matter, the contents and referenced requirements of this document will require periodic modification. Personnel are encouraged to access the latest version of the *DSMC IETM Guide* at: 

http://www.dsmc.edu/IETM/guide.htm.

**1.1.3Organization of the Guide**

The *IETM Guide* is presented as a series of building blocks to enhance your understanding of the IETM life-cycle.

Chapter 2 summarizes the benefits of IETMs and their impact on logistic support systems.

Chapter 3 summarizes the different classes of IETMs.

Chapter 4 provides overall IETM acquisition guidance. 

Chapter 5 reviews pre-IETM development resources including the Government Concept of Operations (GCO) and IETM Concept of Operations (CONOPS).

Chapter 6 provides an overview of IETM development, including developing IETMs from legacy material and as a new program.

Chapter 7 presents a discussion on the future of IETMs from a development and delivery standpoint.

Appendix A reviews IETM software.  It specifically discusses the foundation of many military IETMs: SGML (Standard Generalized Markup Language). The chapter introduces a structured document approach to the creation of technical data to permit the electronic interchange of information within a centralized DoD database.

Appendix B addresses the Continuous Acquisition and Life-cycle Support (CALS) philosophy and how it applies to IETMs. It also provides a discussion of the specifications underlying IETM development and delivery.

Appendix C addresses the training and IETM interface between products such as Interactive Courseware (ICW), Computer-based Training (CBT) and Computer Aided Instruction (CAI).

Appendix D contains Air Force specific IETM acquisition information.

Appendix E contains Navy specific IETM acquisition information.

Appendix F contains Army specific IETM acquisition information.

Appendix G contains USMC specific IETM acquisition information.

Appendix H presents a sample IETM Concept of Operations (CONOPS), which is defined earlier in the text.  Additional supporting material is provided in subsequent appendices.

**1.1.4Roles and Responsibilities**

The Program Manager and the respective project leaders are ultimately responsible for ensuring that requirements and missions are adequately supported.  Each program should establish a team to research and develop an IETM Concept of Operations (see Chapters 4 and 5) to define system/equipment Operational & Maintenance (O&M) data requirements and functionality of IETMs.  The Program Manager should ensure that the team contains adequate representation from program, logistic and engineering disciplines, design agents, training, and user activities.  Their functions and requirements are described below.

· Program/Logistics Element Manager - The acquisition, technical, and functional managers are responsible for creating, reviewing, validating, delivering, maintaining, and updating TMs in any format and for implementation, execution and management of IETM processes supporting the weapon systems or equipment; provides the IETM developers with engineering and technical data.

· Logistics Support (LS) Manager - Responsible for ensuring that the program is supported with accurate TMs and training; leads the procurement of TMs, training and courseware materials (if applicable) and monitors the process and progress for any system under the manager’s cognizance.

· Program/Maintenance Engineer - Defines technical requirements for the program system and assists in interpreting and validating technical information that will produce the TM and courseware; acts as the Government agent for technical issues and provides additional technical support functions.

· Design Agent (e.g. contractor) - Provides initial technical data for the program and may author the IETM content.

· Technical Writer - Verifies the parts of the TM and training using logistics input data and provides proposed changes and alterations to the deliverable products.  Provides initial technical data for the program and may author IETM content.

· Training Agent - Provides and maintains the training facility and curriculum after a ready-for-training date has been reached.

· User - Personnel who use the TM to gather information or perform work (e.g., maintainer, trainer, operator).

# CHAPTER 2 BENEFITS OF IETMS

**2.1Introduction**

Ever since the Egyptians invented papyrus, paper has been used to deliver information. Although paper remains the preferred medium for certain types of information (novels, personalized correspondence, etc.), electronic alternatives are maturing. The average military inductee is computer savvy and experienced with the Internet and can easily adapt to computer delivered information. 

Today’s paper-based manuals are no longer the optimal choice for delivering information about complex machinery. Traditional paper manuals present a wealth of problems, including:

· Weight – Where mobility is a top priority (ships, ground based units), every area where a reduction in weight can be accomplished is scrutinized.  One study determined that an Oliver Hazard Perry Class frigate (FFG 7) contained 21 tons of paper and containers for paper storage. An AEGIS Class cruiser (CG 47) had accumulated 37 tons.

· Volume – Paper takes up much needed space within a mobile unit. In the example presented above, assuming a density of 40 pounds per cubic foot, the frigate's 21 tons of paper would occupy 1050 cubic feet. 

· Information Access –Technical manuals for complex equipment regularly extend across multiple volumes. The technical manuals for the LM2500 are contained in 11 volumes. In a typical maintenance action where the technician needs to diagnose and correct a problem, finding the correct information among the various maintenance volumes can take a considerable amount of time.

· Up-to-date Information – Rapid changes to military equipment through modifications and upgrades require supporting documentation to be updated just as often. Paper-based documents require a series of change pages to be methodically inserted, pen-and-ink annotations made where necessary, and superseded information discarded. The reduction of personnel within the military leaves little time to accurately incorporate and check changes. This can result in incomplete information, incorrect maintenance actions and possible safety problems.

· Printing – Paper is expensive compared to electronic documentation. Technical manual developers spend many hours formatting a document (page breaks, widow/orphans) to fit on 8 1⁄2 x 11” paper. The costs of printing multiple copies, providing binders for the documents, and shipping to multiple destinations also have to be considered.

· Deterioration – The typical harsh military environment with daily handing by technicians, gradually deteriorates the paper technical manual. 

**2.2Introduction of IETMs**

The introduction of a new technology into the military is not accomplished without the completion of an extensive study. Early studies concluded that IETMs were significantly superior to the traditional paper-based technical manuals under operationally realistic conditions.  IETMs solved or mitigated many of the problems identified in the previous paragraph as follows:

· Weight – Standard calculations assume that a CD can store approximately 3,400 pages of text, tables and graphics. This is about 20 pounds of paper-based information. Since a CD (with the jewel case) weighs less than two ounces, the AEGIS Class cruiser could reduce its 74,000 pounds of paper weight to less than 500 pounds if all information were to be placed on CDs. While some weight would need to be added to account for IETM viewing hardware, the reduction in weight for mobile units would in select instances increase maneuverability and reduce fuel consumption.

· Volume – Approximately 1,850 cubic feet of storage space is needed to store the 37 tons of paper aboard an AEGIS Class cruiser. The same documentation would only occupy 35 cubic feet if placed entirely on CD.  Many facilities, which now receive duplicate copies of a single technical manual, operate in a networked environment. A single copy of an IETM on CD,  would be sufficient for the initial IETM network installation and would serve as a backup.

· Information Access – At a minimum, even the most basic (Class I) IETMs provide a limited hyperlinking capability to allow the user to point, click, and quickly access desired information.  The functionality of higher order classes permits word/phrase search capability, internal cross- reference links and links to other material (inventory, training, etc.). Northwest Airlines, using a prototype system, experienced a minimum 50% reduction in airline mechanics’ time spent looking for the appropriate documents.

· Up-to-date Information – Once an IETM has been developed, a process for integrating and distributing updates should be implemented. The electronic “sticky notes” feature of many IETMs can be used as an interim solution between updates. These notes are simply folded into the source file and delivered as a complete revision on a periodic basis. More sophisticated IETMs, manuals, which may also include a “notes” feature, require the entire database to be delivered.  A method known as “push technology” is now being evaluated for updating Web-based IETMs.

**2.3Military IETM Studies**

The Naval Surface Warfare Center, Carderock Division (NSWC-CD) released a report in October 1996 entitled “Maintenance and Logistic System Support Benefits Resulting from Introduction of IETM Based Technology.” The study group identified clear benefits to employing IETMs onboard operational units. Consider the following evaluation summaries from Commanding Officers of Navy ships after their personnel performed an onboard assessment of the Radio Communication Set (RCS) IETM:

CO, USS ANZIO 

· “The IETM is light years ahead of the standard Tech Manuals of raster scanned pages and has become a critical part of the operation and maintenance of the RCS.”

· “IETMs are an information multiplier. With IETM(s) as a tool/coach, junior personnel can perform complex technical tasks with nearly the same effectiveness as senior techs.”

· “Utility is outstanding. Techs and operators are using IETMs exclusively because of speed and ease of technical access to data.”

CO, USS SHILOH

· “RCS IETM program is outstanding. It works and has greatly enhanced communication readiness on Shiloh.”

· “IETM approach should be applied to technical documentation for other AEGIS ship systems (e.g., CSOSS, CSTOMS, EOSS, NSTM, Interface information, etc.)”

· “Program should be expanded to include all new construction CG/DDGs.”

· “This system is a winner and the sailors love it.”

Overall, the results of limited introduction of the RCS IETM into the Navy are summarized as follows:

· Sailor classroom feedback: Outstanding

· 95% rated IETM features used as good or excellent

· 93% preferred IETMs to equivalent paper technical documentation

· Majority cited speed and ease of use as greatest advantages

As a point of reference, the RCS IETM was a more capable (Class IV) system. Generally speaking, the benefits obtained from lower class IETMs are space/weight savings, quicker access/hyperlinked access to desired information, and lower distribution costs. When IETMs are linked to the entire enterprise (e.g., training, supply, maintenance reporting systems), other benefits will also be realized.

The NSWC-CD report highlighted a number of logistical areas where real cost savings could be realized through deployment of IETMs. The remainder of this chapter discusses the findings of this report.

**2.4Maintenance Improvements**

The corrective maintenance process begins with discovering and reporting a system malfunction. It proceeds to completion when the unit is brought back online. In between, various procedures are conducted to verify the fault, identify and repair the faulty component, and operationally check out the performance of the equipment. Every step of the process is vulnerable to human error. Automation of the corrective maintenance process, through the introduction of IETM technology, can greatly increase operational availability and reduce the logistic support burden throughout DoD.

Below are a few of the areas where maintenance process improvements can be realized with increased use of IETMs:

· Reduced false alarms

· Increased percentage of successful fault isolation

· Reduced fault isolation times

· Reduced maintenance time

· Reductions in false removal rates

· Greater effectiveness of inexperienced technician

· Improved personnel and equipment safety

· Reduction in turn-around time for reporting and correcting technical manual discrepancies

· Reduction in technician time spent completing maintenance reporting forms

**2.5Fault Reporting and Fault Isolation Improvement**

**2.5.1Reduction in False Alarm Rate**

Characteristically, a fraction of all fault reports consists of false alarms.  If a maintenance technician cannot verify a fault, the problem is reported as a CND (Cannot Duplicate) or similar designation.  An aircraft, for example, will be removed from operational service for further tests or will be tentatively returned to service.  This can be a serious matter if the fault really exists.

Tests have demonstrated that use of IETMs greatly reduces such occurrences. The Naval Air Systems Command conducted a series of tests during the Aircraft Maintenance Integrated Diagnostics Demonstration (AMIDD), with an integrated IETM system in an F/A-18 C/D squadron. The AMIDD Project Office stated that in going from paper TMs to IETMs, CNDs could be reduced by approximately 50 percent.

**2.5.2Increased Fault Isolation Success Rate**

When a technician has verified that a reported fault exists, he or she must locate the faulty component using Built-in Test Equipment (BITE) information or an operator's statement of the malfunction.  With complex systems, fault isolation is probably the most difficult step in any maintenance sequence.  Paper-manual fault-isolation procedures are cumbersome and static (non-interactive). Often, possible fault sequences cannot be covered in a reasonable period of time.  (The limitation is often with the paper medium and not the engineering content.)  Consequently, the process of troubleshooting, based on step-by-step sequence through a fault tree, can end in failure.  In such a case, the process is repeated, or the whole problem is referred to a higher maintenance level (e.g., O-level to I-level).  A field test using the AN/SPA-25D radar repeater showed an increase in the fault isolation success rate from 64% to 100% for experienced technicians and from 54% to 100% for inexperienced technicians. Note that in this instance, inexperienced technicians became as proficient as experienced technicians. In a similar case, an F-14A test showed an improvement from 42% successful fault isolation with conventional technical manuals to 100% successful fault isolation with IETMs.

**2.5.3Fault Isolation Time Reduction**

The time required for fault isolation is also reduced through the use of IETMs.  For example, Navy field tests on the AN/SPA-25D showed a decrease in fault-isolation time of 24% for various inserted faults when IETMs were used in the corrective maintenance process.  Other tests have provided similar results.  The Air Force reported that Integrated Maintenance Information System (IMIS) tests on the F/A-18 aircraft resulted in fault-isolation time reduction by 37 percent.  The Naval Personnel Research and Development Center (NPRDC) documented a decrease in fault-isolation time of 56.8% while conducting tests on a set of communication equipment IETMs. The magnitude of the cited improvements, including improved performance of less experienced technicians, has been repeatedly verified in independent tests.

The fact that an IETM significantly shortens the time required to perform troubleshooting is due largely to its interactive functions.  A technician enters a test result and the IETM can automatically and immediately advance to the next appropriate test.  This process continues until the cause of the problem is isolated.  Electronically displayed information-format improvements contribute to the effectiveness of the IETMs.  For example, using the IETM, text and relevant graphics can be presented in a side-by-side format to save the technician from having to search for locator information. In paper manuals, the text is frequently not co-located with relevant graphics, forcing the technician to search for the required information.  Finally, IETMs provide "how to" instructions, whereas the steps in paper manuals merely state "what to do" (assuming the technician knows how).  

**2.6Maintenance Procedure Improvements**

**2.6.1Reduced Maintenance Time**

After troubleshooting has identified the cause of a deficiency, technicians need to perform correction tasks.  These are usually repairs (straighten pins, splice wiring, calibrate, adjust), or remove-and-replace (R&R) actions. Hughes Aircraft conducted an investigation of the Navy Technical Information Presentation System******(NTIPS), centering on the benefits of replacing paper manuals with IETMs.

NTIPS tests on the AN/SPA-25D system showed a decrease in repair time for both experienced technicians (by 16-28%) and inexperienced technicians (by 22-30%).

**2.6.2Reduced False Removal Rates**

Once a faulty component is identified, it is either repaired (when the maintenance procedures for the system so indicate) or is removed and replaced.  Removed components are usually forwarded from an O-level maintenance facility to an I-level Maintenance Activity (IMA) for evaluation.  Typically, a large fraction of removed parts have been found not to be defective, indicating false removals.  

The USAF F-16 tests with IMIS (Integrated Management Information Systems) showed a reduction of 26% in false-removal rates by specialists, and 37% by non-specialists. A briefing on the results of the AMIDD tests reported a reduction in false-removal rates of 60 percent.

**2.7Greater Effectiveness of Inexperienced Technicians with IETMs**

As indicated in the previous paragraphs, the performance of inexperienced technicians using IETMs has shown striking improvement relative to that of technicians of the same level of experience using paper TMs.  This improvement has been particularly noticeable in troubleshooting success.  Early F-14A IETM tests revealed inexperienced technicians were unable to locate a fault inserted into an operational F-14A using paper TMs. When an IETM was used, all of the technicians tested successfully located the fault. In general, inexperienced technicians perform on a level equivalent to that of experienced technicians when an IETM is utilized.  The IETM can be expected to compensate in some measure for both a shorter training program and less experience among technicians.

**2.8Improved Personnel and Equipment Safety**

TMs include numerous WARNINGs****(which point out situations involving danger to personnel), CAUTIONs****(which identify situations involving possible damage to equipment), and NOTEs (pointing out possible errors in procedure).  With paper manuals, problems resulting from a technician ignoring or misunderstanding these instructions are not uncommon. In an IETM procedure, the technician cannot continue without explicitly acknowledging his/her observation of****WARNINGs****and CAUTIONs**.**Moreover, WARNINGs, CAUTIONs,****and NOTEs are more effectively displayed, via popup dialog boxes and/or in color, to the technician than in the case of paper manuals.  "HELP",****through an online hypertext system, or “coach”, may be available if he/she does not understand the information presented.  

The capability of IETMs to be automatically updated, via electronic sticky notes or e-mail,  means that safety-related messages and updates will appear far more rapidly in the electronic technical data package than in paper TMs. 

**2.9Reduction in Cycle Time for Reporting Technical Manual Discrepancies**

With establishment of direct interaction of an on-board maintenance Local Area Network (LAN) with a management information system, response time for the submission of IETM deficiencies in technical information can be reduced from weeks to hours by the use of direct electronic-trouble reporting.  The user in many cases may receive a same-day response to verify receipt of his/her trouble report.  Corrections involving issues related to personnel or ship safety can be routed to the responsible activity within hours of receipt, in lieu of a longer period required to route paper. The Naval Sea Systems Command (NAVSEA) has been working on the Technical Information Deficiency Evaluation System (TIDES) to achieve this goal. 

**2.10Reduction in Technician Time Required for Maintenance Reporting**

As a part of each maintenance action, a technician must fill out a standard maintenance report form, which differs somewhat between services and for different types of systems.  Tests based on the actual conduct of the specific maintenance action, as reflected by the interaction of the technician and the IETM, have shown that automation of this process can substantially reduce the time required for this procedure.  Similarly, ordering a required part can be accomplished quickly on an IETM display of IPB information. This replaces the time-consuming process of locating parts data in a paper manual, filling out a form, and delivering the form to the supply chain.  With an IETM, parts inventories can be instantly adjusted as a result of each parts-ordering action.  The Air Force has shown that the time required to order necessary parts can be reduced by 94% using IETMs.

**2.11Features of IETMs that Improve Maintenance**

**2.11.1Access to Technical Information**

One of the key elements involved in effective troubleshooting and repairing of equipment is having immediate multipath access to all the needed technical information.  With IETMs, all of the required information can be at the technician's fingertips.  For example, IETMs can incorporate maintenance aids such as a Fault Lookup Mode.  When the maintainer receives a BITE fault code for a piece of equipment, he/she can access the IETM and enter the fault code.  The IETM will then lead the maintainer immediately into the troubleshooting procedure for that fault code, and send him/her directly to the proper corrective maintenance procedure and IPB (Illustrated Parts Breakdown) to enter the data into the supply system. Sailors using the AEGIS Radio Communications System IETM retrieved information up to four times faster than with the paper documentation that it replaced.

**2.11.2Greater Display Effectiveness Due to Multimedia Technology**

The interactive visual presentation of complex procedures by using animations, video clips, virtual reality technology, and expert system modules can provide the maintainer with improved comprehension of technical information.  The benefits of audio, in addition to visual notification windows, can improve the delivery of WARNINGs, CAUTIONs, and NOTEs in troubleshooting and maintenance procedures.

**2.11.3Integration of IETMs with Other Management Information Systems**

The Navy has already integrated the IETM with the Advanced Technical Information System (ATIS). This provides the maintainer with access to all of the technical documentation normally stored in disparate locations.  This resource includes the entire ship's library, Ships Service Manuals (SSMs), Engineering Drawings, Maintenance Requirement Cards (MRCs), and Standard Operating Procedures (SOPs). As other “islands of information” come online within the services, integration, through middleware applications, will become a priority. Only when the information systems of each service are tied into a DoD wide network, will the benefits of automation (e.g., parts ordering from a centralized DoD facility) be fully realized.

**2.12Improvements in Life-cycle Support**

Although reliable quantitative estimates are as yet generally unavailable, it is clear that life-cycle costs of maintaining IETMs will be a fraction of the cost required to maintain conventional paper manuals. It has been estimated that a reduction of 20% in ownership costs (life-cycle support costs) for the LM2500 Gas Turbine will result from the introduction of an IETM to support its training and Fleet maintenance.

An evaluation of the effectiveness of the LM2500 Gas Turbine IETM effort carried out by the NPRDC stated:

"The elimination of seven training weeks from the GSE training pipeline and three training weeks from the GSM pipeline results in a reduction in student training costs of over $1,900,000 in FY 95 and FY 96.  The cost savings in avoiding reproduction of the paper-based technical manuals used in the GSE/GSM courses were estimated at $96,000 for FY 96."

**2.12.1Reduction in Time and Errors for Technical Information Update/Modification**

Correcting and updating electronic media can be more thoroughly and effectively performed by the use of key text-searching capabilities.  Global find and replace actions for paper legacy data require a hit-or-miss visual scan of the entire paper-based product, often resulting in failures to correct all instances of the desired changes. Significant time is currently spent to generate and maintain conventionally based paper products. This includes the time required to review for potential errors in technical information updates.  Automatic referencing of the electronically stored tables and figures ensures absolute and correct updates to numbering changes created by revisions to the source material. Electronic media also enables the automatic generation of the table of contents, list of figures, list of tables and indexes.

Changes are made to the entire IETM at once instead of producing a separate change package for each stand-alone paper TM.  Changes that ripple through the entire set of manuals could be quickly and effectively located and corrected by the use of the search features available with electronic media, a function not available for paper-based products.  Advance Change Notices (ACNs) can be delivered as annotated files to supplement the IETM, thus reducing ACN printing, shipping, and storage costs.

**2.12.2Reduction in Costs of Technical Information Printing and Publishing**

Printing costs can be eliminated by the replacement of paper-based manuals with electronically generated media.  The cost of mastering and reproducing a CD is less than the setup costs of reproducing a paper-based set of manuals.  The cost of procuring and storing binders can also be eliminated. 

**2.12.3Reduction in Storage Space Required for Technical Information**

Storage space requirements can be substantially reduced with the elimination of paper technical manuals. This space requirement can be reduced to a single filing cabinet for the storage of the equivalent magnetic material. It has always been anticipated that IETM display equipment would not be purchased solely to view IETMs. Thus, IETMs may take advantage of existing computer display systems. 

**2.12.4Reduction in Shipping Costs**

Shipping costs can be reduced for conventional shipment of routine initial distribution material and routine updates. The cost of distributing emergent changes to paper manuals will be reduced to a few pounds of the electronic equivalent.  This expense could drop further as changes/updates are made using satellite links.

**2.12.5Automation and Integration of Logistic Support Technical Information**

The use of automated techniques to create, manage, deliver and update technical information documentation via an easily revisable database across hardware and software neutral platforms will greatly reduce the life-cycle costs of technical information and improve the quantity and functional integration of information for end-user use.  The IETM and its associated database will be the repository for all deliverable technical information relating to the documented system; information which can be extracted easily and quickly.

An IETM production process should electronically integrate those areas of the logistics discipline that support the development and organization of technical information for system operation, maintenance and training.  In addition to training, these functions include logistics support analysis, human factor engineering, reliability/maintainability and maintenance planning.  In the process of forming an integrated end-user product, the IETM will make maximum use of existing electronic data to lower cost, maximize consistency and provide a medium for user inputs.

**2.12.6Supply Support**

Implementation of IETMs reduces the weight and storage requirements associated with paper-based manuals. As a result, weapons platforms are able to carry additional mission-critical equipment or stores.  Supply support costs will be decreased because there will be less mis-ordering of parts.  This will be a direct result of improved fault localization/identification via the expert-system troubleshooting routines available in IETM technology. This translates directly into reduced weapon-system maintenance costs and decreased time to repair.

# CHAPTER 3 CLASSES OF IETMS

**3.1IETM Definitions**

As IETMs began to proliferate, so did the methods for converting and presenting digital data. While careful not to inhibit innovation, the military did not want contractor proprietary solutions either.  NSWC, Carderock Division, released a document titled “DoD Classes of Electronic Technical Manuals,” which addressed five classes (Class I through Class V) of IETMs based on the source data format of the IETM and its functionality. 

The Classes are defined in fairly general terms that necessarily overlap.  They facilitate discussion of options and differences, but they are insufficient to serve as a basis for contractual use (e.g., direct the contractor to prepare a “Class III” manual).  The Statement of Work (SOW) or Technical Manual Contract Requirements (TMCR) should specify exact functionality requirements without referring to this set of definitions. The structure of each class is illustrated in Figure 3-1.  Table 3-1, found at the end of this chapter, summarizes the key points of each class of IETM, for ready reference.

**3.1.1Class I - Electronically Indexed Page Images**

These IETMs include digital page images obtained from raster scanning, using the Navy Implementation of Raster Scanning/Navy Image File Format (NIRS/NIFF).  They are intelligently indexed, based on the front matter (i.e., table of contents, list of figures/fold-outs/tables etc.) and rear index using MIL-M-29532.  This indexing allows the user to select a topic from front matter and have the corresponding raster page, from the body of the TM, automatically displayed or to create an automatic collation of page changes. Page orientation is retained and can be directly printed.

**3.1.2Class II - Electronic Scrolling Documents**

Most of these ASCII-based IETMs conform to Standard Generalized Markup Language (SGML), per MIL-PRF-28001, and link front matter to corresponding material in the body of the TM.  (Refer to Appendix A for additional information relating to SGML).  They may have additional links to cross-references, tables, figures, etc. and to voice, video, expert systems, or other special external applications.  They generally have word search and bookmark capabilities, electronic sticky notes, and may contain raster or vector graphics.  The linked manual can be viewed electronically or be printed in compliance with existing military style and format specifications.  While MIL-PRF-28001 is the preferred format at this time, other SGML formats (e.g., HyperText Markup Language, HTML) are emerging and provide similar benefits. A second format, Adobe’s Portable Document Format, PDF, is also being used for basic conversions. As discussed in detail in Appendix A, PDF is based on Adobe’s Postscript printer language and allows Class II interactivity.  However, the PDF file cannot currently be edited. Consequently, if the Government chooses to maintain the TM data through PDF files, it must first own or have access to the publishing system that generated those files before it can ensure that data maintenance and update responsibilities can be transferred between technical manual maintenance activities. Disagreements exist both within and between the services, about classifying PDF as a Class I or Class II document.

**3.1.3Class III - Linearly Structured IETMs**

These IETMs have enhanced functionality over Class II.  They may have MIL-PRF-28001 or MIL-PRF-87269 SGML tags applied to the ASCII text to allow user interaction through “view packages.” View package requirements can be developed to emphasize functional subjects, such as training, maintenance, and system overview.  Being linearly structured, Class III IETM files can be used to print hard-copy TMs.  But while all of the data will appear in the proper sequence, the printed copy will not necessarily be in the same format as the traditional "MIL SPEC" manual.  Class III IETMs can include optional linkages, such as voice, video, expert systems or special applications.  Some caution and planning are required, however, if a single database is intended to produce the IETM and publish the hard-copy TM.  

**3.1.4Class IV - Hierarchically Structured IETMs**

Class IV is a complete departure from the previous classes in which data is structured to support a classical publishing environment based upon sentences, paragraphs, chapters, pages, etc.  Class IV data is created or re-authored and then rebuilt into a database.  It is then managed as hierarchical objects within a database.  In acquisition, Class IV technical data is built into a structured database, using Logistic Support Analysis (LSA) disciplines and formats to create the database.  Data is only created once with no duplication.  For legacy TMs, two types of duplicate data are found:

· Identical data is exactly repeated each time it is found.  Examples include WARNINGs, CAUTIONs, NOTEs, common procedural steps, graphics, etc.  

· Redundant data sets convey the same information, but cannot be substituted for one another.  Examples include paragraphs containing essentially the same steps, but which must be managed as individual data sets, because the words within the paragraph provide a different context for each occurrence (e.g., refer to different figures or different preceding paragraphs). 

With Class III, identical data can be eliminated.  Because re-authoring is avoided to minimize cost or to preserve the ability to print hard-copy, much redundancy remains.  For conversion of legacy data to Class IV, data is re-authored to remove its formatting and to rebuild the data into a structured database.  Paragraphs or information can be decomposed to simple statements that approximate Logistic Support Analysis Record (LSAR) type of entries at the step level.  As the new structure eliminates previous need for duplicate data, the redundant data also is eliminated.  The application (view) program then provides the necessary context and transition.  The total amount of data being stored and managed is significantly reduced and multiple updates within the IETM are eliminated.  Other SGML based databases found in Class II and III IETMs also have the ability to store data once and apply it many times.  They, however, can only share these information objects within a single IETM.

Data linkages in Classes I through III rely on application programs such as scripting or hyperlinks to define the linkages between data.  Their Data Base Management System (DBMS) manages the objects, if applicable, but not the structure.  For Class IV, building a hierarchical database structure (typically following an LSAR) provides the inherent logic and the linkages among and between data.  This principle greatly simplifies the processing of change data and the use of application programs.  IETM data  modules are structured in conformance with MIL-PRF-87269 and may be represented as SGML-tagged files.  All item links are built into the structure of the DBMS.  The availability of modules (e.g., figures, text, tables, video, voice clips) enables the user to access information in a highly interactive manner and from a variety of paths.  The text is created or edited to have the same "look and feel" as the steps in LSAR entries.  IETMs have user interfaces developed in accordance with MIL-PRF-87268 and provide "frame-," rather than "page-" oriented displays.  The Class IV IETM can prompt the user or may directly receive fault code information from which the IETM software determines the appropriate path to display through the database. As its contents are contained in a hierarchically structured database, a Class IV IETM cannot be printed as a unit for distribution in hard-copy form.

A third primary difference between Class IV and the first three IETM classes is that the Class IV product is not bound by a predetermined sequence of presentation.  While the sequencing of data may be different for different view packages, Class II and III would have to establish the sequenced data files for each view package; Class IV would create it directly.  Class IV IETMs (and Class V IETMs that use Class IVs as a base) have the ability to naturally apply precondition and applicability statements within the IETM database and to "branch on condition found."  The program analyzes each condition and brings in the necessary data.  This process continues through to a logical conclusion.  By using these features, a Class IV IETM can display only "user specific" data from the database and can tailor presentations based on several input criteria.  For example, it may only present certain maintenance choices to a trainee, but present additional choices to a journeyman working with the same equipment configuration and fault indicators.  Class IV IETMs can share data sets among users, thereby making data maintenance even more efficient.

Program Offices may encounter contractors with significant investments in legacy publishing systems, legacy IETM software tools, and lack of work force training in or understanding of Class IV production processes.  These factors tend to weigh IETM recommendations away from Class IV functionality and toward the "status quo."  The persistent comparison of sunk costs in existing systems with investments needed to execute new technology generally fails to consider all costs involved in product creation and review or of the potential savings to be achieved throughout the life-cycle.  Nonetheless, the acquisition of SGML tagged "linear databases" can provide many of the end-user features and some of the advantages found in maintaining object oriented databases through different strategies of use. Whether object oriented or linear, SGML tagged databases support the longer term goal of the CALS data integration philosophy.

**3.1.5Class V - Integrated Database IETMs**

The Class V IETM combines the functionality and capabilities of an expert system with a technical database to allow the user to perform tasks more quickly and accurately. This *DSMC IETM Guide* does not address the requirements of expert systems or the efforts needed to achieve the full integration of a multi-functional Class V system.  It does address the IETM component of a Class V manual and the interface to an expert system.  Class V IETMs allow the subject matter experts (SMEs), in all areas (e.g., troubleshooting, fault isolation, accomplishing repairs, establishing alternate repair paths), to bring their knowledge to the maintenance unit and apply it in a specific situation.  The system and equipment diagnostic programs can "talk" directly to the user through the IETM;  relatively unskilled technicians can be led through complex procedures.  Seldom-used processes and procedures (e.g., annual inspections) can be properly planned and executed without significant research.  Programs will also typically analyze the data received and add it to the knowledge base to allow the software to "learn" and apply the knowledge to future analytical processes.

**Table 3-1.  IETM Classes**

Basic ETMs

IETMs

Class I

Class II

Class III

Class IV

Class V

Electronically Indexed Pages

Electronic Scrolling Documents

Linearly Structured IETMs

Hierarchically Structured IETMs

Integrated Database 

**D**

**I**

**S**

**P**

**L**

**A**

**Y**

Full page viewing

Page-turner/Next function

Intelligent index for user access to page images

Page integrity preserved

Primary view is scrolling text window

Hot-spot access (Hyper-links) to other text or graphics

User selection and navi​gation aids (key-word search, on-line indices)

Minimal text-formatting for display

User selectable call to (launch) another process

View smaller logical blocks of text - less use of scrolling

Interaction through dialog boxes

Interaction per Mil-PRF-87268 to extent possible

Text and graphics simultaneously displayed in separate window when keyed together

View smaller logical blocks of text - very limited use of scrolling

Interaction through dialog boxes with user prompts

Interaction per Mil-PRF-87268

Text and graphics simultaneously displayed in separate window when keyed together

Class IV IETM functions

Interactive electronic dis​play per Mil-PRF-87268

Multi-function display session

Expert system allows same display session and view system to provide simultaneous access to many differing functions (e.g., supply, training, troubleshooting)

**D**

**A**

**T**

**A**

**F**

**O**

**R**

**M**

**A**

**T**

Bit Map (raster)

Indexing and header files (Navy Mil- 29532)

MIL-PRF-28001 or Postscript

Generic: C/NDI imaging system formats

Text - ASCII or PDF

Graphics - whatever viewer supports - e.g., BMP or CALS

Can be SGML tagged - no page breaks (browser)

Access/index often C/NDI dependent with HyperText browser

Generic: C/NDI with HyperText browser

Linear ASCII with SGML tags

SGML with content vice format tags

Maximum use of Mil-PRF-87269

Generic: SGML tags equivalent to Mil-PRF-87269 tags

Fully attributed database elements (Mil-PRF-87269)

Mil-PRF-87269 content tags with full conformance with Generic Level Object Out-lines (architectural forms)

Authored directly to DB for interactive electronic output

Data managed by a DBMS

Interactive features authored-in vice added-on

Generic: C/NDI has Mil-PRF-87269 data definition/tags

IETM info integrated at the data level with other application info

Does not use separate databases for other application data

Identical to Class IV standards for IETM applications data per Mil-PRF-87269

Coding for Expert Systems and AI modules when used

Generic: C/NDI has Mil-PRF-87269 data definition/tags

**F**

**U**

**N**

**C**

**T**

**I**

**O**

**N**

**A**

**L**

**I**

**T**

**Y**

Access pages by intelligent index/ header info

View page with pan, zoom, etc tools 

Limited use of hot-spots

Useful for library or reference use

Browse through scrolling info

User selection of graphics or hot-spot reference to more text

Hot-spot and cross-reference usually added after original authoring

Dialog-driven interaction

Logical display of data in accordance with content

Logical NEXT and BACK functions

Useful as interactive maintenance aid

User-selectable cross-refs and indices

Content specific help available

Dialog-driven interaction

Logical display of data in accordance with content

Logical NEXT and BACK functions

Useful as interactive maintenance aid

User-selectable cross-refs and indices

Content specific help available

Single viewing system for simultaneous access to multiple info sources

Same as Class IV for IETM functions

Expert system to assist in NEXT functions, based on info gathered in session

# CHAPTER 4 Acquisition Of IETMs

**4.1Introduction**

The general philosophy of IETM acquisition is to procure, as a minimum, a Class II IETM in a format such as SGML or Indexed PDF.  (Refer to Appendix A for detailed information about SGML and PDF.)  The preferred option is to procure standard SGML tagged IETM data that are optimally structured to create survivable data in revisable and economically maintained databases by sharing common objects.  This philosophy is a key element in the migration toward the DoD’s Integrated Data Environment (IDE).  The IDE is a dynamic data environment in which all users draw from a common virtual database containing data maintained by an unlimited number of Government or commercial service providers.  A shared information environment providing immediate access to digital data supports the IDE.  An IETM may also be procured as a logistic support product under a major weapon system or equipment buy, as a separate item under its own contract to support new equipment, or as a conversion.

**4.2IETM Acquisition Process Phases**

Figure 4-1 shows the general phases involved in the IETM acquisition process.

**Figure 4-1.  IETM Acquisition Phases**

Criteria for the digital data infrastructure and implementation strategy of an acquisition program are included in the Government Concept of Operations (GCO).  This document is a necessary precursor for the subsequent phases of IETM development.  Both the GCO and the CONOPS (referred to below) are presented in detail in the next chapter.

**4.2.1Phase 1: Develop an IETM Concept of Operations (CONOPS)**

Chapter 5 discusses the IETM CONOPS in detail.  The document provides potential offerors with anticipated IETM support requirements of the proposed system.  Users and the issuing program can evaluate the proposed IETM solutions against the support requirements. The CONOPS provides a common language, set of assumptions and point-of-departure for all Government and contractor participants in the process.  It assists the program in ensuring that needed IETM resources are in place or that deficiencies are identified.  

Even with new acquisitions, much of the technical data supporting the system already exists.  The program decision to convert this data, usually to a standard digital format, involves a commitment of resources to accomplish one or more objectives to reduce costs and improve availability, productivity and quality.  However, each of the Services is either involved in or has completed major conversion efforts that have involved digitization of existing TMs.  Many of these are Class II IETMs in the form of Indexed PDF files or linearly structured SGML files.  Prior to deciding to convert data, the Program Manager needs to determine whether the data has already been converted as part of these digitization efforts.  The decision on the type of IETM to select is critical.  Selection impacts cost of conversion, available functionality ability to maintain and update data, ability to interface and interact with other data files, and the ability, cost, and effort to migrate in the future to newer technology. A functionality decision model is presented in Figure 5-2 to assist the Program Manager in selecting the best conversion model for his or her program. Development of an IETM CONOPS is a critical first step in establishing the conditions within and under which the IETM will be expected to function.  The act of preparing the CONOPS should raise and clarify issues and establish parameters.  It is important to document the conditions and assumptions that were used to make the IETM selection decision and to help formulate an implementation strategy. 

**4.2.2Phase 2:  Develop Procurement Package**

The IETM procurement process varies between Services. However, there is agreement that an IETM CONOPS must be developed prior to solicitation to ensure programs have properly planned for IETM definition, implementation and ongoing maintenance.  Upon development of a program-specific IETM CONOPS, the Program Office will follow procurement guidance for its service.

**4.2.2.1Sample List of IETM Deliverables**

The list of deliverables will vary depending on the Class of IETM being acquired.  The following is provided as guidance only and is not intended to be a complete or approved list:

a. Technical Manual Schedules and Status Reports. In-Process Reviews (IPRs) should be held at the 30%, 75% and 100% completion milestones to ensure all parties have a common understanding of the final product.

b. Outline Book Plan or equivalent (will apply to either the hard-copy TM or IETM and defines the content and the structure of the TM).

c. Quality Assurance Program Plan.

d. Software Development Plan. This plan should specify all software, including the utilities procured or developed to convert, develop, test or verify the IETM being delivered. Examples of software include conversion filters, Java applets or ActiveX controls that increase IETM functionality, and helper applications that may connect the IETM to training modules.

e. The DTD (as accepted) and its final SGML tagged file, including:

· Graphic images in MIL-PRF-28002 Raster 

- or -

· Graphic images in conformance with MIL-PRF-28000 IGES

- or -

· MIL-PRF-28003 Computer Graphic Metafile (CGM) series of performance specifications (note: audio, video, Expert Systems, and other externally linked files used within the Class IIIII IETM, or these same file types found within Class IV or V IETMs, are delivered in the runtime version of the IETM, as noted in item (h) below).

f. Any graphics that exist in vector format (vendor format).

g. Source publishing system file (vendor format) if other than that as described in item (e) above. This could be a Microsoft Word, Interleaf or PageMaker file.

h. Runtime version of the IETM.  The file that has been processed through the IETM application software that would reside on media to be viewed by the user.  This is to include all linked files in their compiled runtime format.  This deliverable is not required if the runtime version is the same SGML used as described in item (e).

i. CD in accordance with the SOW.

j. Hard-copy fold-outs bound in a Supplemental Manual (if required).

k. Audio and video materials in mutually accepted formats and media. Popular file formats for video are .AVI and .MOV; animation files are typically .FLI or .FLC; audio files are either .WAV or .MID.

l. A PDF file (only for those IETMs that are able to provide hard-copy products for distribution).

m. Contractor IETM cost data.

n. Configuration Management Plan for the software and/or the data, as necessary.

o. Software Licensing Costs (for distribution in the user environment).

**4.2.3Phase 3**:**Distribute Procurement Package and Evaluate Contractor Response**

Figure 4-2, the IETM Acquisition Process Model, illustrates the process of distributing an RFP and evaluating contractors’ IETM proposals.  The figure also illustrates what the Government and contractor must provide in the acquisition of IETMs.

The IETM Acquisition Process Model below contains two acquisition process scenarios.  Steps 1 through 6 plus 16 and 17 identify the process of acquiring an IETM only.  Steps 1 through 17 identify the overall IETM acquisition process when it is included as part of a larger system procurement.

Step 1:An IETM CONOPS is developed by conducting a data call in accordance with DoD 5010.12M during the acquisition planning process.  The data call is used to gather and define the IETM requirements from the appropriate Logistic Managers.  Note that the IETM CONOPS will include a list (including the scope) of all relevant software licensed for use by the program.  It will also require that the contractor stipulate the software packages selected and the anticipated total costs, including procurement of additional licenses for Government technical management, reviewing activities and users.  Note also that IETM requirements are a small portion of the total system Request for Proposal (RFP) (refer to Chapter 5 for more information on IETM CONOPS.)

Step 2:The RFP and IETM CONOPS are released to bidders.

**Figure 4-2.  IETM Acquisition Process Model**

Step 3:Contractors' proposals are received and evaluated against the IETM requirements.

Step 4:If a contractor’s proposal meets all IETM functional requirements, determine whether the IETM development costs are acceptable.

Step 5:If proposed IETM costs are acceptable, determine whether the contractor has addressed using IETM software that is currently licensed to the program. The contractor may select IETM development software that is currently licensed by the program or a specific Service.  If not, the contractor shall determine and acknowledge the costs to the program to obtain appropriate licenses for the contractor’s selected IETM software.  This should specify costs for acquisition and life-cycle use by users identified in the IETM CONOPS.

Step 6:Acquire the IETM.

Step 7:The program must evaluate whether the contractor satisfies minimum hardware system requirements prior to proceeding further within these steps.

Step 8:If the contractor does not satisfy proposed system requirements, note this appropriately and evaluate the next proposal.

Step 9:If the contractor does not satisfy IETM requirements but does meet system requirements, the program may consider whether IETM requirements are reasonable and justified or warrant modification.

Step 10:If the IETM requirements are to be changed, modify the RFP to incorporate the new IETM requirements with a modified CONOPS and distribute to the bidders.

Step 11:If negotiations fail to identify an acceptable IETM solution, the program can decide to acquire only the technical content in a non-IETM format.

Step 12:If the IETM requirements are not met and technical content only is not desired, resolve any differences through negotiations.

Step 13:If in-house or Service Bureau conversion of content into the required IETM is not desired, the contractor proposed IETM should be acquired.

Step 14:The program must delete the IETM runtime and possibly modify the other deliverables.  If these delivery requirements are dropped, the contractor will be responsible for developing and delivering the technical content and providing the source and SGML files, but not developing the IETM end product.

Step 15:Once the content is acquired by the program, it can be converted (in-house or by Service Bureaus) into an IETM having the required functionality.  SGML should be the data format in which the content is received.  If not, both program and contractor should mutually agree to the format.

Step 16:Determine whether the IETM software licensing costs are acceptable, whether the software contractor’s proposal meets program needs or provides significant features beyond those IETM tools currently in use; endorse the request to procure the IETM software.

Step 17:Acquire IETM and IETM software license. Acknowledge new IETM software licensing with appropriate Licensing Coordinator as identified in Appendices D, E, F or G.  The central tracking of the various IETM software packages used throughout the Service can assist in achieving economies of scale with IETM vendors as well as helping identify what IETM software may be available to the program at no charge.

**4.3Phase 4**:**Acceptance and Testing of IETM Products**

The TMCR describes the QA responsibilities of the acquiring program and of the contractor preparing the IETM.  Included in the TMCR are the detailed descriptions of the QA products and processes to be performed in developing and accepting an IETM deliverable.  Verify that the contractor has met all of the IETM functionality requirements through IPRs up to and including the final deliverable. Representatives from the user community (sailors, mechanics, technicians, subject matter experts) should be invited to review the product. Engaging the user throughout the IETM development process provides ample time for IETM product improvement.

# CHAPTER 5 Pre-IETM Development Issues

**5.1Introduction**

Today’s PMs face a dizzying array of issues when undertaking an IETM development program. Fortunately, processes exist which can assist the PM in determining the appropriate characteristics for the Program's IETMs. Two major processes (and resulting products), the Government Concept of Operations (GCO) and the IETM Concept of Operations (CONOPS), are addressed in this chapter. 

**5.2GCO Development Process**

The Defense Acquisition University has developed a GCO template, the GCO Generator, which is downloadable at http://www.acq.osd.mil/log/lro/toolkit/gco/gcointro.html, to provide a step-by-step tool that assists managers in selecting digital data for their defense systems. The GCO is a Government document that is used to provide information to potential offerors about the Government infrastructure and Integrated Data Environment (IDE) implementation strategy for defense systems.

The GCO planning process should start as early as possible in the acquisition process. This Government document is prepared during the acquisition planning stage for each procurement.   Development of a GCO will help ensure that the Government can access or receive, via the IDE, the correct version and formats of digital data products needed to acquire and support a defense system. 

The GCO can assist the Program Manager in determining:

p. Hardware and software systems the Government has, or is developing, to manage and use the data.

q. Data users, types of data, frequency of use, and timeliness of data access or delivery to each user.

r. Data use and the review/approval processes to support life-cycle functions.

s. User locations and their primary functions in support of the defense system.

t. Data interchange requirements including format, media, applicable standards, and existing telecommunications capabilities.

u. Access authorizations and restrictions.

v. Data acceptance requirements including data format, content, and the Government processes for accepting product data, processable data, or Contractor Integrated Technical Information Service (CITIS) data.

The GCO is developed by the Government acquisition team with input from other supporting Government activities involved in the life-cycle support of the defense system. The GCO should be included in the RFP (Section J) as Government Furnished Information (GFI). 

**5.3About the Tool**

The tool requires extensive input of program information dealing with the following:

· Program’s supporting activities

· Data use and how it is used

· Infrastructure in place at each activity

· Activities’ experience with the CALS standards and automated information systems

 For a greater understanding of CALS, Joint Continuous Acquisition and Life-cycle Support (JCALS), and IDE, refer to Appendix B. This information can be analyzed by the software and used by the Program Manager to determine the requirements and data environment that will be described in the GCO. The GCO document is generated from a database of text based on actual GCOs, which is then tailored by the Program Manager to suit the program’s requirements. The final output is either a digital or hard-copy version of the GCO document, including both the text and selected data tables.

The GCO Generator was originally developed in 1995 as a Navy software tool (version 1.0). The new version 2.0 is a DoD version that incorporates information from all of the services. Version 2.0 is not readily compatible with 1.0 because of many changes made to the GCO text database. Since a rewrite of the 1.0 version has been completed, any previously developed data should be regenerated with version 2.0 to produce the GCO text sections. 

**5.4The GCO Process**

The steps shown below are performed as part of the data collection, input, and analysis steps in the GCO Generator.  This information is presented in MIL-HDBK-59B.

1. Identify what types of data are required 

Product description data

Logistics plans and reports

Publications

Management and administrative data 

 2. Identify who will use the data 

Management

Engineering/Design

Supply

Training

Manufacturing

Maintenance 

 3. Identify what the user will do with the data 

View only

Comment/annotate

Update/maintain

Extract/process/ transform

Archive 

 4. Identify the user’s infrastructure 

Hardware

Software

Networks 

5. Identify the type of digital data deliverables 

Composed products

Processable data files 

6. Determine the required data format 

Document image file

Text file

Graphics file

Alphanumeric file

Audio/visual file

Integrated data file 

7. Determine what data interchange standards are required 

Document image standards

Text standards

Graphics standards

Application unique/data standards 

8. Determine the mechanisms and type of media for data delivery/access 

Hard-copy

Physical (magnetic tape, optical disk)

Online (CITIS)

Telecommunications (DISN, OSI, contractor specific) 

**5.5Generator Process**

This GCO Generator tool is designed to lead the Program Manager through the GCO development process, encompassing the following five steps:

· Data Collection. This step involves creation of a data collection survey that is distributed to supporting activities, preferably along with the normal data call information. This survey will gather information regarding the activities' infrastructure, data use requirements, IDE requirements, and experience with CALS standards and Automated Information Systems (AISs).

· Data Input. Once the surveys have been distributed, completed, and returned, all the data they contain is entered into a series of data tables. There is no requirement that data be entered into all the tables – only those that are needed by the program.

· Data Analysis. Data from the surveys is now analyzed to help determine the most common data formats and the overall experience with AISs (plus which ones to select for use by the program).

· CITIS Decision. Once the data has been analyzed, the Program Manager can determine whether or not and to what extent a CITIS should be implemented for the program.

· GCO Creation. After all the data is analyzed, writing the text of the GCO begins. The text contains five sections: 

1. Introduction

2. CALS Implementation

3. Data Requirements

4. IDE Requirements 

5. IDE Infrastructure

After all these tasks are complete, the GCO Generator allows the preparer to view all the GCO text assembled on one form for final changes and then print the final, complete GCO.

**5.6Selection of IETM Functionality**

Where the GCO assists the Program Manager in identifying the types (IETM, drawing packages, etc.) and the interchange standards (SGML, PDF) of digital deliverables, the IETM CONOPS assists the PM in determining IETM functionality.  Therefore, after the decision to procure an IETM has been made, the IETM CONOPS should be developed.  Whether acquiring new data or converting existing data for use in an IETM, the program must make key decisions in three areas: 

w. Functionality - The features and capabilities that are desired to support users.

x. Standards - Government, commercial, performance or other specifications, standards, conventions, etc. that will be used to establish hardware/software interfaces and to ensure data neutrality, transportability, and survivability.

y. Data structure - The method for creating or assembling the data and effectively and affordably managing it throughout its life-cycle. 

Each decision acts as an enabler, facilitator, or constraint on other decisions.  The selection of functionality has critical impact on:

· Cost and time required for conversion

· Functionality available to the users

· Costs and ability to maintain and update the data

· Ability to interface and interact with other data files

· Ability, cost, and effort to migrate to newer technology in the future.

**5.7Concept of Operations (CONOPS) Acquisition and Support Planning Process**

The first step in defining IETM functionality is to develop an IETM CONOPS. It is vital that the PM team preparing this document the many interacting factors, assumptions, and considerations that formulate an implementation strategy.  This is done in the IETM CONOPS, which establishes the conditions within and under which the IETM will function.  Preparing the CONOPS should clarify issues and establish parameters to help a manager select optimal IETM functionality levels consistent with program requirements.  If IETM development is to be contracted out, the CONOPS provides key information to the bidders. Whether an IETM is being acquired as part of a new hardware system, or being converted under contract, the resulting CONOPS will be referenced in the Request for Proposal (RFP), Statement of Work (SOW), Statement of Objectives (SOO), or Work Order along with the environment within which the IETM will be developed, fielded, and used.  Additionally, the SOO/SOW should include other information as required to help bidders prepare their proposals and assist the program staff in evaluating the responses to required and desired functionality requirements.

The decision on the optimum class of IETM can result from the accumulation of information from all of the factors in the CONOPS or from any single factor (e.g. remaining service life, complexity of the system).  The decision also may be made solely to satisfy external factors (such as direction from higher authority, required interface with other systems or manning).  Consequently, the CONOPS is not intended to be a “score sheet” with a weighted quantitative value for each factor and a “right” answer.  Instead, it provides a “check list” of items to be included in the deliberative process to ensure that the cognizant manager is assisted in selecting the highest level of automation and best class of IETM for his or her program. New conditions, such as changes in training philosophy, budget reductions, program phasing, evolving functionality requirements, emerging technologies, etc., may require that the CONOPS and its associated decisions be reviewed and changed.

**5.8Role of the CONOPS**

The IETM CONOPS guides the program in identifying and projecting the characteristics of the hardware system (whether already in the field or in process of acquisition) which the IETM will support.  (A sample CONOPS for the fictional "Sagittarius System" is included as Appendix H).  This helps to define the functionality of the supporting IETM.  

· The IETM CONOPS helps programs define/plan the processes required for the life-cycle support of the IETM.  The IETM Functionality Determination Model (Figure 5-2) uses system attributes data to determine the functionality required to support the intended IETM users.  Interplay between items in the CONOPS and the decisions of this model may result in a number of iterations before the plan is finalized.   

· Completion of the CONOPS provides a tailored document that highlights processes, issues, and considerations related to the successful implementation of IETMs in both program and DoD terms. When complete, the CONOPS will provide a common structured document that describes the anticipated factors and environment that affect IETM development and use. 

· The IETM CONOPS will provide program personnel and bidders with a broad perspective of the range of factors and issues affecting their proposed IETM solution.  The Government also will use the CONOPS to evaluate how well a bidder has understood and met the program’s IETM needs. Development may be iterative.  New conditions such as budget reductions, program phasing, emerging technologies and evolving functionality requirements may necessitate a review of the CONOPS and a reevaluation of some or all decisions.

· Finally, a key benefit of developing a CONOPS is that change is discussed as a part of the IETM development process. Factors critical to IETM success are highlighted in the CONOPS and monitored so that changes which impact IETMs can be quickly noted.  This helps to ensure that a proposed solution is not overtaken or overwhelmed by events or technology.  Decision processes are revisited and parameters adjusted, if necessary, to ensure continued success.  

Instructions for Figure 5-2

Step 1: The program identifies or projects the attributes of the system or equipment as they relate to the IETM, as the first step in developing the IETM CONOPS.  

Step 2:Does the user require an expert system?  Expert systems capture and broadly share technical support, where minimal levels of technical support may be available.  They provide the user with subject matter expertise that expands user levels of knowledge and detail, augments skills, and improves diagnostic and maintenance procedure accomplishment for complex systems. Training and foreign military support requirements should also be considered when evaluating expert system requirements.  The following lists some examples of system characteristics that may require the use of expert systems:

· In a new design where the diagnostics and processes are clearly laid-out and ready for incorporation with an expert system.

· A highly complex system with complex troubleshooting or fault isolation procedures.  The expert system keeps track of what has been done, what is next, other possibilities, etc.

· Critical systems needing reduced time from diagnostics to repair (e.g., flight line download and processing, online sensors connected to the expert system).

· Reduced maintenance cost from higher quality repair, reduced false return rates, “smarter” maintenance from system “learning,” more concise and accurate parts orders.

· Systems requiring supplemental training of all types.

Step 3: Is the IETM and/or the expert system to be integrated into the weapon system?  Some systems have the operating systems available that can support the processing of IETM viewing software.  This efficient use of computer processing capability minimizes the computer components required to support the IETM.  Is it intended that the expert system be embedded within the IETM.  If so, this may present additional hardware, software, and interface requirements.  If integration of the IETM and/or expert system with the weapon system or embedding of the expert system within the IETM is not a requirement, Class V functionality can be achieved through an independent system interface.  If the IETM does not need to be integrated, it can have a linearly structured database as found in Class I-III IETMs, which allows the entire TM to be printed for field and other users until all are outfitted with display hardware. The IETM display infrastructure must also consider any potential training and foreign military display support requirements.

Step 4: Is the user outfitted with display hardware, and are the display hardware maintenance processes in place to support these displays? 

Step 5:If the user is not or has no current plans to be outfitted with the IETM display hardware needed, the program may adopt a less capable strategy that allows for continued production of hard-copy (HC) TMs. 

Step 6:Is the IETM application a new acquisition or conversion of existing legacy TMs? 

Step 7: The costs for conversion to Class I and II IETMs are fairly well understood because of each Service’s TM digitization efforts, while the cost of conversion to the higher level Classes is still evolving.  Management decisions on the granularity and level of indenture needed, will also significantly impact these costs.  The Program Manager must decide whether the relatively high conversion costs for Class IV and V IETMs are offset by improvements in task performance and savings achieved in maintaining the database.

In addition to the system or equipment attributes discussed above, the following factors should be considered or emphasized:

· Periodicity of updates - More frequent updates will result in substantially more savings (cost avoidance) as compared with other IETM update processes.

· Configuration volatility – Object-oriented databases are very efficient in managing data in support of multiple configurations of complex systems.  For fairly static systems, the advantages are less significant. 

· Quantity of legacy data involved in support of the system - If a large amount of legacy data exists (e.g., greater than 500 pages), there is typically a lot of repeated data (e.g., WARNINGs, CAUTIONs, NOTEs, procedures, descriptions).  Redundant data can also be significantly reduced with re-authoring.  An object-oriented database provides the most efficient method to store, maintain, update and use this data.

· Cost reduction – With new IETM authoring tools being implemented in applications that require a significant reuse of data, it has been proven that IETM changes can be produced at 50% of the cost incurred in producing hard-copy changes using traditional publishing processes.

· Maturation – Object-oriented database strategy planning is a new field, with only a limited number of applications.  There are still only a few Class IV and V IETM tools currently available commercially.  

Step 8:Create an IETM with Class V functionality.

Step 9:If a Class V conversion is not cost effective when considering its benefits over the life-cycle, then the program must reevaluate the IETM/system requirements and optimize them to meet budgeting requirements.  Programs should also consider implementing IETMs in a phased approach, which helps lower cost impacts over time. 

Step 10: Do the contents of the manual(s) and the attributes of the hardware system support Class III and IV functionality?  Several factors need to be considered to determine whether Class III or IV functionality is the most cost effective in support of the system. The following factors should be considered:

•quality of the data•configuration volatility

•complexity of the system/equipment•manning requirements

•conversion costs•training levels

•system maintenance levels•contractor and Government infrastructure

Step 11:Are there plans to deploy the IETM in the field? In particular, if the IETM is to be Class IV (object database), “print screen” may be the only printing option.  As all data will be conveyed via the display hardware, it is imperative that the field have the appropriate display hardware and the support processes needed to maintain the IETM and IETM hardware in place.  The IETM display infrastructure must consider any potential training and Foreign Military display support needs.

Step 12: Is the IETM application a new acquisition or a conversion of existing legacy TMs? 

Step 13:Using the factors in Step 10, determine the costs and benefits of Class III and IV IETMs, and whether the budget will support a Class IV IETM conversion process.

Step 14:If program budgets support the conversion effort, convert the legacy data into a Class IV IETM by creating an hierarchical structure within an object-oriented DBMS using MIL-PRF-87269.

Step 15:Is the IETM application a new acquisition or a conversion of existing legacy TMs?

Step 16:If a Class IV functionality is not required, conversion is not cost effective, or the field will not be outfitted with display hardware in an appropriate time, then the program should determine whether converting legacy TMs into an IETM having Class III functionality is cost effective and affordable.  The primary element of Class III IETMs is the use of view packages, which can emphasize specific subject matter content within the IETM and only present the user with data pertaining to the subject controlled by the view package.  An IETM can have several view packages, each emphasizing a different subject (e.g., operator training, overhaul procedures, system overview).  The user might also be able to select view packages for novice, intermediate, and expert levels that present or emphasize the data differently.

Step 17: If view packages are needed and affordable, convert the legacy TM into a Class III IETM.

Step 18: Is the IETM application a new acquisition or conversion of existing legacy TMs?  If it is a new acquisition, the minimum functionality that should be procured is Class II.

Step 19: Determine if frequent updates to the TM are required.  If so, an IETM having Class II functionality is preferred over Class I.

Step 20:Determine whether the ability to perform “word searches” would significantly benefit the user.  This benefit must be weighed against the cost to convert the hard-copy into ASCII or other neutral format such as PDF, plus the cost of proofing the resultant file to ensure that it accurately represents the hard-copy.  If it is determined to be cost effective, an IETM having Class II functionality is preferred.

Step 21:If a digital file of the legacy TM is available, the program should convert the legacy data into an IETM having Class II functionality.  The cost to convert existing digital files into IETMs having Class II functionality is well worth the expense, by being able to use an automated publishing system to update information, as well as giving better navigational features (word search, links, etc.) to the user.  Note that each of the Services has already completed major TM digitization efforts that have resulted in either Class II IETMs or files easily convertible to Class II.

Step 22: If Class II IETM cost of conversion can be supported, convert the data into an IETM having Class II functionality.

Step 23:Convert the legacy data into, or acquire the IETM having Class II IETM functionality. 

Step 24: If Class II IETM cost of conversion cannot be supported, convert the legacy TM into a Class I IETM.

**5.9Inclusion in the Statement of Work/Objectives (SOW/SOO)**

The information presented in the CONOPS is not intended to be exhaustive, but should include the primary management considerations when deciding a program’s optimal IETM level.  Whether an IETM is being acquired as part of a new hardware system or being converted under contract, the resulting CONOPS will be referenced in the SOW/SOO along with the environment within which the IETM will be developed, fielded, and used.  Additionally, the CONOPS should indicate other information that helps bidders propose their systems and, in addition, helps the program staff evaluate the responses to the required and desired functionality requirements.  Do not substitute detailed descriptions and/or “laundry lists” of highly desirable or mandatory features for firm requirements.  This may restrict all bidders to a solution that may or may not be optimal or that unnecessarily drives up the cost of the proposed solution.  Where the program has decided on specific features, functionality or characteristics that are required to support various aspects of the system, they should be reflected in the SOW/SOO and Technical Manual Contract Requirements (TMCR).

**5.10CONOPS Development**

Development of the CONOPS involves analysis of the hardware or weapon system being supported, determination of the functionality required by the users of the system, and consideration of a variety of other factors that will be documented in separate paragraphs of the CONOPS. The following paragraphs suggest a sequence in which applicable subjects are covered in the CONOPS and describe what those paragraphs need to contain.  Other paragraphs or information that are deemed relevant to the common understanding of the system and its operating environment, the IETM and its operating environment, and/or any unique conditions may be added.  Use the outline below as a guide to develop your CONOPS.

6. Weapon System/Equipment Attributes and Factors Influencing or Dictating Functionality

7. IETM Functionality Determination

8. IETM Implementation Schedule

9. Urgency and Frequency of Information Update

10. DTDs and FOSIs

11. Graphics

12. Links to Other Information Resources

13. Security

14. IETM Licenses

15. Development of IETM View Package Requirements

16. Technical Manual Identification Number

17. Deficiency Reporting Process

18. Media Identification Labels

19. Building CD-ROM Deliverables

20. Display Hardware, Operating Systems and Networks

21. Environmental Conditionals and IETM Display Hardware

22. Display Hardware, and Software Maintenance and Support

# CHAPTER 6 CLASS CONVERSION MODELS AND PROCESSES

**6.1Introduction**

Although it is not incumbent upon acquisition managers to understand the intricate details involved in developing an IETM, they should become familiar at a top level with the decision making process required to field an IETM. This section has been extracted from the Draft IETM Process Plan as a guide through the steps to convert legacy data to IETM format or to prepare for a new IETM development program.

**6.2Conversion Decisions**

The program decision to convert data, usually from hard-copy to a digital format, involves a commitment of resources to reduce costs and to improve availability, productivity, and quality.  Although the IETM CONOPS is generally associated with a new acquisition, many of the issues and decisions confronting a manager are the same for a conversion project.  This section provides information and considerations on converting data from an existing legacy (generally hard-copy or basic word processing format) to an acceptable digital format with functionality that will benefit the user.  It also presents a functionality decision model that will assist the cognizant manager in selecting the best conversion model for his or her program.   This is the critical first step in developing an IETM CONOPS, which will establish the conditions in which the IETM will be expected to function. 

While reading this section, keep in mind that each of the Services is either involved in or has already completed major technical data conversion efforts.  These efforts primarily encompass conversion from hard-copy (paper or aperture cards) to either Class I (raster) or Class II (Indexed PDF) formats.  Therefore, any conversion required by the program would typically be from one of these formats to a higher level of IETM and not from the original data format; e.g., instead of having to convert from paper to a Class IV IETM, the data would be converted from a Class II to a Class IV IETM with an associated reduction in conversion cost.

Figure 6-1 provides a general overview of the process for converting legacy TMs into IETMs.  The decision on what type of IETM to select is critical, as it impacts cost of conversion, functionality available to the user, costs and ability to maintain and update data, ability to interface and interact with other data files, and the ability, cost, and effort to migrate to newer technology.  Note that Figure 6-1 represents the IETM phases for conversion to the preferred SGML-based IETM.  However, if the data is to be converted to PDF/IPDF (Indexed Portable Document Format) format, the only relevant question is whether the legacy data is in digital or hard-copy format.  The two options are:

z. Data in digital format (e.g., ASCII or native file format) - Output directly to PDF format.

aa. Hard-copy - Scan in the data and then either run the Adobe Acrobat Capture program to convert directly to PDF format, or run an Optical Character Recognition (OCR) program to convert it to a format that can be processed (e.g., word-processing).  At this point, convert it to PDF/IPDF.

Step 1: If the ASCII file including digital graphics (typically from a publishing or word processing system) of the TM can be obtained, the cost of converting and proofing can be avoided.

Step 2: If ASCII is not available, the existing TMs must be converted from hard-copy into ASCII text using OCR software, and graphics can be taken in various vector or raster formats.  In some cases the capability exists to go directly from the ASCII files into the authoring software, as indicated by the dashed line from box 2 to 4 in Figure 6-1 above.

Step 3:When IETM development is contracted out, SGML tagged data should be acquired to provide the program with the benefits described in the CONOPS.  Most IETM software tools allow commercial publishing formats to be processed directly through the IETM authoring software. Programs acquiring the data in this manner must be careful not to become locked into a single contractor or vendor product as the only source capable of maintaining the IETM database.

Step 4: The SGML/ASCII data is processed through an “IETM authoring software” to provide the features that the program determined it needs to support its system. 

Step 5:Conversion may result in data errors.  The data must be revalidated and reverified to ensure that the converted data file is an accurate representation of the original.  Where the conversion is from hard-copy to ASCII, the verification is straight-forward.  However, where the conversion includes linking, processing, dividing, re-authoring or replacing data (e.g., with video), an engineering certification must occur.  It will follow the normal TM validation and verification processes. 

Step 6: The result of IETM authoring software, a “runtime” version, may be a proprietary file that can be viewed only through vendor proprietary software.  To avoid this problem, the acquiring program should obtain an SGML or commercial format file which is compatible with its own TM support infrastructure.  There are some IETM viewing software packages that use the native SGML file in the viewer and therefore eliminate any proprietary concerns.  Distribution may be on CD, other electronic media or across the Internet.

**6.3Legacy Conversion Processes**

**6.3.1Raster  Conversion Process**

While some conversion from hard-copy to raster may continue to be required to update existing raster manuals, it is being phased out for new conversion efforts.  

**6.3.2Service Conversion Efforts**

All of the Services are currently involved in the conversion of drawings and documents into digital formats.  Descriptions of Air Force, Navy, Army and Marine Corps efforts are provided in Appendices D, E, F and G.

**6.3.3Class II Conversion Model**

Figure 6-2 describes the general process involved in converting a hard-copy TM into a Class II IETM.   TMs can be converted to Class II from existing legacy hard-copy TMs or they can be acquired as Class II source data from the authoring contractor or Government activity. Acquisition involves a slightly different decision-making process than conversion and has been  described in detail in Chapter 4 of this document.  As with Class I, development processes exists that may relieve the program of many conversion costs. 

Step 1:Determine required linkages.  They enable the user to select a desired item of data by having the IETM locate and present data to the user.  The front matter (e.g., table of contents, lists of figures or tables) are examples of specific items of data that are linked with their respective location in the body of the IETM.  Other examples are: parts lists that can be linked to the IPB; hazardous chemicals that can be linked to warning statements; and textual references that can be linked to tables, figures, and drawings.  Evaluate which optional linkages best support the user in accessing information from the IETM.  Optional linkages can be initiated by the user selecting an item within the IETM that links to external programs such as audio, video, an expert system or special applications.  The CONOPS  contains a table that allows the program to identify the type of linkages that are to be applied to a given subject.

Step 2: Is ASCII text required?  If the TM has significant change activity, then the cost of an Optical Character Recognition (OCR) can be offset by the savings incurred by being able to update and change an ASCII file.  

Step 3:If ASCII text is not required, arrange to convert to a non-SGML format such as PDF which can be further processed into an IETM having the functionality of a Class II IETM by adding an index and hyperlinks.  Note that PDF cannot be edited; therefore, the activity producing the PDF file has the only files that can be edited.  Programs should always have an editing capability by acquiring PDF files with the source files that produced the PDF.  PDF files can either be created from the word processing or other software used to create the original TM or they can be generated as an output of the scanning process.

Step 4:Incorporate the required and optional linkages determined in Step 1 into the PDF or other selected file format.

Step 5: Determine which software licenses are held at the implementing activity and whether any experts are available to advise on how to properly implement the IETM software.  If software has not been licensed for use by the implementing activity, the acquisition of software should be initiated. Chapter 4 outlines the steps to be followed in procuring IETM software.

Step 6: Determine which Document Type Definition (DTD) will be used by evaluating the structure and the content of the data that is to be SGML tagged.  DTDs and the software selected must also be compatible.  Existing DTDs must be used whenever possible.  Appendices D, E, F, and G explain how to obtain those official DTDs that are registered with each Service.

Step 7:Determine the availability of the TM in ASCII and the graphics in raster or vector format.

Step 8:If an ASCII file of the TM does not already exist, the hard-copy TM should be converted into ASCII.  The hard-copy graphics should be converted into raster or vector formats depending on whether they need to be modified. Raster graphics can be edited using “draw” type programs.  Complex or precise drawings become more difficult to raster edit and benefit from conversion to a vector format using vector graphics software.  The cost of conversion or redrafting to vector formats may be significant and the use of the software requires more training, but subsequent costs of updating the drawings and graphics will be greatly reduced. Most IETM software tools allow commercial publishing formats to be processed directly through the IETM authoring software. Note that all conversions should be validated or certified by the appropriate authority.

Step 9: The selected DTD and defined linkage requirements can be used to SGML tag the ASCII and graphic files.  Where the SGML tagged file is to be used to produce the hard-copy TM, any supplemental data that is presented as audio or video enhancements to the IETM must also be tagged and provided for the printed text.  Optional linkages must also provide a textual identification of the destination link (e.g., a reference TM, program, database). Paragraph numbers must be consistent in both the hard-copy and IETM to facilitate easy user reference between the two products.  If this is done, the SGML file can be processed into a hard-copy publishing system that ignores all audio and video tagged files when composing and printing.

Step 10: The resultant SGML tagged database is the source file.  All changes are made to this single source file to keep configuration control as simple as possible.  Using the SGML file as the source file requires an SGML authoring system or an SGML input/output filter to an existing publishing system.

Step 11: The SGML data is composed into a publishing system for hard-copy printing.  There is no Formatting Output Specification Instance (FOSI) used in this process.  The printed hard-copy will contain the same information, but may not have page integrity to the IETM.

Step 12: Foresight in developing the SGML file will allow the same SGML file to be used for both hard-copy printing and electronic display.  The SGML file is processed through “IETM authoring software” that produces an IETM runtime file, which is then distributed via CD, other digital media or the Internet.    

**6.3.4Class III Conversion Model**

The Class III conversion process, Figure 6-3, is the same as the Class II process with one notable difference:  Class III IETMs have view packages that enable the viewer to present only selected data from the IETM to the user. It should also be noted that an object-oriented database can be used here without having it integrated into the IETM itself.  The creation of view packages is accomplished after the conversion and SGML tagging of the data.  As with Class II, foresight must be used in generating the SGML tagged data to ensure that any audio or video information is represented by text and graphics in the hard-copy TM.  Note that PDF files are not currently appropriate for use as Class III IETMs because they cannot utilize view packages.

Steps 1-6Same instructions as the corresponding steps 1-2 and 5-9 found in paragraph 6.3.3 Class II Conversion Model.

Step 7: View packages are developed using IETM software tools.

Step 8: The resultant SGML tagged database is the source file.  All changes are made to this single source file to keep configuration control as simple as possible.  Using the SGML file as the source file requires an SGML authoring system or an SGML input/output filter to an existing publishing system. All changes to the source data must be validated to determine whether they affect primary, secondary or even tertiary linkages in the view packages.

Step 9: Foresight in developing the SGML file will allow the same SGML file to be used for both hard-copy printing and electronic display.  The SGML file would be processed through “IETM authoring software” that produces an IETM runtime file.  The runtime file along with other files are then written to distribution media.

 Step 10: The SGML file can be used to print hard-copy TMs by processing it into a publishing system.  As the SGML file will have surrogate text and graphics that represent the audio and video material used, the publishing system should be set up to ignore all audio and video tagged files when composing and printing.

**6.3.5Class IV Conversion Model**

Figure 6-4 shows the process for converting legacy data into a Class IV revisable database format.   While Class IV IETMs provide significant savings in maintaining and updating the data, the costs of conversion are currently high. These costs are due to the re-authoring of the legacy data to take advantage of Class IV functionality. The major costs of conversion are based on the following required tasks:

ab. Developing the hierarchical structure

ac. Re-authoring the legacy TM to prepare data for use in a database

ad. Selecting the level of granularity and indenture for decomposing each section

ae. Re-authoring and clean-up to eliminate repetition and redundancy

af. Adding photographs, animations, movies, verbal instructions, and other supplemental enhancements

ag. Naming common and unique data objects and linking them into a logical presentation

ah. Validation of the re-authored information

When Class IV IETMs are created from scratch, the level of indenture and granularity of the data is optimized at the lowest or smallest level (i.e., individual steps).  For conversions, the costs of driving all TM data down to this optimal level may be prohibitively high.  However, this is not the only logical option.  Class IV IETMs can be developed with the objects being roughly the same size as comparable objects in Class III IETMs (e.g., one paragraph or a procedure).  By minimizing the handling of the objects and substantially reducing the re-authoring desired or required, the conversion costs can be reduced to the same range as Class III.  This IETM would have the presentation features found in a normal Class IV IETM, but would not be as robust.  This compromise retains some redundant data, sacrifices some database maintenance efficiency, requires more update effort, and reduces some flexibility.  While some of the data may always remain in its initial conversion state, the program has the option of incrementally re-authoring specific sections of the TM (e.g., troubleshooting) down to the appropriate level of indenture (e.g., step).  These decisions can be made on the basis of specific maintenance needs, and funds available.

Step 1: Determine what authoring and presentation software licenses are held at the implementing activity and whether experts are available to assist in implementing the IETM software.  If software is not licensed for use by the implementing activity, the acquisition of software should be initiated. 

Step 2: Determine the DTD to be used by evaluating the structure and the content of the data to be SGML tagged. Existing DTDs must be used whenever possible. 

Step 3: Reauthor source data, creating objects of information in accordance to the selected DTD.  Eliminate repeated and redundant data. Create objects and linkages that allow these objects to be referred to many times.  Complex or precise drawings become more difficult to raster edit and would benefit from conversion to a vector format, using vector graphics software.  The cost of conversion or redrafting to vector formats may be significant and the use of the software requires more training, but subsequent costs of updating the drawings and graphics will be greatly reduced.  Some common hybrid processes allow vector overlays of changes to raster graphics, thereby allowing the use of vector graphic tools and precision without the cost of complete drawing conversion. Note that all conversions must be verified by the appropriate authority.

Step 4: Name these objects to enable the authors to identify the object subject matter content.  The named objects are used to create and tailor presentations (view packages) to subject matter requirements. Tailoring can be done to many presentation criteria such as training, user knowledge levels, system configuration, subject emphasis and overviews.

Step 5: Determine the linkages that best support the user in accessing information from the IETM.  Internal linkages enable the user to select a desired item of data and have the IETM locate it from within the IETM data file and present it to the user.  Some examples of linkage are: parts lists to the Illustrated Parts Breakdown, chemical names to warning statements, and text references to tables, figures and drawings. Desired external linkages should also be identified. External linkages can be initiated by the user selecting an item within the IETM that links to external programs such as audio, video, an expert system or special applications.  

Step 6: Have the appropriate authority validate the complete IETM against the source data to ensure that the same content has been conveyed using the Class IV IETM functionality.

Step 7:Once validated, the IETM can be written to the distribution media with associated files as required.

**6.3.6Class V IETM Migration**

The formal Class V IETM consists of a Class IV IETM which shares an integrated database with other associated applications.  Consideration should be given to the data configuration issues entailed when multiple logistics databases are integrated into a single database.  The decision tree in the CONOPS provides the model for determining whether formal Class V functionality is needed.

# CHAPTER 7 THE FUTURE OF IETMS

**7.1Introduction**

Since the advancement of technology does not stand still, neither will the development or application of IETMs. New, more cost effective methods for legacy conversion will be developed, faster computers and better monitors will permit a wider range of multimedia use, and users will demand real time access to data. As more and more information systems are fielded by the military, the user will eventually have access to a completely integrated operation that includes training, parts ordering/requisitioning and expert systems. 

Responding to an increasingly likely scenario that future military operations will consist of joint missions and in which one Service might be required to repair another Service’s equipment, DoD formed the Tri-Service IETM Interoperability Committee. The committee was tasked by the Joint Commanders Group for Communication and Electronics (JCG-CE) to develop guidance and policy to accomplish the following:

· Develop a uniform approach for electronically communicating and accessing technical data throughout DoD

· Maximize the use of C/NDI technology in the process

· Develop a common user information interface for field delivery systems

The committee is composed of representatives responsible for IETM policy from each of the services, and contractors with extensive experience with IETM development. It is important to point out that the committee is concerned in user interoperability, not data interoperability. (Data interoperability, basically implementation of MIL-PRF-87269, is being addressed by another IETM committee.) The committee meets on a bi-monthly basis and is conducting a DoD study to develop a solution for the JCG-CE and other IETM development and delivery issues.

**7.2Objective of the Study**

The objective of the DoD study has been to create a high-level Joint IETM Architecture (JIA) to guide and standardize IETM acquisition, management, and display.  This architecture will:

ai. Enable maximum interoperability in the use of technical information to meet the needs of the Defense Logistics community in supporting the material readiness of the military.

aj. Serve as the basis for a formal DoD-wide adoption of the proposed approach in promulgating the required acquisition and field-support policy.  To reduce the risk of implementation and to demonstrate utility of the approach, the policy recommendations are based on a series of FY99 pilot demonstration programs that will show the applicability of the Architecture to support IETMs for the whole spectrum of military systems.

**7.3Goal for the Architecture**

The primary goal for the JIA is to establish a technical framework for acquisition and deployment of the whole spectrum of ETMs. When completed, the user will be able to view and utilize technical information distributed to the work location through a common user interface, no matter what the authoring source or data format.  In so doing, the DoD will be able to establish a unified approach to the acquisition, management, and use of existing and newly procured IETMs.  

To meet this goal, the overall approach will be based on maximum use of existing Commercial/Non Developmental Items (C/NDI), the Internet and World Wide Web technology.  Another goal is to achieve end-user-level interoperability of the IETMs delivered to and used by the entire DoD Operational Community.  In this context, an ETM or IETM is defined as having end-user interoperability when it can enable a user with one common, commercially available display device, (such as a portable personal computer) to:

· View and interact with technical information from any source and of any internal format.

· Automatically access and view, by means of an electronic-link reference in the displayed technical information, additional information in any other ETM or IETM.

**7.4Technical Approach**

The overall concept of this JIA effort is to utilize the group of emerging technologies that the commercial marketplace is rapidly adopting as the standard for distributable electronic documents, which are, in general, based on the technology of the Internet and the World Wide Web.  For security and operational reasons, the DoD will not utilize the public Internet or the World Wide Web, but will employ essentially the same technology and C/NDI products in a private and dedicated DoD intranet environment.  Such an approach is becoming the de facto standard for corporate information distribution systems worldwide.  Once this approach has been proven effective, a set of implementation-guidance documents and performance specifications will be developed within this comprehensive, DoD‐wide, commercially supported framework.

A major objective of the JIA effort is to demonstrate user interoperability of proprietary and legacy IETMs.  This will be accomplished by encapsulating them into a common view package format, which can be electronically distributed to DoD intranets and eventually viewed by a user employing a single interface (i.e., browser).  This process is referred to as "object encapsulation.”  Such a demonstration will require the establishment of the following technical capabilities:

· An authoring framework to effectively create and manage IETM view packages for delivery to the Government, regardless of which authoring tools are used.

· An infrastructure that permits a military agency to distribute, manage, and deliver these IETM view packages.

· A methodology for the user to access and view the required technical information and to retrieve relevant data from other IETMs, including those of other Services, as necessary. 

In order to achieve interoperability, the interface requirements recommended for the JIA will be specific, but they will be constructed so as to encourage innovative and effective solutions, especially in light of the constantly expanding technology base.  Achieving this balance has required some decisions that may need to be reexamined over time.  Whenever possible, the design will adhere to open standards and/or de facto Internet standards widely implemented by multiple vendors, with clear intent to maximize the use of commercially available software products. 

**7.5Overview of the Architecture**

The JIA is firmly based on proven and widely accepted Internet and World Wide Web technology, implemented as a private Web on a contained intranet.  This intranet can be configured as a private DoD World-wide network (e.g., the Global Combat Support System – GCSS), as a combat-capable, unit-wide local intranet, or simply as a group of computers in close proximity hard-wired in a local Ethernet configuration.  It can also be configured in a single display device (portable or workstation personal computer) which operates as both a client browser and a personal single-user Web server.  The technology for implementing such an intranet is low-risk, easily implemented, and widely understood. The proposed Architecture is based entirely on C/NDI technology.  The Architecture is based on a dedicated Web intranet that has at least one Web-browser client and at least one Web server (more precisely, an HTTP (Hypertext Transfer Protocol) server and its included file-based store), as well as a network to connect them if they are not contained in the same computer.  The specific implementation of the network, which is typically a TCP/IP (Transmission Control Protocol/Internet Protocol)-based network when more than one device is involved, will typically vary from one implementation to another.  As will be described more fully below, the intranet may include other optional database servers and application servers in addition to the principal HTTP Web server.

**7.6JTA Compliance**

The Joint IETM Architecture will be compliant with the DoD Joint Technical Architecture (JTA). Individual services or programs may define the operating environments for their IETM applications, but neither the JIA nor the JTA require a specific operating system.  In technical terms, the “glue” (i.e., the communication protocol) that holds intranet Webs together is the Web protocol HTTP operating over the communications protocol TCP/IP, not the requirement for common operating systems.  A TCP/IP network (e.g., an intranet) can easily accommodate multiple operating systems on its server and client computers.

**7.7JIA Use of Internet and World Wide Web Technology**

The approach to developing a solution for this interoperability problem has been to adapt commercial and industry applications involving electronic documentation for which there is widespread vendor product support.  A JIA-compliant IETM product will apply the vendor software and standards being developed for the World Wide Web and the Internet in a dedicated and private intranet environment.  Following the rapid change trend in Internet technology, the JIA has been designed to be extensible, flexible, and able to accommodate the predictable rapid growth in technology for all aspects of the Internet, the Web, and emerging electronic documentation applications.  

The Web is, by its nature, a client/server architecture and there is one area on the client/server spectrum in which JIA-compliant IETM applications may differ in emphasis from a major “server-centric” trend that is emerging for many commercial enterprise applications.  The recommendations for implementation of the JIA are intentionally biased towards a model employing encapsulated objects that are downloaded to a portable device for use.  In this approach, the server is preferred as a utility electronic bookshelf for IETM view packages (i.e., the package of encapsulated IETM objects).  By analogy, these digital books are designed so they can easily be moved to another electronic bookshelf at another physical library site, reflecting the operational reality of the military unit itself.  On the other hand, commercial Web sites tend to be permanently located corporate resource centers at which both the servers and the information providers are located.  For these commercial activities, the mobile and less controlled entity is the user client.  In these applications, the preference is towards server-centric computing and the use of server-oriented, Web-object components.  The corporate personnel resources for maintaining both the Web server and the content are located at the Web site.  In military applications, the server sites resemble a technical library rather than a computer information center.  Technical expertise lies with the content creator or the user and not the administrator of the server.  This situation, at this time, dictates total object-encapsulation and “client-centric” computing as the primary emphasis of the JIA.

Progress in Web-oriented technology and the availability of secure, affordable military intranets offering global connectivity may change this in the future.  Thus, the JIA is intentionally designed not to preclude other solutions should such a change occur.  It is important to emphasize that any implementing policy for the JIA must include some specific guidance on how to apply the Architecture, as well as the requirement to conform to the Architecture.  The use of custom servers is an important issue for which guidance must mature.  Guidance documents for the acquisition of JIA-compliant IETMs must be continually updated.  Updates must be based on a continuing study of emerging military requirements, as compared with the current state of commercial technology and available C/NDI commercial products.

**7.8Proposed Requirement Documents for Implementation of the Architecture**

This section summarizes initial recommendations for the baseline requirement documents for the JIA, development of JIA-compatible IETMs, and infrastructure capability.

In addition to requiring the HTTP and TCP/IP networking protocols used by the Internet and  commercial Web-based intranet products, the JIA will be specified in the following areas: 

· Object Encapsulation and Component Interface.  This specification is needed for definition of the delivery, transport, and structure of the integrated collection of software components and data contained in the IETM view packages.  This specification include the interface between multiple components when they exist, and the automated mechanisms for placing the IETM on the targeted intranet.  It will also include requirements for the capability to automatically install these components on a user device in a manner sufficiently simple so that no professional system administrator is needed.  It will include a primary specification to tell the IETM developers in what form they are to deliver the IETM view package.

· Intranet Server and Database Interface.  For those IETMs that require the services of an application server and/or a database server, the IETM supplier must provide the proper software extensions to the basic JIA intranet Web server if they are not already in place.  This specification outlines cooperation between the developers of the user intranet infrastructure and the IETM provider, and the interfaces and protocols involved. The JIA is designed to recognize the fact that it will be necessary to install software using conventional system administration practices on fielded servers in order to achieve needed functionality. (This is not to be the case for the components fielded on JIA-conforming user browsers.)  This specification/guidance document will provide the requirements that an IETM provider must take into account when proposing or delivering such a capability for a JIA intranet.

· Common Browser.  The immediate target for this specification will be the procurers of user PEDDs (Portable Electronic Delivery Devices) and workstations, since the installation of this standard browser will be required for these devices.  The browser software component must be pre-installed on the PEDD since it is not included in the IETM view package.  IETM source will also be affected by this specification since the IETM must be formed and viewed using any JIA-compliant browser. Two products dominate the Web-browser commercial marketplace at present, Microsoft Internet Explorer and Netscape Navigator, and the thrust of this specification is to specify the configuration of each so that they will be functionally equivalent in any JIA intranet.  This will involve some extensions to the commercially-released products via plug-ins and controls.  There would be viewing capabilities common in military IETMs such as CGMs or the common PDF used for legacy TMs. 

· Electronic Addressing and Library Model.  This is the overarching specification that holds the enterprise collection of IETM information together by means of digitally encoded and executable-link references.  The specification itself will define the syntax and mechanism for building and executing the automated links to the IETM content and the IETM presentation software.  Two additional areas regarding administration and enforcement of the recommendations are needed so that the enterprise-wide addressing concept will work.  The Electronic Addressing and Library Model specification will discuss these aspects, which includes the actual bureaucratic administration and allocation of the DoD-wide IETM  “address space.”  This is the indexing or Uniform Resource Locator (URL)-based electronically processed numbering system to which the services and their suppliers must subscribe.  The specification will also discuss the area of the library model which can be used to perform an intelligent content-based access to another IETM when the exact specific locator is not known. To support the proposed Library Search functionality, the specification will also specify and require metadata files, encoded in eXtensible Markup Language (XML), which will serve as the primary search index files.

The Object Encapsulation and Component Interface, Intranet Server and Database Interface, Common Browser, and Electronic Addressing and Library Model technical descriptions are all needed to effect interoperability of disparate IETMs in the field. The specific DoD form of these technical descriptions (i.e., whether they all should be formal DoD Performance Functional Specifications or some other type of guidance document) will be determined at the time the final recommendations are formulated at the end of the DoD Interoperability Project.  

The overall interoperability goal is the ability to view any IETM with any browser that conforms to the JIA Common Browser technical description.  It also requires that all cross-references by one IETM, to another IETM, be encoded in a standard manner (i.e., in conformance with the Electronic Addressing technical descriptions) so that the IETM browser will be able to access the referenced IETM by a simple user selection (e.g., a mouse click).  The other two specification areas are subordinate to these two user requirements, but are very important to ensure that contractor-delivered IETM view packages and the DoD infrastructure provide the needed user interoperability.

The following paragraphs contain a short summary of the concept and philosophy embodied in each technical description.

**7.8.1Object Encapsulation and Component Interface Technical Description**

A core philosophy underlying this architecture is that developers of IETMs can deliver, as a single view package, all capability in the form of data and software contents needed to install and use an IETM on a standard DoD intranet.  This technical description provides the IETM suppliers with the form in which they are to package and deliver the digitally encoded IETM.  This view package may contain both content data and software components that have been combined into encapsulated objects and delivered as a contract package for electronic archiving or subsequent store-and-forward management.  There is no provision for separately delivering an IETM player or piece of viewer software for installation onto the user device. The view package will contain the capability to be automatically installed onto the user intranet upon arrival. 

The encapsulated data and software objects will eventually be delivered by the operational infrastructure to the field user as though they were simple binary data packages.  These packages will be treated by the infrastructure as file-oriented data destined for an agency intranet Web server. The packages will appear simply as a generic “bucket of sequenced bits” that make sense to the server.  The infrastructure activity need only make certain that these bits remain packaged together.  The view package is a set of industry standard binary files, each of which is assigned a JIA notional locator (e.g., a URL [Universal Resource Locator] conforming to the JIA addressing model) that contains sufficient information to support its installation as data in the intranet server file system.  

The complexity and degree of integration of these view packages will vary greatly among differing IETMs.  Some will simply be a two-part collection of one software component and one data set.  The simplest form will be a single set with all of the needed software contained in the standard JIA browser.  In other forms, a system of software components and possible multiple data sets will spread out among several servers and the browser device when the IETM is operational.  This would be the case when there are background software agents operating that might be performing diagnostics and system monitoring.  Another emerging technology requiring complex IETM objects entails the use of software agents (acting as mentors) inserting training aids into the job-aiding presentation when the agent (a computer program) determines that they are needed.  In between there is a spectrum of complexity, each level requiring a different object-encapsulation approach.  The “object” nature of these view packages is that all the intelligence to construct the operational IETM on the target intranet is contained within the view package objects themselves.  There is no standard for the internal constructs of the view package in the JIA.  This is the characteristic of the object-oriented approach utilized by the JIA.

Until the point of receipt by the intranet server, the view package is processed as a single object.  There are a variety of mature approaches for bundling a set of files with headers into a single data set (e.g., Internet MIME [Multiservice Internal Mail Extensions] Standards). The Architecture may use any of them, requiring only that the view package can be installed as a set of files on the intranet server(s).  With this approach, no overt man-in-the-loop software-installation processes are required other than the automatic capability built into Web-capable browsers and servers.  Many technical options exist for encapsulating view packages; however, this requirement for automated software-component installation using Industry-Standard Web practices is critical to determining the extent to which an encapsulation approach is satisfactory.  

**7.8.2Server and Data-Base Interface Technical Description**

The simplest way for the JIA to achieve IETM interoperability for the DoD is to utilize only generic Web servers. This approach will not require additional software to be installed on either the servers or the browser device.  However, some legacy systems and some highly innovative new IETM applications may require custom server extensions and database interface components.  For complex IETMs, which require extended services operating on an intranet server, installation will likely involve two phases.  One phase will be to “extend” the intranet, a process governed by the Server and Database Interface Technical Description, and the other will be to install the data and required browser components, a process governed by the Object Encapsulation Technical Description.

Final recommendations on the use and encapsulation of server extensions will require additional technical investigations, since the technology and marketplace need to mature before the development of specific recommendations can be accomplished.

**7.8.3Browser Technical Description**

In line with the philosophy of this Architecture to use de facto Industry Standards, the browser requirements are established by the two particular commercial products, which together have captured essentially the entire Web browser market. While it is possible to develop, assess, and evaluate a long list of needed and desirable requirements for the IETM browser, such an exercise would serve little purpose in light of economic and marketplace realities.  New Web browsers are software products that are very complex and expensive to develop.  Furthermore, the current products are being offered in the marketplace free of charge, effectively precluding the development of additional commercial general-purpose browser products.  At this writing, these two products are Microsoft Internet Explorer and Netscape Navigator.  Except for a few (but very important) capabilities discussed below, these two products are functionally identical.  For existing Web pages, they perform in a similar fashion.

The Browser Technical Description will specify the appropriate version of the commercial browser products and a set of standard extensions (i.e., controls and/or plug-ins) to these browsers.  These extensions will include common DoD data viewers for file formats such as PDF, SGML/XML, CGM Version 4 Graphics, and CALS raster images.  Since an XML capability will be in the basic functional set, the Version 5 release of these two products will probably serve as the baseline.  These will be the first versions of both browsers to support XML and both companies (Microsoft and Netscape) have aggressive plans to add this capability. The inherent capabilities of the JIA-compliant browser will include basic presentation methods, either native to the commercial browser or added to meet JIA requirement, so that the component portion of the encapsulated object can be assumed to be preinstalled on the user device.  In most cases, these particular components need not be included in the view package.  Native browser support includes components such as HTML layout, GIF (Graphics Interchange Format) viewers, and JPEG (Joint Photographic Experts Group) displays.

One major area of difference between the two browsers lies in the area of object brokering and the automatic downloading of components.  Ideally, it would be desirable to require that IETMs operate with either browser in its out-of-the-box form; however, the JIA Study Team has concluded that such a policy would restrict some very needed capabilities regarding the “downloadable” components needed for the JIA object-encapsulation concept.  The differences are due to the lack of cooperation on the part of the two competing companies (Netscape and Microsoft) to provide compatible solutions for the marketplace.  The generic capability to automatically download and install software components is essential to the JIA, so it may be necessary to chose one over the other for a specific implementation.  To support users of Microsoft Windows 95, 98, or NT-based devices (which includes the vast majority of portable devices available), it is desirable to utilize products supporting the Microsoft Distributed Component Object Model (DCOM) object standards that provide turnkey support of this feature.  For communities employing Microsoft software, it is strongly recommended that both browser products be enhanced (by third party plug-ins if necessary) to support DCOM objects (especially the downloadable ActiveX controls).  These are the most efficient formats for executable programs running in a Microsoft 32-bit operating system.

There is also a marked degree of difference in the way the two products handle Dynamic HTML (DHTML), an emerging technology for putting intelligence into actual Web pages.  However, because of the lack of consensus in the vendor community on DHTML standards and the fact that there are options for this functionality, the JIA Study Team has not yet establish this requirement as part of the minimal baseline and currently discourages its use in DoD programs.

The eventual goal is that all valid DoD IETMs be compatible with both the Internet Explorer and Netscape products.  This may require some installed extensions to make the two products interchangeable to the maximum extent possible.

**7.8.4Electronic Addressing and Library Model Technical Description**

The syntax for JIA electronic addressing will be based on the URL standard for the World Wide Web because it is widely implemented in virtually all Web-enabled vendor products. Any occurrence of a legitimate URL string of characters is automatically made "hot" in the vendor application, and a “mouse click” or two, on the hot spot, will launch a Web browser search which will locate the file referenced by the URL and display it on the screen. In addition to requiring a standard syntax, the Electronic Addressing and Library Model Technical Description will also require that all of the Services maintain and publish a permanent registry of all valid references to the IETMs issued by that Service. Once published, a valid URL must not be changed.  This type of URL is called a persistent URL.  In order to ensure that URLs are indeed persistent URLs, the JIA recommends the use of virtual URLs (vURLs).  These are URLs that use an administratively assigned server reference, notated by URL syntax; however, the referenced server exists in name only.  That is, it does not actually exist on a network and is used for data management purposes only.  When the IETM is installed on a network, the vURL is remapped to the server on which the IETM data resides.  (This is easily accomplished in practice using what are called Host files and/or Domain Name Services (DNS) in accordance with standard World Wide Web practice.) 

The specification will address the requirement for the remapping of these vURLs (which reference a hypothetical server on the World Wide Web) into the actual server and file system locations on the intranet.  The Specification will also outline an on-line, search-oriented Library Model and identify the requirement for a standard metadata package to support on-line searches.  This metadata package will be encoded in XML and attached to each IETM view package, which will contain indexing information useful for automated search engines in identifying an IETM reference. 

**7.9Basic JIA Operational Flow Diagram**

Figure 7-1 shows the flow of IETMs through the JIA.  It illustrates the employment of the JIA by the original IETM developer, the management infrastructure repository, the user-site intranet server, and the user who selects the next object to view via a point-and-click Web-browser interface.  The presentation components referred to can be either client or s erver components or implied (i.e., omitted) in the cases in which they are preinstalled in the standard browser. 

**7.10Benefits of Employing the Architecture**

Although implementation of the JIA produces a number of significant benefits, it will primarily benefit the end user, the IETM developer and the DoD IETM Distribution Infrastructure.

**7.10.1 Benefits from the User Perspective**

The principal benefit of the JIA is that the user will be able to utilize a single device to read any DoD IETM, no matter which Service originated it.  To accomplish this, the user accesses and views the IETMs with either a workstation personal computer in a shop environment or a PEDD.  The portable device will be configured either as a network client attached to the unit intranet or it will be reconfigured to operate in stand-alone or detached mode.  In either case, the display of the information on the user interface is identical, and the user cannot determine from the look-and-feel of a screen display the mode in which the device is operating.

A major benefit of the JIA to the user is that all information is viewed through a common and very familiar Web-browser interface.  To access an IETM, the user will select a URL reference using one of the many access-screens or menu-select options available (e.g., favorites list, explicit entry, a preassembled list of active IETMs on a unit Home Page, a hot-spotted index graphic, or a Web page job assignment form listing the needed technical references).  All of these are common practices borrowed directly from the World Wide Web community.  From the user’s perspective, the referenced IETM content simply appears in the browser window.  

A major benefit to the user organization is that no explicit software installations are required to utilize an IETM even on a new out-of-the-box JIA-conforming browser device.  Depending on the browser security level set, the user may, need to accept software components that require installation by an acknowledgment but for which no explicit installation action is needed; the browser installs the components automatically. This is an essential user-friendly feature of the JIA.  Thus, there is no need for a trained and certified system administrator to install user software.  

Another key benefit of the JIA is that the Web-based access methodology is a proven “point and click” user interface.  If one IETM contains a reference to another IETM, the user can “click” on the highlighted reference and that referenced IETM will appear in the browser window (assuming, of course, the referenced IETM exists on the user’s intranet).  This second IETM can in turn reference a third IETM.  To return to the original IETM, the user simply uses the “back” arrow on the browser interface, effectively reversing the references.  Modern Web browsers can handle many levels of such nested referencing with no performance degradation.  From the user perspective, the JIA is thus intended to make the use of disparate IETMs as easy and “seamless” as possible with modern technology.  Because of the nature of the Web browser technology employed, the user experiences a great deal of common “look-and-feel” in the interactive (navigation-control) area, even if the individual IETM user-interface for the content varies. 

A common practice on the World Wide Web is the use of search engines such as those employed by Yahoo and Excite.  The JIA Library Model and the required standard XML-encoded metadata package are specifically designed to facilitate the inclusion of search engines on a JIA-conforming intranet.  In these search engines, the user will enter a list of key words or reference designators and the search engine will identify possible IETM references available on the user’s intranet.  The JIA will not specify the search engine, but a rich selection of commercially available search engines, which build their indices from XML- and HTML-encoded sources and can easily be employed on a JIA intranet, is expected.  The ability to get all the information needed to perform a task in a timely and convenient manner has, from the beginning of the IETM concept, been one of the promised performance-enhancing capabilities of IETMs.  This JIA implementation, using low cost commercially available technology, will permit realization of this capability.

**7.10.2Benefits for the IETM Developer**

The principal emphasis of the JIA from the IETM-developer perspective is that all software components and data needed to make an IETM accessible on the JIA display device are bundled into a single digital product (i.e., the encapsulated object), which can be easily installed as a set of data files onto an intranet-server file system.  The primary benefit to the IETM developer of that object-oriented concept is that he/she is free to choose whatever authoring and development environment is preferred.  The JIA does not dictate how the IETM is to be developed nor what the internal format of the IETM object must be.  External interfaces are in accordance with electronic-document authoring environments which are being adapted to operate on the World Wide Web and, as such, should operate equally well on a JIA-compliant intranet.  Proofing tools for IETM objects are also easy to set up as a JIA-compliant intranet and JIA browsers are made up of available software products which the authoring activity can procure.  Again, the design philosophy for the JIA is to use the best readily available commercial practices for developing and deploying IETM products.  

While the technology needed to bundle all of the IETM components into a single digital package is complex, it is readily available in C/NDI products.  These are inexpensive, relative to traditional IETM products, and easy to obtain.  There has been an unprecedented rush by suppliers to get competitive products into the commercial market.  A fundamental principal of the JIA is that the products developed for the Internet can be used to develop IETM products for a JIA-compliant intranet.  This process is in contrast to current practice, where the IETM product is delivered as two separate items, the IETM content data and the IETM presentation system software program.

**7.10.3Benefits to the DoD IETM Distribution Infrastructure**

The primary benefit of the JIA to the DoD IETM digital distribution infrastructure is that encapsulated IETM objects can be distributed without requiring that the distributing system know what is inside the electronic capsules.  The infrastructure activities can therefore be simple distribution centers, for which the DoD has substantial experience, and not data-processing centers, which would be much more difficult to operate and staff.  

The specific design of and development of a specific DoD component infrastructure is not within the scope of the JIA effort.  This infrastructure design will undoubtedly be a complex task that will be further complicated by the impact it will have on many existing business practices.  However, the JIA element which enables the objects to be processed as an item of supply (with no requirement to manage the internal content or structure of the object), should make this task more manageable.

**7.11Architecture Types**

In practice, the implementation of an IETM intranet may be simpler (as is the case with basic HTML pages) or more complex (as is the case with most custom servers) than the baseline Operational Flow described in the previous section. The following breakdown of anticipated IETM view packages by architecture type is presented to categorize variants and to provide implementation guidance.  Any particular IETM intranet implementation will typically contain a mixture of these types.  The four types of categories represent a continuous spectrum of variation (i.e., some applications will be difficult to categorize precisely).  However, identifying the types will make it easier to present guidance in the JIA, particularly regarding the Server and Database Interface Specification.  Definitions of these Architecture types are given in Table 7-1. 

Type definitions are grouped into two categories:

23. The baseline architecture, IETM Architecture Types C1 and C2.  Definition of these two client-centric Architecture types has essentially been completed.  These types require only a browser and a generic HTTP server.

24. The extended architecture, Architecture Types S1 and S2.  For these server-centric types, the technology for employing the additional servers in the Web environment is less mature and more diverse.  This segment of the marketplace is emerging and it is still dominated by proprietary products.  This situation is in large part due to the fact that vendors have opened the browser products to the public domain (a market in which there is little money to be made) and have kept the server market proprietary (where vendors see profit potential and seek competitive advantage).

**7.12Characteristics of Architecture Types**

Architecture Types C1 and C2 share common important characteristics in that they do not require installation or operation of unique software on the server.  Thus, the server can be treated as an electronic bookshelf.  As far as the server is concerned, the two parts of an encapsulated object (the data and the associated software components) are simply treated as files.  Additionally, any contemporary HTTP server can be employed and it does not matter what operating system is utilized.  Thus, for Type C1 and C2 IETM applications, interoperability is very low-risk in the sense that, any IETM view package can be accessed using any server. Only a generic server is required for Types C1 and C2 and no JIA-specific server specification is required.  Both types are considered pure encapsulated-object types; however for Type C1, the component part of the object can be implied (i.e., omitted), as its presence can be assumed as preinstalled on any JIA-compliant browser and need not be included in the transported IETM view package.

The Type C1 definition is closely tied to the specific versions of HTML and XML, a factor which needs further clarification.  For planning purposes, it is recommended that emerging standards (and not current standards) for both HTML and XML be used to define the JIA requirement.  In this light, HTML/XML is herein specified as employing both HTML version 4.0 and XML version 1.0 (including the associated XSL style and XLL linking specifications), when these two International W3C (World Wide Web Consortium) standards are formally approved.  HTML 4.0 is a mature specification and should soon be approved, while the XML family of standards is still a year or two away.  There are several reasons for this recommendation.  The future standards will almost certainly be relevant in the time frame when most applications are developed according to the proposed architecture, so the best estimate as to what will be applicable should be used.  Vendor implementations of the draft standards are available now for test purposes.  

Another important consideration is that there has been written commitment by many major software vendors to support future standards, whereas there is no complete agreement on the delivered-product support of the current standard (i.e., HTML 3.2).  In particular, vendors have indicated support of the emerging HTML 4.0 standard.  Additionally the XML standard has elicited widespread vendor promise of support as a user-extensible expansion of HTML.  XML lags behind HTML 4.0 in maturity, but is sufficiently complete so that prototype software exists from major vendors, and shows promise of becoming a Web-based tagging standard that is more suited to complex IETMs than HTML. In particular, it will be much easier to convert the large DoD inventory of SGML-tagged source data to XML for a run-time object than it is to convert it to HTML for presentation.

For Type S1 and S2 IETM applications, the situation for ascertaining de facto industry practices is much more complex.  Several approaches are available for standardizing many issues such as Microsoft’s design-time controls, Active Server Pages (ASP), and Front Page server extensions, and a variety of third-party middle-ware products; but they are all proprietary and not universally accepted.  The technology of C/NDI are not sufficiently mature at this time to propose any one of them as a DoD standard so that all IETMs can operate on a single server.  There are two possible approaches for a working solution to operational interoperability with a particular server in the short term:

25. The various IETM providers must put their own physical server(s) plus the IETM view packages on the shared user intranet.  This is very feasible with the state of the art and capacity of today's portable computers and plug-in network standards; or

26. Require that all IETM creators use the same sets of server components and that the standard components be installed on all intranets employed in the community throughout which the IETMs are interoperable.  However, for multi-service operations, this alternative is not practical.  

**Table 7-1.  Proposed IETM Architecture Types**

Type

Characteristics

Examples

**Type C1:**

**Basic HTML/**

**XML Pages**

****

HTML/ XML page(s) with only browser-resident components. Requires no component licensing. Most will work on any browser. Includes HTML 4.0 scripts.Client processing only. “Basic” HTTP server.

HTML with Java script, GIF, JPEG, frames

XML + XSL Style Sheets

****

Note:  HTML/ XML pages may be used to include one or more Type C2 custom components.  If the HTML/XML tags no displayed content, it is considered Type C2.  If it does contain tagged data, it is a combination C1/C2.

C1/C2 examples:

HTML file plus Java “bean(s)”HTML file plus plug-inHTML file plus ActiveX control(s)

**Type C2:Simple Component**

****

One data set plus one custom automatically downloaded non-HTML component

.pdf plus Acrobat reader control .doc plus WordView control

****

May be nested Type C2 data-set/component pairs (“encapsulated objects”).  First component loaded into browser shell/container has capability to access another client component and associated data set under control of original component. Requires component licensing.  Not recommended for new applications.Client processing only. Uses “basic” HTTP server.

Legacy systems reprogrammed as custom browser or presentation system operating inside a standard browser shell/container.

**Type S1:HTML Plus Application Server**

Two-tier architecture in which Web page includes reference to server application(s), which must operate before page is delivered to client as Type 2 HTML/ XML.  Data and components managed on server.  May utilize database collocated on server, but most content is in Web page files.

Requires HTTP server with components for server-side computations. Requires client*and*server processing.

MS Front Page WebsMS Design-time Controls

CGI Server AppsDynaWeb

**Type S2:**

**HTML withDatabase Server**

Three-tier architecture that includes a Web page server with pages functioning like a template; e.g., for calls to a database, which contains most of the IETM content.  Can include server and components for custom functions. Requires a database server (e.g., Oracle) in addition to the HTTP server.  Can use MIL-PRF-87269 Data model for database on server.

Permits both Client*and S*erver processing.

AIMSS 4.0 (planned)GD  TechSight WebMS ASP w/ODBC Calls

**7.13Elements Diagrams for Architecture Types**

The core Architecture (Types C1 and C2) requires two kinds of software elements: client browsers and Web servers, as illustrated in Figure 7-2.  In general these are hosted on separate devices connected by a TCP/IP network.  However, an intranet can also be set up in a single display device without a network.  In the case of IETM Architecture Types C1 and C2, these two kinds of elements are all that is needed.  In the case of Type S1 (Figure 7-3), a requirement exists for an additional element, the application server, sometimes referred to as a Web server extension, since it effectively operates in the same operating system as, and is an extension of, the HTTP server.  In the case of Architecture Type S2 (Figure 7-4), there is the additional requirement for a database server which hosts most of the IETM content, which may or may not be hosted in the same device as the Web server.  A Type S2 application usually includes aspects of a Type S1, since it requires an application server to process the data access and request dialog between the Web server and the separate database server.  Note that while the line between these two types may not be clear, in general they differ in where the primary data content is stored (i.e., in the server files or database server).  

**7.14Pilot Programs**

Each of the services selected pilot programs to test the JIA goals and objectives (Table 7-2) The selection encompassed each of the architecture types previously described.  During the October 1998 CALS ’98 Expo in Long Beach, CA, the conceptual JIA was successfully demonstrated. The pilot programs were hyperlinked to demonstrate that regardless of architecture type, authoring system or service, the IETMs could be viewed using a Web browser. 

**Table 7-2.  JIA Pilot Programs**

**Service**

**Program**

**Technology**

**Demonstration**

**Architecture**

**Type**

****

****

****

****

**Navy**

LM-2500

SGML to HTML 

Type C1

LINK-16

SGML to HTML 

Type C1/C2

F-18

Quill to Web-based

Type S2

ATIS-AIR

PDF to Web-based

Type C2

NSSN Library

SGML to HTML/XML

Type C1

****

****

****

****

****

**USMC**

Diode Test Set

PDF to Web-based

Type C2

TAOM

MediaLynk to Web-based

Type S1

AAAV

TechSight to Web-based

Type S2

****

Sweep Function Generator

PDF to Web-based****

Type C2

****

****

****

****

****

****

**Air Force**

MPTO

PDF to Web-based

Type C2

F-22

Paper study 

N/A

****

****

****

****

****

**Army**

PPS-5

PDF to Web-based

Type C2

EPLRS

SGML to Web-based

Type S1

**APPENDIX ASGML, HTML, XML and IETM Software**

**A.1Introduction**

Selecting IETM software is dependent upon many factors, but mainly upon the class of IETM that is to be developed. This appendix discusses the role of SGML and DTDs (Document Type Definition) in the development process for IETMs. It also provides information on software available to accomplish an IETM development program.  Discussion of software products in this section in no way implies endorsement by DoD.

IETM software falls into four distinct categories:

· Development and editing software

· Parsers (an application that checks conformance to a DTD)

· Display or viewing software

· Data management software

**A.2SGML**

In 1986, the SGML became an ISO standard [ISO 8879, Information Processing - Text and Office Systems].  ISO 8879 defines a method (set of rules) and a “language” for document representation.  SGML provides a formal markup procedure used to “tag” or identify elements of document text.  This tagging is machine processable and independent of system and output environments.  SGML provides the grammar and syntax rules for the language used to describe both document content and structure regardless of the type of document or the nature of document text. 

**A.2.1Background**

SGML was adopted as the format for delivery of technical documentation as part of the CALS initiative in the mid-1980s. All DoD technical manuals are required to be delivered in SGML format according to a Service's DTD.  SGML was designed to provide a flexible, yet structured, open approach to documentation development and management. Any document, including technical documentation, typically contains three characteristics: content, presentation and structure. Most commercially available word processors, and to a lesser extent desktop publishing programs, are categorized as WYSIWYG (what-you-see-is-what-you-get) programs. Editors and authors using these programs are usually more concerned with the presentation of the content than with the structure. Many authors spend inordinate amounts of time formatting a document for an aesthetically pleasing display (usually paper). This presents a problem when data needs to be shared across the enterprise but is inconsistent because various authors applied their own interpretation of "what looks good." If authors could spend their valuable time creating content with a structurally sound guide (or template), and leave the presentation of the content up to a predefined style, all documents conforming to the template could share elements while maintaining a consistent look and feel. 

This is the underlying philosophy behind the CALS initiative; to have many different authors (contractors), creating reusable chunks of information (technical data), according to a standard set of structure rules (DTD), to share across the enterprise (DoD). Formatting of the resulting SGML instance is accomplished by application of a stylesheet(s) permitting output of the data to various display devices (paper, CD ROM, Web). In short, SGML separates a document's content and presentation from its structure. Publishing SGML for electronic display is typically more cost effective than publishing on paper. 

SGML documents can be visualized as a series of parent-child relationships residing in containers. In the military, technical manuals are structured as indicated in Figure A-1. The document is the “root element”, and also the “parent”, that contains the front matter, body and rear matter “child” elements. This analogy can be extended to the entire manual, resulting in the visual tree structure of the Body element shown in Figure A-2. The Chapter elements are the children of the Body element and also contain children of their own. The structure of Chapter X is representative of the structure found in a procedural (corrective maintenance) chapter of a military technical manual. Chapter Y reflects a general information (description of operation) chapter and Chapter Z is indicative of an IPB chapter. Figure A-2 is a simple example of the main structural elements of military technical manuals. Many manuals can contain sophisticated structures requiring extensive document analysis to completely describe the parent-child relationships.

The military is not the only organization to adopt SGML as a standard for the exchange of technical data. Many industries have recognized the benefits SGML provides over proprietary authoring programs, including:

**Industry**

**Common SGML Reference**

****

Automotive

J2008

Airlines

ATA

Semiconductor

Pinnacle (PCIS)

Financial

EDGAR

Literature

Text Encoding Initiative (TEI)

Publishing

AAP

**A.2.2DTDs**

The content of a technical manual may be considered unformatted source data.  In order for the source data to be processable, it must be marked-up (tagged) in some way with respect to its structure or content.  The tagging rules that apply to standardized technical manuals are defined by the DTDs. A DTD is a file that identifies the elements within an SGML tagged manual, as well as the hierarchical relationship between the elements. Other than MIL-PRF-28001, DTDs exist for a number of military specifications as represented by the below chart.

**DTD**

**Used by**

****

MIL-STD-38784

All services

Quest

Navy

NAVSEAC2

Navy

MIL-STD-2361

Army

Workpackage

Navy (aircraft)

SSM

Navy (submarine)

MIL-PRF-87269

All services

An example of the partial DTD for a technical manual containing a Body element described in Figure A-2 is as follows:

<!DOCTYPE DOC [

<!ELEMENT doc - - (front, body, rear)>

<!ATTLIST doc secure (uc|c|ts)#REQUIRED>

<!ELEMENT body - - (chapter+)>

<!ELEMENT chapter - - (title, section)>

<!ELEMENT section - - (title, para0+)>

<!ELEMENT para0 - - (title, subpara1, figure, table)

<!ELEMENT subpara1 - - (para+)

<!ELEMENT para - - (#PCDATA)

]>

The actual DTD is contained within the open “[“ and close “]” square brackets. The first line <!DOCTYPE DOC, begins the document type definition, and indicates the DTD will be defined for documents of type “DOC.” The <!ELEMENTS statements identify what structural objects are permitted within the document and also their hierarchical relationship. The **<!ELEMENT doc - - (front, body, rear)>**statement****identifies**doc**as the root element that must contain a front element, a body element, and a rear element. The body element must contain one or more chapters, which must contain at least one section. Notice the addition of the <!ATTLIST statement. An attribute is a method of modifying an ELEMENT’s SGML tag. In this example, the **doc** ELEMENT has an attribute “secure” indicating its security classification status. Our document can either be unclassified (uc), classified (c), or top secret (ts). While some attributes are optional, the secure attribute on the doc tag is required (#REQUIRED). Also note the term #PCDATA which stands for parseable character data, meaning source data (text and characters).

**A.2.3FOSIs and Stylesheets**

Publishing tagged instances on paper relies upon Formatting Output Specification Instances (FOSIs) to describe the format or how the printed document will be presented on paper.  FOSIs control such things as location of footer information, page numbers, headings, font size, etc., on a printed page.

A FOSI is merely an instance of a DTD.  It provides specific values, chosen from the options defined in the MIL SPEC, for formatting the SGML document. Multiple FOSIs for the same DTD can be developed to produce different presentation formats for the same instance.  By selecting different values for the style characteristics, a FOSI may be developed that creates a page-oriented single column output format or a two-column output format.

Electronic publishing of tagged instances for IETM displays generally rely on application specific stylesheets. Within a stylesheet authoring environment, an IETM developer specifies the formatting characteristics, such as font size, color, space before, indentation, etc., of elements in the IETM. Fortunately, SGML elements can, within stylesheets, possess an inheritance property. This means that if the IETM author desires the para0 element to be 12 point, left justified and arial font, all children of para0 (subpara1, steps, etc.) will inherit the parent’s formatting characteristics. Stylesheet formatting typically starts at the root element and continues through to the lowest level of the SGML tree structure. In this manner, the look and feel of the IETM displayed on a computer monitor is developed. Like FOSIs, multiple stylesheets may be built for a single SGML tagged instance. 

**A.3SGML and HTML**

SGML is the parent language of the Hypertext Markup Language , the popular format for developing Web pages on the WWW. Sometimes referred to as "SGML-lite" or "dumbed down SGML", HTML was designed to be easy to understand and therefore to be used by the general public. The HTML DTD contains a limited number of available elements to produce a Web page. The same general concept of structured documentation applies to HTML. However, HTML browsers are more forgiving in the presentation of an HTML tagged document. An example of an HTML document is as follows:

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>

<head>

   <meta name="GENERATOR" content="Mozilla/4.5 [en] (Win95; I) “>

</head>

<body>

<h1>HANDY’s has Bikes for Sale!</h1>

<h2>Manufacturer: Thrasher</h2>

<h3>Model - The Zoomer 2 Wheeler</h3>

<p>We have a <i>Monster Bike</i> sale going on!</p>

<table BORDER >

<tr>

<td>Men</td><td>Women</td><td>Children</td>

</tr>

<tr>

<td>$109.99</td><td>$105.99</td><td>$99.99</td>

</tr>

<tr>

<td>$99.99</td><td>$89.99</td>

</tr>

</table>

</body>

</html>

In this simple example, the HTML document structure consists of  <head> and <body> elements. The <H1> is the first level heading; similar to a chapter title or <para0> element in military SGML documents. The three column table structure consists of rows <tr> and table data <td>. Formatting codes <i> can be added to emphasize words or characters. The display of the individual HTML elements are interpreted by the browser’s built-in stylesheet. Rendering of the above example in Internet Explorer yields Figure A-3.

**A.4SGML and XML**

The limitations of HTML prompted the World Wide Web Consortium (W3C [a organization combining a mixture of industry and Government experts]) to proposed a more definitive language for describing Web documents. The eXentsible Markup Language (XML version 1.0) was accepted in 1998 as a standard by the W3C. XML is only in its infancy, but the advantages of using XML (versus HTML) to describe the contents of a document are readily apparent. XML is an example of content tagging versus many DTDs that implement the structure tagging approach. Compare the XML example shown below with the HTML example previously discussed.

<?XML version 1.0">

<!DOCTYPE bikes SYSTEM bikes.dtd>

<bikes>

<company>HANDY’s has Bikes for Sale!</company>

<manufacturer>Thrasher</manufacturer>

<model>The Zoomer 2 Wheeler</model>

<announce>We have a <i>Monster Bike</i> sale going on!</announce>

<bikeinfo>

<biketype>Men</biketype>

<biketype>Women</biketype>

<biketype>Children</biketype>

</bikeinfo>

<bikeprice>

<regprice>$109.99</regprice>

<regprice>$105.99</regprice>

<regprice>$99.99</regprice>

</bikeprice>

<sale>

<saleprice>$99.99</saleprice>

<saleprice>$89.99</saleprice>

<saleprice>$75.99</saleprice>

</sale>

</bikes>

Notice that the tags describe the information contained between the tags. The XML document inside an XML capable Web browser will be displayed identically to the HTML document. 

**A.5SGML and PDF**

Before the explosion in popularity of the WWW, the Adobe Corporation recognized the need for electronic documents that retained the look and feel of the printed version. Also highly desirable was a platform independent file with powerful hyperlinking capabilities. Utilizing their Postscript printing language, Adobe developed a Portable Document Format (PDF) that permits the user to quickly navigate an electronic document via a key word search, hyperlinked table of contents, or by clicking on "thumbnail" images of electronic pages (see Figure A-4). This capability is available to the user from the same source file regardless of the viewing platform (PC, Mac or Unix). The user only needs to have installed the freely distributable Adobe Acrobat Reader. When the Internet became a popular distribution medium for electronic documents, Adobe reconditioned Acrobat to work with either Microsoft's Internet Explorer or Netscape's Navigator. This permitted thousands of pages of documents already in PDF format to be displayed from within a Web browser without further modification (i.e. converted to HTML). Since most word processing files or desktop publishing files could already output a Postscript file, it gave large numbers of potential Web publishers a relatively inexpensive method of converting their electronic files for Web display.

Probably the greatest advantage PDF has over SGML is its simplicity. Typically, novice electronic publishers already have all the required tools installed on their computer and can quickly begin developing PDF. SGML, on the other hand, requires specialized software tools and has a steep learning curve associated with DTDs, the concept of structured documents, and FOSIs. Another benefit of PDF files, is the fact that licensing fees are not required for viewing IETMs delivered in PDF format. All current SGML browsing software applications have a licensing fee associated with the distribution of SGML based IETMs.

PDF files, however, do have some drawbacks. Technically, PDF files are a proprietary format,  Adobe's Acrobat Reader is the only application that can view a PDF file while maintaining internal functionality. The PDF file itself cannot be edited, only the source file can be modified and remade into a PDF. Adobe is addressing these issues by providing updates to the functionality of the Acrobat Reader. Acrobat can be downloaded at www.adobe.com.

**Figure A-4.  Electronic Page in Adobe Acrobat Reader**

**A.6Developing and Editing Software - Class II and III**

**A.6.1ASCII Editors**

Since SGML is an ASCII file, any text editor can develop or modify an SGML instance. This approach is not recommended for large SGML files or for SGML novices. Those authors unfamiliar with structured documents or the target DTD can introduce too many structural mistakes. The most common process when using a text editor is to edit a previously developed instance, run the SGML through a parser and then correct the errors until the instance parses. Common text editors include:

· Notepad

· Wordpad

· Textpad

· Program File Editor (PFE)

· Emacs

· Word

· WordPerfect

**A.6.2ADEPT*Editor**

A product of Arbortext in Ann Arbor, Michigan, ADEPT was the first widely distributed SGML development/editor software program on the market. It combined the ease of a word processing/desktop publishing environment with a SGML tagging environment. ADEPT is an SGML development tool and not an IETM development program. It produces SGML that can be used as the source data for IETM viewers. An ADEPT session (Figure A-5) typically consists of:

· Opening a new Arbortext document.

· Selecting a precompiled DTD. The program reads the DTD and stores it in memory.

· Begin developing your document.

Whereas an inappropriate element could be introduced at any point within the SGML by a text editor, the ADEPT development environment permits the author to only create elements that conform to the structure defined by the DTD. A “quick tag” feature displays a list of structural elements that can be created at a particular location within the document.

A screen FOSI and a print FOSI (if necessary), conforming to the target DTD, need to be developed prior to authoring. Fortunately, many of the Services have already developed these FOSIs for popular DTDs. The graphical user interface of Arbortext can be customized using a program known as the ADEPT Command Language (ACL) which is available separately.  As long as a document conforms to the DTD loaded into memory, ADEPT will accept pre-tagged SGML files. ADEPT will parse the file upon loading and ADEPT will reject the file if errors are encountered. All known SGML errors should be corrected before importing an SGML-tagged file into ADEPT.

**A.6.3FrameMaker+SGML (FM+SGML)**

FM+SGML is an Adobe System product and is based upon their popular FrameMaker desktop publishing software. FM+SGML is an SGML development tool and not an IETM development program. It produces SGML that can be used as the source data for IETM viewers. The FM+SGML authoring environment (Figure A-6) provides both a WYSIWYG and an SGML view of the data during author and edit. The approach to development of SGML files is very similar to that of ADEPT. Instead of FOSIs, Adobe substitutes Electronic Display Definitions, read/write rules and SGML application support files. Through the development of filters and scripts, FM+SGML files can be exported to HTML and/or PDF for Web display. FM+SGML treats non-conforming SGML files as unstructured documents. SGML construction errors can be corrected by traversing the document and correcting as required.

**A.6.4IADS**

The Interactive Authoring and Display System (IADS) was developed at the Army’s Redstone Arsenal in response to many Army Program Manager’s requests for an IETM viewing software free of licensing requirements. IADS also releases DoD from committing to any one proprietary method of displaying IETMs. It uses SGML as the source data but requires the data to be chunked, or separated into frames of logical topics. A first level paragraph can be a frame, table, or figure. The frames are given specific ID attributes and then hyperlinked based on the ID value. The resulting file is delivered with the IADS reader to view (Figure A-7) on a standard PC.

**A.7Developing and Editing Software - Class IV**

**A.7.1TechSight**

The TechSight Developer’s Kit was developed for the Armed Forces as a MIL-PRF-87268/87269 compliant authoring program that provides the necessary tools to create Class IV IETMs, either as a single IETM or as part of a collection of documents which supports cross referencing and data object sharing. The TechSight database structure separates information by data type for ease of maintenance and minimum redundancy of common objects. Users have complete flexibility in authoring tools and can readily transform TechSight data to other DTDs or formats using C/NDI tools, providing data portability and durability. TechSight integrates with FM+SGML to provide SGML editing features. The TechSight Viewer provides the capability to view hierarchical illustrated repair parts, navigate procedures with complex branching, and link to integrated training modules.  It also permits a feature which automatically requires the user to log-in upon accessing the ITEM.  In addition to the normal views of text, tables, and graphics, TechSight provides a procedure execution mode that can be authored to show procedures (Figure A-8) either as step-by-step, or with multiple steps shown with the active step highlighted. The table viewer supports complex tables as allowed by MIL-PRF-87269, and permits the replication of complex tables that are frequently used in legacy documentation. Within a single IETM, a user can view data in multiple windows simultaneously (e.g. descriptive text in one window, an associated graphic in another, a procedure in a third, and repair part sparing and ordering information in another). The viewer also provides full navigation and search capabilities, and the ability to include notes, bookmarks and directed change notations.  TechSight was developed by General Dynamics.

**A.7.2Quill**

The Quill21 system (Figure A-9) consists of an authoring system, a database and presentation tool. The authoring system is a C++ X-Windows application that populates an object-oriented database (based on the Versant engine). MIL-PRF-87269 compliant SGML is generated for the object-oriented database and parsed into a relational database for presentation. The presentation tool is a cross platform application that displays dynamically constructed panes of data. All user activity through the IETM is captured in an audit log that can be downloaded into the customer’s maintenance network. The presentation system runs on the Windows 95/NT, SCO Unix, Solaris and HP operating systems using Oracle, Informix or Sybase relational database management systems. Quill21 was developed by Boeing.

**A.7.3Advanced Integrated Maintenance Support System (AIMSS)**

AIMSS is a Windows-based product which combines an IETM with state-of-the-art object database technology. AIMSS uses a common graphical user interface to display maintenance information in text, graphics, and table windows that can be easily manipulated by the technician for preferred viewing.  Hypertext and graphic “hot spots” are embedded in descriptions and procedures to provide rapid access to related information contained in the database.  For example, while viewing a fault isolation procedure, the technician is provided direct access to related information such as schematics and parts lists by way of links that are embedded in the text of the procedure and its associated graphics. 

One of the most powerful features of the system is its fault isolation capability.  The troubleshooting approach used is much like the traditional fault logic diagrams provided in technical documentation. However, AIMSS eliminates the navigation problems sometimes experienced with lengthy flow diagrams.

Troubleshooting information is presented in a linear step-by-step fashion to the technician.  Each step contains detailed instructions and a question requiring a simple “yes/no” answer or a type-in response.  The system then either branches directly to the next step on “yes/no” responses or performs an arithmetic operation on the technician’s type-in response to determine the next step to be displayed.  Using a combination of “yes/no” answers, type-in responses, and arithmetic operations, AIMSS can simplify complicated procedures (Figure A-10).

**A.7.4Joint Integrated Maintenance Information System (JIMIS)**

JIMIS is also an object oriented database capable of producing MIL-PRF-87269 compliant IETMs. Currently deployed in the Joint Surveillance Target Attack Radar System (JSTARS) community, JIMIS (Figure A-11) is also being used for IETM development in the V-22 Osprey Helicopter program.  Technical data for the entire aircraft is stored on a ruggedized laptop computer. Fault codes supplied to the maintenance chief by the flight crew are imported to the IETM as an identifier to rapidly access the appropriate location of the IETM and resolve the problem quickly and efficiently. A program running in the background records each keystroke and time to perform procedural steps. The output data from the recording program can be used to update Mean Time To Repair (MTTR)  parameters and provide updated statistical information on Mean Time Between Failure (MTBF) for parts/equipment.  The JSTARS Web page is accessible at http://www.jimis.jstars.af.mil.  JIMIS was developed by Northrup Grummen.

**A.8Parsers**

A parser is a software application that is capable of analyzing the structure of a document. Two input files are required for a parser to validate a document: the SGML instance itself and the DTD. A parser will check the tree structure and permitted elements from a DTD against the tree structure and elements of an SGML instance. Some parsers will check the entire instance and produce an output error file. The error file will contain information about the line number on which the SGML error occurred and why it was an error. Other parsers will exit upon encountering the first SGML error, requiring the user to repeatedly parse and correct.

Some parsers are pre-packaged with an application (such as ADEPT), while others are free. The two most popular parsers are SP and Omnimark, others are also presented below.

**A.8.1SP**

This is a free parser and toolkit. SP contains a parser; nsgmls and two SGML normalizers; SP Added Markup (SPAM) and sgmlnorm. The normalizer is an application that takes SGML input and substitutes all the proper entities enabling a formatter to produce a complete SGML document. SP is written in C++ and is available for many types of Unix, MS-DOS, and Windows 95/NT platforms. It can be downloaded at www.jclark.com/sp. 

**A.8.2Omnimark**

Although mainly used as a parser, Omnimark can also be used for pattern recognition, hypertext processing and converting other file formats (RTF, ASCII) to SGML. Omnimark understands structured documents and employs a sophisticated pattern matching language which permits easy identification of character and text strings to marked-up data. Conversion utilities, rules and script development within Omnimark allow fast translation between DTDs and instances (i.e. SGML to HTML). Although the full version is costly, Omnimark offers a Limited Edition (LE) version for developers to utilize for familiarization in developing Omnimark scripts. OMLE can be downloaded at www.omnimark.com.

**A.9IETM Viewing Software**

*Note: All Class IV IETM development software is delivered with its own viewing software. Class IV viewers can only read their databases and cannot be used to view a different database.*

Displaying SGML files with a simple text editor is not recommended for the SGML novice. Users would quickly become annoyed at viewing tags and marked up documents. A reader or browser, is needed to interpret and display the SGML instance as well as provide the functionality offered by the SGML. Functionality can include hyperlinked references (i.e., “*see Table* ...”), full word/phrase search and quick navigation of document elements (figures, paragraphs, etc.).

**A.9.1Advanced Technical Information System (ATIS)**

ATIS is the Navy’s document and library management software installed on many surface combatants and shore-based facilities. It includes a graphic viewer to display raster-scanned technical manuals compliant with NIRS/NIFF (Class I IETM). Documents are intelligently indexed to include hyperlinked table of contents, list of figures, andlist of tables. The presentation is page oriented and can be printed directly. The library management software is also capable of indexing Class II/III IETMs and digitized engineering drawings.

**A.9.2Acrobat**

Acrobat is the freely distributed PDF viewing software (Figure A-12) from Adobe Systems. PDF files retain their page orientation and can also be hyperlinked. When a PDF has been internally hyperlinked via an indexing process, the resulting file is known as ‘Indexed” PDF (IPDF). Acrobat cannot be used to view SGML documents. Acrobat is used by all the services for displaying various types of technical data.

**A.9.3InfoAccess (IA)**

Also known as Owl or Guide, IA was one of the first commercially developed hypertext programs to be used by DoD. It can accept structured languages (HTML, SGML) and convert them to IA’s Hypertext Markup Language (HML, *not HTML*). Formatting styles are applied to the HML document for presentation and display (Figure A-13) of IETMs. IA is used extensively by the submarine community for displaying IETMs. The user interface can be customized using built-in tools within the Guide Professional Publisher suite.

**A.9.4DynaText**

This product is one of the most popular SGML browser displaying IETMs within DoD. DynaText compiles an SGML instance into an electronic book. Stylesheets add functionality to the IETM resulting in a fully hyperlinked document with a consistent look and feel (Figure A-14). Users can create personalized electronic sticky notes, hyperlinks and bookmarks. DynaText books can be printed in whole, or in chunks based on containerized SGML elements. With the purchase of the optional System’s Development Kit, the DynaText interface can be tailored according to user needs.

**Figure A-14.  DynaText Browser**

**A.10SGML Database Managers**

One of the early benefits noted with both SGML and IETMs, was the ability to share and reuse information objects both internal to a document and external to the IETM. For example, a specific warning is repeated ten times within a technical manual and is physically recreated in the authoring software at each occurrence. If the content of the warning was modified, it was necessary to change the warning ten times. Relational database managers allow an author to create an object once (a warning object) and establish the object’s relation to other technical data in the manual. When the object is modified, it is changed once and accessible throughout the document. Although the warning example is simplistic, the implications for storing parts data once and having changes reflected throughout an entire set of manuals can be highly desirable. 

Class IV programs use a relational database as the engine to power the IETM and have information reuse capability. Until recently, this type of capability could not be extended to the Class II and Class III level IETMs. It is important to note the following software products do not produce an MIL-PRF-87269 compliant database, nor is the database delivered with the IETM. The Class II and Class III viewing software programs previously described are still required to be packaged with the SGML source data contained in the database. These products are SGML managers and provide the Class II/III IETM Life-cycle Manager with a tool to reap the benefits of information object reuse.  They can also manage the data with SGML editors, export SGML for electronic distribution, or forward data to composition engines for hard-copy printing.

The Naval Surface Warfare Center, Philadelphia and Port Hueneme Divisions use the Texcel Information Manager (IM). IM is a comprehensive content and process management system for creating and managing SGML and non-SGML documents. IETM authors working simultaneously can use IM's collaborative tools to find, edit, review, reuse, and assemble information managed in a secure database. The information manager establishes a collaborative environment in which the participants in the IETM life-cycle, authors, editors, reviewers, and subject matter experts can interact with each other as well as with the document database. The integrated workflow system (Figure A-15) pushes a task (and its associated data) to the correct user and, upon completion, instantly notifies those assigned to the next step in the process. The Electronic Review tool captures the electronic comments of local and remote reviewers, which are immediately available to IETM authors and editors. SGML objects and fragments can be checked out of the repository for off-line editing. When the object is checked-in, it is parsed to ensure conformance to the DTD.

**APPENDIX BCALS PHILOSOPHY**

**B.1Introduction**

Today's environment of computer technology has created possibilities for information management that were impossible a decade ago.  The computer has become an indispensable tool in the creation, handling, and management of technical information.  In order to capitalize on this fact, DoD and industry have been cooperating in a joint initiative to improve weapon system quality and reduce costs through effective application of computer technology.

**B.2Continuous Acquisition and Life-cycle Support (CALS)**

This Continuous Acquisition and Life-cycle Support initiative, formerly Computer Aided Logistics Support, was designed to reduce the time to generate, access, manage, maintain, distribute, and use acquisition and logistics support data.

CALS is a DoD and industry strategy intended to enable more effective generation, exchange, management, and use of digital data supporting defense systems. The primary goal of the CALS strategy is to migrate from manual, paper-intensive defense system operations to integrated, highly automated acquisition and support processes.  Because of this vision, CALS is now recognized as a facilitator for process reengineering globally and as a strategic initiative to enable worldwide integration. The CALS initiative includes infrastructure modernization and standardization for the exchange of digital data. The integration of weapons system technical information is the essence of the CALS concept for an Integrated Weapons System Database (IWSDB).

CALS sets interchange standards for and takes advantage of the digital data revolution.  Other initiatives, such as the Integrated Data Environment (IDE), have been introduced to further capitalize on the ability to swap/transfer data electronically within a weapons development program.  While the IETM is a CALS/IDE product, JCALS provides the architecture and a series of management tools to facilitate the sustainment of IETM deliverables and other digital data products.  As is noted in Figure B-1, CALS serves as the overarching environment within which the IETM is developed.

**B.3SECDEF Policy**

A 29 June 1994 policy memo from the Secretary of Defense initiated action to migrate away from the use of Government specifications and standards in favor of performance standards and accepted commercial processes and practices, where applicable.  This would allow DoD contractors to produce less costly deliverables that provide the user with the same functional support. 

In executing the policy, the DoD has reviewed commercial and international TM format and content specifications and standards with the goal of using them in lieu of military specifications and standards; none were found to be complete enough for use.  Commercial and international organizations responsible for maintenance of these documents were asked to adopt certain military specification or standards; none were willing. The Core CALS Standards, MIL-X-2800X series and MIL-X-87268/87269 (addressed later in this chapter) have been designated as “performance” standards (MIL-PRF-2800X) and can now be used in any contractual process.  Those specifications and standards not specifically listed on the DoD Index of Specifications and Standards (DoDISS) as “performance specifications and standards” will require a waiver for use in the contractual process. 

**B.4DOD Instructions**

DoD 5000.2-R directs the application of CALS to new defense system acquisitions and provides a basis for applying CALS to existing defense systems.  Implementing CALS policy requires a new acquisition strategy to plan and contract for defense systems.  Requirements for CALS should be incorporated in defense system program plans, the appropriate sections of RFP or the Acquisition Requirements Package, and the subsequent contract.  CALS implementation requires a significant upgrade in the DoD infrastructure.  DoD components are building this infrastructure to acquire, exchange, and use digital data deliverables and will continue to expand the ability to receive, store, manage and distribute digitized technical data. 

**B.4.1Planning**

Defense Federal Acquisition Regulation Supplement (DFARS) Part 207.105 requires acquisition managers to describe the extent of CALS implementation in their acquisition plans.  These plans establish the framework for effective implementation of the CALS strategy by identifying system and infrastructure requirements.

**B.4.2Solicitations**

DoD 5000.2-R, released 15 March 1996, established a core of fundamental policies and procedures to implement various engineering, manufacturing, and support disciplines. Paragraph 3.3.4.5, “Continuous Acquisition and Life-cycle Support”, states: 

*Beginning in FY '97, all new contracts shall require on-line access to, or delivery of, their programmatic and technical data in digital form, unless analysis shows that life-cycle time or life-cycle costs would be increased by doing so.  Preference shall be given to on-line access to contractor developed data through contractor information services or existing information technology infrastructure rather than data delivery.  The PM shall be responsible for establishing a data management system and appropriate IDE that meets the data requirements of the program throughout its total life-cycle.  MDAs shall assess the IDE developed to enhance the program and mitigate long-term costs at each milestone and program review.  In the implementation of an IDE, independent standards setting bodies' data formats shall take precedence over all other formats.  The issue of data formats and transaction sets shall be independent of the method of access or delivery.  Acquisition strategies and plans shall describe the extent of implementation of these requirements in accordance with DFARS 207.105.*

*Solicitations shall require specific proposals for an IDE to support systems engineering and logistics activities.  The PM shall ensure compatibility of data deliverables with existing internal information systems, and augment such systems as required to provide timely data access and distribution consistent with DFARS 227 and 252.*

*This Regulation hereby authorizes the publication of DOD 5010.12-M, DoD Technical Data Management Program, and DOD 5010.12-L, Acquisition Management Systems Data Requirements Control List (AMSDL), which list the data item descriptions and source documents approved for use in acquisition.  Programs electing not to use the data management processes described in DOD 5010.12-M must find other ways to comply with Public Law 104-13, The Paperwork Reduction Act of 1995.*

**B.5Infrastructure**

As part of the CALS implementation, the program office must ensure that recipients of digital data have the capability to receive, store, and maintain the data.  The availability of this required infrastructure is a key consideration in implementing the CALS strategy for any given program acquisition. Deficiencies in the Government infrastructure may require investments by the acquisition management team to effectively implement the CALS strategy.  Additional lead time must be considered in the acquisition planning process.

**B.5.1Existing Defense Systems**

Existing defense systems should exploit opportunities to obtain cost savings by retrofitting digital information technology into their programs.  Program phase, type, size, and duration are influencing factors in implementing CALS.  Infrastructure modernization and process improvement programs must look to opportunities for retrofitting digital information technology into existing programs.  In order to take advantage of this technology in existing programs, legacy data conversion, re-acquisition of technical data in digital formats, and re-authoring data into processable data files may be required.

**B.6JCALS**

The DoD CALS infrastructure program, JCALS, provides an Information Management System that is evolving to support uniform logistic, acquisition, engineering, manufacturing, configuration management, materiel management, and other life-cycle functional processes.  The JCALS open-system architecture will implement a communications and computing infrastructure based on CIM (Corporate Information Management) Technical Reference Model standards.  The system will provide uniform applications and services to implement joint functional processes through the use of the JCALS workbench.  The workbench will provide a uniform human-user interface and will give transparent access to all data, applications, and software tools available throughout the architecture.  The system, through the workbench, will provide a flexible workflow management capability, which will be tailorable to suit the organizational structure of the Service, command, or workplace while ensuring that future changes can be accommodated easily. The Global Data Management System (GDMS) and the Workflow Manager form the core of the JCALS program and are key to the JCALS and Defense Infrastructure Initiative (DII) Architectures. In addition to these core JCALS applications, activities can also implement JCALS Technical Manual development and management application. The JCALS open-system architecture will be scalable to allow growth in scope, size, functionality, and processing speed. This will be accomplished via adherence to open systems standards, and through modular hardware and data-driven modular software design. 

Although the current JCALS design does not include an application for development of the databases that are the core of the higher IETM classes, its SGML editor does allow creation of Class II and III IETMs. With its rapidly growing deployment throughout the Services, JCALS can play an important part in many programs’ technical manual development and management strategies.  This is especially true in the Air Force, whose IETM strategy includes extensive use of JCALS as its primary TM creation and revision system.  JCALS technical manual capabilities are described in the following paragraphs.

**B.6.1TM System Functions**

The JCALS TM processes described in this subsection are a collection of services that ensure control and standardization of the major TM system functions: manage, acquire, improve, publish, stock, and distribute. These functions include managing policy and guidance, providing program support, controlling TM numbering and indexing, and managing TM publication, stocking, and distribution.

**B.6.1.1Manage**

The Manage TM System requirements ensure control and standardization of the major TM system functions: management, acquisition, maintenance/improvement, publication, stocking, and distribution.  Within the TM management process, managers at all levels are involved with the planning, scheduling, development, controlling, and budgeting of TMs.

Requirements to satisfy the function of managing TMs will be fulfilled in large part by the JCALS Infrastructure Work Management and Information Management functions. There are four sub-functions within Manage TM Systems:

· Manage Policy and Guidance

· Provide Program Support

· Control Publication Numbering and Indexes

· Manage TM Repository

**B.6.1.2Acquire**

In the Acquire TMs functions, the user identifies TM requirements for specific equipment acquisition, develops TM planning documents, drafts TM Contract Data Requirements List (CDRL) requirements, and incorporates planning documents and data into TM acquisition/management plans. The Acquire TMs function consists of developing planning documents for the TM acquisition process, controlling the TM acquisition process, and developing TM processes.

**B.6.1.3Improve**

TM improvement refers to the correction or enhancement of a TM due to errors, problems, or system/equipment modifications that occur during the life-cycle of a weapons system. These activities could include the receipt and evaluation of a recommended change due to a perceived deficiency, as well as the analysis, content, coordination, approval, processing, and control of TM improvement.

**B.6.1.4Publish**

In the Publish TMs function, the change pages and/or TM pages developed in previous publications are used to develop draft and final reproducible masters that are then used to publish the TMs or change pages for distribution and/or storage. Publishing a TM includes the activities required to ensure the quality of the published document. The Publish TMs function is divided into four processes: 

· The development of a reproducible master

· The preparation of a reproduction package

· The reproduction of a TM

· The control of the reproduction material. The current contractor is responsible for the first process.

**B.6.1.5Stock**

Stock TM refers to the online management of all activities associated with the receipt, storage, and maintenance of the TMs and records associated with TM inventory. In the Stock TMs function, information concerning publications received from a reproduction facility is inputted to JCALS at the stock point. Updates concerning stock status are provided from the stock point JCALS site as an element of the program’s database.  Standardized Stock Status reports are generated according to the Service's requirements.

**B.6.1.6Distribute**

Distribute refers to the activities associated with the tracking of requests for TMs; initial identification of requirements, distribution, or allocation of the TMs; changes and revisions; re-supply; and the routing of all basic manuals and changes to a storage location. In the Distribute TMs function, TM accounts are created and TM distribution requirements are established.

**B.7TM Process Functions**

The JCALS TM System performs the following TM process functions:

· Manage Policy and Guidance

· Manage TM Numbering

· Manage TM Index

· Generate TM Index Reports

· Manage Quality Assurance

· Improve TM

· Manage Program Support

· Manage Repository

· Perform Acquisition

· Develop TM Reproducible Master

· Reproduce TM

· Manage Inventory

· Manage TM Accounts

· Manage Initial Distribution for a TM

· Manage Initial Distribution for a TM Account

· Manage One-Time Requisition

· Clear TM Exception Transactions

· Perform Post Publication Review

· Manage TM Pricing

**B.8Common IETM Standards**

CALS standards and specifications are geared toward technical data interchange requirements.  The documents listed below are CALS standards that apply to IETM acquisition and development and serve as controls to ensure that information systems are independent of hardware platform and proprietary data format. 

**B.8.1Document Interchange Standards**

**B.8.1.1MIL-STD-1840, Automated Interchange of Technical Information**

MIL-STD-1840 is the interface standard which defines the means for exchanging large quantities of engineering and technical support data among heterogeneous computer systems.  MIL-STD-1840 is often called the "parent" or "umbrella" standard for CALS, because it identifies other standards, specifications, and practices to be used in a CALS solution. It applies selected Federal, DoD, International, National, and Internet standards/specifications/practices for the exchange of digital information between organizations or systems and for the conduct of business by electronic means.

The initial areas addressed by MIL-STD-1840 involved automating the creation, storage, retrieval, and delivery of technical manuals and engineering drawings. The standard defines a logical file identification and bundling convention for device and medium-independent transfer of technical information. MIL-STD-1840 also addresses electronic product data, packaging of data for electronic commerce, and electronic product data technology. Revision C of the standard adds several new data types, provides for new transfer media in addition to 9-track tape, and supports increased Information Security (INFOSEC) capabilities including digital signature and encryption.

This standard applies to technical information which is part of the traditional technical data package used for system or item acquisition; technical information used to design, manufacture, field, and dispose of a system or item; and the technical documentation used for system or item support.  MIL-STD-1840 also can be employed for information exchange applications; its use is not limited to technical data exchange in a defense acquisition environment.

**B.8.1.2MIL-PRF-28001, Markup Requirements and Generic Style Specification for Electronic Printed Output and Exchange of Text**

MIL-PRF-28001 is the performance specification which defines DoD requirements for the application of the Standard Generalized Markup Language [defined by ISO 8879, Information Processing - Text and Office Systems - Standard Generalized Markup Language (SGML)]. This specification provides a mechanism for the digital interchange of technical publications and other text data. MIL-PRF-28001 is designed to facilitate the automated storage, retrieval, interchange, and processing of technical documents from heterogeneous computer systems.

SGML provides the ability to markup (tag) textual data in a manner to define data content and document structure. SGML is the basis for HyTime and for HTML, which are used in electronic presentation (notably, the WWW). SGML evolved from a mid-1960s effort for an electronic ability to format printed text. SGML is described in more detail in Chapter 3.

MIL-PRF-28001 establishes a DoD application protocol of SGML that defines the following requirements for page-oriented technical documents in digital form:

· Procedures and symbology for markup of unformatted text in accordance with this specific application of the SGML.

· SGML compatible codes that will support encoding of a technical publication to specific format requirements applicable to technical manuals.

· Output processing requirements that will format a conforming SGML source file to the style and format requirements of the appropriate FOSI based on the Output Specification (OS). Revision C of MIL-PRF-28001 introduces a Formatting Presentation Specification Instance (FPSI) as an OS for the electronic display of SGML documents.

Future versions of MIL-PRF-28001 will emphasize the document content rather than structure to provide more content tagging, and database interfaces, as well as capabilities for hypertext constructs and applications.

**B.8.1.3MIL-PRF-87268, General Content, Style, Format, and User Interaction Requirements for Interactive Electronic Technical Manuals**

This was the first in a series of documents released by NSWC, Carderock in an attempt to standardize requirements for military IETMs. The specification contains common requirements for the general content, style, format, and user interaction features (GCSFUI – pronounced *gucks phooey*), which are required for IETMs. This specification established the “look and feel” and navigational aspects of the IETM viewing software. Although intentionally broadly written to permit increased browser functionality, many software vendors have not followed MIL-PRF-87268, developing their own interpretation of the specification instead. The end result has been a variety of IETM viewing software that does not provide a common look and feel for each equipment/system. 

**B.8.1.4MIL-PRF-87269, Revisable Database for Support of Interactive Electronic Technical Manuals**

This specification prescribes the requirements for an Interactive Electronic Technical Manual Database (IETMDB) to be constructed by a weapon-system contractor for the purpose of an IETM. The requirements cover the specification for the IETMDB and are intended to apply to one or both of two modes as specified in a contract: 

· The interchange format for the database to be delivered to the Government: or 

· The structure and the naming of the elements of the database created and maintained by the contractor for purposes of creating IETMs which are in turn delivered to the Government. 

Mainly applying to Class IV and above IETMs, this specification suffered the same fate as its sister GCSFUI specification. The intention of MIL-PRF-87269 was to specify how a revisable database of technical data elements could be constructed to permit interchange of data with other MIL-PRF-87269 database driven IETMs. However, software vendors and original equipment manufacturers applied their own interpretation of MIL-PRF-87269 to fit their own program needs. While Class IV type IETMs have provided many of the benefits first envisioned by IETM pioneers, interchange of MIL-PRF-87269 databases has not been fully realized.

The MIL-PRF-87269 specification calls out two layers to define the IETMDB; the generic layer and the content layer.

**B.8.1.4.1IETMDB Generic Layer**

The IETMDB Generic Layer provides mandatory requirements for the definition of IETMDB conforming DTDs. 

The Generic Layer is not a DTD.  It is a layer of constructs that can be used by any DTD and IETM application implemented in accordance with the requirements of MIL-PRF-87269. In the Generic Layer, the two requirements that are of importance to the acquisition manager are the use of “Architectural Forms” and the required SGML element types. The IETMDB architectural forms and the SGML element types required for the IETMDB are briefly discussed in the following sections.

**B.8.1.4.1.1Architectural Forms**

Architectural forms are a way of logically describing building blocks for an application without constraining the application‐specific information that a developer might need to add.  Only information that must be standardized for interoperability is defined rigorously.

Architectural forms enable the DTD designer to rapidly create a legal and safe "blueprint" or template for the hypermedia application. That design is the IETMDB DTD. Any instance of that design is an IETM. 

Just as standard window styles and sizes are used by an architect to create a design for a house, architectural forms, element types and attribute specification lists of the Generic Layer enable an IETMDB designer to create a content layer DTD that meets the needs of an specific IETM.

**B.8.1.4.1.2Nodes**

Nodes are units of information for the human reader or for the IETM presentation system. Some nodes determine order or presentation, enable the selection of alternative versions of the same information, or set criteria for deciding if and how many times a unit is to be presented. A unit of information may be used by the processing system or the user. Each node contains information about a subject.

**B.8.1.4.1.3Links**

The relationships among nodes are expressed both through the hierarchy of the nodes as declared in the DTD, and by references made in some nodes to other nodes. These references are called "links". The use of links permits alternative organizations of the information. The user can traverse the information in different orders depending on the type of link and sometimes conditions that must be met before that information is presented.  

**B.8.1.4.2IETMDB Organizational Level Content Layer**

MIL-PRF-87269 uses an Organization Level (O-Level) Technical Manual DTD to illustrate the default content layer, however it is not required to be used in its exact form in order to produce a conforming IETMDB.  This DTD would be based on the required elements of the generic layer of MIL-PRF-82769 and would provide for the content layer of the IETMDB. The O-Level DTD of MIL-PRF-87269 could be used as a guide, but specific tailoring will be required by each IETM acquisition.

**B.8.2Graphics Interchange Standards**

**B.8.2.1MIL-PRF-28002, Requirements for Raster Graphics Representation in Binary Format**

MIL-PRF-28002 is the performance specification which defines DoD requirements for the standardized encoding and compression of raster (bit-mapped) image data. This specification provides for the digital binary representation of 2D bitonal  images or pictures for display or interchange. MIL-PRF-28002 also defines data compression to reduce file size.

In Revision C of the MIL-PRF-28002 specification, the digital representation of raster data is classified as the following four types:

· Type 1, Untiled Raster Data

· Type 2, Tiled/Untiled Raster Data, Office Document Architecture (ODA) Raster Document Application Profile (DAP)

· Type 3, Tiled/Untiled Raster Data, Navy Image File Format (NIFF)

· Type 4, Tiled Raster Data, Joint Engineering Data Management Information and Control System (JEDMICS) C4

Essentially, MIL-PRF-28002 selected a popular graphics file format, the Tagged Information File Format (TIFF), and the Navy derivative (NIFF), as the required graphics format for scanned images. Other graphic formats, especially those containing color (GIF, JPG, BMP, etc.), have surpassed TIF in popularity. However, TIF remains the preferred graphics file format for black and white line art found in many technical publications.

**B.8.2.2MIL-PRF-28003, Digital Representation for Communication of Illustration Data: CGM Application Profile**

MIL-PRF-28003 is the performance specification which establishes the DoD requirements for 2D picture description or illustration data that is vector-based (or mixed vector and raster). MIL-PRF-28003 is the CALS application profile of the Computer Graphics Metafile (CGM), as specified by the Federal Information Processing Standard, FIPS PUB 128.

CGM provides a standardized electronic format for the capture, storage, retrieval, transmission, and interchange of 2D pictures, independent of system architecture, device capabilities, or transmission medium. CGM viewers and plug-ins are available for many SGML and Web browsers to easily view 2D vector data.

Revision B of MIL-PRF-28003 is being written to follow closely the Air Transport Association (ATA) application protocol for CGM, thereby providing a bridge for the interchange of 2D vector data between Government and private industry.

**B.8.3Product Data Interchange Standards**

**B.8.3.1MIL-PRF-28000, Digital Representation for Communication of Product Data: IGES Application Subsets and IGES Application Protocols**

MIL-PRF-28000 is the performance specification, which defines DoD requirements for the application of the Initial Graphics Exchange Specification (IGES). This specification provides a mechanism for the digital exchange of product data among computer aided design (CAD) and computer aided manufacturing (CAM) systems. This specification is required when procuring three dimensional illustrations (e.g., 3-D models, wire frames, etc.)

MIL-PRF-28000 applies IGES as specified by the U.S. Product Data Association (USPRO) standard. It defines application protocols, or "classes", which are subsets of the IGES entities identified according to the application for which the digital data was prepared. The following IGES classes will appear in Revision B of MIL-PRF-28000:

· Class 1 - Technical Illustration Subset

· Class 2 - Engineering Drawing Subset

· Class 3 - Electrical/Electronic Applications Subset (Withdrawn)

· Class 4 - Geometry for NC Manufacturing Subset

· Class 5 - 3D Piping Application Protocol

· Class 6 - Layered Electric Products Application Protocol

· Class 7 - 3D Geometry

Most SGML browsers cannot view IGES illustrations natively. Therefore, the IGES drawing is typically converted to a CGM format (see paragraph B.8.5) for viewing within an IETM application.

**APPENDIX CIETM and Training Strategies**

**C.1Introduction**

Today’s military budgets demand the cost effective development of IETM products that serve both maintenance and training requirements. IETMs are a key source of data to implement the electronic classroom and on-the-job training. Training benefits from IETMs have already been demonstrated through practical applications in several programs.  Training development for a system is a long and complex logistics support process that is begun early in system acquisition. Clearly, there is a major interface between development of training and the development of IETMs.  When appropriate, a training plan (or equivalent) should address those IETM items needed for familiarization, formal classroom, and on-the-job training for system operation, maintenance, and other special forms of logistic support.  To identify and understand requirements and interfaces, close coordination between the maintenance planning, technical manual, and training disciplines for an IETM is required. In order to determine the IETM functionality needed to economically support training, input is required on training infrastructure requirements and its objectives to:

· Develop, reduce or eliminate formal course training

· Develop on-site training

· Define and develop a shared IETM and training database

Once the equipment and user training requirements are determined, all disciplines must identify the issues and resources required for each to implement the IETM within their community.  The Training Plan is needed prior to contract award to permit definition of IETM features needed to support the training requirements, whether in a formal classroom or on-site. 

**C.2Integrated/Interfacing Training Strategies and Issues**

There are a number of issues involved in the integration of electronic versions of technical manual data (which is the source of technical data for training materials) and automated, electronic training development and delivery systems.  The following paragraphs highlight the selection of an interface strategy and other issues that would need to be resolved by Program Managers in developing logistic support for a system or equipment.  Due to the rapid advancement and employment of automated tools to create and present technical data, failure to address these issues may lead to early problems in implementing even conventional systems.  

**C.2.1Strategies**

There are four strategies for approaching the interface between training and the IETM development process:

· Coordinated (exchanging files, interfacing software) - Independent IETM and training product development with planned and coordinated exchange of IETM files, software, etc. for interface with automated curriculum development programs.

· Concurrent (developing some shared data, sharing/interfacing software) - Simultaneous, planned, and coordinated development of IETM and training support products; development and use of shared data and software; initial joint planning and requirements determination which enable data integration into the training curriculum.

· Integrated (developing a shared database; sharing software) - Structured, concurrent, and shared development of all maintenance, operations, and training materials into a single, fully integrated database that uses multiple tailored view packages to present material to various users.

· Embedded - Combining all requirements and materials into an integrated database with a single view package so that training materials are indistinguishable from maintenance, operations, and other materials; enable operations, maintenance, and training personnel to use a single product.

In its initial planning, the Program Manager must decide which approach will provide the most benefit, including acquisition and support of both IETM and training requirements throughout the life-cycle.  As training will have a significant impact on both acquisition and life-cycle costs, these decisions may affect the choice of IETM that will most appropriately support the system and military unit.

**C.3Logistic Organization Changes**

The electronic training and IETM interface has organizational implications for both the Government and contractors/developers.  Traditional logistic organizations are divided into product-oriented groups (e.g., provisioning, training, technical manuals) that support specific logistic functions, such as supply support, training and maintenance.  Differing requirements, goals, timing, and funding have served to keep these products and the development processes unique.  The Logistics Support Manager oversees and manages the assignment, coordination, and synchronization of logistic product development.  The development of an IETM offers a fresh opportunity to combine separate logistic functions into a single effort that focuses the leadership and work force of the entire logistic spectrum. This confluence should also improve the quality and consistency of all logistic products, while reducing both initial and life-cycle resource requirements. For example, the technician who repairs and the instructor who teaches about the item can pool their knowledge and develop a single set of data that satisfies multiple requirements and augments and enhances work performance and quality at any maintenance level.  The writer could be either a subject matter expert (SME) or a third party skilled in preparing technical data.  This would ensure that data is sufficiently granular, or properly subdivided, to satisfy multiple requirements and enhance work performance at the organizational or intermediate level.

**C.3.1Concurrent Development of Technical Logistic Information and Training**

Under the accelerated and integrated acquisition processes for new ships, aircraft, and weapon systems, training (e.g., course curriculum) and technical manual data needed to teach a course may be jointly and concurrently developed.  Occasionally, the training schedule may even require that training begin before the system or its technical manual is complete.  Traditionally, the basic outline of the technical manual is developed from an approved book plan that contains all paragraph elements, tables, and figures needed to support a basic curriculum plan.  Because a Class IV/V technical manual will at least have all of the required data, but will not have the traditional publishing organization, the equivalent of a book plan must be developed to provide the definitions and relationships that satisfy the need for understandable and mutually agreeable “hooks.” This navigation tool is then populated with cross-references between traditional organizational elements and an object identification (ID) for each element.  The cross-reference IDs are stored and managed in a database and provide the links in the final product.  As more detailed information is developed by TM authors, the IDs can be expanded under this structure.  These new IDs are made available to curriculum authors who use them to improve the accuracy of the curriculum references. It is easier to integrate a static or completed data set with a developing data set.  But in the case of parallel development, integration is part of the overall process during creation of both data sets.

**C.3.2Interface Versus Integration of Training and IETMs**

Selection and design of the database is among the more sophisticated and technical decisions that need to be made.  There are essentially two choices.  The first is to divide and manage the TM data as objects that are some variant of their original form (i.e., raster scanned page, tagged paragraph, warning, title, etc).  For text files already in digital form (Class II/III), data are generally tagged in accordance with MIL-PRF-28001 with little or no significant re-authoring.  The file may remain in a linear format, particularly where hard-copy versions of the TM are also required.  

This orientation toward hard-copy product formats is well suited to existing training processes, where traditional linking ties data (e.g., paragraphs, tables, figures, videos) to specific learning objectives.  The data extracted from the IETM, however, must often be processed to glean only a specific portion needed to meet a learning objective.  As an example, an IETM paragraph generally contains extraneous or excessive data that can obscure the point of the learning objective or confuse the student.  This excess data must be edited out.  Legacy data conversions that attempt to fully accommodate these training requirements may find that additional data handling, authoring and processing may add sufficiently to conversion costs to change the initial decisions on the selection of IETM or conversion type.

The other choice is to build the data as an object (Class IV/V) database, where information is broken down into small units (steps) that are connected by the inherent logical hierarchical structure of the database (as discussed in MIL-PRF-87269).  Typically, this process will evolve from a new acquisition or major modernization where the documentation is already being substantially redone.  A significant advantage is that an integrated team of training and TM authors can ensure that these steps are at the smallest logical unit that accommodates both TM and training team members and are phrased with language that can be used by both with no additional processing.  

Curriculum connections are made at points in the hierarchical structure which provide access to sets of data that may include graphics, animations and audio.  For the maintainer, these data sets can vary based on actual conditions found at each decision point.  That is, the IETM can propose alternate courses of action based on input from the technician, equipment historical files, diagnostic data, maintenance schedules and a variety of other factors.  Because of specific training objectives, the trainee’s use is more constrained.  This mandates a more active training role in concurrent development of electronic training and IETM requirements and products to maximize the benefits.  Significant initial planning and coordination is needed, but huge benefits can accrue in the elimination of initial redundant efforts (e.g., authoring, reviews, formatting, storage) and data.  The reduction in life-cycle costs is also significant, but difficult to fully measure at this time due to the lack of much practical experience with a sufficient number of mature, fielded systems.  

Early program decisions on the most beneficial approach enable coordinated planning for support of both sets of requirements throughout the life-cycle.  As training will have a significant impact on both acquisition and life-cycle costs, these decisions may also affect the choice of the most appropriate IETM.

**C.3.3Life-cycle Configuration Management and Update Considerations**

Budgeting, funding sources and priorities, update cycles, and distribution vary significantly between the hardware and required logistic products.  On one hand, an interfaced or integrated logistic system can substantially reduce life-cycle costs and improve user performance.  On the other hand, failure of any portion of the system to effect changes on a timely or synchronized basis can rapidly lead to disconnects in the existing manual system.  In comparing electronic database with manual counterparts, the difference is that manual systems generally allow users to “make do” with available data; the computer may simply provide a “file not found” message that will severely frustrate users and may actually negatively impact readiness.  Proper planning and process modification are needed to ensure that a single engineering update is sufficient to satisfy all logistic needs and ensure appropriate modifications are made to the logistic infrastructure.  

Traditionally, training lags other equipment and logistic changes by weeks or months.  Synchronization of the electronic training and IETM products demands that changes occur simultaneously.  There is currently no formal mechanism or to ensure this happens.  Failure to do so may either cause electronic products to simply stop working (e.g., the training system is unable to find expected data and “crashes”) or all joint users will be forced to use the last common revision, even though it does not reflect current installations.  Where the IETM is embedded within the operating system of the actual hardware system, this problem can become even more complex and life-cycle planning must account for it in overall system deployment and operational plans.

**C.3.4Field Interface and Responsibilities**

Reduction of costs for life-cycle support is a key objective for both automated training and IETM development.  Both consider automated processes for reducing  development and update costs and for improving the delivery of the data to the user.  For training, fewer classroom hours may be a key measure of success.  It may reduce the number of instructors and students in the training pipeline.  The IETM similarly enables personnel with less skill or little training to perform functions at an acceptable level of performance.  In both cases, the net result is that training costs can be reduced and maintainers who are able to perform increasingly sophisticated and demanding work, are available sooner.  

**C.3.5Mutual Functionality**

Adding training developers, instructors, students, and other related users into the IETM requirements increases the complexity but does not change the decision-making process for functionality determination.  Three elements are involved; function, functionality, and feature.  Function is the customer task that must be satisfied  (e.g., manage and update drawings).  Functionality is the capability to perform that function.  For example, the function “update drawings” may be satisfied by “edit 3D CAD,” “edit 2D CAD,” “edit with vector over raster,” “edit raster” or “input new drawing.”  The products derived from each are clearly different.  There is also a substantial difference in the infrastructure investment, training and life-cycle costs required for each.  Thus, while giving the user the ability to “walk around” a 3D version of the system is desirable, the benefits may not justify the life-cycle costs of maintaining a 3D model of each system.  

The choice of functionality, therefore, depends upon potential cost, priority, expected uses of the resulting product, projected benefit and other related factors.  Once selected, various software packages are examined for features (i.e., how the functionality is provided).  For example, all major word processing programs can “create tables.”  How they are created, edited, modified, and tailored are features.  If the user has few or relatively simple tables, this may be an interesting, but inconsequential feature.  If much of the prospective data is tabular, this critical feature may decide which software is selected. 

Training may increase the functionality requirements and probably will change the priority and importance of specific functionality.  Specific features may be critical to training, but not to developers or maintainers and vice versa, thus complicating software selection.  Most programs also provide a range of functionality so decisions may involve some duplication or sub-optimization of functionalities to obtain the most cost effective or productive mix.  The addition of training requirements and functionality may also impact the selection of the database management system and associated presentation software and hardware.  Thus, training input must be an integral part of this decision-making process in order to ensure an optimal mix of software that works together and provides at least adequate functionality for all potential users.

**C.3.6Migration**

Using standard formats, selecting mainstream software and hardware, documenting processes,  purifying and managing data are all critical to having a system that is able to continuously satisfy the functional requirements of users. It is essential to migrate source data to a common format prior to developing a cohesive training/IETM program.

Planning for orderly progress is challenging when migration is unilateral (TMs), but it becomes significantly more complex when migration is multilateral (e.g., TMs, training, supply support).  This is particularly true where programs have followed the “rules” and are using C/NDI resources.  A prime benefit of C/NDI products is that they are constantly upgraded and improved at modest or no cost to the Government.  However, C/NDI sometimes require application tailoring or selection of application options.  Further, when multiple C/NDI packages are used, the specific interface and integration tailoring is left to the using activity.  Thus, any C/NDI upgrade may upset the balance between packages, leading to significant programming, re-tailoring or worse.  The problem can be significant when the original developer is still engaged, but can be severe when the system has been turned over to a Government maintenance activity that is not familiar with or prepared to update the integration software.  

With multiple migration paths to consider, a key part of strategic planning is to determine where interfaces and integration occur and how they are impacted.  For example, if multiple presentation systems feed off of the same database, each can be independently upgraded without direct impact so long as the interface with the database is constant.  Modifying the database, however, may impact all application programs.  These problems cannot be solved by strategic planning, but can be addressed with management attention focused on key decisions to mitigate impact.

**C.4Interactive Courseware (ICW)**

Another viable training program to consider integrating with an IETM ICW.  ICW differs from other training programs in that it is self-paced.  The following paragraphs discuss the fundamentals of a combined IETM-ICW program.

**C.4.1ICW Definition**

MIL-HDBK-284-3 defines interactive courseware as denoting either of the following:

· “A computer program-controlled instruction that relies on trainee input to determine the order and pace of instructional delivery.  The trainee advances through the sequence of instructional events by making decisions and selections.  The instruction branches according to the trainee's responses.”

· “A term referring to any type of computerized instruction characterized by the ability of the trainee to respond through an input device.  ICW may be an integral part of computer-based instruction (CBI), computer aided instruction (CAI), and computer-based training (CBT)."

ICW specifications and guides support the development of highly realistic, efficient training with the end-user considered the primary focus of courseware design and information presentation.  Within financial and logistic constraints and without compromising training effectiveness, ICW is expected to provide:

· A user-friendly trainee interface and lesson structure

· Accurate, up-to-date technical information and procedures

· Instruction, segmented to provide meaningful training

· Extensive use of help routines and remediation

· Individualized tailored instruction

· Confirmation of learning by immediate and/or delayed lesson- and content-specific feedback

**C.4.2Introduction and Background**

ICW is based on a systems approach and a well established Instructional Systems Development (ISD) model with six basic phases:  analysis, design, development, implementation, evaluation and revision.  ICW has evolved from different forms of instruction delivered by way of computer.  In an optimally designed course, the learner’s decisions and inputs determine the level, order, and pace of instructional delivery, and forms of individualized visual or aural outputs.  Interactivity ranges from simple button-pushing to complex inputs, content-specific feedback and remediation.  ICW is used in a variety of educational and commercial training environments as well as Government and military training programs.  It may:

· Present information by text, graphics and sound

· Elicit learner responses through various prompted and unprompted strategies

· Provide feedback, remediation, and testing

· Provide practice in simulated tasks and decision-making scenarios  

User control varies from limited navigational to complete control.

**C.4.3ICW Production and Display**

ICW consists of text, graphics, and computer programming and/or scripting instructions assembled into a logical structure designed to convey facts, concepts, procedures, and to provide instruction and practice in problem solving.

**C.4.3.1ICW Production**

Assembling the various elements of ICW is commonly called authoring.  Authoring software packages are available for a variety of computer platforms including Microsoft WindowsTM and MacintoshTM-based systems.  Most authoring programs provide the capability to access or call-in external programs, while the instructional program is running. ICW may be produced on various configurations of computer hardware.  The current trend is to produce ICW on multimedia PCs or Macintoshes.  Video and sound cards, SVGA monitors, and built-in CD players are required.  The PCs may be stand-alone or part of a computer network.  A general overview of the production process for the ISD system and ICW subsystem is shown in Figure C-1.

**Figure C-1.  ISD System and ICW Subsystem**

**C.4.3.2Display Software/Hardware and User Needs**

A run-time version of the authoring software is normally used as the presentation software. Ideally, an ICW developer should determine in advance the computer specifications of the intended user’s computer.  Material that displays just fine on a powerful developer’s computer may not display at all on a user’s less capable computer. Due to their small size, portability, and increasing capacity and capabilities, laptop computers are increasingly popular as ICW delivery hardware.  As deployed military units have critical space and weight limitations, having all training combined with the technical information (i.e., IETM) on a compact medium is advantageous.

**C.4.4IETM - ICW Interface**

There are many obvious mutual benefits to interfacing ICW with IETMs.   From an IETM perspective, the user can access content-specific instructional materials to refresh or augment technical concepts or enhance performance of procedures.  From an ICW perspective, the necessary learning elements (e.g., menus, objectives, embedded questions) are resident in the ICW.  Moreover, during an ICW lesson, the instructor will also have on-line access to extensive depth and scope of referenced interactive technical information from an IETM database.  This will substantially expand the instructor’s ability to provide realistic, real-time responses to student requirements, queries, etc.  There is, however, a key issue.  Training and its associated funding  frequently lag introduction and changes to the weapon systems by as much as two years.  Therefore, training (i.e., the ICW) may be "generic" in nature and may not be complete or technically accurate.  Conversely, an IETM would require timely upgrades, changes, and modifications commensurate with the system it supports.  The issue of synchronizing updates and funding will be addressed in more detail later in this chapter.

**C.4.4.1Comparison of Categories of ICW with Classes (I - V) IETM**

IETMs and ICW can be classified and compared in terms of their interactivity and branching capabilities. The following discussion uses these designations as a preliminary point of comparison.  The IETM classifications have been defined previously and are summarized as:

· Class I - Electronically Indexed Page Images

· Class II - Electronic Scrolling Documents

· Class III - Linear Structured IETMs

· Class IV - Hierarchically Structured IETMs

· Class V - Integrated Database IETMs

MIL-HDBK-284-3 has categorized ICW by three general levels of interactivity as shown in Table C-1.

Category 3 ICW presentation of data is similar to the functionality of Class III, IV, and V IETMs.

**C.4.4.2ICW and IETM Commonalty and Differences**

While there will be differences in the specific presentation of the material, it is clear that there can and should be an exact match between data presented in ICW and in a corresponding IETM.  The same discrete set of technical data (e.g., technical manual data, drawings, animations, expert systems modules, videos, text items, training review questions, and audio clips) should appear in both view packages.  However, it is also clear that the needs of and results required by the maintenance technician may be quite different from those of the student.  Consequently, while the whole set of data should be the same, each user will be working from a tailored subset of that data. There are other important differences in the underlying foundations and design of IETMs and ICW that determine how the IETMs or ICW lessons are programmed and the type of navigation and access capabilities that are needed for the two information presentation systems. It is therefore critical that technical information be developed in a concurrent engineering environment to ensure that a single set of data can fulfill all of its intended roles.

Table C-1.  ICW Categories of Interactivity

**Presentation**

**Description**

Category 1 - Baseline

A knowledge-based or familiarization lesson, in linear format, used for introducing an idea or concept with minimum trainee interactivity.  (i.e., the trainee has little control of what is seen).  There are two types:

· Video and minor text presentation

· Graphics and minor text presentation

Category 2 - Medium Simulation

A lesson that involves the recall of more information and a moderate degree of simulation and that allows the trainee increased control over the presentation. This presentation:

· Provides combined information and skills lessons

· Requires a moderate degree of programming

· Provides trainee interactivity with various input/output devices

· Provides computer-managed instruction to track and analyze student performance

· Normally combines video and graphics presentations

Category 3 - High Simulation

This lesson uses the full capabilities of ICW with every subtask analyzed and presented for full, on-screen interaction, similar to that used in aircraft simulator technology.  The trainee determines areas where further training is desired.  This presentation provides: 

· Procedural tasks and skills

· A high level of student interactivity

· Extensive branching capability

· Maximum remediation opportunity

· Real-time event simulation with minor equipment limitations

· Capability to interface with other output devices

· Exhaustive CMI capability

**C.4.5IETM - ICW Interface Scenarios**

Two major scenarios for interfacing IETMs with ICW and the procedural similarities and differences in various acquisition and/or production conditions are discussed:  concurrent development and developing ICW using an existing IETM.

**C.4.5.1Concurrent IETM and ICW Development**

Concurrent development is the optimal method and is expected to be used extensively in the future both for new manuals and for major conversions (e.g., to Class IV) where significant re-authoring is required. If a fully developed IETM does not exist, every effort should be made to develop the ICW and IETM concurrently.  The general processes can be modified and adapted to mutually support the instructional systems development associated with ICW and IETMs. Learning and performance objectives for ICW****strongly impact the complexity of its development.  Using specified learning and performance objectives and the technical content within the IETM, the ICW design team will have complete and accurate data to develop courseware focused on the user. Factual information presented with simple graphics is easy for the user to grasp and requires less time to design, develop, program, maintain, and update than complex troubleshooting lessons employing 3-dimensional animations. The same SMEs should be used for IETM and ICW development on a particular topic. 

**C.4.5.2Development of ICW Using an Existing IETM**

Under the most prevalent type of scenario, ICW will typically be developed using an existing IETM.  Figure C-2 describes the five major task associated with this process.

**Figure C-2.  Creating ICW Using an Existing IETM**

**C.4.6ICW Specifications**

**C.4.6.1Requirements Definition**

MIL-HDBK-284-1 Appendices A and B provide detailed guidance for requirements pertaining to ICW Front-End Analysis (FEA), and ICW design, development, and implementation.

**C.4.6.2IETM - ICW Interface Specifications Development**

Since IETM-ICW interface specifications are not currently available, ICW specifications (developed according to MIL-HDBK-284-1) may be merged with an IETM specification developed using considerations provided elsewhere in this document.

**C.4.6.3Government Specifications - ICW Standards**

MIL-HDBK-29612 provides tailorable requirements and task descriptions for acquisition of military training programs.  Tasks described in this standard should be selectively applied to DoD contract acquisition and Government development of requiring military programs.  Specific task description number(s) and appropriate paragraphs, as well as applicable task inputs and task outputs, should be included in the SOW/SOO of the Request for Proposal and in the contract. The Appendices of MIL-HDBK-284-1 contain guidance on the acquisition and support of ICW.  The requirements are applicable MIL-HDBK-29612 task descriptions rather than material/weapon system/equipment training program requirements. The task descriptions in MIL-HDBK-29612 are presented in recommended SOW/contract performance sequences.

**C.5IETM Interface Decisions**

The program decision to use an IETM and interface it with training involves a commitment of resources to accomplish one or more objectives to reduce costs and improve operational availability, worker productivity, and quality.  Whether acquiring new data or converting existing data for use in an IETM, the program has three key decisions to make: 

· Functionality - The capabilities and features that are desired

· Standards - Which Government, commercial, performance (or other) standards will be required

· Data structure - How the data will be created or assembled, managed, and related to itself, associated data, and its environment and parent equipment

Each decision is an enabler, facilitator or constraint for other decisions.  For simplicity, decisions on data structure, standards, and functionality will be collectively referred to as “functionality” unless otherwise noted.  Clearly, the functionality selected has critical impact on:

· Cost of and time needed for conversion

· Users’ ability to gather and use data

· Costs and ability to maintain and update the data

· Ability to interface, interact, and share data with other logistic processes and data files 

· Ability, cost, and effort to migrate in the future to newer technology

**C.6Training Impact on CONOPS Development**

The decisions on whether to produce an IETM, what kind of IETM, and how the IETM will connect with other requirements (e.g., training) to improve logistic support, are lengthy, complex, and interrelated.  Conveying the breadth of background, knowledge, and understanding needed to derive the product desired is made more difficult by adding training factors and considerations. This further supports the concept of documenting factors and decisions and establishing the conditions within and under which the IETM and training products will function.  Preparing the CONOPS and expanding it to include these additional considerations is still the most effective approach to clarify issues and establish parameters to help a manager select optimal IETM functionality levels consistent with program IETM and training requirements.  The Program Manager can then develop performance statements, mapped to conditions in the CONOPS, to use in the TMCR and any other required documents that deals with the interface of IETMs and training products.  Additionally, as training and IETMs become more intertwined, the existence of an organized and structured way of monitoring, acknowledging, and addressing the total impact of change can provide insight and understanding and obviate the need for hasty or ad hoc changes. By highlighting and monitoring factors that are critical to IETM and training success, decision processes can be periodically or specifically revisited and parameters adjusted, if necessary, to ensure that change is accommodated and continued success is assured.

The IETM Functionality Determination Model (Figure 5-2) identifies and projects the hardware or weapon system characteristics (whether already in the field or being prepared for acquisition or introduction) that define the supporting IETM functionality requirements and uses them to develop the IETM CONOPS.  Integration of the training requirements into this decision set during the initial IETM requirements development is desirable as it will provide the optimal results.  However, even if IETM determinations have already been made and are underway, use of the model to include and assess required training functionality provides a process for ensuring that all factors have been considered within the context of the original decisions.  Where the training input suggests changes are required, the Program and Logistics Managers will be able to properly and completely assess the impact of proposed actions.  This review may also prompt a review of the initial decisions and factors to determine whether other changes are required.  In each case, managers will be acting on a full set of facts that provide a solid base and context for decision-making.  Similarly, the results of these deliberations will be documented in revisions to the CONOPS.

**APPENDIX DAir Force IETM Information**

**D.1Air Force Strategy**

The Air Force’s digital data strategy seeks to achieve three primary objectives:  first, to produce a digital data management approach that provides the Air Force with JCALS and JEDMICS-compatible digital data; second, to facilitate user access to digitized technical data; and third, to exploit technology and significantly reduce the costs associated with hard-copy Technical Order (TO) and engineering data management processes.

In April 1995, the AF PDSM (Product Data Systems Modernization) Program Office produced the Air Force Digital Data Strategy and its accompanying Technical Order Conversion Implementation Plan. The Air Force digital data strategy will convert approximately 16 million TO pages from paper to digital format for input to JCALS.  Through functional and economic analysis, the Air Force has chosen to convert the legacy TOs to Indexed Adobe® Portable Document Format (IPDF). This conversion format will provide maximum data interchange utility to data users and be compatible with JCALS. Because they include indexing and hyperlinks, these documents are classified by the Air Force as Class II IETMs.  Table D-1 lists representative production figures for the TO conversion effort.

The strategy also initiated an update methodology that could be implemented throughout the Air Force to provide users with the capability to sustain page-based digital TOs. It should be noted that for the foreseeable future, TO users will be using both paper and digital products depending upon their operating environment and media requirements. Thus, the IPDF sustainment approach addresses both paper and digital update strategies as it promotes a migration to a "less-paper-intensive" environment.  Because of its substantially higher costs, Class IV IETM functionality is being acquired for only a few select programs until the concept is proven and sustainment and delivery infrastructure constraints are better understood and/or resolved.

The AF Digital Data Strategy requires that new TOs be developed digitally in SGML using Air Force content-specific Document Type Definitions (DTDs).  These DTDs are appended to the Technical Manual Specifications and Standards (TMSS).  The SGML TOs should include graphics that are formatted according to the Computer Graphics Metafile (CGM) language; however, they can also contain Initial Graphics Exchange Specification (IGES) or raster graphics. 

Prior to JCALS deployment, contractors should deliver IPDF files generated from SGML TO source data for organically maintained TOs.  IPDF files are platform independent digital files that are suitable for viewing, document navigation, and print-on-demand. Delivered IPDF files may be stored and sustained on the Digital Legacy Data Storage System (DLDSS) until JCALS is fielded at the users’ location.  DLDSS is an interim storage capability for IPDF TOs provided to each Air Logistics Center (ALC).  After JCALS deployment, contractors should deliver SGML TO files for loading onto the JCALS system for organically maintained TOs.  In addition, if the contractor obtained approval from the PDSM Office to prepare and/or use DTDs that were different from AF DTDs, these DTDs will also be delivered to the Government.

**Table D-1.  Production Status of Air Force TOs (July – November, 1998)**

Production Status

July

August

September

October

November

TOs

Pages

TOs

Pages

TOs

Pages

TOs

Pages

TOs

Pages

# Ordered *

129,002

10,955,338

129,657

10,972,072

133,145

11,004,937

133,663

11,016,817

133,879

11,026,026

# Received *

 97,549

8,564,204

98,290

8,591,449

98,715

8,603,638

99,264

8,629,871

99,384

8,637,949

# Unprocessable*

4,491

393,797

4,495

394,444

4,496

394,490

4,753

522,225

5,054

553,754

# Pre-Conversion Processed *

86,075

7,125,979

86,688

7,146,735

87,024

7,149,956

87,181

7,051,269

86,972

7,024,880

# Ready for Shipment (Backlog)

10,293

334,505

10,951

365,224

11,205

375,908

11,586

392,592

11,431

391,416

# Shipped to Conversion Orgn*

75,782

6,791,474

75,737

6,781,511

75,819

6,774,048

75,595

6,658,677

75,541

6,633,464

# Converted by Conversion Orgn*

17,667

1,353,689

17,800

1,357,860

17,994

1,363,228

18,159

1,365,606

18,354

1,372,361

# Rejected by PDSM PO*

1,016

174,530

1,013

173,901

1,017

173,127

1,014

172,800

1,015

173,036

# Accepted by PDSM PO*

16,541

1,163,116

16,680

1,168,052

16,873

1,174,893

17,043

1,177,656

1,015

173,036

# Change Pkgs. Processed/DiTO

233

2,743

152

4,477

152

4,477

152

4,477

17,240

1,184,387

* Cumulative

**D.2Air Force Conversion Efforts**

The legacy TO conversion effort includes TO pre-conversion, conversion, and post-conversion processes. The pre-conversion process includes requisitioning legacy paper TOs; verifying them against the system List of Applicable Publications (LOAP); making complete TO books, which include changes and supplements; ensuring that individual pages can be scanned; and shipping the complete TO to the converting organization. When TOs are incomplete (missing pages, missing changes, blurred or blank pages, etc.) or contain supplements, the Technical Content Manager (TCM) is notified of the corrective action required; either to replace pages or to incorporate supplements into changes. 

The conversion process includes converting the paper TO to an IPDF file; linking the TO’s table of contents, lists of tables, figures and illustrations, and alphabetical index with the TO’s text; writing it to digital media; ensuring that it is indexed according to the TO Contract Requirements (TOCR) document; and then sending the digital TO along with its paper version to the Technical Order Conversion Operation (TOCO) for post-conversion. The latest TOCR document can be accessed on the WWW at http://www.pdsm.wpafb.af.mil/tocr.html. 

The post-conversion process includes ensuring the IPDF TO has not lost any technical content during the conversion process; meeting the requirements in the TOCR document; maintaining configuration control of the TO until delivery; and shipping the IPDF TOs on 4mm Digital Audio Tape (DAT) or CD-Recordable (CD-R) to the TO Manager at the managing ALC for approval and loading into the DLDSS. JCALS will be used for digital TO sustainment when it is fielded.

The Single Manager (SM) should work with the TOCO facility to convert legacy TOs. It is AF policy  to procure digital TOs where available in complete form rather than undertaking conversion of paper TOs. To that end, SMs should strive to acquire digital TO files from their contractors if the TOs are in complete book form. These TOs should be acquired and delivered in Postscript format, PDF, or IPDF that is indexed according to the requirements in the TOCR and based upon the contractor’s capability to deliver. TOs delivered by contractors in Postscript, PDF, or IPDF should be delivered to the TOCO facility for conversion or linking as required, and Quality Assurance (QA). For the TOCO to avoid converting TO books already in digital form, SMs should contact the TOCO to identify digital TO books being procured from their contractors.

To sustain digital TOs, the SM should eliminate supplements. TO supplements do not lend themselves to use and management within a digital environment. While it is possible to update affected paragraphs in IPDF files by inserting "pointers" (which is in effect what a paper supplement does), the process is too labor intensive for everyday use in the field. Therefore, IPDF TOs should be maintained through Block Cycle Updates (BCUs) and Rapid Action Changes (RACs) using composed page changes. The process for exchanging "pages" in IPDF documents is facilitated by the Digital TO (DiTO) Change Incorporation Software (TO 00-5-1-101) developed by the AF PDSM Program Office. After the change package has been posted or "merged" into the baseline, the TO is linked using C/NDI software packages. These software packages include InfoLinker which, in conjunction with a "rules file" automatically generates links within a document, and LinkManager, which manipulates the instance and appearance of the links. The complete AF change process is further detailed in the SM Guide.

**D.3Air Force IETM Display Equipment**

Program Managers who elect to acquire IETMs should ensure that display devices and accompanying software have the capability to view IPDF files so digitized legacy data can be viewed without the need for conversion to higher-level IETM format. 

The use of IPDF TOs near the flightline introduces a variety of human factors concerns. Environmental conditions such as bright sunlight, rain and dust are just a few of the issues that should be evaluated prior to deployment of IPDF TOs on the flightline. Great strides have been made in “ruggedizing” Portable Maintenance Aids (PMAs) for the harsh military operating environment. However, most PMAs, especially those off-the-shelf, do not currently support the effective viewing of IPDF TOs.

As an alternative approach, organizations could use common-area computers strategically placed in aircraft maintenance bays or dispatch vehicles, so crews could access TOs.  The IPDF TOs could be stored on a server and accessed through the base network, or on a hard disk/CD.  Printers could be provided if print-on-demand is a requirement.

IPDF TOs may be used on an aircraft when they fulfill unique requirements and the computers will not jeopardize safety of flight. PMAs often interfere with onboard navigation and safety equipment.  Once approval is received for using these computers, portable display devices or built-in computer systems should be considered for in-flight use.  Desktop PCs are not conducive to aircraft operations because of the space limitations and onboard power systems of the aircraft.  Access to IPDF TOs onboard the aircraft may be through CD or computer hard drive.  Online access to TOs from positions within the aircraft may be possible if a LAN access system is part of the aircraft system.

**D.3.1Joint Integrated Maintenance Information System (JIMIS)**

JIMIS is a product of the Northrop Grumman Corporation deployed in the Joint Surveillance Target Attack Radar System (JSTARS) community (Warner-Robbins AFB). The JIMIS program currently sustains JSTARS TOs in a parallel paper and Class IV IETM environment. The source data, originally paper, is being completely re-authored to conform to a Class IV database structure. JIMIS displays CALS-compliant technical data electronically for the Air Force technician. Its primary function is the rapid retrieval and presentation of technical data (TD) for the maintenance technician. It can be deployed in an office or shop environment with off-the-shelf PC workstations or in a harsh environment with ruggedized PMAs running X-Windows. 

The JIMIS sustainment plan calls for periodic updates of JSTARS data every 75 days. The contractor supplies the updated information on 4mm storage tape to base personnel who mass replicate the data onto small hard drives. The drives are disseminated to the appropriate personnel who return a hard drive containing the old data. The recycling of hard drives has continued throughout the JIMIS program without experiencing a single hard drive failure. 

**D.4Online Resources**

The best starting point for obtaining Air Force TO information is the PDSM home page at http://wpaftb1.wpafb.af.mil/. The page contains numerous links to strategy and guidance policy, TO conversion information, and other digitization efforts. Of particular note, download the USAF Single Manager’s Guide For Implementing Digital Technical Orders at http://wpaftb1.wpafb.af.mil/datamgt/singmgr.htm. This SM Guide contains the AF integrated approach to implementing digital TOs. The integrated approach was produced to support AF SMs in meeting the challenge of acquiring and sustaining page-oriented digital TOs. The Guide applies to all TO acquisition and sustainment programs supporting systems developed, deployed, or managed by the Air Force. In addition, it applies to newly acquired digital TOs as well as to legacy TOs being managed either organically or by contractors. SMs should use this Guide to acquire new digital TOs, and to convert, sustain, and distribute legacy TOs. The Guide identifies SM responsibilities, which will be required to implement a series of steps and processes to prepare their weapon systems for entry into an IDE. It also provides sample wording to use in a SOO/SOW and describes inputs to various sections of an RFP.

Air Force acquisition managers may obtain the Joint Service CALS Reference Toolkit on CD at http://wpaftb1.wpafb.af.mil/train/calstool.htm. This CD contains the DoD Government Concept of Operations (GCO) Generator Tool; the CALS specs and standards in PDF format along with the Adobe Acrobat Readers; Joint Service information on JCALS, JEDMICS, CMIS, and more.

AF Technical Manual Contract Requirements (TMCR), TM-86-01G, 1 Dec 1998 in Word 6.0 format, can be found at http://wpaftb1.wpafb.af.mil/toprac/WORKING.HTM. A copy of the instructions for use of the TMCR (TO 00-5-3), a generic TO Management Plan and a Generic TO Verification Plan, can also be obtained at this Web site. 

The Air Force offers two methods for obtaining training on digitized TOs. A CBT course for TO Acquisition and Sustainment can be downloaded from http://wpaftb1.wpafb.af.mil/toprac/ to2sys2.htm#TOCBT. The course (Figure D-1) is a desktop computer Windows-based software product that provides in-depth detailed information on TO acquisition and sustainment management concepts, policy, and processes. The CBT course is divided into 10 lesson modules: 

· Lesson 1: Air Force TO System

· Lesson 2: TO Acquisition and Management

· Lesson 3: Interface

· Lesson 4: Budget and Cost

· Lesson 5: Technical Manual Contract Requirements (TMCR)

· Lesson 6: Digital Data

· Lesson 7: Technical Manual Specifications and Standards (TMSS)

· Lesson 8: Time Compliance TOs (TCTOs)

· Lesson 9: Improvement and Update

· Lesson 10: Printing and Distribution

Contact HQ MSG/ILMP, Ms. Pam Sutton at DSN 787-3085 or e-mail: suttonp@afcpo.wpafb. af.mil for more information on the course and its content.

**D.5Acquisition Classroom Instruction**

AF acquisition managers can also attend a one day course for Digital Data Product Acquisition. This course is designed to be presented at customer sites for audiences of ten to thirty students. Customer organizations are to fund the TDY cost of one Air Force CALS Program Office representative to present the course material. The course abstract and outline are presented below. The AF PDSM Program Office (DSN 787-3085) can be contacted for more information about this course.

**D.5.1Course Abstract**

Description: This course will train Air Force personnel in effectively acquiring digital weapon system product data within the current acquisition reform environment. Emphasis is placed upon how to develop an RFP that will result in delivery of digital technical orders and engineering data that are compatible with JCALS and JEDMICS respectively. Particular attention is paid to development of the digital data GCO, contractual language development for digital product data acquisition, and other topics that will enable Air Force weapon system SMs, supporters, and users to more effectively function within the Integrated Product Data Environment (IPDE). 

Target Audience: Course is targeted towards acquisition logisticians, engineers, and data managers at Air Force product centers, Air Logistics Centers, and operating locations. In addition, a two-hour executive summary briefing is available. 

Learning Objectives: 

· To understand how to produce an effective RFP for acquiring digital product data in JCALS and JEDMICS compatible format (reflects the latest Acquisition Reform information).

· To obtain a working level knowledge of digital data types; and digital data interchange, format, and delivery/access characteristics.

· To understand how to determine digital product data requirements.

· To understand DoD and Air Force information management policy, strategies, and infrastructure that frame the digital product data acquisition process.

· To understand techniques that will facilitate digital data.

Course materials (student charts that total 97 pages) will be sent to the customer site for reproduction two weeks in advance of the course. 

**D.5.2Digital Data Acquisition Course Outline**

Module 1:

· Learning DoD’s Digital Data Management Approach

· Modernize DoD’s Infrastructure (JCALS, JEDMICS, IDE)

· Improve Business Processes

· Acquisition Reform Impacts

· Integrate Digital Data with an Integrated Weapon System Management (IWSM) Environment

Module 2:

· Planning for Digital Data Acquisition

· Acquisition Guidance

· Know Your Program Characteristics

· Air Force’s Digital Data Implementation Strategy

· Technology Infrastructure Assessment

Module 3:

· Determining Digital Data Requirements

· Building the Government Concept of Operations

· Determining data types, users, and functions

· Understanding data delivery, format, interchange, and delivery options

Module 4:

· Producing a Cohesive RFP

· The Solicitation Process

· RFP Development

· Data Delivery Considerations

· Acquiring Technical Orders

· Acquiring Technical Data Packages

· SOO/SOW Language

· Acceptance and Evaluation Criteria

Module 5:

· Conducting Source Selection

· Contractor Proposal Process

· Source Selection Process

Module 6:

· Fielding of Digital Data

· JCALS

· JEDMICS

Module 7:

· Gleaning from Experience

· Digital Data Acquisition Return on Investment

· Acquisition Lessons Learned

D.6Software Licensing

In addition to the Adobe Acrobat Reader, the following programs have obtained the appropriate software licenses for viewing digital TOs:

Program Name

Browser Name

Software Vendor

JSTARS

JIMIS

Northrup Grumman

B-1B

Multi-Doc Pro

CITEC

AWACS

Multi-Doc Pro

CITEC

**D.7Air Force DTD Repository**

Page-oriented TOs should be developed in SGML format with the appropriate and approved Air Force content specific DTD.  If an Air Force DTD does not exist for a particular TO type, then the contractor should produce a DTD only after coordinating its development and approval with the Air Force PDSM Program Office, which maintains the AF DTD Repository.

The on-line repository is available through the Technical Manual Specifications and Standards (TMSS) and Digital Support Suites (DSS) system at: http://129.52.152.8/pub/tmss-Web/ all/ all.htm

To access DTDs from this site, select the specification or standard number for which you wish to view the DTD and you will be given a menu of documents, related to the selected documentation.

The following list contains the DTDs that have been developed for legacy data to be used on the JCALS system. These files are updated frequently on this site. An additional FTP site has been established for the ALCs to access sample data. To find out the most current version or for sample data in accordance with these DTDs, contact the AF PDSM Office or Susan Yucker at (513) 257-2229 (email yuckers@afcpo.wpafb.af.mil). 

27. MIL-D-87269, Database, Revisable: Interactive Electronic Technical Manuals, for the Support of 

28. MIL-L-8031F, List of Applicable Publications (LOAPs), Preparation of 

29. MIL-M-5096F, Manuals, Technical: Inspection and Maintenance Requirements; Acceptance and Functional Check Flight Procedures and Checklists; Inspection Work Cards; and Checklists; Preparation of 

30. Legacy MIL-M-5096, Manuals, Technical: Inspection and Maintenance Requirements; Acceptance and Functional Check Flight Procedures and Checklists; Inspection Work Cards; and Checklists; Preparation of 

31. MIL-M-5288H, Manuals, Technical: Cargo Aircraft Loading and Offloading, Preparation of 

32. MIL-M-5920F (-5 Series), Manuals, Technical, Sample Basic Weight Checklists and Loading Data 

33. MIL-M-7700F, Manuals, Flight 

34. MIL-PRF-9854C, Manuals, Technical, Structured Repair (Aircraft)

35. MIL-M-9977K, Manuals, Technical and Checklists: Munitions/Weapons Loading Procedures, Nonnuclear and Nuclear Packages, Standard Data: Munitions Loading Procedures, Nonnuclear, Preparation of 

36. Legacy MIL-M-9977, Manuals, Technical and Checklists: Munitions/Weapons Loading Procedures, Nonnuclear and Nuclear Packages, Standard Data: Munitions Loading Procedures, Nonnuclear, Preparation of 

37. MIL-PRF-9994C, Manuals, Technical, Mobile Training Sets and Parts Task Trainers Operation and Maintenance Instructions

38. MIL-M-38384D, Manuals, Technical and Checklists: Weapon Deliver and Aircrew Procedures, Nuclear and Nonnuclear, Preparation of 

39. MIL-M-38769D, Manuals, Technical: Work Unit Code 

40. Legacy MIL-M-38769, Manuals, Technical: Work Unit Code 

41. MIL-M-38784C, Manuals, Technical: General Style and Format Requirements 

42. Legacy MIL-M-38784C, Manuals, Technical: General Style and Format Requirements 

43. MIL-STD-38784, Standard Practice For Manuals, Technical: General Style and Format Requirements 

44. MIL-PRF-38804, Time Compliance Technical Orders, Preparation of 

45. MIL-T-38804C, Time Compliance Technical Orders, Preparation of 

46. MIL-PRF-38807C, Manuals, Technical: Illustrated Parts Breakdown, Preparation of 

47. MIL-M-38807B, Manuals, Technical: Illustrated Parts Breakdown, Preparation of 

48. Legacy MIL-M-38807, Manuals, Technical: Illustrated Parts Breakdown, Preparation of 

49. MIL-PRF-38807C, Performance Specification, Manuals, Technical - Illustrated Parts Breakdown, Preparation of 

50. MIL-M-83495B, Manuals, Technical: On Equipment Set, Organization Maintenance Manuals; Detailed Requirements for 

51. Legacy MIL-M-83495, Manuals, Technical: On Equipment Set, Organization Maintenance Manuals; Detailed Requirements for 

52. MIL-PRF-83495B, Manuals, Technical: On Equipment Maintenance Manual Set Preparation 

53. MIL-PRF-87158B, Manuals, Technical, Aircraft Battle Damage Assessment and Repair

54. MIL-M-87929A, Manuals, Technical: Operation and Maintenance Instructions in Work Package Format (for USAF Equipment) 

55. Legacy MIL-M-87929, Manuals, Technical: Operation and Maintenance Instructions in Work Package Format (for USAF Equipment) 

56. DRAFT MIL-PRF-87929B, Manuals, Technical: Operation and Maintenance Instructions in Work Package Format (for USAF Equipment) 

**D.8Air Force Points of Contact**

**Lt. Col John M. Eckerly**

Single Manager

MSG/ILMP

E-mail: eckerly@pdgate01.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Gail P. Brown**

Single Manager

MSG/ILMP

E-mail: brownfg@afcpo.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Major Paul Houk**

Technical Director

MSG/ILMP

E-mail: houkp@afcpo.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Harry M. Ray**

Chief, Business Management Division

MSG/ILMP

E-mail: rayh@afcpo.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Michael L. Collier**

Chief, JCALS Implementation and TMSS Division

MSG/ILMP

E-mail: colliem@afcpo.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Bradley S. Sanders**

Chief, Data Management Division

MSG/ILMP

E-mail: sanders@afcpo.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Timothy Sierer**

Chief, JEDMICS Implementation Division

MSG/ILMP

E-mail: sierert@afcpo.wpafb.af.mil

Phone: DSN: 787-3085 or Commercial: (937) 257-3085

Fax: DSN: 787-5881 or Commercial: (937) 257-5881

**Michael L. Collier**

Chief, JCALS Implementation and TMSS Division

MSG/ILMP

E-mail: colliem@afcpo.wpafb.af.mil

Phone: DSN: 674-0840 or Commercial: (937) 904-0840

Fax: DSN: 787-5881 or Commercial: (937) 257-5881 

**Steve Holloway**

JCALS/TMSS//IETM Project Lead 

DSN 787-8215 (937) 257-8215

E-mail:  hollows@afcpo.wpafb.af.mil

**APPENDIX ENavy IETM Information**

**E.1Background**

When IETM developments began in earnest in the early 1990s NAVSEA, NAVAIR and SPAWAR, as well as many individual codes within each command, initiated exploratory IETM programs. The AEGIS community funded and developed an IETM for the Radio Communication Set (RCS), as did the submarine community for the AN/BSY-2 Sonar Set. Based on the impressive feedback as a result of these IETM deployments, NAVSEA 04 selected a mature Hull, Mechanical and Electrical equipment program to prove that legacy systems could be cost effectively migrated to Class II/III IETM status. The LM2500 Gas Turbine, prime mover for many of the Navy’s surface combatants, was selected as the candidate program. Thousands of pages of material were scanned, placed in OCR format and SGML tagged. View packages were built from the resulting SGML instance and displayed using the Info Access browser. Conversion and developmental costs were within acceptable parameters, and positive feedback was obtained through demonstration of the Gas Turbine Systems IETM within the Naval community.

To avoid potential conflicts and inefficiencies when paper technical manuals were converted to IETM format by individual NAVSEA/SPAWAR Program Managers, NAVSEA 04 was designated as the central authority for digitizing legacy data. Over the past several years, nearly a million pages of technical data, including drawings, maintenance data and operational procedures have been digitized in the form of SGML and/or raster images.  The data is stored and maintained in an SGML relational database and disseminated on CD-ROM when requested. IETM data can be viewed/printed from either Adobe Acrobat or the Dynatext browser. 

NAVAIR had a different set of criteria it wanted to meet when converting paper to SGML. NAVAIR determined it needed more of the benefits resulting from a Class III/IV IETM to support its Advanced Maintenance Environment [(AME), formerly AIMDD] concept. 

For new systems, the overall Navy strategy is to pursue acquisitions of Class IV/V IETMs when the acquisition cost model substantiates financial savings over the life-cycle of the weapon system. For the conversion of legacy systems, refer to paragraph E.3 of this Appendix.

**E.2Compatibility with ATIS**

The Advanced Technical Information Support (ATIS) system provides software that performs library functions and supports the display of all Classes of digital TMs.  Once the user selects a TM to view, ATIS locates it and then launches the appropriate viewer for that IETM.  ATIS provides a guaranteed set of hardware that enables IETMs created by different programs to be viewed on the same display hardware, minimizing the amount of unique display equipment.  Additionally, ATIS and a 240 CD jukebox will be available on Shipboard Non-tactical ADP (SNAP) terminals on ships. While it is desirable for all IETMs to be compatible with ATIS, it is recognized that there may be conditions where that is not possible or practical; for example, on IETMs where:

· Software programming is integrated into the weapon system operating software.

· The ATIS software constraints and/or restrictions severely impact on a program or user or preclude a specific IETM implementation (cognizant managers should be aware of those restrictions and ensure that there are no negative impacts from them).  

If for any reason the IETM chosen is not ATIS compatible, particularly those integrated into the weapon system or equipment, the program assumes the responsibility for roles that ATIS currently fills and must ensure that all potential legitimate users have access to the data.  Directions on making IETMs ATIS compatible are found on the WWW at http://navysgml.dt.navy.mil/ ietmdeve.html or by contacting the ATIS Help Desk identified in paragraph E.11 of this Appendix.

**E.3Data Conversion Efforts**

Raster TMs have two mature conversion processes in place at NSWC, Philadelphia and the Naval Air (NAVAIR) Technical Services Facility (NATSF).  Any legacy hard-copy TM should be referred to these sites for conversion.  Conversion is already under Government contract and programs should not attempt to convert legacy TMs into this raster format other than at these conversion sites.  In many cases, NSWC, Philadelphia and NATSF may be funded to convert the TMs into raster format.  If conversion funds have not been allocated, NSWC, Philadelphia and NATSF will be able to quote the costs of converting the TMs (Table E-1).

**Table E-1.  Cost of Conversion**

**Interactivity**

**Description**

**Class**

**Savings**

**Cost/Page**

****

Low

Raster scanned with Indexing

I

Wt/Space

$ 2

Moderate

Intelligent (printable)

II

Wt/Space, reduced access time

$ 2-10

Good

Interactive to user (printable)

III

Wt/Space, reduced access time, reduced data set

$10-25

High

Interactive to user (objects)

IV

Wt/Space, reduced access time, minimized data set

$40 - 100+

Full

Interactive to user and associated systems

V

Training Fleet/Data Maintenance Integration

$ 200+

NAVSEA, NAVAIR, and SPAWAR have scanned the majority of existing hard-copy TMs. NSWC, Philadelphia or NATSF can assist the program in determining whether required TMs have already been converted into this Class I/II format and whether the configuration of the Class I/II IETM is current.  These scanned images are also used as the source data for Technical Manual Publish On Demand System (TMPODS) that provides hard-copy manuals without the need to store excesses or dispose of obsolescent material.

Step 1: Contact NSWC or NATSF to initiate Class I conversion process.

Step 2: NSWC/NATSF determine whether hard-copy TM is a raster candidate (e.g., front matter indexing in basic and changes, page quality, security classification, size of the TM, and whether color is used in the TM all determine suitability for scanning).

Step 3: If the TM is not a Class I/II candidate, decide whether conversion of the TM to a higher, more costly IETM Class is justified.

Step 4:NSWC/NATSF determine if funding is available to support the conversion.

Step 5: If not, NSWC/NATSF provide the program with an estimate of conversion costs.

Step 6: Determine whether the conversion costs are acceptable.

Step 7: If the conversion costs are not acceptable, evaluate the costs and benefits of converting to a more interactive Class of IETMs.

Step 8: If the costs are acceptable, send the TMs and necessary funding to support conversion.

Step 9: NSWC/NATSF will return the converted TM on the agreed upon media.

Step 10: Procure ATIS software from NAVSEA Logistics - Indian Head Detachment and ensure that appropriate display hardware exists where IETM is to be used.

**E.4Navy IETM Display Equipment**

Where a common infrastructure, such as the Naval Tactical Command Support System (NTCSS) exists or is being formed, that manager will be responsible for ensuring the availability of items under his or her cognizance.  When programs decide not to use the common infrastructure or develop IETMs that will not effectively play on the common architecture, the program remains responsible for display equipment availability until another activity assumes full responsibility, including funding.  With the exception of NTCSS, there are also no current mechanisms that require programs that share common work places to coordinate the use, distribution, and support of IETM display hardware.  It is imperative to do so in order to minimize the costs associated with IETM display hardware support, as well as minimizing other impacts (e.g., space onboard ship).  These logistic support issues must be evaluated and addressed to ensure the effective availability of the IETMs provided by the minimum number of units at reasonable costs.

Display equipment that is to be part of the NTCSS infrastructure (SNAP LAN) will follow the procedures established by NTCSS (see paragraph E.11 of this Appendix for the appropriate points of contact).  These procedures include certification of display hardware as to its hardware and software compatibility on the LAN.  NAVMASSO and NAVSEA Automated Data Systems Activity (SEAADSA) support NTCSS in performing the certification process.  Once certified, NTCSS will manage the sparing, LAN and warranty management involved with the displays.  NTCSS has existing display hardware acquisition contracts it can make available if needed.  NAVAIR has also released a performance specification for PEDDs.  See paragraph E.11 of this Appendix for the appropriate points of contact.

**E.5Development Resources**

A copy of the Navy IETM Process Plan (S0005-AD-PRO-010), signed out by NAVSEA and SPAWAR in December 1995, is available at http://calsric.crane.navy.mil/refinfo.htm. This document is intended to instruct and guide programs in the development of IETMs in a way that provides for their life-cycle use and maintenance within the Department of the Navy infrastructure. The Navy IETM Process Plan is to be used by NAVSEA and SPAWAR programs in the acquisition of new, or conversion of existing hard-copy, technical manuals into IETMs. 

**E.6Classroom Instruction**

NSWC, Port Hueneme regularly provides classroom instruction on both the east and west coasts, for the acquisition and development of Navy technical manuals, including IETMs. Consult paragraph E.11 of this Appendix for the appropriate points of contact.

**E.6.1Authoring Instructional Materials (AIM)**

AIM is a software application implemented in FY94 by the Chief of Naval Operations (OPNAV N75), to streamline the development, maintenance, and management of formal training course materials.  These training materials draw heavily on and refer extensively to technical data included within technical manuals.  The creation of this data in or conversion of this data to digital formats for interactive view and use through electronic devices introduces the potential for substantial savings in technical data maintenance and training development and substantial benefits from more efficient and effective training.  It also mandates the need for concurrent development of products to ensure that all requirements can be filled from the new digital data set.  AIM provides a critical automated linkage between formal course material and IETMs.  The following paragraphs describe the AIM program and discuss the interface requirements between AIM and IETMs.

**E.6.1.1Introduction to AIM**

AIM is designed to automate many elements of the ISD process and to ensure uniform formatting and specification compliance of all required products.  It provides for a highly effective automated process which includes the course design, development, surveillance, maintenance, and production of formal training materials.  AIM was developed by the U.S. Navy and now has more than 200 systems in use by Naval Education and Training Command (NAVEDTRACOM), PEO, DRPM, SYSCOM and other Government activities with responsibility for curriculum development.  AIM produces both immediate and long-term benefits by reducing the time and cost to develop and maintain training materials throughout their life-cycle; users have reported an average time-savings of 40 percent for curriculum development and maintenance.

AIM optimizes instructional material development processes and standardizes training products by:

· Automating the format and production standards of MIL-HDBK-29612 and NAVEDTRA 130/131

· Providing specialized software to design, develop, and maintain training materials, including the conversion of existing training materials to proper relational database management system (RDBMS) products

· Supporting configuration management of graphics and their integration with text

· Connecting AIM data with other training related databases (e.g., LSAR, test/test item banks, training administrative data, technical data) to streamline the exchange of training material information

· Interfacing with Defense Printing Service (DPS) offices to enable automated publishing and printing of training materials

· Supporting the DoD CALS standards

New development or revision of training material production typically occurs at:

· One of the Navy's centralized training material development units

· A Navy training activity

· A contractor facility, usually as a part of a SYSCOM hardware contract

The decision to use in-house resources or to acquire the curriculum is a Training Support Agent (TSA) responsibility.

**E.6.1.2AIM System Description**

The AIM System provides a menu-based interface to SMEs and training materials for developers.  By guiding the user through menus, it allows the user to develop, convert, maintain, and manage training materials.  The menus provide requests for information for background and support of training materials, as well as prompts for the training material itself.  This interactive, menu-driven approach to develop and maintain training materials provides the user with much faster and more consistent data entry than manual methods.

The AIM System uses an RDBMS for power and flexibility in organizing and accessing the data and the complex relationships between each element stored.  It simplifies the tasks of locating the reusable data units and can automatically cross-reference data across several training material products.  Life-cycle surveillance and maintenance is achieved with a menu-driven user interface and automated links among the various AIM modules.  The user is notified of all potential impacts of maintenance actions to all other related training materials, thus ensuring that each related item affected by a change is kept up-to-date.  Three versions, AIM, AIM I, and AIM II, currently comprise the overall AIM System and provide compliance with current Navy training policy.

**E.6.1.3AIM and AIM I**

Both AIM and AIM I support the development of Personnel Performance Profile (PPP) based training materials.  NAVEDTRA 131 (Personnel Performance Profile Based Curriculum Development Manual) provides detailed guidance on this methodology. PPP was originally designed to develop training programs that teach operation and maintenance of hardware systems or equipment. (This methodology is advantageous where equipment or procedures are subject to frequent update or change.)  PPP-based training materials rely heavily on references to technical manual data.  These structural references are inserted in the curriculum in discussion points of the lesson plans of the Instructor Guide.  The Trainee Guide typically also uses technical data references on Instruction Sheets.

AIM I transitions the PPP/Training Path System (TPS)-based AIM into the graphic user interface (GUI) environment.  AIM I is a MS WindowsTM based product that takes advantage of user friendly software and promotes a “look-and-feel” that is comfortable and familiar to nearly all computer users.  Training materials that are developed and maintained in accordance with MIL-HDBK-29612 and NAVEDTRA 131 will be supported by AIM I.  Output products of AIM I are:

(Training Project Plan (TPP)•   PPP Table

(Curriculum Outline of Instruction (COI)•   TPS 

(Course Master Schedule (CMS)•   Lesson Plan (LP)

(Training Course Control Document (TCCD)•   Trainee Guide (TG)

(Instructional Media Materials (IMM)•   Test Items

**E.6.1.4AIM II**

AIM II supports the development of task-based curricula.  The task-based ISD process was designed to develop training programs that teach performance of a job or function where operation or maintenance of the hardware is usually incidental or secondary to actual performance of the job.  Task-based curriculum uses information from technical manuals even more extensively than PPP training.  Task-based materials not only used structural references in related instructor activities and TG Sheets, but frequently incorporate actual portions of the material (e.g., blocks of text or graphics) directly into the training materials.  NAVEDTRA 130 (Task Based Curriculum Development Manual) provides details on this methodology.

**E.6.1.5AIM-IETM Automated Interface**

The automated interface with IETMs implemented in AIM I Rel 2.0 enables the training material developer to browse the IETM from within AIM during LP and TG preparation and create automated links in the database from specific LP Related Instructor Activities (RIAs) and TG Sheets to particular points in the IETM.  During surveillance of training materials, the automated interface provides major time savings for curricula staff by defining precise differences between the version of the IETM currently used in training materials and new versions.  It then pinpoints all of the courses (down to the RIA and TG sheet level) in which IETM elements changed or were deleted in the new IETM version.  This reduces the curriculum surveillance task from literally thousands of IETM elements to be manually checked to less than 100 elements based on the analytical tools built into AIM I Rel 2.0.

**E.6.1.6AIM Implementation**

All programs interested in implementing AIM should contact the Naval Air Warfare Center Training Systems Division (NAWCTSD).  The Electronic Training Environment (ETE) Program of NAWCTSD also administers the installation of automated electronic classrooms and learning resource centers in Navy activities.  Refer to paragraph E.11 of this Appendix for NAWCTSD points of contact.

**E.7Training Integration Management Software (TIMS)**

**E.7.1Background**

TIMS is being developed as part of a larger project addressing the needs of an automated classroom developed by NAVSEA.  With the advent of new electronic media replacing paper technical manuals and the new information technologies creating opportunities to enhance training and maintenance processes, it became necessary to develop a common graphical user interface (GUI) that makes the efficient management of electronic training materials.  TIMS allows schoolhouse personnel to link, deliver, and manage a variety of electronic media.  Refer to paragraph E.11 of this Appendix for points of contact.

TIMS is designed to work in a Microsoft WindowsTM environment bringing together various Windows-compatible software applications to ensure efficient link and delivery of electronic training materials.  It can be used in a stand-alone configuration or as part of a network configuration.  The application of this software interface creates costs savings by reducing instructor preparation time and life-cycle maintenance.

**E.7.2Objectives**

The primary objective of TIMS is to enable curriculum developers and instructors to link and deliver a variety of electronic course materials.  By bringing a greater variety of more readily accessible teaching materials into the classroom, TIMS should enhance learning.  The TIMS GUI enables instructors to more efficiently perform these various tasks, while conforming to established procedures.

**E.8Software Licensing**

SEA 04TD has considerable experience in qualifying and licensing IETM related software tools for wide scale application.  NAVSEA (04TD) has agreed to act as the software clearinghouse for programs seeking advice and assistance concerning licensing issues. Refer to Table E-2 for a brief summary of existing license agreements.

**Table E-2.  Licensing in Place**

**CLASS**

**NOMENCLATURE**

**STATUS**

I

TMS View Director

500 applications in Fleet.

Provided with ATIS

II

TMS Master View

20,000 pages converted for PIMS.

20 viewers currently licensed.

License for PHALANX Close-In Weapons System being negotiated

II

Electronic Book Technology

Licensed for all Programs at NSWC, Philadelphia and NSWC, Pt. Hueneme.

II

Adobe Postscript/Alliant

3,000 pages converted by VLS.  Fifteen conversion license available for NSWC, Pt. Hueneme use.

III

InfoAccess

Licensed for any TAD Program at NSWC, Pt. Hueneme.

III

IADS 

Government Owned 

IV

AIMSS

Licensed for AEGIS Fire Control Radar Transmitter

**E.8.1Navy CALS DTD Repository**

The Navy CALS Coordination Office tasked the David Taylor Model Basin (DTMB) (Naval Surface Warfare Center, Carderock Division) as the central site for registration, testing, and distribution of Department of the Navy (DoN) DTDs (and FOSIs, where applicable). NSWC-CD is only responsible for DTDs and FOSIs developed in compliance with MIL-PRF-28001 and MIL-PRF-87269 SGML. NSWC-CD established the Navy CALS DTD Repository to:

· Minimize duplicative DTD investments

· Register DTDs and tag sets

· Perform technical testing and approval

· Coordinate functional testing of Navy DTDs and FOSIs

DTDs are complex SGML constructs that can be costly to develop. NSWC-CD maintains an electronic repository of DTDs and SGML tags and constructs for re-use by Navy activities in implementing digital technical manual applications.  NSWC-CD provides technical support to Navy activities for application of digital interchange technology and standards in support of the DoN CALS Program.  NSWC-CD is also the Navy custodian for CALS data interchange specifications and has extensive experience in CALS interchange specifications for engineering data, technical manuals, and IETMs.  

E.8.2Available

The following Navy DTDs can be retrieved from the Navy CALS DTD Repository:

· MIL-M-38784C - Manuals, Technical; General Style and Format Requirements

· MIL-M-81927 - Manuals, Technical; General Style and Format of (Work Package Concept).

· MIL-M-81928 - Manuals, Technical: Aircraft and Aeronautical Equipment Maintenance, Preparation of (Work Package Concept)

· MIL-M-81929 - Manuals, Technical: Illustrated Parts Breakdown, (Work Package Concept); Preparation of 

· MIL-PRF-87269, Interactive Electronic Technical Manuals DataBase (IETMDB) DTD

· NAVSEA C2 Revision D -  Naval Sea Systems Command Electronic Technical Manual Class 2, DTD 

The following FOSIs are undergoing development in the Navy and can be accessed through the Repository:

·  NSWCCD-SSES Engineering Operational Sequencing System (EOSS DTD) 

· ArborText Adept Series FOSI 

· INSO DynaText Style Sheets

· Fleet Technical Support Center Planned Maintenance System (FTSC PMS DTD) 

· INSO DynaText Style Sheets

To facilitate rapid distribution of information, the CALS DTD Repository can be accessed via the Internet, the WWW, anonymous FTP, e-mail, and U.S. Mail.  The information provided on the NSWC-CD WWW server includes:

· Approved Navy SGML DTDs and FOSIs

· Navy SGML Baseline Tag Set

· Navy CALS Reports and Technical Memoranda 

· CALS Standards Information 

· IETM Information (Standards and current research efforts)

· Links to other pertinent on-line repositories

· Information on emerging and de facto standards

**E.9Access to the  Navy DTD Repository**

**E.9.1World Wide Web (WWW)**

The WWW provides the most “user-friendly” connection to the Repository.  WWW pages guide the user through hyperlinks to desired information.  The WWW URL address for the Navy CALS DTD Repository is:

· http://navycals.dt.navy.mil/dtdfosi/repository.html

**E.9.2Anonymous FTP**

The DTDs installed in the Navy DTD Repository may also be retrieved via the “anonymous guest” FTP protocol.  The pub directory contains the files associated with the Navy CALS DTD Repository.  The Internet address for the FTP Repository is:

· ftp://navycals.dt.navy.mil/pub/dtd/

**E.9.3E-mail**

Information in the Navy CALS DTD Repository may be requested by an e-mail message.  The request will automatically be sent to the appropriate person and the requested information will be sent to register electronically. The e-mail address is:

· webmaster@navycals.dt.navy.mil

**E.9.4Telephone or Mail**

Requests may also be sent to DTMB either by phone or U.S. mail at:

Advanced Information Systems Branch, Code 183

Naval Surface Warfare Center 

Headquarters, Carderock Division

Bethesda, Md.  20084-5000 

Telephone:  (301) 227-3348

DSN 287-3348

**E.10CD Guidelines**

For compatibility with ATIS systems, network, and jukebox, CDs should be tested at NAVSEA Logistics - Indian Head Detachment, prior to replication.  The Navy CALS website, http://navycals.dt.navy.mil/, contains information related to ATIS and CD ROM publication. Refer to the following paragraph for points of contact.

**E.11Points of Contact**

The following personnel can be used by contractor and Government programs alike in seeking advice in the issues and processes associated with comparing the features of each of the listed IETM software packages.  

**Table E-3. Available Subject Matter Experts**

**CLASS**

**NOMENCLATURE**

**STATUS**

**PHONE**

****

I

TMS View Director (ATIS)

Andy Kelly SEA 04TD

703 602-1060 

II

TMS Master View

Chester Ellswick NSWC-Louisville

502 364-6406

III

IADS

Rich Gramly, Army

205 876-8112

II

Adobe Postscript/Hercules

Jim Moses NSWC-PHD

805 982-8170

III

Info Access

Marty Cohen NSWC-CD-SSES

Jim Moses NSWC-PHD

215 897-1233

II

Electronic Book Technology

Marty Cohen, NSWC-CD-SSES

805 982-8170

IV

AIMSS

Ramona Braun NSWC-PHD

805 982-0746

***Questions or Comments on the Navy IETMPP***

Wayne Honea  -  NSWC-PHD (5B20)

Chair of Navy Technical Manual Working Group

Internet: honea_wayne@om.nswses.navy.mil

DSN 551-2971   (805) 982-2971

***Digital Data Specifications and Standards***

***MIL-PRF-87269***

Mr. Joe Fuller  -  NSWC-CD (Code 182)

Internet: fuller@oasys.dt.navy.mil

DSN 287-1358   (301) 227-1358

***MIL-PRF-28001***

Mr. Joe Garner  -  NSWC-CD (Code 183)

Internet: garner@oasys.dt.navy.mil

DSN 287-1533   (301) 227-1533

***DTD Registration and Guidance***

Mr. Joe Garner  -  NSWC-CD (Code 183)

Internet: garner@oasys.dt.navy.mil

DSN 287-1533   (301) 227-1533

Status of Specification and Standards Waivers 

***NAVSEA***

Mr. Mickey Ander  -  SEA 04TD (Code 04TD31)

Internet: ander_mickey@hq.navsea.navy.mil

DSN 332-8700   (703) 602-8700

***NAVAIR***

Mr. Tom Martin  -  NATSF (Code 3.3D)

Internet: thomas_martin@natsfgw.natsf.navy.mil

DSN 442-2924   (215) 697-2924

***Tracking of IETMS/CD ROMs***

***NAVAIR***

Mr. Rich Rizzo  -  NATSF (Code 3.3.1.5)

Internet: richard_rizzo@natsfgw.natsf.navy.mil

DSN 442-5302   (215) 697-5302

***NAVSEA/SPAWAR***

Ms. Carrie Ganzman  -  NSWC-PHD (Code 5B62)

Internet: ganzman_carrie@om.nswses.navy.mil

DSN 551-3141   (805) 982-3141

Mr. Bob Uehlein  - NSWC-PHD (Code 5B32)

Internet: uehlein_bob@om.nswses.navy.mil

DSN 551-2964   (805) 982-2964

***MEDIA Identification Numbers (e.g. CD  IDs)***

***NAVSEA/SPAWAR***

Mr. Bob Uehlein  - NSWC-PHD (Code 5B32)

Internet: uehlein_bob@om.nswses.navy.mil

DSN 551-2964    (805) 982-2964

***NAVAIR***

Mr. Rich Rizzo  -  NATSF (Code 3.3.1.5)

Internet: richard_rizzo@natsfgw.natsf.navy.mil

DSN 442-5302   (215) 697-5302

***IETM Identification Numbers***

***NAVSEA/SPAWAR***

Ms. Tona******Martinez  - NSWC-PHD (Code 5B61)

Internet:  martinez_tona@om.nswses.navy.mil

DSN 551-3168    (805) 982-3168

***NAVAIR***

Mr. Rich Rizzo  -  NATSF (Code 3.3.1.5)

Internet: richard_rizzo@natsfgw.natsf.navy.mil

DSN 442-5302   (215) 697-5302

***Technical Manual Contract Requirements***

***NAVSEA/SPAWAR***

Mr. Alan Hatmaker  - NSWC-PHD (Code 5B61)  

Internet: hatmaker_alan@om.nswses.navy.mil

DSN 551-3159    (805) 982-3159

***NAVAIR***

TMCR Guidance Document available from NAVAIR TM Working Group:

Debby Young - Chair  NAWCWD (Code 3.3.1)

Internet: young@tecnet1.jcte.jcs.mil

DSN 351-6576    (805) 484-6576

***NAVSEA IETM Software Licensing Coordinator***

SEA 04TD - George White

Internet: white_george@hq.navsea.navy.mil

DSN 332-8700   (703) 602-8700

***Paper or Electronic TPDRs/TMDERs***

***NAVAIR***

NATSF Code 3.3.1.2- Attention: John Malloy

Internet: John_molloy@ natsfgw.natsf.navy.mil

DSN 442-5307  (215) 697-5307

***NAVSEA/SPAWAR***

Mr. Mike Snavely  - NSWC-PHD (Code 5B30)

Internet: snavely_mike@om.nswses.navy.mil

DSN 551-2970 (805) 982-2970

***TIDES Electronic TMDERS forwarded to:***

***NAVSEA/SPAWAR***

tides@log04.nswses.navy.mil

***IETM Electronic Display Requirements***

***NAVAIR (PEDDs)***

Mr. John Baranowski  - NAVAIR (Code 3.6.4) Processes Branch

Internet: baranowskijj.jfk@navair.navy.mil

DSN 664-3090 x4183   (703) 604-3090 x4183

***NAVSEA***

Mr. George White  -  NAVSEA (Code 04TD34)

Internet: white_george@hq.navsea.navy.mil

DSN 332-8700   (703) 602-8700

***ATIS/IETM Management Interfacing***

***NAVSEA/SPAWAR***

Mr. Andy Kelly  - NAVSEA Logistic Indian Head Det. (Code 092)

Internet: kelly_william@hq.navsea.navy.mil

DSN 332-0076    (703) 602-0076 x202

***NAVAIR***

Mr. John Baranowski  - NAVAIR (Code 3.6.4) Processes Branch

Internet: baranowskijj.jfk@navair.navy.mil

DSN 664-3090 x4183   (703) 604-3090 x4183

***ATIS Help Desk***

301-743-4911

***ATIS IETM.NDX Web Location***

http://navysgml.dt.navy.mil/repository.html

***NTCSS (SNAP Network) Interfacing***

Mr. Pete Davenport  -  Shipboard Non-tactical ADP (SNAP) Program Office

Internet: davenpop@smtp-gw.spawar.navy.mil

(703-602-0814)

***NALCOMIS Functional Requirements***

Mr. Bill Booth  -  NAVAIR (Code 3.6.2) Logistics Information Systems Division

Internet: boothwc.jfk@navair.navy.mil

DSN  664-3090 x4126    (703) 604-3090 x4126

***Automated Electronic Classrooms***

Mr. Ben Aaronson – NAWCTSD

Internet:  AaronsonBA@navair.navy.mil

DSN 960-  (407) 380-

***Training Integration Management Software***

Mr. Tim Tate  -  NAVSEA (Code 042)

Internet: tate_timothy@hq.navsea.navy.mil

DSN 224-5438  (703) 614-5438

***Authoring Instructional Materials (AIM)***

Mr. Alan Litz - NAWCTSD

Internet: LitzAD@navair.navy.mil

DSN 960-8607   (407) 381-8607

**APPENDIX FArmy IETM Information**

*Note: The Army classifies any manual less than a Class III as an ETM. This notation has been preserved for this appendix only.*

**F.1IETM Strategy**

The U.S. Army IETM Strategy is to identify, develop, and fund IETMs that contribute the greatest potential for cost saving efficiencies while improving the mission readiness of the weapon and C4I systems in Force XXI. The Army's goal is to establish a management structure and evaluation criteria that will accelerate IETM implementation to derive maximum benefits from: 

· Reduced weapon system maintenance costs and time

· Increased weapon system availability

· Reduced training costs and course lengths

· Improved repair technician performance, quality, and efficiency

· Reduced costs to author, deliver, manage, and update TM information

· Capability to transmit to remote locations.

**F.2Digital Conversion Efforts**

The Army’s electronic technical manual effort began when the Deputy Chief of Staff for Logistics (DCSLOG) initiated an ETM initiative in the 3rd and 4th Infantry Divisions (ID) (Mechanized) and their Corps trace. With nearly 30,000 maintenance publications in circulation, this initiative represents an entirely new methodology with which technical information is configured, distributed, accessed and updated.  ETMs provide the Army, civilian, and contract maintenance technicians with a CALS compatible representation of the instructions for installation, operation, maintenance, training and support of weapon systems, weapon systems components, and support equipment.  Users have access to technical manuals, technical bulletins (TB), supply bulletins (SB), lubrication orders (LO), maintenance work orders (MWO) and other maintenance documents electronically via compact disk-equipped desktop or portable personal computers (which include notebooks and cruisepads). 

The digital conversion process involves scanning the paper TM pages and applying optical character recognition software to create a portable document file (PDF). Once in the PDF format, hypertext links are applied to enable soldiers to maneuver through the electronic book faster than through the paper version. It allows for quick access to specific pages, figures, tables, and other related TMs. These files are then stored on CDs where they can be accessed by an Adobe Acrobat that resides on each CD, making it usable on any computer with a CD reader. In addition, ETMs are configured by weapon system and include all related TMs for ordinance and communication sub-systems. The ETMs are to be distributed using the U.S. Army Publishing Agency (USAPA) system. 

The current Army strategy is to continue to print paper maintenance manuals and paper changes for unit-level and higher pubs for those who want them. In the future, when CDs and other media are more accepted, paper may be ended or in limited availability for 20 manuals and higher.

Operator manuals will continue to be printed on paper, even if they are part of an electronic manual. 

Two types of CDs will be produced. One will have major end items or weapons systems, including pubs on their components. A second type will cover common-use equipment or general subject matter.

ETMs are only the first step towards automating the Army’s maintenance facilities. The evolution is towards IETMs, which are already in the process of development by several agencies throughout the Army. The IETM strategy is based on the assumption that technical data acquired for new and major product improvements will be in digital format. The conversion effort will utilize the editable word processing file which is a by-product of the PDF conversion efforts.

**F.3IETM Display Equipment (SPORT)**

Since Army ETMs reside on a platform-independent CD, several different computer options can be used to meet user display requirements. The Logistics Integration Agency is currently testing the program using both notebook computers and wireless high frequency local area networks (CruiseLANs). The CruiseLAN system allows several mechanics to simultaneously access different ETMs located on a central server, utilizing individual wireless dumb terminals (Cruise Pads) (Figure F-1).

Through a prototype software interface, known as Electronic Technical Manual – Interactive (ETM-I), mechanics can also electronically transfer parts request information and work order data between the ETM platform and the Unit Level Logistics System (ULLS) and the Standard Army Maintenance System (SAMS). The interface not only cuts down on extensive data entry, but eliminates transposition errors that could lead to faulty requisitions and excess parts.

ETMs are currently in use at Fort Hood, Fort Carson, Fort Stewart, Fort Campbell, the National Training Center, and a few National Guard sites. There have been 54 CruiseLAN systems and almost 1000 multimedia computer notebooks fielded in support of the ETM program. The type of platform used varies by location, as the hardware was tailored to the individual units. To date, several CDs have been distributed to the selected units. In the coming months, CDs will continue being distributed to units at the rate of several new weapon systems per month.

**F.4Development Resources**

MIL-STD-2361 establishes SGML requirements for use in Army digital publications. Within the standard, Army publications SGML requirements are separated by publication types. There are specified sections for administrative publications, training and doctrine publications, and technical and equipment publications. This initial publication of the standard contains the SGML requirements for Army Technical Manuals developed in accordance with the functional requirements contained in MIL-STD-40051 (Technical Manual Preparation). The SGML requirements for technical equipment publications are applicable for the development, acquisition, and delivery of ETM/IETMs. Specific ETM/IETM functionality (e.g., display and database requirements), currently contained in MIL-PRF-87268 and MIL-PRF-87269 will be included in future revisions to MIL-STD-2361. Subsequent versions of MIL-STD-2361 will contain the SGML requirements for all other Army publications, developed in accordance with their respective functional requirements documents.

Additionally, the Guide to Contracting for Technical Information, AMC pamphlet 25-35, can be downloaded from http://www.amc.army.mil/amc/ci/pub_index.htm. The pamphlet contains language for inclusion when preparing a SOW to acquire an ETM/IETM from a contractor. Specifically, unless you are acquiring a Class III IETM or higher is being acquired, the SOW must require the contractor to deliver the technical manuals in PDF. PAM 25-35 also requires the ETM/IETM contractor to develop a quality assurance plan in accordance with ISO 9001. In doing so, the contractor should address validation and verification of the ETM/IETM, including the furnishing of display equipment during Validation & Verification (V&V).

To keep up with the latest in Army ETMS/IETMs, subscribe to the Army’s ETM Bulletin at http://www.logsa.army.mil/pubs.htm.

The USAPA Web site, http://www.usapa.army.mil, allows Army personnel to electronically order many publications pertaining to Army information products.

The LOGSA IETM Management Plan, dated April 1997, is available from Mr. John Zibell (jzibell@logsa.army.mil).  The IETM Management Plan is separated into three sections:

· Section I, Management – Defines the actions required to establish and assign ETM/IETM related responsibilities to the Army commands, activities and Project Managers. It also defines the actions to charter a body of SMEs for the coordination of ETM/IETM issues, establish teams to review ETM/IETM related products/tools and provide recommendations.

· Section II, ETM/IETM Related Policy, Guidance and Development Procedures for Army and Tri-Service Initiatives – Defines the capabilities that are or will be available to aid technical publication and weapon system managers in preparing and procuring ETMs/IETMs.

· Section III, Funding Requirements – This section was to define the Army’s efforts to identify, develop and fund for ETM/IETM efforts that contribute the greatest potential for cost saving efficiencies while improving mission readiness. However, only a list of Army IETM candidates is included in this section.

The Army Doctrine and Training Digital Library (ADTDL) can be accessed at http://155.217.58.58. The site provides a globally accessible digital repository of Army doctrine, training knowledge sets, and interactive applications to support the training of individuals and units.

The site also supports normal library functions, maintains a library information catalog, provides a help desk and bulletin board, and transmits requested information.   Additionally, it offers information such as doctrinal literature (e.g., field manuals), that have been digitized and converted to HTML format. In the future, the library will be expanded to include:

· Multimedia

· Interactive courseware

· Training Support Packages (TSP) containing structured situational templates for planning, preparing for, and conducting training

· Information relating to Training Aids, Devices, Simulations and Simulators (TADSS) available to support training

· Unprocessed After Action Review (AAR) information from Combat Training Center (CTC) unit rotations, major exercises, and operational missions

· Lessons learned derived from processed and analyzed AAR information resident in the Army Historical Archives System (AHAS)

**F.5Software Licensing**

The Army uses Acrobat Reader and the IADS browser as delivery vehicles for their ETMs.

**F.5.1Interactive Authoring and Display System (IADS)**

The IADS application provides an authoring environment for interactive and integrated electronic documents. It is part of a MICOM initiative designed to reduce or eliminate the massive duplication of paper inherent in the current process throughout DoD. IADS contains several software modules designed to support the development, sustainment, and navigation of CALS compatible hypertext documents. The software is currently in use world-wide.

IADS allows users to build or edit documents using SGML tags and embed or reference graphics using the CALS Raster CCITT Group 4 or Vector (Computer Graphics Metafile - CGM) files. Several industry graphics standards are supported as well. IADS is designed as a Class III environment, but is capable of doing Class V diagnostic and expert system integration. It also allows Class I and II environments for static documents. A database application for electronic Repair Parts and Special Tools List (RPSTL) or IPB database is also included in the software suite.

While the original concept of IADS was to support IETMs developed within the U.S. Army, the robust nature of the environment has allowed all services to use IADS in a variety of applications.

The tool is Government-owned.  Although the software is free, there is currently an optional $7,500 fee for training and in-depth technical support.   In addition, the user will receive all software and documentation upgrades as well as access to the IADS Help Line.

**F.6Army SGML Registry and Library (ASRL) for DTDs**

The USAPA has established the Army SGML Registry and Library (ASRL), which provides approved DTDs based on MIL-STD-2361 and MIL‐STD-40051 constructs for reuse by Government activities and their contractors.

DTDs are complex SGML constructs that can be costly to develop and will probably involve a long lead time for approval.  The ASRL has been established to:

· Minimize duplicative DTD investments

· Register DTDs and tag sets

· Perform technical testing and approval

· Coordinate functional testing of DTDs and FOSIs

The WWW site address for the ASRL is:  http://www.asrl.com/

DTDs currently available are (as part of MIL-STD-2361 and MIL-STD-40051):

· Technical Manual Assembly Information Chapter (Production)

· General Information Chapter (GIM)

· Maintenance Information Chapter (MIM)

· Operator’s Information Chapter (OPIM)

· Repair Parts and Special Tool Lists Information Chapter (RPSTL) (PIM)

· Aircraft Operator’s Instruction and Checklist Information Chapter (PILOT-OPIM)

· Preparation of Aircraft for Shipment Information Chapter (SHIPIM)

· Supporting Information Chapter (SIM)

· Troubleshooting Information Chapter (TIM)

It should be noted that MIL-STD-2361 and 40051 are presently geared for page-oriented IETMs.  However, with a minimum of creativity, these DTDs can be modified for use with data-oriented IETMs.

**F.7Army Points of Contact**

**Technical Pubs**

Ms. Judy Brissom

DSN 645-9843  (256-955-9843)

jbrisson@logsa.army.mil

Dean Despelder

DSN 645-9844 (256-955-9844).

Ddespeld@logsa.army.mil

Mr. John Zibell

DSN 645-9833 (256-955-9833)

jzibell@logsa.army.mil

**IADS Ordering and Information**

Mr. Rich Gramly

DSN 746-8112  (205-876-8112)

rgramly@redstone.army.mil

**ApPENDIX GUSMC IETM INFORMATION**

**G.1Introduction**

The Marine Corp IETM acquisition strategy closely mirrors that of the Army:  purchase SGML but deliver digital data in PDF.  This is in part due to the similar operational mission profiles shared by the two services that result in an increase in the amount of shared equipment. Since the Army is the life-cycle manager on the majority of the shared equipment and therefore responsible for the technical publications, the Marine Corps did not want to choose a different and possibly incompatible digital data delivery and sustainment system.

**G.2USMC Policy**

In FY99, the Marine Corps plans to issue a new acquisition and policy guidance document on IETMs. (This document may be a chapter or appendix to the USMC’s overall acquisition strategy.)  The draft version of the USMC’s, *Integration of Information Technologies into the Marine Corps Supply and Maintenance Infrastructure,*will address the following:

· Define how the levels of IETMs can support the diverse types of equipment requiring maintenance in the Marine Corps

· Identify how IETMs should be integrated into the business practices within the maintenance community

· Define how the integration of an IETM can support a simplified user interface and thereby streamline data input

· Identify interfaces between IETM information technologies (AIT, TMDE, onboard vehicle systems) and logistics systems (ATLASS, TC-AIMS II)

**G.3Digital Conversion Efforts**

For the past few years, MARCORSYSCOM (PSD) has been converting many USMC legacy documents to PDF format. At the end of FY98, the Marine Corps have converted nearly 2,200 technical publications for online distribution. These documents are available at http://www.pubs.ala.usmc.mil, which is a Marine Corps Web site hosted by the Marine Corps Logistics Base in Albany, Georgia. Access is restricted to those personnel trying to access the site with a .mil IP address. For SGML source data, the Marine Corps is a heavy user of the IADS software (see Appendix A). IADS documents can be viewed over the Web with specialized third party software (Citrix Winframe). Interested parties should contact Greg Ransom (ransomga@quantico.usmc.mil) for more information. Efforts are currently underway to make IADS capable of interpreting XML files. Additional USMC efforts include an IETM built for the TAOM program, which has used MediaLynk, a Class III software program from PRC/Litton.

**G.4Development Resources**

Potential USMC IETM developers should first check with MARCORSYSCOM (PSD) prior to committing resources to IETM development. MARCORSYSCOM (PSD) will provide guidance to the Program Manager for the acquisition of digital data and check with the proper Army personnel if the original technical publication was obtained from the Army. MARCORSYSCOM (PSD) will also make recommendations to the Program Manager for the type of ETM/IETM to support the weapon system/equipment. Keep in mind, ETM/IETM data procured must be compatible with Government furnished software (IADS). IADS can be provided to defense contractors by sending a request to:

Commander USAMICOM 

ATTN: AMSMI-MMC-LS-SA 

Redstone Arsenal, AL 35898-5238 DSN 746-4024

or

Downloaded from the Web at http://darkside.redstone.army.mil/

**G.5USMC IETM Acquisition Policy and DTD Guidance**

The Marine Corps philosophy for IETM acquisition is to procure SGML marked up in accordance with MIL-PRF-28001 or MIL-D-87269. In practice, the SGML should be tagged to the IADS DTD using the IADS Authoring system to ensure the resulting technical information can be displayed using the IADS Reader. The IADS DTD is available by sending an e-mail to gramly-rg@redstone.army.mil (Rich Gramly).

**G.6USMC Point of Contact**

USMC IETM Acquisition Policy and Guidance

Mr. Greg Ransom

MARCORSYSCOM (PSD)

ransomga@quantico.usmc.mil

703-784-4206

(DSN) 278-4206

**APPENDIX H**

**SAMPLE IETM CONCEPT OF OPERATIONS**

**FOR THE SAGITTARIUS SYSTEM**

*The following is a sample CONOPs developed for the Sagittarius System, a conceptual military program.  This CONOPS was developed by Wayne Honea (NSWC-PHD) and copied from the Navy's IETM Process Plan.*

**H.1System Introduction**

Sagittarius is a sophisticated engagement system capable of supporting a wide variety of configurations, including various ship class combat system, Land Based Test Site, Training, an airborne configuration with potential use by all US Military and foreign military Services.  IETM data will be maintained and updated by the IETM contractor and/or an In-service Engineering Agent (ISEA).

**H.2System Attributes**

**H.2.1Complexity of the System**

Sagittarius is comprised of a sophisticated, processor-controlled equipment set that is capable of supporting multiple configurations.  However, this equipment incorporates self-test and operator controlled test and fault isolation features that simplify troubleshooting and fault isolation.  The maintenance concept is "remove and replace." Consequently, there is no requirement for highly complex maintenance guides and a lower level of IETMs might be acceptable.  Accordingly, a Class III type IETM has been selected for Sagittarius use.

**H.3Configuration Volatility**

Sagittarius is being designed and developed as Common Equipment Sets that have two baseline configurations; that is, a shipboard and an airborne configuration.  Due to the differences inherent in airborne and shipboard configuration requirements, two IETMs will be produced.  The Common Equipment Set concept minimizes the number of configurations that must be considered in the IETMs and reduces IETM change requirements.  Structured update planning will also decrease minor differences among ship classes amount and frequency of IETM change requirements.

**H.4Classification and Security**

Although some system parameters and hardware bear a high security classification level, the IETM will not contain classified data.  Where necessary, it will reference documents containing the appropriate classified data.

**H.5Expected Service Life**

Expected service life of the Sagittarius System is anticipated to be on the order of 20 years with

technological updates occurring on a three-to-five year basis.

**H.6Number and Deployment of Systems**

The US Navy will deploy over 200 Sagittarius Systems.  Location of equipment varies by Ship/Hull.  Other Service and foreign military requirements cannot be forecast a this time.  IETM Display Devices (one in use and one backup) will be required to support each Sagittarius System, for a total, based on expected Sagittarius Systems deployment, of 348 IETM Display Devices.  In addition, it may be found necessary to provide data printing capability, therefore, cost of providing graphic capable printers should be anticipated.  Reference the Sagittarius System fielding schedule.

**FY**

97

98

99

00

01

02

03

04

05

06

07

**IETMs**

2

8

12

11

10

17

20

36

36

35

29

Initial IETM authoring and viewing software licensing costs may be anticipated.  Additional licenses for new software to upgrade capabilities can be anticipated at three-to-five year intervals based on technology advances.

**H.7Number of IETM Users**

The IETM will serve as the primary maintenance tool and source of technical information concerning the Sagittarius System for:

57. Two Shipboard Maintenance Technicians per System.

58. Engineering Support Personnel for the Fleet Technical Support Centers, Atlantic/Pacific.

59. In Service Engineering Agent (ISEA) Engineering Support Personnel.

60. Contractor Field Engineering Support Personnel

61. Naval Training Command Schools Personnel and Students.

IETM data will be maintained and updated by the IETM contractor and/or the ISEA.

**H.8Quantity of Data**

The Sagittarius System is an initial procurement of a technical manual to be constructed from an electronic IETM data base derived largely from electronic Logistic Support Aanalysis, LSA/LSAR data bases.  The fact that the Sagittarius System is comprised of a small equipment set and that the two basic configuration baselines share some commonality, limits the volume of technical data.

**H.9Quality of Data**

The Sagittarius System TM is as an initial procurement technical manual not based on scanning and/or re-authoring of legacy hard copy technical manual data.  Initial product authoring costs must be borne.  However, product data quality is expected to be high without additional quality improvement re-authoring costs.

**H.10Consolidation of Subject Matter**

The first release of the IETM is to contain maintenance information only.  Later releases of the IETM will provide electronic OPNAV 4790/2K submission capability once SNAP supports the automated input of 2K information.

Expert System and integrated training information will not be included in the IETM.  The capability of the equipment's incorporated self and operator controlled test and fault isolation features allows for relatively simple remove and replace procedures to be performed.

The Airborne IETM and the shipboard IETM will be supported by separate IETM databases.  This is due to the significantly different operational requirements and the inability of the contractor's authoring/maintenance system to support a single database that produces two unique IETM products.

**H.11Maintenance Levels**

Organizational level maintenance to be supported includes fault isolation, overhaul, corrective maintenance (remove and replace), and scheduled test and inspection procedures.  The equipment's incorporated self and operator controlled test and fault isolation features allow the IETM to present simple, quick to perform procedures.

**H.12Training Levels**

Due to the planned ease of maintenance and integrated diagnostic features, there are no requirements to include training information in the IETM.  Fleet Training Command Center (FTCC) will receive the preliminary IETM for integration into their existing paper-based training curriculum.  FTCC will provide IETM operation and use in addition to the standard curriculum.  Training is forecast to last 8-10 weeks.

**H.13Manning Requirements**

The Sagittarius System automatic fault diagnostic capabilities will enable the IETM to present quick and simple maintenance procedures.  Shipboard manpower surveys indicate no additional manpower is required.

**H.14Existing Government and Contractor Infrastructure**

The Sagittarius System and contractor currently do not have IETM authoring tools in place.  The Sagittarius System will coordinate with the contractor in assuring that the selected IETM authoring software will produce and support SGML data and the features required of the IETM.  It is expected that a total of 20 CD-ROM drives will be required and procured to prepare the Sagittarius System Program Office and ISEA for display of the IETM.  FTCC will provide the Sagittarius System Program Office with their plan and resources required to implement the IETM in their curriculum.

Contractor and Sagittarius System Program Office/ISEA are able to communicate and send electronic deliverables over the Internet.

**H.15IETM Implementation Schedule**

The Sagittarius System IETM is to be implemented on 10 ships/training sites/aircraft by June 1998.  Approximately 30 months are allowed to implement the IETM.  The IETM implementation schedule includes developing a Comprehensive Technical Manual Plan, conducting a Technical Manual Guidance Conference, and determining, to proceed with IETM development based on the plan and guidance conference results.

Approximately six months are allowed to develop a Comprehensive Technical Manual Plan and conduct a Technical Manual Guidance Conference.  As part of the plan development, available authoring and viewing systems will be reviewed and selected.  About four weeks are allowed to disseminate/review the Comprehensive Technical Manual Plan and to conduct the Technical Manual Guidance Conference.  The purpose of this conference is to discuss and reach government/contractor agreements upon desired plan changes, and make a determination whether or not to proceed with Class III type IETM implementation.  Around 24 months are then available for database and actual IETM development and in-process reviews.

**H.16Urgency of Information Update**

Priority changes will be disseminated to the Fleet user in the most expeditious manner possible.  When safety or health related, methods of dissemination could include naval message, speedletter, or engineering technical bulletins, dependent upon the nature and urgency of the change.  A process for direct updating of shipboard IETMs will be developed.

For less urgent, large volume changes, hard copy supplement to the IETM may be used on a temporary basis until the IETM is updated via a scheduled or, dependent upon the requirement, an unscheduled change.  Unscheduled change requirements and change methodology are seen as subject to case-by-case determination.

**H.17Security**

Although the IETM will contain sensitive information, it will not contain classified information.  Access to IETM data will be restricted by a log-in process which, at a minimum, requires the user to enter a password.

**H.18Display Hardware, Operating Systems, and Networks to be Used for ATIS Compatibility Aboard Ship**

Currently, network drops are not available in the vicinity of combat and/or weapon system equipment spaces.  Use of devices such as the SNAP network CD-ROM jukebox inherently create IETM data downloading device access problems, conflicting user requirements, and mutual interference that create at least a potential for equipment maintenance disruption.

Future shipboard LAN development may provide amore suitable IETM user Infrastructure, for the immediate future, however a CD-ROM compatible notebook PCs are the most feasible means of providing this infrastructure.  The notebook PC provides the portability critical to effective use of the IETM where it is required, adjacent to the equipment undergoing tests, troubleshooting, fault isolation, and repair.

**H.19Environmental Conditions and IETM Display Hardware**

The IETM display hardware is expected to be used in a high noise level environment, exposed to dirt and grease, and be subjected to long hours of operation.  In addition, it may be subject to ship motion and being dropped accidentally.

**H.20Display Hardware Maintenance and Support**

Use of IETMs to support maintenance of Combat System’s electronic equipment is an evolving technology.  Consequently, there is little experience to rely upon for display hardware maintenance and support guidance.

For the moment, and assuming that CD-ROM compatible notebook PCs are the display hardware medium, one notebook PC for data display use and one notebook PC for back-up use is felt to be sufficient for a small electronic equipment employing not more than two maintenance technicians.  When a notebook PC becomes inoperative, it can simply be replaced via a suitable commercial source.

**APPENDIX IACRONYMS AND ABBREVIATIONS**

AAR

After Action Review

ACNs

Advanced Change Notices

ADTDL

Army Doctrine and Training Digital Library

AF

Air Force

AHAS

Army Historical Archives System

AIM

Authoring Instructional Material

AIMSS

Advanced Interactive Maintenance Support System

AIS

Automated Information Systems

ALC

Air Logistics Center

AME

Advanced Maintenance Environment

AMIDD

Aircraft Maintenance Integrated Diagnostics Demonstration

AMSDL

Acquisition Management Systems Data Requirements Control List

ASCII

American Standard Code for Information Interchange

ASP

Active Server Pages

ASRL

Army SGML Registry and Library

ATA

Air Transport Association

ATIS

Advanced Technical Information System

BITE

Built-in Test Equipment

BCU

Block Cycle Update

CAD

Computer Aided Design

CAI

Computer Aided Instruction

CALS

Continuous Acquisition and Life-cycle Support

CAM

Computer Aided Manufacturing

CBI

Computer-based Instruction

CBT

Computer-based Training

CD-ROM

Compact Disk - Read Only Memory

CD-R

Compact Disk - Recordable

CDRL

Contract Data Requirements List

CGM

Computer Graphic Metafile

CIM

Corporate Information Management

CITIS

Contractor Integrated Technical Information Service

CMI

Computer-Managed Instruction

CND

Cannot Duplicate

C/NDI

Commercial/Non Developmental Items

CNET

Chief of Naval Education and Training

CONOPS

Concept of Operations

CTC

Combat Training Center

DAP

Document Application Profile

DAT

Digital Audio Tape

DBMS

Data Base Management System

DCOM

Distributed Component Object Model

DCSLOG

Deputy Chief of Staff for Logistics

DFARS

Defense Federal Acquisition Regulation Supplement

DHTML

Dynamic Hyper Text Markup Language

DII

Defense Infrastructure Initiative

DII-COE

Defense Infrastructure Initiative Common Operating Environment

DiTO

Digital Technical Order

DLDSS

Digital Legacy Data Storage System

DNS

Domain Name Services

DoD

Department of Defense

DoDI

Department of Defense Instruction

DoDISS

DoD Index of Specifications and Standards

DoN

Department of Navy

DPS

Defense Printing Service

DSMC

Defense Systems Management College

DTD

Document Type Definition

DTMB

David Taylor Model Basin

EC

Electronic Classroom

EDD

Electronic Display Device

EOSS

Engineering Operational Sequencing System

EPSS

Electronic Performance Support System

ETE

Electronic Training Environment

ETM

Electronic Technical Manual

ETM-I

Electronic Technical Manual - Interactive

FAR

Federal Acquisition Regulations

FEA

Front-End Analysis

FM

FrameMaker

FOSI

Formatting Output Specification Instances

FPSI

Formatting Presentation Specification Instance

FTCC

Fleet Training Command Center

FTP

File Transfer Protocol

GCO

Government Concept of Operations

GCSFUI

General Content, Style, Format and User Interaction

GCSS

Global Combat Support System

GDMS

Global Data Management System

GFI

Government Furnished Information

GIF

Graphics Interchange Format

GUI

Graphic User Interface

HC

Hard Copy

HTML

HyperText Markup Language

HTTP

 Hypertext Transfer Protocol

IA

InfoAccess

IADS

Interactive Authoring and Display System

ICW 

Interactive Courseware

ID

Identification

IDE

Integrated Data Environment

IETM

Interactive Electronic Technical Manual

IETMDB

Interactive Electronic Technical Manual Database

IETMPP

Interactive Electronic Technical Manual Process Plan

IETM WG

Interactive Electronic Technical Manual Working Group

IG

Instructor Guide

IGES

Initial Graphics Exchange Specification

ILS

Integrated Logistic Support

IM

Information Manager

IMA

I-level Maintenance Activity

IMIS

Integrated Management Information System

INFOSEC

Information Security

IPB

Illustrated Parts Breakdown

IPDE

Integrated Product Data Environment

IPDF

Indexed Portable Document Format

IPR

In-Process Review

ISD

Instructional Systems Development

ISEA

In-Service Engineering Agent

ISO

International Standards Organization

IWSDB

Integrated Weapons System Database

IWSM

Integrated Weapon System Management

JCALS

Joint Continuous Acquisition and Life-cycle Support

JCG-CE

Joint Commanders Group for Communication and Electronics

JEDMICS

Joint Engineering Data Management Information and Control System

JIA

Joint IETM Architecture

JIMIS

Joint Integrated Maintenance Information System

JIT

Just-in-time

JPEG

Joint Photographic Experts Group

JSTARS

Joint Surveillance Target Attack Radar System

JTA

Joint Technical Architecture

LAN

Local Area Network

LIA

Logistics Integration Agency

LO

Lubrication Orders

LOAP

List of Applicable Publications

LP

Lesson Plan

LSA

Logistic Support Analysis

LSAR

Logistic Support Analysis Record

MIL SPEC

Military Specification (e.g., MIL-D for drawings; MIL-M for manuals)

MIL-PRF

Military Specification - Performance

MIL-STD

Military Standard

MIME

Multiservice Internal Mail Extensions

MRC

Maintenance Requirement Cards

MWO

Maintenance Work Orders

NALCOMIS

Naval Aviation Logistics Command Management Information System

NATSF

Naval Air Technical Services Facility

NAVAIR

Naval Air Systems Command

NAVEDTRACOM

Naval Education and Training Command

NAVSEA

Naval Sea Systems Command

NAWCTSD

Naval Air Warfare Center Training Systems Division

NDOI

Non-Developmental Item

NIFF

Navy Image File Format

NIRS

Navy Implementation of Raster Scanning

NOI

Non-Developmental Item

NPRDC

Naval Personnel Research and Development Center

NTIPS

Navy Technical Information Presentation System

NSDSA

NAVSEA Data Support Activity

NSN

National Stock Number

NAVSEA

Naval Sea Systems Command 

NSTM

Navy Ships Technical Manual

NSWC

Naval Surface Warfare Center

NSWC-CD

Naval Surface Warfare Center – Carderock Division

NSWC-PHD

Naval Surface Warfare Center – Port Hueneme Division

NTCSS

Navy Tactical Command Support System

OCR

Optical Character Reader

ODA

Office Document Architecture

OMLE

Omnimark Limited Edition

O&M

Operational & Maintenance

OS

Output Specification

PAM

Pamphlet

PC

Personal Computers

PDF

Portable Document Format

PEDD

Portable Electronic Display Device

PFE

Program File Editor

PMA

Portable Maintenance Aid

PMS

Preventive Maintenance Subsystem

PPP

Personnel Performance Profile

QA

Quality Assurance

RAC

Rapid Action Changes

RCS

Radio Communication Set

RDBMS

Relational Database Management System

RFP

Request for Proposal

RIA

Related Instructor Activities

RPSTL

Repair Parts and Special Tools List

R&R

Remove-and-replace

SAMS

Standard Army Maintenance System

SB

Supply Bulletins

SEAADSA

NAVSEA Automated Data Systems Activity

SECDEF

Secretary of Defense

SGML

Standard Generalized Markup Language

SIM

Supporting Information Chapter

SM

Single Manager

SME

Subject Matter Expert

SNAP

Shipboard Non-tactical Automated Data Processing Program

SOO

Statement of Objectives

SOP

Standard Operating Procedures 

SOW

Statement of Work

SPAM

SP Added Markup

SPAWAR

Space and Warfare Systems Command

SSES

Ship Service Engineering Station

SSMs

Ships Service Manuals

TADSS

Training Aids, Devices, Simulations and Simulators

TB

Technical Bulletins

TCM

Technical Content Manager

TCTO

Time Compliance TO

TG

Trainee Guide

TCP-IP

Transmission Control Protocol/Internet Protocol

TIC

Troubleshooting Information Chapter

TIDES

Technical Information Deficiency Evaluation System

TIFF

Tagged Information File Format

TIMS

Training Integration Management Software

TM

Technical Manual

TMARC

Technical Manual Acquisition Requirements Checklist

TMCR

Technical Manual Contract Requirements

TMDER

Technical Manual Deficiency Evaluation Report

TMIN

Technical Manual Identification Number

TMINS

Technical Manual Identification Numbering System

TMMA

Technical Manual Management Activity

TMMP

Technical Manual Management Program

TMPODS

Technical Manual Publish On Demand System

TMSS

Technical Manual Specifications and Standards

TO

Technical Order

TOCO

Technical Order Conversion Operation

TOCR

Technical Order Contract Requirement

TPS

Training Path System

TSA

Training Support Agent

TSP

Training Support Packages

ULLS

Unit Level Logistics System

URL

Uniform Resource Locator

USAF

United States Air Force

USAPA

United States Army Publishing Agency

USMC

United States Marine Corps

USN

United States Navy

USPRO

U.S. Product Data Association

V&V

Verification & Validation

VP

View Package

vURL

virtual Uniform Resource Locator

WAN

Wide Area Network

WWW

World Wide Web

WYSIWYG

What-you-see-is-what-you-get

W3C

World Wide Web Consortium

XML

eXtensible Markup Language

**APPENDIX JLIST OF SOURCES**

In addition to the numerous Web sites, policy manuals, specifications, standards and vendor supplied information, the following resources served as the basis for much of the material presented in this document.

Draft IETM Process Plan

Wayne Honea 

NSWC-PHD

February 1998

Interactive Electronic Technical Manuals Cost/Benefit Analysis

Hughes Technical Services Corporation

Joint IETM Architecture

Eric Jorgensen

NSWC, Carderock Division

July 1998

Maintenance and Logistic System Support Benefits Resulting From Introduction of IETM Based Technology

NSWC-CD/TSS-97/02

Joseph Fuller

Samuel C. Rainey

Theodore J. Post

October 1996

NAVSEA/SPAWAR IETM Process Plan

S0005-AD-PRO-010

Wayne Honea

December 1995

Yes

Functionality

IETM w/ Class 4

No

Integrated ?

 Sys

Expert 

IETM/

Yes

No

2

Identified/Projected

System Attributes

No

Functionality

IETM w/ Class 5

4

?

Processes

 HC and IETM

Support

3

?

Displays

Outfitted w IETM

Field

Figure 5-1.  GCO Development Process

8.  Determine the mechanism and type of medium for data delivery /access.

4.  Identify the user’s infrastructure.

7.  Determine the data interchange standards.

3.  Identify what the user will do with the data.

6.  Determine the required data format.

5.  Identify type of digital data deliverables.

2. Identify who will use the data.

1. Identify what types of data are required.

4

3

2

1

Accept

and test

IETM deliverables

Distribute and

evaluate contractor

responses

Develop

Procurement

Package

Develop IETEM

Concept of

Operations

6

Develop the

Government

Concept of 

Operations

Figure 3-1.  Graphical Representation of IETM Classes

� EMBED Word.Picture.8  ���

IETM w/ Class 3

Functionality

Yes

IETM w/ Class 2

Functionality

ASCII File

Available

?

No

Class 1 ETM

Frequent

Updates Required

?

Word

Search Needed

?

Yes

No

Yes

Yes

No

10

11

19

20

Yes

7

12

21

13

Class 4

Conversion

Supported by

Budget

?

Yes

Class 3

Conversion

Supported by

Budget

?

18

No

Class 2

Conversion

Supported by

Budget

?

Yes

No

No

Class 5

Conversion

Supported by

Budget

?

Yes

No

1

9

8

Expert

System

Requirements

?

Review

IETM/System

Requirements

No

Yes

Yes

No

Yes

No

Field

Outfitted w IETM

Displays

?

Class 3/4

Functionality

Required

?

6

5

No

IETM

Conversion

Project

?

Yes

IETM

Conversion

Project

?

No

IETM

Conversion

Project

?

IETM

Conversion

Project

?

Yes

Yes

No

24

22

17

16

15

14

23

No

Yes

Figure 5-2.  IETM Functionality Determination Model

IETM Presentation Component

No

Yes

ASCII file tagged

to selected DTD

Convert 

Hard-copy

into ASCII/Graphics

SGML/ASCII file

processed through

IETM authoring

software

Validation and

verification of

data/links

1

2

3

4

5

SGML tagging

IETM authoring

Validating &

 verifying

Publishing

General IETM Phases

Resultant

“runtime version”

        distributed

6

IETM viewing

Figure 6-1.  IETM Conversion Process

Hard-copy

TM available in

ASCII/Graphics

?

  Determine

Class 2 DTD

  Determine

Class 2 IETM

software

No

 Is TM

 available in

ASCII?

Yes

  SGML tag ASCII

to DTD and make

linkages

 SGML data

used to

convert into IETM

 SGML data

used to

print hardcopy

  SGML database

updated and

maintained

  Determine

internal/external

linkages required

5

9

2

1

6

11

10

3

12

   Convert hardcopy

into ASCII

and vector/raster

graphics

 Is ASCII

text required?

No

Yes

Acquire non-SGML

file such as

    PDF

8

7

Make linkages

4

Figure 6-2.  Class II IETM Conversion Process

Figure 6-3.  Class III IETM Conversion Process

Figure 6-4.  Class IV IETM Conversion Process

Figure A-5.  Arbortext’s ADEPT*Editor Interface

Figure A-6.  FrameMaker+SGML Authoring Environment

Figure A-7.  IADS Reader

Figure A-8.  TechSight Viewer

Figure A-9.  Quill21 System

Figure A-10.  AIMSS Viewer

Figure A-11.  JIMIS Screens

� EMBED Word.Picture.8  ���

Figure A-12.  Acrobat Viewer

Figure A-13. GUIDE Reader (InfoAccess)

Figure A-15.  Texcel's Information Manager

+ Table Heading

* Body of the Table (columns rows, entries)

7

Figure A-1.  Military Manual Structure

Document

     Front Matter (Foreword, Safety Summary)

     Body (Chapters, Sections, and Paragraphs)

     Rear Matter (Appendices, Glossary)

 Section

 Graphic

  BODY

 Chapter X

 Chapter Y

  Chapter Z

 Section

 Section

 Section

 Section

  Para0

  Para0

 Subpara1

 Subpara1

   Para

    Para

   Step1

   Step1

   Step2

   Step2

  Step n

  Step n

  Para0

  Para0

  Table

  Figure

THEAD+

TBODY*

   Row

   Row

  entry

   entry

   entry

   entry

  Para0

  Para0

 Subpara1

 Subpara1

 Subpara2

 Subpara2

 Subpara n

Subpara n

Figure A-2.  SGML Tree Example

� EMBED Word.Picture.8  ���

Figure A-3.  HTML Display Within Internet Explorer

� EMBED Word.Picture.8  ���

Infrastructure Server

(Receive View Packages from 

Developer

Store View Packages

Forward/Push to User Site Server

Manage View Package-item, not the content

Figure 10-1.  Flow of IETMs Through the JIA

Figure D-1.  Sample Screens from TO CBT Course

Figure B-1.  Digital Product Relationship

�

IETM Content Data

IETM View Package (Encapsulated Objects)

Site Server for User Intranet

Site Server File Base

User Device (Workstation or PEDD) with Web Browser Client Software Installed

Request (via URL) and Receive Web Objects

User views IETMs in Single Common Browser Using Point-and-Click Hot Spots (URL Links)

IETM View Package Transmitted to Site Server

Figure 7-1.  Flow of IETMs Through the JIA

Figure 7-2.  Elements for Architecture Types C1 and C2

Request Web Object via URL 

Web Browser

HTTP Server

Return Web Pages/Components

Server Files

Return Web Pages/Components

Web Browser

HTTP Server

Server Files

Request Web Object via URL 

Application Server (e.g., HTML-on-the-fly)

Figure 7-4.  Elements for Architecture Type S2

Figure 7-3.  Elements for Architecture Type S1

Web Browser

HTTP Server

Request Web Object via URL 

Return Web Pages/Components

Server Files

Application Server

(e.g., Request Data Instance from Database Server)

Database Server

DBMS managed database

� EMBED Word.Picture.8  ���

Figure F-1.  Army IETM Display Equipment

5

Distributed to

presentation

system

IETM

validated

against source

data

4

3

2

1

External linkages

defined and

implemented

Naming/linking

objects into

view packages

Reauthor

legacy data

into objects

IAW DTD

Determine

Class IV DTD

Determine

Class IV IETM

software

x

# _980259426.doc

# _997473821.doc

# _978446346.doc

# _978975009.doc

# _978875821.doc

# _978436273.doc