NATO CALS HANDBOOK

APPENDICES

March 1, 2000

TABLE OF CONTENTS
APPENDIX A: CALS CONCEPTS .......................................................................................... A-1
A1.0 CALS CONCEPTS ........................................................................................................... A-1
A2.0 WHAT IS NATO CALS? ................................................................................................. A-1
A2.1 Importance of CALS to NATO ............................................................................. A-1
A2.1.1 Roles and Responsibilities of NATO with Respect to CALS ................ A-2
A2.1.1.1 Internal Roles .......................................................................... A-2
A2.1.1.2 External Role........................................................................... A-2
A2.2 NATO CALS Objectives ...................................................................................... A-3
A2.2.1 Increase Interoperability......................................................................... A-3
A2.2.2 Decrease Defense Equipment Life-cycle costs...................................... A-3
A2.2.3 Ensure the Readiness of NATO Forces ................................................. A-3
A2.2.4 Decrease Acquisition Lead Times ......................................................... A-3
A2.2.5 Increase the Quality of Delivered Products ........................................... A-3
A2.3 Management Vision and Leadership ..................................................................... A-4
A2.3.1 NATO CALS Vision.............................................................................. A-4
A2.3.2 The Critical Importance of Leadership .................................................. A-4
A2.4 The Need to Accommodate Change ..................................................................... A-5
A2.5 The Extended Enterprise ....................................................................................... A-5
A2.6 The NATO Extended Environment ...................................................................... A-7
A2.7 Information Process and Tool Elements ............................................................... A-7
A2.8 Controlled Access ................................................................................................. A-7
A2.9 Data Sharing and Collaboration............................................................................ A-8
A2.10 Digital Data Exchange ........................................................................................ A-8
A2.11 Information Architecture..................................................................................... A-8
A2.12 Product Data Management .................................................................................. A-8
A2.13 User Applications................................................................................................ A-9
A2.14 Infrastructure Elements ....................................................................................... A-9
A2.15 Telecommunications ........................................................................................... A-9
A2.16 Desktop ............................................................................................................. A-10
A2.17 Hardware and Operating Systems ..................................................................... A-10
A2.18 Policy and Standards Elements ......................................................................... A-10
A2.19 Training and User Support Ele ments ................................................................ A-11
A2.20 Multi-Disciplinary Work Groups ...................................................................... A-12
APPENDIX B:
NATO CALS DATA MODEL EXPRESS G DIAGRAMS
AND EXPRESS DEFINITIONS.................................................................................................B-1
APPENDIX C: TLBM V 6.01 ACTIVITY DEFINITIONS ..................................................... C-1
C1.0 TLBM V 6.01 ACTIVITY DEFINITIONS ...................................................................... C-1
C2.0 TLBM 6.01 ICOM REPORT ............................................................................................ C-9
APPENDIX D: PRODUCT, PROCESS, AND DATA INTEGRATION................................. D-1
D1.0 INTRODUCTION ............................................................................................................ D-1
D2.0 DIGITAL REPRESENTATION FOR COMMUNICATION OF PRODUCT DATA:
IGES APPLICATION SUBSETS AND IGES APPLICATION PROTOCOLS ....................... D-1
D2.1 Purpose .................................................................................................................. D-1
D2.2 Scope ..................................................................................................................... D-1

ii

D2.3 Application Subsets............................................................................................... D-1

D2.3.1 Class I: Technical Illustrations Application Subset. .............................. D-2
D2.3.2 Class II: Engineering Drawings Application Subset............................. D-2
D2.3.3 Class III: Electrical/Electronic Applications Subset............................. D-2
D2.3.4 Class IV: Geometry for NC Manufacturing Application Subset .......... D-2
D2.4 Application Protocols............................................................................................ D-3
D2.5 Implementation Issues........................................................................................... D-3
D3.0 STANDARDIZED GENERALIZED MARKUP LANGUAGE...................................... D-3
D3.1 Purpose .................................................................................................................. D-3
D3.2 Document Type Definition ................................................................................... D-4
D3.3 SGML Markup ...................................................................................................... D-4
D3.4 Output Specification.............................................................................................. D-4
D3.5 Electronic Review ................................................................................................. D-5
D3.6 Partial Documents ................................................................................................. D-5
D3.7 NATO CALS SGML Registry/NATO CALS SGML Library............................. D-5
D3.8 Software Tools ...................................................................................................... D-6
D4.0 HYPERMEDIA
TIME-BASED
DOCUMENT
STRUCTURING
LANGUAGE
(HYTIME) (ISO/IEC DRAFT INTERNATIONAL STANDARD 10744) ............................... D-7
D4.1 Purpose .................................................................................................................. D-7
D4.2 Typical Applications ............................................................................................. D-7
D4.3 Features ................................................................................................................. D-7
D4.4 Hytime Architecture and Modules........................................................................ D-8
D4.5 Advantages of Current Specification.................................................................... D-9
D4.6 Enhancements to the Published Standard ............................................................. D-9
D4.7 Implementation Issues........................................................................................... D-9
D5.0 DIGITAL REPRESENTATION FOR COMMUNICATION OF ILLUSTRATION DATA:
COMPUTER GRAPHICS METAFILE ................................................................................... D-10
D5.1 Purpose ................................................................................................................ D-10
D5.2 Typical Applications ........................................................................................... D-10
D5.3 Architecture......................................................................................................... D-11
D5.4 Status and Planned Extensions............................................................................ D-11
D5.5 Advantages of Current Specification.................................................................. D-12
D5.6 Implementation Issues......................................................................................... D-13
D6.0 STANDARDS FOR THE EXCHANGE OF PRODUCT MODEL DATA ................... D-13
D6.1 Purpose ................................................................................................................ D-13
D6.2 Architecture of the Standard ............................................................................... D-14
D6.2.1 Overview (Parts 1 - 9) .......................................................................... D-14
D6.2.2 Description Methods (Parts 10 - 19) .................................................... D-14
D6.2.3 Implementation Forms (Parts 20 - 29) ................................................. D-15
D6.2.4 Conformance Testing (Parts 30 - 39) ................................................... D-15
D6.2.5 Integrated Resources (Parts 40 - 199) .................................................. D-15
D6.2.6 Application Protocols (Parts 200 +) ..................................................... D-15
D6.3 Status and Planned Extensions............................................................................ D-15
D6.3.1 STEP Initial Release ............................................................................ D-15
D6.3.2 STEP Subsequent Releases .................................................................. D-16
D6.4 Advantages of Current Specification.................................................................. D-17

iii

D6.5 Implementation Issues......................................................................................... D-17

D6.5.1 Implementation of APs ........................................................................ D-17
D6.5.2 Software Tools ..................................................................................... D-17
D6.6 Implementation Levels........................................................................................ D-18
D6.7 Testing..................................................................................................... D-18
D6.8 Training and Education....................................................................................... D-19
D7.0 EQUIPMENT ACQUISITION STANDARDS AND APPLICATION PROFILES
(VERSION 2 Section 10.0)....................................................................................................... D-19
D7.1 Acquisition Processes ......................................................................................... D-19
D7.2 Logistics Support Analysis ................................................................................. D-19
D7.3 Initial Provisioning.............................................................................................. D-20
D7.4 Illustrated Parts Catalogues................................................................................. D-20
D7.5 NATO Codification............................................................................................. D-20
D7.6 Machine Readable Code (Bar Coding) ............................................................... D-21
D7.7 Order Administration.......................................................................................... D-21
D7.8 Order Administration Format, Content, and Communications Techniques ....... D-22
D7.9 Consumption and Maintenance Data Exchange ................................................. D-22
D7.10 Standard Parts Library Data Exchange ............................................................. D-22
D8.0 TECHNICAL DOCUMENTATION STANDARDS AND APPLICATION PROFILES D-23
D8.1 Character Sets and International Codes .............................................................. D-23
D8.2 Information Processing ....................................................................................... D-25
D8.3 Graphics and Illustrations ................................................................................... D-30
D8.4 Product Data........................................................................................................ D-34
D8.5 Images ................................................................................................................. D-43
D8.6 CD-ROM Storage/Transfer Media ...................................................................... D-44
D8.7 Video and Motion Picture Media ........................................................................ D-45
D8.8 Digital Audio ....................................................................................................... D-46
D8.9 Hypermedia and Multimedia .............................................................................. D-47
D8.10 Interactive Electronic Technical Manuals......................................................... D-48
D9.0 SYSTEM MANAGEMENT STANDARDS AND APPLICATION PROFILES .......... D-49
D9.1 Systems Engineering........................................................................................... D-49
D9.2 Integrated Logistics Support ............................................................................... D-50
D9.3 Configuration Management ................................................................................ D-50
D9.4 Environmental Life-cycle Assessment ................................................................ D-56
D9.5 Disposal of Equipment ........................................................................................ D-56
D9.6 Quality Management ........................................................................................... D-57
D10.0 DATA FORMATS AND DELIVERY STANDARDS ................................................ D-59
D10.1 Contract Data Requirements Lists .................................................................... D-59
D10.2 Classified Data .................................................................................................. D-59
D10.3 Data Encryption ................................................................................................ D-59
D10.4 Digital Signatures.............................................................................................. D-59
D10.5 Digital Data Delivery........................................................................................ D-60
D10.6 Electronic Data Interchange (EDI).................................................................... D-60
D10.7 Electronic Data Interchange Agreement ........................................................... D-62
D10.8 Data Dictionary................................................................................................. D-63
D10.9 Integrated Product Database ............................................................................. D-65

iv

D10.10 Database Query Language .............................................................................. D-65

D10.11 Contractor Integrated Technical Information Service..................................... D-66
D10.12 Automated Interchange of Information........................................................... D-66
D10.13 Technical Data Packages................................................................................. D-67
D10.14 Database Manager ........................................................................................... D-67
D10.15 Communications Infrastructure....................................................................... D-67
D10.16 Status of Document ......................................................................................... D-68
D10.17 Disclaimer ....................................................................................................... D-68
D10.18 Feedback ......................................................................................................... D-68
APPENDIX E: INDEX OF STANDARDS ................................................................................E-1
APPENDIX F: CALS TERMINOLOGY/ACRONYMS ...........................................................F-1
APPENDIX G: INTERFACE SPECS AND THE TLBM ........................................................ G-1
G1.0 INTERFACE SPECS AND THE TLBM ......................................................................... G-1
G1.1 The Problem.......................................................................................................... G-1
G1.2 The Solution.......................................................................................................... G-1
G1.3 Candidate Interface Specifications ........................................................................ G-2
G2.0 FROM DEFENSE SYSTEM TO THE ARMED FORCE................................................ G-2
G2.1 Requirement .......................................................................................................... G-2
G2.2 Design ................................................................................................................... G-2
G2.3 Interface Details for Other Systems (DS Data)..................................................... G-2
G2.4 Support Design...................................................................................................... G-2
G2.5 Support .................................................................................................................. G-3
G3.0 FROM AF TO DS ............................................................................................................. G-3
G3.1 Requirements......................................................................................................... G-3
G3.2 Design ................................................................................................................... G-3
G3.3 Support Design...................................................................................................... G-3
G3.4 Provides List of Common Tools and Equipment* (External Data) ...................... G-4
G3.5 Support .................................................................................................................. G-4
G3.6 Operate .................................................................................................................. G-4
APPENDIX H: LIST OF POSSIBLE CALS IMPROVEMENT TARGETS ........................... H-1
APPENDIX I:
INFRASTRUCTURE REQUIREMENTS FOR THE CREATION,
MANAGEMENT, AND USE OF DIGITAL DATA ...................................................................I-1
I1.0 INFRASTRUCTURE REQUIREMENTS FOR THE CREATION, MANAGEMENT, AND
USE OF DIGITAL DATA............................................................................................................I-1
I1.1 Introduction................................................................................................................I-1
I1.1.1 Purpose ......................................................................................................I-1
I1.1.2 Infrastructure Resource Planning ..............................................................I-1
I1.2 General Considerations .....................................................................I-2
I1.2.1 Hardware Considerations ...........................................................................I-2
I1.2.1.1 Computer Architecture ...............................................................I-3
I1.2.1.2 Computer Operating System ......................................................I-3
I1.2.1.3 System Backup ...........................................................................I-4
I1.2.1.4 Physical Media ............................................................................I-4
I1.2.1.4.1 Magnetic Media ...........................................................I-4
I1.2.1.4.2 Optical Media ..............................................................I-5
I1.2.1.5 Output Devices ...........................................................................................I-5

I1.2.1.6 Computer Graphics and Monitors ..............................................I-5

I1.2.1.7 Network Devices ........................................................................I-6
I1.2.1.8 Input Devices..............................................................................I-6
I1.2.2 Software Considerations ............................................................................I-7
I1.2.2.1 Data Formats...............................................................................I-7
I1.2.2.2 Operating System Compatibility ................................................I-8
I1.2.2.3 Application Packages..................................................................I-8
I1.2.2.4 Software Licensing .....................................................................I-9
I1.2.3 Telecommunications................................................................................I-10
I1.2.3.1 Network Protocols ....................................................................I-10
I1.2.3.2 LAN ..........................................................................................I-10
I1.2.3.3 WAN.........................................................................................I-11
I1.2.4 Data Processes .........................................................................................I-11
I1.3 Hardware Requirements for Processing Digital Data.............................................I-11
I1.3.1 Hardware Requirements for Processing TMs..........................................I-11
I1.3.2 Hardware Requirements for Processing TDPs ........................................I-13
I1.3.3 Hardware Requirements for Processing ILS/LSAR................................I-13
I1.3.4 Software Requirements for Processing Digital Data ...............................I-13
I1.3.5 Software Requirements for Processing TMs ...........................................I-13
I1.3.5.1 Software Requirements for Creating SGML Format TMs .......I-14
I1.3.5.2 Software Requirements for Creating IETMs ............................I-14
I1.3.5.3 Software Requirements for Managing TMs .............................................I-14
I1.3.5.4 Software Requirements for Using TMs ....................................I-15
I1.3.6 Software Requirements for Processing TDPs .........................................I-15
I1.3.6.1 Software Requirements for Creating TDPs ..............................I-15
I1.3.6.2 Software Requirements for Managing TDPs............................I-15
I1.3.6.3 Software Requirements for Using TDPs ..................................I-16
I1.3.7 Telecommunications Requirements for Processing Digital Data ............I-16
APPENDIX J: VIKING THROUGH LIFE STRATEGY AND PLAN ......................................J-1
APPENDIX K: VIKING THROUGH INFORMATION MANAGEMENT PLAN ................. K-1
APPENDIX L: PMCMS ENABLING EFFECTIVE TEAMS THROUGH THE USE OF
INTEGRATED DATA ENVIRONMENTS ................................................................................L-1

vi

APPENDIX A: CALS CONCEPTS

A1.0 CALS CONCEPTS

Continuous Acquisition and Life-cycle Support (CALS) allows companies and governments to
extend their enterprise to encompass contractors and subcontractors working in full collaboration
(e.g., concurrent engineering).
A2.0 WHAT IS NATO CALS?
Continuous Acquisition and Life-cycle Support (CALS) is a strategy intended to accelerate the
transition from a present paper-intensive non-integrated product development, design,
manufacturing and support processes to a highly automated, integrated mode of operation by
developing standards for data storage and exchange, and automated systems to store, manage and
distribute this information to many and varied users across an organization.
The general objectives of the CALS strategy are to reduce cost, improve the timeliness, and
improve the quality of products. Achieving these objectives will lead to increased operational
readiness, improved interoperability in the field and industrial competitiveness. CALS envisions
an integrated data environment created by applying the best technologies, processes, and
standards for the development, management, exchange, and use of business and technical
information among governmental and industrial enterprises. It is founded on the need for
affordable, readily accessible, timely technical and business information.
Since 1989, NATO has addressed CALS in the Conference of National Armament Directors
(CNAD). In October 1993, the CNAD endorsed the creation of a NATO Organization for CALS
that will take the lead on all CALS issues within NATO.
A2.1 Importance of CALS to NATO
NATO post the cold war era, faces an unprecedented challenge in preserving force effectiveness
in light of the radically altered and ever changing threat, substantially declining defense budgets,
and changes in global development of technology.
NATO will use a strategy entitled CALS as one way to decrease defense equipment life-cycle
costs, ensure the readiness of its forces, and increase cooperation with industry and the
international community. CALS provides these benefits by quickening the pace at which highquality information flows within NATO and between NATO and its business partners and at the
same time, providing an opportunity to reduce information management overhead costs. CALS
does this by use of national and international standards and practices, business process
improvements, and application of advanced technologies.

A-1

The emerging role of NATO is one involving a new flexibility for the deployment of NATO
systems, where a faster response to diverse locations is required with smaller, better equipped
forces. Of equal significance, is the greater multinational integration within the newly formed
force structures, such as the Rapid Reaction Corps and the allied NATO Air Force. This
multinational context is becoming even more prominent as new friends of the Alliance are to be
considered in a Partnership for Peace. Consequently it is vital that NATO concentrates on
achieving greater cooperation in acquisition and greater operational interoperability in order to
ensure that smaller, better equipped multinational forces are able to operate efficiently together.
CALS can allow this to happen while, at the same time, benefiting NATO nations by reducing
defense equipment life-cycle costs.
Budgetary constraints and accelerating changes in
information technology are principal for fundamental improvements in the way government and
industry conduct business.
Rapid development in information technology have propelled
western economies into an era of global interdependence, where the major discriminating factor
among these competing economies is the ability to develop and apply this technology. NATO
therefore does not have a 'do nothing' option when considering the endorsement of CALS and the
incorporation of CALS into functional process improvement. CALS is considered to be one
prime contributor to increased sortie rates, reduced downtimes, enhanced logistic support, safer
operations, and increased interoperability in the field. In order to reach those benefits, NATO
will have to consider up-front investments in CALS.
A2.1.1 Roles and Responsibilities of NATO with Respect to CALS
A2.1.1.1 Internal Roles
There are two internal roles to accomplish. The first role becomes apparent when considering
NATO bodies, responsible for NATO infrastructure, standards, policy, and regulatory
considerations. In order to achieve NATO CALS standardization, as a first step towards
international standardization, these bodies' advise and endorsement will be sought whenever
deemed necessary.
To ensure internal NATO harmonization, the important role of CALS standards 'creator' is to be
performed. Several NATO Organizations and Agencies have been established and tasked with
the acquisition and in-service support for multinational equipment projects. Therefore, within
NATO, CALS implementation is to be ensured by clear directives and thus NATO will act as a
CALS standards 'enforcer' within the Alliance and a CALS standards p' romoter' to the individual
nations.
A2.1.1.2 External Role
NATO is a multinational organization with one common (military) goal. NATO is one of the
few organizations capable of aligning developments taking place in the two powerful industrial
complexes of North America and Europe. NATO's role therefore is one of a multinational
CALS catalyst and coordinator of international standardization and R&D efforts. NATO
therefore should establish formal links with international standardization organizations that
operate within NATO's areas of interest. NATO should also establish formal links with

A-2

organizations that subsidize and stimulate international R&D within the NATO region.
should closely liaise with industry.

NATO

A2.2 NATO CALS Objectives

To ensure improved service to our coalition forces, NATO CALS will seek to identify further
opportunities for improvement in acquisition and logistic processes, information standards and
interchange specifications, based on the following operational and business objectives.
The objectives are consistent with, and respond to the Ministerial Guidance on logistics.
Activities will be directed at improving the interoperability of NATO forces and enabling
increased agility through optimization of the logistics footprint.
Without interoperability,
International Co-operative Logistics for in-theatre support of NATO forces will be difficult to
attain. Without in-theatre support, higher logistics footprints will burden the mobility and agility
of the operational force.
A2.2.1 Increase Interoperability
The NATO CALS program will strive for improved capability for co-operation in logistics,
though standardization of information and of shared processes. This will be achieved by
working closely with the Senior NATO Logistics Conference (SNLC) and the SNLC Ad Hoc
Working Group on Co-operative Logistics.
A2.2.2 Decrease Defense Equipment Life-cycle costs
The NATO CALS program will reduce product support costs through migration to commercial
information standards and systems, and increased reliance on industry to provide information as
a service.
A2.2.3 Ensure the Readiness of NATO Forces
Higher operational availability of Defense Systems will be accomplished through reduced
downtime and faster repairs. This can be achieved through improved access to accurate product
data, including digital product definition data to enable rapid manufacturing and enhanced
maintenance diagnostics.
A2.2.4 Decrease Acquisition Lead Times
Faster, more assured delivery of Defense System spares demanded by Armed Force users is
possible by improving the consistency of information in the supply chain.
A2.2.5 Increase the Quality of Delivered Products
Quality increases will be achieved through the capture of information once and re-using if many
times, thus avoiding data entry errors. Product documentation quality can also be improved
using Interactive Electronic Technical Manual (IETM) concepts.

A-3

A2.3 Management Vision and Leadership

A2.3.1 NATO CALS Vision
The NATO CALS program was initiated by CNAD as a means to achieving greater NATO
effectiveness in alliance operations through the use of information standards and technology in
both armament and infrastructure programs.
The basic tenant of NATO CALS is that
information is a critical asset to be managed within the infrastructures of allied nations and of
NATO throughout the complete life-cycle of programs. The NATO CALS vision achieves
significant improvements in performance by using a Shared Data Environment that makes
accurate information available, when and wherever it is needed, in an appropriate form.
The benefits of implementing a CALS Environment can be maximized by:

Treating information as an asset

Starting early
Being clear and specific on the expected performance improvements
Taking a whole life perspective
Planning for change over time (IT, Product, Organizational)
Tailoring the solution to the program.

A2.3.2 The Critical Importance of Leadership

Today, most Defense System program information is created, stored, and used in digital format.
The transition to a full digital environment is inevitable and is happening rapidly. The challenge
for program managers is to gain the maximum benefit from digital data, by managing
information effectively.
The use of a Shared Data Environment (SDE) can offer enormous opportunities for
improvement, but involves significant change and requires some very hard work. It is therefore
of absolute importance that the program senior management has a clear vision of what the
SDE is meant to achieve for their program, and has the necessary personal commitment to
achieve the required changes.
In the book Navigating the Digital Environment: A Program Managers Perspective 1 the
authors write:
The PM (Program Manager) must have the vision, or ability, to understand the potential for a
cross-functional integrated digital environment. Interviews have shown that extensive technical
knowledge or detailed functional acquisition experience is clearly not a prerequisite for the
success of an APDE (Acquisition Programs Digital Environment). The PM must understand
that information itself is an asset that needs to be managed carefully over the entire life-cycle of
the program.

1 Navigating the Digital Environment: A Program Managers Perspective, Cromar, Wiley,

Tremaine, Defense Systems Management College Press, 1996, p.5-2
A-4

Experience has shown that the quality of vision and leadership provided by the Senior
Management is the single most critical factor in the successful implementation of CALS.
Management commitment to the CALS implementation must be demonstrated by the allocation
of appropriate resources, by support for local champions who are leading change implementation
and by personal participation in the key NATO CALS Operations (NCOPS) activities.
Intelligent use of NCOPS can reduce risks, but without adequate leadership, the changes to
deliver benefits simply will not happen.
A2.4 The Need to Accommodate Change
Most Defense Systems change continuously over their lifetime. The processes and organizations
used to manage each Defense System will also improve over time. Major change in the CALS
Environment the hardware, the software, and the culture can be expected every two or three
years (with the cultural changes usually lacking behind considerably). Change must be expected,
planned for, and managed. The Program Strategy for CALS, developed through use of NCOPS,
will need review and update throughout the entire life-cycle.
A2.5 The Extended Enterprise
Successful organizations in the future will have in common their ability to assemble in whatever
virtual configurations are necessary to identify, scope, pursue, and capture business, and then
perform to specifications within budget and schedule constraints. Business will be won and
executed by extended enterprises. These will not be static over the life of a product, but will
change with conditions and the ebb and flow of requirements and capabilities. Participants will
include customer organizations, high technology partners and subcontractors, and suppliers of
various levels of capability and sophistication.
The process mechanisms by which teams interface and operate must in large measure be
common, as solutions specific to only one opportunity will be too costly for most players.
Business processes will be executed in a collaborative mannerin real-time where appropriate
by teammates distributed physically and in time. Co-location will be electronic, and information
needed for the task at hand will be immediately accessible and usable with little or no
preparation. Information will be provided through a variety of electronic mediatext, graphics,
voice, and video. Huge volumes of data will be stored, accessed, viewed, shared, and moved.
This will occur efficiently, accurately, securely, and affordably.
The purpose of an integrated information environment is to support the execution of streamlined
business processes across enterprise boundaries. Teams will accomplish this with members
geographically dispersed by distance and time, enabled by controlled access to data and related
software, effective exchange and sharing of data, and the collaborative preparation of
information deliverables.
A simple model of business processes, people, and the environment is presented in the figure
below. The specific business processes are related to the information deliverables of the
extended enterprise they support. The people who execute the processes are representative of the
various organizations that comprise the extended enterprise. The enabling CALS environment
must support their location, responsibilities, and team relationships. The extended enterprise
A-5

concept of operations provides a framework for the overall identification of the work processes,
team members, responsibilities, interactions, and supporting environment composition.

PEOPLE
T
R
A
I
N

BUSINESS PROCESSES
GENERIC
(DEVELOP INFORMATION PRODUCT)
SPECIFIC
(e.g. PROPOSAL PREP, PART PROCUREMENT)

P
O
L
I
C
I

SUPPORTING CALS ENVIRONMENT

E
S

&
I. INFORMATION PROCESSES & TOOLS
U
S
E
R

CONTROLLED ACESS
DATA SHARING AND COLLABORATION
DIGITAL DATA EXCHANGE

INFORMATION ARCHITECTURE

PRODUCT (&OTHER) DATA MGMT

USER APPLICATIONS (TECH, BUS)

N
D

U
P
P
O
R

&

II. INFRASTRUCTURE

TELECOMMUNICATIONS

DESKTOP SOFTWARE (e.g. EMAIL,

WORD PROCESSOR, SPREADSHEET)

HARDWARE AND OPERATING SYS S/W

The environment is best understood through a description of the concepts, which compose it.
These elements can be characterized as information processes and tools, infrastructure, policies
and standards, and training and user support. They are briefly discussed in the sections that
follow:

A-6

A2.6 The NATO Extended Environment

The Extended Enterprise is a grouping of individual businesses or organizations that cooperate to achieve a common goal. NATO can be viewed as an extended enterprise. Within
NATO CALS, the term is used to refer to all of the parties involved in the acquisition or support
of a particular Defense System.
A2.7 Information Process and Tool Elements
These elements have to do with the what and how of information provision to teams and
individuals executing business processes. The what addresses the processes and procedures
for creation of and operations on the information deliverables. It includes the access and
electronic transfer of digital data as a basic capability that replaces transfer of paper, or the
access and sharing of such data in the collaborative execution of business processes or
procedures. The how addresses the tools and techniques for accomplishing the what. It has to
do with ensuring data (or an image of data) arrives at its destination, under proper access control,
and is correct, complete, consistent, current, and associated with the desired configuration or
version. It includes the actual creation, analysis, review, and modification of the information
product. The
A2.8 Controlled Access
This element ensures that only authorized users gain access to data, that those users see only the
data they are privileged to access, and that they can perform on it only those operations approved
for them. This is a most critical element in the CALS environment, for it must strike a practical
balance between the openness required for collaboration, and the security of proprietary,
competition-sensitive, or national defense data.
Controlled access requires identification of specific incoming users or node locations. It:

Includes user profiles that delineate specific accessible data stores and allowed
operations.
Provides firewall services that can range from very simple to very complex, applied
uniformly to all users or individually crafted.
Includes transaction logging or audit trails.

For optimum effect, controlled access to an organization's information space should be through
a single logical node. The number of physical access nodes is dependent on the number of
concurrent users and the desired performance.
Access to allowed data stores can be direct if the access mode and the data store structure
support encapsulated operations against segmented data, with control always returning to the
access node after normal or abortive exit. If these conditions cannot be met, the data in question
can be uploaded to the access node by one party, and downloaded by the other using various
file transfer protocols. The put and get process can be coordinate through E-Mail if need be.

A-7

If controlled access is to facilitate the efficient exchange and sharing of datawithin appropriate
security constraintsthe data itself must be easy to find; the parties in the transaction should not
have to know where it is or the details of how it is accessed. This implies a minimum
requirement for a data index that includes location and access mode. For a relatively small
operation, the index may be nothing more than a simple list updated regularly. For broad and
pervasive collaborative work, a global data directory and robust packaging and warehousing
capabilities will be required. Workflow and task-management tools are also appropriate for realtime collaboration in support of a major project. This latter situation requires a Contractor
Integrated Technical Information System (CITIS)-like capability that essentially meets the
requirements of MIL-STD-974.
A2.9 Data Sharing and Collaboration
This element supports the collaborative creation, review, modification, approval, disposition, and
status of information products such as documents, drawings, CAD models, schedules,
spreadsheets, product, and process specifications, or composites such as bid packages. It implies
a sharing and simultaneous (or near simultaneous) use of data by the collaborating parties. Files
can be shared and operated on during on-line sessions, or comment/markup software can be used
in conjunction with rapid file exchange. Shared windows allows passing of control for creation
and modification. GroupWare and video or telephone conferencing capabilities can support
multiple participants. E-Mail and file transfer are also used, but in a more time-critical sense
than is true of simple data exchange.
A2.10 Digital Data Exchange
This is a simple transfer of digital data between parties, either through a physical send/receive
operation, or through access-in-place. The purposes include review, comment, status, approval,
or as input to a task. The sense of such transfers is that they support serial tasks that are not
necessarily time critical. The data is contained in files, and is sent point-to-point either following
a transfer protocol (e.g., ftpFile Transfer Protocol), or as an attachment to an E-Mail message.
In the case of specific business transactions, the conventions of Electronic Data Interchange
apply, with several options (e.g., ANSI X12, UN/Electronic Data Interchange For Administration
Commerce And Transport [EDIFACT]) available that often have significant incompatibilities.
A2.11 Information Architecture
Consideration must be made for an Information Architecture element that supports business
policies and company procedures. This elementwhich requires additional development based
on user feedbackcontains appropriate Document Type Definitions (DTD) to manage textual
data and Data Models to manage database applications in general.
A2.12 Product Data Management
The Product Data Management (PDM) element ensures that the data to be used, transferred, or
shared is the right data, i.e., that it is correct, complete, consistent, current, and pertinent to the
product configuration and information package version of interest. A work step enabled by
perfect telecommunications, controlled access, and collaboration support will have an

A-8

unfortunate result if the input data is wrong. In a simple process with a few very knowledge
users, PDM may be a minimal requirement. However, it becomes increasingly necessary as the
size and complexity of the project and the numbers of users grow, and as the information space
that must be accessed becomes larger.
Product data management in the broad sense addresses all data that directly or indirectly supports
the concept exploration, design, fabrication, assembly, testing, and life-cycle support of a
product, including primary and derived requirements and cost/schedule information that supports
tracking of progress and timely corrective action when required. Successful organizations of the
future will have such a capability. It will seldom be implemented as a whole, however, but will
usually evolve from the legacy environment of today, in a judicious and cost effective manner.
Critical first steps include robust file and document management. The scope of the data
addressed by PDM will vary among organizations, based on varying definitions of what
comprises product data. Wherever the boundaries are drawn, there must by effective links
between PDM and those systems that manage data related to other critical aspects of an
enterprise, such as schedules, costs, and shop floor, as well as systems of customers and partners
in the virtual enterprise.
A2.13 User Applications
If information is to be well used in the target business process, the user(s) must be able to apply
appropriate application software to it to create, analyze, modify, simulate, or otherwise affect
the information deliverable that is the output of the business process. This software may address
data of a technical or a business aspecte.g., a CAD/CAM modeler or an EDI transaction
generator.
There are as many application packages as there are processes and users. Some are so generic
that they may better identified as an Infrastructure Desktop Element, such as Microsoft Excel.
Some are very much discipline specific, such a finite-element modeler. In any case, the
applications provide the mechanisms to the end user to form and finalize the ultimate deliverable
of the business processthe information product or package.
A2.14 Infrastructure Elements
There is no definition of infrastructure that has a wide consensus. The term as used here
comprises the many elements that address underlying capabilitiesoften mundane and taken for
grantedthat must function harmoniously to allow the more visible or specific processes and
tools to operate effectively, or at all.
A2.15 Telecommunications
This element addresses the physical connection between the parties of a data exchange or shared
session. Options include the Internet, direct lines or private networks, and dial-up. These
provide a spectrum of bandwidth, reliability, privacy/security, and cost.
A variety of
communications protocols, hardware, and software are available, each with its strengths and
weaknesses. Whatever options are chosen, the user should be aware that incompatibilities
abound, even between sub-elements that are perfectly suited to meet specific requirements. The

A-9

performance of the telecommunications element depends on the compatibility and harmonious

operation of its various parts. Related topics for additional information include Open System
Interconnection (OSI), Integrated Services Digital Network (ISDN), Asynchronous Transfer
Mode (ATM), Systems Network Architecture (SNA), Synchronous Data Link Control (SDLC),
Transmission Control Protocol/Internet Protocol (TCP/IP), and Ethernet.
A2.16 Desktop
These tools provide the basic capability to author information deliverables, including text,
graphics, and tables. Standard office software such as Microsoft Office that includes word
processing, spreadsheets, and presentations (graphics) is a good example of a desktop tool. Also
included is basic electronic mail. Related subjects for additional information include ComputerAided Design (CAD), Standard Generalized Markup Language (SGML), Computer Graphics
Metafile (CGM), and Consultative Committee for International Telegraph and Telephone Group
4 (CCITT Group 4).
A2.17 Hardware and Operating Systems
These elements include the end user devices (personal computers, X-terminals, etc), application
and data servers, data storage devices, printers and plotters, video conferencing equipment,
routers, etc., as well as the system software that controls the specific operations of the hardware
in executing user and application software commands. See also UNIX, POSIX.
A2.18 Policy and Standards Elements
If collaborative teams are to successfully create, access, and use information effectively, they
must be able to exchange and share this information very readily, with a minimum of translation
of format or content. The only way in which this can occur is that there be generally accepted
data content and structure for all aspects of data exchange, and that these standards be followed
uniformly by all members of the virtual team.
The policy element is simply the set of policies, guidelines, processes, procedures, and standards
that management has accepted and decreed as the way to do business. It is absolutely essential
for success. It must also include a mechanism to clarify ambiguous situations that arise, and
address new or changed circumstances that might affect the agreed operations.
Standards selected as the basis of information exchange and effective use must avoid, except as a
last resort, those that are company- or vendor-specific. Here follows a list of baseline nonproprietary (neutral data format) standards supported by the U.S. CALS Industry Steering Group.

Standard Generalized Markup Language (SGML)markup requirements, tagging and

generic style specifications for page-oriented document text.
Initial Graphics Exchange Specification (IGES)a neutral file format for the
representation and transfer of production definition data among CAD/CAM systems and
application programs.

A-10

Standard for the Exchange of Product Model Data (STEP)a computer- interpretable data
representation format under development to include all product model data necessary to
define geometry, function, and behavior of a product throughout its life-cycle.
Consultative Committee of the International Telegraph and Telephone/Group 4
(CCITT/GROUP 4)the efficient compression of scanned raster images. Uses the code
from the Group 4 facsimile recommendation of the International Telegraph and
Telephone Consultative Committee. A 'tiled' form is described by using the architecture
nomenclature of International Standard, ISO 8613.
Computer Graphics Metafile (CGM)a neutral data format for the description, storage,
and communication of graphical information.
Interactive Electronic Technical Manuals (IETM)prescribes the requirements governing
the creation of interactive electronic technical manuals and the development of
presentation software applicable to a computer-controlled Electronic Display System
(EDS).
Electronic Commerce/Electronic Data Interchange (EC/EDI)the electronic interchange
of business information between trading partners.
Uses standard formats currently
defined by ANSI X12 in the U.S. (with migration to EDIFACT by 1997), EDIFACT in
Europe, Association Europeene des Constructeurs de Materiel Aerospatial (AECMA)
2000 for NATO.
Contractor Integrated Technical Information Service (CITIS)contractor provided service
for electronic access and/or delivery of contractually committed business and technical
information on a need-to-know basis.

In addition to these, other areas requiring standards are emerging, addressing the interoperability
of key capabilities such as workflow management, CITIS, and Product Data Management. It
will be necessary that appropriate standards evolve in a timely manner so that disciplined process
integration can proceed at a pace consistent with the growth of global collaboration.
A2.19 Training and User Support Elements
The success of collaborative teams in executing business processes depends on how well they
understand these processes, and on how effectively they can apply the supporting processes and
tools through which the information products are developed and provided to the customer.
Adequate training must be provided that addresses these items, as well as the overall policies,
guidelines, procedures, and standards that have been agreed upon. Equally important is a
sufficiently large expert support staff that provides direct support to the teams and individuals as
they apply the tools and execute the processes and procedures. This is especially true during the
initial operations of the enterprise, and at times of major modifications to policies, processes, or
tools.

A-11

A2.20 Multi-Disciplinary Work Groups

In the future NATO CALS Environment development work is assumed to be undertaken by
Multi-Disciplinary Groups (MDG), (or Integrated Project Teams), using a systems engineering
methodology, and self regulating, iterative processes, to reduce costs and time scales and
improve product quality. This approach is sometimes known as Concurrent Engineering.

A-12

APPENDIX B: NATO CALS DATA MODEL EXPRESS G DIAGRAMS

AND EXPRESS DEFINITIONS

This Section was Intentionally Left Blank

B-2

APPENDIX C: TLBM V 6.01 ACTIVITY DEFINITIONS

C1.0 TLBM V 6.01 ACTIVITY DEFINITIONS

Activity Name
MANAGE A
DEFENSE
SYSTEM
THROUGH LIFE
ESTABLISH AND
CONTROL DS
PROGRAM TL
ESTABLISH AND
CONTROL THE
REQUIREMENT

Table C-1 TLBM Activity Definitions

Activity
Activity Definition
Number
A0

A1

A11

DEVELOP LC
STRATEGIES AND
POLICY

A12

DEFINE LC
STRATEGY AND
POLICIES
DEFINE
ACQUISITION
STRATEGY

A121

DEFINE RISK
STRATEGY

A123

DEVELOP ILS
STRATEGY

A124

A122

Activities needed to create resource and manage the

organization, or organizations needed to obtain, use, and
dispose of the DS over its life-cycle.
This activity takes the VMN, the Business directives, the
Usage and Support Policy and any recommendations for
change arising from within the DS program activities and
develops, and sustains a Current Requirement statement, to
the level of detail needed to execute the DS program.
Requirement change proposals are assessed, approved, or
rejected, seeking external agreement where necessary. The
valid current requirement is released for use.
Configuration of the requirement statement, and the
requirement history are maintained as required.
Develop and implement an integrated suite of policies and
strategies for managing the DS over its life-cycle. These
strategies will shape the development of the program
organization and establish the framework within which the
Program Directives are developed.
This activity establishes a consistent and integrated set of
high-level policies and strategies to guide the management
of the DS program over its full life-cycle.
The approach to be taken in acquiring a service or DS
component, initially and for re-supply. It should cover the
method of acquisition, the rent, make or buy policy, the
use of competition and or partnering arrangements, and the
contract incentive mechanisms. Particular attention should
be paid to ensuring continued satisfactory operation of the
DS after the contract closure, as this determines what rights
and what data must be acquired as part of the contract, or
separately
Development of the program approach to identifying,
assessing, and managing risk of failure to comply fully
with the VMN or Business Directives.
Develop a strategy and plan to show how ILS will be
implemented for the particular DS over its full life-cycle.

C-1

Activity Name
DEVELOP CM
STRATEGY AND
PLAN
DEVELOP QA
STRATEGY AND
PLANS

Activity
Number
A125

A126

DEVELOP CALS
STRATEGY AND
PLAN

A127

ESTABLISH and
RUN the DS
ORGANIZATION
MANAGE
PROGRAM
SCHEDULE

A13

ESTABLISH
ROLES and
RELATIONSHIPS

A132

PLACE AND
MANAGE
CONTRACTS

A133

A131

Activity Definition
Develop a strategy and plan to show how CM will be
implemented for the particular DS over its full life-cycle.
Define the actions required to ensure systematic
approaches are taken to the integrated concurrent design,
manufacture, and support of the DS and the related
processes.
An assessment of the business and CALS Environment
facing the DS program, development of the program goals
for CALS and an assessment of the costs, risks, and
benefits of the options of CALS-implementation.
Set up and run an organization capable of delivering an
acceptable DS, that meets the Current Requirement.
Define the tasks to be performed and services to be
provided, in response to the Current Requirement and
Change Proposals (what to do), and monitor task
achievement. Develop a Program WBS or Task list.
Develop any Service Level Agreements needed to specify
the standard of ongoing services. The WBS or Task List
must reflect the work needed to assess the impact of
proposed change. Based on the implications reported,
decisions are made on which proposed changes to
implement or reject. The work required to implement
approved changes is reflected in the updated WBS or Task
list. Develop and publish top level Program schedules
showing when activities are to be undertaken. (Detailed
planning of tasks in other activity boxes is assumed to
occur locally.)
This activity establishes how responsibility for the various
program tasks is to be allocated over the life-cycle,
including the identification of tasks to be placed on
contract. As roles and relationships will change over time,
particular attention should be paid to the mechanisms for
incentivising and ending contracts and to the management
of transitional arrangements (e.g., on entry into service).
Action needed to place, operate and close contractual
agreements required by the DS program. It includes
generation of the contract requirements and the
development and operation of payment and incentive
arrangements.

C-2

Activity Name
DEVELOP
CONTRACT
STRATEGY

Activity
Number
A1331

ISSUE
SOLICITATION

A1332

ASSESS
PROPOSALS

A1333

RUN CONTRACT

A1334

MANAGE DS LC
FUNDING

A134

MANAGE HUMAN
RESOURCES
MANAGE DS
INFORMATION

A135

DEVELOP IM
PLAN

A1361

A136

Activity Definition
The process of programming, controlling, documenting,
and implementing the specific requirements levied by the
negotiated contract or agreement. This process includes
ensuring that the Staff Target, program objectives, and
implementation plans are incorporated in contractual
definitions and design information. In addition, it includes
programming available funding into the contractual
process through negotiations, incentives, and
modifications, and the initiation and execution of
appropriate agreements, which may fall outside of the
specific contract such as those between government units.
The specific contractual solicitation or tender is prepared
and Issued, including the Statement of Work, the
Evaluation Criteria, and the Contract Deliverables.
This activity encompasses all actions in assessing the
formal response to the solicitation or tender, prepared by
either a contractor or another government entity
responding to the solicitation, and in choosing the
successful bidder.
Activities required to place and operate the contract over
its lifetime, and, when required, to close it. This will
include assessment of achievement against requirements,
approval of payments, and resolution of issues arising.
Acquire, allocate, and account for the funds needed to
provide the DS through life. This is assumed to include the
task of forecasting and tracking DS Life-cycle Cost.
External data will be needed for this including cost of the
operator/users and their training. The extensive feedback
needed to capture costs and expenditure details over the
life-cycle are not shown in this model.
Plan, organize, monitor and control, the provision of
human resources for DS program life-cycle.
The act of constantly monitoring and updating both the
technical data requirements and the database support
structure that provides the through-life support the Defense
System.
Define the program Information and IT- infrastructure
requirements based on an analysis of user needs over the
life-cycle. Develop a plan for capturing, controlling, and
delivering the required information to users.

C-3

Activity Name
ESTABLISH AND
OPERATE
PROGRAM SDE

Activity
Number
A1362

PROVIDE
INFORMATION
SERVICES
COMPARE
ACTUAL SYSTEM
STATE AND
PERFORMANCE
WITH REQUIRED

A1363

OBTAIN DS

A2

A14

Activity Definition
Design, acquisition, deployment, and use of a Shared Data
Environment for the DS. (See NCOPS). Those activities
include analysis, acquisition, test, delivery, operation, or
management of hardware, software, and communications
systems.
The activities required to support users in entering,
maintaining, and using DS information stored in the SDE.
The comparison of actual system state and performance
with that required by the Current Requirement, Business
Directives, and Operational Program to identify the need
for changes. This comparison addresses both technical and
business aspects (e.g., will/can the aircraft achieve the
specified range; are in-service maintenance costs in line
with approved budgets, is the actual configuration in line
with that needed to meet the Current Requirement and
Operational Program?) This comparison will identify the
need for any changes to the Defense System itself, or to the
DS Program, required to address the VMN. (Changes to
the VMN are outside the TLBM) The comparison may
lead to the raising of a Changes Proposal, affecting either
the DS Design or the DS Program. Proposals may also be
generated to change the Current Requirement, either
directly or after assessing and rejecting the viability of a
Proposed Change to the DS. This activity will also address
the acceptability or otherwise of requests for waivers or
concessions for components which fall short of the design
intent. The activity also generates a report on the
performance of the DS and the DS Program (Perf. Rep)
and issues advice to Operators over specific design
limitations applicable as a result of shortfalls (e.g., a power
restriction applies until a suspect component is inspected).
The activities necessary to define, design, procure,
manufacture, and test a new or improved DS capability to
meet the Current Requirement. The activity includes the
assessment of conceptual options, procurement of systems
via integrated product development, the conducting of total
system testing prior to making the operational system
available for first operational deployment. It also includes
the refurbishment systems and re- testing of Systems or
components returned for recycling from the Operational
environment and the establishment of a Support Capability
which can sustain the operational system in use.

C-4

Activity Name
DEVELOP DS

Activity
Number
A21

DEVELOP
CONCEPTUAL
OPTIONS

A211

DEFINE DS

A212

ENGINEERING
DESIGN

A213

FAILURE
ANALYSIS

A214

Activity Definition
Develop possible realizable solutions to the Current
Requirement, to the appropriate level of detail. This
activity will be repeated to an increasing level of detail as
the solution evolves from a proposed DS concept to a full
definition of the DS to be produced. The DS solution must
address the intended operational system and the support
management arrangements needed to sustain the system in
use, including any special-to-type tools, facilities, and
support equipment needed for this purpose.
The action taken to review the operational threat and
Mission Need to identify and evaluate potential alternative
solutions. The activity applies to both the system and its
support, establishing in-service goals for operational
implementation of the proposed Defense System solution.
The evaluation will address cost, schedule, performance,
supportability, and technological feasibility to select the
conceptual solution, or options to be offered in response to
the defined operational need.
The functional design of the Defense System includes
analysis of the design features needed by the subsequent
manufacturing, transportation, use, support, and disposal
processes. From this analysis the required functionality of
systems, sub systems and components is derived, for both
the operational system and the support system, and
responsibility is allocated to the various elements within
the functional architecture, for meeting all aspects of the
overall system of performance, as defined by the Current
Requirement. Acceptance criteria for test (A23) and
evaluation (A37) are also defined. This activity also
decides what items can be bought in from suppliers (as
Goods and Services from Others), an which still require to
be designed.
The detailed engineering design activities to arrive at a
product model for the DS and its support equipment and
simultaneously define the manufacturing, refurbishment,
and disposal processes. The task includes the design of the
deployed system and of any special to type support tools,
equipment, and facilities.
Analyze failure modes, effects, and criticality to define
product anomaly, criticality, causes/effects, and
compensating provisions. Provide diagnostic and
troubleshooting recommendations. Predict the expected
frequency of failure and calculate expected reliability.

C-5

Activity Name
DESIGN THE
SUPPORT
SYSTEM

PREDICT LIFECYCLE
PERFORMANCE

Activity
Number
A215

A216

Activity Definition
Create the procedures and data needed to provide an
optimized support capability for the DS, to deliver the
readiness, sustainability, and availability required from the
operational system, at least life-cycle cost. This activity
will create procedures for operating, servicing, and
maintaining the Operational System, including diagnostics
and post repair tests. It will define intentions for managing
the initial and ongoing supply of materials, components,
and spares required for manufacture and in-service use.
This includes definition of the intended spares holding and
the development of procedures buying, holding, issuing,
and accounting for stock. Decisions on the form of stock
management (e.g., unique to the DS, by an Armed Force,
by National or NATO stock systems) and undertaking any
screening and codification activities form part of this task.
It will develop policies and procedures for the return,
assessment, refurbishment, and disposal of items no longer
required. It will develop policies and procedures for
supplying operators and maintainers with the information
they require to perform operating, servicing and
maintenance tasks, deciding whether to achieve this by
components built into the equipment, by access to the
SDE, by digital storage medium or on paper. It will also
generate or re- format any additional data required for
support, which is not already available from the SDE. It
will define what feedback is needed from operators and
maintenance staff to optimize the performance of the
support system, and develop procedures for data collection
and analysis. It will establish training requirements for
operators and maintainers. The support system design
activity will also identify requirements for special-to-type
tools, facilities, test, and training equipment, the design of
which is undertaken in A214.
Task of predicting the expected performance of the DS in
regards to all aspects of the Current Requirement and
Business Directives. This includes prediction of system
capability, life, availability, readiness, and life-cycle cost.

C-6

Activity Name
PRODUCE DS

Activity
Number
A22

CONDUCT
TESTING

A23

DEPLOY DS

A24

SUPPORT THE
USE of the DS
PLAN SUPPORT

A3

STORE
TRANSPORT AND
ISSUE ITEMS

A32

A31

Activity Definition
The fabrication, assembly, and production testing of the
Operational DS, of related spares and components; of
engineering test models, breadboards, and prototypes and
of associated special-to-type tools, facilities, and test
equipment. The refurbishment of items returned from
service use to the original production standard, or as
otherwise defined, is also included in this activity, as it
requires similar facilities and data.
Process of measuring the performance of all DS
components (including software, hardware, and human
interface) for compliance with Current Requirements in
accordance with the Test Definition and Test Plan. The
Testing function also applies to the supportability features,
processes and equipment (e.g., a test of the Maintenance
Procedures and Tools). Normal production testing, applied
routinely to each new item, is included within A22
(Produce).
The activities needed to, receive, process, and transport
new Operational DS, support equipment, or components,
from the manufacturing environment to the location from
which they will normally operate, or be stored. NOTE: the
operational activity of deploying a DS from its peacetime
base to another operational environment, as part of a Task
Force, is not included in the TLBM as this requires
integration with other systems and activities beyond the
scope of this model.

Decide what work to do, in what order, on the systems

awaiting support action. The plan will include
specification of the required configuration for each
individual system. The Plan Support activity also
generates a requirement for items to be purchased for use
in support activities.
The storage and issue as required of items needed for
maintenance or to support the DS on operational use.

C-7

Activity Name
MAINTAIN,
UPDATE AND
PROVIDE
FEEDBACK

Activity
Number
A33

O&S TASKS

A34

MANAGE
FACILITIES
TRAIN SUPPORT
STAFF

A35

CONDUCT
EVALUATIONS

A37

DISPOSE or
RECYCLE

A4

A36

Activity Definition
Perform the work needed to restore the DS to the condition
required for the next intended operation (except for O&S
tasks), by diagnosing, repairing, testing, and calibration the
item in accordance with the Core Product Data and
Support Information. Implement updates and
configuration changes in accordance with Required
Support Actions. Provide maintenance feedback on
findings, action taken, and issues arising. Update current
configuration to reflect work done.
(Non maintenance) activities needed to prepare the system
for operations e.g., fuelling, tow from hanger, empty waste
tanks etc.
Activities needed to sustain the special to type facilities
and tools in a fit for use condition.
[IEEE Std 1220-1994] The tasks, actions, and activities to
achieve and maintain the knowledge and skill level
necessary to efficiently and effectively perform operations,
support, and disposal.
The evaluation of a DS operational and support capabilities
based on both predetermined criteria and needs evolving
from operational experience. These evaluations include
analysis of existing data derived from operations and the
collection and analysis of data to support a particular need.
Conclusions and recommendations are documented as
evaluation findings.
Activities related with the retired Defense Systems and DS
components for disposal or refurbishment. Items for
refurbishment or recycling are returned to A2. Items no
longer needed are disposed of. Asses the state of the item,
decide whether to refurbish for use within the program,
make it available for use by others (sell or re-allocate to
other program) or scrap as waste.

C-8

C2.0 TLBM 6.01 ICOM REPORT

Arrow Name
Acq Strat
Activities to be
contracted
Allocated
Manpower
As-built
Config
As-maint
Config
Available
Funding
Budget Req

Business
Directives

CALS Strategy

Change Impact
Change
Proposal
CM Strategy
Contract Dir.

Contract
Information
Req
Contract
Strategy

Table D-2 ICOM Report

Arrow Definition
An acquisition strategy details the intended approach to obtaining the Defense
System capability, initially and for upgrades.
Definition of the tasks to be undertaken, and services to be provided by
contract.
Allocation of available manpower resources to organizational units and plans
for providing trained people
The full configuration definition of each DS post production or refurbishment.
The configuration definition of the DS following maintenance. This definition
would also include the reporting of configuration problems and anomalies.
Actual funds, available to the DS program, after approval and release by the
Financial Management function.
Defense System specific requests for funding, in the form of budget
requirement requests to the external authorities responsible for the program
Business Directives.
Program specific business requirements and constraints placed on the LCowner by his tasking body, matched by appropriate resources. Resources are
assumed to be defined in terms of an allocated Budget for a DS, based on
annual cash limits plus a target or acceptable range for whole Life-cycle Costs.
These provide the input from which the program goals, priorities, and budget
are derived. This should include any directives for international co-operation.
The CALS strategy defines how to change the way business is conducted
today through replacement of traditional paper-based processes with digital
electronic processes, global data definitions and standards development, and
continuous process improvement.
Assessment of the technical implications of a proposed change to the DS, or of
an off design condition, arising in production or in-service use.
A proposed change to the DS or the DS program to correct a state or
performance shortfall. This may include a request from within the DS
program to change the requirement itself.
Strategy, Policies and plans for achieving adequate control of DS
configuration through life
Instructions to staff on actions they need to take in regard to DS contracts.
This may include supplying information, checking progress, or assisting the
contractor to perform elements of the work.
The information requirements to be included in DS program contracts.

details the intended approach to acquiring goods and services from industry
over the Life-cycle

C-9

Arrow Name
Contracts and
ITTs

Contracts and
Requests

Core Product
Data

Current Req

Def. Pol. and

Stds
Disposed Items
DS Concept
DS Data to
Others
DS for
Deployment
DS needing
support

Arrow Definition
Contracts and/or Invitations to Tender for the provision of goods or services to
the DS Program Contract. A mutually binding legal relationship obligating the
seller to furnish the supplies or services (including construction) and the buyer
to pay for them. It includes all types of commitments that obligate the acquirer
to an expenditure of appropriate funds and that, except otherwise authorized,
are in writing. In addition to bilateral agreements, contracts include, but are
not limited to, awards and notices of awards; job orders or task letter issued
under purchase orders, under which the contract becomes effective by written
acceptance or performance; and bilateral modifications. Invitation to Tender
(ITT). An ITT is a package of documents issued by the MOD to potential
contractors, which invites bids for the supply of goods or services against a
defined set of terms and conditions and technical specifications.
Contracts or Request for action from organizations or entities not directly
controlled by the DS Life-cycle Owner. This may include: contracts to
industry, training requirements, request for changes to other DS, facility
change requests, proposed changes to imposed, constraints including requests
for additional funding and proposed new common tools.
Information to define and describe items, components, assemblies and systems
to the level needed by those who will operate and support the system inservice. It includes the identity, version, definition, properties, classifications,
and characteristics of all parts likely to be exchanged during the in- service life
and the assembly structure of the Defense System (the Design Configuration)
including permitted options and variants.
Current Requirement The latest approved statement of the functional and
interface requirements for the DS, including the definition of the intentions and
requirements for operational use and support (Use Study). The Current
Requirement is also assumed to reflect approved changes. (Instructions to
implement changes, either to the system design, or to specific systems, are part
of Program Directives). The level of detail in the Current Requirement will
grow over time. It will range from the Validated Mission Need, at the program
outset, to the full technical specification of the product to be produced or in
service. The Current Requirement is assumed to be managed as one or more
CIs, in its own right. The history of requirement changes will be maintained
over time, and made available, where needed, through the SDE.
Defense Policy and Standards Defense Standards, Policies and Directives
applicable to the DS program.
All, or any part of a DS, or waste it has generated, which are no longer
required for operations and is to be removed from DS Program control.
Selected Concept, or Concepts, to be further developed into a full design.
All data relating to the DS required by external authorities. This includes:
reports on achievement v target
A new DS or component ready for initial deployment.
The Operational Defense System requiring support, as returned from
operations.

C-10

Arrow Name
DS ready for
Ops
Eval Def
Evaluation
Findings
Existing
Business Info

Existing
Infrastructure
External Data

Feedback fm
Maintenance

Feedback fm
Ops
Financial
Implication
FMECA Data
Functional
Architecture

Goods and
Services fm
others
ILS Strategy

Arrow Definition
DS ready for Operations
Evaluation Definition: The criteria and specific manner in which evaluations
will take place.
The documented results of an evaluation of a DS
Existing Business Information: Data, needed by the LSA activity, from
external sources. This may include government- provided list of approved
LSA tools, standard supportability data such as labor costs at each echelon,
existing documented historical data, etc.
Facilities Systems Tools
Data from other Systems or Authorities needed by the DS program. Other DS
program Schedules, Policies, WBS, Budgets and Organizations (A131/2/3),
Data on other Contracts and Contractors (A134), Personnel information
(A135), extent of and experience with existing Info Systems (A136) Data
needed for Support Design (A215) including historical data, predecessor data,
independent study data, health, safety or environmental data and data on
existing tools, facilities, components and parts. Current locations holdings of
other equipment and spares (A24)
Feedback fm Maintenance Feedback of information arising from maintenance
activities. This may include reporting of defects found, actions taken,
resources used and proposals for design or support system changes. It must
include the Current Product Structure (Configuration) post maintenance.
Feedback from Operators Ops History Survey Results State, Failures,
Deficiencies Changes made
Report of the financial implications of the program WBS, including proposed
changes.
Description of possible failure modes for the DS, with their likely
consequences and frequency of occurrence.
An arrangement of functions and their sub functions and interfaces (internal
and external) that define the execution sequencing, conditions for control of
system data flows, and the allocation of performance requirements to each
functional element within the operational and support systems, to satisfy the
overall system requirement. Support influence on design is achieved through
the allocation of requirements in the functional architecture
Goods and Services from others

The formal planning document for the integration of the activities concerned
with logistics support. It is kept current throughout the project life. It sets
forth the concept of operational support, provides a detailed ILS program to fit
with the overall program and results in the necessary ILS information required
by decision making bodies to make sound decisions in the system development
and production.
C-11

Arrow Name
IM Plan
In Service
Goals
Information
Services
In-Scope Eval
Findings
Inst to Ops
Invitation to
Tender

Items for RFB

Items for Test
Items for Use
Laws and Gov
Policy
LC Strat and
Pol.

Maintained DS
Mfr and Rfb
data
Ops Prog
Org Structure
Perf Rep

Predicted LCC
Predicted Perf

Arrow Definition
Plan to manage information over the LC
A statement of general utilization intentions for a Defense System including
reference to national or co-operative logistics and training arrangements.
Provision of Information services which cannot be provided directly through
the SDE itself e.g., archiving, retrieval of historic records, special reports, new
applications, new hardware, help desk services etc.
In-Scope Evaluation Findings: Evaluation findings that indicate a requirement
to change Operational Support Instructions or Operational Support
Requirements that do not effect existing system plans or strategies.
Instructions to Operators
A formal request for a proposal from a contractor upon which a contract for
goods or services could be based. It includes, either directly or by reference,
all of the technical, commercial and legal information needed to establish and
operate a successful contract.
Items for Refurbishment Items removed from operational service and returned
for reconditioning or repair
Items removed from for test
Spares and other consumables supplied for incorporation into the main
equipment, (this includes the on board stock where appropriate)
Relevant Laws and regulations from beyond the Defense environment
The set of documents which provide the DS program team with policies and
strategies for managing the acquisition and support of a DS in a consistent
manner over its life-cycle. It includes: Acquisition Strategy (Acq Strat)
Quality Management Plans (ImpPlan) ILSPlans
DS after completion of the maintenance tasks, awaiting preparation for
deployment on mission
Manufacturing and refurbishment data: information needed to manufacture,
refurbish or dispose of the DS and its associated components
Program of the DS when deployed on operational missions
Organizational Structure of the DS project
The currently achieved (or predicted) performance of the DS in relation to
Current Requirement and Business Directives, highlighting any actual or
expected shortfalls in technical or financial performance.
Prediction of the expected Life-cycle Cost of the DS
Predicted Performance of the DS, in relationship to all aspects of the current
requirement

C-12

Arrow Name
Prg Dir

Proc Spec

Program
Schedule
Program SDE

Program WBS

Project Pers

QA Strategy
Req Config

Req Feedback
Requests for
Assistance
Required Items
Returned Items

Arrow Definition
Program Directives: Program management directives generated within the DS
Program, issued to set up the DS Organization and to control the work of staff
who can be tasked directly by the DS Life-cycle Owner. (other resources are
obtained or tasked through Contracts and Requests) Program Directives
include the Organizational Structure and approved budgets, WBS, program
plans, make or buy plans, instructions to buy, change authorizations and all
other forms of instruction used to make things happen on the program. The
Program Directives also communicate the specific policies, procedures and
plans established by the DS program and approved by the Life-cycle Owner.
Technical or functional definition of Items to be purchased, to the level of
definition needed to enable contract action to proceed. Note: Instruction to
place orders for specific Items of Supply are provided from two sources: the
Program WBS, for initial acquisition or from Plan Support, for re-supply, as
Required Items.
Plans showing what activities have to be performed when, to meet DS
Program requirements.
The hardware, software and communications and information infrastructure
needed to enable participants in DS program to access the information they
require to conduct the business processes illustrated by this TLBM.
Definition of the activities to be performed to deliver (or dispose of) a
successful DS. This may take any form. Typical outputs would include a
formal work breakdown structure, a Task list, or a series of Service Level
Agreements for ongoing tasks. Changes to the DS and to the work program
are initiated by changes to the Program WBS.
Project Personnel Staff from industry, government, or the Armed Forces who
is supplied to work on the program, potentially as part of a Multi Disciplinary
Team or Integrated Project Team. Will include operational user on temporary
deployment to the DS program to provide their experience or evaluation skills.
People supplied as a resource are trained and educated adequately except in
regard to the DS itself.
Details the intended approach to implementing an integrated systems approach
to Quality through the DS life-cycle.
The required configuration state of a specific DS to be achieved by the
maintenance activity. This would define the desired operational configuration
required for a particular mission (e.g., fit the long range fuel tanks), and
indicate what approved changes/modifications were to be incorporated during
a specific maintenance session.
Required Feedback
Requests for assistance from or action by parties beyond the control of the DS
Life-cycle Owner (e.g., the owners of other DS, the Armed Forces, External
training authorities, the Department of Defense [DoD], etc.).
The identity, quantity, and required delivery details for purchased items
needed to support the use of the DS.
Items for recycling or disposal

C-13

Arrow Name
Risk Mgt
Strategy
SDE Req.
Selected
Contractor
Spares and
Components
Support
Equipment
Requirements
Support Info

Support Plan
Test Def

Test Findings
Tools and
Facs.
Trained People

Trg Req

Usage and
Support Policy
Users

Validated
Mission Need

Arrow Definition
Details the requirements and intended approaches management of program
risk over the life-cycle.
Requirement Statement for the Program SDE
Spares and components obtained for use in support activities.

Requirements for special-to-type support equipment, tools, training equipment,

and facilities required to support the DS.
Support information provides the directives and data required to support the
DS in-service. It includes: maintenance policy and maintenance procedures
including, task descriptions and resources needed (skills, tools, parts etc);
diagnostic, calibration and test procedures; supply support policy and
procedures e.g., supply policy, stock holdings, initial stock buy, stock
management and provisioning procedures, provisioning data, codification data
return, assessment, refurbishment and disposal instructions.
Instructions (short term) and plans (longer terms) defining the work to be
undertaken on specific DS or DS components requiring support.
Test Definition: Test objectives which are based on DS specifications and
program requirements that define the parameters on which the qualification
and quality tests are based.
The results of comparing actual results with identified performance,
functional, and logistic specifications.
The special-to-type tools, test equipment, and facilities created for the DS.
Trained personnel destined for logistics support activities, in the right number,
and to the required capability. Trained personnel contribute to the
requirements fulfilled to customer satisfaction and also flowed back to the
resources.
Training Requirements A specification of the training needed by the operators
and maintainers of the DS, plus a request to the training authorities to provide
the necessary training in a time scale required by the program.
Constraints, requirements or policy guidance relating to the operation or
support of the DS in service, placed on the program by the known or potential
users of the System
The designated user of the proposed system (maintainers, operators,
repairmen, commanders, etc.) provided to contribute to, or assess the evolving
product and support design.
A statement based on a mission analysis, identifying in broad outline a
quantitative or qualitative operational deficiency that cannot be solved
satisfactorily with existing forces or equipment. The mission need is
constantly re-evaluated throughout the life of the Defense System and may
change over time. The VMN will also define any requirements for
interoperability with other DS.
C-14

APPENDIX D: PRODUCT, PROCESS, AND DATA INTEGRATION

D1.0 INTRODUCTION
This section presents an overview of the CALS standards including their purpose, current status,
and implementation issues. It concentrates notably on:

Digital Representation for Communication of Product Data: IGES Application subset.

Markup requirements and Generic Style Specification for Electronic Printed Output and
exchange of text (SGML).
Hypermedia Time-based document structuring language (Hytime)
Digital Representation for Communication of Illustration Data: CGM Application
profiles.
Standards for the exchange of product model data (STEP).

D2.0 DIGITAL REPRESENTATION FOR COMMUNICATION OF PRODUCT DATA:

IGES APPLICATION SUBSETS AND IGES APPLICATION PROTOCOLS
D2.1 Purpose
Initial Graphics Exchange Specification (IGES) is the standard specified by the American
Society of Mechanical Engineers (ASME), standard Y14.26M, for Communication of Product
Definition Data.
D2.2 Scope
Five basic classes of the IGES standard (technical illustrations, engineering drawings,
electronic/electronics applications, numerical control manufacturing, and 3D piping) should be
considered for this discussion as opposed to the entire IGES standard. IGES is large and
complex, with different options that may be used to represent the same Computer Aided Design
(CAD) model entity. As a result, CAD software vendors seldom support every IGES entity in
the specification, but support a subset of IGES that best matches the features of their CAD
system. Invariably, there is a mismatch between the set of entities by one CAD system's
pre-processor and another CAD system's post-processor. There is no guarantee that the
intersection of the two different CAD systems' supported IGES entities is adequate for the
required data transfer.
D2.3 Application Subsets
The first four classes specify the entities needed for specific application subsets. In this way, the
recipient of an IGES data file may specify the class of data needed without becoming an expert
on the IGES.
The subset concept addresses many of the user's problems, but is not an entire solution. One
difficulty is that the subsets address the needs of applications by directly specifying the particular
IGES entities to be included in the subsets, but do not include enough information on how to use
those entities to transfer all the product data typically needed by that application. Most IGES
entities are general purpose in nature. They can be combined to create constructs needed for

D-1

product data transfer, such as a circuit in an electrical application, but they do not rigorously
define how this is done. This can be a problem in transfer, because unless the receiving system
knows how the IGES entities were combined to create the construct, and has a rigorous
definition of the meaning of the construct, that receiving system will not be able to interpret the
construct. The basic data is translated, but not all the information needed to translate product
data for the application is transferred.
The four application subsets are described in the following paragraphs:
D2.3.1 Class I: Technical Illustrations Application Subset.
The Class I application subset is for the exchange of illustrations for technical publications. The
emphasis is on the visual appearance of the illustrations, not on the functionality of the entities
within the class. Class I is a two dimensional subset with limited non-geometric information
(such as subfigures).
D2.3.2 Class II: Engineering Drawings Application Subset
The Class II application subset is for the exchange of product data (Technical Data Packages,
General Specification for). The emphasis is on completeness, functionality of the drawing
model, and visual equivalency for human interpretation. The class contains many geometric
entities, annotation entities and attributes such as color and line fonts, along with organizational
information such as levels and subfigures. The geometric entities in this class are three
dimensional, though two-dimensional data can be transferred by placing all the information on
the same plane within the sending CAD system.
D2.3.3 Class III: Electrical/Electronic Applications Subset
The Class III application subset is for the exchange of product data for electrical and electronic
products.
The emphasis is on completeness and functionality of the model for design,
manufacturing and testing. Class III supports both the logical product representation and the
physical product representation, which can both be in the same file. The logical representation
includes net lists and schematics, while the physical representation includes assembly placement
and pad layouts. Class III is difficult to use for unambiguous data exchange without further
restrictions and interpretations applied to the subset. The IGES/PDES Organization (IPO)
Electrical Applications Committee (AEC) is developing a Layered Electrical Products (LEP) AP
for the representation of electrical products. The LEP AP is currently planned to be a
replacement for MIL-D-28000 Class III.
D2.3.4 Class IV: Geometry for NC Manufacturing Application Subset
The Class IV application subset is for the exchange of product data for manufacturing by
numerical control. The emphasis is on the completeness and functionality of the part model.
Geometry data is either 2-D wireframe, for profiles or sheet metal, or a 3-D wireframe model, for
multi-axis machining. Precision and accuracy on the wireframe and surface geometry must be
maintained, as well as first order continuity. Geometry and Text form the majority of the data
for this class.

D-2

D2.4 Application Protocols

An Application Protocol (AP) is a way to transfer defined product data through IGES. An AP
documents the user requirements for an application in a graphical model called an Application
Reference Model (ARM). The requirements in the ARM are then represented by specific IGES
entities in a given AP (the AIM). APs enable IGES to be used to transfer product data reliably
until PDES/STEP is available from the commercial CAD vendors. APs provide a defined and
more reliable method for transferring product data through IGES.
An AP is composed of the following elements:

a scope and requirements section;

an Application Reference Model (ARM) of the supported information that explains what
is covered in the application and how the different elements relate to one another;
an Application Interpreted Model (AIM) that shows how the information is mapped into
IGES entities;
and Conformance Requirements and Abstract Test Purposes.

APs are very specific in nature. For example, the 3D Piping AP (Class V) exclusively supports
the exchange of product data for 3D piping system models. It does not support piping
engineering drawings. A user wishing to transfer an engineering drawing of a piping system
would have to use an Engineering Drawing AP.
In addition, only CAD/CAM systems
supporting piping will be able to support the piping AP. A CAD/CAM system that does not
support piping just does not have the appropriate constructs within its' database to either output
data in the Piping AP, or input the data reliably. APs will provide increased information transfer,
but with a much narrowed scope in the information that is transferred.
D2.5 Implementation Issues
Most IGES entities are general purpose in nature. They can be combined to create constructs
needed for product data transfer, such as a circuit in an electrical application, but they do not
rigorously define how this is done. This can be a problem in transfer, because unless the
receiving system knows how the IGES entities were combined to create the construct, the
receiving system may not be able to interpret it. The basic data will be translated, but not all the
information needed to translate product data for the application will be available.
D3.0 STANDARDIZED GENERALIZED MARKUP LANGUAGE
D3.1 Purpose
Standardized Generalized Markup Language (SGML) establishes requirements for the digital
interchange of technical publication text. Data prepared in conformance to SGML will facilitate
the automated storage, retrieval, interchange, and processing of technical documents from
heterogeneous data sources.

D-3

D3.2 Document Type Definition

The CALS SGML standard defines both a methodology and a high-level computer language for
document representation. It provides a coherent and unambiguous grammar and syntax for
describing whatever a user chooses to identify within a document regardless of the type of
document or the nature of the document's text and provides a formal markup procedure, also
independent of system and output environments for this purpose.
The definition of the
document's structure or content in terms of elements, their attributes, entities, and other
components is a called Document Type Definition (DID). A DTD defines the structure or
content of a specific class of documents.
D3.3 SGML Markup
"SGML markup (or an SGML document instance") consists of unformatted text with inserted
SGML tags which correspond to the elements and attributes of the DTD. These tags identify
elements of the text (e.g., titles, paragraphs, tables, footnotes) defined in the document's DTD.
The marked up document (or SGML document instance) can then be parsed using special
software to determine if the document's tagging conforms to the DTD.
In order to format an SGML source file, associated formatting information must be provided.
This associated formatting information must define formatting characteristics such as a page
model, font and family characteristics, point size, indenting, etc. In addition, these formatting
characteristics must be responsive to certain SGML tags. For example, a paragraph tag may
trigger a change in the line leading or a chapter title tag may trigger bolding and center
functions. The associated formatting information are provided in the form of an Output
Specification (OS) DTD.
D3.4 Output Specification
The Output Specification (OS) DTD defines a finite set of formatting characteristics used to
rigorously describe the composition processing functions to be performed with respect to the tags
of an SGML source file. A Formatting Output Specification Instance (FOSI) is an instance of
the OS DTD. The FOSI defines values for the formatting characteristics defined in the OS DTD
for every SGML element used in the document DTD, taking into account every context in which
the SGML element has a unique formatting requirement. In example, a title of a TM chapter is
formatted differently than a title of a TM subparagraph. The objective of the FOSI is to
rigorously define the format style of the document to be produced from the SGML tagged source
file, as required by the appropriate functional specification.
A FOSI should be developed for each DTD to describe all default formatting characteristics
necessary to compose and publish a document authored according to that DTD. The FOSI
should be delivered with the SGML source tagged file. Since all FOSIs will be written with
respect to the standard OS (paper medium), vendors will be able to develop software that can
accept and process FOSIs and interface with the publishing software.

D-4

D3.5 Electronic Review

MIL-M-28001B provides a mechanism which enables an electronic review and comment
capability for SGML tagged source files. This capability allows reviewers located in diverse
environments to make and exchange comments electronically on multiple copies of a document
file over a network. The comments may then be sorted, processed, and incorporated into the
document by the file owner.
The mechanism for electronic review of SGML tagged source files consists of certain SGML
constructs which are incorporated into a DTD for a given document type. These SGML
constructs have been defined as generally as possible to take into account the many kinds of
reviews: internal contractor reviews, Government reviews, contractor/Government reviews,
specification reviews, etc.
Plans for future extensions of electronic review include both a CALS graphics comment
capability using SGML tagged for the comments, and a capability to link SGML text and CALS
graphics files for related changes. Efforts will also be made to develop a more precise
addressing mechanism for indicating the location within document elements of a proposed
change.
D3.6 Partial Documents
Partial document delivery is used to transmit source SGML tagged source data either as an
interim deliverable or as an update package containing data for a document that has been
previously delivered. Its purpose is to minimize the retransmission of unchanged data or to
indicate incomplete data. Partial document delivery is not intended to address the issues of page
integrity or fidelity, nor is it intended to include specific change pages. The intent of this
methodology is to allow the delivery of certain portions of a source document such that the
receiving system can identify the location of the information in the original document and
perform the appropriate addition, deletion, or replacement operations. Both the manner in which
this is accomplished and the effect of the change on composition depends on the receiving
system.
D3.7 NATO CALS SGML Registry/NATO CALS SGML Library
The NATO CALS Organization is investigating the requirements for the development and
maintenance of a NATO CALS SGML Library (NCSL).
It is envisioned that a NATO CALS SGML Registrar will administer the NATO CALS SGML
Registry (NCSR), a central registry office where DTDs and FOSIs will be registered. The NCSR
will maintain a NATO CALS SGML Library which will be an on-line database containing all
SGML elements and attributes that have been defined, with cross references to DTDs and
governing military specifications. The NATO CALS SGML Registry will require adherence to
basic guidelines for acceptance of SGML tags/attributes. Some of these guidelines are:

Querying the NCSL for a suitable registered DTD in lieu of developing a new DTD

D-5

If a new DTD is to be developed, compare tag requirements with the tags currently
registered in the NCSL. Utilize generic elements as much as possible. For example,
the requirement for a group assembly parts list can utilize an existing NCSL element
pl (parts list). Accordingly, the NCSL should not contain redundant elements, i.e.,
different tags for the same information.
If no existing NCSL element is deemed suitable, develop a new element and submit it to
the NCSR for inclusion into the NCSL. The NCSR will require that the element be
unique (i.e., no existing NCSL element will suffice); that (if possible), a generic tag name
be used to facilitate NATO-wide use; and that the tag name satisfy naming conventions
defined by the NCSR

D3.8 Software Tools

Currently, there are no tests for vendor products claiming conformance to MIL-M-28001. Such
MIL-M-28001 product conformance testing will depend upon the product's function. For
instance, conformance testing of SGML parsers entails the correct interpretation of ISO 8879.
Conformance testing of auto-taggers or authoring stations would be limited to determining
the parseability of the instances generated, and again would involve correct ISO 8879
interpretation. With few exceptions, there is no disagreement regarding the correct interpretation
of ISO 8879.
The vendor community is aware of the evolving nature of MIL-M-28001. Some vendors are
waiting until the standard is finalized, while other vendors are undertaking full implementations
at the present time. A large vendor community is represented on the Electronic Publishing
Committee.
For the CALS environment, vendors supporting MIL-M-28001 should not
hard-code their systems to process only a single DTD or FOSI. Certainly, most users will be
processing a variety of technical publications which must conform to multiple DTDs and will
require a system that can be configured to adapt to new and changing requirements as they arise.
Currently there are various types of SGML software products on the market. These include:

SGML parsers. Such parsers check DTDs for conformance to the SGML grammar and
syntax. They also check document instances for conformance to a given DTD. They
return error reports on errors found in the parsing process. Many other SGML software
packages (e.g., SGML editors) come with a built-in parser.
SGML authoring and editing software which understands the DTD as ti is given. Such
software guides an author through the creation of a document, not requiring the author to
type in the SGML tags. The keyed-in text is automatically formatted and displayed
(non-WYSIWYG) on the screen.
SGML Publishing systems that accept an SGML-tagged document and associated
graphics and compose the entire document in accordance with the document's format
specifications, whether in the form of a FOSI, or system-internal style-sheet.
Software which automatically tags an ASCII file based on format -driven triggers. Most
of the structure type tags (for paragraphs, lists, etc.) can be automatically generated
without any trouble. However, unless the software is very sophisticated, the content
type tags (for cross references, equipment numbers, etc.) cannot be automatically

D-6

generated. Content type tags are very important in data base applications. This
auto-tagging software can be used in conjunction with media converters to translate
formatted system -dependent files (i.e., WordPerfect") into SGML files.
D4.0 HYPERMEDIA TIME-BASED DOCUMENT STRUCTURING
(HYTIME) (ISO/IEC DRAFT INTERNATIONAL STANDARD 10744)

LANGUAGE

D4.1 Purpose
The Hypermedia Time-Based Document Structuring Language (HyTime) is a standard language
for representing the logical structure of documents with requirements for space and time based
coordinates and addressing. HyTime is based on SGML (ISO 8879), and uses the grammatical
and syntactical conventions of SGML. HyTime provides the capability to package information
objects using a standardized markup language whose structure will enable non-sequential access,
querying, version control, and long-term maintenance despite system evolution or migration.
By using the SGML/HyTime standards, the application designer can create system independent
files that are transferable and interoperable across dissimilar computer applications. HyTime
provides architectural forms for the definition of SGML element classes in SGML Document
Type Definitions (DTD). HyTime does not provide a DTD, as such, but instead, constitutes a
meta-DTD from which conforming application DTDs can be created.
HyTime is not yet a CALS standard. It is perceived as a potential standard supporting future
interactive, electronic, hypertext and multimedia CALS applications.
D4.2 Typical Applications
The HyTime language can be directly applied to hypertext (documents that enable multiple
access paths) and multimedia applications.
These include the design and encoding of
information for Interactive Electronic Technical Manuals and Portable Maintenance Aids
(IETM/PMA), on-line review of existing documents both in and not in neutral formats, and the
creation of large interoperable hyperdocument libraries or design data bases.
HyTime has potential applications in the areas of project management, enterprise process design,
discrete event simulation, and music.
D4.3 Features
HyTime is designed for modular application. Features of the language which are not needed for
an application need not be supported. Depending on which features are supported, HyTime
provides:

Location addressing: a standard way of encoding a system-neutral address of any

information object or any part of an information object within or external to any given
document. Addressing may be by name, position, or semantic property.

D-7

Hyperlinking: models for hyperlink classes independent of the number of objects linked
to, and the context of the link. One model even provides for attaching properties to
information objects that cannot be modified or over-written.
Scheduling synchronization and alignment of information objects relative to one another.
Information objects are positioned within events on the spatio-temporal axes of a Finite
Coordinate Space (FCS). The axes of the FCS can be related and can be named to match
the context of the application. For example, the X axis can represent a virtual time line as
seen in a project management schedule for project phases, and the Y axis can represent
the real clock time as seen by a calendar.
Object Modification: Object modification is scheduled by HyTime but must be applied
by application-specific functions. This enables the scheduling of rendering instructions
in other notations, e.g., PostScript.
Event Projection: Events may be scheduled and projected onto alternative finite
coordinate systems and scaled accordingly. For example, if a graphic in a document must
be rendered in a smaller area on a display screen, this projection and scaling can be
indicated by HyTime notation.
Parseability: HyTime documents are parseable by SGML applications; parsing checks for
correct SGML grammar and syntax as well as conformance of the instance to the DTD.

D4.4 Hytime Architecture and Modules

The modules of HyTime are:

Base Module: includes hyperdocument management facilities, SGML, identification

facilities for replacing HyTime-specific identifiers with user-defined identifiers with
provisions for name collisions, coordinate addressing for scheduling dimensions,
positions of events, and document locations addressing by position. There is optional
support for specifying activity tracking policies by an activity tracking attribute that is
part of the SGML document, and for other basic utilities used to declare default attribute
values and definition tables.
Location Address Module: includes functionality to provide addressing of information
objects without a unique identifier within the current document's name space. Supports
addressing by coordinate location (discrete dimensions of arbitrary universe), semantic
location (by SGML attribute name or by notation-specific address), or namespace
location (SGML entities and SGML elements in external documents).
Hyperlink Module: uses five metaclasses of hyperlinks to define application-specific
hyperlink elements with their own processing semantics. The link classes are:
a. independent links can have any number of link ends with optional end terms used
as text or icons to invoke the link,
b. property links (two link ends which associate an attribute name and value with an
element),
c. contextual links (two link ends, one of which is a link's own location),
d. aggregate location links link multiple locations and treat them as a single location,
e. span links allow contiguous information to appear to be undivided by SGML
markup.

D-8

Finite Coordinate Space Module (FCS): provides for scheduling of objects with optional
projection and modification modules. Event schedules define the position and occurrence
of objects. Objects occur in an FCS as the content of an event. An event is a conceptual
bounding box. Each event has a set of dimension specifications for its position and
extent on the coordinate axes of the FCS in which the event schedule appears. The FCS
coordinates can be expressed in the terms of the application. Finite Coordinate Spaces
can be nested. For example, if a project schedule is modeled as processes nested within
processes, the FCS can be used to encode this nesting, the relationship of time changes
that occur within a process and the effect of these changes on processes within which it is
nested.

D4.5 Advantages of Current Specification

Users of HyTime-compliant systems can incorporate active references within documents and to
external on-line documents. This includes referencing to non-HyTime documents. HyTime can
reference documents in multiple notation languages, e.g., IGES, VHDL, ODA, etc. HyTime
location addressing includes the capability to reference read-only documents which is crucial to
incorporating legacy data.
HyTime provides a standard way to represent abstract time dependencies.
HyTime's
representation of time and space measurements is the same and can be extended to any
measurement domain with any number of axes.
HyTime does not restrict the potential sets of applications nor the application design except in
the agreements about how to express hyperlinks. This enables maximum interoperability of
hyperdocuments without attempting to standardize the information object notations or modifiers.
D4.6 Enhancements to the Published Standard
The newest and most significant addition to the HyTime published standard is the HyQ query
language. It was added to provide an alternative user interface (sanctioned by ISO) not only to
HyTime and SGML documents but non-SGML documents as well by using HyTime features.
Some of the recent technical changes to the published standard impact the Content Data Model
which must be revised accordingly.
D4.7 Implementation Issues
Non-HyTime notations used in scaling factors cannot be executed by a HyTime system. Such
notations might include the potential for asynchronous interrupts by a user. HyTime has been
created by the ISO X3Vl.8M committee with much effort and time spent anticipating
conceivable applications. However, at this time, there are no full scale commercial applications
that can be examined to determine if the standard is effective.

D-9

D5.0 DIGITAL REPRESENTATION FOR COMMUNICATION OF ILLUSTRATION

DATA: COMPUTER GRAPHICS METAFILE
D5.1 Purpose
The Computer Graphics Metafile (CGM) standard is a published International Standard
(ISO/IEC 8632) and has been adopted by the American National Standard Institute (ANSI). The
CGM standard is being developed and maintained through a coordinated effort of ISO SC24 and
ANSI X3H3.
The overall intent of the CGM standard is to provide the lowest level of drawing functionality
required to capture and reproduce a picture, in a way that is portable across applications and
devices. The CGM standard specifies two-dimensional graphics data interchange in a file format
that can be created independently of device requirements and translated into formats needed by
specific output devices, graphics systems, and computer systems.
A metafile is a device-independent, application-independent storage format for the exchange of
the data that makes up a picture ("picture data"). The metafile definition in ISO/IEC 8632
includes a definition of output primitives and attributes that may be used to compose an
illustration, but in an intentionally under-specified semantics (meaning). This was done to
accommodate a wide range of existing systems, and to make the standard more adaptable to the
requirements of diverse applications and users. The application software wishes to store a
picture on a metafile. To do this, it has to write all the information required to a file. The
software that performs these writing actions is called the generator. The software that reads a
metafile back into an application is called an interpreter.
A profile addresses implementation conformance requirements for the generator and interpreter.
For generators, the graphical characteristics of the picture are mapped onto a set of CGM
elements which define the pictures within the accuracy and latitude defined by the
implementation requirements in the profile. For interpreters, the graphical characteristics of the
CGM elements are rendered into a graphical image or picture within the latitude defined by the
implementation requirements in the profile. Without a profile, one can only address the
syntactical correctness of the data stream. With a profile, one can address and test that the
picture is correct. A profile provides a way of standardizing and publicly specifying the options
that a vendor supports and how they are to be supported.
The three CGM encodings meet different needs, but all may be interchanged without loss of
information. The binary encoding facilitates rapid graphic data processing. The character
encoding is compact and transportable. The clear text encoding is human readable and editable.
Only the binary format is approved for use by MIL-D-28003.
ISO/IEC 8632 CGM is an upwardly compatible standard format, developed in three versions that
offer steps in capability. Version 1 includes elements of ISO 8632
D5.2 Typical Applications
CGM is intended for use in computer graphics applications in the following situations:

D-10

A graphics metafile is maintained at a central facility for a decentralized system that

employs graphics devices of different makes and models that must utilize the data.
A graphics metafile is required to preserve picture data when conversion or migration
from one graphics system to another is necessary and the two systems are not necessarily
compatible.
A graphics metafile is intended for information interchange between a source system and
a target system that are not necessarily compatible.

ISO/IEC 8632 is the recommended standard to:

View the image on a wide variety of devices, with different characteristics (such as color
and resolution), where the set of devices may not even be known at the time the metafile
is generated;
Enhance the picture before viewing the final image;
Compose or overlay several drawings into a single picture for viewing.

D5.3 Architecture
The CGM standard (ISO 8632-1987), Computer Graphics - Metafile for the Storage and
Transfer of Picture Description Information is composed of 4 parts. MIL-D-28003A utilizes Part
1 and Part 3 of the standard's four-part architecture.

Part 1 - Functional Specification - defines the functions of the CGM, independent of any
encoding. It also includes responses for the standard and design requirements and design
criteria.
Part 2 - Character Encoding - defines an encoding of the Part 1 functionality in a format
that conforms to ISO code extension rules. It is intended to provide an encoding of
minimum size, and may be used for transfer of pictures through networks that cannot
support binary transfer of data.
Part 3 - Binary Encoding - defines an encoding of the Part 1 functionality that is intended
to not require any other effort to generate and interpret on many systems.
Part 4 - Clear Text Encoding - specifies an encoding of the Part 1 functionality that can
be created, viewed, and edited with standard text editors. This encoding is appropriate
for networked systems that support only text file transfer.

D5.4 Status and Planned Extensions

Work is in progress to produce several International Standardization Profiles (ISP) for CGM.
The profiles will be based on ISO 8632:1992 and Amendment 1 which specifies profile rules and
a model profile. It is proposed that there will be three profiles based on current profiles
(including MIL-D-28003 the CALS CGM Application Profile [AP]), which range from basic
scientific and technical graphics to advanced presentation and visualization.
The 1992 edition of the international standard for CGM provides critical capabilities for the
CALS environment, which include:

D-11

Advanced two-dimensional graphics (curves; fine control of line appearance; composite line
primitives; user defined line types, hatch styles and marker types; additional standardized hatch
styles; arbitrary text path; filing mechanism; and general linear transformations).

Improved text and font support.

Arbitrary boundaries for clipping and shielding.
Additional color models beyond RGB (used in printing).
Additional raster graphics (scanned image) capabilities.
Symbols: external reference to standard libraries of named symbols.

The purpose of this edition of the standard is to extend CGM to fulfill requirements of
engineering drawings, the preparation of graphic arts quality presentation materials, cartography,
and technical publishing. To a large degree, this work was directly in response to CALS
requirements.
Of particular interest to the CALS environment is the work under way within the CGM standards
organization (X3H3) to provide intelligent graphics.
Intelligent Graphics is defined as
adding information to graphics that is not graphical information, but that attaches application
intelligence or semantics to the graphics. Requirements are association of comments with
graphics elements, association of comments with element groups (hierarchical), native format
editing, version control, and text to graphics links. This requirement was originally introduced
by the electronic Review work of the CALS Industry Steering Group (ISG) Electronic
Publications Committee, where SGML-tagged documents are used to provide a commenting
capability. The CGM additions will allow for SGML tags to be attached to objects within the
CGM file.
Note that the addition of tiled raster capabilities, based on the Tiled Raster Interchange Format
(TRIF), allows for the encoding of large raster images within a CGM file. Possible future
extensions to the international standard that could be of considerable interest to CALS include
the formulation of an object structured grammar. This has been requested from, and will be of
major use to, CGM users in commercial aviation (intelligent graphics); CALS electronic review
(review comments in graphics and stronger links to text); and hypermedia (smart objects in
graphics databases).
D5.5 Advantages of Current Specification
The CGM contains device-independent, digitally-encoded vector and raster graphics data. CGM
files are easily transferred and displayed on a wide variety of hardcopy devices (dot-matrix,
ink-jet, electrostatic, and laser printers, pen plotters, and film cameras). CGM files can also be
easily previewed on an extensive range of softcopy terminals. In comparison to Raster, CGM is
easily modifiable, generally of much smaller size, and not dependent upon resolution of the
output device. In comparison to IGES (2D data), CGM is faster to interpret and display, and
again more compact. The selection of which of the CALS graphic standards (raster, IGES, or
CGM) that best fits the application, should be the result of the thorough examination of the
processes involved in the application.

D-12

D5.6 Implementation Issues

Standards testing, conformance testing and interoperability testing are essential steps towards
achieving successful interoperability. Standards testing examines the design, construction, and
details of the standard, and tests to see if it is correct and well-defined. Interoperability testing
demonstrates that a given pair of systems (or products) can interoperate. In other words,
standards testing assures that the standard is well-defined; conformance testing ensures that the
product is built correctly"; and interoperability testing ensures that there are no hidden problems
in system interfaces resulting from laxity in defining the specification.
D6.0 STANDARDS FOR THE EXCHANGE OF PRODUCT MODEL DATA

Surface Information
Roughness
Coating

Material Specifications
Type
Composition

Shape and Size

Geometry
Topology
Product
Part Number
Version Number
Security Classification

Tolerance Specifications
Size Dimension
Tolerance Range
Position Tolerance

Feature Definition
Hole Pattern
Groove
Outside Diameter

Figure D-1 Example of a STEP Data File

D6.1 Purpose
STEP (Standard for the Exchange of Product model data) is the unofficial name for the ISO
10303 standards that are being developed by the International Organization for Standardization
(ISO). STEP is formally called the Industrial Automation Systems and Integration - Product
Data Representation and Exchange Standard. In the United States, STEP is known as PDES
that stands for Product Data Exchange using STEP. PDES is the U. S. organizational activity
that supports the development and implementation of STEP.

D-13

STEP is an international standard that is being designed to give a complete

computer-interpretable representation of product data in a neutral format throughout the
complete product life-cycle (design, engineering analysis, manufacture, support and
maintenance, and disposal). This representation makes it suitable not only for file exchange but
also as a basis for implementation, sharing, and archiving product databases.
With the proliferation of Computer-Aided Design, Computer-Aided Manufacturing, and
Computer-Aided Engineering systems (CAD/CAM/CAE), all product data can be captured in
digital form. The ability to transfer such product data in computer-readable format from one
system to another is essential. Once the STEP standard is defined and implemented on various
systems, then such systems can accept, use, and exchange product data so that developers,
suppliers, vendors, and manufacturers will be able to receive and supply information about
product parts and materials digitally. This will mean shorter development times, higher quality
products, and lower costs. It will also ensure flexibility and responsiveness to the needs of
customers, manufacturers, suppliers, and users.
The STEP standards are fundamental to the CALS effort. CALS encompasses an architecture
for Contractor integrated Technical information Services (CITIS) which requires an Integrated
Weapon System Data Base (IWSDB). The STEP shared data environment will provide the
kernel of the IWSDB and will support information access for prime contractors, sub-contractors,
and the DoD. The scope of STEP standards development is immense with respect to the variety
of products addressed.
D6.2 Architecture of the Standard
STEP is organized as a series of Parts that are divided into six logical groups. Each of these
groups is called a Class. Each Class has a unique function in STEP. Within each Class,
documentation for each Part is being developed. STEP is being published as a set of
inter-related standards, each of which falls into one of the six classes.
D6.2.1 Overview (Parts 1 - 9)
This Class provides an overview of all the STEP standards. Currently, only one part, Part 1Overview and Fundamental Principles, has been developed. Other Parts in this Class may be
developed in the future.
D6.2.2 Description Methods (Parts 10 - 19)
This Class specifies the methods used to describe the information models found in both the
integrated Resources Class and Application Protocols (AP) Class. Only one part, Part 11 EXPRESS language, has been developed. The EXPRESS language provides the mechanism for
the description of product data for both integrated resources and APs within STEP. This
description is independent of any implementation method and will support all such methods
defined in STEP consistently.

D-14

D6.2.3 Implementation Forms (Parts 20 - 29)

This Class specifies the methods for exchanging and sharing data captured from information
models.
D6.2.4 Conformance Testing (Parts 30 - 39)
This Class specifies the methods that determine whether a STEP implementation conforms to the
standard.
D6.2.5 Integrated Resources (Parts 40 - 199)
This Class provides the specification of integrated conceptual information models for all of the
STEP effort. Within this Class, there are two types of STEP Parts:
1. Generic Resources (Parts 40 - 99): These are Parts comprised of concepts and constructs
that may be used by many applications, including the higher level Application Resources
and APs.
2. Application Resources (Parts 100 - 199): These are Parts containing conceptual
constructs for specific application areas. These Parts may be used by many APs.
D6.2.6 Application Protocols (Parts 200 +)
These Parts, the Application Protocols (AP), provide the mechanism both for specifying
implementation requirements and for ensuring reliable information communication within the
context of a given application. An AP is a complete specification of the context and scope for
the use of product data in a particular domain using standardized integrated resources and other
application specific entities. The AP also describes the conformance requirements and test
purposes from which its abstract test suite is derived. Parts in this Class are numbered 200 and
above.
D6.3 Status and Planned Extensions
D6.3.1 STEP Initial Release
Twelve STEP Parts were registered for Draft International Standard (DIS) status in May 1993.
This initial release of STEP provides capabilities for the exchange of two-dimensional drafting
product data and the configuration controlled exchange of three-dimensional product definition
data with emphasis on mechanical parts and assemblies.
The initial STEP release establishes a foundation for subsequent releases of STEP.
release of STEP includes the following Parts:

Part 1 - Overview and Fundamental Principles

Part 11 - EXPRESS Language Reference Manual
Part 21 - Clear Text Encoding of the Exchange Structure
Part 31 - Conformance Testing Methodology

D-15

This initial

Part 41 - Fundamentals Product Description and Support

Part 42 - Geometric and Topological Representation
Part 43 - Representation Structures
Part 44 - Product Structure Configuration
Part 46 - Visual Presentation
Part 101 - Drafting
Part 201 - Explicit Drafting
Part 203 - Configuration Controlled Design

D6.3.2 STEP Subsequent Releases

Subsequent STEP releases will provide added functionality and extend the capabilities of the
Parts in the initial Release. The schedule for these STEP subsequent releases has not been
determined. The following Parts are currently being developed.

Part 22 - STEP Data Access Interface (SDAI)

Part 32 - Test Laboratory Requirements
Part 33 - Structure and Use of Abstract Test Suites
Part 34 - Abstract Test Methods
Part 45 - Materials Products
Part 4~ - Shape Tolerances
Part 48 - Form Features
Part 104 - Finite Element Analysis
Part 105 - Kinematics
Part 202 - Associative Drafting
Part 204 - Mechanical Design Using Boundary Representation
Part 205 - Mechanical Design Using Surface Representation
Part 206 - Mechanical Design Using Wireframe Representation
Part 20~ - Sheet Metal Die Planning and Design
Part 208 - Life-cycle Product Change Process
Part 209 - Design Through Analysis of Composite and Metallic Structures
Part 210 - Electronic Printed Circuit Assembly: Design and Manufacture
Part 211 - Electronic Printed Circuit Assembly: Test, Integrated Diagnostics and
Remanufacture
Part 212 - Electrotechnical Plants
Part 213 - NC Process Plans for Machined Parts
Part 214 - Core Data for Automotive Mechanical Design
Part 215 - Ship Arrangements
Part 216 - Ship Molded Forms
Part 217 - Ship Piping Systems
Part 218 - Ship Structures
Part 219 - Dimensional inspection Process Planning

D-16

D6.4 Advantages of Current Specification

STEP is an extremely broad specification, including virtually every data item required to
develop, analyze, manufacture, document, and support products ranging from mechanical
products to electronic products to large structures such as ships and buildings, etc.
STEP is a conceptual specification for communicating product information at all stages in a
product's life-cycle, covering all aspects of product description and manufacturing specifications.
The fundamental components of STEP are product information models and specifications to
exchange information corresponding to these product models. STEP will provide tools to reduce
time to market, reduce costs, improve quality, and continuously improve processes. STEP will
allow all information from finance, marketing, engineering, manufacturing, support, etc. to work
together and share data. STEP data is open: it is independent of the applications or systems that
create it, and is accessible to and usable by any other applications that need to use it.
STEP will provide the ability to turn data into meaningful information to support decision
making. STEP will provide a foundation for the next generation of open systems.
D6.5 Implementation Issues
The initial Release of DIS STEP is available for implementation. The emphasis on software
applications is currently focused on creating Application protocols (APs) which are focused on
high value industrial processes.
D6.5.1 Implementation of APs
APs are the implementable parts of STEP. Many APs are in the planning or development stages.
Guidelines for the development of APs are documented and are available through the U. S.
Product Data Association.
When an AP is proposed for development, approval is required from the IGES/PDES
Organization (IPO). The AP proposal requires a precise definition of scope and a detailed plan
for development. The development of the AP proceeds in accordance with the STEP guidelines.
The draft AP is reviewed and balloted through the international standards process.
D6.5.2 Software Tools
There is a growing recognition of the need for software tools to facilitate the STEP standards
development, application software implementation, and testing process.
Software tools can be catalogued in four major groupings.

Standards development tools: Parsers, compilers, editors, schema generators, etc.

STEP data exchange tools: Software to generate and interpret STEP physical files and
databases, etc.
Data management tools: STEP data access interfaces and database management software,
etc.

D-17

End User Tools: Translators, etc.

D6.6 Implementation Levels

STEP provides a wide variety of levels for system implementation. Implementation levels are
particular ways of storing, exchanging, or accessing information which are distinguished by the
degree of data sharing. Those levels may include the following:

Exchange File - Product data is exchanged between computer systems or applications

using STEP exchange files which are defined in STEP Part 21. The structure of the
exchange file is derived from the conceptual data model's EXPRESS definition. It is
expected that the early use of STEP will involve using exchange files to move data
between systems.
Database - Product data is stored and accessed in databases based on various database
architectures (such as relational or object-oriented) This database level will allow
application developers to create, manipulate, and share STEP data, based on standard
data models and system interfaces. Applications use a standard query language such as
SQL or standard interfaces such as the STEP Data Access Interface (SDAI) defined in
Part 22.
Data Access - Product data can be accessed independently of the storage method used.

D6.7 Testing
The STEP testing activities are categorized as follows:

Standards testing: it addresses the quality of the evolving STEP specification itself.
These validation efforts provide assurance that the methods employed by STEP will
indeed work, and that the standard provides a means to meet the functionality that it
claims to support.
Component testing: This is the preliminary testing conducted by the STEP software
implementer to verify that the application software addresses both the basic requirements
imposed for compliance with the standard and the users' functionality requirements.
Conformance testing: it evaluates a software product with respect to the specifications
provided in a Part of a STEP standard and tests for the presence of these characteristics
required by the standard itself. STEP includes the specifications for Conformance testing
as a requirement built into many Parts of the standard.
Acceptance testing: it is concerned with the user's specific requirements. It tests a
software product against a set of requirements defined by the users of that software
product.
This type of testing may include performance, user interfaces, and
inter-operability with other systems.

Current efforts are primarily focused on developing methods for Conformance and Standards
testing. Component and Acceptance testing activities have just gotten underway within the
vendor and user communities.

D-18

D6.8 Training and Education

The STEP standard is technically complex and requires different types of skills for the
development of the standard, as well as, its implementation in a production environment.
Training has been focused on the highly technical needs of the developers. As industry proceeds
from the standards development stage to testing and implementation, additional types of training
are needed for the new users, new developers, and even experienced staff. More formal,
structured training programs will be required to effectively transfer the needed information to
users.
D7.0 EQUIPMENT ACQUISITION STANDARDS AND APPLICATION PROFILES
(VERSION 2 SECTION 10.0)
D7.1 Acquisition Processes
The Acquisition Phase of a NATO Project encompasses all Business functions carried out by a
System Project Office before a system enters service and is accepted by the designated user(s).
These functions include Logistics Support Analysis, Initial Provisioning and associated activity
such as Illustrated Parts Catalogues, NATO Codification, and Order Administration, decisions
related to the development of Integrated Logistics Support and the definition and creation of
Integrated Databases needed to support both Initial Acquisition and the In-service Phase of the
system Life-cycle, and specification of Technical Documentation and Maintenance Manuals.
D7.2 Logistics Support Analysis
Logistics Support Analysis (LSA) consists of a series of analytical tasks which identify the
support planning parameters and management requirements for an equipment project, define the
support requirements of an equipment, identify major cost drivers, assess and influence the
Reliability and Maintainability (R&M) for the design options, identify optimum support
solutions, balance life-cycle costs against performance, and verify the support solution adopted
once an equipment enters service. The results of LSA are stored in a Logistics Support Analysis
Record (LSAR) which is a single database for the equipment.
Standard
[T]
Profile
[E]

MIL-STD-1388-1A

DoD Logistic Support

Analysis

S/S MIL-HDBK-502

Notice 4
To be
cancelled

UK DEF STAN 0060

Pt 0

Interim Issue
1

Application of Integrated
Logistic Support (ILS) Profile of MIL-STD1388-1a for UK MOD
use.

Note: The NCMB is considering sponsoring the development of an International Standard to

support Acquisition Programs and the associated Data Exchange, and this work has started to
integrate MIL-STD-1388, AECMA SPEC 2000M, and AECMA SPEC 1000D and to harmonize

D-19

their associated Data Dictionaries. If this work is successful, the resulting ISO Standard and any
associated NATO Applications Profiles (STANAGs) should replace the above Standard and
Applications Profile by 1997.
D7.3 Initial Provisioning
Initial Provisioning Procedures are the first steps that constitute the formal process for the
acquisition of initial spares needed to support defense equipment. The processes include the
identification, listing, and presentation of sparable items, the presentation of Illustrated Parts
Catalogues (IPC), and NATO Codification.
Standard
[T]

AECMA 2000M

Revision 3.0

Material Management
Integrated Data
Processing for Military
Equipment

D7.4 Illustrated Parts Catalogues

Illustrated Parts Catalogues provide a spare parts breakdown for personnel employed in
maintenance and stock management. Although the following standard includes a specification of
Illustrated Parts Catalogues, current development work indicates that it may be more appropriate
to handle such illustrations as part of Technical Documentation using AECMA 1000D.
Standard
[T]

AECMA 2000M

Revision 3.0
Chapter 1

Material Management
Integrated Data
Processing for Military
Equipment

D7.5 NATO Codification

NATO uses a standard system of numbering items of supply known as the NATO Codification
System (NCS). NCS is designed to achieve maximum effectiveness in national and international
logistics support, to facilitate data management in the materiel area, and to identify items which
appear to be different but meet the same requirement.

D-20

Standard
[T]

STANAG 3150

Issue: 1989
Revision:
5.07.1989

Codification of
Equipment - Uniform
System of Supply
Classification

Standard
[T]

STANAG 4177

Issue:
21.08.90

Manual
[R]

ACodP-1

Codification of Items of
Supply - Uniform
System of Data
Acquisition
NATO Manual on
Codification
Guide to NATO
Codification Systems

D7.6 Machine Readable Code (Bar Coding)

Items of supply for delivery to NATO Nations have packaging specifications which include the
labeling of each item with a machine-readable reference number specified by the NATO
codification standard. The machine-readable symbology is specified as a bar code.
Standard
[E]

AECMA 2000M
Based on
STANAG 4329

Revision 3.0
Appendix 3

Standard
[T]

STANAG 4329

Issue:
6.4.1992

Material Management
Integrated Data
Processing for Military
Equipment - Appendix 3
Bar Coding
NATO Standard Bar
Coding Symbology

D7.7 Order Administration

Order Administration is the term used to describe the methods used for placing orders for new
items of supply or repair of repairable items of supply together with the related processes needed
to obtain status information about existing orders.
Standard
[E]

AECMA 2000M

3.0 Chapter 3

D-21

Material Management
Integrated Data
Processing for Military
Equipment

D7.8 Order Administration Format, Content, and Communications Techniques

Standard
[E]

AECMA 2000M
Based on ISO 9735
(EDIFACT)
/ EN29735
/ DIN16536

Revision 3.0

Material Management
Integrated Data
Processing for Military
Equipment - Appendix 1
Data Dictionary and
Appendix 2
Communications
Techniques

AECMA SPEC 2000M Revision 2.1 includes a comprehensive set of Order Administration
messages that do not conform to ISO 9735/UN EDIFACT. Publication of an EDIFACTcompliant message set is expected in early 1996.
D7.9 Consumption and Maintenance Data Exchange
Mechanisms for the exchange of data about item consumption in-use and on maintenance
operations is prescribed in the AECMA 2000M standard, and further work is in hand to extend
this work to cover repair activity.
Standard
[E]

AECMA 2000M

Revision 3.0

Material Management
Integrated Data
Processing for Military
Equipment - Chapter 5
Consumption Data
Exchange

D7.10 Standard Parts Library Data Exchange

The emerging standard for parts libraries will provide open capability for extracting information
from different types of structured libraries into application systems and for transferring data
between libraries. Libraries can range from parametric definitions through numeric tables to
STEP Parts.

D-22

Standard
[E]

ISO 13584

CD
ISO TC184
SC4

Industrial Automation Parts Library

Part 1 Over View and
Fundamental Principles
Part 10 Conceptual
Model
Part 20 General
Resources
Part 24 Logical Model
of Supplier Library
Part 26 Supplier
Identification Codes
Part 31 Programming
Interface
Part 42 Dictionary
Methodology
Scheduled for DIS End1995
NATO Master CrossReference List

Standard
[T]

Note: The Policy and applicable standards for Parts Libraries, Data transfer for NATO, and the
status of the above Standard has not yet been confirmed or validated in the NATO CALS
context. NATO Maintenance and Supply Agency (NAMSA) currently publishes a Master Cross
Reference List of parts subject to NATO Codification for use by the Nations.
D8.0 TECHNICAL DOCUMENTATION STANDARDS AND APPLICATION
PROFILES
D8.1 Character Sets and International Codes
The NATO base standard for information processing is the internationally agreed reference for
Latin-based languages (ISO 646) which defines the ASCII compatible binary representation of
English alpha-numeric characters, a range of punctuation symbols, and four special control
characters (space, tab, and the line/record start and end codes.
It can be easily modified for use with other Latin-based languages. Representation of languages,
country names, currencies, dates/times, and the units of measurement should also be specified
using the appropriate ISO standards.

D-23

Standard
[R]

ISO 31

3rd Ed. 1992

Information Processing
Representation of
Quantities and Units

Standard
[R]

ISO 639

1988

Information Processing
Coded Representation of
Names of Languages

ISO/IEC 646

3rd Ed.
1991

Information Technology
- ISO 7-Bit Coded
Character Set for
Information Interchange
SI Units and
Recommendations for
the Use of Their
Multiples and of Certain
Other Units.
Information Technology
Codes for the
Representation of Names
and Countries and Other
Subdivisions. Part I
Country Names
Part II Country
Subdivision Codes

Standard
[R]

Standard
[R]

ISO 1000

3rd Edition
1992

Standard
[R]

ISO 3166-1

1997

Standard
[R]

ISO 3166-2

1998

Standard
[R]

ISO 3166-3

1999

Part III Formerly Used

Names of Countries

Standard
[R]

ISO 4217

1995

Standard
[R]

ISO 6709

1983

Standard
[R]

ISO 6936

1988

Codes for the

Representation of
Currencies and Funds.
Standard Representation
of Latitude, Longitude,
and Altitude for
Geographic Point
Locations.
Information Technology
- Character Set
Conversion between ISO
646 and ISO 6937-2 with
CCITT No. 2 (ITA-2).

D-24

Standard
[R]

ISO/IEC 8859

Various

Standard
[R]

ISO 8601

1st Ed. 1988

ISO/WD 8601

2nd Ed.

ISO/IEC 10646-1

1st Ed. 1993

ISO/IEC WD
10646-1

2nd Ed.

Standard
[R]

Information Technology
- 8-bit single byte coded
graphic character sets.
Pt. 1 Latin Alphabet No.
1
Pt. 2 Latin Alphabet No.
2
Pt. 3 Latin Alphabet No.
3
Pt. 4 Latin Alphabet No.
4
Pt. 7 Latin/Greek
Alphabet
Pt. 9 Latin Alphabet No.
5
Pt. 10 Latin Alphabet
No. 6
Pt 11 Latin/Thai
Alphabet
Pt. 13 Latin Alphabet
No. 7
Pt. 14 Latin Alphabet
No. 8
Pt. 15 Latin Alphabet
No. 9
Data Elements and
Interchange Formats
Information Interchange
Representation of
Date/Time.
Information Technology
- Universal Multiple
Octet Coded Character
Sets (UCS)

D8.2 Information Processing

In order to share and reuse the information in documents across software applications and across
computing platforms the preferred system is based on a Standard Generalized Markup Language
(SGML). SGML document elements can contain text and data in ISO 646 format, graphics in
CGM format, Computer Aided Design (CAD) Data in IGES format, images in ISO 8613 raster
graphics format, spreadsheets and video/voice.
ISO 8879 does not contain a document presentation standard and Document Style Semantics and
Specification Language (DSSSL)(DIS 10179) is intended to remedy this in the near future.
MIL-M-28001 Appendix B contains a Format Outputting Specification Instance (FOSI) which

D-25

can be used temporarily as an interim standard. Any application that generates a page image
format can use Standard Page Description Language (SPDL) including SGML/DSSSL and
ODA.
Standard
[N]

Standard
[N]

Standard
[N]

Standard
[N]

Standard
[N]

Standard
[N]

ISO/IEC 8613-1

ISO/IEC 8613-1
Cor. 1

1994

ISO/IEC 8613-2

1995

ISO/IEC 8613-2
Cor. 1

1998

ISO/IEC 8613-2
Cor. 2
ISO/IEC 8613-3

1998

ISO/IEC 8613-4

1994

ISO/IEC 8613-4
Cor. 1

1998

ISO/IEC 8613-4
Cor. 2
ISO/IEC 8613-5

1998

ISO/IEC 8613-5
Cor. 1

1998

ISO/IEC 8613-5
Cor. 1
ISO/IEC 8613-6

1998

ISO/IEC 8613-6
Cor. 1

1998

1998

1995

1994

1994

ISO/IEC 8613-6
FCD Amd. 1

D-26

Information Technology.
Office Documentation
Architecture (ODA) and
Interchange Format.
Part 1 Introduction and
General Principles
Part 2 Document
Structures

Part 3 Abstract
Interface for the
Manipulation of ODA
Documents.
Part 4 Document
Profile.

Part 5 Open Document

Interchange Format

Part 6 Character
Content Architectures

Standard
[N]

ISO/IEC 8613-7

1994

ISO/IEC 8613-7
Amd. 1

1998

ISO/IEC 8613-7
Cor. 1998
ISO/IEC 8613-8

1998
1994

Part 8 Geometric
Graphics Content
Architectures.

Standard
[N]

ISO/IEC 8613-9

1996

Part 9 Audio Content

Architectures.

Standard
[N]

ISO/IEC 8613-10

1995

Part 10 Formal
Specifications.

Standard
[N]

ISO/IEC 8613-11

1995

Part 11 Tabular
Structures and Tabular
Layout.

Standard
[N]

ISO/IEC 8613-12

1996

Part X12 Identification

of Document Fragments.

Standard
[N]

ISO/IEC 8613-14

1997

Part 14 Temporal
Relationships and Nonlinear Structures.

Standard
[R]

ISO 8879

1986

Information Processing Text and Office Systems

- Standard Generalized
Markup Language
(SGML)

ISO 8879 Amd. 1

1988

ISO 8879 Cor. 1

1996

ISO 8879 Cor. 2

ISO 9069

1999
1988

Standard
[N]

Standard
[R]

D-27

Part 7 Raster Graphics

Content Architectures.

Information Processing SGML Support Facilities

- SGML Document
Interchange Format
(SDIF)

Standard
[]

ISO/IEC TR
9573

1988

Standard
[]

ISO/IEC TR
9573-11

1992

Standard
[]

ISO/IEC TR
9573-13

1991

Standard
[E]

ISO/IEC 10179

1996

Standard
[E]

ISO/IEC 8824

1990

Standard
[E]

ISO/IEC 8824-1

1995

ISO/IEC 8824-1
FCD Amd. 1

1996

Relative Object
Identifiers

ISO/IEC 882-1
Amd. 1

1996

Rules of Extensibility

ISO/IEC 882-1
Cor. 1

1996

ISO/IEC 882-1
Amd. 2

Information Processing
SGML Support Facilities
Techniques for Using
SGML.
Part 11 Application at
ISO Central Secretariat
for International
Standards and Technical
Reports.
Part 13 - Public Entity
Sets for Mathematics and
Science
Information Technology
Processing Languages
- Document Style
Semantics and
Specification Language
(DSSSL)
Scheduled for IS in 1995
Information Technology
Open Systems
Interconnection
Specification of Abstract
Syntax Notation One
(ASN. 1).
Part 1 Specification of
Basic Notation

Semantic Model

D-28

Standard
[E]

Standard
[E]
Standard
[E]

Standard
[E]

Standard
[E]

ISO/IEC 8824-2

1995

Part 2 Information
Object Specification

ISO/IEC 8824-2
FCD Amd. 1

1995

Semantic Model

ISO/IEC 8824-2
Amd. 1
ISO/IEC 8824-3

1996

Rules of Extensibility

1995

Part 3 Constraint
Specification

ISO/IEC 8824-4

1995

Part 4 Parameterization
of ASN. 1
Specifications

ISO/IEC 8824-4
FCD Amd 1 ASN
1
ISO/IEC 8825

Semantic Model

1990

ISO/IEC 8825-1

1995

ISO/IEC 8825-1
FCD Amd. 1

Standard
[E]

ISO/IEC 8825-1
Cor. 1
ISO/IEC 8825-2

Information Technology
Open Systems
Interconnection
Specification of Basic
Encoding Rules for
Abstract Syntax Notation
One (ASN.1)
Part 1 ASN.1 Encoding
Rules: Specification of
Basic Encoding Rules
(BER), Canonical
Encoding Rules (CER),
and Distinguished
Encoding Rules (DER)
Relative Object
Identifiers

1996
1996

ISO/IEC 8825-2
FCD Amd. 1

Part 2 ASN.1 Encoding

Rules: Specification of
Packed Encoding Rules
(PER)
Relative Object
Identifiers

D-29

Standard
[E]

ISO/IEC 10180

1995

Profile
[T]

MIL-HDBK28001

30 Jun 1995

Handbook
[T]

MIL-HDBKSGML

DRAFT
Published
May 1994

WAS NOT
FOUND

Information Technology
Processing Languages
Standard Page
Description Language
(SPDL)
DEPARTMENT OF
DEFENSE
APPLICATION OF
MIL-PRF-28001 USING
STANDARD
GENERALIZED
MARKUP LANGUAGE
(SGML)
U.S. Department of
Defense Application of SGML.
Federal Information
Processing Standard
(FIPS 152)

D8.3 Graphics and Illustrations

Graphics and Illustrations requiring two dimensional vector presentation in technical manuals such as graphs, charts, simple figures and line drawings - should be specified in Computer
Graphics Metafile (CGM) format.
CGM provides for the interchange of processable, digital, 2-D graphics data through a Metafile
format which can be created independently of device requirements and translated into the
formats required by output devices, graphics, and computer systems.

D-30

Standard
[R]

ISO/IEC 8632 1

1992

Information Technology
- Computer Graphics Metafile of the storage
and transfer of picture
description information
Part 1 Functional
Specification
Rules for Profiles

1994

Application Structuring
Extensions

ISO/IEC FDIS
8632
ISO/IEC 8632-1
Amd. 1
1995
ISO/IEC 8632-1
Amd. 2
Standard
[R]

ISO/IEC 8632-2

1992

Part 2 Character
Encoding

ISO/IEC 8632-2
Amd. 1

1994

Rules for Profiles

ISO/IEC 8632-2
Amd. 2
ISO/IEC 8632-3

1995
1992

Application Structuring
Extensions
Part 3 Binary Encoding

ISO/IEC 8632-3
Amd. 1

1994

Rules for Profiles

ISO/IEC 8632-3
Amd. 2
ISO/IEC 8632-4

1995

Application Structuring
Extensions
Part 4 Clear Text
Encoding

ISO/IEC 8632-2
CD Cor. 1

Standard
[R]

Standard
[R]

1999

D-31

Standard
[]

ISO/IEC 9592 - 1

1997

Standard
[]

ISO/IEC 9592 - 2

1997

Standard
[]

ISO/IEC 9592 - 3

199

Part 3 Specification for

Clear-Text Encoding of
Archive File

Standard
[]

ISO/IEC 9593 -1

1990

Information Processing
Systems Computer
Graphics
Programmers
Hierarchical Interactive
Graphics System
(PHIGS) Language
Building
Part 1 FORTRAN

ISO/IEC 9593 -1
Amd. 1

1995

ISO/IEC 9593 -1
Cor. 1

1993

ISO/IEC 9593 -1
Cor. 2
ISO/IEC 9593 3

1994
1990

Part 3 ADA

ISO/IEC 9593 3
Amd. 1

1994

Incorporation of PHIGS
PLUS

ISO/IEC 9593 3
Cor. 1

1993

ISO/IEC 9593 3
Cor. 2

1994

Standard
[]

D-32

Information Technology
Computer Graphics
and Image Processing Programmers
Hierarchical Interactive
Graphics System
(PHIGS) Part 1
Functional Description
Part 2 Archive File
Format

Standard
[]

Standard
[]

Standard
[]
Standard
[]
Standard
[]
Standard
[]
Standard
[]
Profile
[E]

ISO/IEC 9593 4

1991

ISO/IEC 9593 4
Amd. 1

1994

ISO/IEC 9593 4
Cor. 1

1994

ISO/IEC 9593 4
Amd. 2
ISO/IEC 9636 - 1

1998

ISO/IEC 9636 - 2

1991

Incorporation of PHIGS
Amendments
Information TechnologyComputer Graphics Interfacing Techniques
for Dialogues with
Graphical Devices (CGI)
Functional
Specification
Part 1 Overview,
Profiles, and
Conformance
Part 2 - Control

ISO/IEC 9636 - 3

1991

Part 3 - Output

ISO/IEC 9636 - 4

1991

Part 4 - Segments

ISO/IEC 9636 - 5

1991

ISO/IEC 9636 - 6

1991

Part 5 Input and

Echoing
Part 6 - Raster

ISP 12064-1

DISP

1991

D-33

Part 4 C

Image Application Simple Document

Structure - Raster
graphics Content
Architecture Document
Application Profile ITUISB Recommendations
T4 and T6 + Tiled Raster
Graphics
FOD 112

Profile
[T]

MIL-D-28002
NOT FOUND IN
ASSIST

Rev B
Amend 1
20 Sep 93

Requirements for Raster

Graphics Representation
in Binary Format.
Federal Information
Processing Standard
(FIPS 150)

Profile
[T]

MIL-D-28003
NOT FOUND IN
ASSIST

Rev A Nov
92
Amend 1
14 Aug 92

NISTIR 5108 Raster

Graphics: A Tutorial and
Implementation Guide
provides guidance
regarding use of MIL-D28002
Digital Representation
for Communication of
Illustration Data: CGM
Application Profile.
MIL-D-28003 is
scheduled to migrate to a
Federal Information
Processing Standard
(FIPS 128-1) by End1996.

D8.4 Product Data

The exchange of technical 2-D and 3-D drawings, documentation, and other data required for
product design and manufacturing, including geometric and non-geometric data such as form
features, tolerances, material properties, and surfaces and the information typically associated
with Computer Aided Design and Manufacturing (CAD/CAM) should be described in
international standards terms. Currently the Initial Graphics Exchange Specification (IGES)
should be used. IGES will eventually be replaced by STEP (Standard for the Exchange of
Product Model Data) which will be capable of representing product data throughout its life-cycle
and of specifying file exchange. STEP is the informal name for ISO 10303 which is likely to be
adopted for NATO usage.
Standard
[E]

ISO/IEC 10303 - 1

1994

D-34

Industrial Automation
Systems and Integration
Product Data
Representation and
Exchange
Part 1 Overview and
Fundamental Principles

Standard
[E]

ISO/IEC 10303
11

1994

1999

Standard
[E]

ISO/IEC 10303
11 Cor. 1
ISO/CD TR 10303
12

Standard
[E]

ISO/AWI 10303
14

Standard
[E]

ISO 10303 21

1997

1994

Part 11 Description
Methods: The EXPRESS
Language Reference
Manual

Part 12 Description
Methods: The
EXPRESS-I Language
Reference Manual
Part 14 XML
Representation for
EXPRESS-Driven Data
Part 21 Implementation
Methods: Clear Text
Encoding of the
Exchange Structure

ISO 10303 21
CD Amd. 1

Standard
[E]

ISO 10303 21
Cor. 1
ISO 10303 22

Standard
[E]

ISO/DIS 10303
23

Standard
[E]

ISO/CD 10303
24

Standard
[E]

ISO/AWI 10303
26

Standard
[E]
Standard
[E]

ISO/CD 10303
27
ISO 10303 31

1996
1998

Part 22 Implementation
Methods: Standard Data
Access Interface
Part 23 Implementation
Methods: C++ Language
Binding to the Standard
Data Access Interface
Part 24 Implementation
Methods: C Language
Binding to the Standard
Data Access Interface
Part 26 Implementation
Methods: Interface
Definition Language
Binding to the Standard
Data Access Interface

1994

Part 31 Conformance
Testing Methodology
and Framework: General
Concepts

D-35

Standard
[E]

ISO 10303 32

Standard
[E]

ISO 10303 34

Standard
[E]

ISO 10303 35

Standard
[E]

ISO 10303 41

1994

ISO/DIS 10303-41
ISO 10303 42

2nd Ed.
1994

ISO/DIS 1030342

2nd Ed.

ISO 10303 42
Cor. 1

1999

Standard
[E]

Standard
[E]

1998

ISO 10303 42
Cor. 2
ISO 10303 43

1994

ISO/DIS 1030343

2nd Ed.

ISO 10303 43
Cor. 1

1999

D-36

Part 32 Conformance
Testing Methodology
and Framework:
Requirements on Testing
Laboratories and Clients
Part 34 - Conformance
Testing Methodology
and Framework:
Abstract Test Methods
Part 35 - Conformance
Testing Methodology
and Framework:
Abstract Test Methods
for Standard Data Access
Interface Implementation
Part 41 Integrated
Generic Resources:
Fundamentals of Product
Description and Support

Part 42 Integrated
Generic Resources:
Geometric and
Topological
Representation

Part 43 - Integrated
Generic Resources:
Representation
Structures

Standard
[E]

ISO 10303 44

1994

ISO/DIS 1030344

2nd Ed.

ISO 10303 44
Cor. 1
ISO 10303 45

1999

ISO 10303 45
Cor. 1
ISO 10303 46

1999

ISO 10303 46
Cor. 1
ISO 10303 47

1999

Standard
[E]

ISO 10303 49

1998

Standard
[E]

ISO 10303 101

1994

ISO 10303 101

Cor. 1
ISO 10303 104

1999

Standard
[E]

ISO 10303 105

1996

Standard
[E]

ISO 10303 106

Standard
[E]

ISO 10303 107

Standard
[E]

Standard
[E]

Standard
[E]

Standard
[E]

1998

1994

1997

D-37

Part 44 - Integrated
Generic Resources:
Product Structure
Configuration

Part 45 - - Integrated
Generic Resources:
Materials
Part 46 Integrated
Generic Resources:
Visual Presentation
Part 47 - Integrated
Generic Resources:
Shape Variation
Tolerances
Part 49 - - Integrated
Generic Resources:
Process Structure and
Properties
Part 101 Integrated
Application Resources:
Draughting
Part 104 - Integrated
Application Resources:
Finite Element Analysis
Part 105 - Integrated
Application Resources:
Kinematics
Part 106 - Integrated
Application Resources:
Building Construction
Core Model
Industrial Data
Part 107 - Integrated
Application Resources:
Engineering Analysis
Core Application
Reference Model (EA CARM)

Standard
[E]

ISO 10303 201

1994

Standard
[E]

ISO 10303 202

1996

Standard
[E]

ISO 10303 203

1994

ISO 10303 203

Cor. 1

1996

ISO 10303 203

Cor. 2
ISO 10303 207

1998

Standard
[E]
Standard
[E]

ISO 10303 208

Standard
[E]

ISO 10303 209

Standard
[E]

ISO 10303 210

Standard
[E]

ISO 10303 212

Standard
[E]

ISO 10303 213

Standard
[E]

ISO 10303 214

Standard
[E]

ISO 10303 215

1999

D-38

Product Data
Part 201 Application
Protocol: Explicit
Draughting
Part 202 Application
Protocol: Associative
Draughting
Part 203 - Application
Protocol: Configuration
Controlled Design

Part 207 - Application

Protocol: Sheet Metal
Die Planning and Design
Part 208 - Application
Protocol: Life-cycle
Management
Part 209 - Application
Protocol: Composite and
Metallic Structural
Analysis and Related
Design
Part 210 - Application
Protocol: Electronic
Assembly,
Interconnection, and
Packaging Design
Part 212 - Application
Protocol:
Electrotechnical Design
and Installation
Part 213 - Application
Protocol: Numerical
Control Process Plans for
Machined Parts
Part 214 - Application
Protocol: Core Data for
Automotive Mechanical
Design Processes
Part 215 - Application
Protocol: Ship
Arrangement

Standard
[E]

ISO 10303 216

Standard
[E]
Standard
[E]
Standard
[E]

ISO 10303 217

Standard
[E]

ISO 10303 222

Standard
[E]

ISO 10303 223

Standard
[E]

ISO 10303 224

Standard
[E]

ISO 10303 225

Standard
[E]

ISO/WD 10303
226

Standard
[E]

ISO/DIS 10303
227

Standard
[E]

ISO/AWI 10303
229

Part 216 - Application

Protocol: Ship Molded
Forms
Part 217 - Application
Protocol: Ship Piping
Part 218 - Application
Protocol: Ship Structures
Part 221 - Application
Protocol: Functional
Data and Their
Schematic
Representation for
Process Plants
Part 222 - Application
Protocol: Exchange of
Product Data for
Composite Structures
Part 223 - Application
Protocol: Exchange of
Design and
Manufacturing Product
Information for Cast
Parts
Part 224 - Application
Protocol: Mechanical
Product Definition for
Process Planning Using
Machining Features
Part 225 - Application
Protocol: Building
Elements Using Explicit
Shape Representation
Part 226 - Application
Protocol: Ship
Mechanical Systems
Part 227 - Application
Protocol: Plant Spatial
Configuration
Part 229 - Application
Protocol: Exchange of
Design and
Manufacturing Product
Information for Forged
Parts

ISO 10303 218

ISO 10303 221

D-39

Standard
[E]

ISO/WD 10303
230

Standard
[E]

ISO/CD 10303
231

Standard
[E]

ISO/CD 10303
232

Standard
[E]

ISO/AWI 10303
233

Standard
[E]

ISO/AWI 10303
234

Standard
[E]

ISO/CD 10303
235

Standard
[E]

ISO/PRF TR
10303 307

Standard
[E]

ISO/PRF TS
10303 324

Standard
[E]

ISO/AWI 10303
332

Standard
[E]

ISO/PRF 10303
501

Standard
[E]

ISO/PRF 10303
502

Standard
[E]

ISO/PRF 10303
503

Part 230 - Application

Protocol: Building
Structural Frame:
Steelwork
Part 231 - Application
Protocol: Process
Engineering
Part 232 - Application
Protocol: Technical Data
Packaging Core
Information and
Exchange
Part 233 Systems
Engineering Data
Representation
Part 234 - Application
Protocol: Ship
Operational Logs,
Records, and Messages
Part 235 - Application
Protocol: Materials
Information for the
Design and Verification
of Products
Part 307 Abstract Test
Suite: Sheet Metal Die
Planning and Design
Part 324 Abstract Test
Suite: Mechanical
Product Definition for
Process Plans Using
Machining Features
Part 332 Abstract
Suite: Technical Data
Package
Part 501 Application
Interpreted Construct:
Edge-based Wireframe
Part 502 Application
Interpreted Construct:
Shell-based Wireframe
Part 503 Application
Interpreted Construct:
Geometrically Bound 2D
Wireframe

D-40

Standard
[E]

ISO/DIS 10303
504

Standard
[E]

ISO/DIS 10303
505

Standard
[E]

ISO/DIS 10303
506

Standard
[E]

ISO/DIS 10303
507

Standard
[E]

ISO/DIS 10303
508

Standard
[E]

ISO/DIS 10303
509

Standard
[E]

ISO/PRF 10303
510

Standard
[E]

ISO/DIS 10303
511

Standard
[E]

ISO/FDIS 10303
512

Standard
[E]

ISO/DIS 10303
513

Standard
[E]

ISO/FDIS 10303
514

Standard
[E]

ISO/DIS 10303
515

Part 504 Application

Interpreted Construct:
Draughting Annotation
Part 505 Application
Interpreted Construct:
Drawing Structure and
Administration
Part 506 Application
Interpreted Construct:
Draughting Elements
Part 507 Application
Interpreted Construct:
Geometrically Bounded
Surface
Part 508 Application
Interpreted Construct:
Non-manifold Surface
Part 509 Application
Interpreted Construct:
Manifold Surface
Part 510 Application
Interpreted Construct:
Geometrically Bounded
Wireframe
Part 511 Application
Interpreted Construct:
Topologically Bounded
Surface
Part 512 Application
Interpreted Construct:
Faceted Boundary
Representation
Part 513 Application
Interpreted Construct:
Elementary Boundary
Representation
Part 514 Application
Interpreted Construct:
Advanced Boundary
Representation
Part 515 Application
Interpreted Construct:
Constructed Solid
Geometry

D-41

Standard
[E]

ISO/DIS 10303
517

Standard
[E]

ISO/CD 10303
518

Standard
[E]

ISO/FDIS 10303
519

Standard
[E]

ISO/FDIS 10303
520

Standard
[ ]

ANSI/EIA 548

1988

NOT FOUND

Part 517 Application

Interpreted Construct:
Mechanical Design
Geometric Presentation
Part 518 Application
Interpreted Construct:
Mechanical Design
Shaded Representation
Part 519 Application
Interpreted Construct:
Geometric Tolerances
Part 520 Application
Interpreted Construct:
Associative Draughting
Elements
Electronic Design
Interchange Format
(EDIF)
May be subsumed by
STEP
IEEE Standard VHDL
Language Reference
Manual

Standard
[E]

ANSI/IEEE 1076

1993

Standard
[E]

ANSI/IEEE 1076.2

1996

IEEE Standard VHDL

Language Math
Packages

Standard
[E]

ANSI/IEEE 1076.3

1997

IEEE Standard VHDL

Synthesis Packages

Standard
[E]

ANSI/IEEE 1076.4

1995

IEEE Standard for

VITAL ApplicationSpecific Integrated
Circuit (ASIC) Modeling
Specification

Standard
[T]

ANSI/ASME
Y14.26M / FIPS
177

Ver 5.2
(1989)

Profile
[E]

STEP Applications

Initial Graphics
Exchange Specification
(IGES)
May be subsumed by
STEP
At least 34 different ISO
STEP Application
Profiles are under
development.

D-42

Profile
[T]

MIL-D-28000
NOT FOUND IN
ASSIST

Rev A
10 Feb 92
Amend 1
14 Dec 92

Digital Representation
for Communication of
Product Data: IGES
Application Subset and
IGES Application
Protocols.

D8.5 Images
Non-processable, optically scanned drawings and documents should be specified using raster
graphics interchange standards.
These were developed initially for digital facsimile over
Integrated Services Digital Networks (ISDN). Two forms of raster data may be specified: Type I
(untiled) and Type II (tiled).
Type II (tiled) is the preferred format. A tiled raster image resembles a two-dimensional grid
with each tile or set of pixels representing a portion of the image.
Text and graphics in raster data formats allow a rapid and consistent access to stored images and
are suitable for electronic transmission. Raster files can also be converted to digital documents
for work processing or desktop publishing and edited through manipulation of individual pixels.
A number of standards exist which are not CALS-specific.
Standard
[R]

ISO/IEC 10918 - 1

1994

Standard
[R]

ISO/IEC 10918 - 2

1995

Standard
[R]

ISO/IEC 10918 3

1997

ISO/IEC 10918 3
Amd. 1

Information Technology
Digital Compression
and Coding of
Continuous-tone Still
Images
Part 1 - Requirements
and Guidelines
Part 2 Compliance
Testing
Part 3 Extensions
Provision to Allow
Registration of New
Compression Types and
Revisions in the SPIFF
Header

D-43

Standard
[R]

ISO/IEC 10918 - 4

1999

Standard
[ ]

ISO/IEC 12087 - 1

1995

Standard
[ ]

ISO/IEC 12087 2

1994

ISO/IEC 12087 2
Cor. 1
ISO/IEC 12087 3

1997
1995

Part 3 Image
Interchange Facility (IIF)

ISO/IEC 12087 3
Amd. 1

1996

Standard
[ ]

ISO/IEC 12087 5

1998

Standard
[R]

ITU-TSB T6
(formerly CCITT
Recommendation
T.6)

1988

Type Definition,
Scoping, and Logical
Views for Image
Interchange Facility
Part 5 Basic Image
Interchange Format
(BIIF)
Facsimile Coding and
Control Functions for
Group IV Facsimile
Apparatus.

Standard
[ ]

Part 4 Registration of
JPEG Profiles, SPIFF
Profiles, SPIFF tags,
SPIFF Color Spaces,
APPn Markers, SPIFF
Compression Types and
Registration Authorities
(REGAUT)
Information Technology
Computer Graphics
and Image Processing Image Processing and
Interchange (IPI)
Functional Specification
Part 1 Common
Architecture for Imaging
Part 2 Programmers
Imaging Kernel System
Application Program
Interface

D8.6 CD-ROM Storage/Transfer Media

Multi-media applications may specify the use of CD-ROM for file transfer or technical
documentation applications.

D-44

Standard
[]

ISO/IEC DIS 9660

1988

Standard
[]

ISO/IEC 10149

1995

Information Processing Volume and File

Structure of CD-ROM
for Information
Exchange.
Information Technology
- Data Interchange on
Read-only 120mm
Optical Data Discs (CDROM)

Note: The Policy and applicable standards for NATO CD-ROM usage have not yet been
confirmed for CALS applications. In particular, a number of NATO STANAGS contain CDROM specifications and work is in hand to identify such references.
D8.7 Video and Motion Picture Media
Multi-media applications may specify the inclusion of Video and Motion Picture files or still
images derived from moving pictures. Such specifications, together with legacy data migration
strategies, will also need to include appropriate reference to the acceptable data compression
standards.
Standard
[E]

ISO/IEC 10918 - 1

1994

Standard
[E]

ISO/IEC 10918 2

1995

Standard
[E]

ISO/IEC 10918 3

1997

Part 3 Extensions

ISO/IEC 10918 3
Amd. 1

1997

ISO/IEC 10918 4

1999

Provision to Allow
Registration of New
Compression Types and
Revisions in the SPIFF
Header
Part 4 Registration of
JPEG Profiles, SPIFF
Profiles, SPIFF Tags,
SPIFF Color Spaces, APPn
Markers, SPIFF
Compression Types and
Registration Authorities
(REGAUT)

Standard
[E]

D-45

Information Technology Digital Compression and

Coding of Continuous-ton
Still Images
Part 1 Requirements and
Guidelines
Part 2 Compliance
Testing

Standard
[R]

ISO/IEC 11172 - 1

1993

ISO/IEC 11172 1
Cor. 1

1996
1999

Information Technology Coding of Motion Pictures

and associated Audio for
Digital Storage Media at
up to About 1.5 Mbps
Part 1 - Systems

ISO/IEC 11172 1
Cor. 2
Standard
[R]

ISO/IEC 11172 2

1993

ISO/IEC 11172 2
Cor. 1

1996

ISO/IEC 11172 2
Cor. 1
ISO/IEC 11172 3

1999

ISO/IEC 11172 3
Cor. 1
ISO/IEC 11172 4

1996
1995

Part 4 Compliance
Testing

Standard
[R]

ISO/IEC TR 11172
5

1998

Part 5 Software
Simulation

Standard
[R]

ISO/IEC 13813

1998

Standard
[ ]

ISO/IEC 11544

1993

ISO/IEC 11544
Cor. 1

1995

Information Technology
Programming Languages
Generic Packages of Real
and Complex Type
Declarations and Basic
Operations of Ada
Information Technology Coded Representation of
Picture and Audio
Information - progressive
bi-level image
compression (JBIG).

Standard
[R]

Standard
[R]

1993

Part 2 - Video

Part 3 - Audio

Note: The Policy and applicable standards for NATO Video and Motion Picture Video usage
have not yet been confirmed for CALS applications.
D8.8 Digital Audio
Multi-media applications may specify the inclusion of Audio files but to date there is no
internationally accepted standard for digital audio specification.

D-46

Standard
[]
Profile
[ ]
STANAG
[ ]

TBD
TBD
TBD

Note: The Policy and applicable standards for NATO Audio usage have not yet been
determined.
D8.9 Hypermedia and Multimedia
The HyTime standard, which is built on SGML, is used to create relational links between objects
(text, graphics, audio, video, etc). The objects are then linked in a document or between
documents so as become accessible within a computer system.
Standard
[R]

ISO/IEC 10744

1997

Standard
[ ]

ISO/IEC 13522 - 1

1997

Standard
[ ]

ISO/IEC 13522 - 3

1997

Standard
[ ]
Standard
[ ]

ISO/IEC 13522 - 4

1996

ISO/IEC 13522 5

1997

ISO/IEC 13522 5
AWI Amd. 1
ISO/IEC 13522 5
Cor. 1

Information Technology Hypermedia/Time Based

Document Structuring
Language (HyTime).
Information Technology Coding of Multimedia
and Hypermedia
Information (MHEG).
Part 1 MHEG Object
Representation Base
Notation (ASN.1)
Part 3 MHEG Script
Interchange
Representation
Part 4 MHEG
Registration Procedure
Part 5 Support for Baselevel Interactive
Applications
Class Extensions

1999

D-47

Standard
[ ]

ISO/IEC 13522 - 6

Standard
[ ]

ISO/IEC AWI
13522 - 7

Standard
[ ]

ISO/IEC 13522 - 8

1998

Part 6 Support for

Enhanced Interactive
Applications
Part 7 Interoperability
and Conformance Testing
for ISO/IEC 13522-5
Part 8 XML Notation
for ISO/IEC 13522-5

Note: The Policy and applicable standards for NATO Hypermedia and Multimedia use has not
yet been confirmed or validated in the NATO CALS context.
D8.10 Interactive Electronic Technical Manuals
An Interactive Electronic Technical Manual (IETM) is a technical manual (e.g., maintenance,
user, training, operations, etc) prepared (authored) in digital form on a suitable medium, by
means of an automated authoring system, designed for electronic screen display to an end-user,
and possessing the following characteristics:

The format and style of the presented information are optimized for screen presentation
to ensure maximum comprehension; that is, the presentation format is frame-oriented
and not page-oriented."
The elements of technical information constituting the technical manual are so
interrelated that a user's access to the required information is facilitated to the greatest
possible extent and is achievable by a variety of paths.
Display devices, including personal computers and portable laptop devices can
function interactively (as a result of user requests and information input) in providing
procedural guidance, navigation directions, and supplemental information.
Screen presentations can include material derived from data stored in textual, graphical,
audio, or video form in a relational database which is composed of logically connected,
bud randomly accessible IETM data elements.

D-48

Standard
[]

ISO 12083

1994

Standard
[E]

ISO/DIS 2709

1996

Standard
[E]

AECMA SPEC
1000D

Change 4

Standard
[T]

MIL-M-87268

20 Nov 92

WAS NOT
FOUND
MIL-D-87269

20 Nov 92

WAS NOT
FOUND
MIL-Q-87270

Interactive Electronic
Technical Manual
(IETM) Database

20 Nov 92

Interactive Electronic
Technical Manual
(IETM) -Quality
Assurance Requirements
for Quality Assurance
Program.

Standard
[T]

Standard
[]

Cancelled No
S/S Document

31 May 1996

Information and
Documentation Electronic Manuscript
Preparation and Markup
Information and
Documentation - Format
for Information
Exchange
International
Specification for
technical Publications
using a Common Source
Database.
Interactive Electronic
Technical Manual
(IETM) Content

Notes: See Note to Sect 10.3.2

AECMA SPEC 1000D embodies both hard-copy and IETM requirements and emphasis the use
of Internationally agreed standards:

Text to SGML (ISO 8879)

Graphics to CCITT Group 4 (MIL-R-28002)
Vector Graphics to IGES V4 (MIL-D-28000)
Images to CGM (MIL-D-28003)
Magnetic Tape Transfer to MIL-STD-1840A

D9.0 SYSTEM MANAGEM ENT STANDARDS AND APPLICATION PROFILES

D9.1 Systems Engineering
The term Systems Engineering is used to describe an interdisciplinary, collaborative approach to
derive, evolve, and verify a life-cycle balanced system solution which satisfies customer

D-49

expectations and meets public acceptability. The process includes the planning, implementation,
and control of the total effort to develop a total system solution in response to the user
requirement and external constraints.
Standard
[E]

IEEE 1220

1994
(Feb 1995)
Trial
Use
Standard

Application
and
Management
of
the
Systems
Engineering
Process

D9.2 Integrated Logistics Support

The term Integrated Logistics Support (ILS) is used to describe a disciplined management
approach, affecting both customer and industry, aimed at optimizing equipment Life-cycle Costs.
It includes elements for influencing equipment design and determining support requirements to
achieve supportable and supported equipment.
Profile
[E]

UK DEF STAN
0060

Standard
[T]

AC/305(SLM) D23

Handbook
[T]

MIL-HDBK 59B
NOT 1

Interim Issue
1 1994

Canceled
10 Sep 1997

Application of Integrated
Logistic Support (ILS)
Orientation Document for
Integrated Logistic Support
Within the Framework of
Multinational Equipment
Projects
Continuous Acquisition and
Life-cycle Support(CALS)
Implementation Guide

No S/S Document
D9.3 Configuration Management
Configuration management provides the technical and administrative direction and surveillance
actions taken to identify and document the functional and physical characteristics of a
configuration item, to control the changes to a configuration item and its characteristics, and to
record and report change processing and implementation status.

D-50

Standard
[E]

ISO/CD 9004

Standard
[E]

ISO/CD 9004 - 1

1994

Standard
[E]

ISO 9004 2

1991

ISO 9004 2 Cor.

1
ISO 9004 - 3

1994
1993

Part 3 Guidelines for

Processed Materials

ISO 9004 4

1993

Part 4 Guidelines for

Quality Improvement

ISO 9004 4 Cor. 1

ISO/IEC 10164 1

1994
1993

ISO/IEC 10164 1
Amd. 1

1996

ISO/IEC 10164 1
Amd. 1 Cor. 1
ISO/IEC 10164 2

1996
1993

Part 2 State
Management Function

ISO/IEC 10164 2
Amd. 1

1996

Implementation
Conformance Statement
Proformas

ISO/IEC 10164 2
Amd. 1 Cor. 1

1996

ISO/IEC 10164 2
Cor. 1

1996

Standard
[E]
Standard
[E]
Standard
[E]

Standard
[E]

D-51

Quality Management
Systems - Guidelines for
Performance
Improvements
Quality Management and
Quality System Elements
Part 1 Guidelines
Part 2 Guidelines for
Services

Information Technology
- Open Systems
Interconnection
Systems Management
Part 1 Object
Management Function
Implementation of
Conformance Statement
Proformas

Standard
[E]

Standard
[E]

Standard
[E]

ISO/IEC 10164 3

1993

ISO/IEC 10164 3
Amd. 1

1996

ISO/IEC 10164 3
Amd. 1 Cor. 1
ISO/IEC 10164 4

1996
1992

Part 4 Alarm Reporting

Function

ISO/IEC 10164 4
Amd. 1

1995

Implementation of
Conformance Statement
Proformas

ISO/IEC 10164 4
Amd. 1 Cor. 1

1996

ISO/IEC 10164 4
Cor. 1

1994

ISO/IEC 10164 4
CD Cor. 2
ISO/IEC 10164 5

Part 3 Attributes for

Representing
Relationships
Implementation of
Conformance Statement
Proformas

1993

Part 5 Event Report

Management Function

ISO/IEC 10164 5
Amd. 1

1995

Implementation of
Conformance Statement
Proformas

ISO/IEC 10164 5
Amd. 1 Cor. 1

1996

ISO/IEC 10164 5
Cor. 1

1994

ISO/IEC 10164 5
CD Cor. 2

D-52

Standard
[E]

Standard
[E]

Standard
[E]

Standard
[E]

Standard
[E]

ISO/IEC 10164 6

1993

Part 6 Log Control

Function

ISO/IEC 10164 6
Amd. 1

1996

Implementation of
Conformance Statement
Proformas

ISO/IEC 10164 6
Amd. 1 Cor. 1

1996

ISO/IEC 10164 6
CD Amd. 2
ISO/IEC 10164 7

1992

Part 7 Security alarm

reporting Function

ISO/IEC 10164 7
Amd. 1

1995

Implementation
Conformance Statement
Proformas

ISO/IEC 10164 7
Amd. 1 Cor. 1
ISO/IEC 10164 8

1996

ISO/IEC 10164 8
Cor. 1

1995

ISO/IEC 10164 8
Cor. 2

1996

ISO/IEC 10164 8
Cor. 3
ISO/IEC 10164 9

1999

ISO/IEC 10164 9
Cor. 1
ISO/IEC 10164
10

1996

1993

1995

Part 8 Security Audit

Trail Function

Part 9 Objects and

Attributes for Access
Control

1995

Part 10 Usage
Metering Function for
Accounting Purposes

1998

Implementation
Conformance State
Proformas

ISO/IEC 10164
10 Amd. 1
1999
ISO/IEC 10164
10 Cor. 1

D-53

Standard
[E]

ISO/IEC 10164
11

1994

Part 11 Metric Objects

and Attributes

1998

Implementation
Conformance State
Proformas

ISO/IEC 10164
11 Amd. 1
1999

Standard
[E]

ISO/IEC 10164
11 Cor. 1
ISO/IEC 10164
12

1994

Part 12 Test
Management Function

1998
ISO/IEC 10164
12 Cor. 1
1999

Standard
[E]

ISO/IEC 10164
12 Cor. 2
ISO/IEC 10164
13

1995

Part 13 Summarization
Function

1999

Implementation
Conformance State
Proformas

ISO/IEC 10164
13 Amd. 1
1999

Standard
[E]

ISO/IEC 10164
13 Cor. 1
ISO/IEC 10164
14

Standard
[E]

ISO/IEC 10164
14 Cor. 1
ISO/IEC 10164
15

Standard
[E]

ISO/IEC 10164
15 Cor. 1
ISO/IEC 10164
16

1996

Part 14 Confidence and

Diagnostic Test
Categories

1995

Part 15 Scheduling
Function

1999

1997

Part 16 Management
Knowledge Management
Function

1998

Extension for General

Relationship Model

ISO/IEC 10164
16 Amd. 1

D-54

Standard
[E]

ISO/IEC 10164
17

Standard
[E]

ISO/IEC 10164
17 Cor. 1
ISO/IEC 10164
18

1996

Part 17 Change Over

Function

1999

1997

Part 18 Software
Management Function

1999

Standard
[E]

ISO/IEC 10164
18 Cor. 1
ISO/IEC 10164
19

Standard
[E]

ISO/IEC 10164
20

1999

Standard
[E]

ISO/IEC 10164
21

1998

Standard
[E]
Standard
[T]

ISO/IEC FCD
10164 22
STANAG 4159

Standard
[T]

MIL-STD-973

Profile
[N]

MIL-STD-483A
NOT 1

1998

Ed 2

Canceled

S/S MIL-STD-973

Standard
[]

MIL-STD-498
NOT 1

Canceled

S/S IEEE/EIA
12207.0 12207.2

D-55

Part 19 Management
Domain and
Management Policy
Management Function
Part 20 Time
Management Function
Part 21 Command
Sequencer for Systems
Management
Part 22 Response Time
Monitoring Function
NATO Materiel
Configuration
Management Policy and
Procedures for multinational Joint Projects
Configuration
Management Practices
for Systems, Equipment,
Munitions, and
Computer Programs.
Configuration
Management Practices
for Systems, Equipment,
Munitions, and
Computer Programs.
Configuration
Management and
Software Development.

Note: The Policy and applicable standards for NATO Configuration Management have not yet
been determined, but the NCMB/NICG -sponsored Acquisition Workshop held in 1994-1995 has
this topic under consideration.
D9.4 Environmental Life-cycle Assessme nt
Environmental issues are becoming increasingly important and this field is undergoing rapid
advancement and change. Not only is the body of knowledge increasing but the demand for
consistent, usable guidelines and reliable standards is also becoming obvious. In the face of
environmental claims, it is essential to know the environmental impact of product design, usage
throughout the life-cycle, and ultimate disposal. Although this topic is not specific to CALS,
users and regulatory bodies will require access, throughout a product life-cycle, to reliable
information to assist in the development of regulations, operating instructions, and disposal
programs which recognize environmental issue.
Standard
[E]

ISO 14040

1997

Standard
[E]

ISO 14041

1998

Standard
[E]
Profile
[]

ISO/FDIS 14042

1999

Environmental
Management Life-cycle
Assessment Principles
and Framework
Life-cycle Assessment
Goal and Scope
Definition and Inventory
Analysis
Life-cycle Impact
Assessment

Note: The Policy for Life-cycle Assessment and applicable standards for NATO assessment of
environmental impacts have not yet been determined, but the NCMB/NICG -sponsored
Acquisition and Operational Logistics Workshops held during 1994 -1996 have Life-cycle
matters under consideration.
D9.5 Disposal of Equipment
This paragraph will consider the methodology required for defense equipment disposal in the
future.

Montreal Convention Particular reference will be made to the standards applicable to the
disposal of products which require special handling (e.g., Radioactive, Toxic, Corrosive,
Poisonous, etc) and to the life-cycle data requirements of products covered by the
Montreal Convention.
UN List - Although no standard applicable to disposal of hazardous items has yet been
identified, some information is contained in a document know as The UN List
UN Recommendations on the Transport of Dangerous Goods ST/SG/AC.10/1 Rev 5
Chapter 2
D-56

UN Publication Sales No E87 VIII.1 ISBN 92-1-13 9023-0

Reference may also be made to NATO mechanisms which exist [STANAGS] or are under
development [E.G., NAMSA SHARE] to assist in formulating disposal methodology.
U.S. DoD MIL-STD-1388 contains some data elements which carry information appropriate to
the U.S. Disposals Process but this standard is currently being reviewed pending its withdrawal.
Standard
[]
Profile
[]

TBD

D9.6 Quality Management

Although Quality Management is in no way specific to CALS, quality assessments may well be
based on data acquired through CALS tools and the appropriate standards are therefore relevant.
However, it is not possible to recommend a specific approach to quality management. The
CALS operating environment should be analyzed and the quality requirements determined from
user requirements. The user requirements, which must be well defined, should determine the
selection of the most critical factors in order to assess an acceptable level of service of the
required quality.
Standard
[R]
Standard
[R]

ISO 8402

1994

Standard
[R]

ISO 9000 - 1

1994

Standard
[R]

ISO 9000 - 2

1997

Standard
[R]

ISO 9000 3

1997

ISO/CD 9000

D-57

Quality - Vocabulary
Quality Management
Systems- Fundamentals
and Vocabulary
Quality Management and
Quality Assurance
Standards
Part 1 Guidelines for
Selection and Use
Part 2 Generic
Guidelines for the
Application of ISO 9001,
ISO 9002, and ISO 9003
Part 3 Guidelines for
the Application of ISO
9001: 1994 to the
Development, Supply,
Installation, and
Maintenance of
Computer Software

Standard
[R]

ISO 9000 4

1993

Standard
[R]

ISO 9001

1994

ISO/CD 9001

Part 4 Guide to
Dependability Program
Management
Quality Systems - Model
for Quality Assurance in
Design, Development,
Production, Installation,
and Servicing.
Quality Management
Systems - Requirements

ISO 9001 Cor. 1

1995
Standard
[R]

ISO/CD 9004

Standard
[R]

ISO 9004 - 1

1994

Standard
[R]

ISO 9004 2

1991

ISO 9004 2 Cor.

1
ISO 9004 3

1994

ISO 9004 4

1993

ISO 9004 4 Cor.

1
STANAG 4107

1994

Standard
[R]
Standard
[R]

Standard
[R]
Standard
[T]

AQAP 1

Standard
[T]

AQAP 13

1993

Quality Management
Systems Guidelines for
Performance
Improvements.
Quality Management and
Quality Systems
Elements
Part 1 Guideline
Part 2 Guidelines for
Services

Part 3 Guidelines for

Processed Materials
Part 4 Guidelines for
Quality Improvement

Mutual Acceptance of
Government Quality
Assurance
NATO Requirements for
an Industrial Quality
Control Program
NATO Software Quality
Control System
Requirements.

Note: Quality Standards for NATO CALS applications have not yet been verified.

D-58

D10.0 DATA FORMATS AND DELIVERY STANDARDS

D10.1 Contract Data Requirements Lists
Specific data requirements, formats, and delivery modes will have to be specified for each
project on one or more Contract Data Requirements Lists (CDRL). Generic guidelines for multinational projects have been prepared by AC/313 (Committee on Acquisition Practices) and this
subject is being considered in detail in the NCMB/NICG-sponsored Acquisition Workshop
(1994-1996).
Guidelines
[E]
Standard
[]
Profile
[]

AC/313 - D/67

9 Jun 95

STANAG

NK

D10.2 Classified Data

Classified data will be safeguarded in accordance with the NATO Regulations appropriate to
each Project. [ C-M (55)15(FINAL) ].
D10.3 Data Encryption
In the past, data encryption needs could only be met, legally, through the use of Governmentapproved encryption methods. More recently, however, commercial encryption methods have
been developed and are now in use within NATO although the approval for such activity has not
yet been confirmed as being generally applicable.
Standard
[]
Standard
[]
Profile
[]

STANAG

NK

D10.4 Digital Signatures

Digital signatures may be specified in accordance with Electronic Data Interchange agreements
that form part of the contractual negotiations on a project. Although this subject is still in its
infancy, guidelines are under development by AC/313 together with suitable sample clauses for
use in Electronic Data Interchange agreements.
The following standards currently apply.

D-59

Standard
[R]

ISO/IEC 9796

Standard
[R]
Standard
[R]
Standard
[R]

ISO/IEC DIS 9796

-1
ISO/IEC 9796 - 2

Profile
[E]
Standard
[]
Guidance
[]

FIPS 161-1

1991
Ed 1

1997

ISO/IEC FDIS
9796 - 3

STANAG
AC/313 -D/66

Information Technology
- Security Techniques Digital Signature
Scheme giving Message
Recovery
Part 1 Mechanisms
Using Redundancy
Part 2 Mechanisms
using a Hash Function
Part 3 Discrete
Logarithm Based
Mechanisms
U.S. Federal Information
Processing Standard
NK

14 Sep 95

D10.5 Digital Data Delivery

Data will be acquired in digital form unless specific operational reasons dictate otherwise.
Product (Equipment) Data should be developed and presented in digital form regardless of the
intended use of such data throughout the product or equipment life-cycle.
Data with a relatively short life (e.g., Agenda, Minutes, schedules, spreadsheets, plans, and
progress reports) may be specified according to project management requirements:

According to the standards contained in this Section

According to administrative standards used in the project (For Example HQ NATO has
adopted WordPerfect for word-processing and Microsoft Excel for Spreadsheets). The
are not CALS Standards but their specification may satisfy the management requirement
Mutually Agreeable Commercial Software agreed by all participants in a Project.

In general, it should be noted that, in principle, CALS products should be software and hardware
independent. Any departure from this principle must take into account the eventual use of the
data so acquired and management should consider not only Project Office requirements but also
the needs of the users during the whole of the life-cycle, so far as these may be ascertained.
D10.6 Electronic Data Interchange (EDI)
Data Exchange should be specified by electronic means unless operational requirements have
determined that such means are inappropriate or not cost-effective.

D-60

Standard
[R]

ISO 7372

1993

Standard
[R]

ISO 9735

1988
1992

ISO 9735 Amd. 1

Standard
[R]

ISO 9735 1

1998

ISO 9735 1 Cor. 1

1998

Standard
[R]

ISO 9735 2

1998

Standard
[R]

ISO 9735 3

1998

Standard
[R]

ISO 9735 4

1998

Standard
[R]

ISO 9735 5

1999

Standard
[R]

ISO 9735 6

1999

Standard
[R]

ISO 9735 7

1999

D-61

Trade Data Interchange

Trade Data Elements
Directory
Electronic Data
Interchange for
Administration,
Commerce and Transport
(EDIFACT)
Application Level Syntax
Rules

Syntax Version Number 4

Part 1 Syntax Rules
Common to all Parts,
Together with Syntax
Service Directories for
Each of the Parts
Syntax Version Number 4
Part 2 Syntax Rules
Specific to Batch EDI
Syntax Version Number 4
Part 3 Syntax Rules
Specific to Interactive
EDI
Syntax Version Number 4
Part 4 Syntax and
Service Report Message
for Batch EDI (message
type CONTRL)
Syntax Version Number 4
Part 5 Security Rules
for Batch EDI
(authenticity, integrity,
and non-repudiation of
origin)
Syntax Version Number 4
Part 6 Security
Authentication and
Acknowledgement
Message (message type
AUTACK)
Syntax Version Number 4
Part 7 Security Rules
for Batch EDI
(confidentiality)

Standard
[R]

ISO 9735 8

1998

Standard
[R]

ISO 9735 9

1999

Standard
[T]

ANSI X.12

Version 3
Release 3
Sub-release
2 (June
1993)

Profile
[E]

FIPS 161-1

Standard
[T]

STANAG 5500

Profile
[T]

ADatP-3

Syntax Version Number 4

Part 8 Associated Data
in EDI
Syntax Version Number 4
Part 9 Security Key and
Certificate Management
Message (message type
KEYMAN)

U.S. Federal Information

Processing Standard
(EDIFACT)
(Transaction Set 841?)
NATO MESSAGE TEXT
FORMATTING
SYSTEM
Allied Data Publication 3
- NATO Message Text
Formatting System
Part 1 - Rules and
Procedures

Note: An EDIFACT-compliant version of AECMA Specification 2000M was issued in DRAFT

in late-1995 and will be formally issued in 1996. Whereas X.12 is the current Requirement of
U.S. CALS DoD, it should also be noted that MIL-HDBK-59B and MIL-STD-974(CITIS)
explicitly reference FIPS 161-1 EDIFACT for CALS applications and ANSI have submitted
appropriate change requests to facilitate migration to EDIFACT. UN/ted Nations/Economic
Commission for Europe (UN/ECE) EDIFACT is expected to be adopted as the NATO standard
in the near future.
D10.7 Electronic Data Interchange Agreement
An Electronic Data Interchange Agreement records the understanding between two or more
parties in a joint project or acquisition program as to the type and level of services to be provided
for the transfer of data.

D-62

Standard
[E]

AECMA 2000M

Revision 3.0

Profile
[E]

UK DEF STAN
0060 Part 20

Interim Issue
1

Guidelines
[R]

AC/313 - D/60

17 Nov 94

Guidelines
[E]

AC/313 - D/

1 Aug 95

Material Management
Integrated Data
Processing for Military
Equipment - Volume 4
Appendix 2 Annex G Example of an
Interchange Agreement
Application of Integrated
Logistic Support (ILS) Electronic Data
Interchange Agreement
for Data Exchange
specified in AECMA
SPEC 2000M
Guidelines and Sample
Provisions for
Memoranda of
Understanding
Guidelines and Sample
Clauses for Electronic
Data Interchange

AECMA 2000M Chapter 4 contains an outline Data Interchange Agreement.

AC/313 has published a draft NATO Data Interchange Agreement and this has been used as the
basis for Section 8 of this Handbook.
D10.8 Data Dictionary
The NATO CALS Office is compiling a standard data dictionary to support logistics information
processing. Whilst there is no definitive standard for a data dictionary, a number of supporting
standards exist:
Standard
[R]

Standard
[R]
Standard
[R]

ISO 639

1988

ISO/CD639 1
ISO 639 - 2

1998

ISO 8601

1988

ISO/WD 8601

2nd Ed.

ISO 8601 Cor. 1

1991

D-63

Code for the

Representation of names
of Languages
Part 1 Apha-2 Code
Part 2 Alpha-3 Code
Data Elements and
Interchange Formats
Information Interchange
Representation of
Dates and Times

Standard
[R]

ISO 4217

1995

Standard
[R]

ISO 3166 - 1

1997

Standard
[R]
Standard
[R]

ISO 3166 - 2

1998

ISO 3166 - 3

1999

Standard
[R]

ISO/IEC 11179 - 1

Standard
[R]
Standard
[R]

ISO/IEC 11179 2
ISO/IEC 11179 3

1994

ISO/IEC WD
11179 3
ISO/IEC 11179 4

2nd Ed.

Standard
[R]

ISO/IEC 11179 5

1995

Standard
[R]

ISO 11179 - 6

1997

Standard
[R]

1995

Codes for the

Representation of
Currencies and Funds
Codes for the
Representation of Names
of Countries and Their
Subdivisions
Part 1 Country Codes
Part 2 Country
Subdivision Code
Part 3 Code for
Formerly Used Names of
Countries
Information Technology
- Specification and
Standardization of Data
Elements
Part 1 Framework for
the Specification and
Standardization of Data
Elements
Part 2 Classification
for Data Elements
Part 3 Basic Attributes
of Data Elements

Part 4 Rules and

Guidelines for the
Formulation of Data
Definitions
Part 5 Naming and
Identification Principles
for Data Elements
Information Technology
- Part 6 Registration of
Data Elements

Note: The International Standards Community, as a joint ISO, UN/ECE, and ISO/IEC activity,
is currently engaged in the development of a Basic Semantic Repository (BSR). The BSR is a
tool to aid in the rationalization and alignment of existing data dictionaries in line with
international standards and to enable future alignment of internal data and external
communication requirements as an aid to the development of a NATO Data Dictionary. The
representation of the Data Elements in the NATO Data Dictionary will be in accordance with
ISO 11179.
D-64

D10.9 Integrated Product Database

The use of a single coherent set of CALS standards, the acquisition of data in digital form, and
the exchange of data electronically does not, in itself, fully exploit the advantages of CALS. To
obtain added value, all project data should be stored on a single database organized in such a way
that all authorized used can have optimum access. Such a database, which may be physically
distributed between several locations, should permit data to be created once and used many
times. The creation of the Integrated Product Data Base should use the standards defined above
under Data Dictionary.
D10.10 Database Query Language
SQL is based on a relational database model. It is used to define data in relational databases
within a data dictionary component of SQL and to manipulate data.
Standard
[E]

Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]

ISO/IEC 9075

3rd Ed.
1992

ISO/IEC 9075 Cor. 1

1996

ISO/IEC 9075 Cor. 3

ISO/IEC 9075 - 1
ISO/IEC 9075 - 2
ISO/IEC 9075 3

1995

ISO/IEC 9075 3 Cor. 1

ISO/IEC 9075 4

1996

ISO/IEC 9075 4 Cor. 1

ISO/IEC 9075 5

ISO/IEC WD 9075 6
ISO/IEC AWI 9075 7
ISO/IEC CD 9075 7
ISO/IEC FCD 9075 10

D-65

Information Technology
- Database Language Structured Query
Language (SQL)

Part 1 Framework
(SQL/Framework)
Part 2 Foundation
(SQL/Foundation)
Part 3 Call-Level
Interface (SQL/CLI)
Part 4 Persistent Stored
Modules (SQL/PSM)
Part 5 Host Language
Bindings
(SQL/Bindings)
Part 6 SQL/XA
Specialization
Part 7 - Temporal
Part 9 Management of
External Data
Part 10 Object
Language Bindings
(SQL/OLB)

Standard
[E]

ISO/IEC 10032

1995

Standard
[E]

ISO/IEC 9579

1999

ISO/IEC FCD 9579

3rd Ed.

ISO/IEC FDIS 9579

2nd Ed.

ISO/IEC 9579 CD Amd.

2

Information Technology
- Reference Model of
Data Management
Information Technology
Remote Database
Access for SQL
Remote Database Access
for SQL with Security
Enhancement

Distribution Schema for

RDA

Note: As far as we are aware, NATO has not yet adopted any International Standard for use
within NATO as a Standard Query Language.
D10.11 Contractor Integrated Technical Information Service
Contractor Integrated Technical Information Service (CITIS) is intended to be an efficient,
contractually implementable means for providing Purchasers with on-line access to, and
exchange of, Contractor-generated and maintained data specified in a Contract Data
Requirements List (CDRL).
Standard
[T]

MIL-STD-974

20 Aug 93

Contractor Integrated
Technical Information
Service (CITIS)

The initial U.S. concept described in MIL-STD-974 specified requirements within a U.S. legal
framework; such a framework does not necessarily exist outside the US. Intellectual Property
Rights and other legal issues may inhibit the implementation of a CITIS approach within NATO
unless clear contractual agreements can be reached within each project, and therefore it has not
yet been possible to determine the NATO Policy towards CITIS or to define a standards for its
implementation.
Section 5 of this Handbook addresses the use of CITIS.
D10.12 Automated Interchange of Information
MIL-STD-1840 defines the procedures for handling several forms of document transmittal and
for the transmittal of product data that does not consist of documents. However, it prescribes
that the primary and only required form is that of SGML encoded text with graphics in separate
(linked) files.

D-66

Standard
[T]

MIL-STD-1840

Revision B
3 Nov 93
Revision C
26 June 1997

Note: The Policy and applicable standards for

NATO, and the status of the above Standards has
NATO CALS context. Although there are legacy
Standard in use within NATO, it should be noted
CALS requirements.

Automated Interchange
of Technical Information

Automated Interchange of Information for

not yet been confirmed or validated in the
systems based on this U.S. DoD Military
that this Standard may not reflect NATO

D10.13 Technical Data Packages

Technical Data Packages (TDPs) contain the information necessary to describe a defense system
and its components in terms of design, engineering, manufacturing, and logistics support. The
application of CALS principles to the creation, management, and use of TDPs is addressed in
Section 3 of this Handbook.
Standard
[T]

MIL-T-31000

Revision A
1 Dec 92

General Specification for

Technical Data Packages

WAS NOT
FOUND!!!
Note: The Policy and applicable standards for Technical Data Packages for NATO, and the
status of the above Standard has not yet been confirmed or validated in the NATO CALS
context; it should be noted that the above U.S. DoD Military Standard may not yet reflect CALS
requirements.
D10.14 Database Manager
To facilitate such database development, a database manager with a clear understanding of
CALS principles, should be appointed for each project.
D10.15 Communications Infrastructure
Whilst CALS Standards should ideally be specified independently of hardware, software, and
communications infrastructure, nevertheless a number of CALS applications are dependent on
communications/infrastructure standards.
However, such standards are necessarily not
CALS-specific and do not fall within the area of responsibility of the NATO CALS Management
Board.

D-67

D10.16 Status of Document

D10.17 Disclaimer
This document is issued by the NATO CALS Office as a WORKING DRAFT ONLY and it has
not been fully endorsed by the NATO CALS Management Board at its date of issue.
Nevertheless, the information contained in the draft is believed to reflect NATO CALS Policy
and the CALS-related standards applicable at the date of issue.
D10.18 Feedback
Comments or Observations on layout, content, or future distribution would be welcomed by the
NATO CALS Office. Further details may be obtained from the Director, CALS Policy (Mr.
Charles W. Schaffer, Tel: Brussels (+32) 2 707 4750) or the Director, CALS Implementation
(Wing Commander Brian W Price, Tel: Brussels (+32) 2 707 4653)

D-68

APPENDIX E: INDEX OF STANDARDS

INDEX OF STANDARDS
The main standards referenced in this section are as follows:
AcodP-1
AdatP-3
AECMA 2000M
AECMA SPEC 1000D
ANSI/ASME Y14.26M
ANSI/IEEE 1076
AQAP 1
AQAP 13
IEEE 1220:1994
ISO 1000
ISO 10164
ISO 10646-1
ISO 11172
ISO 11179
ISO 12083
ISO 13584
ISO 14041
ISO 14042
ISO 3166
ISO 31
ISO 4217
ISO 639
ISO 646
ISO 6709
ISO 6936
ISO 7372
ISO 8601
ISO 8613
ISO 8824/8825
ISO 8859

NATO Manual on Codification Guide to NATO Codification

Systems
Allied Data Publication 3 - NATO Message Text Formatting
System
Material Management Integrated Data Processing for Military
Equipment
International Specification for technical Publications using a
Common Source Database
Initial Graphics Exchange Specification (IGES). May be subsumed
by STEP
Very High Speed Integrated Circuit (VHSIC) Hardware description
Language (VHDL)
NATO Requirements for an Industrial Quality Control Program
NATO Software Quality Control System Requirements
Application and Management of the Systems Engineering Process
SI Units
Configuration Management
Information Processing - Universal Character Sets
MPEG2 Motion Picture Experts Group (MPEG) Coding of Motion
Pictures and associated Audio for Digital Storage Media
Information Technology - Basic Data Element Attributes
Electronic Manuscript Preparation and Markup
Industrial Automation - Parts Library Environmental Life-cycle
Assessment
Life-cycle Inventory Analysis
Life-cycle Impact Assessment
Information Processing - Country Name Representations
Information Processing Representation of Quantities and Units
Information Processing - Currencies and Funds
Information Processing Coded Representation of Names of
Languages
Information Technology - ISO 7-Bit Coded Character Set for
Information Interchange
Information Processing - Representation of Latitude and Longitude
Information Processing - Character Set Conversion
EDIFACT Data Element Directory
Information Processing - Date/Time Representations
Information Processing Systems. Office Documentation
Architecture
Standard Page Description Language (SPDL)
Information Processing - 8-bit single byte coded graphic character
sets

E-1

ISO 8879
ISO 9000
ISO 9001
ISO 9004-2
ISO 9004-7
ISO 9075
ISO 9660
ISO 9735
ISO DIS 10918
ISO/IEC 9069
ISO/IEC 10149
ISO/IEC 10303
ISO/IEC 10918
ISO/IEC 12087
ISO/IEC 13673
ISO/IEC 8632
ISO/IEC 9592
ISO/IEC 9636
ISO/IEC 9796
ISO/IEC DIS 10179
ISO/IEC IS 10744
ISO/IEC TR 9573
ISO/IECS 13522
ISP 12064-1
ITU-TSB T6
MIL-D-28000
MIL-D-28002

Information Processing - Text and Office System - Standard

Generalized Markup Language (SGML)
Quality Management and Quality Assurance Standards - Guidelines
for Selection and Use.
Quality Systems - Model for Quality Assurance in Design,
Development, Production, Installation, and Servicing
Quality Management and Quality Systems elements - Guidelines
for services.
Guidelines for Configuration Management
Database Language - Structured Query Language (SQL)
Information Processing - Volume and File Structure of CD-ROM
for Information Exchange
Electronic Data Interchange for Finance, Administration,
Commerce and Transport (EDIFACT) Syntax Rules
Joint Photographic Experts Group (JPEG) Still Picture Grayscale
and Color Image Data Compression Algorithms.
Information Technology - SGML Support Facilities - SGML
Document Interchange Format (SDIF)
Information Technology - Data Interchange on Read-only 120mm
Optical Data Discs (CD-ROM)
Standard for the Exchange of Product Model Data (STEP)
Coding of Digital Continuous Tone Still Picture Images (JPEG)
Information Processing Systems - Image Processing and Interface
(IPI)
Conformance Testing for SGML Systems
Information Processing Systems - Computer Graphics - Metafile
Information Processing Systems - Programmers Hierarchical
Interactive Graphics System (PHIGS))
Information Processing Systems - Computer Graphics Interface
(CGI)
Information Technology - Security Techniques - Digital Signature
Scheme giving Message Recovery
Document Style Semantics and Specification Language (DSSSL)
Information Technology - Hypermedia/Time Based Document
Structuring Language (HyTime)
Information Technology - SGML Support Facilities - Techniques
for using SGML
Information Technology - Coding of Multimedia and Hypermedia
Information (MHEG)
Image Application - Simple Document Structure - Raster graphics
Content Architecture
Facsimile Coding and Control Functions for Group IV Facsimile
Apparatus
Digital Representation for Communication of Product Data
Requirements for Raster Graphics Representation in Binary Format

E-2

MIL-D-28003
MIL-D-87269
MIL-HDBK-470
MIL-HDBK 59B
MIL-HDBK-SGML
MIL-M-28001
MIL-M-87268
MIL-Q-87270
MIL-STD-1379D
MIL-STD-1388-1A
MIL-STD-1388-2B
MIL-STD-1390
MIL-STD-1629
MIL-STD-1840
MIL-STD-482A
MIL-STD-785
MIL-STD-973
MIL-STD-974
MIL-T-31000
STANAG 3150
STANAG 4107
STANAG 4159
STANAG 4177
STANAG 4329
STANAG 5500
UK DEF STAN 0060

Digital Representation for Communication of Illustration Data:

CGM Application Profile
Interactive Electronic Technical Manual (IETM) Database
Maintainability Program for Systems and Equipment
Computer Aided Acquisition and Logistics Support (CALS)
Program Implementation Guide
U.S. Department of Defense Application of - SGML. Federal
Information Processing Standard (FIPS 152)
Markup Requirements and Generic Style Specifications for
Electronic Printed Output and Exchange of Text - SGML
Interactive Electronic Technical Manual (IETM) Content
Interactive Electronic Technical Manual (IETM) -Quality
Assurance
Military Training Program
DoD Logistic Support Analysis
7
DoD Requirements for a Logistic Support Analysis Record (LSAR)
Level of Repair Analysis
Procedures for Performing a Failure mode Effects and Criticality
Analysis
Automated Interchange of Technical Information
Configuration Status Accounting
Reliability Program for Systems and Equipment Development
Configuration Management [TO BE CANCELLED]
Contractor Integrated Technical Information Service (CITIS)
General Specification for Technical Data Packages
Codification of Equipment - Uniform System of Supply
Classification
Mutual Acceptance of Government Quality Assurance
NATO Materiel Configuration Management Policy and Procedures
for multi-national Joint Projects
Codification of Items of Supply - Uniform System of Data
Acquisition
NATO Standard Bar Coding Symbology
NATO MESSAGE TEXT FORMATTING SYSTEM
Application of Integrated Logistic Support (ILS)

E-3

APPENDIX F: CALS TERMINOLOGY/ACRONYMS

CALS TERMINOLOGY/ACRONYMS
Abstract

A term for a user provided narrative entry which describes, defines,

or synopsizes an asset.

AECMA

Association Europeenne des Constructeurs de Materiel Aerospatial

ASCII

American Standard Code for Information Interchange

ASRL

Army SGML Registry and Library

Attribute (of an element)

A qualifier indicating a property of an element, other than its type

(which is done by a generic identifier) or its content (which is
delimited by start-tags and end-tags). Attributes are only found on
start-tags, and can indicate reference identifiers, confidentiality,
formatting information, and so on.

Attribute Definition

A member of an attribute definition list within an attribute list

declaration. It declares an attribute name, specifies the form and
SGML-specific aspects of possible values, and specifies the action
(such as providing a default value) to be taken if an attribute's value
is not specified. In the display under ATTRIBUTE (DEFINITION)
LIST DECLARATION, each attribute definition is shown as:
name_of_attribute allowable_values default

Attribute (Specification)
List

Markup that is a set of one or more attribute specifications, shown

as:
attribute="value attribute="value attribute="value"
The markup is used within a Start Tag, as in:
<element_name attribute="value attribute="value
attribute="value">

Attribute (Definition)
List Declaration

A markup declaration that associates an attribute definition list with

one or more element types, shown as:
<ATTLIST name_of_associated_element(s) name_of_attribute
allowable_values default>

Business Plan

Description of the result oriented tasks to be progressed by the

NCMB (two-year scope with annual update)

F-1

CALS

Continuous Acquisition and Life-Cycle Support (previously known

as Computer-aided Acquisition and Logistic Support)

CEN

European Committee for Standardization

CENELEC

European Committee for Electrotechnical Standardization

CENELEC/ETSI

European Telecommunications Standards Institute

CFS

Center for Standards

CITIS

Contractor Integrated Technical Information Service

Constructs

Document type definitions (DTDs), formatting output specification

instances (FOSIs), and SGML tag narrative definitions.

COTS

Commercial Off-The-Shelf

CNAD

Conference of National Armaments Directors

CSL

CALS SGML Library

CSR

CALS SGML Registry

DCA

Document Class Authority

DDRS

Defense Data Repository System

Declaration

The SGML declaration defines which characters are used in a

document instance, which syntax the DTD is written in, which
SGML features are used, and so on. It is supposed to accompany
each SGML document, although a default to the one described in
the standard may be assumed.

DISA

Defense Information Systems Agency

Document Instance

The instance is the actual document text and its accompanying

SGML tags conforming to the specifications and restrictions set
forth in the DTD.

F-2

Document Type
Declaration

A markup declaration that contains the formal specifications of a

document type definition, shown as:
<DOCTYPE document_type_name optional_external_identifier
[optional_document_type_declaration_subset ]>
The declaration invokes a DTD in an SGML document. The
document instance of an SGML document must always be
preceded by a document type declaration.

Document Type
Definition (DTD)

A DTD, or Document Type Definition, is an SGML construct used

to rigorously and unambiguously describe the structure and content
of classes of documents in terms of SGML instances (elements,
attributes, entities, etc.). NOTE: 'DTD' is occasionally-but not in
compliance with ISO 8879 terminology- used as an abbreviation
for 'document type declaration'; it is also an SGML reserved word
used in formal public identifiers to indicate that the identified entity
is a document type declaration set, and is often used to identify
such a set.

DoD

Department of Defense (USA)

DoDISS

Department of Defense Index of Specifications and Standards

DSSSL

Document Style Semantics and Specification Language

DTD

Document Type Definition

EDI

Electronic Data Interchange

EDIFACT

EDI For Administration Commerce and Transport (ISO 9735)

e-i-c

Element in Context

Element

A component of the hierarchical structure defined by a document

type declaration or DTD. It is identified in a document instance by
descriptive markup, usually a start-tag and end-tag, shown as:
<element_type_name attribute=value attribute=value>content of
the element</element_type_name>

F-3

Element Type
Declaration

A markup declaration that contains the formal specification of the

part of the definition of an element type that deals with the content
and markup minimization, shown as:
<!ELEMENT element_type_name start_tag_minimization
end_tag_minimization content_model_group_or_declared_content
content_exceptions>

Entity

A unit of information that may be referred to by a symbol in a DTD

or in a document instance. Entities may be used for character
strings, characters that cannot be keyed in on a keyboard, or for
separate files that may be or may not contain SGML data.

Entity Reference

A reference that is replaced by an entity, shown as: & entity_name;

or %entity_name; the ampersand is used for general entities
(referenced in the document element); the percent sign is used for
parameter entities (typically referenced in the document type
declaration).

ETM

Electronic Technical Manual

FOSI

Formatting Output Specification Instance is an instance of the

Output Specification (OS) that assigns values to the style
characteristics for a particular document type declaration. The
FOSI uses the syntax of an SGML document instance and is
designed to format documents for paper delivery.

FPSI

Formatting Presentation Specification Instance is an instance of the

Presentation Specification (PS) that assigns values to the style
characteristics for a particular document type declaration. The
FPSI uses the syntax of an SGML document instance and is
designed to format documents for electronic or paper presentation.

FPI

Formal Public Identifier

FPSI

Formatting Presentation Specification Instance

IATA

International Air Transport Association

ICOM

Input, Control, Output, Mechanism

IEC

International Electrotechnical Committee

IETM

Interactive Electronic Technical Manual

F-4

IGES

Initial Graphics Exchange Specification

IIG

NIAG Industrial Interface group

Information
Infrastructure

Combined architecture of data, applications, information, and

communications technology

IMP

Information Management Plan

IPSC

Information Processing Standards for Computers

ISO

International Organization for Standardization

ISO 8879 Information

Processing

Text and Office Systems - Standard Generalized Markup Language

(SGML) completely specifies the SGML Meta-language with
regard to the grammar and syntax required for the SGML language
along with the features that may be optionally enabled for a given
SGML application. In addition, ISO 8879 also specifies various
procedures for processing SGML notation.

LSA

Lead Standardization Activity

Markup

The process of adding formatting or other processing commands to

a text.

NCMB

NATO CALS Management Board

NCS

NATO Committee for Standardization

NIAG

NATO Industrial Advisory Group

NICG

NATO Industrial CALS Group

NSLB

NATO Standardization Liaison Board

Objects

SGML elements, entities, attributes of elements, public identifiers,

notations, and standard tagging schemes.

OS

Output Specification

F-5

Output Specification
(OS)

An OS, or Output Specification, provides a rigorously defined set

of options for the style characteristics which provide the formatting
intent for interchanged SGML-tagged technical publications. The
OS has a mechanism for binding the style characteristics to SGML
elements and attributes in a document's DTD. The OS is in the
form of an SGML DTD. At present, the OS is intended for hard
copy composition but can be applied to digital display in limited
applications (e.g., non-interactive).

PA

Preparing Activity

Page Fidelity

The ability to preserve the exact presentation characteristics in

addition to the same information on pages exchanged between
systems or revisions.

Page Integrity

The ability to preserve the exact same information on each page in

a manual as it is exchanged between systems or revisions. This
does not mean that the information will be presented exactly the
same way, but only that it appear between the same page
boundaries.

Parsing

An SGML parser is a computer application that breaks down an

SGML-coded document into a series of logical elements and
checks that these elements conform to the model defined in the
associated document type declaration. When parsing a document,
the SGML parser:

Checks each new character to see if it is part of a general

delimiter string that identifies the start of a piece of markup.
Checks whether or not the character is a short reference
delimiter that needs to be expanded.
Checks if the character is a separator character that should
be ignored.
Identifies the various markup tags, identifying any entities
that need to be expanded or recalled from external sources.
Checks if identified markup tags are valid according to the
declared model.

PDL

Page Description Language

PfP

Partnership for Peace

Preparing Activity

The DoD activity or the Civilian Agency responsible for the

preparation, coordination, issuance, and maintenance of
standardization documents.

F-6

Presentation
specification (PS)

A finite set of style characteristics to convey formatting intent for

interchange of data to an electronic display medium coupled with a
mechanism for binding the style characteristics to logical elements
in an SGML document type declaration. The PS uses the syntax of
an SGML document type declaration.

PS

Presentation Specification

PSI

Presentation Specification Instance

SACEUR

Supreme Allied Command Europe

SACLANT

Supreme Allied Command Atlantic

SGML

Standard Generalized Markup Language, as detailed in ISO 8879

and FIPS Pub 152. SGML is a meta language that provides a
coherent and unambiguous syntax for describing the logical
structure of publications in unambiguous grammar. Formalizes the
markup process and frees it of system and processing dependencies.

SGML Declaration

An SGML Declaration is an SGML construct which specifies an

SGML implementation in terms of the values of the SGML
parameters, character set, concrete syntax, optional features, and
capacity requirements and the SGML features used.

SGML Entity

An entity whose characters are interpreted as markup or data IAW

ISO 8879.

SGML Instance

An SGML Instance or SGML-tagged document is the collection of

data composing a specific document that includes SGML tags
(SGML markup) corresponding to elements, their attributes, entity
references, etc. The SGML markup conforms to the document's
DTD.

SGML Parser

An SGML parser is a computer program or a specialized code

compiler called a parser. An SGML parser first processes (or
parses") an SGML Declaration defining the particular SGML
implementation and stores this SGML environment. Then the
SGML parser can be used to process (or parse") a DTD to
determine its conformance regarding grammar and syntax to ISO
8879 and the SGML Declaration for that SGML application. The
SGML parser can then be used to process an instance of a particular
document to determine the conformance of the instance to both
SGML grammar and syntax and the DTD.

F-7

SMA

Standardized Management Activity

STARS

Software Technology for Adaptable, Reliable Systems

STEP

STandard for the Exchange of Product model data

Tag or Tagging

Adding tags (descriptive markups) to document data.

Task

A sequence of user actions with a definite beginning and an end.

User tasks relate to installation checkout operation, and
maintenance of systems or equipment. Tasks may contain
procedures and in turn steps to complete the assigned task.

Technical Publication
Verification:

This term refers to the parsing of the digital data stream containing
a publication to assure compliance with the standard (SGML,
CCITT, CGM, IGES) to which it was written. There is no intent in
this term to imply the validation/verification process used to certify
the content of the publication.

TLIMP

Through Life Information Management Plan

TM

Technical Manual

URL

Uniform Resource Locator

Work Package

Presentation of information functionally divided into individual

task packages in the logical order of work sequence. The work
packages shall be stand-alone general information, operating,
maintenance, troubleshooting, parts, and supporting information
units containing all information required for directing task
performance. Work packages may be given to a soldier(s) so they
may have complete instructions for accomplishing a task.

WWW

World Wide Web

WYSIWYG

What You See Is What You Get

X.12

American National Standards Institute / Accredited Standards

Committee (ANSI/ASC) standard for EDI

F-8

APPENDIX G: INTERFACE SPECS AND THE TLBM

G1.0 INTERFACE SPECS AND THE TLBM

G1.1 The Problem
TLBM V4.2 reflected several viewpoints:
a. Program Manager, or Life-cycle Owner (LCO), of a Single DS
b. Armed Force
c. Mission or Task Force Commander
The three input models make different assumptions about the work that needs to be performed
and hence the information flows required (e.g., OLA included provide medical services,
Operations is rarely a single system activity).
G1.2 The Solution
Develop NC TLBM to reflect single viewpoint: that of the Life-cycle Owner of the single DS.
TLBM should therefore include all activities that need to be undertaken to deliver the single DS
in a ready to use condition. TLBM should not include Operational Use, or the integration
activities performed by an Armed Force or Operational Commander on a multi system basis.
(Note: This approach relates well to the Office of the Secretary of Defense (OSD) CALS
Common Operating Digital Environment diagrams Mission, Sustainment (AF) and Defense
System.)
In this context, a Defense System therefore includes the main equipment (e.g., F16) and all of the
special to type support system, equipment, and facilities under the direct control of the LCO.
In practice, many of the later activities (e.g., the of supply spares) are not performed on a single
system basis, but in an integrated manner.
In developing TLBM we will assume all of the life-cycle activities needed to deliver the single
DS ready for Operational Use are organized on a single system basis, under the control of the
LCO. To complete the TLBM on this basis, some of the OLA activities need to be removed
from the TLBM but and replaced by information flows (ICOMS) between the DS and the AF,
who are assumed to perform any multi-system tasks without the model
In using TLBM to explore information and information exchange requirements for a specific
program it will be necessary to mark up activity boxes within TLBM to identify those tasks to be
performed in a multi-system manner, and not just from the perspective of the single DS in
question. Activities shared between the AF and the DC LSO should be further decomposed until
the tasks of each party can be separated out. The requirement for information exchange between
the program SDE and the AF IT systems can then be analyzed across this boundary, in terms of
the information flows in both directions.

G-1

There may be benefit in tasking the OLA group to develop an IDEF model to show how an
Armed Force and or a Combined joint Task Force would integrate information from many DS
for the purpose of Sustainment (what is this?) or Mission Support.
G1.3 Candidate Interface Specifications
The following interactions are identified between the single DS and an Armed Force(s) and/ or
International Armament Co-operation organization, not under PM control.
Notes:
1. Items in brackets refer to Arrows in TLBM V5.0 e.g., (Current Requirement).
2. The asterisk * identifies a potential I.S. Expected to fall within the scope of Track 2
Standardization effort.
3. Comments are in italics.
G2.0 FROM DEFENSE SYSTEM TO THE ARMED FORCE
G2.1 Requirement
For changes to facilities (Request)
For additional Training e.g., new common skill requirements (Request)
Change request for other DS (Request)
G2.2 Design
Proposed change to AF design constraints or standards (Request)
Common parts used in this system * (not yet covered by TLBM. Needs a two way flow)
Identify Alternate Parts is this in use elsewhere with different id.* (Being explored with
AC135. The set of info needed to perform form, fit, and function comparison)
G2.3 Interface Details for Other Systems (DS Data)
G2.4 Support Design
Proposed changes to AF maintenance policy- harmonization of approach.
Data).
Potential new common tools and equipment* (DS data).

(Request, plus DS

Note: Provisioning of some parts may not be managed through life by the DS Life-cycle Owner
(LCO). If parts management is an AF activity, the following interactions will occur with AF
stock management agency.
Provisioning recommendations including re-procurement details.* (DS data)
Packaging Handling Storage and Transportation requirements * (DS data)

G-2

G2.5 Support
If maintenance is provided primarily on a single DS basis, support activities are assumed to lie
within the TLBM, under LCO control, and using the DS program SDE. If maintenance activities
have to be integrated across several DS, beyond LCO control, either for reasons of work
planning (e.g., a Brigade workshop, NAMSA) or access and availability reasons (e.g., ships,
aircraft) then the following interactions occur:
DS Support and Maintenance Instructions/ Plans*
Ad hoc work requirements *.
System changes required/permitted.* (Selected Configuration)
Details of resources to be provided by PM (Not covered)
System Ready for use (DS ready for use)
Operate
Operating instructions* (DS data where from?)
Operational support requirements interfaces, services needed* (DS Data from Obtain)
G3.0 FROM AF TO DS
Legal, Policy, Resources, Trained manpower, Program approvals, annual cash limits etc
(Constraints and Resources including: Business Directives, O&S Policy, users etc.)
G3.1 Requirements
Responsibility for establishing, validating, and sustaining the Mission Need for a DS lies with
the Operational Staff, not the LCO. The LCO/PM is responsible for delivering a system that
meets the need.
DS Operational Requirement (including inter-operability requirements)** (VMN)
Use Study* (Derived from VMN, Business Directives and U&S Policy reflected in Current
Requirement)
AF Maintenance and Support policy (O&S Policy)
Standardization policy (e.g., common parts to be used) (Business Directives and/or U&S policy)
Policy or constraints from International support MoUs (Business Directives)
G3.2 Design
Required Interfaces with other DS or facilities. (Business Directives for policy, with technical
details from External data)
Design Standards (Defense Pol and Stds)
Imposed Design solutions (e.g., new tank must use this engine) (Business Directives)
G3.3 Support Design
Common skills which can be expected* (External Data).

G-3

G3.4 Provides List of Common Tools and Equipment* (External Data)

Current Infrastructure facilities, depots, location, function, etc. (External data plus Existing
Infrastructure).
Current Stock Levels, Locations, usage pattern and future demand.* (External data this area
needs more work)
Instruction to make use of AF information systems (incl. paper based) (Business directives)
G3.5 Support
Requirement and priorities for operational equipment (what, where, when) *?? (Operating
Program)
(See note on maintenance above)
Feedback of results from in service evaluations not under PM control:
Deficiency/Failures reports* (Maint Feedback)
Condition/State reports * (Maint Feedback)
Changes made* (Maint Feedback)
Work done, parts used, costs etc.* (Maint Feedback)
G3.6 Operate
Operational History (hours run etc.) * (Feedback from Operations)

G-4

APPENDIX H: LIST OF POSSIBLE CALS IMPROVEMENT TARGETS

LIST OF POSSIBLE CALS IMPROVEMENT TARGETS

Real life examples still need to be selected from available resources and added in the following
tables. Improvement targets starting at Automate Change Management need to be detailed.
Table H-1 Requirement Management
Improvement
Target
Description

Application/
Benefits

Requirement Management
(Pre and Post Contract Award)
Software tool used to manage the requirement document in a structured form
through life. Enables better control of the requirements and easier management
and traceability of changes.
Time
Preproduction
Production
Use

Quality
We know what we
are meant to do and
who asked for it.

Better baseline
for in service
CM.
Maintaining a
valid and
current
structured
requirement
statement
during the
in-service
phase, it
provides a
better baseline
for decisions
on support
planning and
upgrades.

Cost
Do the right
thing.
Provides good
baseline for
justification
of changes.

Example

Table H-2 Shared E-Mail and Office Software

Improve ment
Target
Description
Application/
Benefits

Shared E mail and Office Software

(between program participants)

Preproduction
Production
Use

Time
Faster
communications
lead to faster
decisions.

Example

H-1

Quality

Cost
Quicker is
cheaper.
Some
potential for
travel savings.

Table H-3 Electronic Program Document Library

Improvement
Target
Description
Application/
Benefits

Electronic Program Document Library

Central managed source of significant documents (e.g., requirement, contract,
Specs, policy, etc.) (Scope office docs, drawings, models, video, etc.)
Time
Quality
Cost
PreTime reduction in
Much improved
Reliable data gives
production
retrieval and
change control and
better decisions.
distribution.
CM.
(Technology is
Production
cheap but set up
Use
and operating costs
are non trivial)

Example

Table H-4 Improve Program Management

Improvement
Target
Description
Application/
Benefits

Improve Program Management

Use of Common Program Management tool set for project planning and control
(Tasks, Resources WBS, CSCS, Plans)
Time
Quality
Cost
PreSome improvement. Better resource

People know
production
management.
what to do
Production
when.

Better visibility
of project
status.
Use

Example

Table H-5 Program Workflow System

Improvement
Target
Description
Application/
Benefits

Example

Program Workflow System

Allows standardization, simplification, and automation of work in processes.
Time
Quality
Cost
PreMajor savings
Enforces adherence
Can deliver
production
possible
to defined process
substantial savings
Production
on repetitive
processes.
Use
Acts as a major stimulus and support for Business Process Improvement. Big
cultural issues.
JCALS
Those who use the environment have found it easy to make changes to electronic
workflow to achieve process improvements. The workflow manager allowed
them to see the opportunities for improvement and make changes to the
automated workflow rather than having to notify others to carry out new routing
procedures.
(Source: DoD IDEHDBK)

H-2

Table H-6 Implement a Virtual Design Environment

Improvement
Target
Description
Application/
Benefits

Example

Implement a Virtual Design Environment

A Shared Data Environment for design, facilitating working concurrently on the
same design (data)
Time
Quality
Cost
PreSaves on traveling

Saves traveling
production
expenses.
time.

Concurrent
working speeds
up design time.
Production
Use
Computer modeling was used almost exclusively to design and build the first test
aircraft (no mock-ups), resulting in:

Product to market time substantially reduced

Quality improvement remarkable with alignment of first aircraft in

hundredths of inches

Added aircraft performance (e.g., lower fuel consumption) due to team

input, higher quality and resultant superior products
(Source: IDEBAT, slide 24)

Table H-7 Implement a Virtual Design and Test Environment

Improvement
Target
Description

Application/
Benefits

Implement a Virtual Design and Test Environment

A Shared Data Environment for design and testing of the design, facilitating
working concurrently on the same design (data) and test the design without
building prototypes, e.g., virtual mock-up.
Time
Quality
Cost
Pre
Saves traveling

Allows for

Saves on
production
time.
testing a great
traveling
deal of designexpenses.

Concurrent
variants.
working speeds

Saves because
up design time,
not having to
Allows for
not having to
testing under
build
build physical
many
prototypes.
prototypes for
simulated
testing.
(hazardous)
environments

Concurrent
and conditions.
testing and
redesign
possible
Production
Use

Example

H-3

Table H-8 Improve Configuration Management (CM)

Improvement
Target
Description
Application/
Benefits

Improve Configuration Management (CM)

Single logical CM system for project, used as index
information.
Time
Quality
PreSome benefits due

Control of
production
to better access to
requirement
information.
and
requirement
changes.

Control of
emergent
design.
Production

Less time needed to

find information.

Use

Savings in
maintenance time
through better
information.

Example

H-4

Consistent CM info
through the supply
chain.
We know what we
have to support.

for most product

Cost
Some benefits due
to better access to
information.

Minimize
rework.
Minimize
unnecessary
purchases

APPENDIX I: INFRASTRUCTURE REQUIREMENTS FOR THE CREATION,

MANAGEMENT, AND USE OF DIGITAL DATA

I1.0 INFRASTRUCTURE REQUIREMENTS FOR THE CREATION, MANAGEMENT,

AND USE OF DIGITAL DATA
The hardware guidelines provided in this section reflect the current state of art of computer technology.
Project managers, however, should understand that the computer technology is constantly changing, and
that the items addressed below are provided as a guideline but do not imply that only the following
technology should be used in building infrastructure.

I1.1 Introduction
The NATO CALS Handbook provides decision templates for selecting the most effective digital
data formats and media formats. Digital data includes the Technical Data Package (TDP),
Technical Manuals (TM), and the Logistic Support Analysis Record (LSAR).
Effective
acquisition and use of digital data can only be accomplished with full consideration of the ability
of NATO/NATO nations to receive, store, distribute, and use the digital data.
The infrastructure requirement is a key consideration in implementing the CALS strategy on any defense
system acquisition. Do not buy digital data if there is not an adequate digital data infrastructure
capability.

The project manager should ensure that all recipients of digital data will have the capability to
receive, store, and maintain the provided data. The materials and equipment required for
receiving, storing, and maintaining data constitutes the infrastructure requirements of CALS.
This infrastructure requirement is a key consideration in implementing the CALS strategy on any
defense system acquisition.
Deficiencies in the NATO/NATO nations' infrastructure may
require investments by the project manager to implement the CALS strategy effectively.
I1.1.1 Purpose
This section is intended to provide NATO/NATO nations project managers with an overview of
hardware and telecommunications requirements for the creation, management, and use of digital
technical data. Paragraph 7.2 discusses the general considerations and requirements of a
computer system infrastructure. Paragraph 7.3 describes the specific requirements that are
dependent on the data type, data format, and user function.
I1.1.2 Infrastructure Resource Planning
The project manager should plan to fund an infrastructure modernization program. The project
manager should plan infrastructure requirements such that funding can be set aside to be used
when the infrastructure investment is required. This approach will utilize program funding and
resources better.

I-1

I1.2 General Considerations

If data users do not have access to the appropriate hardware, software, and telecommunications
equipment, working in a digital data environment can become an obstacle course.

The computer hardware must have the appropriate processing speed and display capability to run
the application software adequately. The application software must perform specific tasks on the
digital data that are required by the user. Rather than recreate the data, the appropriate computer
networking system should allow the users to share data and resources, and telecommunications
equipment should allow users to transfer digital data easily. After reading the NATO CALS
Handbook, the project manager should have an implementation approach for data type, process,
format, and delivery/access method. With this information, infrastructure requirements can be
identified. Each decision will affect the life-cycle costs of a program and the cost of the
program's computer infrastructure. Human- interpretable data formats, such as Page Description
Language (PDL) and raster, may not be suitable as source data for other applications.
Processable data formats can be integrated with other digital data to reduce the total life-cycle
costs. The following topics are addressed as considerations for a computer infrastructure:

Computer Architecture
Computer Operating System
Storage Devices
Output Devices
Computer Graphics and Monitors
Network Devices
Application Software
Software Licensing
Network Protocols
Local Area Networks (LANs)
Wide Area Networks (WAN)
Data Process

The above topics are the basis of discussion in Paragraph 7.3, Infrastructure Requirements, for
specific hardware, software, and telecommunication requirements of a program. Also included
are several decision diagrams to help the project manager.
I1.2.1 Hardware Considerations
Computer hardware consists of the computer processor, memory, monitor, storage devices, and
input devices. Each computer should be tailored to fit the need of the main application.
Computational intensive applications such as mechanical solid modeling or engineering
simulation will require a larger amount of memory than general text and 2-D graphics-based
applications. Each application requires a distinct amount of hard disk space for data storage.
Raster images and simulation models tend to require more disk space than vector-based
databases such as Computer Graphics Metafile (CGM) or Computer Aided Design (CAD) files.

I-2

I1.2.1.1 Computer Architecture

Computer technology is constantly changing, and the project manager should understand that the items
addressed below are provided as a guideline but do not imply that only the following technology should
be used in building infrastructure.

Each computer is designed to meet a specific requirement. In many cases, the computer
architecture is driven by the choice of application software needed to perform a specific task.
For this reason, the software selected may be the most important decision made. The Personal
Computers (PC) are the most widely used computers and are ideal for non-intensive applications
that require low-to-medium graphic displays. The RISC workstations are widely used in
engineering and technical publishing applications that require either a powerful processor for
extensive calculations or a high-resolution graphics display for document editing. A diskless
RISC workstation may provide a low-cost solution to some engineering computing needs. These
workstations typically have a small hard disk for the operating system while the application
software and user files are loaded from a server workstation that is connected by a network. A
third option is a graphic display workstation that supports the X-window Motif standard.
However, a PC with X-window emulation software may provide the same features at a lower
cost. The standard options for each type of computer are presented in Table I-1.

Processor
Memory
Media
Hard Drive
Floppy Drive
Tape Drive
CD Drive
WORM
Monitor

Table I-1 Standard Options for PC Types

WINDOWS
RISC
WORKSTATION
WORKSTATION
TYPE 1
TYPE 2
PENTIUM, 486 DX 2, 68040
RISC
32 Mb
32 Mb
1Gb
3.5
Optional
Yes
Optional
17"-19 Flat SVGA

2 Gb
3.5
Yes
Yes
Optional
19"-21 High Res

I1.2.1.2 Computer Operating System

The operating system is the shell that interprets the user's commands and translates them into
machine code to control the computer's resources. The computer's internal clock, memory,
Central Processing Unit (CPU), terminal, and other peripherals are controlled by the operating
system. The three major distinctions among operating systems are the internal throughput bit
size, the amount of available memory, and the ability for multitasking. Each of these factors
controls the effectiveness of a computer for a particular user. The Pentium PCs have a 32-bit
internal bus as do most RISC workstations. A few of the high-end RISC workstations have a
64-bit internal bus and will be compatible with a 64-bit operating system. Two operating
systems are available for Pentium-based PCs. Disk Operating System (DOS) was the first major
operating system for a PC and continues to be the standard. DOS is only an 8-bit or 16-bit
operating system and does not offer true multitasking. OS/2 was introduced a few years ago and
I-3

offered users multitasking and a 32-bit operating system. Windows 95 and Windows NT are
similar to System 7, discussed in following paragraph and offers many advantages compared to
DOS. The largest benefit is that Windows NT is available on PCs and RISC-based workstations.
This will allow the engineering users access to the same application software on a RISC
workstation that most business users have on a PC.
A popular operating system used for the 68000 series processor is System 7, which is a true
windowing system with 32-bit multitasking capabilities. This operating system has attained
popularity due to its ability to meet the demands of both beginner and expert computer users.
The operating system has strict hardware/software standards that reduce compatibility and
installation problems, although the cost of this system is generally higher than similar
Windowing systems. Most RISC workstations currently have a UNIX operating system based
on System V UNIX or Berkeley BSD 4.4 UNIX that is POSIX compliant. Each operating
system provided with RISC workstations is unique, but most will run application programs that
were compiled using System V or Berkeley BSD UNIX. The CAD2 program specifies a POSIX
operating system with a Motif standard graphical user interface. OSF/1.0, OPEN VMS, and
Windows NT are new operating systems that are designed to allow users a greater variety of
application software. Windows NT is designed to allow users of the RISC-based computer and
80486-processor-based-computer to run the same operating system and the same versions of
application software.
I1.2.1.3 System Backup
System backup is very important to the project manager. If managed properly, systems can be
designed such that even a catastrophic loss of data can be recovered in a relatively short period.
To do this, the project manager should address areas such as hard drive or CPU failure, lightning
strike, fire, or damaging storm in a disaster recovery plan. Backup of a system should include a
practical means to back up system data. This is a function that should be easy to accomplish and
convenient to the users. If a system does not have a convenient backup system, the user will be
unlikely to back up regularly and, thus, risk catastrophic loss of program data. An acceptable
means to archive system and program data is to use a tape backup system.
I1.2.1.4 Physical Media
Each computer system needs the appropriate amount of data storage capacity to allow users
access to all areas of project data. This disk space can reside on each computer or on a network
file server.
Storage technology is constantly changing, and the project manager should
understand that the physical media addressed below is provided as a guideline but does not
necessarily imply that only the following technology should be used in building infrastructure.
When evaluating whether to use new technology, the project manager should assure
compatibility with other equipment of the same technology or with older, less sophisticated
media.
I1.2.1.4.1 Magnetic Media
Magnetic disk drives are available for most computer systems. Magnetic disk drives can store
from 200 to 4,000 megabytes and should be American National Standard Institute (ANSI), SCSI,

I-4

or IDE compatible. SCSI provides compatibility and allows for expansion when greater disk
space is required. Magnetic disks can be used to transfer data when required. The most common
magnetic disk used to transfer data is the 3.5-inch diskette that can hold up to 1.44 MB of data.
Using magnetic disks to transfer data should only be considered when the total data does not
exceed 10 MB. When transferring over 10 MB of data, a 9-track computer tape or Quarter Inch
Cartridge (QIC) tape would be better suited (MIL-STD-1840). The standard 9-track tape can
store approximately 240 MB of data compared to 500 MB with the QIC. The exact
configuration of the tape format can greatly affect the capacity of the tape. Tape drives that
accept tape cartridges are easier to obtain and integrate into a desktop computer system.
However, the project manager should confirm that tape formats are compatible. An alternative
technology to 9-track tape or an optical drive is the Digital Audio Tape (DAT) drive. DAT
drives can store up to 5 Gigabytes (G-byte) of data. The tapes are small and are easily integrated
into the desktop environment. This avoids capacity problems that are sometimes encountered in
9-track and optical drives.
I1.2.1.4.2 Optical Media
Optical drives are readily available and come in many different types and sizes. The most
common optical drive is the 5.25-inch Compact Disk (CD) Read Only Memory (ROM) drive.
These drives are used for end user systems similar to the Advanced Technical Information
Support (ATIS) system. A Write Once/Read Many (WORM) optical disk system should be
considered for storing the final deliverable digital data for a large project. Optical disks can store
up to 200 G-bytes. This will provide the project with a non-erasable copy of the data that can
help in configuration control. However, not all WORM optical disk systems produce the same
format as CD, and compatibility with the end user should be verified.
I1.2.1.5 Output Devices
Each computer user will need access to a printer and/or a plotter. These devices can be set up on
a LAN rather than directly to a specific computer, so that network users can share the devices.
Printers are generally used to produce A or B (ANSI Y14.1-80) size documents. Plotters are
used to create up to J size documents. An A size PostScript compatible laser printer is the
standard printer recommended for general use. The printer should have a minimum resolution of
300 by 300 Dots Per Inch (DPI) and a minimum print speed of four to eight pages per minute.
An A/B size laser printer would be better suited to print engineering drawings. Most drawings
are legible when printed on B size paper. The two main types of plotters are electrostatic and
pen plotters. Electrostatic E size plotters are recommended for engineers involved in the
creation and review of engineering documents or when there is a requirement to plot up to E
size raster drawings. A pen plotter may suffice, but these plotters can take up to 30 minutes to
print a vector drawing versus only 1 to 2 minutes for an electrostatic plotter. Pen plotters cannot
be used to plot raster images.
I1.2.1.6 Computer Graphics and Monitors
The resolution and monitor size are important considerations when choosing the proper monitor.
Most users who work with graphical data such as engineering drawings or technical illustrations
will be more efficient with a high-resolution, 19-inch monitor. This is especially true when

I-5

working with raster files. A larger monitor may eliminate the need to zoom in on a section of the
drawing or illustration.
A 14- to 16-inch monitor is suited only for general Windows
applications and is not recommended for reviewing drawings or illustrations. An option for
some RISC-based workstations is real-time, 3-D graphic manipulations. This allows the user to
rotate and/or scale the view of the object in real time. Any engineer performing solid modeling
or finite element analysis will increase productivity on the workstation with this option. Screen
redraws for complex images can take up to several minutes with a standard graphics option but
can be performed instantaneously with the 3-D graphic processors.
I1.2.1.7 Network Devices
Network devices include equipment that is required to connect a single user station to an existing
network or to connect two or more networks together. Examples of this type of equipment
usually are network cards, bridges, and routers. The basic requirements for creating a single
LAN are a Network Interface Card (NIC) and the appropriate cable; for example, an Ethernet
board for each computer and the coaxial or twisted-pair cable to connect each computer.
Network bridges can be added to the LAN, to connect to other LANs or manage the LAN
electronic message traffic. Network terminal servers allow terminals, modems, and printers to be
connected into the LAN. Network routers enable remote LANs to be connected or the LAN to
connect to a WAN. All network devices should support the Ethernet V2.0 and Institute of
Electrical and Electronic Engineers (IEEE) 802.3 standards.
Due to LAN configuration
complexity and variety, the project manager should discuss infrastructure requirements with the
supporting activity Automated Data Processing (ADP) manager before purchasing any LAN
equipment.
I1.2.1.8 Input Devices
There are many different ways to provide input to a computer system. One of the most basic
input devices is a keyboard. There are many different arrangements; however, the industry
standard is the 101-key type. Additional devices include mice, track balls, digitizing tablets,
light pens, and scanners. With the exception of the scanner, all the previous devices generate
data with the user's guidance. The technology of scanners has greatly increased in the past few
years and can add speed in the generation of technical data.
Scanners can have many features including color, gray scale, line art, and a host of others. As a
general rule, the more features and higher detail of the image, the more disk space is required.
There are definite ranges where there is a point of diminishing return comparing quality of image
vs. size of image. Attention should be made to this aspect, because, not only will a large image
consume a large amount of disk space, but it will also slow the speed of the computer when the
graphic is to be displayed. There are many different types and sizes of scanners available to the
project manager.
The two basic types of scanners are page scanners and large-format scanners. Page scanners are
designed to be implemented with text or graphics up to 8.5 by 11 inches. When scanning images
for documents that are currently being created or updated, a single-page scanner should work
well. Features for a single-page scanner include quality of scan and moderate speed. Sheet-fed
scanners are generally used to archive large amounts of paper data. The features required are
I-6

speed of scan and moderate resolution. Large-format scanners are used to generate raster images
from paper drawings up to 60 inches wide with an unlimited length. The scanners are
monochrome/gray scale and are a single-sheet feed operation. In recent years, the speed and cost
have been significantly reduced while quality has been enhanced.
Large-format scanners can provide a means of converting old, deteriorating paper drawings into
an electronic form that can be edited and restored, if required. Many activities and sites are
currently using scanners. Although the cost has been reduced significantly, a large-format
scanner is a major investment and is usually purchased by the software support activity as a
shared resource.
I1.2.2 Software Considerations
The project manager must consider how a specific software application fits into the complete
data process. Configuration management software may be needed to control the access and
revision of digital data files as well as the specific application software. Software applications
and repository services already available should be considered before different software
applications are examined. Another important question is whether the software import and
export files are in a CALS format such as MIL-D-28000 Initial Graphics Exchange Specification
(IGES) and MIL-M-28001 Standard Generalized Markup Language (SGML). This will ensure
the data will be accessible by other users.
I1.2.2.1 Data Formats
Digital data deliverables available in the CALS environment are extensive. The NATO/NATO
nations project manager must evaluate the need to determine which format is appropriate at each
stage of a specific program. The final deliverables must be in a standard CALS format while
preliminary digital data may be in a format that is agreeable to the project manager and the
contractor. Commercial word processing software with the capability of text attribute, style
sheets, and imbedded graphics may be used to view and annotate preliminary TMs. A list of
various digital data formats is shown in Table I-2.
Table I-2 Standard Digital Data Formats
STANDARD DIGITAL DATA FORMATS
MIL-D-28000 IGES /CALS
MIL-M-28001 SGML /CALS
MIL-R-28002 Raster graphics /CALS
MIL-D-28003 CGM for illustration data /CALS
Formatted American Standards Code for Information Interchange (ASCII) text
Page Description Language POSTSCRIPT
VHSIC Hardware Description Language (VHDL)/BBS
Electronic Design Interchange Format (EDIF)/BBS
Institute for Interconnecting and Packaging (IPC)-D-350 /BBS
Native CAD format

I-7

The project manager must consider who is going to use the data in the armed forces and ensure
that the infrastructure matches each user's requirements and the function of the requirements.
The required infrastructure will vary depending on the data use and the data format. Formats,
such as Raster, will require a higher resolution monitor but less processing capability to view and
modify compared to a solid-model-based CAD system. Raster and IGES data formats generally
necessitate larger disk memory. Some data functions cannot be performed on all digital data
formats.
I1.2.2.2 Operating System Compatibility
The first consideration is which operating systems the program uses. A software application that
supports both Disk Operating System (DOS) for the PCS and UNIX for the RISC-based
workstations will allow greater flexibility than a program tied to a single operating system. This
is especially true when business and engineering personnel need to review the digital data. Most
business applications operate on a PC while most engineering applications operate on
RISC-based workstation. X-window emulation software may solve some problems. The current
generation of X-window emulation programs are quite robust and can be used to allow PC users
access to UNIX X-window software from a PC. The PC emulation packages for RISC-based
workstations are not as sophisticated as the X-window emulation programs.
I1.2.2.3 Application Packages
General types of packages of application packages are shown in Table I-3.

I-8

Table I-3 General Types of Application Packages

COMPUTER
CAPABILITIES
EXAMPLES
SOFTWARE
Word Processing
Creating Text-Based Doc.
Documents
Spread Sheet
Calculations
Financial Reports
Data Manipulations
Engineering Calculations
Chart and Graphs
Data Reports
Desktop Publishing
Advanced Text and Graphics
Advanced Documents and
Integrated Documents
Publications
Mathematics
Symbolic Calculations
Engineering Calculations
Advanced Calculations 2-D,
Technical Reports
3-D Plots
Terminal Emulation
Emulates Specific Terminals for
X-Window Emulation on a
PCS
PC
MCAD
3-D Solid Modeling Mechanical
Weapon System
Drawing
Models Ship Drawings
Schematic Capture
Electrical Schematic Logic
Wiring Diagrams
Checking
Avionics System Designs
Printed Wiring Board
PWB Layout
Computer Aided
(PWB) Layout
PWB Manufacturing Data
Manufacturing
Finite Element Analysis
Structural Simulation Vibration
Flight Safety Checks
Simulation Thermal Simulation
Cooling Systems
Evaluations
Dynamic Simulation
Mechanism Simulation
Bomb Rack Mechanism
Dynamic System Simulation
Evaluations
Vehicle Characteristic
Simulations
Electrical Simulation
VHDL Analog Simulation
Computer Aided
ASIC Simulation
Engineering
I1.2.2.4 Software Licensing
The type of software licensing available can affect the total cost to implement a software system.
The four types of software licensing that are prevalent today are single-user license,
single-computer license, network license, and a site license. Each licensing option has a proper
use and can greatly affect the total life-cycle costs associated with the software procurement. A
single-user license allows the software to be loaded on one computer, and one person has access
to the program at a time. Most PC software programs are licensed to a single user. A
single-computer license is licensed for a specific computer, and the vendor may charge to move
the license to a different computer. This type of license can allow either a single user or multiple
users access to the program. The multiple-user option is generally used when the software is
operating on a mainframe computer or network server. A network license will allow a specific
number of simultaneous users, who share a common network, access to the program.
Single-computer and network licenses are usually offered on software available on UNIX
workstations. These licenses can reduce the total cost of supplying the needed software for all of

I-9

the users of an acquisition program.

computer at a particular location.

A site license allows the software to be used on any

I1.2.3 Telecommunications
The standard equipment required for telecommunications is a modem. The modem is used to
link two or more computer systems via a phone line. Normal uses could include connection to
larger computer systems via a terminal emulation program, connection to a remote site to
send/receive files, or to access Contractor Integrated Technical Information Service (CITIS). A
more specialized modem that has become readily available is a modem capable of sending and
receiving Facsimile (FAX) data as well as the standard CCITT (Consultative Committee for
International Telegraphy and Telephony) information. The speed requirement of the modem is
directly related to the size of the data files that will be transferred and frequency that the modem
will be used. If data is only to be accessed and viewed remotely, using a terminal emulation
program, then a 9600-baud (character per second) modem is probably acceptable. However, if
there is a requirement to send/receive large data files, a faster modem with built-in data
compression is required. Before purchasing a modem, the project manager should assure
compatibility with the remote location.
I1.2.3.1 Network Protocols
Network protocols are essentially the software standards that enable users to communicate over
LANs or WANs. There are several types of network protocols that are acceptable in the CALS
community. Factors to consider when choosing the type of network protocol needed include
current facility LAN/WAN compatibility, interface requirements, data to be transferred, and
distance of network. The following are common protocols and their capabilities.

GOSIP: The Government nations Open Systems Interconnection Profile (GOSIP) is the
standard for networking protocols. Its function is to provide interoperability among
different equipment manufacturers.
TCP/IP: Transmission Control Protocol/Internet Protocol (TCP/IP) is the general protocol
(IEEE 802.3) for most engineering workstations and servers. It allows UNIX computers
to connect to each other for remote login with 'rlogin' and 'rsh' UNIX commands. It also
allows a PC with X-windowing software to establish an X-window session on a UNIX
server.

I1.2.3.2 LAN
A LAN is required when there are several users who need to share data, application software,
and equipment. The LAN network devices commonly used are printers, disk drives, modems,
and other Management Information System (MIS) equipment. As the name LAN suggests, this
type of network is contained within a small area (usually within the same building or floor).
LANs are based on the needs of the user. Some LANs may only need to be connected to share
resources such as modems or printers. Another LAN function could be used for configuration
management of large CALS databases. A common need for organizations is to transfer data
from one LAN to another or to connect to a large mainframe computer. These functions can be
achieved with what is commonly referred to as a bridge.
I-10

A LAN is required when there are several users who need to share data, application software,
and equipment. The LAN network devices commonly used are printers, disk drives, modems,
and other Management Information System (MIS) equipment. As the name LAN suggests, this
type of network is contained within a small area (usually within the same building or floor).
LANs are based on the needs of the user. Some LANs may only need to be connected to share
resources such as modems or printers. Another LAN function could be used for configuration
management of large CALS databases. A common need for organizations is to transfer data
from one LAN to another or to connect to a large mainframe computer. These functions can be
achieved with what is commonly referred to as a bridge.
I1.2.3.3 WAN
A WAN is required when there are several users who need to share data or equipment over a
large area (usually many miles). A WAN should only be considered if there is a need to transfer
large amounts of data for long periods. If occasional or limited use of access to remote data or
equipment is needed, then a modem will suffice.
I1.2.4 Data Processes
The project manager needs to determine what digital data functions are required and who is the
data user. The infrastructure may vary for each use of the data, if the hardware, software, and
network cost are to be minimized. Generally, certain data functions are performed with a
specific format. Conversion software may need to be procured to ensure that the format of the
data is also compatible with the end user's requirements. The user functions are divided in the
following areas.

View: Acceptance, verification, and review of acquired digital data sets.

Comment/Annotate: Annotate or highlight for future reference, or make annotations and
comments without the ability to change the original file. The annotations are associated
with a specific item or location within a document.
Update/ Maintain: Update and modification of digital data.
Process/Transform: Categorize, extract, cross-reference, and modify the format,
composition, and structure of the data into another usable form.
Archive: Storage of the accepted data into a repository, managed by a central index or
locator.

I1.3 Hardware Requirements for Processing Digital Data

I1.3.1 Hardware Requirements for Processing TMs
The hardware requirements for processing TMs are dependent on the specific requirements of
the user. However, if the project manager chooses to retain a separate archive master, the
suggested system hardware on Table 4-12 provides TM archive capability. The view only
function requires the basic equipment to reference TMs. The equipment can be as simple as a
machine that can display ASCII characters or as complex as reading CD ROM over a network.
The hardware in Table 4-12 displays the equipment required for accessing TMs from a CD
I-11

ROM. The comment/annotate function for processing TMs is used primarily during the review
process prior to and during validation. This is to allow technical personnel the capability to
include additional information, if required. To accomplish this task, there must be a link
between CD ROM data and additional information stored remotely. If there is no direct link
between the CD and the additional information, then there is no requirement to supply CD ROM
drives with a system required to comment/annotate TMs. The hardware requirements for
updating and maintaining TMs include the capability to work with tagged SGML documents.
The system requirements for using an SGML editor can be found in Table I-4. Specific
requirements, including CD ROM, scanners, and WORM drives, should be addressed on a
case-by-case basis depending on the type and amount of data being processed. The hardware
requirements for extracting, processing, and transforming TM data depend on the data being
generated. The TM can be generated in a commercial editor and translated into SGML later.
This can reduce the infrastructure requirements if there is a basic infrastructure already in place.
If the requirement is to transform an approved TM into an Interactive Electronic Technical
Manual (IETM), then the hardware should reflect standard equipment that will support an IETM.
Table I-4 Matrix of Infrastructure Requirements

PROCESS
TECHNICAL
MANUAL:
ARCHIVE
VIEW ONLY
COMMENT/ANNOTATE
UPDATE/MAINTAIN
EXTRACT/PROC./TRANSF.
PROCESS
TECHNICAL
DATA PACKAGE:
ARCHIVE
VIEW ONLY
COMMENT/ANNOTATE
UPDATE/MAINTAIN
EXTRACT/PROC./TRANSF.
PROCESS ILS/LSAR:
ARCHIVE
VIEW ONLY
COMMENT/ANNOTATE
UPDATE/MAINTAIN
EXTRACT/PROC./TRANSF.

P R
E I
N S
T C
I
U
M
/
4
8
6

S
C
A
N
N
E
R

X
X
X

C
D
/
R
O
M

W
O
R
M

T
A
P
E
D
R
I
V
E

W
O
R
D

S
G
M
L

P
R
O
C
.

V
I
E
W
E
R

X
X
X

X
X

X
X

X
X

X
X
X

X
X
X

X
X

X
X
X
X
X
X
X
X
X
X

X
X
X
X

X
X

X
X
X
X
X

I-12

D
A
T
A
B
A
S
E

S
P
R
E
A
D
S
H
E
E
T

X
X
X

X
X
X

X
X
X
X
X

X
X
X

X
X

X
X
X
X
X

X
X
X
X
X

G
R
A
P
H
/
R
A
S
T
E
R

G
R
A
P
H
/
V
E
C
T
O
R

X
X
X
X
X

X
X
X

X
X
X

X
X
X

X
X
X
X
X

X
X
X
X
X

X
X
X

X
X
X

X
X
X
X

X
X

I
L
S
/
L
S
A
R

X
X
X
X
X

P
R
I
N
T
E
R
S

P
L
O
T
T
E
R
S

X
X
X
X

N
E
T
W
O
R
K
S

X
X
X
X
X
X
X
X
X
X

I1.3.2 Hardware Requirements for Processing TDPs

Two decisions that affect the hardware requirements are whether the final engineering drawings
will be stored in the native CAD files or an equivalent vector format versus raster and whether
the engineers will be performing simulation. Engineering analysis cannot be performed on raster
data; thus, the processing requirement to work with only raster data can be significantly less than
with processable vector format, such as Initial Graphics Exchange Specification (IGES) or
VHDL. Processing TDPs with raster is limited to changes that would be accomplished on a
paper or 2-D drawing. This type of processing could make basic changes relatively quickly and
easily. However, modeling and simulation are best suited for 3-D vector data. The hardware
requirements differ among the disciplines of engineering required to be processed. Some basic
commercial IGES drawing packages can produce 3-D models on an 80486 computer. If the
project manager plans to simulate the stresses of a mechanical part or the multi layer printed
circuit board (PCB) layout, a RISC-based workstation should be considered. In addition to the
basic workstation, the project manager should address the procurement of the following
equipment:

Database Server (required for large, drawing databases)

MIL-STD-1840 tape drive (standard for large, data delivery)
Other media drives, including DAT, cartridge tape, and QIC (provide large storage
capacity)
PostScript printer (required for A size drawing and documentation)
A to D size electrostatic plotter (large volume of drawings or for raster drawings)
A to D size pen plotter (low volume vector drawings)

I1.3.3 Hardware Requirements for Processing ILS/LSAR

The specific hardware requirement for processing ILS/LSAR is directly dependent on the
software requirements. Several configurations can be made depending on the number of users
who need to access LSAR data. With multiple users sharing data, it is recommended that a
LAN-based LSAR system be installed. However, if the need is for a single user only, refer to
Table 7-4 for a guideline of the equipment required.
I1.3.4 Software Requirements for Processing Digital Data
The software requirements for processing digital data will be dependent on how the digital data
is received: on magnetic, via LAN/WAN or modem, or by other data transfer means. All of
these options will carry with them specific software needs and operating system requirements.
The project manager should procure systems that are compatible with not only end user output
requirements but also with both known and possible future digital data sources.
I1.3.5 Software Requirements for Processing TMs
The typical TM creation process consists of authoring, reviewing, updating, and inspecting the
technical manual or publication. Each program can accomplish these tasks by various methods.
The first decision of the project manager is whether the TM will be an illustrated text data file
technical manual or an IETM. This decision, along with the data use and the data format, will

I-13

determine the specific infrastructure

management, and use of a TM.

individuals

involved

will

require

in

the

creation,

I1.3.5.1 Software Requirements for Creating SGML Format TMs

The preliminary TM may be authored in a variety of software programs. Commercial word
processing software, desktop publishing software, or an SGML editor all have ability to author
technical documents with imbedded tables and figures. Therefore, the project manager must
ensure that the TM reviewers have software compatible with the contractor's TM-authoring
software unless the contractor is providing the viewing and commenting/annotating capabilities
through a CITIS. The TM reviewer must be able to view and annotate the TM file rather than
edit the existing file. Once the preliminary version is complete, commercial software is available
to convert a word processing or desktop publishing document into a MIL-M-28001 SGML
format file.
These programs try to add all the appropriate tags to the SGML text file. If the preliminary TM
is in SGML format, several options exist to allow users to view and annotate the manual.
Low-cost SGML document editors are available for PCS and UNIX workstations. PDL viewers
and annotator translators can be purchased to convert the entire SGML file into raster format,
word processing file formats, and desktop publishing file formats. Network software licensing
and data translators can minimize the cost of procuring the required software products. Since
most users involved in the review of a TM will not need an SGML editor all the time, a single
network license may provide five to ten users access to the software. As a final option,
translators can also be purchased to convert the document format into a format compatible with
their existing software. Data files can be translated among SGML and raster format, word
processing file formats, and desktop publishing file formats.
I1.3.5.2 Software Requirements for Creating IETMs
The preliminary IETM may be developed in a commercial word processing software or SGML
editor. Once the preliminary version is complete, the data must be converted such that a
Hypertext system can retrieve the data and display the information requested. IETMs should be
developed on systems that are capable of executing complex graphical user interface processes
immediately.
I1.3.5.3 Software Requirements for Managing TMs
Once the final reproducible copy of the TM is accepted, the cognizant life-cycle maintenance
activity is responsible for the configuration management of the document.
To properly
implement configuration management, the following software packages should be available to
the configuration manager.

SGML editor
DTD editor
Illustrator editor for vector and raster
Configuration management database

I-14

I1.3.5.4 Software Requirements for Using TMs

The software requirements for using TMs are based on the user's receiving electronic data
containing the TM and having the needed software to utilize the TM. Depending on the format
that the TM was delivered in, the end user could require any part of the following software to
utilize the TM.

SGML parser
illustrator editor for vector and raster
Database query application

I1.3.6 Software Requirements for Processing TDPs

The first decision that affects the software requirements is whether the final engineering
drawings will be stored in the native CAD files or an equivalent vector format versus raster.
Raster data does not allow the ability to utilize the data for engineering analysis; thus, the
processing requirement to work with only raster data can be significantly less than with
processable vector format, such as IGES or VHDL.
I1.3.6.1 Software Requirements for Creating TDPs
The software requirements for creating TDPs can be in several formats. The specific format
used depends on the type of data being generated and the way the data will be managed
throughout its life-cycle. The following formats may be used:

Native CAD
CAD2
IGES view
FEM (VHDL simulation)

I1.3.6.2 Software Requirements for Managing TDPs

Managing the TDP after its distribution to the field forces will entail all of the same software
requirements needed during its creation. The following list of software applications may be
required to meet these needs:

CAD2
Fluid flow analysis
PWB layout
SPICE simulator
VHDL simulator
PLD software
Hybrid/Application Specific Integrated Circuit (ASIC) software
Configuration management
Relational database

I-15

I1.3.6.3 Software Requirements for Using TDPs

The requirements for using TDPs are limited by the fact that users will not edit or change the
content of the TDP. Therefore, only the software necessary to view and print the TDP data will
be required. This will then depend on the type of TDP being used and the formats in which it
was distributed. The manager will have to determine what TDP formats are likely to be
encountered and develop a system appropriate to the end users' requirements. This will include
all or part, but not limited to, the following programs:

GES translators
Configuration management
Relational database
CAD2 - PWB layout

I1.3.7 Telecommunications Requirements for Processing Digital Data

The telecommunications requirements for processing digital data have been briefly discussed in
Paragraph 7.3. These requirements should be based on how data is to be shared or manipulated
and what current telecommunications infrastructure is available.
Specifically, the project
manager should determine the average number and size of data transfers to determine the type
and size of the communication systems needed. Considerations are the number of modems or
outside lines being supported, baud rate of the modem, error detection/correction performance,
and compatibility to data sources. Will the telecommunications system be installed using
standard, conditioned, trunk, or uninterruptible lines, or will fiber optics be used, if available?
Once the data is coming into the facility, how and where will it be stored, and will other outside
sources be allowed access? All these factors need to be given careful consideration. The initial
decisions will affect the current operation and future expansion of the system.

I-16

APPENDIX J: VIKING THROUGH LIFE STRATEGY AND PLAN

PG Viking Through Life Information Management Strategy

Date of first issue:
Project No.:
14 August 1998
Approved by:
Organizational unit:
Truls Grasmo
The ILS Group
Client:
Client ref.:
Kockums Ordernr: 213012 10
Summary:
As the first of three reports making up the Information Management Study in the Viking
program, this report constitutes the Through Life Information Management Strategy. In
addition, the Information Management studies will deliver the reports Information
Management Plan and Preparation for next project phase.
The Viking program is still in an early stage, and few decisions have been made, and it will
probably be necessary to update the Through Life Information Management Strategy when
more decisions regarding concept for the submarine and organization of the program have
been made.
The goals for Through Life Information Management are:

Improved through life quality and accuracy of system information

To establish accurate and consistent configuration management through life.
Reduce design, development, and production cost by 10%.

In order to accomplish these goals the following recommendations are made:

To establish a shared data environment with a common logical data structure amongst
all participating parties on both the government and the industry side.
The recommended solution for the shared data environment is:
Unclassified information: A shared data environment based on one logical information
structure with integrated access. Data can be allowed to be stored in several
geographical places, but in one logical structure. Information access shall be on-line.
Classified Information: Dedicated local systems with approved on-line connection. All
classified information shall be managed in the same logical structure as for unclassified
information.
The logical data structure for Viking should be able to hold and integrate all
information necessary to design, build, operate, and support the Viking submarines. It
should be based on open, international, or de facto industry standards, and necessary
commercial software should be available.

J-1

Editors Ref.:

PG Viking Through Life Information Management Strategy

Subject Group:

fbp/98aaadzf
Report title:
Through Life Information
Management Strategy
Work carried out by:
Viking Information Management
group, see Appendix A
Edited by:
Nils Sandsmark,
Frank Brre Pedersen
Work verified by:
Boye Tranum
Date of this
Rev.
revision:
No.:
5 September
03
1998

Indexing terms
Information Management, Digital Information
Through Life, Viking
No distribution without permission from the
responsible organizational unit

Limited distribution within PG Viking

Number
of pages:
*

Unrestricted distribution

J-2

PG Viking Through Life Information Management Strategy

Table of Contents
1 Introduction *
2 Description of the Viking Business Environment *
2.1 Goals for Viking *
2.2 Constraints, political decisions and concept choices *
2.3 Roles and relationships *
2.4 Options to be maintained *
2.5 Miscellaneous *
3 the Viking lifecycle *
3.1 Introduction *
3.2 Purpose *
3.3 The TLBM Model for PG Viking *
4 External Information Environment *
5 Goals for Through life Information Management *
5.1 Technical goals *
5.2 Business improvements *
5.3 How improvements will be managed and measured *
6 Shared Data Environments for VIKING *
6.1 Shared data environment options for Viking *
6.1.1 Solution A *
6.1.2 Solution B *
6.1.3 Solution C *
6.2 Common logical data structure for Viking *
7 Assessment of Options *
7.1 Shared data environment options *
8 Recommendation *
9 References *
Participants in the study
Cost, benefit and risk definitions

J-3

PG Viking Through Life Information Management Strategy

1. Introduction
The Viking program is a joint Scandinavian defense program between Norway, Sweden and,
Denmark with the overall intent to develop the next generation submarines. The program is
currently in the study and concept phase, where the main goal is to:
"Prepare the necessary background documentation for a decision to be taken by
March 31, 1999; thus allowing the authorities in the three countries to decide
whether or not it is considered expedient to continue the co-operation and
develop a common building specification for the new submarines."
See reference /1/ for further information.
As the first of three reports making up the Information Management studies in the Viking
program, this report constitutes the Through Life Information Management Strategy. In
addition, the Information Management studies will deliver the reports Information
Management Plan and Preparation for next project phase.
2. Description of the Viking Business Environment
2.1 Goals for Viking
The goals for the Viking program are:

Common procurement: To plan for a possible common procurement and if

politically acceptable, procure 10 submarines to Denmark, Sweden and Norway within
the period from 1999 to 2012.
Required capability: The submarines shall fulfill the operational goals for each
nation, and procurement costs for each submarine must be far less than if each nation
should procure individually. The program must also be beneficial for the life support
cost for the participating nations, and shall give Scandinavian industry the opportunity
to participate in the development and production of the submarines.
Required availability: To be determined during study and concept phase, but not less
than the Gotland-class. Staff requirements require that the benefit of availability must
be considered in proportion to the procurement costs.
Required sustainability: The submarine sustainability shall be calculated from the
basis of operational profiles and submarine missions. High degree of sustainability
must be given higher priority than redundancy.

2.2 Constraints, political decisions and concept choices

The Viking program is still in an early stage, and few decisions have been made, and it will
probably be necessary to update the Through Life Information Management Strategy when
more decisions regarding concept for the submarine and organization of the program have
been made.
Program constraints:
Decision to start a co-operative Project Definition Phase (PDP) medio/ultimo 1999
J-4

PG Viking Through Life Information Management Strategy

after the delivery of study phase reports in March 99.
Nations will have the opportunity to decide a common procurement after PDP,
probably at the end of 2001
Cost limit for the procurement of Danish submarines is 900 mill SEK (1996)
Limited competition due to the requirement to involve the nations submarine and
submarine related industry.

Political decisions:
Non of the nations have a political decision to acquire submarines
Expected after PDP.
Concept choices already made:
Study phase shows that harmonization of operational and technical requirements is
possible, and that particular systems to fulfill the special Norwegian requirements can
be fitted into separate sections or modules.
Requirements for training:
To be decided during study phase.
2.3 Roles and relationships
Several actors, their roles, and relationships have been identified for the Through Life
Information Management (TLIM) of Viking. As for section 2.2, several decisions will have
to wait until the program as a whole has made the relevant governing decisions.
PMO and Prime Contractor:
The status of prime contractor to be decided during Study Concept Phase (SCP).
Several options are possible, two of which are:
1. One prime contractor is preferred.
2. The prime contractor could be an industrial group/joint venture with
participants from Norway, Denmark, and Sweden.
PMO and operational logistics and support concept:
To be decided during study phase.
Industry involvement through life:
Project Definition Phase: Common development of specifications between industry and
PMO.
Design Phase (DP): To be decided during study phase.
Production Phase (PP): To be decided during study phase.
Support Phase (SP): To be decided during study phase.

Management of mid-life-updates:

J-5

PG Viking Through Life Information Management Strategy

To be decided during study phase.

Intellectual property rights:

To be decided during study phase.

How to audit warrantees and incentive mechanisms:

To be decided during study phase.

Roles and relationships regarding TLIM:

To be defined in TLIM Plan.

2.4 Options to be maintained

Not applicable in study phase.
2.5 Miscellaneous
Special issues requiring attention in the next version of the Through Life Information
Management strategy are:

Update of Through Life business Model (TLBM).

3. The Viking Lifecycle

3.1 Introduction
Based on the NATO CALS Through Life Business Model (TLBM), a TLBM has been
developed for the Viking program.
The TLBM is developed to help the program
management to manage change, by making best use of information technology over the lifecycle of the program, as enabled by a shared data environment (SDE). It represents a
common, agreed description of the major life-cycle activities and information flows, which a
program will need to address.
The Viking TLBM has to some extent been tailored and adapted to a Scandinavian through
life model for weapon systems, and to an appropriate level for the current project phase. The
Viking TLBM covers all main activities in the project (not just the information management
part), and is thus applicable to the program management of PG Viking. The TLBM may be
further detailed, e.g., into the areas of risk management and logistic support analysis (LSA).
3.2 Purpose
This TLBM constitutes an agreed description of the Viking lifecycle, allowing PG Viking to:

Maintain and update an agreed description of the Viking life-cycle, through a common
understanding of the main activities and information flows.
Gather, store and retrieve information for the Viking life-cycle
Facilitate creation of project plans, work orders, etc.

3.3 The TLBM Model for PG Viking

This Viking TLBM is dynamic and is developed in a structured manner as a BPWin model
J-6

PG Viking Through Life Information Management Strategy

/2/, based on the IDEF0 standard. The TLBM for the Viking program is enclosed in
Appendix C in the form of a Word document. The original BPWin model should be
consulted for a full reference of the Viking TLBM.
4. External Information Environment
At present, a large number of legacy systems are in use in Sweden, Denmark, and Norway.
Some of these systems are old and will be replaced before year 2000. Some are new and a
long life is expected.
Within the military services the situation is different in the three countries:

Denmark has made a decision to replace all the old systems with one integrated system
(DeMars) common to the entire Danish Defense. This system will be implemented in
the period 1999-2004 and will therefore be in full operation well before the first
Viking submarine will be delivered. This means that for the Danish navy, only the
DeMars system needs to be addressed.
Sweden is using a number of legacy systems, see reference /3/. The Swedish Defense
has decided to put all software system development on hold until an ongoing study on
the issue has been completed. This study is planned to be completed within a couple
of years and until then it is difficult to make assumptions with respect to relevant IT
trends, policies and plans.
Norway is also using a number of legacy systems, see reference /4/. The Norwegian
Navy is currently into a major acquisition project, where new escort vessels are to be
procured. This project is of such a size that software standard, choices and policies
will be of great relevance to other projects, also Viking.

For Defense industries in Sweden, Denmark, and Norway, very little information has been
received. This will be addressed at a later stage.
5. Goals for Through life Information Management
5.1 Technical goals
With regard to Through Life Information Management, the following technical goals are set
for the Viking program:

To store system information according to a common logical data structure and be online available . This includes also all support and maintenance information.
To establish and run accurate and consistent configuration management through life.

5.2 Business improvements

The use of Through Life Information Management will provide business improvements in
the Viking program:

Improved through life quality and accuracy of system information including support
and maintenance information.
Reduced cost, both in the acquisition phase, and in a life-cycle view. Reduce design,
J-7

PG Viking Through Life Information Management Strategy

development and production cost by 10% by introducing a shared data environment
and related working processes amongst all participating parties, both on the industry
side and on the government side. The 10% reduction shall be gained purely because of
better, faster and more accurate information flow, and shall be calculated based on
estimates from previous Norwegian, Swedish and/or Danish submarine programs and
LCC estimates to be calculated on the Viking submarine.
5.3 How improvements will be managed and measured
System information: No duplication of information will be accepted. The program
shall be manned with necessary skills to manage and handle information.
Configuration Management: The configuration management scheme shall include a
configuration audit function in order to assure the quality of the CM activity and CM
information.
Cost reduction: Cost reduction shall be measured by ongoing LCC tracking. Initial
estimates shall form a baseline (expected in the PDP).
6. Shared Data Environments for VIKING
6.1 Shared data environment options for Viking
6.1.1 Solution A
Unclassified information:
A shared data Environment based on common data structure with local stored
information.
Local data vaults partitioned based on functions and disciplines
(e.g., CM, LSAR). Distribution of data between installations will be based on off line
methods. The original data shall not be stored in more than one place. This requires a
common data administration.
Classified information:
Dedicated local systems with approved off line distributions.
6.1.2 Solution B
Unclassified information:
A shared data environment based on one logical information structure with integrated
access. Data can be allowed to be stored in several geographical places, but in one
logical structure. Information access shall be on-line.

Classified Information:
Dedicated local systems with approved on-line connection. All classified information
shall be managed in the same logical structure as for unclassified information. A
consistent system for referencing between classified and unclassified information must
be established.

6.1.3 Solution C
One multi security concept where all information is managed in one logical structure.
Information access shall be on-line.
6.2 Common logical data structure for Viking
J-8

PG Viking Through Life Information Management Strategy

The logical data structure for Viking should be able to hold and integrate all information
necessary to design, build, operate, and support the Viking submarines. It should be based
on open, international, or de facto industry standards, and necessary commercial software
should be available.
7. Assessment of Options
This section contains an assessment of the three options for a shared data environment
(SDE). The assessment takes into account:

Benefits: Value added by SDE in meeting project goals (such as Operational

Availability, minimized LCC, shorter development)
Cost: Cost of SDE (people, software, maintenance, etc ) Information resources is all
expenses incurred in the creation, processing and distribution of information
Risks: Technical, cultural, process change, etc. How much change can we manage?
How sophisticated can we be? (Evolution v revolution!)

Another important measure for the Viking program in order to support decisions regarding
Information Management is the life-cycle cost (LCC) model. This would naturally be a part
of the main LCC model in Viking. However, as the latter model is not established yet, this
will have to be postponed.
The assessment is performed using the philosophy of Criticality Management Tools (CMT)
as described in Refs. /5/-/6/. At the present stage, only a qualitative assessment is made.
The various options are evaluated on a relative scale, using the definitions listed in Appendix
B.
7.1 Shared data environment options
A qualitative assessment of the three solutions for a shared data environment (SDE) is
provided in Table 7.1 below. Refer to Appendix B for definitions of the terms used.
Table 7.1 Assessment of the Options for SDE
Solution

Cost

Solution A

Medium:
Cost estimate comparable
to other solutions

Solution B

Medium:
Cost estimate comparable
to other solutions

Solution C

High:
Cost estimate higher than
comparable solutions

Benefit

Risk

Low:
Off-line methods for
diversified information.
Requires a common data
administration

Significant:
Uncertainty
regarding ability
to adapt to
technological and
process changes.
Significant:
Geographically
distributed data
represents a
considerable
technological risk.
Critical:
Security
requirements not
acceptable.

Medium:
On-line methods for
geographically
distributed data.
Improved accessibility
due to one logic
High:
J-9
One multi security
system, with on-line
access to one logical

PG Viking Through Life Information Management Strategy

Solution C

High:
Cost estimate higher than
comparable solutions

High:
One multi security
system, with on-line
access to one logical
structure.

Critical:
Security
requirements not
acceptable.

8. Recommendation
Based on the assessment of Section 7, the following points are made for the shared data
environment options:

Solution A is inadequate as far as functionality is concerned, i.e., it is based on oldfashioned working processes that inhibit the full utilization of a shared data
environment.
Solution B is acceptable with respect to cost. Furthermore, it has major benefits. The
associated risk level can be accepted.
Solution C is unacceptable with respect to handling of classified information.
Technical challenges in relation to developing a solution meeting the security
requirements may be unacceptably costly.

From these considerations, the following recommendation is given: Solution B.

9. References
/1/
/2/
/3/
/4/
/5/
/6/

PG Viking, Minutes of meeting no 2, March 19, 1998.

BPWin Users Guide, Logic Works Inc., 1997.
List of Swedish legacy systems, FMV, 1998.
List of Norwegian legacy systems, SFK, 1998.
Criticality Management Tools Operation Manual, Det Norske Veritas, 1998.
Risikomanual PG Viking, 1998.

J-10

PG Viking Through Life Information Management Strategy

Appendix A: Participants in the Study
The participants in the Information Management group in the Viking program are:

Commander T. Grasmo
Major B. Tranum
Principal Technical Officer U. S. Carlsson
Head of Division J. B. Leimand
Captain K. Eikanger (Meeting 1 through 4)
Senior Eng. V. Smberg (Meeting 5 and onwards)
Cons. N. Sandsmark

J-11

PG Viking
NATO CALS
FMV
FKO
SFK
DNV

Sweden
Denmark
Norway

PG Viking Through Life Information Management Strategy

Appendix B: Cost, Benefit and Risk Definitions
This appendix contains the definitions of the cost, benefit and risk categories used in the
assessment of the three options regarding a shared data environment.
As opposed to cost and benefits, risk is a two dimensional quantity. It describes
uncertainties, and contains both a probability and a consequence dimension. For this reason,
risk is treated separately from cost and benefits below.
Table B.1 Consequence Categories for Cost and Benefits
Category
Cost

Benefit

Consequence
High
Medium
Low
High
Medium
Low

Definition
The option inflicts a large cost to the program
The option inflicts a considerable cost to the program
The option inflicts a minor cost to the program
The option provides large benefits to the program
The option provides considerable benefits to the
program
The option provides minor benefits to the program

Risk represents an unwanted deviation from a target. It has a two-dimensional nature, as it

depends both on the probability of such a deviation, as well as the consequence ("size") of
the deviation. In the qualitative version of CMT, the risk is divided into three levels, as
shown in Table B.2 below.
Table B.2: Risk Levels
Risk level
Critical

Significant

Negligible

Definition
A critical risk is unacceptable and mitigative actions must be implemented.
A Critical risk has both large probability of occurring and large
consequence.
A significant risk represents a considerable risk, but is still acceptable on
the grounds that it is constantly monitored to ensure that the risk level is not
increased to a Critical level.
A Significant risk has either large probability of occurring or large
consequence
A negligible is acceptable and can in most cases be discarded.
A Negligible risk has small probability of occurring and small consequence

Using the measures defined in Tables B.1 and B.2, the three options regarding a shared data
environment are evaluated with respect to their cost, their benefit, and the risks associated
with that option. This is done in sec 7 of this report.

J-12

APPENDIX K: VIKING THROUGH INFORMATION MANAGEMENT PLAN

PG Viking
Through Life Information Management Plan
Editors Ref. NSAN/99IMP_Rev 4
Revision No. 4
PG Viking
Mailing address
Projektkontor VIKING
S-205 55 Malm
Sweden
Tel:
Fax:

+46 40 34 80 00
+46 40 34 85 04

K-1

PG Viking Through Life Information Management Plan

Date of first issue:
Project No.:
19 January 1999
Approved by:
Organizational unit:
Truls Grasmo
The ILS Group
Client:
Client ref.:
Kockums Ordernr: 213012 10
Summary
As the second of two reports making up the Information Management Study in the Viking
program, this report constitutes the Through Life Information Management Plan. The Plan is
based on the Through Life Information Management Strategy and the Viking Requirements
Document (Preliminrt Kravdokument nr. 2).
The Through Life Information Management Plan is intended to be used as basis for:

Information Management in the Viking Program

Contract negotiations and discussions with Prime Contractor
Acquisition of IT systems for the Viking Program.

Information requirements for the Viking program are:

1. All information necessary to design, build, operate, and support the Viking submarines
should be stored according to a common logical data structure.
2. All information necessary to design, build, operate and support the Viking submarines
should be available on-line.
3. Information quality and accuracy through life shall be secured.
4. A shared data environment and related working processes should be introduced
amongst all participating parties, both on the industry side and on the government side.
5. The information from the Viking program shall be exchanged digitally with the
national information systems.
6. Classified and unclassified information shall be handled according to applicable
security requirements.
7. The Viking Through Life Business Model (TLBM) constitutes an agreed description of
the Viking lifecycle.
It is recommended that future information analyses for Viking is based on the Viking TLBM,
and that these analyses are regarded as living documents that will be subject of further
development. They should as a minimum be revised prior to each life-cycle phase.
The shipbuilding Parts of the STEP standard and the results of Product Life-cycle Support
initiative should be the core of the Viking Information Architecture for the design, production
and support activities. The Systems Engineering for the Viking program should be based on
IEEE Std 1220 and EIA/IS 632.

K-2

PG Viking Through Life Information Management Plan

Editors Ref.:
Subject Group:
NSAN/99IMP_Rev 4
Indexing terms
Report title:
Through Life Information Management Plan
Information Management, Digital
Information Through Life, Viking
Work carried out by:
Viking Information Management group, see
No distribution without
Appendix A
permission from the
Edited by: Nils Sandsmark
responsible organizational unit
Work verified by:
Boye Tranum
Limited distribution within PG
Viking
Date of this
Rev. No.: Number of
revision:
pages:
19 January 1998
4
19 + App
Unrestricted distribution

K-3

PG Viking Through Life Information Management Plan

TABLE OF CONTENTS
1
2

Purpose
Background
2.1
General Background
2.1.1 Overall project plan with milestones/schedule
2.1.2 How to address cultural changes/training
2.1.3 Program Office Staffing.
2.1.4 Program participants and location
2.2
Previously defined requirements
3
Information Requirements (content)
4
Information Architecture Requirements
4.1
Common Aspects for the Viking Life-cycle Information
4.1.1 Product Identification
4.1.2 Configuration and Structure
4.1.3 Linking
4.2
Life-cycle Activities
4.2.1 Define User Needs and specify Requirements
4.2.2 Design and Production
4.2.3 Support
4.2.4 Operation
5
Hardware requirements inclusive basis SW.
6
Software Applications Requirements
7
Roles and responsibilities
8
relevant data sources
8.1
External Information Environment
8.1.1 The military services
8.1.2 Defense industries in Sweden, Denmark and Norway
9
Implementation Plan
9.1
Infrastructure Implementation Plan
9.2
Contract Strategy for Information and Infrastructure
10
Review plan for the IMP
11
References
Appendix A: Participants in the Study
Appendix B: Information Analysis
Appendix C: Process for Information Management
Appendix D: Product Definition
Appendix E: Information Management Responsibilities

K-4

PG Viking Through Life Information Management Plan

1. Purpose
This Through Life Information Management Plan (TLIMP) represents a common approach
of Norway, Denmark, and Sweden to acquire and use information within the frames of the
Viking program.
It is intended to be used as basis for:

Information Management in the Viking Program

Contract negotiations and discussions with Prime Contractor
Acquisition of IT systems for the Viking Program.

The Through Life Information Management Strategy /1/ was the first of three reports making
up the Information Management study in the Viking program, The Through Life Information
Management Plan is the second report. It is based on the Strategy /1/ and the Viking
Requirements Document /2/ (Preliminrt Kravdokument nr. 2
2. Background
2.1 General Background
2.1.1 Overall project plan with milestones/schedule
The overall plan for the Viking program is:
Study-Concept Phase:
1997-1999
Project Definition Phase:
2000-2002
Design and Production Phase:
2002-2014
Launch of first submarine:
2007
This schedule is based on the requirement of delivery of the first submarine to Denmark in
2007.
2.1.2 How to address cultural changes/training
The participants in the Viking program shall conduct training during the extended
Study-Concept Phase in accordance with project plan in order to acquire the necessary skills
to use the information systems. Special attention will be given in assuring that the Prime
Contractor has necessary qualification and ability to respond in accordance with the Through
Life Information Management Plan.
2.1.3 Program Office Staffing.
PG Viking will be supported by a plan coordinator for Systems Engineering, Integration,
Quality Assurance, Information Management, and Configuration Management. This person
will have the role of Information Manager.
2.1.4 Program participants and location
Prime Contractor (PC) is expected to be a joint venture, IG Viking, consisting of Kockums
Naval Systems (KNS), Kongsberg Defense & Aerospace (KDA) and Danyard, (DAA). The
joint venture must have financial back-up from their mother companies.

K-5

PG Viking Through Life Information Management Plan

The PC is expected to establish itself at KNS in Malm, Sweden.
organization at Kongsberg, Norway, and DDA in Aalborg, Denmark.

KDA have the main

The three nations naval material commands are located in:

Naval Material Command Norway (Sjforsvarets Forsyningskommando, SFK):

Haakonsvern Naval Base, Bergen, Norway.
Swedish Defense Material Administration (Forsvarets Materiellverk, FMV):
Stockholm, Sweden.
Naval Material Command Denmark (Svrnets Materielkommando, SMK): Holmen,
Copenhagen, Denmark

2.2 Previously defined requirements

The Through Life Information Management Strategy /1/ constitutes the basis of the
information requirements for the Viking program. The requirements have been further
developed, structured and coordinated with other requirements in the Viking Requirements
Document /2/. These information requirements have formed the foundation for this Through
Life Information Management Plan:

All information necessary to design, build, operate and support the Viking
submarines should be stored according to a common logical data structure
The information shall be such that configuration management can be performed
during the entire life-cycle.
The information shall be such that codification can be performed during the entire
life-cycle
The information structure and format shall be developed according to international
standards or open de-facto industrial standards.
Necessary commercial software should be available to support the chosen standards.
The information should be adaptable to different actors with different needs.
All information necessary to design, build, operate and support the Viking
submarines should be available on-line
Affected actors in the Viking program should be able to work with the same
information simultaneously.
Both classified and unclassified information shall be available on-line
Information quality and accuracy through life shall be secured:
The Viking information system shall not contain any duplication of approved original
information.
The information shall be extensive enough so that adequate traceability can be
performed between different data-elements, requirements, functions, and solutions.
The information should have a logical structure and format so that it does not require
reformulation with regard to exchange and sharing.
A shared data environment and related working processes should be introduced
amongst all participating parties, both on the industry side and on the government

K-6

PG Viking Through Life Information Management Plan

side.
The information from the Viking information system shall be exchanged digitally
with the national information systems.
Denmark: The DeMars system
Norway: Await results of ongoing study and decisions made during the new frigate
project
Sweden: Await results of ongoing study
Classified and unclassified information shall be handled according to applicable
security requirements.
Unclassified information: A shared data environment based on one logical
information structure with integrated access. Data can be allowed to be stored in
several geographical places, but in one logical structure.
Classified Information: Dedicated local systems with approved on-line connection.
All classified information shall be managed in the same logical structure as for
unclassified information.
The Viking Through Life Business Model (TLBM) constitutes an agreed description
of the Viking lifecycle.

3. Information Requirements (content)

Information requirements should be based on an information analysis. This analysis must be
regarded as an integrated part of the proposed study on work processes, methods and tools
for the Viking program.
A number of methods are available for information analysis. Two methods have been
considered during the development of the Viking Thorough Life Information Management
Plan:

An information analysis based on the Viking TLBM /1/.

The Information and Information Systems analysis developed by FMV, see Appendix
C

An interim information analysis based on the Viking Thorough Life Business Model is
described in Appendix B. The aim of this analysis is to identify information objects, and to
determine roles and responsibilities for information handling.
It is recommended that also future information analyses for Viking is based on the Viking
Thorough Life Business Model, and that these analyses are regarded as living documents that
will be subject of further development. They should as a minimum be revised prior to each
life-cycle activity according to Figure 4.1.
4. Information Architecture Requirements
The purpose of this Information Architecture is to give a through life common method of
linking and referencing information in order to fulfill the Through Life Information
Management Strategy /1/. This will facilitate communication and communality across all

K-7

PG Viking Through Life Information Management Plan

life-cycle activities and functions
The scope of the Information Architecture is all information necessary to design, build,
operate and support the Viking submarines.
The life-cycle of the Viking system is divided into 5 main activities as shown in Figure 4.1
and described in chapter 4.2. The Information Architecture is based on the planning
documents of the Product Life-cycle Support (PLCS) initiative /3/. This initiative is intended
to develop standards that will be Parts of ISO 10303 (STEP). The shipbuilding Parts of the
STEP standard /4/ and the results of PLCS are planned to be the core part of the Viking
Architecture. Together these STEP Parts cover three of the five main activities, namely the
design, produce and support activities.
The shipbuilding and the life-cycle support Parts of the STEP standard are not ready for use
in a major project today. However, they are expected to be ready by the time the Viking
programme enters the Design and Production and the Operation Phase respectively, see
chapter 2.1.1. Alternatives exists for all three phases, see Chapter 4.2.2.2 and 4.2.3.6.
Within STEP, a project has been started to develop a Part for Systems Engineering. The
activity define user needs and specify requirement is intended to be covered by this Part of
ISO 10303. However, this part will not be ready by the time the Viking programme enters
the Project Definition Phase, see chapter 2.1.1. The Viking programme therefore plan to use
other standards, see chapter 4.2.1.1 Standards for Systems Engineering.
The activity operate is not directly covered by STEP. Information from operations that is
required in order to support the Viking submarine is included in PLCS. Other information
requirements must be included later, see chapter 4.2.4. Operation.

K-8

PG Viking Through Life Information Management Plan

Through Life Business Model
Operate
Define User Needs
and specify
Requirements

Linking
Configuration
and
Structure
Support
Product
ID

Design
Produce
Management
ManagementInformation
Information

Figure 4.1 The Viking Information Architecture

The system information is a result of and is linked to the activities that will be carried out, as
documented in the Viking Through Life Business Model. In addition to the product
information, there is a need for management information like budget, personnel, time etc,
This information is not a part of this architecture.
Information needed and how such information is stored, retrieved, and changed depend on
the strategies, policies, methods, and processes that will be applicable for the program
through the lifetime of the Viking submarine.
4.1 Common Aspects for the Viking Life-cycle Information
A set of common rules and regulations is necessary in order to facilitate communication and
traceability of system information between the main activities during the life-cycle. At the
very center of this is the concept of product identification.
4.1.1 Product Identification
Defining a product is complex because there are many ways of looking at the same thing.
STEP defines a product as a thing or substance produced by natural or artificial processes.
Use of the word produced in the above definition may communicate the idea that a product
is always a physically existing object. This is not true. At the very early stage of its
life-cycle, a product may exist simply as a concept described by the customer needs and
operational requirements. At the end of the design phase a product may be seen as
physically realizable object or design. It becomes a physically existing object only at the
end of the manufacturing process. Once realized the product is to be supported throughout

K-9

PG Viking Through Life Information Management Plan

the life-cycle.
To manage products over their life-cycle it is necessary to address these different views of
product and to distinguish between the product As Required, As Designed, As Built,
and As Maintained.
4.1.2 Configuration and Structure
Configuration Management shall be applied on all system information covered in this plan.
4.1.3 Linking
Linking regulations will act as enabler to transfer and relate information between life cycle
activities and information management systems. The linking layer will contain all necessary
transformation protocols and techniques.
4.2 Life Cycle Activities
The life cycle of the Viking system is divided into 5 main activities as shown in Figure 4.1.
This brake down is based on information intensive activities, and does not jeopardize the
formal project phases. These activities are not necessarily in sequence.
4.2.1 Define User Needs and Specify Requirements
Define User Needs and specify Requirements implies everything from the identification of
operational needs to detailed technical requirements. The requirement development will be
carried out according to the descriptions and standards as described in the Acquisition
Strategy (Viking Kontraheringsstrategi) document.
The project/product model depicted in Figure 4.2 shows the connections between high-level
documents/strategies and specifications down to the basis for production.

K-10

PG Viking Through Life Information Management Plan

Obj

Strategy and policies

Ops req
Acquisition
strategy
Master
Budget
plan
PMP
StoW
ILS-Plan
SSS
VIKING
SSS
IPC
(P01)

SSS

Time and economy

Quality
(Functionality and performance)

SSS
IWS

Sub-functions and diciplines

SSS
P02 - P09

Detailed specifications

Figure 4.2 Viking Strategies and Specifications

4.2.1.1 Standards for Systems Engineering
The Systems Engineering for the Viking program will be based on the IEEE Trial-Use
Standard for Application and Management of the Systems Engineering Process (IEEE Std
1220) and the Interim Standard Systems Engineering (EIA/IS 632).
If the system descriptions in the database will not become the basis for a contract or there is a
need for distributing specification information by other means, the contents of the database
must be documented as requirement specifications. The documentation format will be based
on DI-CMAN-80008A for the System/Segment Specification (SSS) and on DI-CMAN80534 for the System/Segment Design Document (SSDD). They will cover the top-level
functional and non-functional requirements, operational scenarios, interfaces, physical
structure, and the life cycle processes including the Information Logistics Support (ILS)
aspects.
4.2.1.2 The Purpose of the Systems Engineering Standards
The purpose of the DI-CMAN-80008A is:

Specify the requirements for a system or a segment of a system.

Provide a general overview of the system or segment that may be used by training
personnel, support personnel, or users of the system.

The purpose of the DI-CMAN-80534 is:

Describe the design of a system/segment and its operational and support

environments. It describes the organization of a system or segment as composed of
K-11

PG Viking Through Life Information Management Plan

Hardware Configuration Items (HWCI), Computer Software Configuration Items
(CSCI), and manual operations.
Contain the highest-level design information for the system or segment, and it
describes the allocation of system requirements to HWCIs, CSCIs, and manual
operations.
To be used by the contractor primarily to present the system design at the System
Design Review and use the design information as basis for developing the Software
Requirements Specification for each CSCI, the Interface Requirements Specification
for the system and the requirements specification for each HWCI.

4.2.2 Design and Production

Based on the previously defined requirements, see Chapter 2.2, the ISO 10303 STEP
standard is chosen as the basis for the common logical data structure for design and
production in the Viking program.
Several aspects were important:

The ability of the data structure to hold all necessary information to design and build
the Viking submarine.
The amount of reformulation necessary for design and production information in
order to make it suitable for operation and support activities
Exchange, and sharing of information between the parties involved in design and
production
Integration of information
Long term storage of information

4.2.2.1 ISO 10303 STEP for Shipbuilding

ISO 10303 STEP is an International Standard for the computer-interpretable representation
and exchange of product data. The objective is to provide a mechanism that is capable of
describing product data throughout the life cycle of a product, independent from any
particular system. The nature of this description makes it suitable not only for neutral file
exchange, but also as a basis for implementing and sharing product databases and archiving.
At present five Parts or Application Protocols of the Ship Product Model are under
development:
1.
2.
3.
4.
5.

AP 215 Arrangements
AP 216 Molded Forms
AP 217 Piping
AP 218 Structures
AP 226 Mechanical Systems

All of these Application Protocols have reached a stage where they are technically stable.
However, the Ship Product Model is not covering all areas necessary to hold all necessary
K-12

PG Viking Through Life Information Management Plan

information for design and production of the Viking submarine. Other solutions must be
chosen for Electrical, HVAC, Combat Systems, etc. For some of these areas, like Electrical,
Application Protocols developed for other industries can be used. In other areas, like
Combat Systems, STEP does not have a solution. A more detailed plan must therefore be
developed for the Viking program. This must be done in co-operation with the industry (IG
Viking).
STEP translators are available for the major CAD and CAE systems and exchange of
information based on STEP Application Protocols is common today. Integration and longterm storage of information based on STEP are less developed. However, several of the
major PDM vendors are in the process of developing solutions based on the STEP PDM
schema.
4.2.2.2 Alternative Solutions for Design and Production
Two other options for a common logical data structure for the design and production
activities have been considered:
1. Standardize on existing, well-proven IT systems. Today, a number of well proven
CAD, CAE, and PDM systems exist. On a short term basis, it could be a solution that
PG Viking and IG Viking chose the same systems. However, it seems unlikely that
PG Viking and the relevant industrial partners in the three countries could agree on
using the same systems. Furthermore, the cost of the transfer of the information for
operation and support to the three countries will be high.
2. ISO 15926 Oil and Gas. ISO 15926 Oil and Gas will become a standard for
integration and sharing of information in the oil and gas industry. The draft standard
is already used by the oil and gas industry in Norway, England, and Holland. In
addition, USA and Japan have shown interest for this standard. Software to support
for the standard exists (Intergraph, IBM, etc.). The standard is not generally accepted
in NATO. There is, however, interest shown by defense authorities in some NATO
countries (USA, UK), and in Sweden. It is difficult to predict how this standard will
be received outside the oil and gas industry.
None of the two alternatives described above are recommended for the Viking program.
However, they should be kept in mind if further work shows that it is more difficult than
expected to base the common logical data structure on STEP.
4.2.3 Support
Support information implies all information necessary to support the Viking system from the
owner's point of view. Traceability must be maintained between support information, design
information, and requirement information.
Support information includes the information necessary to support Viking after it is handed
over to the owners. The information can be divided into information for four areas:

K-13

1.
2.
3.
4.

PG Viking Through Life Information Management Plan

Maintenance
Supply chain
Configuration management/Change control
Support engineering

In addition to the specific information for each of the four areas, there is a set of information
that is common. This is called the core information.
4.2.3.1 Information scope for support activities
The information scope for the support activities is:

Maintenance: Maintain, test, calibrate, repair, and modify the Viking submarine,
including schedules, resources, and feedback.
Supply chain: Buy, store, pack, move, issue and dispose of physical items for the
Viking submarine and its support systems.
Configuration management/Change control: Manage change to a configured item
through-out the life cycle, including tracking of serial number where applicable.
Support engineering: Provide and sustain the support infrastructure.

The information scope is to provide the necessary information for the support activities. The
core information is described in chapter 4.1 Common Aspects for the Viking Life Cycle
Information
4.2.3.2 Maintenance Information
This section defines and structures the information needed to prevent or respond to
predictable failures of the physical product instance (single individual), in a specified usage
scenario. This information includes:

The identification and configuration of the product instance including its physical and
functional breakdown.
The required product performance, to the level needed for maintenance,
Failure modes and diagnostic characteristics,
Relevant usage and operating history,
Maintenance task descriptions and associated resources (parts, tools, skills and
facilities),
A sufficient description of the product to support the maintenance activity
(e.g., drawings, video clips etc),
Test and calibration procedures, following product maintenance,
Information on the return or safe disposal of items no longer required.

Note: Most of this data is generated by the Design and Support Engineering processes.
4.2.3.3 Supply Chain Information
Operational availability cannot be sustained without access to appropriate spare parts. This

K-14

PG Viking Through Life Information Management Plan

section defines the part related information that is relevant to maintenance of the physical
product. This includes:

The identification and properties of parts, including packaging, handling storage and
transportation characteristics,
The information needed to procure parts, including details of alternative suppliers.
The planned location of spares holdings.

4.2.3.4 CM/Change control

Changes to the product configuration may change the maintenance and spares required.
Implementation of a change may be a maintenance task. This section addresses the
information needed to manage changes to the configuration of an existing product.
In addition, because of the high importance of the configuration structure to product
information management, this section also address the information needed to develop a
configuration structure as part of the design activity and to manage changes to design. It
does not address the re-engineering of the design solution.
4.2.3.5 Support Engineering
This section defines the information needed to develop and to optimize the support solution
for the product, initially and during life. The information needed to achieve this includes:

Intended operating and maintenance scenarios.

Supportability characteristics (required, forecast and actual).
Classification of maintainer skills.
Policies and procedures for maintenance and supply.
Intended support solutions (the required maintenance and supply activities).
The reasons for choosing support solutions (e.g., Level of Repair Analysis).

4.2.3.6 Alternative Solutions for Support

ISO 10303 STEP. STEP is the recommended standards for a logical data structure for
support as well as for design and production. Support is not yet covered by STEP. NATO
CALS has, however, taken an initiative to have this area covered (Product Life Cycle
Support PLCS), and there exist plans for a project that will develop such a standard during
the period 1999-2001.
STEP is supported by several of the large software vendors, and a large number of software
systems supporting this standard already exist. Most likely, this will also be the case for a
prospective PLCS standard. It is expected that STEP will be generally accepted in NATO
when it has reached a further level of maturity.
Several other options exists for a logical data structure for support:

Standardize on existing, well-proven IT systems. Today, there exist several well-

K-15

PG Viking Through Life Information Management Plan

proven systems in this category, for instance SAP. On a short term basis, this may be
the best solution. However, it seems unlikely that all three Defense procurement
agencies and relevant industrial partners in the three countries all agree on purchasing
the same systems. Furthermore, the cost of a potential transfer to different systems in
the future will be large. This alternative must however be seriously considered. If
STEP or one of the marked leading systems is chosen, it will have (or the vendor will
develop) external communication protocols that are compatible with other systems.
If one of the standards listed below turns out to be generally accepted,
communication solutions based on these standards will most likely be developed.

UK Def. Std. 0060 This standard has been chosen as interim standard for Integrated
Logistic Support (ILS) in Norway. It is based on well-proven technology and there
exists software to support it. It is however partially based on old technology, and it is
a combination of three standards (U.S. MIL STD 1388, AECMA 2000M and
AECMA 1000D). This results in the same data being stored more than once. The
standard is not generally accepted by NATO. Nevertheless, for ILS solutions based
on accepted standards, it seems like the lowest risk solution.

NATO CALS Data Model. This specification is developed by NATO CALS. It

contains several good elements, but is still not complete. It is not generally accepted
in NATO, and there is limited software to support it. However, software is under
development and a further development of the NATO CALS Data Model could be an
alternative for the Viking program.

None of the three alternatives described above are recommended for the Viking program.
However, they should be kept in mind if further work shows that it is more difficult than
expected to base the common logical data structure on STEP.
4.2.4 Operation
This implies information necessary to conduct Operational Logistics, including co-operative
logistics with other elements and weapon systems.
4.2.4.1 Operational Information Requirements
The Viking Information Management System should provide necessary information to the
Operational support activity during operational missions. Information elements according to
Logistical messages in the ADatP-3 (Allied Data Publication nr 3) will define the detailed
information requirements. This has to be taken into account when finalizing the support
phase information system.
No further detailed requirements will be determined at this point in time, due to significant
development in the Operational Command and Control area concerning information
requirements and handling.
5. Hardware requirements inclusive basis SW.
At present, no specific requirements have been identified.

K-16

Hardware requirements will be

PG Viking Through Life Information Management Plan

determined at contract point according to functional performance requirements.
6. SoftWare Applications Requirements
Which software applications will be use for each information group throughout the lifecycle
activities.
Define user needs and
specify requirements
Microsoft Systems
Engineering software
Open PDM systems

Design/Construction

Open PDM systems

CAD, CAE and other
design systems

Support/Operation

Open PDM, etc.

and/or national
support systems
IETM and CBT
systems

7. Roles and Responsibilities

This chapter determine all roles and responsibilities for information creators, information
managers, information owner and users throughout the lifecycle:

Information Creators: Persons or organizations that creates information and deliver

it to the Viking Information Management System.
Information manager: The person responsible for the Information Architecture and
the Information Management System. The Structure and System owner This role is
also responsible for the legal aspects for information as described in Appendix E.
Information Owner: The person or organization responsible for the information
content.
Information user: Persons or organization that uses information stored in the Viking
Information Management System.

8. RELEVANT DATA SOURCES

8.1 External Information Environment
At present, a large number of legacy systems are in use in Sweden, Denmark, and Norway.
Some of these systems are old and will be replaced before year 2000. Some are new and a
long life is expected.
8.1.1 The military services
Within the military services the situation is different in the three countries:

Denmark has made a decision to replace all the old systems with one integrated
system (DeMars) common to the entire Danish Defense. This system will be
implemented in the period 1999-2004 and will therefore be in full operation well
before the first Viking submarine will be delivered. This means that for the Danish
navy, only the DeMars system needs to be addressed.

K-17

PG Viking Through Life Information Management Plan

Sweden is using a number of legacy systems, see reference /5/. The Swedish
Defense has decided to put all software system development on hold until an ongoing
study on the issue has been completed. This study is planned to be completed within
a couple of years and until then it is difficult to make assumptions with respect to
relevant IT trends, policies and plans.
Norway is also using a number of legacy systems, see reference /6/. The Norwegian
Defense is at present carrying out several studies and projects on information
management and information systems. These activities are planned to be completed
within a couple of years, and until then, it is difficult to make assumptions with
respect to relevant IT trends, policies and plans.

8.1.2 Defense industries in Sweden, Denmark and Norway

For defense industries in Sweden, Denmark and Norway some information has been received
on status and near tem plans for IT systems. Very little information is available on plans for
information management. This must be addressed at a later stage in co-operation between
PG Viking and the relevant industry.
9.0 Implementation Plan
This chapter is mainly focused on the near future, and will act as preparation for the next
program phase.
9.1 Infrastructure Implementation Plan
The following activities will be carried out:

Discussion with potential information management system suppliers in order to

determine which system to use to specify requirements, analyze, and organize user
needs.
Determine how to install and run the Viking Information Management System
All responsibility with Prime Contractor
Separation between Prime Contractor and PG Viking with split responsibility
Third party support
Determine the necessary level of support from the supplier of the Viking Information
Management System
Implementation of agreed system, including necessary hardware
Training and testing
Mapping of existing Objectives, User Needs, and Requirements into the Viking
Information Management System.

9.2 Contract Strategy for Information and Infrastructure

Discussion with IG Viking, the Prime Contractor, concerning detailed roles and relationships
for the coming phase will be initiated and document in the contract for the coming phase.
The aim shall be to have full transparency of all information from the Prime Contractor,
without any delay.

K-18

PG Viking Through Life Information Management Plan

10. Review plan for the IMP
This Plan shall be revisited when necessary, and must be regarded as a living document. As
a minimum, it shall be renewed at each new lifecycle phase.
Next Renewal no later than: Prior to development Contract
11. References
/1/
Through Life Information Management Strategy, PG Viking, 1998
/2/
Viking Requirements Document (Preliminrt Kravdokument nr. 2), PG
Viking, 1998
/3/
http://www.cals.nato.be
/4/
http://www.nist.gov/sc4
/5/
List of Swedish legacy systems, FMV, 1998.
/6/
List of Norwegian legacy systems, SFK, 1998.
Please do not delete the Bookmark named numPages on this last page in the report.
- o0o -

K-19

PG Viking Through Life Information Management Plan

Appendix A: Participants in the Study
The participants in the Information Management group in the Viking program are:
Commander T. Grasmo
Lieutenant Colonel B. Tranum
Principal Technical Officer U. S. Carlsson
Head of Division J. B. Leimand
Captain K. Eikanger (Meeting 1 through 4)
Senior Eng. V. Smberg (Meeting 5 and onwards)
Cons. N. Sandsmark
o0o

K-20

PG Viking
NATO CALS
FMV
FKO
SFK
DNV

Sweden
Denmark
Norway

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
TLBM Leaf Processes:
The lowest level processes in the Through Life Business
Model for Viking
Information Objects:
Information objects derived from or created by the TLBM
Leaf Processes
Information Creator:
Persons or organizations that creates information and deliver
it to the Viking Information Management System. (VIMS).
Prime contractor (PC)
PMO
Steering Committee (SC)
National rules and regulations (N R&R)
Information manager:

PMO Information Manager (PMOIM)

Prime Contractor Information Manager (PCIM)
National Information Manager (NIM)

Information Owner:

The person or organization responsible for the information

content.

Prime Contractor (PC)

PMO
Nations (N)

Information users:

The person responsible for the Information Architecture and

the Information Management System. The Structure and
System owner This role is also responsible for the legal
aspects for information as described in Appendix C.

Persons or organization that uses information stored in the

VIMS

PMO
Naions (N)
Prime contractor (PC)
Steering Committee (SC)
Support organizations (SO)

K-21

TLBM Leaf
Processes
A111
Analyse Candidate
Solutions

K-22
A112
Derive And
Allocate
Requirements

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Solutions to meet the
Solution Analysis
PMO
PMO
identified mission need
Result
Defined constraints for
N
N
selection of a solution
Approach and evaluation
PMO
PMO
criteria for the analysis
Approach for choosing,
PMO
PMO
selecting, and studying the
candidate solutions
Rationale and results of the
PMO
PMO
analysis.
Detailed and precise set of
requirements
System functions, objects,
people, and supporting
processes, products, and
services which requirements
are allocated to
Derived requirements to
lower level functions or
objects
Status and traceability of
requirements

Detailed and precise set

of requirements

Inf.
Manager
PMOIM

Inf. Users

PMOIM

PMO, PC

PMOIM

PMO, SC

PMOIM

PMO, SC

PMOIM

PMO, SC

PMO, SC,
PC
PMO, SC,
PC

PMO, SC

PMO, PC

PMO

PMOIM

PMO, PC

PMO

PMOIM

PMO, PC

PMO

PMOIM

PMO, SC,
PC

PMO, PC

PMO

PMOIM

PMO, SC,
PC

TLBM Leaf
Processes
A113
Evolve System
Architecture

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
A system design with key
System Architecture
PMO, PC PMO
design issues.
Architecture requirements
PMO, PC PMO

K-23

Functional and physical

structure and interfaces
Allocated architecture
requirements to system
elements
Functional (or logical),
physical (tangible), and
foundation architectures
A114
Integrate
Disciplines

A115
Integrate System

Disciplines necessary for

effective system
development
Co-operative environment

Necessary disciplines

Identified, defined, and

controlled interfaces
Verified system functions
that require multiple system
elements

Current Req

Inf.
Manager
PMOIM

Inf. Users

PMO, PC

PMO

PMOIM

PMO, SC,
PC
PMO, SC,
PC
PMO, PC

PMO, PC

PMO

PMOIM

PMO

PMO, PC

PMO

PMOIM

PMO, SC,
PC

PMO, PC

PMO

PMOIM

PMO, SC,
PC

PMO, PC

PMO

PMOIM

PMO, SC,
PC

PMO, PC

PMO

PMOIM

PMO, PC

PMO, PC

PMO

PMOIM

PMO, SC,
PC

PMOIM

TLBM Leaf
Processes
A121
Define Lc
Strategy
And Policies
A122
Define
Acquisition
Strategy

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
High level Life Cycle
LC Strat and Pol.
N R&R,
NR&R, SC
Strategies and Policies
SC, PMO

K-24

Approach to be taken in
acquiring a service or
VIKING component,
initially
Approach to be taken in
acquiring a service or
VIKING component, for resupply.
Method of acquisition

Acq Strat

Use of competition and or

partnering arrangements
Contract incentive
mechanisms
Determination of what rights
and what data must be
acquired as part of the
contract, or separately.
A123
Define Risk
Strategy

Program approach to
identifying, assessing and
managing risk

Risk Man Strategy

Inf.
Manager
PMOIM

Inf. Users
PMO, PC

N R&R,
SC, PMO

N R&R, SC

PMOIM

PMO, PC

N R&R,
SC, PMO

N R&R, SC

PMOIM

PMO, PC

N R&R,
SC, PMO
N R&R,
SC, PMO
N R&R,
SC, PMO
N R&R,
SC, PMO

N R&R, SC

PMOIM

PMO, PC

N R&R, SC

PMOIM

PMO, PC

N R&R, SC

PMOIM

PMO, PC

N R&R,
PMO

PMOIM

PMO, PC,
SC

PMO

SC

PMOIM

PMO, PC,
SC

TLBM Leaf
Processes
A124
Develop Ils
Strategy

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Strategy and plan to show
ILS Strategy
PMO, N
PMO
how ILS will be
R&R, PC
implemented for the
VIKING System over its full
life cycle.

Inf.
Manager
PMOIM

Inf. Users
N, PMO, PC,
SC

K-25

A125
Develop Cm
Strategy
And Plan

Strategy and plan to show

how CM will be
implemented for the
VIKING System over its full
life cycle.

CM Strategy

PMO, N
R&R, PC

PMO

PMOIM

N, PMO, PC,
SC

A126
Develop Qa
Strategy
And Plans

Actions required to ensure

systematic approaches
Integrated concurrent design,
manufacture and support of
the VIKING System and the
related processes

QA Strategy

PMO, N
R&R, PC
PC, PMO

PMO

PMOIM

PC, PMO

PMOIM,
PCIM

N, PMO, PC,
SC
PC, N, PMO

TLBM Leaf
Processes
A127
Develop TLIM
Strategy and Plan

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Assessment of the business
TLIM Strategy and
N R&R,
PMO
and Through Life
Plan
PMO
Information Management
(TLIM) Environment
Program goals for TLIM
SC, PMO PMO
Assessment of the costs,
risks, and benefits of the
options of TLIM

K-26

A131
Manage
Program
Schedule

A132
Establish
Roles And
Relationships

Program WBS

Program WBS and

Program Schedule

Service Level Agreements

needed to specify the
standard of ongoing services.
Proposed changes to
implement or reject
Top level Program schedules
Allocated responsibility for
the various program task
over the life cycle
Tasks to be placed on
contract.
Mechanisms for
incentivising and ending
contracts

Org Structure and

Requests for Assistance
and
Activities to be
contracted

Inf.
Manager
PMOIM

Inf. Users

PMOIM

PC, PMO,
SC
PMO, SC

PC, PMO,
SC

PMO, PC

PMO

PMOIM

PMO, SC

PMO, SC

PMOIM

PMO, PC,

PMO, PC

PMOIM,
PCIM

PC, PMO,
N
SC

PMO

PMOIM

SC

PMOIM

PMO, SC,
N

PMO, N

PMOIM,
PCIM

PMO, N, PC

PMO, SC,
N
PMO, SC,
N

PMO, N

PMOIM

PMO, PC, N

PMO, N

PMOIM

PMO, PC, N

PMO, SC,
PC
PMO, PC,
SC, N
PMO, PC, N,
SC
PMO, PC, N

TLBM Leaf
Processes
A1331
Develop Contract
Strategy

K-27
A1332
Issue Solicitation

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Program, specific
Contract Strategy
PMO, SC PMO
documented requirements
levied by the negotiated
contract or agreement.
Insurance that Staff Target,
PMO, SC PMO
program objectives, and
implementation plans are
incorporated in contractual
definitions and design
information
Programmed available
PMO, SC, PMO
funding into the contractual
N
process
Initiation and execution of
PMO, SC, PMO
appropriate agreements
N
which may fall outside of the
specific contract
Prepared contractual
solicitation or tender
including the Statement of
Work, the Evaluation
Criteria, and the Contract
Deliverables.

Invitation to Tender

PMO, SC

PMO

Inf.
Manager
PMOIM

Inf. Users

PMOIM

PMO, PC

PMOIM

PMO, N

PMOIM

PMO, N

PMOIM,
PCIM

PMO, PC

PMO, PC

TLBM Leaf
Processes
A1333
Assess Proposals

A1334
Run Contract

K-28
A134
Manage
Viking Lc
Funding

A135
Manage Human
Resources

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Assessment of formal
Selected Contractor
PC
PC, PMO
responses
Selected successful bidder.
PMO, SC SC

Activities required to place

and operate the contract over
its life time
Assessment of achievement
against requirements
Approval of payments
Resolution of issues arising.

Contracts and Contract

Dir.

Acquiring, allocation, and

accounting for the funds
needed to provide VIKING
through life.
Forecasting and tracking
VIKING Life Cycle Cost.

Budget Req
Available Funding and
Predicted LCC

Plans, monitor action and

control of provision of
human resources for
VIKING program lifecycle.

Allocated Manpower

Inf.
Manager
PCIM,
PMOIM
PMOIM

Inf. Users
PMO, SC
PMO, SC,
PC

PMO, PC

PMO

PMOIM

PMO, PC,
SC

PMO, SC

PMO

PMOIM

PMO
PMO, PC,
SC, N

PMO
PMO

PMOIM
PMOIM

PMO, SC,
PC
PC
PMO, PC,
SC, N

PMO, SC

PMO

PMOIM

PMO, N, SC

PMO, PC

PMO, N

PMOIM

PMO, SC, N

PMO, N

PMO

PMOIM

PMO, N, SC,
PC

TLBM Leaf
Processes
A1361
Develop
Im Plan

K-29

A1362
Establish and
Operate
Program Sde

A1363
Provide
Information
Services

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Defined the program
SDE Req. and
PMO, N
PMO
Information requirements
IM Plan
Defined IT-infrastructure
PMO, N
PMO
requirements
Plan for capturing,
PMO, N
PMO
controlling and delivering
the required information to
users.
Design of the Shared Data
Environment
Acquisition plan of the
Shared Data Environment
Deployment plan for the
Shared Data Environment
Guides and rules for use of
the Shared Data
Environment

Contract Information
Req and
Program SDE

Describe Information
Services

Information Services

Inf.
Manager
PMOIM
PMOIM
PMOIM

PMO, N,
PC
PMO, N,
PC
PMO, N,
PC
PMO, N,
PC

PMO

PMOIM

PMO

PMOIM

PMO

PMOIM

PMO

PMOIM

PMO, PC

PMO, PC

PMOIM,
PCIM

Inf. Users
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC

PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC

PMO, PC, N

TLBM Leaf
Processes
A14
Compare Actual
System State and
Performance With
Required

K-30
A211
Develop
Conceptual
Options

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Comparison of actual system
Perf Rep and
PMO, PC PMO, PC
state and performance with
Inst to Ops and
that required
Change Proposal
Identified the need for
PMO; PC, PMO, PC
changes
N
Changes Proposal,
PMO, PC, PMO, PC
N
Acceptability of requests for
PMO, N
PMO
waivers or concessions for
components which fall short
of the design intent
Report on the performance of
PMO, PC, PMO, PC
the VIKING System and the
N
VIKING Program
Advice to Operators over
PMO, PC, PMO, PC
specific design limitations
N
Reviewed operational threat
and Mission Need
Identified and evaluated
potential alternative solutions
Selected conceptual solution

In Service Goals and

VIKING Concept

Inf.
Manager
PMOIM,
PCIM

Inf. Users

PMOIM,
PCIM
PMOIM,
PCIM
PMOIM,
PCIM

PMO, PC, N

PMOIM,
PCIM

PMO, PC, N

PMOIM,
PCIM

PMO, PC, N

PMO, N, PC

PMO, PC, N
PMO, PC, N

PMO, N

PMO

PMOIM

PMO, SC

PMO, N,
PC
PMO, SC

PMO

PMOIM

PMO

PMOIM

PMO, SC,
PC, N
PMO, PC, N,
SC

TLBM Leaf
Processes
A212
Define
Viking
System

K-31
A213
Engineering
Design

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Functional design of the
Change Impact and
PMO, PC PMO, PC
VIKING System
Proc Spec and
Test Def and
Analysis of the design
PMO, PC PMO, PC
Functional Architecture
features needed by the
subsequent manufacturing,
transportation, use, support,
and disposal processes
Required functionality of
PMO, PC PMO, PC
systems, sub systems and
components for both the
operational system and the
support system
Acceptance criteria for test
PMO, PC PMO, PC
and evaluation
Identification of items that
PC
PC
can be bought from
suppliers, and which still
require to be designed.
Detailed engineering design
activities
Product model for the
VIKING System and its
support equipment
Manufacturing,
refurbishment and disposal
processes.

Mfr and Rfb data and

Core Product Data and

Inf.
Manager
PMOIM,
PCIM
PMOIM,
PCIM

Inf. Users

PMOIM,
PCIM

PMO, PC,
SC, N

PMOIM,
PCIM
PCIM

PMO, PC,
SC, N
PMO, PC,
SC, N

PMO, PC,
SC, N
PMO, PC,
SC, N

PC

PC

PCIM

PMO, PC, N

PC

PC

PCIM

PMO, PC, N

PC

PC

PCIM

PMO, PC, N

TLBM Leaf
Processes
A214
Failure
Analysis

K-32

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Failure modes, effects and
FMECA Data
PC, PMO PC, PMO
criticality
Product anomaly, criticality,
PC, PMO PC, PMO
causes/effects and
compensating provisions
Diagnostic and
PC, PMO PC, PMO
troubleshooting
recommendations.
Expected frequency of
PC, PMO PC, PMO
failure
Expected reliability.
PC, PMO PC, PMO

Inf.
Manager
PCIM,
PMOIM
PCIM,
PMOIM

Inf. Users

PCIM,
PMOIM

PC, PMO, N

PCIM,
PMOIM
PCIM,
PMOIM

PC, PMO, N

PC, PMO, N
PC, PMO, N

PC, PMO, N

TLBM Leaf
Processes
A215
Design The
Support
System

K-33

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Procedures and data needed
Support Info and
PMO, PC, PMO, N
to provide an optimized
Reqd Feedback and
N
support capability
Trg Req and
Support Equipment
Procedures for operating,
PMO, PC, PMO, N
Requirements
servicing and maintaining
N
Viking including diagnostics
and post repair tests
Intentions for managing the
PMO, PC, PMO, N
initial and ongoing supply of
N
materials, components and
spares required for
manufacture and in-service
use
Form of stock management
PMO, PC, PMO, N
N
Policies and procedures for
PMO, PC, PMO, N
the return, assessment,
N
refurbishment and disposal
of items no longer required
Policies and procedures for
PMO, PC, PMO, N
supplying operators and
N
maintainers with the
information they require to
perform
Define feedback needed
PMO, PC, PMO, N
from operators and
N
maintenance staff to
optimize the performance of
the support system

Inf.
Manager
PMOIM

Inf. Users

PMOIM

PMO, PC, N

PMOIM

PMO, PC, N

PMOIM

PMO, PC, N

PMOIM

PMO, PC, N

PMOIM

PMO, PC, N

PMOIM

PMO, PC, N

PMO, PC, N

TLBM Leaf
Processes

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Procedures for data
PMO, PC, PMO, N
collection and analysis.
N
Training requirements for
PMO, PC, PMO, N
operators and maintainers.
N
Expected performance of
VIKING
Prediction of system
capability, life, availability,
readiness and life cycle cost.

Predicted Perf

A22
Produce
Viking
System

Fabrication, assembly and

production testing of the
Operational VIKING
Refurbishment of items
returned from service

A23
Conduct Testing

Measuring results for the

performance of all VIKING
components
Defined supportability
features, processes and
equipment

K-34

A216
Predict Life Cycle
Performance

Inf.
Manager
PMOIM

Inf. Users

PMOIM

PMO, PC, N

PMO, PC, N

PMO, PC

PMO

PMOIM

PMO, PC, N

PMO, PC

PMO

PMOIM

PMO, PC, N

As-built Config and

Tools and Facs. and
Spares and
Components and
VIKING System for
Deployment and
Items for Test

PC

PC

PCIM

PMO, PC, N

PC

PC

PCIM

PMO, PC, N

Test Findings

PMO, N

PMO

PMOIM

PMO, PC, N

PMO, N

PMO

PMOIM

PMO, PC, N

TLBM Leaf
Processes
A24 Deploy Viking
System

K-35

A 31
Plan Support

A32
Store
Transport and
Issue Items

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Activities needed to, receive,
VIKING System ready
PMO, N
PMO, N
process, and transport new
for Ops and
Operational VIKING
Spares and
System, support equipment
Components and
or components, from the
Tools and Facs.
manufacturing environment
to the location from which
they will normally operate,
or be stored
What work to do, in what
order, on the systems
awaiting support
Specification of the required
configuration for each
individual system
Requirement for items to be
purchased for use in support
activities.

Required Items and

Support Plan and
Req Config

Items needed for

maintenance or to support
VIKING on operational use

Items for Use

Inf.
Manager
PMOIM

Inf. Users
PMO, N, PC

PMO, N

PMO, N

PMOIM.
NIM

PMO, N, PC

PMO, N

PMO, N

PMOIM.
NIM

PMO, N, PC

N, PMO

PMOIM

PMO, N, PC

TLBM Leaf
Processes
A33
Maintain,
Update and
Provide
Feedback

K-36

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Work needed to restore
Returned Items and
N
N
VIKING to the condition
Feedback fm
required for the next
Maintenance and
intended operation
Maintained Submarines
and As-maint Config
Updated configuration
N
N
changes
Maintenance feedback on
N
N
findings
Action taken and issues
N
N
arising

Inf.
Manager
NIM

Inf. Users

NIM

NIM

NIM

A34
O&S Tasks

Activities needed to prepare

the system for operations

VIKING System ready

for Ops

NIM

A35
Manage
Facilities

Activities needed to sustain

the special to type facilities
and tools in a fit for use
condition.

Returned Items

NIM

A36
Train
Support
Staff

Tasks, actions, and activities

to achieve and maintain the
knowledge and skill levels
necessary to efficiently and
effectively perform
operations, support and
disposal.

Trained People

N, PMO

NIM

TLBM Leaf
Processes
A37
Conduct
Evaluations

A4
Dispose Or
Recycle

PG Viking Through Life Information Management Plan

Appendix B: Information Analysis
Information Objects
TLBM Information
Inf.
Inf. Owner
flow (arrows)
Creator
Evaluation of a VIKING
Evaluation Findings
N, PMO
N
operational and support
and
capabilities
In-Scope Eval Findings
Conclusions and
recommendations

K-37

Identify activities related

with the retired VIKING
Systems and VIKING
components for disposal or
refurbishment
Assessment of the state of
the item
Decide on whether to
refurbish for use within the
program, make it available
for use by others

Disposed Items and

Items for Rfb

Inf.
Manager
NIM

Inf. Users
PMO, N

NIM

NIM

NIM

PG Viking Through Life Information Management Plan

Appendix C: Process for Information Management
Introduction
The target for the Information and Informatic analyse (I2-analyse) is to specify an
information management and processing solution for a defined business process. A
Information Solution is the Business solution for information processing and management
including:

Information processing and management processes

Information
Support systems for Information processing and management processes

Inputs to the I2 process is plans, strategies and descriptions of existing and planed:

Business processes information objects and information flows

Information management process
Support systems for information processing and management

Output is strategies, specifications, work breakdown structures and plans to produce the
Information Solution.

I2-analyse

98-12-21

Command & Control

TLBM

TLBM, PLCS

Realisation
PLCS, TLBM

Business process
analyse

Business
processes

MIL-STD
490A
961D

Design
process

Informationanalyse

Information

Tailoring

K-38

Techniques

Informaticsanalys

Information

PG Viking Through Life Information Management Plan

Appendix C: Process for Information Management
Process description
The I2- process is built up of tree analyse processes, one design process and two
management processes.
The management processes are the Command, Control, and Tailoring processes.
The Command, Control process continuously controls and gives inputs to the tailoring
process and the other processes that also continuously gives feedback in terms of status,
technical opportunities and constrains.
The tailoring process tailors from the beginning, and then continuously, both the overall I2process and its sub processes.
The first step is to use the process to establish it self and to define its own information
processing and management process.
The tree analyze processes, business process analyze, Information analyze and Informatics
analyze are supposed to be performed sequential and iterative.

The business process analyze analyses the business processes

The Information analyze analyses the business processes information
The Informatics analyze analyses the support systems for information processing and
management

The Business process analyses are focused on the business processes from an information
management and processing perspective.
The business process analyse use the inputs from the business process models to define and
give outputs to the Information analyse and the Information solution design process
regarding:

Business objects with related information

Business procedures and tasks processing and or using information
Rules and regulations influencing information management and processing
Organization of Works including roles and responsibilities
Existing and planed infrastructure for information processing and management

The Information analyze is focused on the information content (Information content objects)
and the business objects containing information (Information business objects).
The Information analyze use the inputs from the business process analyze to define and give
outputs to the Informatics analyze and the Information solution design process regarding:

K-39

PG Viking Through Life Information Management Plan

Appendix C: Process for Information Management

Information business objects and Information content objects

Classification of information content and business objects
Processing of information content and business objects
Information processing workflow
Flows for information content and business objects

The Informatics analyze is focused on the support systems for information processing and
management.
The Informatics analyze use the inputs from the information analyze to define and give
outputs to the Information solution design process regarding:

Methodologies for realization

Use of existing and planned infrastructure for information processing and management
Techniques
Standards
Implementation requirements

The Information solution design process is focused on the design of the complete
information solution including processes, information architecture, and support systems.
The Information solution design process use the inputs from the tree analyze processes to
specify the Information solution and its realization.

K-40

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
The Express diagrams presented in this section are provided as visual aids to better describe
the requirements and NOT as modeling solutions.
What is PRODUCT?
Defining a product is complex because there are many ways of looking at the same thing.
STEP defines a product as a thing or substance produced by natural or artificial
processes. Use of the word produced in the above definition may communicate the idea
that a product is always a physically existing object. This is not true. At the very early stage
of its life cycle, a product may exist as simply as concept described by the customer needs
and operational requirements. At the end of the design phase a product may be seen as
physically realizable object or design. It becomes a physically existing object only at the
end of the manufacturing process. Once realized the product is to be supported throughout
the life cycle.
To manage products over their life cycle it is necessary to address these different views of
product and to distinguish between the product As Required, As Designed, As Built
and As Maintained.
This can be accomplished as follows:
The life-cycle of a product starts with the definition of a product_concept that is the idea of
a product as defined by customer needs. The AS REQUIRED view of a product is defined
by the mission need that created the demand for the product and is described by its required
functionality (product_requirement: e.g., expected features, capabilities, performance, et
cetera);
The design activity, based on the required functionality, progressively defines the physically
realizable objects or the AS DESIGNED view of the product. The set of related designs is
then used to manufacture a quantity, possibly thousands, of physical products
(product_instance);
The exact configuration of each of these product_instance(s) in terms of parts/components
identification (e.g., by serial number and/or lot number) defines the AS BUILT view of the
product.
Later in the life-cycle, each product_instance is maintained, repaired and part/components
are replaced due to malfunctions or configuration changes. All information related to these
activities identify the AS MAINTAINED view of the product.
In its broadest sense, a product consists of the sum of its product_concept +
product_requirement + product_design + product_instance.
These objects are closely inter-related as shown in Figure 1.

K-41

Relationships should be

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
maintained throughout the life-cycle.

product_
requirement

product_
requirement_
product_
concept_
association

product_
concept

product_
instance_
product_
concept_
association

product_
instance

product_
concept_
product_
design_
association

product_
requirement_
product_
design_
association

product_
design

Figure 1 The Product Architecture

The product_concept object is the collector or common root for all subsequent objects. The
product concept is the idea of a product as defined by customer needs. It identifies a
deliverable product as perceived by the customer (e.g., an item in the catalog of a supplier).
A product_concept may exist without a product_design or a product_instance. It is related
to the object product_requirement that describes the required performance or behaviors of
the deliverable product.
The object product_requirement, in turn, is related to
product_design making it possible to relate functionality to design.
The product_design object is the container of (1) functional design, (2) physical design and
(3) support design. It is related to product_concept and to product_instance. The latter is
the relationship between a specific actual object (identified, for example, by its serial
number) to the design information from which it was developed. This relationship is
optional since it is not always possible or necessary to relate product_instance(s) to a
product_design.
The product_instance object is the container of data related to the ACTUAL physically
existing object (e.g., an actual helicopter with a tail number).
The Viking Perspective
The VIKING objective is to improve product availability by improving the quality and
availability of the technical information needed to support the complex Viking product inservice. The term product in this definition should be seen and understood as the
product_instance described above (only a physically existing object may be supported).
For Viking the main focus will be placed on the product_instance object.

K-42

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
To support a product_instance in-service, we need to know its ACTUAL configuration,
role, condition state, maintenance history, and operational history (AS BUILT, AS
MAINTAINED). Then we need a mechanism to link the product_instance to (1) the
maintenance directive resulting from the support engineering activity; and (2) to the
technical data resulting from the functional and physical design activity. In this proposed
architecture, the linking mechanism between product_instance and the other product objects
is achieved through relationships.
In Figure 2, each diagram in the stack is a coherent network of information. For each
physical instance of the engine (e.g., Engine with S.N. 003), it is possible to navigate
through the relationships to identify requirements, design information, and logistic
information that are applicable for the specific engine.
ENGINE XMN S.N. 005
ENGINE XMN S.N. 004

ENGINE XMN S.N. 003

product_requirement

product_concept

product _instance

product _design

Figure 2 Product_instance relationship

This is true for all the specific engines that have been manufactured.
specific and unique set of data and relationships for each product_instance.

In fact, there is a

In this way, the effectivity of configuration, technical data, and logistic tasks to
product_instance is explicitly defined through relationships.
Product Concept
A product_concept is the idea of a product as conceived by the user. It will often
correspond to the items supplied to the user (e.g., an item in the catalog of a supplier). The
definition of product_concept(s) is driven by users needs and by user defined usage
scenario. It represents the idea of a product based on user viewpoint and NOT as it might be
designed or manufactured.
The basic relationships of product_concept are described in Figure 3.

K-43

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
classification _of_
class_of_product_
concept

usage_
scenario

classification _of_
usage_scenario

class_of_
product_
concept

product _concept_
usage_scenario_
association

class_of_
usage_
scenario

classification _of_
product_concept

product _concept

product_
concept_
succession

(ABS)
product_concept_
relationship

product_
concept_
composition

class_of_product_
concept_relationship

classified_
product_concept_
relationship

Figure 3 Product_concept Basic Relationships

Some detailed information requirements are the followings:

a product_concept is defined by a name, an identifier and a textual description;

the product_concept identifier is the combination the user organization identifier and a
unique identifier assigned by that organization.
It is assumed that the user
organization issues unique identifier within its domain;
product_concept(s) may be classified, decomposed, and aggregated.
Class of
product_concept should be defined;
product_concept(s) may be versioned and may be subject to Configuration Change
Control (configuration item);
a product_concept may be related to different contexts or usage scenarios. This
relationship is a many-to-many since the same product_concept may have many usage
scenarios and a usage scenario may apply to many different product_concept(s);
a usage_scenario may be described by:
environment conditions (e.g., temperature, pressure, wind velocity);
user conditions (e.g., human capability and limitations, national laws and regulations);
support conditions (e.g., support resources, pipeline times);
mission phase (e.g., landing )
Simple conditions may be combined with AND, OR and XOR operators to define
complex usage_scenario(s);
Usage_scenario(s) may be organized in classes. Most probable scenario and worstcase scenario in peacetime and wartime employment are examples of usage_scenario
classes.

Product Requirement
A product_concept in a specific usage_scenario may be characterized by a set o required or
expected product features, performance or behaviors identified by the user or derived by the
users needs.

K-44

PG Viking Through Life Information Management Plan

Appendix D: Product Definition

product_
concept

product_concept_
usage_scenario_
association

usage_
scenario

applies_to
is_realized_by

product_
requirement

product_
physical_
design

Figure 4 Product_requirement Basic Relationships

A product_requirement relates to one or more product_concept_usage_scenario association
and to zero, one or more product_design. This implies that a product_requirement instance
may exist without a product_design but it could not exist without a product_concept and the
associated usage_scenario.
Product requirements have a number of associations with organizations.
association is the one used to identify the organization defining the requirements.

A typical

Some specific data requirements could be the following:

Product_requirement(s) may be classified, decomposed and aggregated;

A complex combination of product_requirement(s) with conditions may be specified
by composing one or more product_requirement(s) that are related by conditions;
Classes of requirement may be defined. Some product requirement classes may be:
Constraint definitions (e.g., budget constrains, human limitations);
Functional requirements (e.g., to provide an output voltage of 24 Volts plus-minus
0.5V);
Operation requirements (to work ceaselessly for 2500 hours in usage_scenario n.2).
Includes also mobility, mission frequency and duration;
Support requirements (to be repaired on site within 48 hours);
Physical requirements (not more than 5 Kilos);
Change of a product_requirement should be addressed by configuration change
control entities such as change request, implementation directive and applied solution
(see paragraph 6.7.1.1);
Associations between a predecessor product_requirement and a successor
product_requirement should be maintained. This association states that the successor
requirement is created by modifying the predecessor requirement;

K-45

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
Product_requirement(s) may be described by using STEP IRs constructs such as
property definition, property representation and measure schema;

Product Design
The product_design object has a number of relationships with the other views of the
product (see Paragraph 6.1 and Figure 5).
1,3 product_concept
1,1 product_requirement

1,2 product_instance
product_concept_product_
design_association

product_
requirement_
product_design_
association

product_
functional_
design

functional_
design_
physical_
design_
relationship

(ABS)
product_design

product_
physical_
design

product_instance_
product_design_
association

physical_
design_
support_
design_
relationship

product_
support_
design

functional_design_
support_design_
relationship

Figure 5 Product_design Relationships

The product_design may consist of functional design, physical design, and support design.
These three components are related each other, making it possible, for example, to derive
the product_physical_design instances that are involved in a function or the
product_support_design instances applicable for a particular physical design.
Product Functional Design
The product functional domain describes what activities are performed, within a system, in
one or more usage scenario, to fulfill a requirement.
The diagram in Figure 6 describes the basic relationships:

K-46

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
product_
concept

product_
requirement

product_requirement_
product_concept_
association

applies_to
is_realized_by
product_
physical_
design

product_concept_
usage_scenario_
association

usage_
scenario

product_
functional_
design

Figure 6 Product_functional_design Basic Relationships

A function could provide a service, process materials or change the state of the system
environment. Functions form a hierarchy, with the top level being the function of the
product_concept itself and the bottom level being individual actions.
For example if Electric Generator is the product_concept, the functional hierarchy top
level would be Produce Electric Power with such sub-functions like Provide Fuel to the
Combustion Chamber which in turn could be decomposed into Store Fuel, Supply Fuel
and Inject Fuel. The functional analysis is useful to identify the physical products that
need to be designed to perform the activities (e.g., in our case: the fuel tank, the fuel ducts
and the injectors.)
In the above example, only mechanical functions are involved. In other cases, we may have
functional hierarchies that include a set of interacting sub-functions some of which could be
mechanical, some information processing, and some hybrid (both). The function Track
Target, for example, may be an abstraction of the functions Identify Target, Obtain
Current Position, and Maintain Course. The realization of these functions may involve
diverse technologies such as radio communications, radar tracking, interaction with a GPS
satellite and computing equipment to calculate a course.
Functional design is not achieved solely by hierarchical decomposition of top-level function.
In addition to hierarchical relationship, functions may interact in many other ways. For
instance, a function could be activated based on the result of a previous function. In this
case, a chain of functions is defined. In the above example the function Obtain Current
Position cannot be activated until the function Identify Target has been completed.

K-47

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
A typical relationship in the chain is the one between a caused_function and a
causing_function meaning that the first is affected by a status change of the second. In a
wider sense, each function may be controlled by a behavioral interface or control-port that
affects its state.
Some of the data requirements for product functional design are the followings:

A product_functional_design relates to one or many product_concept(s) and to zero,

one or more product_requirement. This implies that a product_functional_design
instance may exist without a product requirement, but will always be related to at least
one product_concept;
A
product_functional_design
is
realized
by
zero,
one,
or
more
product_physical_design;
A product_functional_design is uniquely identified by the combination of the
designing organization identification and by the identifier assigned by that
organization;
A product_functional_design may be controlled by zero or one organization at a given
point in time in one or more control methods;
Control methods should be defined. Authority for approval is an example of control
methods.
A
product_functional_design
may
be
categorized.
A
class
of
product_functional_design may in turn be organized in a class hierarchy;
Agreed classes of product_functional_design should be defined;
A product_functional_design may relate to another product_functional_design;
The rationale for the relationship between two product_functional_design(s) shall be
defined (e.g., a functional breakdown);
A mechanism to trace function execution sequence (causal_chain) should be provided;
A function may be associated with zero, one or many control_port(s);
A function cannot be activated unless all control_port objects associated with the
function are enabled.
Whether a control_port is enabled is decided by the value and type of its attributes;
A product_functional_design has multiple representations in various formats such as
plain text, structured text (SGML, HTML, XML), drawings, video, audio or external
documents.

The diagram in the Figure 7 covers most of the above requirements:

K-48

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
classification_of_
class_of_
product_
functional_design

class_of_
product_
functional_
design

classification_
of_product_
functional_
design

product_requirement_
product_concept_
association

(ABS)
product_functional_
design_relationship

identification_of_
functional_design
organization
control_of_
functional_design

product_
physical_
design

functional_design_
physical _design_
association

product_
support_
design

functional_design_
support_design_
association

1,3 property_
representation

product_
functional_
design

functional_
breakdown
causal_
relationship

causal_
chain

classified_
relationship

class_of_
relationship

functional_
design_
control_port_
association
functional_design_
property_
association

control_
port

functional_design_
property

Figure 7 Product_functional_design High Level Model

Product Physical Design
Product physical design is an abstraction of product_instance or the design of a
product_instance. It may be used to represent the design throughout the design phase, from
the initial design through detailed design including variations in the design that may meet
different requirements or different functionality.
The subject of product_physical_design is the identification, the classification, and
representation of designs and the relationships between them.
This relationship may define a product design in term of its product structure as a set of
constituent product designs.
A product_physical_design has a number of relationships with other views of product (see
Figure 5).
Some detailed information requirements are the following:

Each product_physical_design is identified in the context of an organization. This

implies that the same product_physical_design may have multiple identifications for

K-49

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
different organizations.
Different types of product reports should be possible by using the
product_physical_design. These reports should be able to describe the product
structure to many levels of details. Level of details may address, for instance, the
degree of decomposition (e.g., single level or multi level) and the type of
decomposition (e.g., exploded, flattened, indented etc);
Bill of Material, Part List, Illustrated Part Catalogue Structures are example of product
reports;
A product_physical_design is characterized by zero, one or more properties;
Product_physical_design properties may be represented using STEP IR constructs;
In addition, product_physical_design properties may be represented by plain text,
structured text (SGML, HTML, XML), drawings, video, audio or references to
external documents;
Product_physical_design may be classified. Class of product_physical_design may in
turn be organized in a class hierarchy;
A class of product_physical_design may have a set of predefined properties that must
or may be filled-in to represent a product_physical_design instance that is a
component of that class;
Product_physical_design changes should be addressed by change process information
such as change request, implementation directive, and applied solution.

Product Support Design

In simple terms, the objective of support engineering is to determine what can go wrong
with a product and what has to be done to sustain availability (see 5.1.1). This includes
actions to repair or to prevent problems from occurring.
Basically, support engineering consists of Failure Analysis, Task Analysis, and Spares
Analysis. These activities are conducted on the basis of the users Support Requirements.
(Note: support requirements, a sub-type of product_requirement, relates to the association
between product_concept and usage_scenario).
The focus in this section is NOT on how these Analysis are conducted, but on the
information that are generated by these activities (output) that constitute the logistic
technical information needed to support a product_instance during its life-cycle.
Failure Analysis
It is assumed that, at the end of the design phase, a residual number of predictable failures
still exist. This occurs because it is either impossible or not cost effective to eliminate the
failures or because they result from external agents. Each one of these predictable failures
should be addressed by a maintenance strategy to:

Reduce the risk of failures to a minimum (preventive maintenance);

Provide a remedy should the failure occur (corrective maintenance).

K-50

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
A failure involves a product_physical_design while performing a certain function in a
particular usage scenario.
More precisely, the predicted failure of a product applies to one or
product_physica_design and happens in the context of one or
product_functional_design and of one or many usage_scenario. (See Figure 8).

many
many

product_
concept

product_
functional_
design

functional _design_
usage _scenario_
association

product_concept_
usage_scenario_
association

in_the_context_of
product_
physical_
design

failure _of

usage_
scenario

failure

Figure 8 Failure Context

A failure is described by its:

Cause: failure causes may be classified as internally generated within the system by
an inherent property of the product or produced by external factors (usually human or
environment);
Effect: failure effects fall into two major classes: local_effects (e.g., increased engine
smoke) or failure_inducing_effects (e.g., failure in an oil pump leading to a failure of
the engine).

The notion of failure_inducing_effects introduces the need to manage a cause-effect chain.

At a very simple level, two failures, Failure 1 and Failure 2, may be associated to define that
Failure 2 is caused by Failure 1.
In a more complex situation, Figure 9, a particular failure (Failure 4) will occur only if two
other failures (Failure 1 and Failure 2) occur together or if a third (Failure 3) occurs by its
own and not with the first two.
In a cause-effect chain it should be possible to combine failure causes with:

K-51

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
AND operators, when the related causes must occur together;
OR operators, when the related causes can but need not occur together;
XOR operators, when the related causes are mutually exclusive.

failure 1
consequential_
failure_
relationship
failure 2

causes

xor_consequential_
failure_relationship

Failure 4

consequential_
failure_
relationship

failure 3

Figure 9 Consequential Failures

The association between failure and effects may be used to capture additional information
such as probability and safety hazard severity (e.g., critical, minor, none).
Detection Method: the detection method describes how the operator or the maintenance
technician detects a specific failure. Warning devices, test equipment, and their normal or
abnormal indication are described by the detection methods.
Task Analysis
The basic objective of the task analysis is to define necessary tasks for the support and
operation of the product. Reliability Centered Maintenance techniques can be used to
decide what needs to be done to either correct a failure or to prevent a failure from
occurring.
A task applies to one or more product_physical_design instances. These are not necessarily
the same product_physical_design instances identified in the failure analysis.
A task is performed in a support_scenario that describes under which conditions
(environment, national regulations, available skills, etc) the task is expected to be
performed.
The diagram in Figure 10 describes the task context.

K-52

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
product_
concept

product_
functional_
design

functional _design_
usage_scenario_
association

product _concept_
usage_scenario_
association

usage_
scenario

in_the_context_of
product_
physical_
design

task_
failure_
association

failure_of
failure

product_
physical_
design

in_scenario

applies_to
task

Figure 10 - Task Basic Relationships

A task provides the instructions on how to perform a particular activity or action.
Some information requirements related to task are the followings:

Task(s) may be classified. Servicing Tasks, Scheduled Tasks, Occasional Tasks are
examples of task classes;
A task may relate to another task for a particular reason;
The possible rationale for two task(s) to be related should be defined. Alternate
task(s) is an example of this rationale;
Maintenance level, criticality, and other qualifications may be assigned to a task;
Some task characteristics such as time to perform and cost may be derived by the rollup of sub-task attributes;
When and whether to perform a task depends on conditions. A simple condition may
define, for example, that a task is to be performed every three months (e.g., do task
A IF date(current)-date(task_A_last_done)>90);
Simple conditions may be combined with AND, OR and XOR logical operators to
define more complex conditions (e.g., do task A IF date(current)date(task_A_last_done)>90 .OR. mileage(current) mileage(task_A_last_done) >
3000 );
Condition monitoring may require that certain parameters of product_instance and
support_scenario be measured and recorded. Where data is collected automatically,
the source sensor should be identified.
A task is usually decomposed in elementary task stages or steps that may be seen as
modular building blocks. Tasks may be defined by assembling the elementary (base)

K-53

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
stages using selected criteria.
Some requirements for base_stage are the followings:

A base_stage may be assigned to zero, one or many task(s). This implies that a
base_stage may exist without a task and that the same base_stage may be assigned to
many task(s);
A base_stage may be either a method_stage (what to do) or an advisory_stage
(warnings, cautions, );
A task shall include at least one method_stage;

A method_stage may be described in different forms, e.g., by a simple narrative description

of what to do or by more sophisticated forms of representations such as video, audio, virtual
reality;
Some resources may be needed to perform the activity described by a method_stage.
Resources may have a role (e.g., spare parts, consumables, test equipment, calibration
equipment, etc.) and may be quantified;
The identified resources include the following:

Facility_or_infrastructure: this may be a reference to a generic facility (e.g., 220V

power supply) or a generic infrastructure (e.g., a dry-dock). It also may be a reference
to a specific named and located facility;
Information_requirement: a reference to the applicable information (drawings, wiring
diagram, manuals);
Personnel_with_skill: a reference to the needed skill subject and grade
Material: it is a reference to part, subassemblies that play a role in the method_stage.
This includes tools and support equipment;
Time: optional definition of the expected time required to perform a method_stage.
Time qualifiers may be mean time, maximum time, etc.
Money: optional definition of the expected cost to perform a method_stage;
Build in facilities in the existing product;
Consumables (e.g., oil, water .. )

Having defined the entities task and base_stage, there is still the need to define how the
base_stage(s) are assembled together to form a task.
Basically, a task may be seen as a linear flow or sequence of base_stage(s). In such simple
instance, Task A is made up of Step 1 (the base_stage) followed by Step 2 and so on.
More frequently, however, the flow of actions is not a plain linear sequence of
base_stage(s). For example, the flow of actions (what to do next) may depend on the results

K-54

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
of a test condition.
A flow control structure that is external both to task and to base_stage may be used to alter
the flow of actions of a task. Use of a control structure would enable Interactive Electronic
Technical Manual (ITEM) style functionality to be provided directly from the Product Lifecycle Support database. The constructs that should be supported by the control structure are
the following:

Base_stage_sequence: it is the list of base_stage(s) to be carried out in order;

Control_transfer: rather than referencing a base_stage, the control structure is allowed
to call another base_stage_sequence or even another task. This means that tasks and
sequences can be nested within each other;
Conditional_transfer: enables a choice between different routes depending on the
result of a test condition. The choice could be between two alternatives (IF ELSE
ENDIF) or between many (DO CASE . CASE ENDCASE);
Looping_method: enables one or more base_stage(s), base_stage_sequence(s) or
task(s) to be repeated. There are three ways of controlling the numbers of repeats and
these can be combined:
1. Repeat_count: repeat a specified number of times (FOR NEXT);
2. Repeat_until: repeat until a test condition is met (DO UNTIL ENDDO;
3. Repeat_while: repeat while a test condition remains true (DO WHILE
ENDDO).
Concurrent_methods: gives a group of base_stage(s), base_stage_sequence(s) or
task(s) to be carried out during the time it takes to do the longest.

Together these provide a capability not unlike a programming language so that tasks can be
structured flexibly, and tracked and presented with IETM style functionality.
Product Instance
A product_instance is the physical realization, through the manufacturing process, of a
product_physical_design. In this paragraph, the term product_instance refers to a specific
physical object (e.g., Helicopter with tail number 97-01).
Some detailed requirements for product_instance are the following:

A product_instance is the physical realization of zero or one product_design. The

relationship between product_instance and design is optional since it will not always
be possible or necessary to establish this relationship;
A product_instance is owned by exactly one organization at a given point in time.
Ownership may change over time during the life-cycle. The capability to associate a
date and time with an ownership change and to maintain history of ownership shall be
provided;
A product_instance is manufactured by one or more organizations;

K-55

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
A product_instance is supplied (sold?) by one or more organizations
The combination product_instance identification and the assigning organization
identification will uniquely define the product_instance;
A product_instance may have a serial number that enables to distinguish it from other
product_instance(s) based on the same design;
A product_instance may have a lot or batch number that enables identification of a
group of units of the same design which are manufactured or assembled by one
producer under uniform conditions and which are expected to function in the same
manner. A block identifier may be assigned to designate a quantity of consecutive
production of product_instance(s) which will have similar characteristics;
A product_instance may have both a serial number and a lot number. At least one of
the two is necessary to identify the product_instance. If both are assigned, a
correlation of serial numbers and lot numbers is to be maintained;
The capability to assign additional customer defined identifiers should be provided. If
multiple identifiers are assigned, their correlation is to be maintained;
A product_instance may be categorized in classes of product instance. A class of
product_instance(s) may in turn be organized in a class hierarchy;
Possible classes should be defined. Class of product_instance may include role,
function and condition state (e.g., in repair, spare parts).
A product_instance structure may be the assembly of other product_instance(s). As a
minimum, a product instance structure should include the component
product_instance identification.
A product_instance structure may be subject to changes due to a configuration variant
or replacement of defective items. The old components (predecessors) and the new
components (successors) shall be identified. The capability to associate a date, time
and organization responsible for the change with each change implementation and to
maintain history and rationale of changes shall be provided;
Product_instance structure changes due to configuration variant shall be referenced
by Configuration Change entities such as change_request, implementation directive
and applied_solution;
A product_instance may be controlled by zero, one or many organizations at a given
point in time;
Control of a product_instance may have different forms (e.g., operational, logistics,
storage, etc.). There is exactly one controlling organization associated with each
control form at a given point in time;
Product_instance control may change over time during life-cycle. The capability to
associate a date and time with each transfer of control and to maintain history of
control shall be provided;
A product_instance exists at one location at a given point in time. It may be moved
from one location to another. The capability to associate a date and time with each
change of location and to maintain history of location change shall be provided;
A product_instance is characterized by the properties defined for the related
product_design;

K-56

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
In addition, a product_instance is characterized by zero, one or more actual
characteristics that are either measured from or assigned to the object. Qualifiers
(e.g., calculated, measured) may be applicable to characteristics.
Product_instance characteristics may be organized in classes. A class of product
instance characteristics may, in turn, be part of a class hierarchy;
Product_instance characteristics may be subtyped according to their representation.
Possible subtypes are:
1. Narrative: described by a textual description;
2. Quantified: defined by a measure and a unit of measure;
3. Point in time: defined by a date and time;
4. Period: defined by a time measure.
The capability to maintain product_instance(s) maintenance history and operational
history shall be provided:
1. Maintenance history may include date, type, responsible person/organization;
2. Operational history may include running hours, flight hours, shell fired;
A product_instance may be used as the alternate for another;
A product_instance operates in one scenario at a given point in time. This relates to
the information_objects and tasks defined for that scenario (e.g., maintenance tasks in
desert operations);
Zero, one or many actual functionality may be related to a product_instance.

The diagram in Figure 11 is a high level model that covers most of the above requirements.

K-57

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
product_
instance_
characteristics
classification_of_
class_of_product_
instance

product_instance_
characteristics_
assignment

class_of_product_
instance_
characteristics

classification_of_
class_of_
characteristics

1,3
characteristics_
representation

class_of_product_
instance

product_design

location

product_
operating_
scenario

classification_of_
product_instance

product_instance

product_
instance_
identification
organization

product_
instance_
ownership

product_concept

product_
instance_
control

product_instance_
relationship

product_
instance_
assembly

product_
instance_
succession

product_
instance_
collection

product_
instance_
alternative

Figure 11 - Product_instance High Level Model

Product_instance(s) have a number of relationships with organizations; these include
identification, ownership, and control. Ownership relationship is the easiest to understand.
In this model, an ownership change (e.g., the action of selling) is covered by recording a
new ownership relationship and setting the end effectivity for the previous ownership. The
current ownership is identified by the relationship that has a date for a start effectivity and
has a blank field (empty date) for the end effectivity.
This concept of start effectivity and end effectivity is not shown in the high level model in
Figure 11 but most of the above relationships make use of it.
A product_instance may relate to another product_instance. A typical relationship is the
product_instance_assembly that defines a parent-child relationship between two
product_instance(s) in an assembly structure. This relationship is used to describe, for
example, that the Accelerometer with Serial Number 100267 is part of the Guidance Set
with Serial Number 0982701 which is mounted on the SS-01 Missile with the Serial
Number 003982-45.

K-58

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
The product_instance_succession relationship identifies that one product_instance
(predecessor) has been replaced by another product_instance (successor) for an identified
reason. This entity may communicate information such as that the Accelerometer with
Serial Number 100267 replaced, on 09 July 1998, the Accelerometer with Serial Number
100208 because of an out of tolerance reading during the preventive electronic test.
A product_instance may be classified. This classification should not replicate information
already defined in the product_design classification or product_design properties. The fact,
for example, that the ETS with Serial Number 018992 is an M09 Electronic Test Equipment
used to check the SS-01 Missile Guidance Set is information already available through the
relationship to the product_design schema. A class of product_instance(s) could be, for
example, the class in Repair. This would give the capability to query the database and
derive the list of product_instance(s) that are under repair. In any case, the possible
product_instance classes should be constrained in an Agreement of Common Understanding
between the partners sharing this information.
A product_instance has characteristics.
It is important to distinguish between
product_design properties and product_instance characteristics. For example, the fact that
the size of the ETS with Serial Number 018992 is 30x20x20 +/- .05 cm. is a property of
product_design not of product_instance: in fact all M09 Electronic Test Equipments have
the same size. A product_instance characteristic would describe, for example, that the ETS
with Serial Number 018992 is painted in red for a particular user defined color coding.
There is a requirement to support forward maintenance schedules. For example, lets
assume that the Support Engineering analysis identified a specific calibration task to be
performed every 6 months on the M09 Electronic Test Equipment. This information is part
of the AS DESIGNED view of the product. Data available for the ETS with Serial Number
018992 (AS MAINTANED view) indicates to us that it was last calibrated on 30 June 1998.
It is therefore possible to schedule the next calibration of ETS M09 S.N. 018992 for the end
of December 1998.
Configuration Management
Configuration Management applies to a wide variety of data objects. From a life-cycle
perspective, the configuration management addresses product requirements, product design,
specific physical instance, and their relationships.
Different life-cycle organizations may have different views over what configuration items
they need to manage.
For example:

The user may decide that he will control configuration of product_instance(s) while
the product_design configuration control will be the responsibility of the equipment
supplier;

K-59

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
The main contractor may decide not to maintain configuration control of items
supplied by a subcontractor.

In any case, a standardized interface is needed to exchange consistently configuration

information across different users of the system.
Configuration Management essentially deals with (1) Configuration Identification and (2)
Configuration Change.
Configuration Identification (CI)
The subject of CI is the identification of items, the composition of which is to be managed.
The item to be managed is specified as a Configuration Item. It is usually under control of
the organization that does Configuration Management.
The identification of the Configuration Items is dependent on viewpoints.
The User Perspective
The Configuration Items from the user perspective are the product_instance(s), End Item)
usually identified by a serial number, and their main Components also normally identified
by serial numbers. Whether to consider particular Parts as Configuration Items is a user
decision.
Configuration Identification from the user perspective is achieved at three
different levels:
At the atomic level, Components and Parts should be identified by the manufacturers
identification and a unique identifier assigned by the manufacturer to differentiate between
units of product (Serial Number) or between groups of product (Lot Number). If additional
user identifiers are defined, correlation between them should be maintained.
At the assembly level, the product_instance structure should be uniquely identified by the
top element identifier, e.g., End Item or Component, by the identification of all atomic
elements that are used in the assembly and by the relationships between them.
At the macro level, product_instance which are Configuration Items should be
unambiguously linked to the AS DESIGNED and to the AS REQUIRED views of the
product (see figure)

K-60

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
Organization ID

GC-991
GC-082
GC-076
GC-354

AS-REQUIRED

AS-MANUFACTURED

AS-DESIGNED

Truck Req.
RN-01

Tech Data

Truck
PN -011

Truck
SN-4030

Support Data

AS-USED

Truck
UI-3210

RN-11
RN-12

Engine
PN-02950

Engine Req.
RN-110

Chassis
PN-02398

Engine
SN-33030

Tech Data

Tech Data

Support Data

Support Data
Tech Data

Truck
PN -012

Support Data

Engine Req.
RN-115
RN-1151

Engine
PN-02960

Chassis
PN-02398

Tech Data

Tech Data

Support Data

Support Data

Chassis
SN-00631

Engine
SN-00323

Chassis
SN-00340

Engine
SN-54890

Chassis
SN-00631

Truck
UI-3212

Truck
SN-3908

RN-1152
RN-1153

Engine
SN-54890

Engine
SN-33030
Truck
UI-3211

Truck
SN-3907

RN-1101
RN-1102

Chassis
SN-00340

Chassis
SN-9001

Engine
NSN-2219

Chassis
SN-001

RN : Requirement Number (assigned by the User)

SN: Serial Number (assigned by the Design Authority)
PN: Part Number ( assigned by the Manufacturer)
UI : User Identifier (assigned by the User)
GC: Organization Cage Code

Configuration Identification: The User Perspective

In the above figure, the Truck with Plate Number UI-3210 (user identifier) will be identified
by its primary key and by the foreign keys inherited from the parent data entities. The
complete identifier would be:
GC-991.RN-01.GC-082.PN-011.GC-354.SN-4030.GC-076.UI-3210

The Engine mounted on Truck with Plate Number UI-3212 has a NATO Stock Number as
user defined ID. In this case its completed identifier would be:
GC-991.RN115.GC-082.PN-02960.GC-354.SN-00323.GC-076.NSN-2219

The Designer Perspective

To be developed

K-61

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
Configuration Change
Change Control Basics
A need for change to the baseline configuration may arise from:

An enhancement: a new or improved product_requirement;

A discrepancy: product_instance(s) based on the same design that fails to meet one or
more product_requirement. A discrepancy may be a functional design, physical
design or a support design discrepancy;
A mission need: a product_instance that is reconfigured, in one of the permissible
configurations, for a mission;
A repair activity: a product_instance defective component is replaced by a spare part
(the product_instance structure is changed).

The configuration change activity results in the creation of new data instances, such as new
part/assembly identifications and new relationships. Diagram in Figure 12 illustrates, for
each of the above triggers for change, the product objects that are affected.

ENHANCEMENT
FUNCTIONAL DESIGN DISCREPANCY
PHYSICAL DESIGN DISCREPANCY
SUPPORT DESIGN DISCREPANCY
MISSION NEED
REPAIR ACTIVITY

functional

physical

product_requirement

support
product_instance

product_design

Figure 12 Product Objects Affected by Different Change Triggers

For example:

An enhancement may trigger the creation of new instances of product_requirement,

product_design and product_instance;
A support discrepancy may result in new support design data and new
product_instance/product_design relationships;

K-62

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
A configuration change for a mission need may create a new product_instance
structure but would not affect product_requirement and product_design.

Change Process
The key components of configuration change are: (1) request, (2) implementation directive,
(3) actual resolution.
The following are some data requirements to support the change process:

The change process normally starts with a request that could be either a request for
initial issue or a change request;
A change request may be either a request for enhancement or a request to correct or
accept a discrepancy;
A request for enhancement may be triggered by a new, user defined usage_scenario
or a new user product_requirement.
A request is submitted by an organization at a certain point in time (date and time);
The requesting organization assigns an identifier to the request. The identifier is to be
unique within the organization domain. The combination of the requesting
organization identifier and the request identifier will uniquely define the request;
The request identifies either the baseline product_concept, product_requirement,
product_design and/or product_instance that are impacted by the request;
An initial issue request should address a product_concept and its product_requirement
baseline;
An enhancement related change request should address a product_requirement or
product_design and may address a product_instance baseline;
A discrepancy related change request should address either a product_design or a
product_instance baseline;
A discrepancy related change request should include a narrative identifying the reason
how and why the non-conformance occurred and the detection method that was used
to determine the anomaly;
A request may be referenced by zero, one or many approvals. The approval related
information includes: (a) approval status; (b) approval level; (c) date and time of
approval; (d) approval organization and organization role; (e) relationship with other
approvals;
An approved request may be referenced by zero, one or many
implementation_directive;
An implementation_directive describes the resolution applied to the related request. It
may include description of tasks, manpower, facilities, parts, kits, support equipment,
money needed to apply the actual resolution. It also identifies the organization
responsible for applying the actual resolution and the timetable for finalization;
An implementation_directive may address one or many approved requests;
An implementation_directive is prepared by an organization at a certain point in time;
The combination of the implementation_directive identifier and the organization

K-63

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
identifier of the organization assigning the implementation_directive identifier will
uniquely define the implementation_directive;
An implementation_directive may impact different configuration baseline items from
those identified in the request (see point 6 above);
Implementation_directive(s) may be classified, decomposed and aggregated;
An implementation_directive may be referenced by zero, one or many approvals. The
approval related information are those listed at point 11 above;
An approved implementation_directive may be referenced by zero, one or many
actual_resolution;
An actual_resolution may address one approved implementation directive;
From the information management perspective, an actual_resolution results in the
creation of new data instances (e.g., new design version, new product_instance
structure, new relationships between product views, etc.);
An actual_resolution is applied by a responsible organization;
An actual_resolution is finalized at a certain point in time;
An actual_resolution may be referenced by zero or one approval. The approval related
information are those listed at point 11 above;

Most of the above requirements are addressed in the high level model in Figure 13.
product_
concept

product_
requirement

product_
design

product_
instance

target_select

request_
directive_
relationship

(ABS)
request

implementation_
directive

directive_
resolution_
relationship

identifier
initial_
issue

(ABS)
change_
request

approval

organization
enhancement

(ABS)
configurantion_
change _item

label
date _and_
time

discrepancy
text _select

Figure 13 High level diagram for Change Control

K-64

actual_
resolution

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
Other Issues to Consider
Supportability Characteristics
Required
Actual
Predicted (by whom)
Calculated (by whom)
Spare Analysis
Spare related information includes:

Items of supply (a class product_physical_design instances);

Initial procurement or Spare Specification, e.g., how many and where (a sub-set of
items of supply with quantity and level of allocation)
Alternative identification (product_physical_design alternatives);
Production lead time (product_physical_design property);
Supplier information (product_physical_design property);
Unit of measure (product_physical_design property);
Price (product_physical_design property);
Pipe-line time (product_physical_design property);
Shelf life (product_physical_design property).
Kits/Groups
Supply quantities

Packaging
Package (a class of product_physical_design instance);
Package physical characteristics (product_physical_design property);
Size;
Weight;
Geometry/dimensions;
Stacking requirements;
Protection;
Marking;
Safety/hazard;
Package Identifier and Label (product_physical_design identification);
Package Content (product_physical_design collection);
Handling
Handling equipment (a class of product_physical_design instance);
Handling instructions (task description);
Safety and security during handling (task advisory_stage description).
Emergency actions.
Storage

K-65

PG Viking Through Life Information Management Plan

Appendix D: Product Definition
Type of storage
Permissible Storage condition (temperature, humidity)
Storage methods (stacking and distances);
In-storage maintenance;
Safety and security during storage;
Emergency actions.
Transport
Type of carrier and carrier characteristics;
Transportation methods per carrier;
Safety/Hazard during transport;
Tie down procedure (task description);
Emergency actions during transport;
In-transport maintenance

K-66

PG Viking Through Life Information Management Plan

Appendix E: Information Management Responsibilities
Areas of responsibility: Information ownership
Legal issues for information
Publishing of information
Information procurement
The buyers rights to use and process the information
Information accuracy
Usability of information
Support system, services and infrastructure issues
Information Ownership
The information owner is the organization that owns the intellectual property rights (IPR)
for the information content. The Information owner can sell out all or some of his IPR to
the information content. It will be a contractual issue to define the owner of the IPR taking
in consideration the life-cycle perspective. For the Viking System the Program Managers
Office will act as the information owner for all Through Life information defined in this
document. The level of detail of information belonging to PMO will be determined at the
first contract, and will be subject to change over time.
Legal Issues for Information
In the contract the IPR for both the seller and buyers rights and responsibilities to the
information must be defined. It must also ensure compliance with national laws regarding,
IPR, Information legal reliability (urkund), information archiving, security and public
access to information.
Publishing of Information
Publishing of information means that an organization gives other peoples than the creators
access to a defined instance of information with a declared status. The contract must ensure
that this will be done buy a defined audit and publishing process. It is the responsibility of
the organizations using the published information to ensure that these organization
personnel only use proper published information in compliance with the rules for the
specific instance of information. The information can be updated, integrated with other
information, reconfigured and reused down to the smallest defined information
configuration item, but not below.
Information Procurement
The information buyer is the organization that which to have some kind of access to defined
information owned of some other organization. It is a contractual issue to define the kind of
access, services and performances that will be sufficient. It can be defined in terms of:

Agreements regarding Intellectual Propriety Rights

Procedures for handling product-safety responsibilities
Information services to establish the ordered performances

K-67

PG Viking Through Life Information Management Plan

Appendix E: Information Management Responsibilities
Procedures for delivery of or access to information
Delivery time, place, frequency, capacity, endurance for commitment (life time)
Quality requirements

The Buyers Rights to Use and Process the Information

The purpose of the buyers information processing is to adapt the information to the own
information management system, to integrate the information with information from other
information sources and to adapt the information to his target groups. The limits for this
must be regulated in the contract. To ensure the correct processing of information it is
important to evaluate both the sellers and buyers organizations capability to manage
information in terms of management, personnel skills, processes and support systems.
Information Accuracy
The information accuracy must be defined on the basis of the needs from the processes were
it will be used. It is the responsibility for the acting director in the actual process to decide if
and in which way the information can be used.
Usability of Information
The information usability must be defined on the basis of the needs from the actors in
processes were it will be used. It is the responsibility for the acting director in the actual
process to the minimum level of usability.

K-68

APPENDIX L: PMCMS ENABLING EFFECTIVE TEAMS THROUGH THE USE OF

INTEGRATED DATA ENVIRONMENTS

Enabling Effective Teams

Through the Use of
Integrated Data Environments
Ms. Nancy A. Moulton, PMP
Project Managers Office, Strategic and Theater Command and Control Systems

Abstract
How many of us today are members of some type of Integrated Product Team (IPT)? How many
of us are members of more than one? How many of us feel we are over loaded with the
administrative burden that keeping all member informed places on us? How many of us wish
our IPT could operate more effectively? Peter Drucker said that effectiveness is the foundation
for success. He also said effectiveness is doing the right things. Leadership has also been
defined as doing the right things. In this paper, I will present my ideas on how integrated data
environments can be coupled with teamwork and used to do the right things to enable the teams
we participate in to become more effective.
1. Characteristics of an IDE
As with every new concept in government, it seems different people define the same term
different ways. IDE is no exception. Therefore, to clarify what the IDE looks like, Ive included
the following list of characteristics and examples to enable us to gain a common understanding.

Shared information: create once, maintain at the source, use throughout the life-cycle
All stakeholders have access to data at the right time and place
Greater IPT efficiency is enabled through work flow, on demand data is accessed through
a common operating environment
Automated configuration management process is integrated with acquisition and
sustainment community data requirements
Data management system ensures timely, accurate control
Single work station access to distributed data
Delivery-in-Place method for CDRL data
Policies exist and are followed concerning how to treat data as corporate assets, integrate
it and maintain it

In this kind of environment information is created electronically, and is no longer printed out for
signature. No longer sending hard copy only to be received and re-entered once again into the
recipients computer system. For those of you who use email systems extensively, you would no
longer send attachments to lists of people, constrained by bandwidth and sometimes bringing
down the server that receives multiple copies of the same huge file. Distribution of data is
eliminated, providing access to the data as soon as it is available to all parties at once with an
access time of seconds instead of days or weeks, without incurring any transportation costs or
printing costs. Instead of endless email tennis matches, where we bounce messages back and
forth until someone decides to take action, a work flow tool is provided to more effectively send
the task to action officers, based on the process and task descriptions assigned. All data and
tools needed for research and resolution of the problem are immediately available to the user on
the users desktop. IDE eliminates the need for special terminals used to get into each database,

L-1

sometimes located in special rooms in far away buildings. For product data, configuration
management is central to and integrated with operations of both acquisition and sustainment
communities. The data management system ensures integrity of data and control, to ensure the
right information gets to the right person at the right time. IDE enables delivery-in-place as
described in the DoD 5000 series directives, for delivering contract data to the government. This
environment can reduce CDRLs almost entirely. In the IDE project implemented by the Project
Manager for Combat Mobility Systems (PM CMS), the number of CDRLs went from over 230
to 18 across four major contracts. Thats a 92% improvement! The data was provided through
working relationships in the IPTs and shared via the Delivery In Place (DIP) server, so CDRLs
were no longer needed. However, an IDE will not help a poorly run organization if it continues
to be poorly run. Policies must be established and enforced to ensure teams are doing the right
things to use the IDE effectively. Processes should not be merely automated, they should be
innovated to take advantage of the power of the new environment and tools is offers.
2. Current Status of Defense System Data
Much of the data in defense systems today is not available in a timely manner. It is either
walking around in someones head, forgotten about in a file somewhere, or locked on someones
hard drive. Corporate knowledge is often tied to individuals. Is is not is frustrating to be the one
on Friday afternoon who has to respond to a budget what if drill when everyone else is off who
would have had that last information paper that was submitted on their computer? Now you
have to come up with something up in a hurry and hope it does not contradict what your team
submitted last time. It would be great to have a library of information that can easily be searched
to find all the budget related documents that were ever written on your program? IDE can
provide such off the shelf tools to enable teams to share information more effectively, so that you
can find it when you need it. Today data structures inhibit sharing of information and valuable
data.
Even when PM CMS standardized on one office software package for routine
correspondence, different versions made it difficult. The life span of data is too short today.
Many of our processes repeat themselves over and over. People want the same information over
and over, maybe with a slightly different twist. The mountains of data created early in product
life-cycles is somehow lost when the next crew cannot find the digital copy and it must be recreated. In the past, we have created boundaries and built walls that inhibit information sharing.
Today through the use of IPTs we have seen some progress in removing the organizational
barriers that exist, however, we must ensure the information system architecture also
accommodates an open flow of information across those boundaries. In addition, you would be
amazed at how different each persons perspective is pertaining to how a process is
accomplished. Often very few, if any understand the whole process. Those that thought they
did, find that what is actually happening is not even close to what they thought was happening.
3. Information sharing enables teams to work better
In an IPT environment the IPT has proponency for the CDRL data that is delivered. In an IDE
the distribution, administration and feedback on that data is greatly simplified. The data is
placed on the server, the workflow is launched to team members asking them to comment on it,
and the data is available through a folder that appears on each team members desktop.
Delivery-in-place eliminates hours of duplication and distribution that is done in a paper world.
If you operate in an email world, it eliminates the need for multiple messages, overcomes the
difficulty with sending large files over the Internet and through email systems, and prevents the

L-2

potential for email system failure or significant degradation in performance when sending large
attachments to several people on the same server all at once. The folder that now appears on the
desktop may contain a read-only master copy and a copy for editing, for example. Using off the
shelf standard commercial software tools comments from each member are added to the copy for
editing. All comments appear in a single document and all team members can see everyone
elses comments. Once everyone agrees on the final edit, the document becomes the approved
version and supersedes the previous. Oh, if you are wondering how you clean up the mess of
mark ups from everyone who has left comments, one click of the mouse reformats the document
and removes all the text marked for deletion. These tools offer many options and can be
employed many different ways. The key here is to use integrated off-the-shelf capability to
enhance team performance, not to degrade it. Some other ways the IDE can improve
collaborative productivity are listed below.

Share more information to ensure the best-informed decisions can be made by the team or
enables them to use a consistent decision baseline. This is key to empowering the team
to take action.
Provide greater understanding and visibility into the process, eliminate black holes and
wait states.
Maintain life-cycle consistency, decision traceability, corporate memory, and
buy/maintain only the information that is needed.

4. Information Sharing Outcomes

Using an IDE enhances both individual and team performance by reducing cycle times for
actions to be accomplished, reduces uncertainty, enhances understanding, increases decision
options, reduces downstream discrepancies, supports a task or product driven organizational
structure, enables process innovations and is flexible enough to respond quickly to the ever
changing business environment in which we operate.
Some additional benefits that the IDE has demonstrated are listed below.

Enables acquisition reform initiatives

Facilitates Electronic Delivery of Data
Enhances IPT communication
Provides coordination of product information
Makes program documents/briefings available, reducing requests for information
Ensures all team members use the current revision, reducing errors
Enables parallel processes, more concurrent engineering and acquisition streamlining
Eliminates lag time between drawing approval and distribution

5. Return on Investment
Enterprises that join in partnership to form and use an integrated data environment (IDE) should
baseline the following metrics prior to implementation and can expect great improvement in
these areas as a result of an effective implementation.

Reduced cost of development, acquisition and support of weapon systems

Reduced cycle times for system development, production and development of support
L-3

Improved quality of systems and system support through sharing of current and accurate
data
Improved weapon system life-cycle management processes

Through reading the Coopers and Lybrand study on IDE implementations, 1996 and the book
Process Innovation by Davenport. I have observed the following statistics. Typically when a
company implements an improved team work approach alone the results range from 10 to 50
percent improvement. However, when you combine team empowerment with the power of the
IDE as the force multiplier and innovate the processes instead of improving them, the result is
anywhere from 50 to 90 percent improvement in most cases. The variation in the ranges seems
to come down to how effective the leadership was in implementing the overall strategy.
6. Summary
DoD and industry now have experience and guidance available to assist leaders wanting to
implement IDE. DoD information can be found at http:\\www.acq.osd.mil/cals, which has links
to other sites with additional information. Of particular interest may be an IDE Handbook that is
available on the Web and on the Acquisition Deskbook CD ROM. Two other good sources of
information are Process Innovation by Davenport, which describes the risks involved in
innovating, many success stories as well as failures and outlines what to expect. And most
significantly for me is the book by John Kotter and Harvard Business Press titled Leading
Change. Leading Change is an excellent culmination learned into a of best practice guide.
The process for leading lasting change outlined in his book held true for me when I, together
with Jack Paul, implemented the first IDE for the Army, which we affectionately called the
Paperless PM. The book also serves as an outstanding desk reference.
In closing, Ill leave you with a quote from Albert Einstein The significant problems we face
cannot be solved from the same level we were at when we created them. Operating in an IDE
involves thinking differently about how teams can do business to create less burden and greater
results.
IDE + Team work = High Performance
Ms. Nancy A. Moulton has over twenty years of logistics, acquisition, and project management
experience with the Army. She is currently Chief of the Training, MANPRINT, Fielding and
Support Branch of PM STCCS. She has recently served as IDE Project Manager for OSD and
prior to that led the IDE effort for PM CMS. Ms. Moulton will earn her Masters Degree in
Systems Management with a focus on Information Technology in Oct 97 and has been board
selected as the Project Manager for Light Tactical Vehicles. She will be transitioning to PM
LTV in the spring of 1998.

L-4