; Powerpoint Templates Diagram 076
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Powerpoint Templates Diagram 076

VIEWS: 307 PAGES: 232

Powerpoint Templates Diagram 076 document sample

More Info
  • pg 1
									NATO CALS HANDBOOK
     APPENDICES




       March 1, 2000




             1
                                                 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 Elements ................................................................ 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



                                                                    v
                    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 high-
quality 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 improve ments 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 whene ver
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 'promoter' 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. NATO
should closely liaise with industry.

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 achie ved 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 migrat ion 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 Leade rship

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 the refore
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 require d changes.

In the book “Navigating the Digital Environment: A Program Manager‟s 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 Program‟s 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 Manager‟s 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 manner–in 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 media–text, 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, a nd 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                BUSINESS PROCESSES                                P

             R                                                                  O
                                     GENERIC
             A           (DEVELOP INFORMATION PRODUCT)                          L

              I                                                                  I
                                     SPECIFIC
             N      (e.g. PROPOSAL PREP, PART PROCUREMENT)                      C

             G                                                                   I
                       SUPPORTING CALS ENVIRONMENT                              E

             &                                                                  S
                      I. INFORMATION PROCESSES & TOOLS
                                 CONTROLLED ACESS                               &
             U
                       DATA SHARING AND COLLABORATION
             S
                              DIGITAL DATA EXCHANGE                             S
             E
                           INFORMATION ARCHITECTURE                             T
             R
                         PRODUCT (&OTHER) DATA MGMT                             A
                          USER APPLICATIONS (TECH, BUS)                         N
             S
             U                                                                  D
                                 II. INFRASTRUCTURE                             A
             P
                               TELECOMMUNICATIONS                               R
             P
                          DESKTOP SOFTWARE (e.g. EMAIL,                         D
             O
                         WORD PROCESSOR, SPREADSHEET)
             R                                                                  S
                       HARDWARE AND OPERATING SYS S/W
             T



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 Environme nt
The “Extended Enterprise” is a grouping of individual businesses or organizations that co-
operate 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 locatio ns. 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 data–within appropriate
security constraints–the 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 real-
time 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., ftp–File 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 element–which requires additional development based
on user feedback–contains 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 a ffect
the information deliverable that is the output of the business process. This software may address
data of a technical or a business aspect–e.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 process–the information product or package.

A2.14 Infrastructure Ele ments
There is no definition of “infrastructure” that has a wide consensus. The term as used here
comprises the many elements that address underlying capabilities–often mundane and taken for
granted–that 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. A lso
included is basic electronic mail. Related subjects for additional information include Computer-
Aided 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 non-
proprietary (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 current ly
       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 Ele ments
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 engineer ing
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

                     Table C-1 TLBM Activity Definitions
  Activity Name    Activity                  Activity Definition
                   Number
MANAGE A          A0
DEFENSE
SYSTEM
THROUGH LIFE
ESTABLISH AND     A1          Activities needed to create resource and manage the
CONTROL DS                    organization, or organizations needed to obtain, use, and
PROGRAM TL                    dispose of the DS over its life-cycle.
ESTABLISH AND     A11         This activity takes the VMN, the Business directives, the
CONTROL THE                   Usage and Support Policy and any recommendations for
REQUIREMENT                   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 LC        A12         Develop and implement an integrated suite of policies and
STRATEGIES AND                strategies for managing the DS over its life-cycle. These
POLICY                        strategies will shape the development of the program
                              organization and establish the framework within which the
                              Program Directives are developed.
DEFINE LC         A121        This activity establishes a consistent and integrated set of
STRATEGY AND                  high- level policies and strategies to guide the management
POLICIES                      of the DS program over its full life-cycle.
DEFINE            A122        The approach to be taken in acquiring a service or DS
ACQUISITION                   component, initially and for re-supply. It should cover the
STRATEGY                      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
DEFINE RISK       A123        Development of the program approach to identifying,
STRATEGY                      assessing, and managing risk of failure to comply fully
                              with the VMN or Business Directives.
DEVELOP ILS       A124        Develop a strategy and plan to show how ILS will be
STRATEGY                      implemented for the particular DS over its full life-cycle.



                                       C-1
  Activity Name    Activity                       Activity Definition
                   Number
DEVELOP CM        A125        Develop a strategy and plan to show how CM will be
STRATEGY AND                  implemented for the particular DS over its full life-cycle.
PLAN
DEVELOP QA        A126        Define the actions required to ensure systematic
STRATEGY AND                  approaches are taken to the integrated concurrent design,
PLANS                         manufacture, and support of the DS and the related
                              processes.
DEVELOP CALS      A127        An assessment of the business and CALS Environment
STRATEGY AND                  facing the DS program, development of the program goals
PLAN                          for CALS and an assessment of the costs, risks, and
                              benefits of the options of CALS- implementation.
ESTABLISH and     A13         Set up and run an organization capable of delivering an
RUN the DS                    acceptable DS, that meets the Current Requirement.
ORGANIZATION
MANAGE            A131        Define the tasks to be performed and services to be
PROGRAM                       provided, in response to the Current Requirement and
SCHEDULE                      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.”)
ESTABLISH         A132        This activity establishes how responsibility for the various
ROLES and                     program tasks is to be allocated over the life-cycle,
RELATIONSHIPS                 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).
PLACE AND         A133        Action needed to place, operate and close contractual
MANAGE                        agreements required by the DS program. It includes
CONTRACTS                     generation of the contract requirements and the
                              development and operation of payment and incentive
                              arrangements.




                                       C-2
  Activity Name    Activity                       Activity Definition
                   Number
DEVELOP           A1331       The process of programming, controlling, documenting,
CONTRACT                      and implementing the specific requirements levied by the
STRATEGY                      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.
ISSUE             A1332       The specific contractual solicitation or tender is prepared
SOLICITATION                  and Issued, including the Statement of Work, the
                              Evaluation Criteria, and the Contract Deliverables.
ASSESS            A1333       This activity encompasses all actions in assessing the
PROPOSALS                     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.
RUN CONTRACT      A1334       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.
MANAGE DS LC      A134        Acquire, allocate, and account for the funds needed to
FUNDING                       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.
MANAGE HUMAN      A135        Plan, organize, monitor and control, the provision of
RESOURCES                     human resources for DS program life-cycle.
MANAGE DS         A136        The act of constantly monitoring and updating both the
INFORMATION                   technical data requirements and the database support
                              structure that provides the through- life support the Defense
                              System.
DEVELOP IM        A1361       Define the program Information and IT- infrastructure
PLAN                          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    Activity                        Activity Definition
                   Number
ESTABLISH AND     A1362       Design, acquisition, deployment, and use of a Shared Data
OPERATE                       Environment for the DS. (See NCOPS). Those activities
PROGRAM SDE                   include analysis, acquisition, test, delivery, operation, or
                              management of hardware, software, and communications
                              systems.
PROVIDE           A1363       The activities required to support users in entering,
INFORMATION                   maintaining, and using DS information stored in the SDE.
SERVICES
COMPARE           A14         The comparison of actual system state and performance
ACTUAL SYSTEM                 with that required by the Current Requirement, Business
STATE AND                     Directives, and Operational Program to identify the need
PERFORMANCE                   for changes. This comparison addresses both technical and
WITH REQUIRED                 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).
OBTAIN DS         A2          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    Activity                       Activity Definition
                   Number
DEVELOP DS        A21         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.
DEVELOP           A211        The action taken to review the operational threat and
CONCEPTUAL                    Mission Need to identify and evaluate potential alternative
OPTIONS                       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.
DEFINE DS         A212        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.
ENGINEERING       A213        The detailed engineering design activities to arrive at a
DESIGN                        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.
FAILURE           A214        Analyze failure modes, effects, and criticality to define
ANALYSIS                      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    Activity                        Activity Definition
                   Number
DESIGN THE        A215        Create the procedures and data needed to provide an
SUPPORT                       optimized support capability for the DS, to deliver the
SYSTEM                        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.
PREDICT LIFE-     A216        Task of predicting the expected performance of the DS in
CYCLE                         regards to all aspects of the Current Requirement and
PERFORMANCE                   Business Directives. This includes prediction of system
                              capability, life, availability, readiness, and life-cycle cost.




                                       C-6
  Activity Name    Activity                       Activity Definition
                   Number
PRODUCE DS        A22         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.
CONDUCT           A23         Process of measuring the performance of all DS
TESTING                       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).
DEPLOY DS         A24         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.
SUPPORT THE       A3
USE of the DS
PLAN SUPPORT      A31         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.
STORE             A32         The storage and issue as required of items needed for
TRANSPORT AND                 maintenance or to support the DS on operational use.
ISSUE ITEMS




                                       C-7
  Activity Name    Activity                       Activity Definition
                   Number
MAINTAIN,         A33         Perform the work needed to restore the DS to the condition
UPDATE AND                    required for the next intended operation (except for O&S
PROVIDE                       tasks), by diagnosing, repairing, testing, and calibration the
FEEDBACK                      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.
O&S TASKS         A34         (Non maintenance) activities needed to prepare the system
                              for operations e.g., fuelling, tow from hanger, empty waste
                              tanks etc.
MANAGE            A35         Activities needed to sustain the “special to type” facilities
FACILITIES                    and tools in a fit for use condition.
TRAIN SUPPORT     A36         [IEEE Std 1220-1994] The tasks, actions, and activities to
STAFF                         achieve and maintain the knowledge and skill level
                              necessary to efficiently and effectively perform operations,
                              support, and disposal.
CONDUCT           A37         The evaluation of a DS operational and support capabilities
EVALUATIONS                   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.
DISPOSE or        A4          Activities related with the retired Defense Systems and DS
RECYCLE                       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

                                     Table D-2 ICOM Report
 Arrow Name                                        Arrow Definition
Acq Strat          An acquisition strategy details the intended approach to obtaining the Defense
                   System capability, initially and for upgrades.
Activities to be   Definition of the tasks to be undertaken, and services to be provided by
contracted         contract.
Allocated          Allocation of available manpower resources to organizational units and plans
Manpower           for providing trained people
As-built           The full configuration definition of each DS post production or refurbishment.
Config
As- maint          The configuration definition of the DS following maintenance. This definition
Config             would also include the reporting of configuration problems and anomalies.
Available          Actual funds, available to the DS program, after approval and release by the
Funding            Financial Management function.
Budget Req         Defense System specific requests for funding, in the form of budget
                   requirement requests to the external authorities responsible for the program
                   Business Directives.
Business           Program specific business requirements and constraints placed on the LC-
Directives         owner 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.
CALS Strategy      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.
Change Impact      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.
Change             A proposed change to the DS or the DS program to correct a state or
Proposal           performance shortfall. This may include a request from within the DS
                   program to change the requirement itself.
CM Strategy        Strategy, Policies and plans for achieving adequate control of DS
                   configuration through life
Contract Dir.      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.
Contract           The information requirements to be included in DS program contracts.
Information
Req
Contract           details the intended approach to acquiring goods and services from industry
Strategy           over the Life-cycle


                                                C-9
 Arrow Name                                       Arrow Definition
Contracts and    Contracts and/or Invitations to Tender for the provision of goods or services to
ITTs             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 and    Contracts or Request for action from organizations or entities not directly
Requests         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.
Core Product     Information to define and describe items, components, assemblies and systems
Data             to the level needed by those who will operate and support the system in-
                 service. 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 Req      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.
Def. Pol. and    Defense Policy and Standards Defense Standards, Policies and Directives
Stds             applicable to the DS program.
Disposed Items   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.
DS Concept       Selected Concept, or Concepts, to be further developed into a full design.
DS Data to       All data relating to the DS required by external authorities. This includes:
Others           reports on achievement v target
DS for           A new DS or component ready for initial deployment.
Deployment
DS needing       The Operational Defense System requiring support, as returned from
support          operations.


                                               C-10
 Arrow Name                                    Arrow Definition
DS ready for     DS ready for Operations
Ops
Eval Def         Evaluation Definition: The criteria and specific manner in which evaluations
                 will take place.
Evaluation       The documented results of an evaluation of a DS
Findings
Existing         Existing Business Information: Data, needed by the LSA activity, from
Business Info    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.
Existing         Facilities Systems Tools
Infrastructure
External Data    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      Feedback fm Maintenance Feedback of information arising from maintenance
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 fm      Feedback from Operators Ops History Survey Results State, Failures,
Ops              Deficiencies Changes made
Financial        Report of the financial implications of the program WBS, including proposed
Implication      changes.
FMECA Data       Description of possible failure modes for the DS, with their likely
                 consequences and frequency of occurrence.
Functional       An arrangement of functions and their sub functions and interfaces (interna l
Architecture     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        Goods and Services from others
Services fm
others
ILS Strategy     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                                      Arrow Definition
IM Plan          Plan to manage information over the LC
In Service       A statement of general utilization intentions for a Defense System including
Goals            reference to national or co-operative logistics and training arrangements.
Information      Provision of Information services which cannot be provided directly through
Services         the SDE itself e.g., archiving, retrieval of historic records, special reports, new
                 applications, new hardware, help desk services etc.
In-Scope Eval    In-Scope Evaluation Findings: Evaluation findings that indicate a requirement
Findings         to change Operational Support Instructions or Operational Support
                 Requirements that do not effect existing system plans or strategies.
Inst to Ops      Instructions to Operators
Invitation to    A formal request for a proposal from a contractor upon which a contract for
Tender           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 RFB    Items for Refurbishment Items removed from operational service and returned
                 for reconditioning or repair
Items for Test   Items removed from for test
Items for Use    Spares and other consumables supplied for incorporation into the main
                 equipment, (this includes the “on board stock” where appropriate)
Laws and Gov     Relevant Laws and regulations from beyond the Defense environment
Policy
LC Strat and     The set of documents which provide the DS program team with policies and
Pol.             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
Maintained DS    DS after completion of the maintenance tasks, awaiting preparation for
                 deployment on mission
Mfr and Rfb      Manufacturing and refurbishment data: information needed to manufacture,
data             refurbish or dispose of the DS and its associated components
Ops Prog         Program of the DS when deployed on operational missions
Org Structure    Organizational Structure of the DS project
Perf Rep         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.
Predicted LCC    Prediction of the expected Life-cycle Cost of the DS
Predicted Perf   Predicted Performance of the DS, in relationship to all aspects of the current
                 requirement




                                              C-12
 Arrow Name                                       Arrow Definition
Prg Dir          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.
Proc Spec        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.”
Program          Plans showing what activities have to be performed when, to meet DS
Schedule         Program requirements.
Program SDE      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.
Program WBS      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 Pers     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.
QA Strategy      Details the intended approach to implementing an integrated systems approach
                 to Quality through the DS life-cycle.
Req Config       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.
Req Feedback     Required Feedback
Requests for     Requests for assistance from or action by parties beyond the control of the DS
Assistance       Life-cycle Owner (e.g., the owners of other DS, the Armed Forces, External
                 training authorities, the Department of Defense [DoD], etc.).
Required Items   The identity, quantity, and required delivery details for purchased items
                 needed to support the use of the DS.
Returned Items   Items for recycling or disposal



                                             C-13
 Arrow Name                                    Arrow Definition
Risk Mgt         Details the requirements and intended approaches management of program
Strategy         risk over the life-cycle.
SDE Req.         Requirement Statement for the Program SDE
Selected         Spares and components obtained for use in support activities.
Contractor
Spares and
Components
Support          Requirements for special-to-type support equipment, tools, training equipment,
Equipment        and facilities required to support the DS.
Requirements
Support Info     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 suppo rt 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.
Support Plan     Instructions (short term) and plans (longer terms) defining the work to be
                 undertaken on specific DS or DS components requiring support.
Test Def         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.
Test Findings    The results of comparing actual results with identified performance,
                 functional, and logistic specifications.
Tools and        The special-to-type tools, test equipment, and facilities created for the DS.
Facs.
Trained People   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.”
Trg Req          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.
Usage and        Constraints, requirements or policy guidance relating to the operation or
Support Policy   support of the DS in service, placed on the program by the known or potential
                 users of the System
Users            The designated user of the proposed system (maintainers, operators,
                 repairmen, commanders, etc.) provided to contribute to, or assess the evolving
                 product and support design.
Validated        A statement based on a mission analysis, identifying in broad outline a
Mission Need     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 o f 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 co nstruct, 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 sa me 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 functionalit y 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 informatio n 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 Imple mentation 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 de velop 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 kind s 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 Docume nts
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 poss ible. 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 it 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                                  LANGUAGE
(HYTIME) (ISO/IEC DRAFT INTERNATIONAL STANDARD 10744)

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 informa tion
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 Curre nt 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 Enhance ments 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 Imple mentation 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 e ven 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 intend ed 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 r ules 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 visua lization.

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 t he
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 Curre nt 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 Imple mentation 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




                           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 suitab le 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 C lass 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 1-
Overview 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 Imple mentation 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. This initial
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
      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 Curre nt 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 Imple mentation 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 Imple mentation 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 Imple mentation Levels
STEP provides a wide variety of levels for system implementatio n. 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 syste ms 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 spec ific 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    MIL-STD-1388-1A          Notice 4        DoD Logistic Support
        [T]                                  To be           Analysis
                    S/S MIL-HDBK-502         cancelled
        Profile     UK DEF STAN 0060         Interim Issue   Application of Integrated
        [E]         Pt 0                     1               Logistic Support (ILS) -
                                                             Profile of MIL-STD-
                                                             1388-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       AECMA 2000M            Revision 3.0     Material Management
        [T]                                                    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 fo llowing 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       AECMA 2000M            Revision 3.0     Material Management
        [T]                                   Chapter 1        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       STANAG 3150            Issue: 1989      Codification of
         [T]                                   Revision:        Equipment - Uniform
                                               5.07.1989        System of Supply
                                                                Classification

         Standard       STANAG 4177            Issue:           Codification of Items of
         [T]                                   21.08.90         Supply - Uniform
                                                                System of Data
                                                                Acquisition
         Manual         ACodP-1                                 NATO Manual on
         [R]                                                    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       AECMA 2000M            Revision 3.0     Material Management
         [E]            Based on               Appendix 3       Integrated Data
                        STANAG 4329                             Processing for Military
                                                                Equipment - Appendix 3
                                                                Bar Coding
         Standard       STANAG 4329            Issue:           NATO Standard Bar
         [T]                                   6.4.1992         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 p rocesses needed
to obtain status information about existing orders.

         Standard       AECMA 2000M          3.0 Chapter 3      Material Management
         [E]                                                    Integrated Data
                                                                Processing for Military
                                                                Equipment




                                               D-21
D7.8 Order Administration Format, Content, and Communications Techniques
         Standard     AECMA 2000M             Revision 3.0    Material Management
         [E]          Based on ISO 9735                       Integrated Data
                      (EDIFACT)                               Processing for Military
                      / EN29735                               Equipment - Appendix 1
                      / DIN16536                              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 EDIFACT-
compliant 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      AECMA 2000M            Revision 3.0    Material Management
         [E]                                                  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       ISO 13584             CD               Industrial Automation -
        [E]                                  ISO TC184        Parts Library
                                             SC4              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 End-
                                                              1995
        Standard                                              NATO Master Cross-
        [T]                                                   Reference List

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   ISO 31        3rd Ed. 1992   Information Processing
[R]                                     Representation of
                                        Quantities and Units
Standard   ISO 639       1988           Information Processing
[R]                                     Coded Representation of
                                        Names of Languages
Standard                 3rd Ed.        Information Technology
[R]        ISO/IEC 646   1991           - ISO 7-Bit Coded
                                        Character Set for
                                        Information Interchange
Standard   ISO 1000      3rd Edition    SI Units and
[R]                      1992           Recommendations for
                                        the Use of Their
                                        Multiples and of Certain
                                        Other Units.
Standard   ISO 3166-1    1997           Information Technology
[R]                                     – Codes for the
                                        Representation of Names
                                        and Countries and Other
                                        Subdivisions. Part I –
                                        Country Names
Standard   ISO 3166-2    1998           Part II – Country
[R]                                     Subdivision Codes
Standard   ISO 3166-3    1999           Part III – Formerly Used
[R]                                     Names of Countries
Standard   ISO 4217      1995           Codes for the
[R]                                     Representation of
                                        Currencies and Funds.
Standard   ISO 6709      1983           Standard Representation
[R]                                     of Latitude, Longitude,
                                        and Altitude for
                                        Geographic Point
                                        Locations.
Standard   ISO 6936      1988           Information Technology
[R]                                     - Character Set
                                        Conversion between ISO
                                        646 and ISO 6937-2 with
                                        CCITT No. 2 (ITA-2).




                         D-24
        Standard       ISO/IEC 8859          Various          Information Technology
        [R]                                                   - 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
        Standard       ISO 8601              1st Ed. 1988     Data Elements and
        [R]                                                   Interchange Formats –
                       ISO/WD 8601           2nd Ed.          Information Interchange
                                                              – Representation of
                                                              Date/Time.
        Standard       ISO/IEC 10646-1       1st Ed. 1993     Information Technology
        [R]                                                   - Universal Multiple
                       ISO/IEC WD            2nd Ed.          Octet Coded Character
                       10646-1                                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      ISO/IEC 8613-1       1994           Information Technology.
        [N]           –                                   Office Documentation
                      ISO/IEC 8613-1       1998           Architecture (ODA) and
                      Cor. 1                              Interchange Format.
                                                          Part 1 – Introduction and
                                                          General Principles
        Standard      ISO/IEC 8613-2       1995           Part 2 – Document
        [N]                                               Structures
                      ISO/IEC 8613-2       1998
                      Cor. 1

                      ISO/IEC 8613-2       1998
                      Cor. 2
        Standard      ISO/IEC 8613-3       1995           Part 3 – Abstract
        [N]                                               Interface for the
                                                          Manipulation of ODA
                                                          Documents.
        Standard      ISO/IEC 8613-4       1994           Part 4 – Document
        [N]                                               Profile.

                      ISO/IEC 8613-4       1998
                      Cor. 1

                      ISO/IEC 8613-4       1998
                      Cor. 2
        Standard      ISO/IEC 8613-5       1994           Part 5 – Open Document
        [N]                                               Interchange Format


                      ISO/IEC 8613-5       1998
                      Cor. 1

                      ISO/IEC 8613-5       1998
                      Cor. 1
        Standard      ISO/IEC 8613-6       1994           Part 6 – Character
        [N]                                               Content Architectures

                      ISO/IEC 8613-6       1998
                      Cor. 1

                      ISO/IEC 8613-6
                      FCD Amd. 1


                                           D-26
Standard   ISO/IEC 8613-7    1994   Part 7 – Raster Graphics
[N]                                 Content Architectures.


           ISO/IEC 8613-7    1998
           Amd. 1

           ISO/IEC 8613-7    1998
           Cor. 1998
Standard   ISO/IEC 8613-8    1994   Part 8 – Geometric
[N]                                 Graphics Content
                                    Architectures.
Standard   ISO/IEC 8613-9    1996   Part 9 – Audio Content
[N]                                 Architectures.

Standard   ISO/IEC 8613-10   1995   Part 10 – Formal
[N]                                 Specifications.

Standard   ISO/IEC 8613-11   1995   Part 11 – Tabular
[N]                                 Structures and Tabular
                                    Layout.
Standard   ISO/IEC 8613-12   1996   Part X12– Identification
[N]                                 of Document Fragments.

Standard   ISO/IEC 8613-14   1997   Part 14 – Temporal
[N]                                 Relationships and Non-
                                    linear Structures.
Standard   ISO 8879          1986   Information Processing -
[R]                                 Text and Office Systems
                                    - Standard Generalized
                                    Markup Language
                                    (SGML)

           ISO 8879 Amd. 1   1988

           ISO 8879 Cor. 1   1996

           ISO 8879 Cor. 2   1999
Standard   ISO 9069          1988   Information Processing -
[R]                                 SGML Support Facilities
                                    - SGML Document
                                    Interchange Format
                                    (SDIF)


                             D-27
Standard   ISO/IEC TR       1988   Information Processing –
[]         9573                    SGML Support Facilities
                                   – Techniques for Using
                                   SGML.
Standard   ISO/IEC TR       1992   Part 11 – Application at
[]         9573-11                 ISO Central Secretariat
                                   for International
                                   Standards and Technical
                                   Reports.
Standard   ISO/IEC TR       1991
[]         9573-13                 Part 13 - Public Entity
                                   Sets for Mathematics and
                                   Science
Standard   ISO/IEC 10179    1996   Information Technology
[E]                                – Processing Languages
                                   - Document Style
                                   Semantics and
                                   Specification Language
                                   (DSSSL)
                                   Scheduled for IS in 1995
Standard   ISO/IEC 8824     1990   Information Technology
[E]                                – Open Systems
                                   Interconnection –
                                   Specification of Abstract
                                   Syntax Notation One
                                   (ASN. 1).
Standard   ISO/IEC 8824-1   1995   Part 1 – Specification of
[E]                                Basic Notation

           ISO/IEC 8824-1   1996   Relative Object
           FCD Amd. 1              Identifiers

           ISO/IEC 882-1    1996   Rules of Extensibility
           Amd. 1

           ISO/IEC 882-1    1996
           Cor. 1

           ISO/IEC 882-1           Semantic Model
           Amd. 2




                            D-28
Standard   ISO/IEC 8824-2   1995   Part 2 – Information
[E]                                Object Specification

           ISO/IEC 8824-2   1995   Semantic Model
           FCD Amd. 1

           ISO/IEC 8824-2   1996   Rules of Extensibility
           Amd. 1
Standard   ISO/IEC 8824-3   1995   Part 3 – Constraint
[E]                                Specification


Standard   ISO/IEC 8824-4   1995   Part 4 – Parameterization
[E]                                of ASN. 1
                                   Specifications

           ISO/IEC 8824-4          Semantic Model
           FCD Amd 1 ASN
           1
Standard   ISO/IEC 8825     1990   Information Technology
[E]                                – Open Systems
                                   Interconnection –
                                   Specification of Basic
                                   Encoding Rules for
                                   Abstract Syntax Notation
                                   One (ASN.1)
Standard   ISO/IEC 8825-1   1995   Part 1 – ASN.1 Encoding
[E]                                Rules: Specification of
                                   Basic Encoding Rules
                                   (BER), Canonical
                                   Encoding Rules (CER),
                                   and Distinguished
                                   Encoding Rules (DER)

           ISO/IEC 8825-1          Relative Object
           FCD Amd. 1              Identifiers

           ISO/IEC 8825-1   1996
           Cor. 1
Standard   ISO/IEC 8825-2   1996   Part 2 – ASN.1 Encoding
[E]                                Rules: Specification of
                                   Packed Encoding Rules
                                   (PER)

           ISO/IEC 8825-2          Relative Object
           FCD Amd. 1              Identifiers



                            D-29
        Standard       ISO/IEC 10180         1995            Information Technology
        [E]                                                  – Processing Languages
                                                             – Standard Page
                                                             Description Language
                                                             (SPDL)
        Profile        MIL-HDBK-             30 Jun 1995     DEPARTMENT OF
        [T]            28001                                 DEFENSE
                                                             APPLICATION OF
                                                             MIL-PRF-28001 USING
                                                             STANDARD
                                                             GENERALIZED
                                                             MARKUP LANGUAGE
                                                             (SGML)

        Handbook       MIL-HDBK-             DRAFT           U.S. Department of
        [T]            SGML                  Published       Defense Application of -
                                             May 1994        SGML.
                       WAS NOT                               Federal Information
                       FOUND                                 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   ISO/IEC 8632 1   1992   Information Technology
[R]                                - Computer Graphics -
                                   Metafile of the storage
                                   and transfer of picture
                                   description information –
                                   Part 1 – Functional
                                   Specification
                                   Rules for Profiles
           ISO/IEC FDIS
           8632
                            1994   Application Structuring
           ISO/IEC 8632-1          Extensions
           Amd. 1
                            1995
           ISO/IEC 8632-1
           Amd. 2

Standard   ISO/IEC 8632-2   1992   Part 2 – Character
[R]                                Encoding

           ISO/IEC 8632-2   1994   Rules for Profiles
           Amd. 1

           ISO/IEC 8632-2
           CD Cor. 1

           ISO/IEC 8632-2   1995   Application Structuring
           Amd. 2                  Extensions
Standard   ISO/IEC 8632-3   1992   Part 3 – Binary Encoding
[R]
           ISO/IEC 8632-3   1994   Rules for Profiles
           Amd. 1

           ISO/IEC 8632-3   1995   Application Structuring
           Amd. 2                  Extensions
Standard   ISO/IEC 8632-4   1999   Part 4 – Clear Text
[R]                                Encoding




                            D-31
Standard   ISO/IEC 9592 - 1   1997   Information Technology
[]                                   – Computer Graphics
                                     and Image Processing -
                                     Programmers
                                     Hierarchical Interactive
                                     Graphics System
                                     (PHIGS) Part 1 –
                                     Functional Description
Standard   ISO/IEC 9592 - 2   1997   Part 2 – Archive File
[]                                   Format

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 –
                                     Programmer‟s
                                     Hierarchical Interactive
                                     Graphics System
                                     (PHIGS) Language
                                     Building
                                     Part 1 – FORTRAN

           ISO/IEC 9593 -1    1995
           Amd. 1

           ISO/IEC 9593 -1    1993
           Cor. 1

           ISO/IEC 9593 -1    1994
           Cor. 2
Standard   ISO/IEC 9593 – 3   1990   Part 3 – ADA
[]
           ISO/IEC 9593 – 3   1994   Incorporation of PHIGS
           Amd. 1                    PLUS

           ISO/IEC 9593 – 3   1993
           Cor. 1

           ISO/IEC 9593 – 3   1994
           Cor. 2




                              D-32
Standard   ISO/IEC 9593 – 4   1991   Part 4 – C
[]
           ISO/IEC 9593 – 4   1994
           Amd. 1

           ISO/IEC 9593 – 4   1994
           Cor. 1

           ISO/IEC 9593 – 4   1998   Incorporation of PHIGS
           Amd. 2                    Amendments
Standard   ISO/IEC 9636 - 1   1991   Information Technology-
[]                                   Computer Graphics -
                                     Interfacing Techniques
                                     for Dialogues with
                                     Graphical Devices (CGI)
                                     – Functional
                                     Specification
                                     Part 1 – Overview,
                                     Profiles, and
                                     Conformance
Standard   ISO/IEC 9636 - 2   1991   Part 2 - Control
[]
Standard   ISO/IEC 9636 - 3   1991   Part 3 - Output
[]
Standard   ISO/IEC 9636 - 4   1991   Part 4 - Segments
[]
Standard   ISO/IEC 9636 - 5   1991   Part 5 – Input and
[]                                   Echoing
Standard   ISO/IEC 9636 - 6   1991   Part 6 - Raster
[]
Profile    ISP 12064-1        DISP   Image Application -
[E]                                  Simple Document
                                     Structure - Raster
                                     graphics Content
                                     Architecture Document
                                     Application Profile ITU-
                                     ISB Recommendations
                                     T4 and T6 + Tiled Raster
                                     Graphics
                                     FOD 112




                              D-33
        Profile        MIL-D-28002           Rev B           Requirements for Raster
        [T]                                  Amend 1         Graphics Representation
                       NOT FOUND IN          20 Sep 93       in Binary Format.
                       ASSIST
                                                             Federal Information
                                                             Processing Standard
                                                             (FIPS 150)

                                                             NISTIR 5108 Raster
                                                             Graphics: A Tutorial and
                                                             Implementation Guide
                                                             provides guidance
                                                             regarding use of MIL-D-
                                                             28002
        Profile        MIL-D-28003           Rev A Nov       Digital Representation
        [T]                                  92              for Communication of
                       NOT FOUND IN          Amend 1         Illustration Data: CGM
                       ASSIST                14 Aug 92       Application Profile.

                                                             MIL-D-28003 is
                                                             scheduled to migrate to a
                                                             Federal Information
                                                             Processing Standard
                                                             (FIPS 128-1) by End-
                                                             1996.

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 Specif ication (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       ISO/IEC 10303 - 1     1994            Industrial Automation
        [E]                                                  Systems and Integration
                                                             – Product Data
                                                             Representation and
                                                             Exchange
                                                             Part 1 – Overview and
                                                             Fundamental Principles



                                             D-34
Standard   ISO/IEC 10303 –   1994   Part 11 – Description
[E]        11                       Methods: The EXPRESS
                                    Language Reference
                                    Manual
           ISO/IEC 10303 –   1999
           11 Cor. 1
Standard   ISO/CD TR 10303   1997   Part 12 – Description
[E]        – 12                     Methods: The
                                    EXPRESS-I Language
                                    Reference Manual
Standard   ISO/AWI 10303 –          Part 14 – XML
[E]        14                       Representation for
                                    EXPRESS-Driven Data
Standard   ISO 10303 – 21    1994   Part 21 – Implementation
[E]                                 Methods: Clear Text
                                    Encoding of the
                                    Exchange Structure


           ISO 10303 – 21
           CD Amd. 1

           ISO 10303 – 21    1996
           Cor. 1
Standard   ISO 10303 – 22    1998   Part 22 – Implementation
[E]                                 Methods: Standard Data
                                    Access Interface
Standard   ISO/DIS 10303 –          Part 23 – Implementation
[E]        23                       Methods: C++ Language
                                    Binding to the Standard
                                    Data Access Interface
Standard   ISO/CD 10303 –           Part 24 – Implementation
[E]        24                       Methods: C Language
                                    Binding to the Standard
                                    Data Access Interface
Standard   ISO/AWI 10303 –          Part 26 – Implementation
[E]        26                       Methods: Interface
                                    Definition Language
                                    Binding to the Standard
                                    Data Access Interface
Standard   ISO/CD 10303 –
[E]        27
Standard   ISO 10303 – 31    1994   Part 31 – Conformance
[E]                                 Testing Methodology
                                    and Framework: General
                                    Concepts


                             D-35
Standard   ISO 10303 – 32     1998      Part 32 – Conformance
[E]                                     Testing Methodology
                                        and Framework:
                                        Requirements on Testing
                                        Laboratories and Clients
Standard   ISO 10303 – 34               Part 34 - Conformance
[E]                                     Testing Methodology
                                        and Framework:
                                        Abstract Test Methods
Standard   ISO 10303 – 35               Part 35 - Conformance
[E]                                     Testing Methodology
                                        and Framework:
                                        Abstract Test Methods
                                        for Standard Data Access
                                        Interface Implementation
Standard   ISO 10303 – 41     1994      Part 41 – Integrated
[E]                                     Generic Resources:
                                        Fundamentals of Product
                                        Description and Support


           ISO/DIS 10303-41   2nd Ed.
Standard   ISO 10303 – 42     1994      Part 42 – Integrated
[E]                                     Generic Resources:
                                        Geometric and
                                        Topological
                                        Representation

           ISO/DIS 10303–42   2nd Ed.

           ISO 10303 – 42     1999
           Cor. 1

           ISO 10303 – 42
           Cor. 2
Standard   ISO 10303 – 43     1994      Part 43 - Integrated
[E]                                     Generic Resources:
                                        Representation
                                        Structures

           ISO/DIS 10303–43   2nd Ed.

           ISO 10303 – 43     1999
           Cor. 1




                              D-36
Standard   ISO 10303 – 44     1994      Part 44 - Integrated
[E]                                     Generic Resources:
                                        Product Structure
                                        Configuration

           ISO/DIS 10303–44   2nd Ed.

           ISO 10303 – 44     1999
           Cor. 1
Standard   ISO 10303 – 45     1998      Part 45 - - Integrated
[E]                                     Generic Resources:
           ISO 10303 – 45     1999      Materials
           Cor. 1
Standard   ISO 10303 – 46     1994      Part 46 – Integrated
[E]                                     Generic Resources:
           ISO 10303 – 46     1999      Visual Presentation
           Cor. 1
Standard   ISO 10303 – 47     1997      Part 47 - Integrated
[E]                                     Generic Resources:
                                        Shape Variation
                                        Tolerances
Standard   ISO 10303 – 49     1998      Part 49 - - Integrated
[E]                                     Generic Resources:
                                        Process Structure and
                                        Properties
Standard   ISO 10303 – 101    1994      Part 101 – Integrated
[E]                                     Application Resources:
           ISO 10303 – 101    1999      Draughting
           Cor. 1
Standard   ISO 10303 – 104              Part 104 - Integrated
[E]                                     Application Resources:
                                        Finite Element Analysis
Standard   ISO 10303 – 105    1996      Part 105 - Integrated
[E]                                     Application Resources:
                                        Kinematics
Standard   ISO 10303 – 106              Part 106 - Integrated
[E]                                     Application Resources:
                                        Building Construction
                                        Core Model
Standard   ISO 10303 – 107              Industrial Data
[E]                                     Part 107 - Integrated
                                        Application Resources:
                                        Engineering Analysis
                                        Core Application
                                        Reference Model (EA C-
                                        ARM)


                              D-37
Standard   ISO 10303 – 201   1994   Product Data
[E]                                 Part 201 – Application
                                    Protocol: Explicit
                                    Draughting
Standard   ISO 10303 – 202   1996   Part 202 – Application
[E]                                 Protocol: Associative
                                    Draughting
Standard   ISO 10303 – 203   1994   Part 203 - Application
[E]                                 Protocol: Configuration
           ISO 10303 – 203   1996   Controlled Design
           Cor. 1

           ISO 10303 – 203   1998
           Cor. 2
Standard   ISO 10303 – 207   1999   Part 207 - Application
[E]                                 Protocol: Sheet Metal
                                    Die Planning and Design
Standard   ISO 10303 – 208          Part 208 - Application
[E]                                 Protocol: Life-cycle
                                    Management
Standard   ISO 10303 – 209          Part 209 - Application
[E]                                 Protocol: Composite and
                                    Metallic Structural
                                    Analysis and Related
                                    Design
Standard   ISO 10303 – 210          Part 210 - Application
[E]                                 Protocol: Electronic
                                    Assembly,
                                    Interconnection, and
                                    Packaging Design
Standard   ISO 10303 – 212          Part 212 - Application
[E]                                 Protocol:
                                    Electrotechnical Design
                                    and Installation
Standard   ISO 10303 – 213          Part 213 - Application
[E]                                 Protocol: Numerical
                                    Control Process Plans for
                                    Machined Parts
Standard   ISO 10303 – 214          Part 214 - Application
[E]                                 Protocol: Core Data for
                                    Automotive Mechanical
                                    Design Processes
Standard   ISO 10303 – 215          Part 215 - Application
[E]                                 Protocol: Ship
                                    Arrangement



                             D-38
Standard   ISO 10303 – 216          Part 216 - Application
[E]                                 Protocol: Ship Molded
                                    Forms
Standard   ISO 10303 – 217          Part 217 - Application
[E]                                 Protocol: Ship Piping
Standard   ISO 10303 – 218          Part 218 - Application
[E]                                 Protocol: Ship Structures
Standard   ISO 10303 – 221          Part 221 - Application
[E]                                 Protocol: Functional
                                    Data and Their
                                    Schematic
                                    Representation for
                                    Process Plants
Standard   ISO 10303 – 222          Part 222 - Application
[E]                                 Protocol: Exchange of
                                    Product Data for
                                    Composite Structures
Standard   ISO 10303 – 223          Part 223 - Application
[E]                                 Protocol: Exchange of
                                    Design and
                                    Manufacturing Product
                                    Information for Cast
                                    Parts
Standard   ISO 10303 – 224          Part 224 - Application
[E]                                 Protocol: Mechanical
                                    Product Definition for
                                    Process Planning Using
                                    Machining Features
Standard   ISO 10303 – 225          Part 225 - Application
[E]                                 Protocol: Building
                                    Elements Using Explicit
                                    Shape Representation
Standard   ISO/WD 10303 –           Part 226 - Application
[E]        226                      Protocol: Ship
                                    Mechanical Systems
Standard   ISO/DIS 10303 –          Part 227 - Application
[E]        227                      Protocol: Plant Spatial
                                    Configuration
Standard   ISO/AWI 10303 –          Part 229 - Application
[E]        229                      Protocol: Exchange of
                                    Design and
                                    Manufacturing Product
                                    Information for Forged
                                    Parts




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



                             D-40
Standard   ISO/DIS 10303 –           Part 504 – Application
[E]        504                       Interpreted Construct:
                                     Draughting Annotation
Standard   ISO/DIS 10303 –           Part 505 – Application
[E]        505                       Interpreted Construct:
                                     Drawing Structure and
                                     Administration
Standard   ISO/DIS 10303 –           Part 506 – Application
[E]        506                       Interpreted Construct:
                                     Draughting Elements
Standard   ISO/DIS 10303 –           Part 507 – Application
[E]        507                       Interpreted Construct:
                                     Geometrically Bounded
                                     Surface
Standard   ISO/DIS 10303 –           Part 508 – Application
[E]        508                       Interpreted Construct:
                                     Non-manifold Surface
Standard   ISO/DIS 10303 –           Part 509 – Application
[E]        509                       Interpreted Construct:
                                     Manifold Surface
Standard   ISO/PRF 10303 –           Part 510 – Application
[E]        510                       Interpreted Construct:
                                     Geometrically Bounded
                                     Wireframe
Standard   ISO/DIS 10303 –           Part 511 – Application
[E]        511                       Interpreted Construct:
                                     Topologically Bounded
                                     Surface
Standard   ISO/FDIS 10303 –          Part 512 – Application
[E]        512                       Interpreted Construct:
                                     Faceted Boundary
                                     Representation
Standard   ISO/DIS 10303 –           Part 513 – Application
[E]        513                       Interpreted Construct:
                                     Elementary Boundary
                                     Representation
Standard   ISO/FDIS 10303 –          Part 514 – Application
[E]        514                       Interpreted Construct:
                                     Advanced Boundary
                                     Representation
Standard   ISO/DIS 10303 –           Part 515 – Application
[E]        515                       Interpreted Construct:
                                     Constructed Solid
                                     Geometry




                              D-41
Standard   ISO/DIS 10303 –               Part 517 – Application
[E]        517                           Interpreted Construct:
                                         Mechanical Design
                                         Geometric Presentation
Standard   ISO/CD 10303 –                Part 518 – Application
[E]        518                           Interpreted Construct:
                                         Mechanical Design
                                         Shaded Representation
Standard   ISO/FDIS 10303 –              Part 519 – Application
[E]        519                           Interpreted Construct:
                                         Geometric Tolerances
Standard   ISO/FDIS 10303 –              Part 520 – Application
[E]        520                           Interpreted Construct:
                                         Associative Draughting
                                         Elements
Standard   ANSI/EIA 548        1988      Electronic Design
[ ]                                      Interchange Format
           NOT FOUND                     (EDIF)
                                         May be subsumed by
                                         STEP
Standard   ANSI/IEEE 1076      1993      IEEE Standard VHDL
[E]                                      Language Reference
                                         Manual

Standard   ANSI/IEEE 1076.2    1996      IEEE Standard VHDL
[E]                                      Language Math
                                         Packages

Standard   ANSI/IEEE 1076.3    1997      IEEE Standard VHDL
[E]                                      Synthesis Packages

Standard   ANSI/IEEE 1076.4    1995      IEEE Standard for
[E]                                      VITAL Application-
                                         Specific Integrated
                                         Circuit (ASIC) Modeling
                                         Specification

Standard   ANSI/ASME           Ver 5.2   Initial Graphics
[T]        Y14.26M / FIPS      (1989)    Exchange Specification
           177                           (IGES)
                                         May be subsumed by
                                         STEP
Profile    STEP Applications             At least 34 different ISO
[E]                                      STEP Application
                                         Profiles are under
                                         development.


                               D-42
         Profile        MIL-D-28000           Rev A            Digital Representation
         [T]                                  10 Feb 92        for Communication of
                        NOT FOUND IN          Amend 1          Product Data: IGES
                        ASSIST                14 Dec 92        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 rap id 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       ISO/IEC 10918 - 1     1994             Information Technology
         [R]                                                   – Digital Compression
                                                               and Coding of
                                                               Continuous-tone Still
                                                               Images
                                                               Part 1 - Requirements
                                                               and Guidelines
         Standard       ISO/IEC 10918 - 2     1995             Part 2 – Compliance
         [R]                                                   Testing

         Standard       ISO/IEC 10918 – 3     1997             Part 3 – Extensions
         [R]
                        ISO/IEC 10918 – 3                      Provision to Allow
                        Amd. 1                                 Registration of New
                                                               Compression Types and
                                                               Revisions in the SPIFF
                                                               Header




                                              D-43
       Standard      ISO/IEC 10918 - 4   1999          Part 4 – Registration of
       [R]                                             JPEG Profiles, SPIFF
                                                       Profiles, SPIFF tags,
                                                       SPIFF Color Spaces,
                                                       APPn Markers, SPIFF
                                                       Compression Types and
                                                       Registration Authorities
                                                       (REGAUT)
       Standard      ISO/IEC 12087 - 1   1995          Information Technology
       [ ]                                             – Computer Graphics
                                                       and Image Processing -
                                                       Image Processing and
                                                       Interchange (IPI) –
                                                       Functional Specification
                                                       Part 1 – Common
                                                       Architecture for Imaging
       Standard      ISO/IEC 12087 – 2   1994          Part 2 – Programmer‟s
       [ ]                                             Imaging Kernel System
                                                       Application Program
                                                       Interface

                     ISO/IEC 12087 – 2   1997
                     Cor. 1
       Standard      ISO/IEC 12087 – 3   1995          Part 3 – Image
       [ ]                                             Interchange Facility (IIF)

                     ISO/IEC 12087 – 3   1996          Type Definition,
                     Amd. 1                            Scoping, and Logical
                                                       Views for Image
                                                       Interchange Facility
       Standard      ISO/IEC 12087 – 5   1998          Part 5 – Basic Image
       [ ]                                             Interchange Format
                                                       (BIIF)
       Standard      ITU-TSB T6          1988          Facsimile Coding and
       [R]           (formerly CCITT                   Control Functions for
                     Recommendation                    Group IV Facsimile
                     T.6)                              Apparatus.


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            Information Processing -
        []                                                  Volume and File
                                                            Structure of CD-ROM
                                                            for Information
                                                            Exchange.
        Standard       ISO/IEC 10149        1995            Information Technology
        []                                                  - Data Interchange on
                                                            Read-only 120mm
                                                            Optical Data Discs (CD-
                                                            ROM)

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 CD-
ROM 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 migratio n
strategies, will also need to include appropriate reference to the acceptable data compression
standards.

       Standard       ISO/IEC 10918 - 1     1994           Information Technology -
       [E]                                                 Digital Compression and
                                                           Coding of Continuous-ton
                                                           Still Images
                                                           Part 1 – Requirements and
                                                           Guidelines
       Standard       ISO/IEC 10918 – 2     1995           Part 2 – Compliance
       [E]                                                 Testing
       Standard       ISO/IEC 10918 – 3     1997           Part 3 – Extensions
       [E]
                      ISO/IEC 10918 – 3     1997           Provision to Allow
                      Amd. 1                               Registration of New
                                                           Compression Types and
                                                           Revisions in the SPIFF
                                                           Header
       Standard       ISO/IEC 10918 – 4     1999           Part 4 – Registration of
       [E]                                                 JPEG Profiles, SPIFF
                                                           Profiles, SPIFF Tags,
                                                           SPIFF Color Spaces, APPn
                                                           Markers, SPIFF
                                                           Compression Types and
                                                           Registration Authorities
                                                           (REGAUT)


                                            D-45
       Standard      ISO/IEC 11172 - 1     1993          Information Technology -
       [R]                                               Coding of Motion Pictures
                     ISO/IEC 11172 – 1     1996          and associated Audio for
                     Cor. 1                              Digital Storage Media at
                                           1999          up to About 1.5 Mbps
                                                         Part 1 - Systems
                     ISO/IEC 11172 – 1
                     Cor. 2

       Standard      ISO/IEC 11172 – 2     1993          Part 2 - Video
       [R]
                     ISO/IEC 11172 – 2     1996
                     Cor. 1

                     ISO/IEC 11172 – 2     1999
                     Cor. 1
       Standard      ISO/IEC 11172 – 3     1993          Part 3 - Audio
       [R]
                     ISO/IEC 11172 – 3     1996
                     Cor. 1
       Standard      ISO/IEC 11172 – 4     1995          Part 4 – Compliance
       [R]                                               Testing

       Standard      ISO/IEC TR 11172      1998          Part 5 – Software
       [R]           –5                                  Simulation
       Standard      ISO/IEC 13813         1998          Information Technology –
       [R]                                               Programming Languages –
                                                         Generic Packages of Real
                                                         and Complex Type
                                                         Declarations and Basic
                                                         Operations of Ada
       Standard      ISO/IEC 11544         1993          Information Technology -
       [ ]                                               Coded Representation of
                     ISO/IEC 11544         1995          Picture and Audio
                     Cor. 1                              Information - progressive
                                                         bi- level image
                                                         compression (JBIG).

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       TBD
        []
        Profile        TBD
        [ ]
        STANAG         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       ISO/IEC 10744        1997             Information Technology -
        [R]                                                  Hypermedia/Time Based
                                                             Document Structuring
                                                             Language (HyTime).
        Standard       ISO/IEC 13522 - 1    1997             Information Technology -
        [ ]                                                  Coding of Multimedia
                                                             and Hypermedia
                                                             Information (MHEG).
                                                             Part 1 – MHEG Object
                                                             Representation – Base
                                                             Notation (ASN.1)
        Standard       ISO/IEC 13522 - 3    1997             Part 3 – MHEG Script
        [ ]                                                  Interchange
                                                             Representation
        Standard       ISO/IEC 13522 - 4    1996             Part 4 – MHEG
        [ ]                                                  Registration Procedure
        Standard       ISO/IEC 13522 – 5    1997             Part 5 – Support for Base-
        [ ]                                                  level Interactive
                                                             Applications

                       ISO/IEC 13522 – 5                     Class Extensions
                       AWI Amd. 1

                       ISO/IEC 13522 – 5    1999
                       Cor. 1




                                             D-47
        Standard       ISO/IEC 13522 - 6      1998             Part 6 – Support for
        [ ]                                                    Enhanced Interactive
                                                               Applications

        Standard       ISO/IEC AWI                             Part 7 – Interoperability
        [ ]            13522 - 7                               and Conformance Testing
                                                               for ISO/IEC 13522-5

        Standard       ISO/IEC 13522 - 8
        [ ]                                                    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             Information and
        []                                                    Documentation -
                                                              Electronic Manuscript
                                                              Preparation and Markup
        Standard       ISO/DIS 2709          1996             Information and
        [E]                                                   Documentation - Format
                                                              for Information
                                                              Exchange
        Standard       AECMA SPEC            Change 4         International
        [E]            1000D                                  Specification for
                                                              technical Publications
                                                              using a Common Source
                                                              Database.
        Standard       MIL-M-87268           20 Nov 92        Interactive Electronic
        [T]                                                   Technical Manual
                       WAS NOT                                (IETM) Content
                       FOUND
        Standard       MIL-D-87269           20 Nov 92        Interactive Electronic
        [T]                                                   Technical Manual
                       WAS NOT                                (IETM) Database
                       FOUND
        Standard       MIL-Q-87270           20 Nov 92        Interactive Electronic
        []                                                    Technical Manual
                       Cancelled – No        31 May 1996      (IETM) -Quality
                       S/S Document                           Assurance Requirements
                                                              for Quality Assurance
                                                              Program.

                      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 MANAGEMENT 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       IEEE 1220             1994             Application         and
         [E]                                  (Feb 1995)       Management of the
                                              Trial    Use     Systems     Engineering
                                              Standard         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        UK DEF STAN            Interim Issue   Application of Integrated
       [E]            0060                   1 1994          Logistic Support (ILS)
       Standard       AC/305(SLM) -                          Orientation Document for
       [T]            D23                                    Integrated Logistic Support
                                                             Within the Framework of
                                                             Multinational Equipment
                                                             Projects
       Handbook       MIL-HDBK 59B           Canceled        Continuous Acquisition and
       [T]            NOT 1                  10 Sep 1997     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   ISO/CD 9004                  Quality Management
[E]                                     Systems - Guidelines for
                                        Performance
                                        Improvements
Standard   ISO/CD 9004 - 1       1994   Quality Management and
[E]                                     Quality System Elements
                                        Part 1 – Guidelines
Standard   ISO 9004 – 2          1991   Part 2 – Guidelines for
[E]                                     Services
           ISO 9004 – 2 Cor.     1994
           1
Standard   ISO 9004 - 3          1993   Part 3 – Guidelines for
[E]                                     Processed Materials
Standard   ISO 9004 – 4          1993   Part 4 – Guidelines for
[E]                                     Quality Improvement
           ISO 9004 – 4 Cor. 1   1994
Standard   ISO/IEC 10164 – 1     1993   Information Technology
[E]                                     - Open Systems
                                        Interconnection –
                                        Systems Management
                                        Part 1 – Object
                                        Management Function

                                        Implementation of
           ISO/IEC 10164 – 1     1996   Conformance Statement
           Amd. 1                       Proformas

           ISO/IEC 10164 – 1     1996
           Amd. 1 Cor. 1
Standard   ISO/IEC 10164 – 2     1993   Part 2 – State
[E]                                     Management Function

           ISO/IEC 10164 – 2     1996   Implementation
           Amd. 1                       Conformance Statement
                                        Proformas
           ISO/IEC 10164 – 2     1996
           Amd. 1 Cor. 1

           ISO/IEC 10164 – 2     1996
           Cor. 1




                                 D-51
Standard   ISO/IEC 10164 – 3   1993   Part 3 – Attributes for
[E]                                   Representing
                                      Relationships
           ISO/IEC 10164 – 3   1996
           Amd. 1                     Implementation of
                                      Conformance Statement
           ISO/IEC 10164 – 3   1996   Proformas
           Amd. 1 Cor. 1
Standard   ISO/IEC 10164 – 4   1992   Part 4 – Alarm Reporting
[E]                                   Function

           ISO/IEC 10164 – 4   1995   Implementation of
           Amd. 1                     Conformance Statement
                                      Proformas
           ISO/IEC 10164 – 4   1996
           Amd. 1 Cor. 1

           ISO/IEC 10164 – 4   1994
           Cor. 1

           ISO/IEC 10164 – 4
           CD Cor. 2
Standard   ISO/IEC 10164 – 5   1993   Part 5 – Event Report
[E]                                   Management Function

           ISO/IEC 10164 – 5   1995   Implementation of
           Amd. 1                     Conformance Statement
                                      Proformas
           ISO/IEC 10164 – 5   1996
           Amd. 1 Cor. 1

           ISO/IEC 10164 – 5   1994
           Cor. 1

           ISO/IEC 10164 – 5
           CD Cor. 2




                               D-52
Standard   ISO/IEC 10164 – 6   1993   Part 6 – Log Control
[E]                                   Function

           ISO/IEC 10164 – 6   1996   Implementation of
           Amd. 1                     Conformance Statement
                                      Proformas
           ISO/IEC 10164 – 6   1996
           Amd. 1 Cor. 1

           ISO/IEC 10164 – 6
           CD Amd. 2
Standard   ISO/IEC 10164 – 7   1992   Part 7 – Security alarm
[E]                                   reporting Function

           ISO/IEC 10164 – 7   1995   Implementation
           Amd. 1                     Conformance Statement
                                      Proformas
           ISO/IEC 10164 – 7   1996
           Amd. 1 Cor. 1
Standard   ISO/IEC 10164 – 8   1993   Part 8 – Security Audit
[E]                                   Trail Function
           ISO/IEC 10164 – 8   1995
           Cor. 1

           ISO/IEC 10164 – 8   1996
           Cor. 2

           ISO/IEC 10164 – 8   1999
           Cor. 3
Standard   ISO/IEC 10164 – 9   1995   Part 9 – Objects and
[E]                                   Attributes for Access
           ISO/IEC 10164 – 9   1996   Control
           Cor. 1
Standard   ISO/IEC 10164 –     1995   Part 10 – Usage
[E]        10                         Metering Function for
                                      Accounting Purposes

                               1998   Implementation
           ISO/IEC 10164 –            Conformance State
           10 Amd. 1                  Proformas
                               1999
           ISO/IEC 10164 –
           10 Cor. 1




                               D-53
Standard   ISO/IEC 10164 –   1994   Part 11 – Metric Objects
[E]        11                       and Attributes

                             1998   Implementation
           ISO/IEC 10164 –          Conformance State
           11 Amd. 1                Proformas
                             1999
           ISO/IEC 10164 –
           11 Cor. 1
Standard   ISO/IEC 10164 –   1994   Part 12 – Test
[E]        12                       Management Function
                             1998
           ISO/IEC 10164 –
           12 Cor. 1
                             1999
           ISO/IEC 10164 –
           12 Cor. 2
Standard   ISO/IEC 10164 –   1995   Part 13 – Summarization
[E]        13                       Function

                             1999   Implementation
           ISO/IEC 10164 –          Conformance State
           13 Amd. 1                Proformas
                             1999
           ISO/IEC 10164 –
           13 Cor. 1
Standard   ISO/IEC 10164 –   1996   Part 14 – Confidence and
[E]        14                       Diagnostic Test
                                    Categories
           ISO/IEC 10164 –
           14 Cor. 1
Standard   ISO/IEC 10164 –   1995   Part 15 – Scheduling
[E]        15                       Function
                             1999
           ISO/IEC 10164 –
           15 Cor. 1
Standard   ISO/IEC 10164 –   1997   Part 16 – Management
[E]        16                       Knowledge Management
                                    Function

                             1998   Extension for General
           ISO/IEC 10164 –          Relationship Model
           16 Amd. 1




                             D-54
Standard   ISO/IEC 10164 –     1996       Part 17 – Change Over
[E]        17                             Function
                               1999
           ISO/IEC 10164 –
           17 Cor. 1
Standard   ISO/IEC 10164 –     1997       Part 18 – Software
[E]        18                             Management Function
                               1999
           ISO/IEC 10164 –
           18 Cor. 1
Standard   ISO/IEC 10164 –     1998       Part 19 – Management
[E]        19                             Domain and
                                          Management Policy
                                          Management Function
Standard   ISO/IEC 10164 –     1999       Part 20 – Time
[E]        20                             Management Function
Standard   ISO/IEC 10164 –     1998       Part 21 – Command
[E]        21                             Sequencer for Systems
                                          Management
Standard   ISO/IEC FCD                    Part 22 – Response Time
[E]        10164 – 22                     Monitoring Function
Standard   STANAG 4159         Ed 2       NATO Materiel
[T]                                       Configuration
                                          Management Policy and
                                          Procedures for multi-
                                          national Joint Projects
Standard   MIL-STD-973                    Configuration
[T]                                       Management Practices
                                          for Systems, Equipment,
                                          Munitions, and
                                          Computer Programs.

Profile    MIL-STD-483A        Canceled   Configuration
[N]        NOT 1                          Management Practices
                                          for Systems, Equipment,
           S/S MIL-STD-973                Munitions, and
                                          Computer Programs.
           MIL-STD-498         Canceled   Configuration
Standard   NOT 1                          Management and
[]                                        Software Development.
           S/S IEEE/EIA
           12207.0 – 12207.2




                               D-55
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 Assessment
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 ob vious. 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       ISO 14040             1997            Environmental
        [E]                                                  Management Life-cycle
                                                             Assessment – Principles
                                                             and Framework
        Standard       ISO 14041             1998            Life-cycle Assessment –
        [E]                                                  Goal and Scope
                                                             Definition and Inventory
                                                             Analysis
        Standard       ISO/FDIS 14042        1999            Life-cycle Impact
        [E]                                                  Assessment
        Profile
        []

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                                              TBD
        []
        Profile
        []

D9.6 Quality Manage ment
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       ISO 8402              1994             Quality - Vocabulary
        [R]
        Standard       ISO/CD 9000                            Quality Management
        [R]                                                   Systems- Fundamentals
                                                              and Vocabulary
        Standard       ISO 9000 - 1          1994             Quality Management and
        [R]                                                   Quality Assurance
                                                              Standards
                                                              Part 1 – Guidelines for
                                                              Selection and Use
        Standard       ISO 9000 - 2          1997             Part 2 – Generic
        [R]                                                   Guidelines for the
                                                              Application of ISO 9001,
                                                              ISO 9002, and ISO 9003
        Standard       ISO 9000 – 3          1997             Part 3 – Guidelines for
        [R]                                                   the Application of ISO
                                                              9001: 1994 to the
                                                              Development, Supply,
                                                              Installation, and
                                                              Maintenance of
                                                              Computer Software


                                             D-57
        Standard      ISO 9000 – 4         1993            Part 4 – Guide to
        [R]                                                Dependability Program
                                                           Management
        Standard      ISO 9001             1994            Quality Systems - Model
        [R]                                                for Quality Assurance in
                                                           Design, Development,
                                                           Production, Installation,
                                                           and Servicing.

                      ISO/CD 9001                          Quality Management
                                                           Systems - Requirements
                      ISO 9001 Cor. 1
                                           1995
        Standard      ISO/CD 9004                          –Quality Management
        [R]                                                Systems – Guidelines for
                                                           Performance
                                                           Improvements.
        Standard      ISO 9004 - 1         1994            Quality Management and
        [R]                                                Quality Systems
                                                           Elements
                                                           Part 1 – Guideline
        Standard      ISO 9004 – 2         1991            Part 2 – Guidelines for
        [R]                                                Services
                      ISO 9004 – 2 Cor.    1994
                      1
        Standard      ISO 9004 – 3         1993            Part 3 – Guidelines for
        [R]                                                Processed Materials
        Standard      ISO 9004 – 4         1993            Part 4 – Guidelines for
        [R]                                                Quality Improvement
                      ISO 9004 – 4 Cor.    1994
                      1
        Standard      STANAG 4107                          Mutual Acceptance of
        [R]                                                Government Quality
                                                           Assurance
        Standard      AQAP 1                               NATO Requirements for
        [T]                                                an Industrial Quality
                                                           Control Program
        Standard      AQAP 13                              NATO Software Quality
        [T]                                                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 multi-
national 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     AC/313 - D/67         9 Jun 95
         [E]
         Standard       STANAG                                 NK
         []
         Profile
         []


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 Government-
approved 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       STANAG                                  NK
       []
       Profile
       []


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       ISO/IEC 9796           1991             Information Technology
         [R]                                   Ed 1             - Security Techniques -
                                                                Digital Signature
                                                                Scheme giving Message
                                                                Recovery
         Standard       ISO/IEC DIS 9796                        Part 1 – Mechanisms
         [R]            -1                                      Using Redundancy
         Standard       ISO/IEC 9796 - 2       1997             Part 2 – Mechanisms
         [R]                                                    using a Hash Function
         Standard       ISO/IEC FDIS                            Part 3 – Discrete
         [R]            9796 - 3                                Logarithm Based
                                                                Mechanisms
         Profile        FIPS 161-1                              U.S. Federal Information
         [E]                                                    Processing Standard
         Standard       STANAG                                  NK
         []
         Guidance       AC/313 -D/66           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 requireme nt
      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   ISO 7372              1993   Trade Data Interchange –
[R]                                     Trade Data Elements
                                        Directory
Standard   ISO 9735              1988   Electronic Data
[R]                                     Interchange for
                                 1992   Administration,
           ISO 9735 Amd. 1              Commerce and Transport
                                        (EDIFACT) –
                                        Application Level Syntax
                                        Rules


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


                                 D-61
        Standard        ISO 9735 – 8             1998           Syntax Version Number 4
        [R]                                                     Part 8 – Associated Data
                                                                in EDI
        Standard        ISO 9735 – 9             1999           Syntax Version Number 4
        [R]                                                     Part 9 – Security Key and
                                                                Certificate Management
                                                                Message (message type –
                                                                KEYMAN)
        Standard        ANSI X.12                Version 3
        [T]                                      Release 3
                                                 Sub-release
                                                 2 (June
                                                 1993)
        Profile         FIPS 161-1                              U.S. Federal Information
        [E]                                                     Processing Standard
                                                                (EDIFACT)
                                                                (Transaction Set 841?)
        Standard        STANAG 5500                             NATO MESSAGE TEXT
        [T]                                                     FORMATTING
                                                                SYSTEM
        Profile         ADatP-3                                 Allied Data Publication 3
        [T]                                                     - 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       AECMA 2000M           Revision 3.0     Material Management
        [E]                                                   Integrated Data
                                                              Processing for Military
                                                              Equipment - Volume 4
                                                              Appendix 2 Annex G -
                                                              Example of an
                                                              Interchange Agreement
        Profile        UK DEF STAN           Interim Issue    Application of Integrated
        [E]            0060 Part 20          1                Logistic Support (ILS) -
                                                              Electronic Data
                                                              Interchange Agreement
                                                              for Data Exchange
                                                              specified in AECMA
                                                              SPEC 2000M
        Guidelines     AC/313 - D/60         17 Nov 94        Guidelines and Sample
        [R]                                                   Provisions for
                                                              Memoranda of
                                                              Understanding
        Guidelines     AC/313 - D/           1 Aug 95         Guidelines and Sample
        [E]                                                   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       ISO 639               1988             –Code for the
        [R]                                                   Representation of names
                                                              of Languages

                       ISO/CD639 – 1                          Part 1 – Apha-2 Code
        Standard       ISO 639 - 2           1998             Part 2 – Alpha-3 Code
        [R]
        Standard       ISO 8601              1988             Data Elements and
        [R]                                                   Interchange Formats –
                       ISO/WD 8601           2nd Ed.          Information Interchange
                                                              – Representation of
                       ISO 8601 Cor. 1       1991             Dates and Times



                                             D-63
        Standard      ISO 4217             1995           –Codes for the
        [R]                                               Representation of
                                                          Currencies and Funds
        Standard      ISO 3166 - 1         1997           –Codes for the
        [R]                                               Representation of Names
                                                          of Countries and Their
                                                          Subdivisions
                                                          Part 1 – Country Codes
        Standard      ISO 3166 - 2         1998           Part 2 – Country
        [R]                                               Subdivision Code
        Standard      ISO 3166 - 3         1999           Part 3 – Code for
        [R]                                               Formerly Used Names of
                                                          Countries
        Standard      ISO/IEC 11179 - 1                   Information Technology
        [R]                                               - Specification and
                                                          Standardization of Data
                                                          Elements
                                                          Part 1 – Framework for
                                                          the Specification and
                                                          Standardization of Data
                                                          Elements
        Standard      ISO/IEC 11179 – 2                   Part 2 – Classification
        [R]                                               for Data Elements
        Standard      ISO/IEC 11179 – 3    1994           Part 3 – Basic Attributes
        [R]                                               of Data Elements
                      ISO/IEC WD           2nd Ed.
                      11179 – 3
        Standard      ISO/IEC 11179 – 4    1995           Part 4 – Rules and
        [R]                                               Guidelines for the
                                                          Formulation of Data
                                                          Definitions
        Standard      ISO/IEC 11179 – 5    1995           Part 5 – Naming and
        [R]                                               Identification Principles
                                                          for Data Elements
        Standard      ISO 11179 - 6        1997           Information Technology
        [R]                                               - 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 explo it 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       ISO/IEC 9075                 3rd Ed.   Information Technology
         [E]                                         1992      - Database Language -
                                                               Structured Query
                        ISO/IEC 9075 Cor. 1          1996      Language (SQL)

                        ISO/IEC 9075 Cor. 3
         Standard       ISO/IEC 9075 - 1                       Part 1 – Framework
         [E]                                                   (SQL/Framework)
         Standard       ISO/IEC 9075 - 2                       Part 2 – Foundation
         [E]                                                   (SQL/Foundation)
         Standard       ISO/IEC 9075 – 3             1995      Part 3 – Call- Level
         [E]                                                   Interface (SQL/CLI)
                        ISO/IEC 9075 – 3 Cor. 1
         Standard       ISO/IEC 9075 – 4             1996      Part 4 – Persistent Stored
         [E]                                                   Modules (SQL/PSM)
                        ISO/IEC 9075 – 4 Cor. 1
         Standard       ISO/IEC 9075 – 5                       Part 5 – Host Language
         [E]                                                   Bindings
                                                               (SQL/Bindings)
         Standard       ISO/IEC WD 9075 – 6                    Part 6 – SQL/XA
         [E]                                                   Specialization
         Standard       ISO/IEC AWI 9075 – 7                   Part 7 - Temporal
         [E]
         Standard       ISO/IEC CD 9075 – 7                    Part 9 – Management of
         [E]                                                   External Data
         Standard       ISO/IEC FCD 9075 – 10                  Part 10 – Object
         [E]                                                   Language Bindings
                                                               (SQL/OLB)



                                              D-65
        Standard       ISO/IEC 10032                1995      Information Technology
        [E]                                                   - Reference Model of
                                                              Data Management
        Standard       ISO/IEC 9579                 1999      Information Technology
        [E]                                                   – Remote Database
                                                              Access for SQL

                       ISO/IEC FCD 9579             3rd Ed.   Remote Database Access
                                                              for SQL with Security
                                                              Enhancement
                       ISO/IEC FDIS 9579            2nd Ed.

                       ISO/IEC 9579 CD Amd.                   Distribution Schema for
                       2                                      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       MIL-STD-974           20 Aug 93        Contractor Integrated
        [T]                                                   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       MIL-STD-1840         Revision B      Automated Interchange
        [T]                                 3 Nov 93        of Technical Information
                                            Revision C
                                            26 June 1997

Note: The Policy and applicable standards for Automated Interchange of Information for
NATO, and the status of the above Standards has not yet been confirmed or validated in the
NATO CALS context. Although there are legacy systems based on this U.S. DoD Military
Standard in use within NATO, it should be noted that this Standard may not reflect NATO
CALS requirements.

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       MIL-T-31000          Revision A      General Specification for
        [T]                                 1 Dec 92        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 Docume nt

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                      NATO Manual on Codification Guide to NATO Codification
                             Systems
AdatP-3                      Allied Data Publication 3 - NATO Message Text Formatting
                             System
AECMA 2000M                  Material Management Integrated Data Processing for Military
                             Equipment
AECMA SPEC 1000D             International Specification for technical Publications using a
                             Common Source Database
ANSI/ASME Y14.26M            Initial Graphics Exchange Specification (IGES). May be subsumed
                             by STEP
ANSI/IEEE 1076               Very High Speed Integrated Circuit (VHSIC) Hardware description
                             Language (VHDL)
AQAP 1                       NATO Requirements for an Industrial Quality Control Program
AQAP 13                      NATO Software Quality Control System Requirements
IEEE 1220:1994               Application and Management of the Systems Engineering Process
ISO 1000                     SI Units
ISO 10164                    Configuration Management
ISO 10646-1                  Information Processing - Universal Character Sets
ISO 11172                    MPEG2 Motion Picture Experts Group (MPEG) Coding of Motion
                             Pictures and associated Audio for Digital Storage Media
ISO 11179                    Information Technology - Basic Data Element Attributes
ISO 12083                    Electronic Manuscript Preparation and Markup
ISO 13584                    Industrial Automation - Parts Library Environmental Life-cycle
                             Assessment
ISO 14041                    Life-cycle Inventory Analysis
ISO 14042                    Life-cycle Impact Assessment
ISO 3166                     Information Processing - Country Name Representations
ISO 31                       Information Processing Representation of Quantities and Units
ISO 4217                     Information Processing - Currencies and Funds
ISO 639                      Information Processing Coded Representation of Names of
                             Languages
ISO 646                      Information Technology - ISO 7-Bit Coded Character Set for
                             Information Interchange
ISO 6709                     Information Processing - Representation of Latitude and Longitude
ISO 6936                     Information Processing - Character Set Conversion
ISO 7372                     EDIFACT Data Element Directory
ISO 8601                     Information Processing - Date/Time Representations
ISO 8613                     Information Processing Systems. Office Documentation
                             Architecture
ISO 8824/8825                Standard Page Description Language (SPDL)
ISO 8859                     Information Processing - 8-bit single byte coded graphic character
                             sets




                                               E-1
ISO 8879            Information Processing - Text and Office System - Standard
                    Generalized Markup Language (SGML)
ISO 9000            Quality Management and Quality Assurance Standards - Guidelines
                    for Selection and Use.
ISO 9001            Quality Systems - Model for Quality Assurance in Design,
                    Development, Production, Installation, and Servicing
ISO 9004-2          Quality Management and Quality Systems elements - Guidelines
                    for services.
ISO 9004-7          Guidelines for Configuration Management
ISO 9075            Database Language - Structured Query Language (SQL)
ISO 9660            Information Processing - Volume and File Structure of CD-ROM
                    for Information Exchange
ISO 9735            Electronic Data Interchange for Finance, Administration,
                    Commerce and Transport (EDIFACT) Syntax Rules
ISO DIS 10918       Joint Photographic Experts Group (JPEG) Still Picture Grayscale
                    and Color Image Data Compression Algorithms.
ISO/IEC 9069        Information Technology - SGML Support Facilities - SGML
                    Document Interchange Format (SDIF)
ISO/IEC 10149       Information Technology - Data Interchange on Read-only 120mm
                    Optical Data Discs (CD-ROM)
ISO/IEC 10303       Standard for the Exchange of Product Model Data (STEP)
ISO/IEC 10918       Coding of Digital Continuous Tone Still Picture Images (JPEG)
ISO/IEC 12087       Information Processing Systems - Image Processing and Interface
                    (IPI)
ISO/IEC 13673       Conformance Testing for SGML Systems
ISO/IEC 8632        Information Processing Systems - Computer Graphics - Metafile
ISO/IEC 9592        Information Processing Systems - Programmers Hierarchical
                    Interactive Graphics System (PHIGS))
ISO/IEC 9636        Information Processing Systems - Computer Graphics Interface
                    (CGI)
ISO/IEC 9796        Information Technology - Security Techniques - Digital Signature
                    Scheme giving Message Recovery
ISO/IEC DIS 10179   Document Style Semantics and Specification Language (DSSSL)
ISO/IEC IS 10744    Information Technology - Hypermedia/Time Based Document
                    Structuring Language (HyTime)
ISO/IEC TR 9573     Information Technology - SGML Support Facilities - Techniques
                    for using SGML
ISO/IECS 13522      Information Technology - Coding of Multimedia and Hypermedia
                    Information (MHEG)
ISP 12064-1         Image Application - Simple Document Structure - Raster graphics
                    Content Architecture
ITU-TSB T6          Facsimile Coding and Control Functions for Group IV Facsimile
                    Apparatus
MIL-D-28000         Digital Representation for Communication of Product Data
MIL-D-28002         Requirements for Raster Graphics Representation in Binary Format




                                    E-2
MIL-D-28003        Digital Representation for Communication of Illustration Data:
                   CGM Application Profile
MIL-D-87269        Interactive Electronic Technical Manual (IETM) Database
MIL-HDBK-470       Maintainability Program for Systems and Equipment
MIL-HDBK 59B       Computer Aided Acquisition and Logistics Support (CALS)
                   Program Implementation Guide
MIL-HDBK-SGML      U.S. Department of Defense Application of - SGML. Federal
                   Information Processing Standard (FIPS 152)
MIL-M-28001        Markup Requirements and Generic Style Specifications for
                   Electronic Printed Output and Exchange of Text - SGML
MIL-M-87268        Interactive Electronic Technical Manual (IETM) Content
MIL-Q-87270        Interactive Electronic Technical Manual (IETM) -Quality
                   Assurance
MIL-STD-1379D      Military Training Program
MIL-STD-1388-1A    DoD Logistic Support Analysis        7
MIL-STD-1388-2B    DoD Requirements for a Logistic Support Analysis Record (LSAR)
MIL-STD-1390       Level of Repair Analysis
MIL-STD-1629       Procedures for Performing a Failure mode Effects and Criticality
                   Analysis
MIL-STD-1840       Automated Interchange of Technical Information
MIL-STD-482A       Configuration Status Accounting
MIL-STD-785        Reliability Program for Systems and Equipment Development
MIL-STD-973        Configuration Management [TO BE CANCELLED]
MIL-STD-974        Contractor Integrated Technical Information Service (CITIS)
MIL-T-31000        General Specification for Technical Data Packages
STANAG 3150        Codification of Equipment - Uniform System of Supply
                   Classification
STANAG 4107        Mutual Acceptance of Government Quality Assurance
STANAG 4159        NATO Materiel Configuration Management Policy and Procedures
                   for multi- national Joint Projects
STANAG 4177        Codification of Items of Supply - Uniform System of Data
                   Acquisition
STANAG 4329        NATO Standard Bar Coding Symbology
STANAG 5500        NATO MESSAGE TEXT FORMATTING SYSTEM
UK DEF STAN 0060   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)    Markup that is a set of one or more attribute specifications, shown
List                         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)       A markup declaration that associates an attribute definition list with
List Declaration             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      A markup declaration that contains the formal specifications of a
Declaration        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      A DTD, or Document Type Definition, is an SGML construct used
Definition (DTD)   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

Ele ment           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
Ele ment Type      A markup declaration that contains the formal specification of the
Declaration        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            Combined architecture of data, applications, information, and
Infrastructure         communications technology

IMP                    Information Management Plan

IPSC                   Information Processing Standards for Computers

ISO                    International Organization for Standardization

ISO 8879 Information   Text and Office Systems - Standard Generalized Markup Language
Processing             (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   An OS, or Output Specification, provides a rigorously defined set
(OS)                   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 refe rence
                              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         A finite set of style characteristics to convey formatting intent for
specification (PS)   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   This term refers to the parsing of the digital data stream containing
Verification:           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 Proble m
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 ide ntify 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 Require ment
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. (Request, plus DS
Data).
Potential new common tools and equipment* (DS data).

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)

Ope rate
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 Require ments
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 Equipme nt* (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                               Requirement Management
           Target                                  (Pre and Post Contract Award)
           Description    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.

           Application/                        Time                  Quality                Cost
           Benefits       Pre-                                 We know what we           Do the right
                          production                           are meant to do and        thing.
                          Production                           who asked for it.         Provides good
                          Use               Better baseline                              baseline for
                                             for in service                               justification
                                             CM .                                         of changes.
                                            M aintaining a
                                             valid and
                                             current
                                             structured
                                             requirement
                                             statement
                                             during the
                                             in-service
                                             phase, it
                                             provides a
                                             better baseline
                                             for decisions
                                             on support
                                             planning and
                                             upgrades.

           Example



                          Table H-2 Shared E-Mail and Office Software
           Improvement                         Shared E mail and Office S oftware
           Target                                (between program participants)
           Description
           Application/                         Time                 Quality                 Cost
           Benefits       Pre-          Faster                                           Quicker is
                          production    communications                                    cheaper.
                          Production    lead to faster                                   Some
                          Use           decisions.                                        potential for
                                                                                          travel savings.

           Example




                                                      H-1
               Table H-3 Electronic Program Document Library
Improvement                          Electronic Program Document Library
Target
Description      Central managed source of significant documents (e.g., requirement, contract,
                 Specs, policy, etc.) (Scope – office docs, drawings, models, video, etc.)
Application/                             Time                  Quality                  Cost
Benefits         Pre-           Time reduction in        M uch improved         Reliable data gives
                 production     retrieval and            change control and     better decisions.
                 Production     distribution.            CM .                   (Technology is
                 Use                                                            cheap but set up
                                                                                and operating costs
                                                                                are non trivial)
Example



                  Table H-4 Improve Program Management
Improvement                              Improve Program Management
Target
Description      Use of Common Program M anagement tool set for project planning and control
                 (Tasks, Resources WBS, CSCS, Plans)
Application/                          Time                Quality                 Cost
Benefits         Pre-             People know       Some improvement. Better resource
                 production        what to do                              management.
                 Production        when.
                                  Better visibility
                                   of project
                                   status.

                 Use
Example



                       Table H-5 Program Workflow System
Improvement                                Program Workflow S ystem
Target
Description      Allows standardization, simplification, and automation of work in processes.
Application/                              Time                 Quality                Cost
Benefits         Pre-             M ajor savings        Enforces adherence     Can deliver
                 production       possible              to defined process     substantial savings
                 Production                                                    on repetitive
                 Use                                                           processes.
                 Acts as a major stimulus and support for Business Process Improvement. Big
                 cultural issues.
Example          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                      Implement a Virtual Design Environment
Target
Description    A Shared Data Environment for design, facilitating working concurrently on the
               same design (data)
Application/                         Time                Quality                  Cost
Benefits       Pre-              Saves traveling                          Saves on traveling
               production         time.                                    expenses.
                                 Concurrent
                                  working speeds
                                  up design time.

               Production
               Use
Example        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                 Implement a Virtual Design and Test En vironment
Target
Description    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.
Application/                          Time                  Quality             Cost
Benefits       Pre-              Saves traveling         Allows for       Saves on
               production         time.                    testing a great   traveling
                                 Concurrent               deal of design-   expenses.
                                  working speeds           variants.        Saves because
                                  up design time,         Allows for        not having to
                                  not having to            testing under     build
                                  build physical           many              prototypes.
                                  prototypes for           simulated
                                  testing.                 (hazardous)
                                 Concurrent               environments
                                  testing and              and conditions.
                                  redesign
                                  possible

               Production
               Use
Example




                                            H-3
          Table H-8 Improve Configuration Management (CM)
Improvement                   Improve Configuration Management (CM)
Target
Description    Single logical CM system for project, used as index     for most product
               information.
Application/                         Time            Quality                  Cost
Benefits       Pre-          Some benefits due     Control of         Some benefits due
               production    to better access to    requirement        to better access to
                             information.           and                information.
                                                    requirement
                                                    changes.
                                                   Control of
                                                    emergent
                                                    design.

               Production   Less time needed to   Consistent CM info
                            find information.     through the supply
                                                  chain.
               Use          Savings in            We know what we         M inimize
                            maintenance time      have to support.         rework.
                            through better                                M inimize
                            information.                                   unnecessary
                                                                           purchases

Example




                                         H-4
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 D ATA
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, d istribute, 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 Conside rations
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) fi les.




                                                I-2
I1.2.1.1 Compute r 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.

                           Table I-1 Standard Options for PC Types
                                       WINDOWS                     RISC
                                    WORKSTATION              WORKSTATION
                                        TYPE 1                   TYPE 2
            Processor        PENTIUM, 486 DX 2, 68040       RISC
            Memory           32 Mb                          32 Mb
            Media
            Hard Drive        1Gb                                  2 Gb
            Floppy Drive      3.5                                  3.5
            Tape Drive        Optional                             Yes
            CD Drive          Yes                                  Yes
            WORM              Optional                             Optional
            Monitor           17"-19” Flat SVGA                    19"-21” High Res

I1.2.1.2 Compute r 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 o lder, 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 pe r 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 Compute r 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. A site license allows the software to be used on any
computer at a particular location.

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 I nformation 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 dr ives, 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, ma naged by a central index or
       locator.

I1.3 Hardware Require ments for Processing Digital Data

I1.3.1 Hardware Require ments 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 capab ility 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
                                   P R     S   C   W   T   W   S   D   S   G   G   I   P   P   N
                                   E  I    C   D   O   A   O   G   A   P   R   R   L   R   L   E
                                   N S     A   /   R   P   R   M   T   R   A   A   S   I   O   T
                                   T C     N   R   M   E   D   L   A   E   P   P   /   N   T   W
                                   I       N   O                   B   A   H   H   L   T   T   O
                                   U       E   M       D           A   D   /   /   S   E   E   R
                                   M       R           R   P   V   S   S   R   V   A   R   R   K
                                   /                   I   R   I   E   H   A   E   R   S   S   S
                                   4                   V   O   E       E   S   C
                                   8                   E   C   W       E   T   T
                                   6                       .   E       T   E   O
                                                               R           R   R
   PROCESS       TECHNICAL
   MANUAL:
   ARCHIVE                         X       X       X   X   X       X       X   X       X       X
   VIEW ONLY                       X           X               X           X
   COMMENT/ANNOTATE                X                   X   X   X       X   X   X       X       X
   UPDATE/MAINTAIN                     X   X       X   X   X       X       X   X       X       X
   EXTRACT/PROC./TRANSF.               X   X   X   X   X   X       X   X   X   X       X       X
   PROCESS       TECHNICAL
   DATA PACKAGE:
   ARCHIVE                             X   X           X   X       X   X   X   X       X   X   X
   VIEW ONLY                       X           X       X   X               X   X               X
   COMMENT/ANNOTATE                X           X       X   X       X       X   X       X   X   X
   UPDATE/MAINTAIN                     X   X       X   X   X       X   X   X   X       X   X   X
   EXTRACT/PROC./TRANSF.               X   X   X   X   X   X       X   X   X   X       X   X   X
   PROCESS ILS/LSAR:
   ARCHIVE                         X                   X   X       X       X       X       X   X
   VIEW ONLY                       X                   X   X       X       X       X           X
   COMMENT/ANNOTATE                X                   X   X       X       X       X       X   X
   UPDATE/MAINTAIN                 X                   X   X       X           X   X   X       X
   EXTRACT/PROC./TRANSF.           X                   X   X       X   X       X   X   X       X




                                               I-12
I1.3.2 Hardware Require ments 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 ca nnot 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 Require ments 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 mod em, 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 individuals involved will require in the creation,
management, and use of a TM.

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 interfac e 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 uninterruptib le 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 Manage ment 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 Informatio n 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
              PG Viking Through Life Information Manage ment Strategy
Editors Ref.:    Subject Group:

fbp/98aaadzf                            Indexing terms
Report title:
Through Life Information                Information Management, Digital Information
Management Strategy                     Through Life, Viking
Work carried out by:
Viking Information Management           No distribution without permission from the
group, see Appendix A                   responsible organizational unit

Edited by:
Nils Sandsmark,
Frank Børre Pedersen
Work verified by:
Boye Tranum                             Limited distribution within PG Viking
Date of this    Rev.    Number
revision:       No.:    of pages:
5 September     03      *               Unrestricted distribution
1998




                                        J-2
                PG Viking Through Life Information Manage ment 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 Manage ment 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 procure ment: 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 Manage ment 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 s upport concept:
  To be decided during study phase.

  Industry involve ment 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 Manage ment Strategy
      To be decided during study phase.

     Intellectual property rights:
      To be decided during study phase.

     How to audit warrantees and incentive mechanis ms:
      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 life-
cycle 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 ma nner as a BPWin model


                                             J-6
               PG Viking Through Life Information Manage ment 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 Environme nt
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, c hoices 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 on-
      line 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 Manage ment 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 Manage ment: 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 Manage ment 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                      Benefit                   Risk
      Solution A    Medium:                     Low:                       Significant:
                    Cost estimate comparable    Off-line methods for       Uncertainty
                    to other solutions          diversified information.   regarding ability
                                                Requires a common data     to adapt to
                                                administration             technological and
                                                                           process changes.
      Solution B    Medium:                     Medium:                    Significant:
                    Cost estimate comparable    On-line methods for        Geographically
                    to other solutions          geographically             distributed data
                                                distributed data.          represents a
                                                Improved accessibility     considerable
                                                due to one logic           technological risk.
                                                structure.



                                               J-9
                   PG Viking Through Life Information Manage ment Strategy
      Solution C       High:                         High:                   Critical:
                       Cost estimate higher than     One multi security      Security
                       comparable solutions          system, with on-line    requirements not
                                                     access to one logical   acceptable.
                                                     structure.

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 old-
        fashioned 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/        PG Viking, Minutes of meeting no 2, March 19, 1998.
  /2/        BPWin User‟s Guide, Logic Works Inc., 1997.
  /3/        List of Swedish legacy systems, FMV, 1998.
  /4/        List of Norwegian legacy systems, SFK, 1998.
  /5/        Criticality Management Tools – Operation Manual, Det Norske Veritas, 1998.
  /6/        Risikomanual – PG Viking, 1998.




                                                   J-10
               PG Viking Through Life Information Manage ment Strategy
                        Appendix A: Participants in the Study

The participants in the Information Management group in the Viking program are:

     Commander T. Grasmo                                     PG Viking
     Major B. Tranum                                         NATO CALS
     Principal Technical Officer U. S. Carlsson              FMV                  Sweden
     Head of Division J. B. Leimand                          FKO                  Denmark
     Captain K. Eikanger (Meeting 1 through 4)               SFK                  Norway
     Senior Eng. V. Småberg (Meeting 5 and onwards)
     Cons. N. Sandsmark                                      DNV




                                               J-11
              PG Viking Through Life Information Manage ment 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           Consequence                                Definition
                      High                 The option inflicts a large cost to the program
  Cost                Medium               The option inflicts a considerable cost to the program
                      Low                  The option inflicts a minor cost to the program
                      High                 The option provides large benefits to the program
  Benefit             Medium               The option provides considerable benefits to the
                                           program
                      Low                  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                                        Definition
       Critical       A critical risk is unacceptable and mitigative actions must be implemented.
                      A Critical risk has both large probability of occurring and large
                      consequence.
     Significant      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
      Negligible      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:   +46 40 34 80 00
         Fax:   +46 40 34 85 04




                  K-1
                PG Viking Through Life Information Manage ment 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 (Preliminært 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 Manage ment 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 Manage ment Plan
                          TABLE OF CONTENTS

1     Purpose
2     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 Manage ment Pla n
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/ (Preliminært 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 Manage ment Pla n

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

The three nations naval material commands are located in:

      Naval Material Command Norway (Sjøforsvarets Forsyningskommando, SFK):
       Haakonsvern Naval Base, Bergen, Norway.
      Swedish Defense Material Administration (Forsvarets Materiellverk, FMV):
       Stockholm, Sweden.
      Naval Material Command Denmark (Søværnets Materielkommando, SMK): Holmen,
       Copenhagen, Denmark

2.2 Previously defined require ments
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 t he 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 Manage ment Pla n
       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 Manage ment Pla n
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 Manage ment Pla n

                                       Through Life Business Model


                                                Operate
                                                Linking
                 Define User Needs
                    and specify              Configuration
                   Requirements                   and
                                               Structure
                                                                          Support
                                               Product
                                                 ID




                             Design
                                                     Produce


                                       Management Information
                                       Management 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 sa me 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 Manage ment Pla n
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 prod uction.




                                            K-10
                 PG Viking Through Life Information Manage ment Pla n



                                          Obj
                                                           Strategy and policies
                                          Ops req

                                     Acquisition
                                      strategy
                              Master            Budget
                               plan                           Time and economy
                                       PMP
                              StoW              ILS-Plan
                                                                 Quality
                                          SSS                    (Functionality and performance)
                                           VIKING

                                   SSS    SSS   SSS
                                   IPC          IWS
                                  (P01)

                              SSS                                            Sub-functions and diciplines
                            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-CMAN-
80534 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 Manage ment Pla n
        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.   AP 215 Arrangements
   2.   AP 216 Molded Forms
   3.   AP 217 Piping
   4.   AP 218 Structures
   5.   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 Manage ment Pla n
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 long-
term 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 Alte rnative 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 ho w 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
                 PG Viking Through Life Information Manage ment Pla n
   1.   Maintenance
   2.   Supply chain
   3.   Configuration management/Change control
   4.   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 s upport 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 manage ment/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 pa rts. This


                                              K-14
                 PG Viking Through Life Information Manage ment Pla n
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 Alte rnative 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 Manage ment Pla n
       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 Ope ration
This implies information necessary to conduct Operational Logistics, including co-operative
logistics with other elements and weapon systems.

4.2.4.1 Ope rational Information Require ments
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 informa tion
requirements and handling.

5. Hardware requirements inclusive basis SW.
At present, no specific requirements have been identified. Hardware requirements will be


                                             K-16
                PG Viking Through Life Information Manage ment Pla n
determined at contract point according to functional performance requirements.

6. SoftWare Applications Require ments
Which software applications will be use for each information group throughout the lifecycle
activities.

        Define user needs and            Design/Construction         Support/Operation
         specify requirements
        Microsoft Systems               Open PDM systems           Open PDM, etc.
          Engineering software           CAD, CAE and other          and/or national
        Open PDM systems                 design systems              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 Environme nt
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 Manage ment Pla n
      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 o rder 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 Manage ment Pla n

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 (Preliminært 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 Manage ment Plan
                               Appendix A: Participants in the Study
    The participants in the Information Management group in the Viking program are:

        Commander T. Grasmo                                 PG Viking
        Lieutenant Colonel B. Tranum                        NATO CALS
        Principal Technical Officer U. S. Carlsson          FMV              Sweden
        Head of Division J. B. Leimand                      FKO              Denmark
        Captain K. Eikanger (Meeting 1 through 4)           SFK              Norway
        Senior Eng. V. Småberg (Meeting 5 and onwards)
        Cons. N. Sandsmark                                  DNV

-     o0o –




                                              K-20
               PG Viking Through Life Information Manage ment 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:           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.

      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:             Persons or organization that uses information stored in the
                               VIMS
      PMO
      Naions (N)
      Prime contractor (PC)
      Steering Committee (SC)
      Support organizations (SO)




                                            K-21
                                            PG Viking Through Life Information Manage ment Plan
                                                      Appendix B: Information Analysis
       TLBM Leaf           Information Objects            TLBM Information      Inf.        Inf. Owne r   Inf.      Inf. Users
       Processes                                          flow (arrows)         Creator                   Manager
       A111                Solutions to meet the          Solution Analysis     PMO         PMO           PMOIM     PMO, SC
       Analyse Candidate   identified mission need        Result
       Solutions           Defined constraints for                              N           N             PMOIM     PMO, PC
                           selection of a solution
                           Approach and evaluation                              PMO         PMO           PMOIM     PMO, SC
                           criteria for the analysis
                           Approach for choosing,                               PMO         PMO           PMOIM     PMO, SC
                           selecting, and studying the
                           candidate solutions
K-22




                           Rationale and results of the                         PMO         PMO           PMOIM     PMO, SC
                           analysis.

       A112                Detailed and precise set of   Detailed and precise set   PMO, PC   PMO         PMOIM     PMO, SC,
       Derive And          requirements                  of requirements                                            PC
       Allocate            System functions, objects,                               PMO, PC   PMO         PMOIM     PMO, SC,
       Requirements        people, and supporting                                                                   PC
                           processes, products, and
                           services which requirements
                           are allocated to
                           Derived requirements to                                  PMO, PC   PMO         PMOIM     PMO, SC,
                           lower level functions or                                                                 PC
                           objects
                           Status and traceability of                               PMO, PC   PMO         PMOIM     PMO, SC,
                           requirements                                                                             PC
                                         PG Viking Through Life Information Manage ment Plan
                                                    Appendix B: Information Analysis
       TLBM Leaf          Information Objects           TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                        flow (arrows)         Creator                  Manager
       A113               A system design with key      System Architecture   PMO, PC PMO              PMOIM     PMO, SC,
       Evolve System      design issues.                                                                         PC
       Architecture       Architecture requirements                           PMO, PC PMO              PMOIM     PMO, SC,
                                                                                                                 PC
                          Functional and physical                                PMO, PC   PMO         PMOIM     PMO, PC
                          structure and interfaces
                          Allocated architecture                                 PMO, PC   PMO         PMOIM     PMO
                          requirements to system
                          elements
                          Functional (or logical),                               PMO, PC   PMO         PMOIM     PMO, SC,
K-23




                          physical (tangible), and                                                               PC
                          foundation architectures

       A114               Disciplines necessary for      Necessary disciplines   PMO, PC   PMO         PMOIM     PMO, SC,
       Integrate          effective system                                                                       PC
       Disciplines        development
                          Co-operative environment                               PMO, PC   PMO         PMOIM     PMO, SC,
                                                                                                                 PC

       A115               Identified, defined, and       Current Req             PMO, PC   PMO         PMOIM     PMO, PC
       Integrate System   controlled interfaces
                          Verified system functions                              PMO, PC   PMO         PMOIM     PMO, SC,
                          that require multiple system                                                           PC
                          elements
                                     PG Viking Through Life Information Manage ment Plan
                                              Appendix B: Information Analysis
       TLBM Leaf      Information Objects          TLBM Information      Inf.        Inf. Owne r   Inf.      Inf. Users
       Processes                                   flow (arrows)         Creator                   Manager
       A121           High level Life Cycle        LC Strat and Pol.     N R&R,      NR&R, SC      PMOIM     PMO, PC
       Define Lc      Strategies and Policies                            SC, PMO
       Strategy
       And Policies

       A122           Approach to be taken in        Acq Strat           N R&R,      N R&R, SC     PMOIM     PMO, PC
       Define         acquiring a service or                             SC, PMO
       Acquisition    VIKING component,
       Strategy       initially
                      Approach to be taken in                            N R&R,      N R&R, SC     PMOIM     PMO, PC
K-24




                      acquiring a service or                             SC, PMO
                      VIKING component, for re-
                      supply.
                      Method of acquisition                              N R&R,      N R&R, SC     PMOIM     PMO, PC
                                                                         SC, PMO
                      Use of competition and or                          N R&R,      N R&R, SC     PMOIM     PMO, PC
                      partnering arrangements                            SC, PMO
                      Contract incentive                                 N R&R,      N R&R, SC     PMOIM     PMO, PC
                      mechanisms                                         SC, PMO
                      Determination of what rights                         N R&R,    N R&R,        PMOIM     PMO, PC,
                      and what data must be                               SC, PMO    PMO                     SC
                      acquired as part of the
                      contract, or separately.

       A123           Program approach to            Risk Man Strategy   PMO         SC            PMOIM     PMO, PC,
       Define Risk    identifying, assessing and                                                             SC
       Strategy       managing risk
                                    PG Viking Through Life Information Manage ment Plan
                                               Appendix B: Information Analysis
       TLBM Leaf     Information Objects           TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                   flow (arrows)         Creator                  Manager
       A124          Strategy and plan to show     ILS Strategy          PMO, N     PMO           PMOIM     N, PMO, PC,
       Develop Ils   how ILS will be                                     R&R, PC                            SC
       Strategy      implemented for the
                     VIKING System over its full
                     life cycle.

       A125          Strategy and plan to show       CM Strategy        PMO, N      PMO           PMOIM     N, PMO, PC,
       Develop Cm    how CM will be                                     R&R, PC                             SC
       Strategy      implemented for the
       And Plan      VIKING System over its full
K-25




                     life cycle.

       A126          Actions required to ensure      QA Strategy        PMO, N      PMO           PMOIM     N, PMO, PC,
       Develop Qa    systematic approaches                              R&R, PC                             SC
       Strategy      Integrated concurrent design,                      PC, PMO     PC, PMO       PMOIM,    PC, N, PMO
       And Plans     manufacture and support of                                                   PCIM
                     the VIKING System and the
                     related processes
                                         PG Viking Through Life Information Manage ment Plan
                                                    Appendix B: Information Analysis
       TLBM Leaf           Information Objects          TLBM Information      Inf.       Inf. Owne r      Inf.      Inf. Users
       Processes                                        flow (arrows)         Creator                     Manager
       A127                Assessment of the business   TLIM Strategy and     N R&R,     PMO              PMOIM     PC, PMO,
       Develop TLIM        and Through Life             Plan                  PMO                                   SC
       Strategy and Plan   Information Management
                           (TLIM) Environment
                           Program goals for TLIM                             SC, PMO PMO                 PMOIM     PC, PMO,
                                                                                                                    SC
                           Assessment of the costs,                                  PMO, PC    PMO       PMOIM     PMO, SC
                           risks, and benefits of the
                           options of TLIM
K-26




       A131                Program WBS                     Program WBS and           PMO, SC    PMO, SC   PMOIM     PMO, SC,
       Manage                                              Program Schedule                                         PC
       Program              Service Level Agreements                                 PMO, PC,   PMO, PC   PMOIM,    PMO, PC,
       Schedule            needed to specify the                                                          PCIM      SC, N
                           standard of ongoing services.
                           Proposed changes to                                       PC, PMO,   PMO       PMOIM     PMO, PC, N,
                           implement or reject                                       N                              SC
                           Top level Program schedules                               SC         SC        PMOIM     PMO, PC, N

       A132                Allocated responsibility for    Org Structure and         PMO, SC,   PMO, N    PMOIM,    PMO, N, PC
       Establish           the various program task        Requests for Assistance   N                    PCIM
       Roles And           over the life cycle             and
       Relationships       Tasks to be placed on           Activities to be          PMO, SC,   PMO, N    PMOIM     PMO, PC, N
                           contract.                       contracted                N
                           Mechanisms for                                            PMO, SC,   PMO, N    PMOIM     PMO, PC, N
                           incentivising and ending                                  N
                           contracts
                                            PG Viking Through Life Information Manage ment Plan
                                                       Appendix B: Information Analysis
       TLBM Leaf            Information Objects            TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                           flow (arrows)         Creator                  Manager
       A1331                Program, specific              Contract Strategy     PMO, SC PMO              PMOIM     PMO, PC
       Develop Contract     documented requirements
       Strategy             levied by the negotiated
                            contract or agreement.
                            Insurance that Staff Target,                         PMO, SC PMO              PMOIM     PMO, PC
                            program objectives, and
                            implementation plans are
                            incorporated in contractual
                            definitions and design
                            information
K-27




                            Programmed available                                 PMO, SC, PMO             PMOIM     PMO, N
                            funding into the contractual                         N
                            process
                            Initiation and execution of                          PMO, SC, PMO             PMOIM     PMO, N
                            appropriate agreements                               N
                            which may fall outside of the
                            specific contract

       A1332                Prepared contractual         Invitation to Tender   PMO, SC     PMO           PMOIM,    PMO, PC
       Issue Solicitation   solicitation or tender                                                        PCIM
                            including the Statement of
                            Work, the Evaluation
                            Criteria, and the Contract
                            Deliverables.
                                         PG Viking Through Life Information Manage ment Plan
                                                    Appendix B: Information Analysis
       TLBM Leaf          Information Objects           TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                        flow (arrows)         Creator                  Manager
       A1333              Assessment of formal          Selected Contractor   PC         PC, PMO       PCIM,     PMO, SC
       Assess Proposals   responses                                                                    PMOIM
                          Selected successful bidder.                         PMO, SC SC               PMOIM     PMO, SC,
                                                                                                                 PC

       A1334              Activities required to place    Contracts and Contract   PMO, PC    PMO      PMOIM     PMO, PC,
       Run Contract       and operate the contract over   Dir.                                                   SC
                          its life time
                          Assessment of achievement                                PMO, SC    PMO      PMOIM     PMO, SC,
                          against requirements                                                                   PC
K-28




                          Approval of payments                                     PMO        PMO      PMOIM     PC
                          Resolution of issues arising.                            PMO, PC,   PMO      PMOIM     PMO, PC,
                                                                                   SC, N                         SC, N

       A134               Acquiring, allocation, and      Budget Req               PMO, SC    PMO      PMOIM     PMO, N, SC
                          accounting for the funds        Available Funding and
       Manage             needed to provide VIKING        Predicted LCC
       Viking Lc          through life.
       Funding             Forecasting and tracking                                PMO, PC    PMO, N   PMOIM     PMO, SC, N
                          VIKING Life Cycle Cost.

       A135               Plans, monitor action and       Allocated Manpower       PMO, N     PMO      PMOIM     PMO, N, SC,
       Manage Human       control of provision of                                                                PC
       Resources          human resources for
                          VIKING program lifecycle.
                                       PG Viking Through Life Information Manage ment Plan
                                                  Appendix B: Information Analysis
       TLBM Leaf       Information Objects            TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                      flow (arrows)         Creator                  Manager
       A1361           Defined the program            SDE Req. and          PMO, N     PMO           PMOIM     PMO, PC, N,
       Develop         Information requirements       IM Plan                                                  SC
       Im Plan         Defined IT-infrastructure                            PMO, N     PMO           PMOIM     PMO, PC, N,
                       requirements                                                                            SC
                       Plan for capturing,                                  PMO, N     PMO           PMOIM     PMO, PC, N,
                       controlling and delivering                                                              SC
                       the required information to
                       users.

       A1362           Design of the Shared Data     Contract Information   PMO, N,    PMO           PMOIM     PMO, PC, N,
K-29




       Establish and   Environment                   Req and                PC                                 SC
       Operate         Acquisition plan of the       Program SDE            PMO, N,    PMO           PMOIM     PMO, PC, N,
       Program Sde     Shared Data Environment                              PC                                 SC
                       Deployment plan for the                              PMO, N,    PMO           PMOIM     PMO, PC, N,
                       Shared Data Environment                              PC                                 SC
                       Guides and rules for use of                          PMO, N,    PMO           PMOIM     PMO, PC, N,
                       the Shared Data                                      PC                                 SC
                       Environment


       A1363           Describe Information          Information Services   PMO, PC    PMO, PC       PMOIM,    PMO, PC, N
       Provide         Services                                                                      PCIM
       Information
       Services
                                          PG Viking Through Life Information Manage ment Plan
                                                      Appendix B: Information Analysis
       TLBM Leaf          Information Objects             TLBM Information      Inf.      Inf. Owne r   Inf.      Inf. Users
       Processes                                          flow (arrows)         Creator                 Manager
       A14                Comparison of actual system Perf Rep and              PMO, PC PMO, PC         PMOIM,    PMO, N, PC
       Compare Actual     state and performance with      Inst to Ops and                               PCIM
       System State and   that required                   Change Proposal
       Performance With   Identified the need for                               PMO; PC, PMO, PC        PMOIM,    PMO, PC, N
       Required           changes                                               N                       PCIM
                          Changes Proposal,                                     PMO, PC, PMO, PC        PMOIM,    PMO, PC, N
                                                                                N                       PCIM
                          Acceptability of requests for                         PMO, N    PMO           PMOIM,    PMO, PC, N
                          waivers or concessions for                                                    PCIM
                          components which fall short
K-30




                          of the design intent
                          Report on the performance of                          PMO, PC, PMO, PC        PMOIM,    PMO, PC, N
                          the VIKING System and the                             N                       PCIM
                          VIKING Program
                          Advice to Operators over                              PMO, PC, PMO, PC        PMOIM,    PMO, PC, N
                          specific design limitations                           N                       PCIM

       A211               Reviewed operational threat       In Service Goals and   PMO, N    PMO        PMOIM     PMO, SC
       Develop            and Mission Need                  VIKING Concept
       Conceptual         Identified and evaluated                                 PMO, N,   PMO        PMOIM     PMO, SC,
       Options            potential alternative solutions                          PC                             PC, N
                          Selected conceptual solution                             PMO, SC   PMO        PMOIM     PMO, PC, N,
                                                                                                                  SC
                                     PG Viking Through Life Information Manage ment Plan
                                                 Appendix B: Information Analysis
       TLBM Leaf     Information Objects             TLBM Information        Inf.    Inf. Owne r   Inf.      Inf. Users
       Processes                                     flow (arrows)           Creator               Manager
       A212          Functional design of the        Change Impact and       PMO, PC PMO, PC       PMOIM,    PMO, PC,
       Define        VIKING System                   Proc Spec and                                 PCIM      SC, N
       Viking        Analysis of the design          Test Def and            PMO, PC PMO, PC       PMOIM,    PMO, PC,
       System        features needed by the          Functional Architecture                       PCIM      SC, N
                     subsequent manufacturing,
                     transportation, use, support,
                     and disposal processes
                     Required functionality of                               PMO, PC PMO, PC       PMOIM,    PMO, PC,
                     systems, sub systems and                                                      PCIM      SC, N
                     components for both the
K-31




                     operational system and the
                     support system
                     Acceptance criteria for test                            PMO, PC PMO, PC       PMOIM,    PMO, PC,
                     and evaluation                                                                PCIM      SC, N
                     Identification of items that                             PC     PC            PCIM      PMO, PC,
                     can be bought from                                                                      SC, N
                     suppliers, and which still
                     require to be designed.

       A213          Detailed engineering design   Mfr and Rfb data and    PC        PC            PCIM      PMO, PC, N
       Engineering   activities                    Core Product Data and
       Design        Product model for the                                 PC        PC            PCIM      PMO, PC, N
                     VIKING System and its
                     support equipment
                     Manufacturing,                                        PC        PC            PCIM      PMO, PC, N
                     refurbishment and disposal
                     processes.
                                   PG Viking Through Life Information Manage ment Plan
                                              Appendix B: Information Analysis
       TLBM Leaf   Information Objects            TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                  flow (arrows)         Creator                  Manager
       A214        Failure modes, effects and     FMECA Data            PC, PMO PC, PMO          PCIM,     PC, PMO, N
       Failure     criticality                                                                   PMOIM
       Analysis    Product anomaly, criticality,                        PC, PMO PC, PMO          PCIM,     PC, PMO, N
                   causes/effects and                                                            PMOIM
                   compensating provisions
                   Diagnostic and                                       PC, PMO PC, PMO          PCIM,     PC, PMO, N
                   troubleshooting                                                               PMOIM
                   recommendations.
                   Expected frequency of                                PC, PMO PC, PMO          PCIM,     PC, PMO, N
                   failure                                                                       PMOIM
K-32




                   Expected reliability.                                PC, PMO PC, PMO          PCIM,     PC, PMO, N
                                                                                                 PMOIM
                                    PG Viking Through Life Information Manage ment Plan
                                               Appendix B: Information Analysis
       TLBM Leaf    Information Objects            TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                   flow (arrows)         Creator                  Manager
       A215         Procedures and data needed     Support Info and      PMO, PC, PMO, N          PMOIM     PMO, PC, N
       Design The   to provide an optimized        Reqd Feedback and     N
       Support      support capability             Trg Req and
       System       Procedures for operating,      Support Equipment     PMO, PC, PMO, N          PMOIM     PMO, PC, N
                    servicing and maintaining      Requirements          N
                    Viking including diagnostics
                    and post repair tests
                    Intentions for managing the                          PMO, PC, PMO, N          PMOIM     PMO, PC, N
                    initial and ongoing supply of                        N
                    materials, components and
K-33




                    spares required for
                    manufacture and in-service
                    use
                    Form of stock management                             PMO, PC, PMO, N          PMOIM     PMO, PC, N
                                                                         N
                    Policies and procedures for                          PMO, PC, PMO, N          PMOIM     PMO, PC, N
                    the return, assessment,                              N
                    refurbishment and disposal
                    of items no longer required
                    Policies and procedures for                          PMO, PC, PMO, N          PMOIM     PMO, PC, N
                    supplying operators and                              N
                    maintainers with the
                    information they require to
                    perform
                    Define feedback needed                               PMO, PC, PMO, N          PMOIM     PMO, PC, N
                    from operators and                                   N
                    maintenance staff to
                    optimize the performance of
                    the support system
                                            PG Viking Through Life Information Manage ment Plan
                                                       Appendix B: Information Analysis
       TLBM Leaf            Information Objects            TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                           flow (arrows)         Creator                  Manager
                            Procedures for data                                  PMO, PC, PMO, N          PMOIM     PMO, PC, N
                            collection and analysis.                             N
                            Training requirements for                            PMO, PC, PMO, N          PMOIM     PMO, PC, N
                            operators and maintainers.                           N

       A216                 Expected performance of           Predicted Perf        PMO, PC   PMO         PMOIM     PMO, PC, N
       Predict Life Cycle   VIKING
       Performance          Prediction of system                                    PMO, PC   PMO         PMOIM     PMO, PC, N
                            capability, life, availability,
                            readiness and life cycle cost.
K-34




       A22                  Fabrication, assembly and         As-built Config and   PC        PC          PCIM      PMO, PC, N
       Produce              production testing of the         Tools and Facs. and
       Viking               Operational VIKING                Spares and
       System               Refurbishment of items            Components and        PC        PC          PCIM      PMO, PC, N
                            returned from service             VIKING System for
                                                              Deployment and
                                                              Items for Test


       A23                  Measuring results for the         Test Findings         PMO, N    PMO         PMOIM     PMO, PC, N
       Conduct Testing      performance of all VIKING
                            components
                            Defined supportability                                  PMO, N    PMO         PMOIM     PMO, PC, N
                            features, processes and
                            equipment
                                           PG Viking Through Life Information Manage ment Plan
                                                      Appendix B: Information Analysis
       TLBM Leaf           Information Objects            TLBM Information      Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                          flow (arrows)         Creator                  Manager
       A24 Deploy Viking   Activities needed to, receive, VIKING System ready PMO, N       PMO, N        PMOIM     PMO, N, PC
       System              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
K-35




       A 31                What work to do, in what        Required Items and   PMO, N     PMO, N        PMOIM.    PMO, N, PC
       Plan Support        order, on the systems           Support Plan and                              NIM
                           awaiting support                Req Config
                           Specification of the required                        PMO, N     PMO, N        PMOIM.    PMO, N, PC
                           configuration for each                                                        NIM
                           individual system
                           Requirement for items to be
                           purchased for use in support
                           activities.

       A32                 Items needed for                Items for Use        N, PMO     N             PMOIM     PMO, N, PC
       Store               maintenance or to support
       Transport and       VIKING on operational use
       Issue Items
                                    PG Viking Through Life Information Manage ment Plan
                                             Appendix B: Information Analysis
       TLBM Leaf    Information Objects           TLBM Information      Inf.        Inf. Owne r   Inf.      Inf. Users
       Processes                                  flow (arrows)         Creator                   Manager
       A33          Work needed to restore        Returned Items and    N           N             NIM       N
       Maintain,    VIKING to the condition       Feedback fm
       Update and   required for the next         Maintenance and
       Provide      intended operation            Maintained Submarines
       Feedback     Updated configuration         and As- maint Config  N           N             NIM       N
                    changes
                    Maintenance feedback on                             N           N             NIM       N
                    findings
                    Action taken and issues                             N           N             NIM       N
                    arising
K-36




       A34          Activities needed to prepare       VIKING System ready   N        N           NIM       N
       O&S Tasks    the system for operations          for Ops

       A35          Activities needed to sustain       Returned Items        N        N           NIM       N
       Manage       the “special to type” facilities
       Facilities   and tools in a fit for use
                    condition.

       A36          Tasks, actions, and activities     Trained People        N, PMO   N           NIM       N
       Train        to achieve and maintain the
       Support      knowledge and skill levels
       Staff        necessary to efficiently and
                    effectively perform
                    operations, support and
                    disposal.
                                    PG Viking Through Life Information Manage ment Plan
                                             Appendix B: Information Analysis
       TLBM Leaf     Information Objects          TLBM Information       Inf.       Inf. Owne r   Inf.      Inf. Users
       Processes                                  flow (arrows)          Creator                  Manager
       A37           Evaluation of a VIKING       Evaluation Findings    N, PMO     N             NIM       PMO, N
       Conduct       operational and support      and
       Evaluations   capabilities                 In-Scope Eval Findings
                     Conclusions and
                     recommendations

       A4            Identify activities related    Disposed Items and   N          N             NIM       N
       Dispose Or    with the retired VIKING        Items for Rfb
       Recycle       Systems and VIKING
                     components for disposal or
K-37




                     refurbishment
                     Assessment of the state of                          N          N             NIM       N
                     the item
                     Decide on whether to                                N          N             NIM       N
                     refurbish for use within the
                     program, make it available
                     for use by others
                   PG Viking Through Life Information Manage ment Plan
                     Appendix C: Process for Information Manage ment
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                                       Realisation

            TLBM                         TLBM, PLCS      PLCS, TLBM        MIL-STD
                                                                           490A
                                                                           961D



      Business process
          analyse                                                                Design
                                                                                 process
                                  Information-           Techniques               Information

                   Business          analyse
                   processes


                                                        Informatics-
                                          Information      analys


                                    Tailoring


                                               K-38
                PG Viking Through Life Information Manage ment Plan
                  Appendix C: Process for Information Manage ment

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 I2-
process 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 Manage ment Plan
                  Appendix C: Process for Information Manage ment

     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 Manage ment 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.         Relationships should be


                                             K-41
               PG Viking Through Life Information Manage ment Plan
                             Appendix D: Product Definition
maintained throughout the life-cycle.

                                product_                     product_
                                requirement_   product_      instance_     product_
               product_
                                product_       concept       product_      instance
               requirement
                                concept_                     concept_
                                association                  association




                                               product_
                                               concept_
                                               product_
                                               design_
                                               association




               product_
               requirement_                    product_
               product_                        design
               design_
               association


                              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 in-
service.” 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 Manage ment 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 logis tic
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. In fact, there is a
specific and unique set of data and relationships for each product_instance.

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 user‟s 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 Manage ment Plan
                                Appendix D: Product Definition

       classification _of_         class_of_
                                                 classification _of_
       class _of_product_          product_
                                                 product _concept
       concept                     concept




                             product _concept_                           (ABS)
       usage_                                                                                 class_of_product_
                             usage_scenario_     product _concept        product _concept_
       scenario                                                                               concept_relationship
                             association                                 relationship




                                    class_of_
       classification _of_
                                    usage_                  product_       product_          classified_
       usage_scenario
                                    scenario                concept_       concept_          product _concept_
                                                            succession     composition       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 worst-
       case scenario in peacetime and wartime employment are examples of usage_scenario
       classes.

 Product Require ment
 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
 user‟s needs.


                                                            K-44
                PG Viking Through Life Information Manage ment Plan
                          Appendix D: Product Definition


                                     product_concept_
               product_                                           usage_
                                     usage_scenario_
               concept                                            scenario
                                     association


                                   applies_to
                                                       is_realized_by

                                                               product_
                                       product_                physical_
                                       requirement             design



                  Figure 4 – Product_re quireme nt 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. A typical
association is the one used to identify the organization defining the requirements.

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 Manage ment 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_
                                              (ABS)                      product_instance_
           requirement_
                                                                         product_design_
           product_design_                product_design
                                                                         association
           association




                         functional_                          physical_
         product_        design_             product_         design_           product_
         functional_     physical_           physical_        support_          support_
         design          design_             design           design_           design
                         relationship                         relationship


                                         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 Manage ment Plan
                          Appendix D: Product Definition

                                                                 product_
                                                                 concept



                                  product_requirement_        product_concept_
               product_
                                  product_concept_            usage_scenario_
               requirement
                                  association                 association



                                              applies_to         usage_
                         is_realized_by                          scenario
                product_               product_
                physical_              functional_
                design                 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 Manage ment 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 Manage ment Plan
                               Appendix D: Product Definition

       classification_of_         class_of_         classification_   product_requirement_
       class_of_                  product_          of_product_       product_concept_
       product_                   functional_       functional_       association
       functional_design          design            design



                                                                                (ABS)
                            identification_of_                            product_functional_
                            functional_design                             design_relationship
      organization

                            control_of_                                         functional_
                            functional_design        product_                   breakdown
                                                     functional_
                                                     design                     causal_           causal_
       product_         functional_design_                                      relationship      chain
       physical_        physical_design_
       design           association                                             classified_     class_of_
                                                                                relationship    relationship

       product_         functional_design_                                functional_
       support_         support_design_                                   design_                control_
       design           association                                       control_port_          port
                                                                          association


                                                 functional_design_
                         1,3 property_                                     functional_design_
                                                 property_
                        representation                                     property
                                                 association

                     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 struct ure 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 Manage ment 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 user‟s 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 cond ucted, 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 Manage ment 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 many
product_physica_design and happens in the context of one or many
product_functional_design and of one or many usage_scenario. (See Figure 8).


                                                                 product_
                                                                 concept



                    product_           functional _design_   product_concept_
                    functional_        usage _scenario_      usage_scenario_
                    design             association           association


                             in_the_context_of
                                                                 usage_
                                                                 scenario
                product_      failure _of
                physical_                   failure
                design

                                   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 Manage ment 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 3               failure_
                                                       relationship
                            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 Manage ment Plan
                          Appendix D: Product Definition
                                                                         product_
                                                                         concept



                   product_             functional _design_          product _concept_
                                                                                                  usage_
                   functional_          usage _scenario_             usage_scenario_
                                                                                                  scenario
                   design               association                  association


                                                     _the_context_of
                                                    in

                           failure_of                              task_            in_scenario
              product_
              physical_                     failure                failure_
              design                                               association


                                                      applies_to
                                        product_
                                        physical_                      task
                                        design

                             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 roll-
      up 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 Manage ment 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 Manage ment 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 Life-
cycle 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 … ENDCAS E);
     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 Manage ment 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 Manage ment 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 Manage ment Plan
                               Appendix D: Product Definition
                              product_            class_of_product_         classification_of_
                              instance_           instance_                 class_of_
                              characteristics     characteristics           characteristics
     classification_of_
     class_of_product_
     instance                 product_instance_           1,3
                              characteristics_     characteristics_
                              assignment            representation
     class_of_product_
     instance



                                                       product_                  location
     classification_of_                                operating_
     product_instance                                  scenario

                                                       product_
                                                       instance_
      product_design          product_instance         identification

                                                                                 organization
                                                       product_
                                                       instance_
                                                       ownership
      product_concept

                                                       product_
                                                       instance_
                                                       control



                              product_instance_
                              relationship        product_          product_      product_       product_
                                                  instance_         instance_     instance_      instance_
                                                  assembly          succession    collection     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 previo us 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 Manage ment 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, let‟s
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 Manage ment 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 manufacturer‟s
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 Manage ment Plan
                                  Appendix D: Product Definition
                                                                         Organization ID
                                                                              GC-991
                                                                              GC-082
                                                                              GC-076
                                                                              GC-354


       AS-REQUIRED                           AS-DESIGNED                                   AS-MANUFACTURED                       AS-USED


           Truck Req.                                                   Tech Data
                                                   Truck                                               Truck                          Truck
             RN-01                                PN -011                                             SN-4030
                                                                       Support Data                                                  UI-3210
           RN-11
           RN-12                         Engine              Chassis                        Engine           Chassis
                                        PN-02950            PN-02398                       SN-33030         SN-00340       Engine               Chassis
                                                                                                                          SN-33030             SN-00340
          Engine Req.
                                            Tech Data           Tech Data
            RN-110
                                                                                                   Truck                              Truck
                                          Support Data        Support Data                                                           UI-3211
            RN-1101                                                                               SN-3907

            RN-1102                                                     Tech Data
                                                   Truck                                                                   Engine               Chassis
                                                                                            Engine           Chassis      SN-54890             SN-00631
                                                  PN -012              Support Data
          Engine Req.                                                                      SN-54890         SN-00631
            RN-115
                                         Engine              Chassis
            RN-1151                                                                                Truck                              Truck
                                        PN-02960            PN-02398                                                                 UI-3212
                                                                                                  SN-3908
            RN-1152
                                            Tech Data           Tech Data
            RN-1153                                                                                                        Engine              Chassis
                                          Support Data        Support Data                  Engine              Chassis   NSN-2219             SN-001
                                                                                           SN-00323             SN-9001


     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 Pers pective
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.S N- 00323.GC- 076.NS N-2219

The Designer Perspective
To be developed




                                                                                K-61
               PG Viking Through Life Information Manage ment 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        support
       product_requirement                                            product_instance
                                          product_design

          Figure 12 – Product Objects Affected by Diffe rent 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 Manage ment 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 Manage ment 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_             product_            product_     product_
                                              concept              requirement         design       instance




                                                                             target_select




                                              request_                                            directive_
                   (ABS)                                                  implementation_                           actual_
                                              directive_                                          resolution_
                   request                                                directive                                 resolution
                                              relationship                                        relationship




                                                                                                       identifier
        initial_             (ABS)
        issue                change_
                                                     approval                                            label
                             request                                      (ABS)
                                                                          configurantion_
                                                                                                      date_and_
                                                    organization          change_item
                                                                                                      time
       enhancement              discrepancy
                                                                                                      text_select




                                 Figure 13 – High level diagram for Change Control




                                                                            K-64
                PG Viking Through Life Information Manage ment 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 Manage ment 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 Manage ment Plan
                Appendix E: Information Manage ment 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 Owne rship
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.

Publis hing 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 Procure ment
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 Manage ment Plan
                 Appendix E: Information Manage ment 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 directo r 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 Manager’s 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, I‟ve 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 user‟s 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. That‟s 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. Curre nt 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 someone‟s head, forgotten about in a file somewhere, or locked on someone‟s
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 re-
created. 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 person‟s 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 member‟s 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 sys tems, 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
else‟s 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 docume nt
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 affectionate ly called the
“Paperless PM.” The book also serves as an outstanding desk reference.

In closing, I‟ll 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

								
To top