Professional Documents
Culture Documents
APPENDICES
March 1, 2000
TABLE OF CONTENTS
APPENDIX A: CALS CONCEPTS .......................................................................................... A-1
A1.0 CALS CONCEPTS ........................................................................................................... A-1
A2.0 WHAT IS NATO CALS? ................................................................................................. A-1
A2.1 Importance of CALS to NATO ............................................................................. A-1
A2.1.1 Roles and Responsibilities of NATO with Respect to CALS ................ A-2
A2.1.1.1 Internal Roles .......................................................................... A-2
A2.1.1.2 External Role........................................................................... A-2
A2.2 NATO CALS Objectives ...................................................................................... A-3
A2.2.1 Increase Interoperability......................................................................... A-3
A2.2.2 Decrease Defense Equipment Life-cycle costs...................................... A-3
A2.2.3 Ensure the Readiness of NATO Forces ................................................. A-3
A2.2.4 Decrease Acquisition Lead Times ......................................................... A-3
A2.2.5 Increase the Quality of Delivered Products ........................................... A-3
A2.3 Management Vision and Leadership ..................................................................... A-4
A2.3.1 NATO CALS Vision.............................................................................. A-4
A2.3.2 The Critical Importance of Leadership .................................................. A-4
A2.4 The Need to Accommodate Change ..................................................................... A-5
A2.5 The Extended Enterprise ....................................................................................... A-5
A2.6 The NATO Extended Environment ...................................................................... A-7
A2.7 Information Process and Tool Elements ............................................................... A-7
A2.8 Controlled Access ................................................................................................. A-7
A2.9 Data Sharing and Collaboration............................................................................ A-8
A2.10 Digital Data Exchange ........................................................................................ A-8
A2.11 Information Architecture..................................................................................... A-8
A2.12 Product Data Management .................................................................................. A-8
A2.13 User Applications................................................................................................ A-9
A2.14 Infrastructure Elements ....................................................................................... A-9
A2.15 Telecommunications ........................................................................................... A-9
A2.16 Desktop ............................................................................................................. A-10
A2.17 Hardware and Operating Systems ..................................................................... A-10
A2.18 Policy and Standards Elements ......................................................................... A-10
A2.19 Training and User Support Ele ments ................................................................ A-11
A2.20 Multi-Disciplinary Work Groups ...................................................................... A-12
APPENDIX B:
NATO CALS DATA MODEL EXPRESS G DIAGRAMS
AND EXPRESS DEFINITIONS.................................................................................................B-1
APPENDIX C: TLBM V 6.01 ACTIVITY DEFINITIONS ..................................................... C-1
C1.0 TLBM V 6.01 ACTIVITY DEFINITIONS ...................................................................... C-1
C2.0 TLBM 6.01 ICOM REPORT ............................................................................................ C-9
APPENDIX D: PRODUCT, PROCESS, AND DATA INTEGRATION................................. D-1
D1.0 INTRODUCTION ............................................................................................................ D-1
D2.0 DIGITAL REPRESENTATION FOR COMMUNICATION OF PRODUCT DATA:
IGES APPLICATION SUBSETS AND IGES APPLICATION PROTOCOLS ....................... D-1
D2.1 Purpose .................................................................................................................. D-1
D2.2 Scope ..................................................................................................................... D-1
ii
iii
iv
vi
A-1
The emerging role of NATO is one involving a new flexibility for the deployment of NATO
systems, where a faster response to diverse locations is required with smaller, better equipped
forces. Of equal significance, is the greater multinational integration within the newly formed
force structures, such as the Rapid Reaction Corps and the allied NATO Air Force. This
multinational context is becoming even more prominent as new friends of the Alliance are to be
considered in a Partnership for Peace. Consequently it is vital that NATO concentrates on
achieving greater cooperation in acquisition and greater operational interoperability in order to
ensure that smaller, better equipped multinational forces are able to operate efficiently together.
CALS can allow this to happen while, at the same time, benefiting NATO nations by reducing
defense equipment life-cycle costs.
Budgetary constraints and accelerating changes in
information technology are principal for fundamental improvements in the way government and
industry conduct business.
Rapid development in information technology have propelled
western economies into an era of global interdependence, where the major discriminating factor
among these competing economies is the ability to develop and apply this technology. NATO
therefore does not have a 'do nothing' option when considering the endorsement of CALS and the
incorporation of CALS into functional process improvement. CALS is considered to be one
prime contributor to increased sortie rates, reduced downtimes, enhanced logistic support, safer
operations, and increased interoperability in the field. In order to reach those benefits, NATO
will have to consider up-front investments in CALS.
A2.1.1 Roles and Responsibilities of NATO with Respect to CALS
A2.1.1.1 Internal Roles
There are two internal roles to accomplish. The first role becomes apparent when considering
NATO bodies, responsible for NATO infrastructure, standards, policy, and regulatory
considerations. In order to achieve NATO CALS standardization, as a first step towards
international standardization, these bodies' advise and endorsement will be sought whenever
deemed necessary.
To ensure internal NATO harmonization, the important role of CALS standards 'creator' is to be
performed. Several NATO Organizations and Agencies have been established and tasked with
the acquisition and in-service support for multinational equipment projects. Therefore, within
NATO, CALS implementation is to be ensured by clear directives and thus NATO will act as a
CALS standards 'enforcer' within the Alliance and a CALS standards p' romoter' to the individual
nations.
A2.1.1.2 External Role
NATO is a multinational organization with one common (military) goal. NATO is one of the
few organizations capable of aligning developments taking place in the two powerful industrial
complexes of North America and Europe. NATO's role therefore is one of a multinational
CALS catalyst and coordinator of international standardization and R&D efforts. NATO
therefore should establish formal links with international standardization organizations that
operate within NATO's areas of interest. NATO should also establish formal links with
A-2
organizations that subsidize and stimulate international R&D within the NATO region.
should closely liaise with industry.
NATO
A-3
Experience has shown that the quality of vision and leadership provided by the Senior
Management is the single most critical factor in the successful implementation of CALS.
Management commitment to the CALS implementation must be demonstrated by the allocation
of appropriate resources, by support for local champions who are leading change implementation
and by personal participation in the key NATO CALS Operations (NCOPS) activities.
Intelligent use of NCOPS can reduce risks, but without adequate leadership, the changes to
deliver benefits simply will not happen.
A2.4 The Need to Accommodate Change
Most Defense Systems change continuously over their lifetime. The processes and organizations
used to manage each Defense System will also improve over time. Major change in the CALS
Environment the hardware, the software, and the culture can be expected every two or three
years (with the cultural changes usually lacking behind considerably). Change must be expected,
planned for, and managed. The Program Strategy for CALS, developed through use of NCOPS,
will need review and update throughout the entire life-cycle.
A2.5 The Extended Enterprise
Successful organizations in the future will have in common their ability to assemble in whatever
virtual configurations are necessary to identify, scope, pursue, and capture business, and then
perform to specifications within budget and schedule constraints. Business will be won and
executed by extended enterprises. These will not be static over the life of a product, but will
change with conditions and the ebb and flow of requirements and capabilities. Participants will
include customer organizations, high technology partners and subcontractors, and suppliers of
various levels of capability and sophistication.
The process mechanisms by which teams interface and operate must in large measure be
common, as solutions specific to only one opportunity will be too costly for most players.
Business processes will be executed in a collaborative mannerin real-time where appropriate
by teammates distributed physically and in time. Co-location will be electronic, and information
needed for the task at hand will be immediately accessible and usable with little or no
preparation. Information will be provided through a variety of electronic mediatext, graphics,
voice, and video. Huge volumes of data will be stored, accessed, viewed, shared, and moved.
This will occur efficiently, accurately, securely, and affordably.
The purpose of an integrated information environment is to support the execution of streamlined
business processes across enterprise boundaries. Teams will accomplish this with members
geographically dispersed by distance and time, enabled by controlled access to data and related
software, effective exchange and sharing of data, and the collaborative preparation of
information deliverables.
A simple model of business processes, people, and the environment is presented in the figure
below. The specific business processes are related to the information deliverables of the
extended enterprise they support. The people who execute the processes are representative of the
various organizations that comprise the extended enterprise. The enabling CALS environment
must support their location, responsibilities, and team relationships. The extended enterprise
A-5
concept of operations provides a framework for the overall identification of the work processes,
team members, responsibilities, interactions, and supporting environment composition.
PEOPLE
T
R
A
I
N
BUSINESS PROCESSES
GENERIC
(DEVELOP INFORMATION PRODUCT)
SPECIFIC
(e.g. PROPOSAL PREP, PART PROCUREMENT)
P
O
L
I
C
I
E
S
&
I. INFORMATION PROCESSES & TOOLS
U
S
E
R
CONTROLLED ACESS
DATA SHARING AND COLLABORATION
DIGITAL DATA EXCHANGE
INFORMATION ARCHITECTURE
N
D
U
P
P
O
R
&
II. INFRASTRUCTURE
TELECOMMUNICATIONS
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
Includes user profiles that delineate specific accessible data stores and allowed
operations.
Provides firewall services that can range from very simple to very complex, applied
uniformly to all users or individually crafted.
Includes transaction logging or audit trails.
For optimum effect, controlled access to an organization's information space should be through
a single logical node. The number of physical access nodes is dependent on the number of
concurrent users and the desired performance.
Access to allowed data stores can be direct if the access mode and the data store structure
support encapsulated operations against segmented data, with control always returning to the
access node after normal or abortive exit. If these conditions cannot be met, the data in question
can be uploaded to the access node by one party, and downloaded by the other using various
file transfer protocols. The put and get process can be coordinate through E-Mail if need be.
A-7
If controlled access is to facilitate the efficient exchange and sharing of datawithin appropriate
security constraintsthe data itself must be easy to find; the parties in the transaction should not
have to know where it is or the details of how it is accessed. This implies a minimum
requirement for a data index that includes location and access mode. For a relatively small
operation, the index may be nothing more than a simple list updated regularly. For broad and
pervasive collaborative work, a global data directory and robust packaging and warehousing
capabilities will be required. Workflow and task-management tools are also appropriate for realtime collaboration in support of a major project. This latter situation requires a Contractor
Integrated Technical Information System (CITIS)-like capability that essentially meets the
requirements of MIL-STD-974.
A2.9 Data Sharing and Collaboration
This element supports the collaborative creation, review, modification, approval, disposition, and
status of information products such as documents, drawings, CAD models, schedules,
spreadsheets, product, and process specifications, or composites such as bid packages. It implies
a sharing and simultaneous (or near simultaneous) use of data by the collaborating parties. Files
can be shared and operated on during on-line sessions, or comment/markup software can be used
in conjunction with rapid file exchange. Shared windows allows passing of control for creation
and modification. GroupWare and video or telephone conferencing capabilities can support
multiple participants. E-Mail and file transfer are also used, but in a more time-critical sense
than is true of simple data exchange.
A2.10 Digital Data Exchange
This is a simple transfer of digital data between parties, either through a physical send/receive
operation, or through access-in-place. The purposes include review, comment, status, approval,
or as input to a task. The sense of such transfers is that they support serial tasks that are not
necessarily time critical. The data is contained in files, and is sent point-to-point either following
a transfer protocol (e.g., ftpFile Transfer Protocol), or as an attachment to an E-Mail message.
In the case of specific business transactions, the conventions of Electronic Data Interchange
apply, with several options (e.g., ANSI X12, UN/Electronic Data Interchange For Administration
Commerce And Transport [EDIFACT]) available that often have significant incompatibilities.
A2.11 Information Architecture
Consideration must be made for an Information Architecture element that supports business
policies and company procedures. This elementwhich requires additional development based
on user feedbackcontains appropriate Document Type Definitions (DTD) to manage textual
data and Data Models to manage database applications in general.
A2.12 Product Data Management
The Product Data Management (PDM) element ensures that the data to be used, transferred, or
shared is the right data, i.e., that it is correct, complete, consistent, current, and pertinent to the
product configuration and information package version of interest. A work step enabled by
perfect telecommunications, controlled access, and collaboration support will have an
A-8
unfortunate result if the input data is wrong. In a simple process with a few very knowledge
users, PDM may be a minimal requirement. However, it becomes increasingly necessary as the
size and complexity of the project and the numbers of users grow, and as the information space
that must be accessed becomes larger.
Product data management in the broad sense addresses all data that directly or indirectly supports
the concept exploration, design, fabrication, assembly, testing, and life-cycle support of a
product, including primary and derived requirements and cost/schedule information that supports
tracking of progress and timely corrective action when required. Successful organizations of the
future will have such a capability. It will seldom be implemented as a whole, however, but will
usually evolve from the legacy environment of today, in a judicious and cost effective manner.
Critical first steps include robust file and document management. The scope of the data
addressed by PDM will vary among organizations, based on varying definitions of what
comprises product data. Wherever the boundaries are drawn, there must by effective links
between PDM and those systems that manage data related to other critical aspects of an
enterprise, such as schedules, costs, and shop floor, as well as systems of customers and partners
in the virtual enterprise.
A2.13 User Applications
If information is to be well used in the target business process, the user(s) must be able to apply
appropriate application software to it to create, analyze, modify, simulate, or otherwise affect
the information deliverable that is the output of the business process. This software may address
data of a technical or a business aspecte.g., a CAD/CAM modeler or an EDI transaction
generator.
There are as many application packages as there are processes and users. Some are so generic
that they may better identified as an Infrastructure Desktop Element, such as Microsoft Excel.
Some are very much discipline specific, such a finite-element modeler. In any case, the
applications provide the mechanisms to the end user to form and finalize the ultimate deliverable
of the business processthe information product or package.
A2.14 Infrastructure Elements
There is no definition of infrastructure that has a wide consensus. The term as used here
comprises the many elements that address underlying capabilitiesoften mundane and taken for
grantedthat must function harmoniously to allow the more visible or specific processes and
tools to operate effectively, or at all.
A2.15 Telecommunications
This element addresses the physical connection between the parties of a data exchange or shared
session. Options include the Internet, direct lines or private networks, and dial-up. These
provide a spectrum of bandwidth, reliability, privacy/security, and cost.
A variety of
communications protocols, hardware, and software are available, each with its strengths and
weaknesses. Whatever options are chosen, the user should be aware that incompatibilities
abound, even between sub-elements that are perfectly suited to meet specific requirements. The
A-9
A-10
Standard for the Exchange of Product Model Data (STEP)a computer- interpretable data
representation format under development to include all product model data necessary to
define geometry, function, and behavior of a product throughout its life-cycle.
Consultative Committee of the International Telegraph and Telephone/Group 4
(CCITT/GROUP 4)the efficient compression of scanned raster images. Uses the code
from the Group 4 facsimile recommendation of the International Telegraph and
Telephone Consultative Committee. A 'tiled' form is described by using the architecture
nomenclature of International Standard, ISO 8613.
Computer Graphics Metafile (CGM)a neutral data format for the description, storage,
and communication of graphical information.
Interactive Electronic Technical Manuals (IETM)prescribes the requirements governing
the creation of interactive electronic technical manuals and the development of
presentation software applicable to a computer-controlled Electronic Display System
(EDS).
Electronic Commerce/Electronic Data Interchange (EC/EDI)the electronic interchange
of business information between trading partners.
Uses standard formats currently
defined by ANSI X12 in the U.S. (with migration to EDIFACT by 1997), EDIFACT in
Europe, Association Europeene des Constructeurs de Materiel Aerospatial (AECMA)
2000 for NATO.
Contractor Integrated Technical Information Service (CITIS)contractor provided service
for electronic access and/or delivery of contractually committed business and technical
information on a need-to-know basis.
In addition to these, other areas requiring standards are emerging, addressing the interoperability
of key capabilities such as workflow management, CITIS, and Product Data Management. It
will be necessary that appropriate standards evolve in a timely manner so that disciplined process
integration can proceed at a pace consistent with the growth of global collaboration.
A2.19 Training and User Support Elements
The success of collaborative teams in executing business processes depends on how well they
understand these processes, and on how effectively they can apply the supporting processes and
tools through which the information products are developed and provided to the customer.
Adequate training must be provided that addresses these items, as well as the overall policies,
guidelines, procedures, and standards that have been agreed upon. Equally important is a
sufficiently large expert support staff that provides direct support to the teams and individuals as
they apply the tools and execute the processes and procedures. This is especially true during the
initial operations of the enterprise, and at times of major modifications to policies, processes, or
tools.
A-11
A-12
B-2
Activity Name
MANAGE A
DEFENSE
SYSTEM
THROUGH LIFE
ESTABLISH AND
CONTROL DS
PROGRAM TL
ESTABLISH AND
CONTROL THE
REQUIREMENT
A1
A11
DEVELOP LC
STRATEGIES AND
POLICY
A12
DEFINE LC
STRATEGY AND
POLICIES
DEFINE
ACQUISITION
STRATEGY
A121
DEFINE RISK
STRATEGY
A123
DEVELOP ILS
STRATEGY
A124
A122
C-1
Activity Name
DEVELOP CM
STRATEGY AND
PLAN
DEVELOP QA
STRATEGY AND
PLANS
Activity
Number
A125
A126
DEVELOP CALS
STRATEGY AND
PLAN
A127
ESTABLISH and
RUN the DS
ORGANIZATION
MANAGE
PROGRAM
SCHEDULE
A13
ESTABLISH
ROLES and
RELATIONSHIPS
A132
PLACE AND
MANAGE
CONTRACTS
A133
A131
Activity Definition
Develop a strategy and plan to show how CM will be
implemented for the particular DS over its full life-cycle.
Define the actions required to ensure systematic
approaches are taken to the integrated concurrent design,
manufacture, and support of the DS and the related
processes.
An assessment of the business and CALS Environment
facing the DS program, development of the program goals
for CALS and an assessment of the costs, risks, and
benefits of the options of CALS-implementation.
Set up and run an organization capable of delivering an
acceptable DS, that meets the Current Requirement.
Define the tasks to be performed and services to be
provided, in response to the Current Requirement and
Change Proposals (what to do), and monitor task
achievement. Develop a Program WBS or Task list.
Develop any Service Level Agreements needed to specify
the standard of ongoing services. The WBS or Task List
must reflect the work needed to assess the impact of
proposed change. Based on the implications reported,
decisions are made on which proposed changes to
implement or reject. The work required to implement
approved changes is reflected in the updated WBS or Task
list. Develop and publish top level Program schedules
showing when activities are to be undertaken. (Detailed
planning of tasks in other activity boxes is assumed to
occur locally.)
This activity establishes how responsibility for the various
program tasks is to be allocated over the life-cycle,
including the identification of tasks to be placed on
contract. As roles and relationships will change over time,
particular attention should be paid to the mechanisms for
incentivising and ending contracts and to the management
of transitional arrangements (e.g., on entry into service).
Action needed to place, operate and close contractual
agreements required by the DS program. It includes
generation of the contract requirements and the
development and operation of payment and incentive
arrangements.
C-2
Activity Name
DEVELOP
CONTRACT
STRATEGY
Activity
Number
A1331
ISSUE
SOLICITATION
A1332
ASSESS
PROPOSALS
A1333
RUN CONTRACT
A1334
MANAGE DS LC
FUNDING
A134
MANAGE HUMAN
RESOURCES
MANAGE DS
INFORMATION
A135
DEVELOP IM
PLAN
A1361
A136
Activity Definition
The process of programming, controlling, documenting,
and implementing the specific requirements levied by the
negotiated contract or agreement. This process includes
ensuring that the Staff Target, program objectives, and
implementation plans are incorporated in contractual
definitions and design information. In addition, it includes
programming available funding into the contractual
process through negotiations, incentives, and
modifications, and the initiation and execution of
appropriate agreements, which may fall outside of the
specific contract such as those between government units.
The specific contractual solicitation or tender is prepared
and Issued, including the Statement of Work, the
Evaluation Criteria, and the Contract Deliverables.
This activity encompasses all actions in assessing the
formal response to the solicitation or tender, prepared by
either a contractor or another government entity
responding to the solicitation, and in choosing the
successful bidder.
Activities required to place and operate the contract over
its lifetime, and, when required, to close it. This will
include assessment of achievement against requirements,
approval of payments, and resolution of issues arising.
Acquire, allocate, and account for the funds needed to
provide the DS through life. This is assumed to include the
task of forecasting and tracking DS Life-cycle Cost.
External data will be needed for this including cost of the
operator/users and their training. The extensive feedback
needed to capture costs and expenditure details over the
life-cycle are not shown in this model.
Plan, organize, monitor and control, the provision of
human resources for DS program life-cycle.
The act of constantly monitoring and updating both the
technical data requirements and the database support
structure that provides the through-life support the Defense
System.
Define the program Information and IT- infrastructure
requirements based on an analysis of user needs over the
life-cycle. Develop a plan for capturing, controlling, and
delivering the required information to users.
C-3
Activity Name
ESTABLISH AND
OPERATE
PROGRAM SDE
Activity
Number
A1362
PROVIDE
INFORMATION
SERVICES
COMPARE
ACTUAL SYSTEM
STATE AND
PERFORMANCE
WITH REQUIRED
A1363
OBTAIN DS
A2
A14
Activity Definition
Design, acquisition, deployment, and use of a Shared Data
Environment for the DS. (See NCOPS). Those activities
include analysis, acquisition, test, delivery, operation, or
management of hardware, software, and communications
systems.
The activities required to support users in entering,
maintaining, and using DS information stored in the SDE.
The comparison of actual system state and performance
with that required by the Current Requirement, Business
Directives, and Operational Program to identify the need
for changes. This comparison addresses both technical and
business aspects (e.g., will/can the aircraft achieve the
specified range; are in-service maintenance costs in line
with approved budgets, is the actual configuration in line
with that needed to meet the Current Requirement and
Operational Program?) This comparison will identify the
need for any changes to the Defense System itself, or to the
DS Program, required to address the VMN. (Changes to
the VMN are outside the TLBM) The comparison may
lead to the raising of a Changes Proposal, affecting either
the DS Design or the DS Program. Proposals may also be
generated to change the Current Requirement, either
directly or after assessing and rejecting the viability of a
Proposed Change to the DS. This activity will also address
the acceptability or otherwise of requests for waivers or
concessions for components which fall short of the design
intent. The activity also generates a report on the
performance of the DS and the DS Program (Perf. Rep)
and issues advice to Operators over specific design
limitations applicable as a result of shortfalls (e.g., a power
restriction applies until a suspect component is inspected).
The activities necessary to define, design, procure,
manufacture, and test a new or improved DS capability to
meet the Current Requirement. The activity includes the
assessment of conceptual options, procurement of systems
via integrated product development, the conducting of total
system testing prior to making the operational system
available for first operational deployment. It also includes
the refurbishment systems and re- testing of Systems or
components returned for recycling from the Operational
environment and the establishment of a Support Capability
which can sustain the operational system in use.
C-4
Activity Name
DEVELOP DS
Activity
Number
A21
DEVELOP
CONCEPTUAL
OPTIONS
A211
DEFINE DS
A212
ENGINEERING
DESIGN
A213
FAILURE
ANALYSIS
A214
Activity Definition
Develop possible realizable solutions to the Current
Requirement, to the appropriate level of detail. This
activity will be repeated to an increasing level of detail as
the solution evolves from a proposed DS concept to a full
definition of the DS to be produced. The DS solution must
address the intended operational system and the support
management arrangements needed to sustain the system in
use, including any special-to-type tools, facilities, and
support equipment needed for this purpose.
The action taken to review the operational threat and
Mission Need to identify and evaluate potential alternative
solutions. The activity applies to both the system and its
support, establishing in-service goals for operational
implementation of the proposed Defense System solution.
The evaluation will address cost, schedule, performance,
supportability, and technological feasibility to select the
conceptual solution, or options to be offered in response to
the defined operational need.
The functional design of the Defense System includes
analysis of the design features needed by the subsequent
manufacturing, transportation, use, support, and disposal
processes. From this analysis the required functionality of
systems, sub systems and components is derived, for both
the operational system and the support system, and
responsibility is allocated to the various elements within
the functional architecture, for meeting all aspects of the
overall system of performance, as defined by the Current
Requirement. Acceptance criteria for test (A23) and
evaluation (A37) are also defined. This activity also
decides what items can be bought in from suppliers (as
Goods and Services from Others), an which still require to
be designed.
The detailed engineering design activities to arrive at a
product model for the DS and its support equipment and
simultaneously define the manufacturing, refurbishment,
and disposal processes. The task includes the design of the
deployed system and of any special to type support tools,
equipment, and facilities.
Analyze failure modes, effects, and criticality to define
product anomaly, criticality, causes/effects, and
compensating provisions. Provide diagnostic and
troubleshooting recommendations. Predict the expected
frequency of failure and calculate expected reliability.
C-5
Activity Name
DESIGN THE
SUPPORT
SYSTEM
PREDICT LIFECYCLE
PERFORMANCE
Activity
Number
A215
A216
Activity Definition
Create the procedures and data needed to provide an
optimized support capability for the DS, to deliver the
readiness, sustainability, and availability required from the
operational system, at least life-cycle cost. This activity
will create procedures for operating, servicing, and
maintaining the Operational System, including diagnostics
and post repair tests. It will define intentions for managing
the initial and ongoing supply of materials, components,
and spares required for manufacture and in-service use.
This includes definition of the intended spares holding and
the development of procedures buying, holding, issuing,
and accounting for stock. Decisions on the form of stock
management (e.g., unique to the DS, by an Armed Force,
by National or NATO stock systems) and undertaking any
screening and codification activities form part of this task.
It will develop policies and procedures for the return,
assessment, refurbishment, and disposal of items no longer
required. It will develop policies and procedures for
supplying operators and maintainers with the information
they require to perform operating, servicing and
maintenance tasks, deciding whether to achieve this by
components built into the equipment, by access to the
SDE, by digital storage medium or on paper. It will also
generate or re- format any additional data required for
support, which is not already available from the SDE. It
will define what feedback is needed from operators and
maintenance staff to optimize the performance of the
support system, and develop procedures for data collection
and analysis. It will establish training requirements for
operators and maintainers. The support system design
activity will also identify requirements for special-to-type
tools, facilities, test, and training equipment, the design of
which is undertaken in A214.
Task of predicting the expected performance of the DS in
regards to all aspects of the Current Requirement and
Business Directives. This includes prediction of system
capability, life, availability, readiness, and life-cycle cost.
C-6
Activity Name
PRODUCE DS
Activity
Number
A22
CONDUCT
TESTING
A23
DEPLOY DS
A24
SUPPORT THE
USE of the DS
PLAN SUPPORT
A3
STORE
TRANSPORT AND
ISSUE ITEMS
A32
A31
Activity Definition
The fabrication, assembly, and production testing of the
Operational DS, of related spares and components; of
engineering test models, breadboards, and prototypes and
of associated special-to-type tools, facilities, and test
equipment. The refurbishment of items returned from
service use to the original production standard, or as
otherwise defined, is also included in this activity, as it
requires similar facilities and data.
Process of measuring the performance of all DS
components (including software, hardware, and human
interface) for compliance with Current Requirements in
accordance with the Test Definition and Test Plan. The
Testing function also applies to the supportability features,
processes and equipment (e.g., a test of the Maintenance
Procedures and Tools). Normal production testing, applied
routinely to each new item, is included within A22
(Produce).
The activities needed to, receive, process, and transport
new Operational DS, support equipment, or components,
from the manufacturing environment to the location from
which they will normally operate, or be stored. NOTE: the
operational activity of deploying a DS from its peacetime
base to another operational environment, as part of a Task
Force, is not included in the TLBM as this requires
integration with other systems and activities beyond the
scope of this model.
C-7
Activity Name
MAINTAIN,
UPDATE AND
PROVIDE
FEEDBACK
Activity
Number
A33
O&S TASKS
A34
MANAGE
FACILITIES
TRAIN SUPPORT
STAFF
A35
CONDUCT
EVALUATIONS
A37
DISPOSE or
RECYCLE
A4
A36
Activity Definition
Perform the work needed to restore the DS to the condition
required for the next intended operation (except for O&S
tasks), by diagnosing, repairing, testing, and calibration the
item in accordance with the Core Product Data and
Support Information. Implement updates and
configuration changes in accordance with Required
Support Actions. Provide maintenance feedback on
findings, action taken, and issues arising. Update current
configuration to reflect work done.
(Non maintenance) activities needed to prepare the system
for operations e.g., fuelling, tow from hanger, empty waste
tanks etc.
Activities needed to sustain the special to type facilities
and tools in a fit for use condition.
[IEEE Std 1220-1994] The tasks, actions, and activities to
achieve and maintain the knowledge and skill level
necessary to efficiently and effectively perform operations,
support, and disposal.
The evaluation of a DS operational and support capabilities
based on both predetermined criteria and needs evolving
from operational experience. These evaluations include
analysis of existing data derived from operations and the
collection and analysis of data to support a particular need.
Conclusions and recommendations are documented as
evaluation findings.
Activities related with the retired Defense Systems and DS
components for disposal or refurbishment. Items for
refurbishment or recycling are returned to A2. Items no
longer needed are disposed of. Asses the state of the item,
decide whether to refurbish for use within the program,
make it available for use by others (sell or re-allocate to
other program) or scrap as waste.
C-8
Arrow Name
Acq Strat
Activities to be
contracted
Allocated
Manpower
As-built
Config
As-maint
Config
Available
Funding
Budget Req
Business
Directives
CALS Strategy
Change Impact
Change
Proposal
CM Strategy
Contract Dir.
Contract
Information
Req
Contract
Strategy
details the intended approach to acquiring goods and services from industry
over the Life-cycle
C-9
Arrow Name
Contracts and
ITTs
Contracts and
Requests
Core Product
Data
Current Req
Arrow Definition
Contracts and/or Invitations to Tender for the provision of goods or services to
the DS Program Contract. A mutually binding legal relationship obligating the
seller to furnish the supplies or services (including construction) and the buyer
to pay for them. It includes all types of commitments that obligate the acquirer
to an expenditure of appropriate funds and that, except otherwise authorized,
are in writing. In addition to bilateral agreements, contracts include, but are
not limited to, awards and notices of awards; job orders or task letter issued
under purchase orders, under which the contract becomes effective by written
acceptance or performance; and bilateral modifications. Invitation to Tender
(ITT). An ITT is a package of documents issued by the MOD to potential
contractors, which invites bids for the supply of goods or services against a
defined set of terms and conditions and technical specifications.
Contracts or Request for action from organizations or entities not directly
controlled by the DS Life-cycle Owner. This may include: contracts to
industry, training requirements, request for changes to other DS, facility
change requests, proposed changes to imposed, constraints including requests
for additional funding and proposed new common tools.
Information to define and describe items, components, assemblies and systems
to the level needed by those who will operate and support the system inservice. It includes the identity, version, definition, properties, classifications,
and characteristics of all parts likely to be exchanged during the in- service life
and the assembly structure of the Defense System (the Design Configuration)
including permitted options and variants.
Current Requirement The latest approved statement of the functional and
interface requirements for the DS, including the definition of the intentions and
requirements for operational use and support (Use Study). The Current
Requirement is also assumed to reflect approved changes. (Instructions to
implement changes, either to the system design, or to specific systems, are part
of Program Directives). The level of detail in the Current Requirement will
grow over time. It will range from the Validated Mission Need, at the program
outset, to the full technical specification of the product to be produced or in
service. The Current Requirement is assumed to be managed as one or more
CIs, in its own right. The history of requirement changes will be maintained
over time, and made available, where needed, through the SDE.
Defense Policy and Standards Defense Standards, Policies and Directives
applicable to the DS program.
All, or any part of a DS, or waste it has generated, which are no longer
required for operations and is to be removed from DS Program control.
Selected Concept, or Concepts, to be further developed into a full design.
All data relating to the DS required by external authorities. This includes:
reports on achievement v target
A new DS or component ready for initial deployment.
The Operational Defense System requiring support, as returned from
operations.
C-10
Arrow Name
DS ready for
Ops
Eval Def
Evaluation
Findings
Existing
Business Info
Existing
Infrastructure
External Data
Feedback fm
Maintenance
Feedback fm
Ops
Financial
Implication
FMECA Data
Functional
Architecture
Goods and
Services fm
others
ILS Strategy
Arrow Definition
DS ready for Operations
Evaluation Definition: The criteria and specific manner in which evaluations
will take place.
The documented results of an evaluation of a DS
Existing Business Information: Data, needed by the LSA activity, from
external sources. This may include government- provided list of approved
LSA tools, standard supportability data such as labor costs at each echelon,
existing documented historical data, etc.
Facilities Systems Tools
Data from other Systems or Authorities needed by the DS program. Other DS
program Schedules, Policies, WBS, Budgets and Organizations (A131/2/3),
Data on other Contracts and Contractors (A134), Personnel information
(A135), extent of and experience with existing Info Systems (A136) Data
needed for Support Design (A215) including historical data, predecessor data,
independent study data, health, safety or environmental data and data on
existing tools, facilities, components and parts. Current locations holdings of
other equipment and spares (A24)
Feedback fm Maintenance Feedback of information arising from maintenance
activities. This may include reporting of defects found, actions taken,
resources used and proposals for design or support system changes. It must
include the Current Product Structure (Configuration) post maintenance.
Feedback from Operators Ops History Survey Results State, Failures,
Deficiencies Changes made
Report of the financial implications of the program WBS, including proposed
changes.
Description of possible failure modes for the DS, with their likely
consequences and frequency of occurrence.
An arrangement of functions and their sub functions and interfaces (internal
and external) that define the execution sequencing, conditions for control of
system data flows, and the allocation of performance requirements to each
functional element within the operational and support systems, to satisfy the
overall system requirement. Support influence on design is achieved through
the allocation of requirements in the functional architecture
Goods and Services from others
The formal planning document for the integration of the activities concerned
with logistics support. It is kept current throughout the project life. It sets
forth the concept of operational support, provides a detailed ILS program to fit
with the overall program and results in the necessary ILS information required
by decision making bodies to make sound decisions in the system development
and production.
C-11
Arrow Name
IM Plan
In Service
Goals
Information
Services
In-Scope Eval
Findings
Inst to Ops
Invitation to
Tender
Maintained DS
Mfr and Rfb
data
Ops Prog
Org Structure
Perf Rep
Predicted LCC
Predicted Perf
Arrow Definition
Plan to manage information over the LC
A statement of general utilization intentions for a Defense System including
reference to national or co-operative logistics and training arrangements.
Provision of Information services which cannot be provided directly through
the SDE itself e.g., archiving, retrieval of historic records, special reports, new
applications, new hardware, help desk services etc.
In-Scope Evaluation Findings: Evaluation findings that indicate a requirement
to change Operational Support Instructions or Operational Support
Requirements that do not effect existing system plans or strategies.
Instructions to Operators
A formal request for a proposal from a contractor upon which a contract for
goods or services could be based. It includes, either directly or by reference,
all of the technical, commercial and legal information needed to establish and
operate a successful contract.
Items for Refurbishment Items removed from operational service and returned
for reconditioning or repair
Items removed from for test
Spares and other consumables supplied for incorporation into the main
equipment, (this includes the on board stock where appropriate)
Relevant Laws and regulations from beyond the Defense environment
The set of documents which provide the DS program team with policies and
strategies for managing the acquisition and support of a DS in a consistent
manner over its life-cycle. It includes: Acquisition Strategy (Acq Strat)
Quality Management Plans (ImpPlan) ILSPlans
DS after completion of the maintenance tasks, awaiting preparation for
deployment on mission
Manufacturing and refurbishment data: information needed to manufacture,
refurbish or dispose of the DS and its associated components
Program of the DS when deployed on operational missions
Organizational Structure of the DS project
The currently achieved (or predicted) performance of the DS in relation to
Current Requirement and Business Directives, highlighting any actual or
expected shortfalls in technical or financial performance.
Prediction of the expected Life-cycle Cost of the DS
Predicted Performance of the DS, in relationship to all aspects of the current
requirement
C-12
Arrow Name
Prg Dir
Proc Spec
Program
Schedule
Program SDE
Program WBS
Project Pers
QA Strategy
Req Config
Req Feedback
Requests for
Assistance
Required Items
Returned Items
Arrow Definition
Program Directives: Program management directives generated within the DS
Program, issued to set up the DS Organization and to control the work of staff
who can be tasked directly by the DS Life-cycle Owner. (other resources are
obtained or tasked through Contracts and Requests) Program Directives
include the Organizational Structure and approved budgets, WBS, program
plans, make or buy plans, instructions to buy, change authorizations and all
other forms of instruction used to make things happen on the program. The
Program Directives also communicate the specific policies, procedures and
plans established by the DS program and approved by the Life-cycle Owner.
Technical or functional definition of Items to be purchased, to the level of
definition needed to enable contract action to proceed. Note: Instruction to
place orders for specific Items of Supply are provided from two sources: the
Program WBS, for initial acquisition or from Plan Support, for re-supply, as
Required Items.
Plans showing what activities have to be performed when, to meet DS
Program requirements.
The hardware, software and communications and information infrastructure
needed to enable participants in DS program to access the information they
require to conduct the business processes illustrated by this TLBM.
Definition of the activities to be performed to deliver (or dispose of) a
successful DS. This may take any form. Typical outputs would include a
formal work breakdown structure, a Task list, or a series of Service Level
Agreements for ongoing tasks. Changes to the DS and to the work program
are initiated by changes to the Program WBS.
Project Personnel Staff from industry, government, or the Armed Forces who
is supplied to work on the program, potentially as part of a Multi Disciplinary
Team or Integrated Project Team. Will include operational user on temporary
deployment to the DS program to provide their experience or evaluation skills.
People supplied as a resource are trained and educated adequately except in
regard to the DS itself.
Details the intended approach to implementing an integrated systems approach
to Quality through the DS life-cycle.
The required configuration state of a specific DS to be achieved by the
maintenance activity. This would define the desired operational configuration
required for a particular mission (e.g., fit the long range fuel tanks), and
indicate what approved changes/modifications were to be incorporated during
a specific maintenance session.
Required Feedback
Requests for assistance from or action by parties beyond the control of the DS
Life-cycle Owner (e.g., the owners of other DS, the Armed Forces, External
training authorities, the Department of Defense [DoD], etc.).
The identity, quantity, and required delivery details for purchased items
needed to support the use of the DS.
Items for recycling or disposal
C-13
Arrow Name
Risk Mgt
Strategy
SDE Req.
Selected
Contractor
Spares and
Components
Support
Equipment
Requirements
Support Info
Support Plan
Test Def
Test Findings
Tools and
Facs.
Trained People
Trg Req
Usage and
Support Policy
Users
Validated
Mission Need
Arrow Definition
Details the requirements and intended approaches management of program
risk over the life-cycle.
Requirement Statement for the Program SDE
Spares and components obtained for use in support activities.
D1.0 INTRODUCTION
This section presents an overview of the CALS standards including their purpose, current status,
and implementation issues. It concentrates notably on:
D-1
product data transfer, such as a circuit in an electrical application, but they do not rigorously
define how this is done. This can be a problem in transfer, because unless the receiving system
knows how the IGES entities were combined to create the construct, and has a rigorous
definition of the meaning of the construct, that receiving system will not be able to interpret the
construct. The basic data is translated, but not all the information needed to translate product
data for the application is transferred.
The four application subsets are described in the following paragraphs:
D2.3.1 Class I: Technical Illustrations Application Subset.
The Class I application subset is for the exchange of illustrations for technical publications. The
emphasis is on the visual appearance of the illustrations, not on the functionality of the entities
within the class. Class I is a two dimensional subset with limited non-geometric information
(such as subfigures).
D2.3.2 Class II: Engineering Drawings Application Subset
The Class II application subset is for the exchange of product data (Technical Data Packages,
General Specification for). The emphasis is on completeness, functionality of the drawing
model, and visual equivalency for human interpretation. The class contains many geometric
entities, annotation entities and attributes such as color and line fonts, along with organizational
information such as levels and subfigures. The geometric entities in this class are three
dimensional, though two-dimensional data can be transferred by placing all the information on
the same plane within the sending CAD system.
D2.3.3 Class III: Electrical/Electronic Applications Subset
The Class III application subset is for the exchange of product data for electrical and electronic
products.
The emphasis is on completeness and functionality of the model for design,
manufacturing and testing. Class III supports both the logical product representation and the
physical product representation, which can both be in the same file. The logical representation
includes net lists and schematics, while the physical representation includes assembly placement
and pad layouts. Class III is difficult to use for unambiguous data exchange without further
restrictions and interpretations applied to the subset. The IGES/PDES Organization (IPO)
Electrical Applications Committee (AEC) is developing a Layered Electrical Products (LEP) AP
for the representation of electrical products. The LEP AP is currently planned to be a
replacement for MIL-D-28000 Class III.
D2.3.4 Class IV: Geometry for NC Manufacturing Application Subset
The Class IV application subset is for the exchange of product data for manufacturing by
numerical control. The emphasis is on the completeness and functionality of the part model.
Geometry data is either 2-D wireframe, for profiles or sheet metal, or a 3-D wireframe model, for
multi-axis machining. Precision and accuracy on the wireframe and surface geometry must be
maintained, as well as first order continuity. Geometry and Text form the majority of the data
for this class.
D-2
APs are very specific in nature. For example, the 3D Piping AP (Class V) exclusively supports
the exchange of product data for 3D piping system models. It does not support piping
engineering drawings. A user wishing to transfer an engineering drawing of a piping system
would have to use an Engineering Drawing AP.
In addition, only CAD/CAM systems
supporting piping will be able to support the piping AP. A CAD/CAM system that does not
support piping just does not have the appropriate constructs within its' database to either output
data in the Piping AP, or input the data reliably. APs will provide increased information transfer,
but with a much narrowed scope in the information that is transferred.
D2.5 Implementation Issues
Most IGES entities are general purpose in nature. They can be combined to create constructs
needed for product data transfer, such as a circuit in an electrical application, but they do not
rigorously define how this is done. This can be a problem in transfer, because unless the
receiving system knows how the IGES entities were combined to create the construct, the
receiving system may not be able to interpret it. The basic data will be translated, but not all the
information needed to translate product data for the application will be available.
D3.0 STANDARDIZED GENERALIZED MARKUP LANGUAGE
D3.1 Purpose
Standardized Generalized Markup Language (SGML) establishes requirements for the digital
interchange of technical publication text. Data prepared in conformance to SGML will facilitate
the automated storage, retrieval, interchange, and processing of technical documents from
heterogeneous data sources.
D-3
D-4
Querying the NCSL for a suitable registered DTD in lieu of developing a new DTD
D-5
If a new DTD is to be developed, compare tag requirements with the tags currently
registered in the NCSL. Utilize generic elements as much as possible. For example,
the requirement for a group assembly parts list can utilize an existing NCSL element
pl (parts list). Accordingly, the NCSL should not contain redundant elements, i.e.,
different tags for the same information.
If no existing NCSL element is deemed suitable, develop a new element and submit it to
the NCSR for inclusion into the NCSL. The NCSR will require that the element be
unique (i.e., no existing NCSL element will suffice); that (if possible), a generic tag name
be used to facilitate NATO-wide use; and that the tag name satisfy naming conventions
defined by the NCSR
SGML parsers. Such parsers check DTDs for conformance to the SGML grammar and
syntax. They also check document instances for conformance to a given DTD. They
return error reports on errors found in the parsing process. Many other SGML software
packages (e.g., SGML editors) come with a built-in parser.
SGML authoring and editing software which understands the DTD as ti is given. Such
software guides an author through the creation of a document, not requiring the author to
type in the SGML tags. The keyed-in text is automatically formatted and displayed
(non-WYSIWYG) on the screen.
SGML Publishing systems that accept an SGML-tagged document and associated
graphics and compose the entire document in accordance with the document's format
specifications, whether in the form of a FOSI, or system-internal style-sheet.
Software which automatically tags an ASCII file based on format -driven triggers. Most
of the structure type tags (for paragraphs, lists, etc.) can be automatically generated
without any trouble. However, unless the software is very sophisticated, the content
type tags (for cross references, equipment numbers, etc.) cannot be automatically
D-6
generated. Content type tags are very important in data base applications. This
auto-tagging software can be used in conjunction with media converters to translate
formatted system -dependent files (i.e., WordPerfect") into SGML files.
D4.0 HYPERMEDIA TIME-BASED DOCUMENT STRUCTURING
(HYTIME) (ISO/IEC DRAFT INTERNATIONAL STANDARD 10744)
LANGUAGE
D4.1 Purpose
The Hypermedia Time-Based Document Structuring Language (HyTime) is a standard language
for representing the logical structure of documents with requirements for space and time based
coordinates and addressing. HyTime is based on SGML (ISO 8879), and uses the grammatical
and syntactical conventions of SGML. HyTime provides the capability to package information
objects using a standardized markup language whose structure will enable non-sequential access,
querying, version control, and long-term maintenance despite system evolution or migration.
By using the SGML/HyTime standards, the application designer can create system independent
files that are transferable and interoperable across dissimilar computer applications. HyTime
provides architectural forms for the definition of SGML element classes in SGML Document
Type Definitions (DTD). HyTime does not provide a DTD, as such, but instead, constitutes a
meta-DTD from which conforming application DTDs can be created.
HyTime is not yet a CALS standard. It is perceived as a potential standard supporting future
interactive, electronic, hypertext and multimedia CALS applications.
D4.2 Typical Applications
The HyTime language can be directly applied to hypertext (documents that enable multiple
access paths) and multimedia applications.
These include the design and encoding of
information for Interactive Electronic Technical Manuals and Portable Maintenance Aids
(IETM/PMA), on-line review of existing documents both in and not in neutral formats, and the
creation of large interoperable hyperdocument libraries or design data bases.
HyTime has potential applications in the areas of project management, enterprise process design,
discrete event simulation, and music.
D4.3 Features
HyTime is designed for modular application. Features of the language which are not needed for
an application need not be supported. Depending on which features are supported, HyTime
provides:
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.
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.
D-9
D-10
View the image on a wide variety of devices, with different characteristics (such as color
and resolution), where the set of devices may not even be known at the time the metafile
is generated;
Enhance the picture before viewing the final image;
Compose or overlay several drawings into a single picture for viewing.
D5.3 Architecture
The CGM standard (ISO 8632-1987), Computer Graphics - Metafile for the Storage and
Transfer of Picture Description Information is composed of 4 parts. MIL-D-28003A utilizes Part
1 and Part 3 of the standard's four-part architecture.
Part 1 - Functional Specification - defines the functions of the CGM, independent of any
encoding. It also includes responses for the standard and design requirements and design
criteria.
Part 2 - Character Encoding - defines an encoding of the Part 1 functionality in a format
that conforms to ISO code extension rules. It is intended to provide an encoding of
minimum size, and may be used for transfer of pictures through networks that cannot
support binary transfer of data.
Part 3 - Binary Encoding - defines an encoding of the Part 1 functionality that is intended
to not require any other effort to generate and interpret on many systems.
Part 4 - Clear Text Encoding - specifies an encoding of the Part 1 functionality that can
be created, viewed, and edited with standard text editors. This encoding is appropriate
for networked systems that support only text file transfer.
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).
The purpose of this edition of the standard is to extend CGM to fulfill requirements of
engineering drawings, the preparation of graphic arts quality presentation materials, cartography,
and technical publishing. To a large degree, this work was directly in response to CALS
requirements.
Of particular interest to the CALS environment is the work under way within the CGM standards
organization (X3H3) to provide intelligent graphics.
Intelligent Graphics is defined as
adding information to graphics that is not graphical information, but that attaches application
intelligence or semantics to the graphics. Requirements are association of comments with
graphics elements, association of comments with element groups (hierarchical), native format
editing, version control, and text to graphics links. This requirement was originally introduced
by the electronic Review work of the CALS Industry Steering Group (ISG) Electronic
Publications Committee, where SGML-tagged documents are used to provide a commenting
capability. The CGM additions will allow for SGML tags to be attached to objects within the
CGM file.
Note that the addition of tiled raster capabilities, based on the Tiled Raster Interchange Format
(TRIF), allows for the encoding of large raster images within a CGM file. Possible future
extensions to the international standard that could be of considerable interest to CALS include
the formulation of an object structured grammar. This has been requested from, and will be of
major use to, CGM users in commercial aviation (intelligent graphics); CALS electronic review
(review comments in graphics and stronger links to text); and hypermedia (smart objects in
graphics databases).
D5.5 Advantages of Current Specification
The CGM contains device-independent, digitally-encoded vector and raster graphics data. CGM
files are easily transferred and displayed on a wide variety of hardcopy devices (dot-matrix,
ink-jet, electrostatic, and laser printers, pen plotters, and film cameras). CGM files can also be
easily previewed on an extensive range of softcopy terminals. In comparison to Raster, CGM is
easily modifiable, generally of much smaller size, and not dependent upon resolution of the
output device. In comparison to IGES (2D data), CGM is faster to interpret and display, and
again more compact. The selection of which of the CALS graphic standards (raster, IGES, or
CGM) that best fits the application, should be the result of the thorough examination of the
processes involved in the application.
D-12
Surface Information
Roughness
Coating
Material Specifications
Type
Composition
Tolerance Specifications
Size Dimension
Tolerance Range
Position Tolerance
Feature Definition
Hole Pattern
Groove
Outside Diameter
D-13
D-14
D-15
This initial
D-16
D-17
D6.7 Testing
The STEP testing activities are categorized as follows:
Standards testing: it addresses the quality of the evolving STEP specification itself.
These validation efforts provide assurance that the methods employed by STEP will
indeed work, and that the standard provides a means to meet the functionality that it
claims to support.
Component testing: This is the preliminary testing conducted by the STEP software
implementer to verify that the application software addresses both the basic requirements
imposed for compliance with the standard and the users' functionality requirements.
Conformance testing: it evaluates a software product with respect to the specifications
provided in a Part of a STEP standard and tests for the presence of these characteristics
required by the standard itself. STEP includes the specifications for Conformance testing
as a requirement built into many Parts of the standard.
Acceptance testing: it is concerned with the user's specific requirements. It tests a
software product against a set of requirements defined by the users of that software
product.
This type of testing may include performance, user interfaces, and
inter-operability with other systems.
Current efforts are primarily focused on developing methods for Conformance and Standards
testing. Component and Acceptance testing activities have just gotten underway within the
vendor and user communities.
D-18
MIL-STD-1388-1A
S/S MIL-HDBK-502
Notice 4
To be
cancelled
Interim Issue
1
Application of Integrated
Logistic Support (ILS) Profile of MIL-STD1388-1a for UK MOD
use.
D-19
their associated Data Dictionaries. If this work is successful, the resulting ISO Standard and any
associated NATO Applications Profiles (STANAGs) should replace the above Standard and
Applications Profile by 1997.
D7.3 Initial Provisioning
Initial Provisioning Procedures are the first steps that constitute the formal process for the
acquisition of initial spares needed to support defense equipment. The processes include the
identification, listing, and presentation of sparable items, the presentation of Illustrated Parts
Catalogues (IPC), and NATO Codification.
Standard
[T]
AECMA 2000M
Revision 3.0
Material Management
Integrated Data
Processing for Military
Equipment
AECMA 2000M
Revision 3.0
Chapter 1
Material Management
Integrated Data
Processing for Military
Equipment
D-20
Standard
[T]
STANAG 3150
Issue: 1989
Revision:
5.07.1989
Codification of
Equipment - Uniform
System of Supply
Classification
Standard
[T]
STANAG 4177
Issue:
21.08.90
Manual
[R]
ACodP-1
Codification of Items of
Supply - Uniform
System of Data
Acquisition
NATO Manual on
Codification
Guide to NATO
Codification Systems
AECMA 2000M
Based on
STANAG 4329
Revision 3.0
Appendix 3
Standard
[T]
STANAG 4329
Issue:
6.4.1992
Material Management
Integrated Data
Processing for Military
Equipment - Appendix 3
Bar Coding
NATO Standard Bar
Coding Symbology
AECMA 2000M
3.0 Chapter 3
D-21
Material Management
Integrated Data
Processing for Military
Equipment
AECMA 2000M
Based on ISO 9735
(EDIFACT)
/ EN29735
/ DIN16536
Revision 3.0
Material Management
Integrated Data
Processing for Military
Equipment - Appendix 1
Data Dictionary and
Appendix 2
Communications
Techniques
AECMA SPEC 2000M Revision 2.1 includes a comprehensive set of Order Administration
messages that do not conform to ISO 9735/UN EDIFACT. Publication of an EDIFACTcompliant message set is expected in early 1996.
D7.9 Consumption and Maintenance Data Exchange
Mechanisms for the exchange of data about item consumption in-use and on maintenance
operations is prescribed in the AECMA 2000M standard, and further work is in hand to extend
this work to cover repair activity.
Standard
[E]
AECMA 2000M
Revision 3.0
Material Management
Integrated Data
Processing for Military
Equipment - Chapter 5
Consumption Data
Exchange
D-22
Standard
[E]
ISO 13584
CD
ISO TC184
SC4
Standard
[T]
Note: The Policy and applicable standards for Parts Libraries, Data transfer for NATO, and the
status of the above Standard has not yet been confirmed or validated in the NATO CALS
context. NATO Maintenance and Supply Agency (NAMSA) currently publishes a Master Cross
Reference List of parts subject to NATO Codification for use by the Nations.
D8.0 TECHNICAL DOCUMENTATION STANDARDS AND APPLICATION
PROFILES
D8.1 Character Sets and International Codes
The NATO base standard for information processing is the internationally agreed reference for
Latin-based languages (ISO 646) which defines the ASCII compatible binary representation of
English alpha-numeric characters, a range of punctuation symbols, and four special control
characters (space, tab, and the line/record start and end codes.
It can be easily modified for use with other Latin-based languages. Representation of languages,
country names, currencies, dates/times, and the units of measurement should also be specified
using the appropriate ISO standards.
D-23
Standard
[R]
ISO 31
Information Processing
Representation of
Quantities and Units
Standard
[R]
ISO 639
1988
Information Processing
Coded Representation of
Names of Languages
ISO/IEC 646
3rd Ed.
1991
Information Technology
- ISO 7-Bit Coded
Character Set for
Information Interchange
SI Units and
Recommendations for
the Use of Their
Multiples and of Certain
Other Units.
Information Technology
Codes for the
Representation of Names
and Countries and Other
Subdivisions. Part I
Country Names
Part II Country
Subdivision Codes
Standard
[R]
Standard
[R]
ISO 1000
3rd Edition
1992
Standard
[R]
ISO 3166-1
1997
Standard
[R]
ISO 3166-2
1998
Standard
[R]
ISO 3166-3
1999
Standard
[R]
ISO 4217
1995
Standard
[R]
ISO 6709
1983
Standard
[R]
ISO 6936
1988
D-24
Standard
[R]
ISO/IEC 8859
Various
Standard
[R]
ISO 8601
ISO/WD 8601
2nd Ed.
ISO/IEC 10646-1
ISO/IEC WD
10646-1
2nd Ed.
Standard
[R]
Information Technology
- 8-bit single byte coded
graphic character sets.
Pt. 1 Latin Alphabet No.
1
Pt. 2 Latin Alphabet No.
2
Pt. 3 Latin Alphabet No.
3
Pt. 4 Latin Alphabet No.
4
Pt. 7 Latin/Greek
Alphabet
Pt. 9 Latin Alphabet No.
5
Pt. 10 Latin Alphabet
No. 6
Pt 11 Latin/Thai
Alphabet
Pt. 13 Latin Alphabet
No. 7
Pt. 14 Latin Alphabet
No. 8
Pt. 15 Latin Alphabet
No. 9
Data Elements and
Interchange Formats
Information Interchange
Representation of
Date/Time.
Information Technology
- Universal Multiple
Octet Coded Character
Sets (UCS)
D-25
can be used temporarily as an interim standard. Any application that generates a page image
format can use Standard Page Description Language (SPDL) including SGML/DSSSL and
ODA.
Standard
[N]
Standard
[N]
Standard
[N]
Standard
[N]
Standard
[N]
Standard
[N]
ISO/IEC 8613-1
ISO/IEC 8613-1
Cor. 1
1994
ISO/IEC 8613-2
1995
ISO/IEC 8613-2
Cor. 1
1998
ISO/IEC 8613-2
Cor. 2
ISO/IEC 8613-3
1998
ISO/IEC 8613-4
1994
ISO/IEC 8613-4
Cor. 1
1998
ISO/IEC 8613-4
Cor. 2
ISO/IEC 8613-5
1998
ISO/IEC 8613-5
Cor. 1
1998
ISO/IEC 8613-5
Cor. 1
ISO/IEC 8613-6
1998
ISO/IEC 8613-6
Cor. 1
1998
1998
1995
1994
1994
ISO/IEC 8613-6
FCD Amd. 1
D-26
Information Technology.
Office Documentation
Architecture (ODA) and
Interchange Format.
Part 1 Introduction and
General Principles
Part 2 Document
Structures
Part 3 Abstract
Interface for the
Manipulation of ODA
Documents.
Part 4 Document
Profile.
Part 6 Character
Content Architectures
Standard
[N]
ISO/IEC 8613-7
1994
ISO/IEC 8613-7
Amd. 1
1998
ISO/IEC 8613-7
Cor. 1998
ISO/IEC 8613-8
1998
1994
Part 8 Geometric
Graphics Content
Architectures.
Standard
[N]
ISO/IEC 8613-9
1996
Standard
[N]
ISO/IEC 8613-10
1995
Part 10 Formal
Specifications.
Standard
[N]
ISO/IEC 8613-11
1995
Part 11 Tabular
Structures and Tabular
Layout.
Standard
[N]
ISO/IEC 8613-12
1996
Standard
[N]
ISO/IEC 8613-14
1997
Part 14 Temporal
Relationships and Nonlinear Structures.
Standard
[R]
ISO 8879
1986
1988
1996
1999
1988
Standard
[N]
Standard
[R]
D-27
Standard
[]
ISO/IEC TR
9573
1988
Standard
[]
ISO/IEC TR
9573-11
1992
Standard
[]
ISO/IEC TR
9573-13
1991
Standard
[E]
ISO/IEC 10179
1996
Standard
[E]
ISO/IEC 8824
1990
Standard
[E]
ISO/IEC 8824-1
1995
ISO/IEC 8824-1
FCD Amd. 1
1996
Relative Object
Identifiers
ISO/IEC 882-1
Amd. 1
1996
Rules of Extensibility
ISO/IEC 882-1
Cor. 1
1996
ISO/IEC 882-1
Amd. 2
Information Processing
SGML Support Facilities
Techniques for Using
SGML.
Part 11 Application at
ISO Central Secretariat
for International
Standards and Technical
Reports.
Part 13 - Public Entity
Sets for Mathematics and
Science
Information Technology
Processing Languages
- Document Style
Semantics and
Specification Language
(DSSSL)
Scheduled for IS in 1995
Information Technology
Open Systems
Interconnection
Specification of Abstract
Syntax Notation One
(ASN. 1).
Part 1 Specification of
Basic Notation
Semantic Model
D-28
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
ISO/IEC 8824-2
1995
Part 2 Information
Object Specification
ISO/IEC 8824-2
FCD Amd. 1
1995
Semantic Model
ISO/IEC 8824-2
Amd. 1
ISO/IEC 8824-3
1996
Rules of Extensibility
1995
Part 3 Constraint
Specification
ISO/IEC 8824-4
1995
Part 4 Parameterization
of ASN. 1
Specifications
ISO/IEC 8824-4
FCD Amd 1 ASN
1
ISO/IEC 8825
Semantic Model
1990
ISO/IEC 8825-1
1995
ISO/IEC 8825-1
FCD Amd. 1
Standard
[E]
ISO/IEC 8825-1
Cor. 1
ISO/IEC 8825-2
Information Technology
Open Systems
Interconnection
Specification of Basic
Encoding Rules for
Abstract Syntax Notation
One (ASN.1)
Part 1 ASN.1 Encoding
Rules: Specification of
Basic Encoding Rules
(BER), Canonical
Encoding Rules (CER),
and Distinguished
Encoding Rules (DER)
Relative Object
Identifiers
1996
1996
ISO/IEC 8825-2
FCD Amd. 1
D-29
Standard
[E]
ISO/IEC 10180
1995
Profile
[T]
MIL-HDBK28001
30 Jun 1995
Handbook
[T]
MIL-HDBKSGML
DRAFT
Published
May 1994
WAS NOT
FOUND
Information Technology
Processing Languages
Standard Page
Description Language
(SPDL)
DEPARTMENT OF
DEFENSE
APPLICATION OF
MIL-PRF-28001 USING
STANDARD
GENERALIZED
MARKUP LANGUAGE
(SGML)
U.S. Department of
Defense Application of SGML.
Federal Information
Processing Standard
(FIPS 152)
D-30
Standard
[R]
ISO/IEC 8632 1
1992
Information Technology
- Computer Graphics Metafile of the storage
and transfer of picture
description information
Part 1 Functional
Specification
Rules for Profiles
1994
Application Structuring
Extensions
ISO/IEC FDIS
8632
ISO/IEC 8632-1
Amd. 1
1995
ISO/IEC 8632-1
Amd. 2
Standard
[R]
ISO/IEC 8632-2
1992
Part 2 Character
Encoding
ISO/IEC 8632-2
Amd. 1
1994
ISO/IEC 8632-2
Amd. 2
ISO/IEC 8632-3
1995
1992
Application Structuring
Extensions
Part 3 Binary Encoding
ISO/IEC 8632-3
Amd. 1
1994
ISO/IEC 8632-3
Amd. 2
ISO/IEC 8632-4
1995
Application Structuring
Extensions
Part 4 Clear Text
Encoding
ISO/IEC 8632-2
CD Cor. 1
Standard
[R]
Standard
[R]
1999
D-31
Standard
[]
ISO/IEC 9592 - 1
1997
Standard
[]
ISO/IEC 9592 - 2
1997
Standard
[]
ISO/IEC 9592 - 3
199
Standard
[]
ISO/IEC 9593 -1
1990
Information Processing
Systems Computer
Graphics
Programmers
Hierarchical Interactive
Graphics System
(PHIGS) Language
Building
Part 1 FORTRAN
ISO/IEC 9593 -1
Amd. 1
1995
ISO/IEC 9593 -1
Cor. 1
1993
ISO/IEC 9593 -1
Cor. 2
ISO/IEC 9593 3
1994
1990
Part 3 ADA
ISO/IEC 9593 3
Amd. 1
1994
Incorporation of PHIGS
PLUS
ISO/IEC 9593 3
Cor. 1
1993
ISO/IEC 9593 3
Cor. 2
1994
Standard
[]
D-32
Information Technology
Computer Graphics
and Image Processing Programmers
Hierarchical Interactive
Graphics System
(PHIGS) Part 1
Functional Description
Part 2 Archive File
Format
Standard
[]
Standard
[]
Standard
[]
Standard
[]
Standard
[]
Standard
[]
Standard
[]
Profile
[E]
ISO/IEC 9593 4
1991
ISO/IEC 9593 4
Amd. 1
1994
ISO/IEC 9593 4
Cor. 1
1994
ISO/IEC 9593 4
Amd. 2
ISO/IEC 9636 - 1
1998
ISO/IEC 9636 - 2
1991
Incorporation of PHIGS
Amendments
Information TechnologyComputer Graphics Interfacing Techniques
for Dialogues with
Graphical Devices (CGI)
Functional
Specification
Part 1 Overview,
Profiles, and
Conformance
Part 2 - Control
ISO/IEC 9636 - 3
1991
Part 3 - Output
ISO/IEC 9636 - 4
1991
Part 4 - Segments
ISO/IEC 9636 - 5
1991
ISO/IEC 9636 - 6
1991
ISP 12064-1
DISP
1991
D-33
Part 4 C
Profile
[T]
MIL-D-28002
NOT FOUND IN
ASSIST
Rev B
Amend 1
20 Sep 93
Profile
[T]
MIL-D-28003
NOT FOUND IN
ASSIST
Rev A Nov
92
Amend 1
14 Aug 92
ISO/IEC 10303 - 1
1994
D-34
Industrial Automation
Systems and Integration
Product Data
Representation and
Exchange
Part 1 Overview and
Fundamental Principles
Standard
[E]
ISO/IEC 10303
11
1994
1999
Standard
[E]
ISO/IEC 10303
11 Cor. 1
ISO/CD TR 10303
12
Standard
[E]
ISO/AWI 10303
14
Standard
[E]
ISO 10303 21
1997
1994
Part 11 Description
Methods: The EXPRESS
Language Reference
Manual
Part 12 Description
Methods: The
EXPRESS-I Language
Reference Manual
Part 14 XML
Representation for
EXPRESS-Driven Data
Part 21 Implementation
Methods: Clear Text
Encoding of the
Exchange Structure
ISO 10303 21
CD Amd. 1
Standard
[E]
ISO 10303 21
Cor. 1
ISO 10303 22
Standard
[E]
ISO/DIS 10303
23
Standard
[E]
ISO/CD 10303
24
Standard
[E]
ISO/AWI 10303
26
Standard
[E]
Standard
[E]
ISO/CD 10303
27
ISO 10303 31
1996
1998
Part 22 Implementation
Methods: Standard Data
Access Interface
Part 23 Implementation
Methods: C++ Language
Binding to the Standard
Data Access Interface
Part 24 Implementation
Methods: C Language
Binding to the Standard
Data Access Interface
Part 26 Implementation
Methods: Interface
Definition Language
Binding to the Standard
Data Access Interface
1994
Part 31 Conformance
Testing Methodology
and Framework: General
Concepts
D-35
Standard
[E]
ISO 10303 32
Standard
[E]
ISO 10303 34
Standard
[E]
ISO 10303 35
Standard
[E]
ISO 10303 41
1994
ISO/DIS 10303-41
ISO 10303 42
2nd Ed.
1994
ISO/DIS 1030342
2nd Ed.
ISO 10303 42
Cor. 1
1999
Standard
[E]
Standard
[E]
1998
ISO 10303 42
Cor. 2
ISO 10303 43
1994
ISO/DIS 1030343
2nd Ed.
ISO 10303 43
Cor. 1
1999
D-36
Part 32 Conformance
Testing Methodology
and Framework:
Requirements on Testing
Laboratories and Clients
Part 34 - Conformance
Testing Methodology
and Framework:
Abstract Test Methods
Part 35 - Conformance
Testing Methodology
and Framework:
Abstract Test Methods
for Standard Data Access
Interface Implementation
Part 41 Integrated
Generic Resources:
Fundamentals of Product
Description and Support
Part 42 Integrated
Generic Resources:
Geometric and
Topological
Representation
Part 43 - Integrated
Generic Resources:
Representation
Structures
Standard
[E]
ISO 10303 44
1994
ISO/DIS 1030344
2nd Ed.
ISO 10303 44
Cor. 1
ISO 10303 45
1999
ISO 10303 45
Cor. 1
ISO 10303 46
1999
ISO 10303 46
Cor. 1
ISO 10303 47
1999
Standard
[E]
ISO 10303 49
1998
Standard
[E]
1994
1999
Standard
[E]
1996
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
1998
1994
1997
D-37
Part 44 - Integrated
Generic Resources:
Product Structure
Configuration
Part 45 - - Integrated
Generic Resources:
Materials
Part 46 Integrated
Generic Resources:
Visual Presentation
Part 47 - Integrated
Generic Resources:
Shape Variation
Tolerances
Part 49 - - Integrated
Generic Resources:
Process Structure and
Properties
Part 101 Integrated
Application Resources:
Draughting
Part 104 - Integrated
Application Resources:
Finite Element Analysis
Part 105 - Integrated
Application Resources:
Kinematics
Part 106 - Integrated
Application Resources:
Building Construction
Core Model
Industrial Data
Part 107 - Integrated
Application Resources:
Engineering Analysis
Core Application
Reference Model (EA CARM)
Standard
[E]
1994
Standard
[E]
1996
Standard
[E]
1994
1996
1998
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
1999
D-38
Product Data
Part 201 Application
Protocol: Explicit
Draughting
Part 202 Application
Protocol: Associative
Draughting
Part 203 - Application
Protocol: Configuration
Controlled Design
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
ISO/WD 10303
226
Standard
[E]
ISO/DIS 10303
227
Standard
[E]
ISO/AWI 10303
229
D-39
Standard
[E]
ISO/WD 10303
230
Standard
[E]
ISO/CD 10303
231
Standard
[E]
ISO/CD 10303
232
Standard
[E]
ISO/AWI 10303
233
Standard
[E]
ISO/AWI 10303
234
Standard
[E]
ISO/CD 10303
235
Standard
[E]
ISO/PRF TR
10303 307
Standard
[E]
ISO/PRF TS
10303 324
Standard
[E]
ISO/AWI 10303
332
Standard
[E]
ISO/PRF 10303
501
Standard
[E]
ISO/PRF 10303
502
Standard
[E]
ISO/PRF 10303
503
D-40
Standard
[E]
ISO/DIS 10303
504
Standard
[E]
ISO/DIS 10303
505
Standard
[E]
ISO/DIS 10303
506
Standard
[E]
ISO/DIS 10303
507
Standard
[E]
ISO/DIS 10303
508
Standard
[E]
ISO/DIS 10303
509
Standard
[E]
ISO/PRF 10303
510
Standard
[E]
ISO/DIS 10303
511
Standard
[E]
ISO/FDIS 10303
512
Standard
[E]
ISO/DIS 10303
513
Standard
[E]
ISO/FDIS 10303
514
Standard
[E]
ISO/DIS 10303
515
D-41
Standard
[E]
ISO/DIS 10303
517
Standard
[E]
ISO/CD 10303
518
Standard
[E]
ISO/FDIS 10303
519
Standard
[E]
ISO/FDIS 10303
520
Standard
[ ]
ANSI/EIA 548
1988
NOT FOUND
Standard
[E]
ANSI/IEEE 1076
1993
Standard
[E]
ANSI/IEEE 1076.2
1996
Standard
[E]
ANSI/IEEE 1076.3
1997
Standard
[E]
ANSI/IEEE 1076.4
1995
Standard
[T]
ANSI/ASME
Y14.26M / FIPS
177
Ver 5.2
(1989)
Profile
[E]
STEP Applications
Initial Graphics
Exchange Specification
(IGES)
May be subsumed by
STEP
At least 34 different ISO
STEP Application
Profiles are under
development.
D-42
Profile
[T]
MIL-D-28000
NOT FOUND IN
ASSIST
Rev A
10 Feb 92
Amend 1
14 Dec 92
Digital Representation
for Communication of
Product Data: IGES
Application Subset and
IGES Application
Protocols.
D8.5 Images
Non-processable, optically scanned drawings and documents should be specified using raster
graphics interchange standards.
These were developed initially for digital facsimile over
Integrated Services Digital Networks (ISDN). Two forms of raster data may be specified: Type I
(untiled) and Type II (tiled).
Type II (tiled) is the preferred format. A tiled raster image resembles a two-dimensional grid
with each tile or set of pixels representing a portion of the image.
Text and graphics in raster data formats allow a rapid and consistent access to stored images and
are suitable for electronic transmission. Raster files can also be converted to digital documents
for work processing or desktop publishing and edited through manipulation of individual pixels.
A number of standards exist which are not CALS-specific.
Standard
[R]
ISO/IEC 10918 - 1
1994
Standard
[R]
ISO/IEC 10918 - 2
1995
Standard
[R]
ISO/IEC 10918 3
1997
ISO/IEC 10918 3
Amd. 1
Information Technology
Digital Compression
and Coding of
Continuous-tone Still
Images
Part 1 - Requirements
and Guidelines
Part 2 Compliance
Testing
Part 3 Extensions
Provision to Allow
Registration of New
Compression Types and
Revisions in the SPIFF
Header
D-43
Standard
[R]
ISO/IEC 10918 - 4
1999
Standard
[ ]
ISO/IEC 12087 - 1
1995
Standard
[ ]
ISO/IEC 12087 2
1994
ISO/IEC 12087 2
Cor. 1
ISO/IEC 12087 3
1997
1995
Part 3 Image
Interchange Facility (IIF)
ISO/IEC 12087 3
Amd. 1
1996
Standard
[ ]
ISO/IEC 12087 5
1998
Standard
[R]
ITU-TSB T6
(formerly CCITT
Recommendation
T.6)
1988
Type Definition,
Scoping, and Logical
Views for Image
Interchange Facility
Part 5 Basic Image
Interchange Format
(BIIF)
Facsimile Coding and
Control Functions for
Group IV Facsimile
Apparatus.
Standard
[ ]
Part 4 Registration of
JPEG Profiles, SPIFF
Profiles, SPIFF tags,
SPIFF Color Spaces,
APPn Markers, SPIFF
Compression Types and
Registration Authorities
(REGAUT)
Information Technology
Computer Graphics
and Image Processing Image Processing and
Interchange (IPI)
Functional Specification
Part 1 Common
Architecture for Imaging
Part 2 Programmers
Imaging Kernel System
Application Program
Interface
D-44
Standard
[]
1988
Standard
[]
ISO/IEC 10149
1995
Note: The Policy and applicable standards for NATO CD-ROM usage have not yet been
confirmed for CALS applications. In particular, a number of NATO STANAGS contain CDROM specifications and work is in hand to identify such references.
D8.7 Video and Motion Picture Media
Multi-media applications may specify the inclusion of Video and Motion Picture files or still
images derived from moving pictures. Such specifications, together with legacy data migration
strategies, will also need to include appropriate reference to the acceptable data compression
standards.
Standard
[E]
ISO/IEC 10918 - 1
1994
Standard
[E]
ISO/IEC 10918 2
1995
Standard
[E]
ISO/IEC 10918 3
1997
Part 3 Extensions
ISO/IEC 10918 3
Amd. 1
1997
ISO/IEC 10918 4
1999
Provision to Allow
Registration of New
Compression Types and
Revisions in the SPIFF
Header
Part 4 Registration of
JPEG Profiles, SPIFF
Profiles, SPIFF Tags,
SPIFF Color Spaces, APPn
Markers, SPIFF
Compression Types and
Registration Authorities
(REGAUT)
Standard
[E]
D-45
Standard
[R]
ISO/IEC 11172 - 1
1993
ISO/IEC 11172 1
Cor. 1
1996
1999
ISO/IEC 11172 1
Cor. 2
Standard
[R]
ISO/IEC 11172 2
1993
ISO/IEC 11172 2
Cor. 1
1996
ISO/IEC 11172 2
Cor. 1
ISO/IEC 11172 3
1999
ISO/IEC 11172 3
Cor. 1
ISO/IEC 11172 4
1996
1995
Part 4 Compliance
Testing
Standard
[R]
ISO/IEC TR 11172
5
1998
Part 5 Software
Simulation
Standard
[R]
ISO/IEC 13813
1998
Standard
[ ]
ISO/IEC 11544
1993
ISO/IEC 11544
Cor. 1
1995
Information Technology
Programming Languages
Generic Packages of Real
and Complex Type
Declarations and Basic
Operations of Ada
Information Technology Coded Representation of
Picture and Audio
Information - progressive
bi-level image
compression (JBIG).
Standard
[R]
Standard
[R]
1993
Part 2 - Video
Part 3 - Audio
Note: The Policy and applicable standards for NATO Video and Motion Picture Video usage
have not yet been confirmed for CALS applications.
D8.8 Digital Audio
Multi-media applications may specify the inclusion of Audio files but to date there is no
internationally accepted standard for digital audio specification.
D-46
Standard
[]
Profile
[ ]
STANAG
[ ]
TBD
TBD
TBD
Note: The Policy and applicable standards for NATO Audio usage have not yet been
determined.
D8.9 Hypermedia and Multimedia
The HyTime standard, which is built on SGML, is used to create relational links between objects
(text, graphics, audio, video, etc). The objects are then linked in a document or between
documents so as become accessible within a computer system.
Standard
[R]
ISO/IEC 10744
1997
Standard
[ ]
ISO/IEC 13522 - 1
1997
Standard
[ ]
ISO/IEC 13522 - 3
1997
Standard
[ ]
Standard
[ ]
ISO/IEC 13522 - 4
1996
ISO/IEC 13522 5
1997
ISO/IEC 13522 5
AWI Amd. 1
ISO/IEC 13522 5
Cor. 1
1999
D-47
Standard
[ ]
ISO/IEC 13522 - 6
Standard
[ ]
ISO/IEC AWI
13522 - 7
Standard
[ ]
ISO/IEC 13522 - 8
1998
Note: The Policy and applicable standards for NATO Hypermedia and Multimedia use has not
yet been confirmed or validated in the NATO CALS context.
D8.10 Interactive Electronic Technical Manuals
An Interactive Electronic Technical Manual (IETM) is a technical manual (e.g., maintenance,
user, training, operations, etc) prepared (authored) in digital form on a suitable medium, by
means of an automated authoring system, designed for electronic screen display to an end-user,
and possessing the following characteristics:
The format and style of the presented information are optimized for screen presentation
to ensure maximum comprehension; that is, the presentation format is frame-oriented
and not page-oriented."
The elements of technical information constituting the technical manual are so
interrelated that a user's access to the required information is facilitated to the greatest
possible extent and is achievable by a variety of paths.
Display devices, including personal computers and portable laptop devices can
function interactively (as a result of user requests and information input) in providing
procedural guidance, navigation directions, and supplemental information.
Screen presentations can include material derived from data stored in textual, graphical,
audio, or video form in a relational database which is composed of logically connected,
bud randomly accessible IETM data elements.
D-48
Standard
[]
ISO 12083
1994
Standard
[E]
ISO/DIS 2709
1996
Standard
[E]
AECMA SPEC
1000D
Change 4
Standard
[T]
MIL-M-87268
20 Nov 92
WAS NOT
FOUND
MIL-D-87269
20 Nov 92
WAS NOT
FOUND
MIL-Q-87270
Interactive Electronic
Technical Manual
(IETM) Database
20 Nov 92
Interactive Electronic
Technical Manual
(IETM) -Quality
Assurance Requirements
for Quality Assurance
Program.
Standard
[T]
Standard
[]
Cancelled No
S/S Document
31 May 1996
Information and
Documentation Electronic Manuscript
Preparation and Markup
Information and
Documentation - Format
for Information
Exchange
International
Specification for
technical Publications
using a Common Source
Database.
Interactive Electronic
Technical Manual
(IETM) Content
D-49
expectations and meets public acceptability. The process includes the planning, implementation,
and control of the total effort to develop a total system solution in response to the user
requirement and external constraints.
Standard
[E]
IEEE 1220
1994
(Feb 1995)
Trial
Use
Standard
Application
and
Management
of
the
Systems
Engineering
Process
UK DEF STAN
0060
Standard
[T]
AC/305(SLM) D23
Handbook
[T]
MIL-HDBK 59B
NOT 1
Interim Issue
1 1994
Canceled
10 Sep 1997
Application of Integrated
Logistic Support (ILS)
Orientation Document for
Integrated Logistic Support
Within the Framework of
Multinational Equipment
Projects
Continuous Acquisition and
Life-cycle Support(CALS)
Implementation Guide
No S/S Document
D9.3 Configuration Management
Configuration management provides the technical and administrative direction and surveillance
actions taken to identify and document the functional and physical characteristics of a
configuration item, to control the changes to a configuration item and its characteristics, and to
record and report change processing and implementation status.
D-50
Standard
[E]
ISO/CD 9004
Standard
[E]
ISO/CD 9004 - 1
1994
Standard
[E]
ISO 9004 2
1991
1994
1993
ISO 9004 4
1993
1994
1993
ISO/IEC 10164 1
Amd. 1
1996
ISO/IEC 10164 1
Amd. 1 Cor. 1
ISO/IEC 10164 2
1996
1993
Part 2 State
Management Function
ISO/IEC 10164 2
Amd. 1
1996
Implementation
Conformance Statement
Proformas
ISO/IEC 10164 2
Amd. 1 Cor. 1
1996
ISO/IEC 10164 2
Cor. 1
1996
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
D-51
Quality Management
Systems - Guidelines for
Performance
Improvements
Quality Management and
Quality System Elements
Part 1 Guidelines
Part 2 Guidelines for
Services
Information Technology
- Open Systems
Interconnection
Systems Management
Part 1 Object
Management Function
Implementation of
Conformance Statement
Proformas
Standard
[E]
Standard
[E]
Standard
[E]
ISO/IEC 10164 3
1993
ISO/IEC 10164 3
Amd. 1
1996
ISO/IEC 10164 3
Amd. 1 Cor. 1
ISO/IEC 10164 4
1996
1992
ISO/IEC 10164 4
Amd. 1
1995
Implementation of
Conformance Statement
Proformas
ISO/IEC 10164 4
Amd. 1 Cor. 1
1996
ISO/IEC 10164 4
Cor. 1
1994
ISO/IEC 10164 4
CD Cor. 2
ISO/IEC 10164 5
1993
ISO/IEC 10164 5
Amd. 1
1995
Implementation of
Conformance Statement
Proformas
ISO/IEC 10164 5
Amd. 1 Cor. 1
1996
ISO/IEC 10164 5
Cor. 1
1994
ISO/IEC 10164 5
CD Cor. 2
D-52
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
ISO/IEC 10164 6
1993
ISO/IEC 10164 6
Amd. 1
1996
Implementation of
Conformance Statement
Proformas
ISO/IEC 10164 6
Amd. 1 Cor. 1
1996
ISO/IEC 10164 6
CD Amd. 2
ISO/IEC 10164 7
1992
ISO/IEC 10164 7
Amd. 1
1995
Implementation
Conformance Statement
Proformas
ISO/IEC 10164 7
Amd. 1 Cor. 1
ISO/IEC 10164 8
1996
ISO/IEC 10164 8
Cor. 1
1995
ISO/IEC 10164 8
Cor. 2
1996
ISO/IEC 10164 8
Cor. 3
ISO/IEC 10164 9
1999
ISO/IEC 10164 9
Cor. 1
ISO/IEC 10164
10
1996
1993
1995
1995
Part 10 Usage
Metering Function for
Accounting Purposes
1998
Implementation
Conformance State
Proformas
ISO/IEC 10164
10 Amd. 1
1999
ISO/IEC 10164
10 Cor. 1
D-53
Standard
[E]
ISO/IEC 10164
11
1994
1998
Implementation
Conformance State
Proformas
ISO/IEC 10164
11 Amd. 1
1999
Standard
[E]
ISO/IEC 10164
11 Cor. 1
ISO/IEC 10164
12
1994
Part 12 Test
Management Function
1998
ISO/IEC 10164
12 Cor. 1
1999
Standard
[E]
ISO/IEC 10164
12 Cor. 2
ISO/IEC 10164
13
1995
Part 13 Summarization
Function
1999
Implementation
Conformance State
Proformas
ISO/IEC 10164
13 Amd. 1
1999
Standard
[E]
ISO/IEC 10164
13 Cor. 1
ISO/IEC 10164
14
Standard
[E]
ISO/IEC 10164
14 Cor. 1
ISO/IEC 10164
15
Standard
[E]
ISO/IEC 10164
15 Cor. 1
ISO/IEC 10164
16
1996
1995
Part 15 Scheduling
Function
1999
1997
Part 16 Management
Knowledge Management
Function
1998
ISO/IEC 10164
16 Amd. 1
D-54
Standard
[E]
ISO/IEC 10164
17
Standard
[E]
ISO/IEC 10164
17 Cor. 1
ISO/IEC 10164
18
1996
1999
1997
Part 18 Software
Management Function
1999
Standard
[E]
ISO/IEC 10164
18 Cor. 1
ISO/IEC 10164
19
Standard
[E]
ISO/IEC 10164
20
1999
Standard
[E]
ISO/IEC 10164
21
1998
Standard
[E]
Standard
[T]
ISO/IEC FCD
10164 22
STANAG 4159
Standard
[T]
MIL-STD-973
Profile
[N]
MIL-STD-483A
NOT 1
1998
Ed 2
Canceled
S/S MIL-STD-973
Standard
[]
MIL-STD-498
NOT 1
Canceled
S/S IEEE/EIA
12207.0 12207.2
D-55
Part 19 Management
Domain and
Management Policy
Management Function
Part 20 Time
Management Function
Part 21 Command
Sequencer for Systems
Management
Part 22 Response Time
Monitoring Function
NATO Materiel
Configuration
Management Policy and
Procedures for multinational Joint Projects
Configuration
Management Practices
for Systems, Equipment,
Munitions, and
Computer Programs.
Configuration
Management Practices
for Systems, Equipment,
Munitions, and
Computer Programs.
Configuration
Management and
Software Development.
Note: The Policy and applicable standards for NATO Configuration Management have not yet
been determined, but the NCMB/NICG -sponsored Acquisition Workshop held in 1994-1995 has
this topic under consideration.
D9.4 Environmental Life-cycle Assessme nt
Environmental issues are becoming increasingly important and this field is undergoing rapid
advancement and change. Not only is the body of knowledge increasing but the demand for
consistent, usable guidelines and reliable standards is also becoming obvious. In the face of
environmental claims, it is essential to know the environmental impact of product design, usage
throughout the life-cycle, and ultimate disposal. Although this topic is not specific to CALS,
users and regulatory bodies will require access, throughout a product life-cycle, to reliable
information to assist in the development of regulations, operating instructions, and disposal
programs which recognize environmental issue.
Standard
[E]
ISO 14040
1997
Standard
[E]
ISO 14041
1998
Standard
[E]
Profile
[]
ISO/FDIS 14042
1999
Environmental
Management Life-cycle
Assessment Principles
and Framework
Life-cycle Assessment
Goal and Scope
Definition and Inventory
Analysis
Life-cycle Impact
Assessment
Note: The Policy for Life-cycle Assessment and applicable standards for NATO assessment of
environmental impacts have not yet been determined, but the NCMB/NICG -sponsored
Acquisition and Operational Logistics Workshops held during 1994 -1996 have Life-cycle
matters under consideration.
D9.5 Disposal of Equipment
This paragraph will consider the methodology required for defense equipment disposal in the
future.
Montreal Convention Particular reference will be made to the standards applicable to the
disposal of products which require special handling (e.g., Radioactive, Toxic, Corrosive,
Poisonous, etc) and to the life-cycle data requirements of products covered by the
Montreal Convention.
UN List - Although no standard applicable to disposal of hazardous items has yet been
identified, some information is contained in a document know as The UN List
UN Recommendations on the Transport of Dangerous Goods ST/SG/AC.10/1 Rev 5
Chapter 2
D-56
Reference may also be made to NATO mechanisms which exist [STANAGS] or are under
development [E.G., NAMSA SHARE] to assist in formulating disposal methodology.
U.S. DoD MIL-STD-1388 contains some data elements which carry information appropriate to
the U.S. Disposals Process but this standard is currently being reviewed pending its withdrawal.
Standard
[]
Profile
[]
TBD
ISO 8402
1994
Standard
[R]
ISO 9000 - 1
1994
Standard
[R]
ISO 9000 - 2
1997
Standard
[R]
ISO 9000 3
1997
ISO/CD 9000
D-57
Quality - Vocabulary
Quality Management
Systems- Fundamentals
and Vocabulary
Quality Management and
Quality Assurance
Standards
Part 1 Guidelines for
Selection and Use
Part 2 Generic
Guidelines for the
Application of ISO 9001,
ISO 9002, and ISO 9003
Part 3 Guidelines for
the Application of ISO
9001: 1994 to the
Development, Supply,
Installation, and
Maintenance of
Computer Software
Standard
[R]
ISO 9000 4
1993
Standard
[R]
ISO 9001
1994
ISO/CD 9001
Part 4 Guide to
Dependability Program
Management
Quality Systems - Model
for Quality Assurance in
Design, Development,
Production, Installation,
and Servicing.
Quality Management
Systems - Requirements
ISO/CD 9004
Standard
[R]
ISO 9004 - 1
1994
Standard
[R]
ISO 9004 2
1991
1994
ISO 9004 4
1993
1994
Standard
[R]
Standard
[R]
Standard
[R]
Standard
[T]
AQAP 1
Standard
[T]
AQAP 13
1993
Quality Management
Systems Guidelines for
Performance
Improvements.
Quality Management and
Quality Systems
Elements
Part 1 Guideline
Part 2 Guidelines for
Services
Mutual Acceptance of
Government Quality
Assurance
NATO Requirements for
an Industrial Quality
Control Program
NATO Software Quality
Control System
Requirements.
Note: Quality Standards for NATO CALS applications have not yet been verified.
D-58
AC/313 - D/67
9 Jun 95
STANAG
NK
STANAG
NK
D-59
Standard
[R]
ISO/IEC 9796
Standard
[R]
Standard
[R]
Standard
[R]
Profile
[E]
Standard
[]
Guidance
[]
FIPS 161-1
1991
Ed 1
1997
ISO/IEC FDIS
9796 - 3
STANAG
AC/313 -D/66
Information Technology
- Security Techniques Digital Signature
Scheme giving Message
Recovery
Part 1 Mechanisms
Using Redundancy
Part 2 Mechanisms
using a Hash Function
Part 3 Discrete
Logarithm Based
Mechanisms
U.S. Federal Information
Processing Standard
NK
14 Sep 95
In general, it should be noted that, in principle, CALS products should be software and hardware
independent. Any departure from this principle must take into account the eventual use of the
data so acquired and management should consider not only Project Office requirements but also
the needs of the users during the whole of the life-cycle, so far as these may be ascertained.
D10.6 Electronic Data Interchange (EDI)
Data Exchange should be specified by electronic means unless operational requirements have
determined that such means are inappropriate or not cost-effective.
D-60
Standard
[R]
ISO 7372
1993
Standard
[R]
ISO 9735
1988
1992
Standard
[R]
ISO 9735 1
1998
1998
Standard
[R]
ISO 9735 2
1998
Standard
[R]
ISO 9735 3
1998
Standard
[R]
ISO 9735 4
1998
Standard
[R]
ISO 9735 5
1999
Standard
[R]
ISO 9735 6
1999
Standard
[R]
ISO 9735 7
1999
D-61
Standard
[R]
ISO 9735 8
1998
Standard
[R]
ISO 9735 9
1999
Standard
[T]
ANSI X.12
Version 3
Release 3
Sub-release
2 (June
1993)
Profile
[E]
FIPS 161-1
Standard
[T]
STANAG 5500
Profile
[T]
ADatP-3
D-62
Standard
[E]
AECMA 2000M
Revision 3.0
Profile
[E]
UK DEF STAN
0060 Part 20
Interim Issue
1
Guidelines
[R]
AC/313 - D/60
17 Nov 94
Guidelines
[E]
AC/313 - D/
1 Aug 95
Material Management
Integrated Data
Processing for Military
Equipment - Volume 4
Appendix 2 Annex G Example of an
Interchange Agreement
Application of Integrated
Logistic Support (ILS) Electronic Data
Interchange Agreement
for Data Exchange
specified in AECMA
SPEC 2000M
Guidelines and Sample
Provisions for
Memoranda of
Understanding
Guidelines and Sample
Clauses for Electronic
Data Interchange
Standard
[R]
Standard
[R]
ISO 639
1988
ISO/CD639 1
ISO 639 - 2
1998
ISO 8601
1988
ISO/WD 8601
2nd Ed.
1991
D-63
Standard
[R]
ISO 4217
1995
Standard
[R]
ISO 3166 - 1
1997
Standard
[R]
Standard
[R]
ISO 3166 - 2
1998
ISO 3166 - 3
1999
Standard
[R]
ISO/IEC 11179 - 1
Standard
[R]
Standard
[R]
ISO/IEC 11179 2
ISO/IEC 11179 3
1994
ISO/IEC WD
11179 3
ISO/IEC 11179 4
2nd Ed.
Standard
[R]
ISO/IEC 11179 5
1995
Standard
[R]
ISO 11179 - 6
1997
Standard
[R]
1995
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
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
Standard
[E]
ISO/IEC 9075
3rd Ed.
1992
1996
1995
1996
ISO/IEC WD 9075 6
ISO/IEC AWI 9075 7
ISO/IEC CD 9075 7
ISO/IEC FCD 9075 10
D-65
Information Technology
- Database Language Structured Query
Language (SQL)
Part 1 Framework
(SQL/Framework)
Part 2 Foundation
(SQL/Foundation)
Part 3 Call-Level
Interface (SQL/CLI)
Part 4 Persistent Stored
Modules (SQL/PSM)
Part 5 Host Language
Bindings
(SQL/Bindings)
Part 6 SQL/XA
Specialization
Part 7 - Temporal
Part 9 Management of
External Data
Part 10 Object
Language Bindings
(SQL/OLB)
Standard
[E]
ISO/IEC 10032
1995
Standard
[E]
ISO/IEC 9579
1999
3rd Ed.
2nd Ed.
Information Technology
- Reference Model of
Data Management
Information Technology
Remote Database
Access for SQL
Remote Database Access
for SQL with Security
Enhancement
Note: As far as we are aware, NATO has not yet adopted any International Standard for use
within NATO as a Standard Query Language.
D10.11 Contractor Integrated Technical Information Service
Contractor Integrated Technical Information Service (CITIS) is intended to be an efficient,
contractually implementable means for providing Purchasers with on-line access to, and
exchange of, Contractor-generated and maintained data specified in a Contract Data
Requirements List (CDRL).
Standard
[T]
MIL-STD-974
20 Aug 93
Contractor Integrated
Technical Information
Service (CITIS)
The initial U.S. concept described in MIL-STD-974 specified requirements within a U.S. legal
framework; such a framework does not necessarily exist outside the US. Intellectual Property
Rights and other legal issues may inhibit the implementation of a CITIS approach within NATO
unless clear contractual agreements can be reached within each project, and therefore it has not
yet been possible to determine the NATO Policy towards CITIS or to define a standards for its
implementation.
Section 5 of this Handbook addresses the use of CITIS.
D10.12 Automated Interchange of Information
MIL-STD-1840 defines the procedures for handling several forms of document transmittal and
for the transmittal of product data that does not consist of documents. However, it prescribes
that the primary and only required form is that of SGML encoded text with graphics in separate
(linked) files.
D-66
Standard
[T]
MIL-STD-1840
Revision B
3 Nov 93
Revision C
26 June 1997
Automated Interchange
of Technical Information
MIL-T-31000
Revision A
1 Dec 92
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
D-68
INDEX OF STANDARDS
The main standards referenced in this section are as follows:
AcodP-1
AdatP-3
AECMA 2000M
AECMA SPEC 1000D
ANSI/ASME Y14.26M
ANSI/IEEE 1076
AQAP 1
AQAP 13
IEEE 1220:1994
ISO 1000
ISO 10164
ISO 10646-1
ISO 11172
ISO 11179
ISO 12083
ISO 13584
ISO 14041
ISO 14042
ISO 3166
ISO 31
ISO 4217
ISO 639
ISO 646
ISO 6709
ISO 6936
ISO 7372
ISO 8601
ISO 8613
ISO 8824/8825
ISO 8859
E-1
ISO 8879
ISO 9000
ISO 9001
ISO 9004-2
ISO 9004-7
ISO 9075
ISO 9660
ISO 9735
ISO DIS 10918
ISO/IEC 9069
ISO/IEC 10149
ISO/IEC 10303
ISO/IEC 10918
ISO/IEC 12087
ISO/IEC 13673
ISO/IEC 8632
ISO/IEC 9592
ISO/IEC 9636
ISO/IEC 9796
ISO/IEC DIS 10179
ISO/IEC IS 10744
ISO/IEC TR 9573
ISO/IECS 13522
ISP 12064-1
ITU-TSB T6
MIL-D-28000
MIL-D-28002
E-2
MIL-D-28003
MIL-D-87269
MIL-HDBK-470
MIL-HDBK 59B
MIL-HDBK-SGML
MIL-M-28001
MIL-M-87268
MIL-Q-87270
MIL-STD-1379D
MIL-STD-1388-1A
MIL-STD-1388-2B
MIL-STD-1390
MIL-STD-1629
MIL-STD-1840
MIL-STD-482A
MIL-STD-785
MIL-STD-973
MIL-STD-974
MIL-T-31000
STANAG 3150
STANAG 4107
STANAG 4159
STANAG 4177
STANAG 4329
STANAG 5500
UK DEF STAN 0060
E-3
CALS TERMINOLOGY/ACRONYMS
Abstract
AECMA
ASCII
ASRL
Attribute Definition
Attribute (Specification)
List
Attribute (Definition)
List Declaration
Business Plan
F-1
CALS
CEN
CENELEC
CENELEC/ETSI
CFS
CITIS
Constructs
COTS
Commercial Off-The-Shelf
CNAD
CSL
CSR
DCA
DDRS
Declaration
DISA
Document Instance
F-2
Document Type
Declaration
Document Type
Definition (DTD)
DoD
DoDISS
DSSSL
DTD
EDI
EDIFACT
e-i-c
Element in Context
Element
F-3
Element Type
Declaration
Entity
Entity Reference
ETM
FOSI
FPSI
FPI
FPSI
IATA
ICOM
IEC
IETM
F-4
IGES
IIG
Information
Infrastructure
IMP
IPSC
ISO
LSA
Markup
NCMB
NCS
NIAG
NICG
NSLB
Objects
OS
Output Specification
F-5
Output Specification
(OS)
PA
Preparing Activity
Page Fidelity
Page Integrity
Parsing
PDL
PfP
Preparing Activity
F-6
Presentation
specification (PS)
PS
Presentation Specification
PSI
SACEUR
SACLANT
SGML
SGML Declaration
SGML Entity
SGML Instance
SGML Parser
F-7
SMA
STARS
STEP
Tag or Tagging
Task
Technical Publication
Verification:
This term refers to the parsing of the digital data stream containing
a publication to assure compliance with the standard (SGML,
CCITT, CGM, IGES) to which it was written. There is no intent in
this term to imply the validation/verification process used to certify
the content of the publication.
TLIMP
TM
Technical Manual
URL
Work Package
WWW
WYSIWYG
X.12
F-8
G-1
There may be benefit in tasking the OLA group to develop an IDEF model to show how an
Armed Force and or a Combined joint Task Force would integrate information from many DS
for the purpose of Sustainment (what is this?) or Mission Support.
G1.3 Candidate Interface Specifications
The following interactions are identified between the single DS and an Armed Force(s) and/ or
International Armament Co-operation organization, not under PM control.
Notes:
1. Items in brackets refer to Arrows in TLBM V5.0 e.g., (Current Requirement).
2. The asterisk * identifies a potential I.S. Expected to fall within the scope of Track 2
Standardization effort.
3. Comments are in italics.
G2.0 FROM DEFENSE SYSTEM TO THE ARMED FORCE
G2.1 Requirement
For changes to facilities (Request)
For additional Training e.g., new common skill requirements (Request)
Change request for other DS (Request)
G2.2 Design
Proposed change to AF design constraints or standards (Request)
Common parts used in this system * (not yet covered by TLBM. Needs a two way flow)
Identify Alternate Parts is this in use elsewhere with different id.* (Being explored with
AC135. The set of info needed to perform form, fit, and function comparison)
G2.3 Interface Details for Other Systems (DS Data)
G2.4 Support Design
Proposed changes to AF maintenance policy- harmonization of approach.
Data).
Potential new common tools and equipment* (DS data).
(Request, plus DS
Note: Provisioning of some parts may not be managed through life by the DS Life-cycle Owner
(LCO). If parts management is an AF activity, the following interactions will occur with AF
stock management agency.
Provisioning recommendations including re-procurement details.* (DS data)
Packaging Handling Storage and Transportation requirements * (DS data)
G-2
G2.5 Support
If maintenance is provided primarily on a single DS basis, support activities are assumed to lie
within the TLBM, under LCO control, and using the DS program SDE. If maintenance activities
have to be integrated across several DS, beyond LCO control, either for reasons of work
planning (e.g., a Brigade workshop, NAMSA) or access and availability reasons (e.g., ships,
aircraft) then the following interactions occur:
DS Support and Maintenance Instructions/ Plans*
Ad hoc work requirements *.
System changes required/permitted.* (Selected Configuration)
Details of resources to be provided by PM (Not covered)
System Ready for use (DS ready for use)
Operate
Operating instructions* (DS data where from?)
Operational support requirements interfaces, services needed* (DS Data from Obtain)
G3.0 FROM AF TO DS
Legal, Policy, Resources, Trained manpower, Program approvals, annual cash limits etc
(Constraints and Resources including: Business Directives, O&S Policy, users etc.)
G3.1 Requirements
Responsibility for establishing, validating, and sustaining the Mission Need for a DS lies with
the Operational Staff, not the LCO. The LCO/PM is responsible for delivering a system that
meets the need.
DS Operational Requirement (including inter-operability requirements)** (VMN)
Use Study* (Derived from VMN, Business Directives and U&S Policy reflected in Current
Requirement)
AF Maintenance and Support policy (O&S Policy)
Standardization policy (e.g., common parts to be used) (Business Directives and/or U&S policy)
Policy or constraints from International support MoUs (Business Directives)
G3.2 Design
Required Interfaces with other DS or facilities. (Business Directives for policy, with technical
details from External data)
Design Standards (Defense Pol and Stds)
Imposed Design solutions (e.g., new tank must use this engine) (Business Directives)
G3.3 Support Design
Common skills which can be expected* (External Data).
G-3
G-4
Application/
Benefits
Requirement Management
(Pre and Post Contract Award)
Software tool used to manage the requirement document in a structured form
through life. Enables better control of the requirements and easier management
and traceability of changes.
Time
Preproduction
Production
Use
Quality
We know what we
are meant to do and
who asked for it.
Better baseline
for in service
CM.
Maintaining a
valid and
current
structured
requirement
statement
during the
in-service
phase, it
provides a
better baseline
for decisions
on support
planning and
upgrades.
Cost
Do the right
thing.
Provides good
baseline for
justification
of changes.
Example
Preproduction
Production
Use
Time
Faster
communications
lead to faster
decisions.
Example
H-1
Quality
Cost
Quicker is
cheaper.
Some
potential for
travel savings.
Example
People know
production
management.
what to do
Production
when.
Better visibility
of project
status.
Use
Example
Example
H-2
Example
Saves traveling
production
expenses.
time.
Concurrent
working speeds
up design time.
Production
Use
Computer modeling was used almost exclusively to design and build the first test
aircraft (no mock-ups), resulting in:
Application/
Benefits
Allows for
Saves on
production
time.
testing a great
traveling
deal of designexpenses.
Concurrent
variants.
working speeds
Saves because
up design time,
not having to
Allows for
not having to
testing under
build
build physical
many
prototypes.
prototypes for
simulated
testing.
(hazardous)
environments
Concurrent
and conditions.
testing and
redesign
possible
Production
Use
Example
H-3
Control of
production
to better access to
requirement
information.
and
requirement
changes.
Control of
emergent
design.
Production
Use
Savings in
maintenance time
through better
information.
Example
H-4
Consistent CM info
through the supply
chain.
We know what we
have to support.
Minimize
rework.
Minimize
unnecessary
purchases
I1.1 Introduction
The NATO CALS Handbook provides decision templates for selecting the most effective digital
data formats and media formats. Digital data includes the Technical Data Package (TDP),
Technical Manuals (TM), and the Logistic Support Analysis Record (LSAR).
Effective
acquisition and use of digital data can only be accomplished with full consideration of the ability
of NATO/NATO nations to receive, store, distribute, and use the digital data.
The infrastructure requirement is a key consideration in implementing the CALS strategy on any defense
system acquisition. Do not buy digital data if there is not an adequate digital data infrastructure
capability.
The project manager should ensure that all recipients of digital data will have the capability to
receive, store, and maintain the provided data. The materials and equipment required for
receiving, storing, and maintaining data constitutes the infrastructure requirements of CALS.
This infrastructure requirement is a key consideration in implementing the CALS strategy on any
defense system acquisition.
Deficiencies in the NATO/NATO nations' infrastructure may
require investments by the project manager to implement the CALS strategy effectively.
I1.1.1 Purpose
This section is intended to provide NATO/NATO nations project managers with an overview of
hardware and telecommunications requirements for the creation, management, and use of digital
technical data. Paragraph 7.2 discusses the general considerations and requirements of a
computer system infrastructure. Paragraph 7.3 describes the specific requirements that are
dependent on the data type, data format, and user function.
I1.1.2 Infrastructure Resource Planning
The project manager should plan to fund an infrastructure modernization program. The project
manager should plan infrastructure requirements such that funding can be set aside to be used
when the infrastructure investment is required. This approach will utilize program funding and
resources better.
I-1
The computer hardware must have the appropriate processing speed and display capability to run
the application software adequately. The application software must perform specific tasks on the
digital data that are required by the user. Rather than recreate the data, the appropriate computer
networking system should allow the users to share data and resources, and telecommunications
equipment should allow users to transfer digital data easily. After reading the NATO CALS
Handbook, the project manager should have an implementation approach for data type, process,
format, and delivery/access method. With this information, infrastructure requirements can be
identified. Each decision will affect the life-cycle costs of a program and the cost of the
program's computer infrastructure. Human- interpretable data formats, such as Page Description
Language (PDL) and raster, may not be suitable as source data for other applications.
Processable data formats can be integrated with other digital data to reduce the total life-cycle
costs. The following topics are addressed as considerations for a computer infrastructure:
Computer Architecture
Computer Operating System
Storage Devices
Output Devices
Computer Graphics and Monitors
Network Devices
Application Software
Software Licensing
Network Protocols
Local Area Networks (LANs)
Wide Area Networks (WAN)
Data Process
The above topics are the basis of discussion in Paragraph 7.3, Infrastructure Requirements, for
specific hardware, software, and telecommunication requirements of a program. Also included
are several decision diagrams to help the project manager.
I1.2.1 Hardware Considerations
Computer hardware consists of the computer processor, memory, monitor, storage devices, and
input devices. Each computer should be tailored to fit the need of the main application.
Computational intensive applications such as mechanical solid modeling or engineering
simulation will require a larger amount of memory than general text and 2-D graphics-based
applications. Each application requires a distinct amount of hard disk space for data storage.
Raster images and simulation models tend to require more disk space than vector-based
databases such as Computer Graphics Metafile (CGM) or Computer Aided Design (CAD) files.
I-2
Each computer is designed to meet a specific requirement. In many cases, the computer
architecture is driven by the choice of application software needed to perform a specific task.
For this reason, the software selected may be the most important decision made. The Personal
Computers (PC) are the most widely used computers and are ideal for non-intensive applications
that require low-to-medium graphic displays. The RISC workstations are widely used in
engineering and technical publishing applications that require either a powerful processor for
extensive calculations or a high-resolution graphics display for document editing. A diskless
RISC workstation may provide a low-cost solution to some engineering computing needs. These
workstations typically have a small hard disk for the operating system while the application
software and user files are loaded from a server workstation that is connected by a network. A
third option is a graphic display workstation that supports the X-window Motif standard.
However, a PC with X-window emulation software may provide the same features at a lower
cost. The standard options for each type of computer are presented in Table I-1.
Processor
Memory
Media
Hard Drive
Floppy Drive
Tape Drive
CD Drive
WORM
Monitor
2 Gb
3.5
Yes
Yes
Optional
19"-21 High Res
offered users multitasking and a 32-bit operating system. Windows 95 and Windows NT are
similar to System 7, discussed in following paragraph and offers many advantages compared to
DOS. The largest benefit is that Windows NT is available on PCs and RISC-based workstations.
This will allow the engineering users access to the same application software on a RISC
workstation that most business users have on a PC.
A popular operating system used for the 68000 series processor is System 7, which is a true
windowing system with 32-bit multitasking capabilities. This operating system has attained
popularity due to its ability to meet the demands of both beginner and expert computer users.
The operating system has strict hardware/software standards that reduce compatibility and
installation problems, although the cost of this system is generally higher than similar
Windowing systems. Most RISC workstations currently have a UNIX operating system based
on System V UNIX or Berkeley BSD 4.4 UNIX that is POSIX compliant. Each operating
system provided with RISC workstations is unique, but most will run application programs that
were compiled using System V or Berkeley BSD UNIX. The CAD2 program specifies a POSIX
operating system with a Motif standard graphical user interface. OSF/1.0, OPEN VMS, and
Windows NT are new operating systems that are designed to allow users a greater variety of
application software. Windows NT is designed to allow users of the RISC-based computer and
80486-processor-based-computer to run the same operating system and the same versions of
application software.
I1.2.1.3 System Backup
System backup is very important to the project manager. If managed properly, systems can be
designed such that even a catastrophic loss of data can be recovered in a relatively short period.
To do this, the project manager should address areas such as hard drive or CPU failure, lightning
strike, fire, or damaging storm in a disaster recovery plan. Backup of a system should include a
practical means to back up system data. This is a function that should be easy to accomplish and
convenient to the users. If a system does not have a convenient backup system, the user will be
unlikely to back up regularly and, thus, risk catastrophic loss of program data. An acceptable
means to archive system and program data is to use a tape backup system.
I1.2.1.4 Physical Media
Each computer system needs the appropriate amount of data storage capacity to allow users
access to all areas of project data. This disk space can reside on each computer or on a network
file server.
Storage technology is constantly changing, and the project manager should
understand that the physical media addressed below is provided as a guideline but does not
necessarily imply that only the following technology should be used in building infrastructure.
When evaluating whether to use new technology, the project manager should assure
compatibility with other equipment of the same technology or with older, less sophisticated
media.
I1.2.1.4.1 Magnetic Media
Magnetic disk drives are available for most computer systems. Magnetic disk drives can store
from 200 to 4,000 megabytes and should be American National Standard Institute (ANSI), SCSI,
I-4
or IDE compatible. SCSI provides compatibility and allows for expansion when greater disk
space is required. Magnetic disks can be used to transfer data when required. The most common
magnetic disk used to transfer data is the 3.5-inch diskette that can hold up to 1.44 MB of data.
Using magnetic disks to transfer data should only be considered when the total data does not
exceed 10 MB. When transferring over 10 MB of data, a 9-track computer tape or Quarter Inch
Cartridge (QIC) tape would be better suited (MIL-STD-1840). The standard 9-track tape can
store approximately 240 MB of data compared to 500 MB with the QIC. The exact
configuration of the tape format can greatly affect the capacity of the tape. Tape drives that
accept tape cartridges are easier to obtain and integrate into a desktop computer system.
However, the project manager should confirm that tape formats are compatible. An alternative
technology to 9-track tape or an optical drive is the Digital Audio Tape (DAT) drive. DAT
drives can store up to 5 Gigabytes (G-byte) of data. The tapes are small and are easily integrated
into the desktop environment. This avoids capacity problems that are sometimes encountered in
9-track and optical drives.
I1.2.1.4.2 Optical Media
Optical drives are readily available and come in many different types and sizes. The most
common optical drive is the 5.25-inch Compact Disk (CD) Read Only Memory (ROM) drive.
These drives are used for end user systems similar to the Advanced Technical Information
Support (ATIS) system. A Write Once/Read Many (WORM) optical disk system should be
considered for storing the final deliverable digital data for a large project. Optical disks can store
up to 200 G-bytes. This will provide the project with a non-erasable copy of the data that can
help in configuration control. However, not all WORM optical disk systems produce the same
format as CD, and compatibility with the end user should be verified.
I1.2.1.5 Output Devices
Each computer user will need access to a printer and/or a plotter. These devices can be set up on
a LAN rather than directly to a specific computer, so that network users can share the devices.
Printers are generally used to produce A or B (ANSI Y14.1-80) size documents. Plotters are
used to create up to J size documents. An A size PostScript compatible laser printer is the
standard printer recommended for general use. The printer should have a minimum resolution of
300 by 300 Dots Per Inch (DPI) and a minimum print speed of four to eight pages per minute.
An A/B size laser printer would be better suited to print engineering drawings. Most drawings
are legible when printed on B size paper. The two main types of plotters are electrostatic and
pen plotters. Electrostatic E size plotters are recommended for engineers involved in the
creation and review of engineering documents or when there is a requirement to plot up to E
size raster drawings. A pen plotter may suffice, but these plotters can take up to 30 minutes to
print a vector drawing versus only 1 to 2 minutes for an electrostatic plotter. Pen plotters cannot
be used to plot raster images.
I1.2.1.6 Computer Graphics and Monitors
The resolution and monitor size are important considerations when choosing the proper monitor.
Most users who work with graphical data such as engineering drawings or technical illustrations
will be more efficient with a high-resolution, 19-inch monitor. This is especially true when
I-5
working with raster files. A larger monitor may eliminate the need to zoom in on a section of the
drawing or illustration.
A 14- to 16-inch monitor is suited only for general Windows
applications and is not recommended for reviewing drawings or illustrations. An option for
some RISC-based workstations is real-time, 3-D graphic manipulations. This allows the user to
rotate and/or scale the view of the object in real time. Any engineer performing solid modeling
or finite element analysis will increase productivity on the workstation with this option. Screen
redraws for complex images can take up to several minutes with a standard graphics option but
can be performed instantaneously with the 3-D graphic processors.
I1.2.1.7 Network Devices
Network devices include equipment that is required to connect a single user station to an existing
network or to connect two or more networks together. Examples of this type of equipment
usually are network cards, bridges, and routers. The basic requirements for creating a single
LAN are a Network Interface Card (NIC) and the appropriate cable; for example, an Ethernet
board for each computer and the coaxial or twisted-pair cable to connect each computer.
Network bridges can be added to the LAN, to connect to other LANs or manage the LAN
electronic message traffic. Network terminal servers allow terminals, modems, and printers to be
connected into the LAN. Network routers enable remote LANs to be connected or the LAN to
connect to a WAN. All network devices should support the Ethernet V2.0 and Institute of
Electrical and Electronic Engineers (IEEE) 802.3 standards.
Due to LAN configuration
complexity and variety, the project manager should discuss infrastructure requirements with the
supporting activity Automated Data Processing (ADP) manager before purchasing any LAN
equipment.
I1.2.1.8 Input Devices
There are many different ways to provide input to a computer system. One of the most basic
input devices is a keyboard. There are many different arrangements; however, the industry
standard is the 101-key type. Additional devices include mice, track balls, digitizing tablets,
light pens, and scanners. With the exception of the scanner, all the previous devices generate
data with the user's guidance. The technology of scanners has greatly increased in the past few
years and can add speed in the generation of technical data.
Scanners can have many features including color, gray scale, line art, and a host of others. As a
general rule, the more features and higher detail of the image, the more disk space is required.
There are definite ranges where there is a point of diminishing return comparing quality of image
vs. size of image. Attention should be made to this aspect, because, not only will a large image
consume a large amount of disk space, but it will also slow the speed of the computer when the
graphic is to be displayed. There are many different types and sizes of scanners available to the
project manager.
The two basic types of scanners are page scanners and large-format scanners. Page scanners are
designed to be implemented with text or graphics up to 8.5 by 11 inches. When scanning images
for documents that are currently being created or updated, a single-page scanner should work
well. Features for a single-page scanner include quality of scan and moderate speed. Sheet-fed
scanners are generally used to archive large amounts of paper data. The features required are
I-6
speed of scan and moderate resolution. Large-format scanners are used to generate raster images
from paper drawings up to 60 inches wide with an unlimited length. The scanners are
monochrome/gray scale and are a single-sheet feed operation. In recent years, the speed and cost
have been significantly reduced while quality has been enhanced.
Large-format scanners can provide a means of converting old, deteriorating paper drawings into
an electronic form that can be edited and restored, if required. Many activities and sites are
currently using scanners. Although the cost has been reduced significantly, a large-format
scanner is a major investment and is usually purchased by the software support activity as a
shared resource.
I1.2.2 Software Considerations
The project manager must consider how a specific software application fits into the complete
data process. Configuration management software may be needed to control the access and
revision of digital data files as well as the specific application software. Software applications
and repository services already available should be considered before different software
applications are examined. Another important question is whether the software import and
export files are in a CALS format such as MIL-D-28000 Initial Graphics Exchange Specification
(IGES) and MIL-M-28001 Standard Generalized Markup Language (SGML). This will ensure
the data will be accessible by other users.
I1.2.2.1 Data Formats
Digital data deliverables available in the CALS environment are extensive. The NATO/NATO
nations project manager must evaluate the need to determine which format is appropriate at each
stage of a specific program. The final deliverables must be in a standard CALS format while
preliminary digital data may be in a format that is agreeable to the project manager and the
contractor. Commercial word processing software with the capability of text attribute, style
sheets, and imbedded graphics may be used to view and annotate preliminary TMs. A list of
various digital data formats is shown in Table I-2.
Table I-2 Standard Digital Data Formats
STANDARD DIGITAL DATA FORMATS
MIL-D-28000 IGES /CALS
MIL-M-28001 SGML /CALS
MIL-R-28002 Raster graphics /CALS
MIL-D-28003 CGM for illustration data /CALS
Formatted American Standards Code for Information Interchange (ASCII) text
Page Description Language POSTSCRIPT
VHSIC Hardware Description Language (VHDL)/BBS
Electronic Design Interchange Format (EDIF)/BBS
Institute for Interconnecting and Packaging (IPC)-D-350 /BBS
Native CAD format
I-7
The project manager must consider who is going to use the data in the armed forces and ensure
that the infrastructure matches each user's requirements and the function of the requirements.
The required infrastructure will vary depending on the data use and the data format. Formats,
such as Raster, will require a higher resolution monitor but less processing capability to view and
modify compared to a solid-model-based CAD system. Raster and IGES data formats generally
necessitate larger disk memory. Some data functions cannot be performed on all digital data
formats.
I1.2.2.2 Operating System Compatibility
The first consideration is which operating systems the program uses. A software application that
supports both Disk Operating System (DOS) for the PCS and UNIX for the RISC-based
workstations will allow greater flexibility than a program tied to a single operating system. This
is especially true when business and engineering personnel need to review the digital data. Most
business applications operate on a PC while most engineering applications operate on
RISC-based workstation. X-window emulation software may solve some problems. The current
generation of X-window emulation programs are quite robust and can be used to allow PC users
access to UNIX X-window software from a PC. The PC emulation packages for RISC-based
workstations are not as sophisticated as the X-window emulation programs.
I1.2.2.3 Application Packages
General types of packages of application packages are shown in Table I-3.
I-8
I-9
I1.2.3 Telecommunications
The standard equipment required for telecommunications is a modem. The modem is used to
link two or more computer systems via a phone line. Normal uses could include connection to
larger computer systems via a terminal emulation program, connection to a remote site to
send/receive files, or to access Contractor Integrated Technical Information Service (CITIS). A
more specialized modem that has become readily available is a modem capable of sending and
receiving Facsimile (FAX) data as well as the standard CCITT (Consultative Committee for
International Telegraphy and Telephony) information. The speed requirement of the modem is
directly related to the size of the data files that will be transferred and frequency that the modem
will be used. If data is only to be accessed and viewed remotely, using a terminal emulation
program, then a 9600-baud (character per second) modem is probably acceptable. However, if
there is a requirement to send/receive large data files, a faster modem with built-in data
compression is required. Before purchasing a modem, the project manager should assure
compatibility with the remote location.
I1.2.3.1 Network Protocols
Network protocols are essentially the software standards that enable users to communicate over
LANs or WANs. There are several types of network protocols that are acceptable in the CALS
community. Factors to consider when choosing the type of network protocol needed include
current facility LAN/WAN compatibility, interface requirements, data to be transferred, and
distance of network. The following are common protocols and their capabilities.
GOSIP: The Government nations Open Systems Interconnection Profile (GOSIP) is the
standard for networking protocols. Its function is to provide interoperability among
different equipment manufacturers.
TCP/IP: Transmission Control Protocol/Internet Protocol (TCP/IP) is the general protocol
(IEEE 802.3) for most engineering workstations and servers. It allows UNIX computers
to connect to each other for remote login with 'rlogin' and 'rsh' UNIX commands. It also
allows a PC with X-windowing software to establish an X-window session on a UNIX
server.
I1.2.3.2 LAN
A LAN is required when there are several users who need to share data, application software,
and equipment. The LAN network devices commonly used are printers, disk drives, modems,
and other Management Information System (MIS) equipment. As the name LAN suggests, this
type of network is contained within a small area (usually within the same building or floor).
LANs are based on the needs of the user. Some LANs may only need to be connected to share
resources such as modems or printers. Another LAN function could be used for configuration
management of large CALS databases. A common need for organizations is to transfer data
from one LAN to another or to connect to a large mainframe computer. These functions can be
achieved with what is commonly referred to as a bridge.
I-10
A LAN is required when there are several users who need to share data, application software,
and equipment. The LAN network devices commonly used are printers, disk drives, modems,
and other Management Information System (MIS) equipment. As the name LAN suggests, this
type of network is contained within a small area (usually within the same building or floor).
LANs are based on the needs of the user. Some LANs may only need to be connected to share
resources such as modems or printers. Another LAN function could be used for configuration
management of large CALS databases. A common need for organizations is to transfer data
from one LAN to another or to connect to a large mainframe computer. These functions can be
achieved with what is commonly referred to as a bridge.
I1.2.3.3 WAN
A WAN is required when there are several users who need to share data or equipment over a
large area (usually many miles). A WAN should only be considered if there is a need to transfer
large amounts of data for long periods. If occasional or limited use of access to remote data or
equipment is needed, then a modem will suffice.
I1.2.4 Data Processes
The project manager needs to determine what digital data functions are required and who is the
data user. The infrastructure may vary for each use of the data, if the hardware, software, and
network cost are to be minimized. Generally, certain data functions are performed with a
specific format. Conversion software may need to be procured to ensure that the format of the
data is also compatible with the end user's requirements. The user functions are divided in the
following areas.
ROM. The comment/annotate function for processing TMs is used primarily during the review
process prior to and during validation. This is to allow technical personnel the capability to
include additional information, if required. To accomplish this task, there must be a link
between CD ROM data and additional information stored remotely. If there is no direct link
between the CD and the additional information, then there is no requirement to supply CD ROM
drives with a system required to comment/annotate TMs. The hardware requirements for
updating and maintaining TMs include the capability to work with tagged SGML documents.
The system requirements for using an SGML editor can be found in Table I-4. Specific
requirements, including CD ROM, scanners, and WORM drives, should be addressed on a
case-by-case basis depending on the type and amount of data being processed. The hardware
requirements for extracting, processing, and transforming TM data depend on the data being
generated. The TM can be generated in a commercial editor and translated into SGML later.
This can reduce the infrastructure requirements if there is a basic infrastructure already in place.
If the requirement is to transform an approved TM into an Interactive Electronic Technical
Manual (IETM), then the hardware should reflect standard equipment that will support an IETM.
Table I-4 Matrix of Infrastructure Requirements
PROCESS
TECHNICAL
MANUAL:
ARCHIVE
VIEW ONLY
COMMENT/ANNOTATE
UPDATE/MAINTAIN
EXTRACT/PROC./TRANSF.
PROCESS
TECHNICAL
DATA PACKAGE:
ARCHIVE
VIEW ONLY
COMMENT/ANNOTATE
UPDATE/MAINTAIN
EXTRACT/PROC./TRANSF.
PROCESS ILS/LSAR:
ARCHIVE
VIEW ONLY
COMMENT/ANNOTATE
UPDATE/MAINTAIN
EXTRACT/PROC./TRANSF.
P R
E I
N S
T C
I
U
M
/
4
8
6
S
C
A
N
N
E
R
X
X
X
C
D
/
R
O
M
W
O
R
M
T
A
P
E
D
R
I
V
E
W
O
R
D
S
G
M
L
P
R
O
C
.
V
I
E
W
E
R
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
I-12
D
A
T
A
B
A
S
E
S
P
R
E
A
D
S
H
E
E
T
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
G
R
A
P
H
/
R
A
S
T
E
R
G
R
A
P
H
/
V
E
C
T
O
R
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
I
L
S
/
L
S
A
R
X
X
X
X
X
P
R
I
N
T
E
R
S
P
L
O
T
T
E
R
S
X
X
X
X
N
E
T
W
O
R
K
S
X
X
X
X
X
X
X
X
X
X
I-13
individuals
involved
will
require
in
the
creation,
SGML editor
DTD editor
Illustrator editor for vector and raster
Configuration management database
I-14
SGML parser
illustrator editor for vector and raster
Database query application
Native CAD
CAD2
IGES view
FEM (VHDL simulation)
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
GES translators
Configuration management
Relational database
CAD2 - PWB layout
I-16
To establish a shared data environment with a common logical data structure amongst
all participating parties on both the government and the industry side.
The recommended solution for the shared data environment is:
Unclassified information: A shared data environment based on one logical information
structure with integrated access. Data can be allowed to be stored in several
geographical places, but in one logical structure. Information access shall be on-line.
Classified Information: Dedicated local systems with approved on-line connection. All
classified information shall be managed in the same logical structure as for unclassified
information.
The logical data structure for Viking should be able to hold and integrate all
information necessary to design, build, operate, and support the Viking submarines. It
should be based on open, international, or de facto industry standards, and necessary
commercial software should be available.
J-1
Editors Ref.:
fbp/98aaadzf
Report title:
Through Life Information
Management Strategy
Work carried out by:
Viking Information Management
group, see Appendix A
Edited by:
Nils Sandsmark,
Frank Brre Pedersen
Work verified by:
Boye Tranum
Date of this
Rev.
revision:
No.:
5 September
03
1998
Indexing terms
Information Management, Digital Information
Through Life, Viking
No distribution without permission from the
responsible organizational unit
Unrestricted distribution
J-2
J-3
Political decisions:
Non of the nations have a political decision to acquire submarines
Expected after PDP.
Concept choices already made:
Study phase shows that harmonization of operational and technical requirements is
possible, and that particular systems to fulfill the special Norwegian requirements can
be fitted into separate sections or modules.
Requirements for training:
To be decided during study phase.
2.3 Roles and relationships
Several actors, their roles, and relationships have been identified for the Through Life
Information Management (TLIM) of Viking. As for section 2.2, several decisions will have
to wait until the program as a whole has made the relevant governing decisions.
PMO and Prime Contractor:
The status of prime contractor to be decided during Study Concept Phase (SCP).
Several options are possible, two of which are:
1. One prime contractor is preferred.
2. The prime contractor could be an industrial group/joint venture with
participants from Norway, Denmark, and Sweden.
PMO and operational logistics and support concept:
To be decided during study phase.
Industry involvement through life:
Project Definition Phase: Common development of specifications between industry and
PMO.
Design Phase (DP): To be decided during study phase.
Production Phase (PP): To be decided during study phase.
Support Phase (SP): To be decided during study phase.
Management of mid-life-updates:
J-5
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.
Denmark has made a decision to replace all the old systems with one integrated system
(DeMars) common to the entire Danish Defense. This system will be implemented in
the period 1999-2004 and will therefore be in full operation well before the first
Viking submarine will be delivered. This means that for the Danish navy, only the
DeMars system needs to be addressed.
Sweden is using a number of legacy systems, see reference /3/. The Swedish Defense
has decided to put all software system development on hold until an ongoing study on
the issue has been completed. This study is planned to be completed within a couple
of years and until then it is difficult to make assumptions with respect to relevant IT
trends, policies and plans.
Norway is also using a number of legacy systems, see reference /4/. The Norwegian
Navy is currently into a major acquisition project, where new escort vessels are to be
procured. This project is of such a size that software standard, choices and policies
will be of great relevance to other projects, also Viking.
For Defense industries in Sweden, Denmark, and Norway, very little information has been
received. This will be addressed at a later stage.
5. Goals for Through life Information Management
5.1 Technical goals
With regard to Through Life Information Management, the following technical goals are set
for the Viking program:
To store system information according to a common logical data structure and be online available . This includes also all support and maintenance information.
To establish and run accurate and consistent configuration management through life.
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
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
Another important measure for the Viking program in order to support decisions regarding
Information Management is the life-cycle cost (LCC) model. This would naturally be a part
of the main LCC model in Viking. However, as the latter model is not established yet, this
will have to be postponed.
The assessment is performed using the philosophy of Criticality Management Tools (CMT)
as described in Refs. /5/-/6/. At the present stage, only a qualitative assessment is made.
The various options are evaluated on a relative scale, using the definitions listed in Appendix
B.
7.1 Shared data environment options
A qualitative assessment of the three solutions for a shared data environment (SDE) is
provided in Table 7.1 below. Refer to Appendix B for definitions of the terms used.
Table 7.1 Assessment of the Options for SDE
Solution
Cost
Solution A
Medium:
Cost estimate comparable
to other solutions
Solution B
Medium:
Cost estimate comparable
to other solutions
Solution C
High:
Cost estimate higher than
comparable solutions
Benefit
Risk
Low:
Off-line methods for
diversified information.
Requires a common data
administration
Significant:
Uncertainty
regarding ability
to adapt to
technological and
process changes.
Significant:
Geographically
distributed data
represents a
considerable
technological risk.
Critical:
Security
requirements not
acceptable.
Medium:
On-line methods for
geographically
distributed data.
Improved accessibility
due to one logic
High:
J-9
One multi security
system, with on-line
access to one logical
High:
Cost estimate higher than
comparable solutions
High:
One multi security
system, with on-line
access to one logical
structure.
Critical:
Security
requirements not
acceptable.
8. Recommendation
Based on the assessment of Section 7, the following points are made for the shared data
environment options:
Solution A is inadequate as far as functionality is concerned, i.e., it is based on oldfashioned working processes that inhibit the full utilization of a shared data
environment.
Solution B is acceptable with respect to cost. Furthermore, it has major benefits. The
associated risk level can be accepted.
Solution C is unacceptable with respect to handling of classified information.
Technical challenges in relation to developing a solution meeting the security
requirements may be unacceptably costly.
J-10
Commander T. Grasmo
Major B. Tranum
Principal Technical Officer U. S. Carlsson
Head of Division J. B. Leimand
Captain K. Eikanger (Meeting 1 through 4)
Senior Eng. V. Smberg (Meeting 5 and onwards)
Cons. N. Sandsmark
J-11
PG Viking
NATO CALS
FMV
FKO
SFK
DNV
Sweden
Denmark
Norway
Benefit
Consequence
High
Medium
Low
High
Medium
Low
Definition
The option inflicts a large cost to the program
The option inflicts a considerable cost to the program
The option inflicts a minor cost to the program
The option provides large benefits to the program
The option provides considerable benefits to the
program
The option provides minor benefits to the program
Significant
Negligible
Definition
A critical risk is unacceptable and mitigative actions must be implemented.
A Critical risk has both large probability of occurring and large
consequence.
A significant risk represents a considerable risk, but is still acceptable on
the grounds that it is constantly monitored to ensure that the risk level is not
increased to a Critical level.
A Significant risk has either large probability of occurring or large
consequence
A negligible is acceptable and can in most cases be discarded.
A Negligible risk has small probability of occurring and small consequence
Using the measures defined in Tables B.1 and B.2, the three options regarding a shared data
environment are evaluated with respect to their cost, their benefit, and the risks associated
with that option. This is done in sec 7 of this report.
J-12
PG Viking
Through Life Information Management Plan
Editors Ref. NSAN/99IMP_Rev 4
Revision No. 4
PG Viking
Mailing address
Projektkontor VIKING
S-205 55 Malm
Sweden
Tel:
Fax:
+46 40 34 80 00
+46 40 34 85 04
K-1
K-2
K-3
Purpose
Background
2.1
General Background
2.1.1 Overall project plan with milestones/schedule
2.1.2 How to address cultural changes/training
2.1.3 Program Office Staffing.
2.1.4 Program participants and location
2.2
Previously defined requirements
3
Information Requirements (content)
4
Information Architecture Requirements
4.1
Common Aspects for the Viking Life-cycle Information
4.1.1 Product Identification
4.1.2 Configuration and Structure
4.1.3 Linking
4.2
Life-cycle Activities
4.2.1 Define User Needs and specify Requirements
4.2.2 Design and Production
4.2.3 Support
4.2.4 Operation
5
Hardware requirements inclusive basis SW.
6
Software Applications Requirements
7
Roles and responsibilities
8
relevant data sources
8.1
External Information Environment
8.1.1 The military services
8.1.2 Defense industries in Sweden, Denmark and Norway
9
Implementation Plan
9.1
Infrastructure Implementation Plan
9.2
Contract Strategy for Information and Infrastructure
10
Review plan for the IMP
11
References
Appendix A: Participants in the Study
Appendix B: Information Analysis
Appendix C: Process for Information Management
Appendix D: Product Definition
Appendix E: Information Management Responsibilities
K-4
The Through Life Information Management Strategy /1/ was the first of three reports making
up the Information Management study in the Viking program, The Through Life Information
Management Plan is the second report. It is based on the Strategy /1/ and the Viking
Requirements Document /2/ (Preliminrt Kravdokument nr. 2
2. Background
2.1 General Background
2.1.1 Overall project plan with milestones/schedule
The overall plan for the Viking program is:
Study-Concept Phase:
1997-1999
Project Definition Phase:
2000-2002
Design and Production Phase:
2002-2014
Launch of first submarine:
2007
This schedule is based on the requirement of delivery of the first submarine to Denmark in
2007.
2.1.2 How to address cultural changes/training
The participants in the Viking program shall conduct training during the extended
Study-Concept Phase in accordance with project plan in order to acquire the necessary skills
to use the information systems. Special attention will be given in assuring that the Prime
Contractor has necessary qualification and ability to respond in accordance with the Through
Life Information Management Plan.
2.1.3 Program Office Staffing.
PG Viking will be supported by a plan coordinator for Systems Engineering, Integration,
Quality Assurance, Information Management, and Configuration Management. This person
will have the role of Information Manager.
2.1.4 Program participants and location
Prime Contractor (PC) is expected to be a joint venture, IG Viking, consisting of Kockums
Naval Systems (KNS), Kongsberg Defense & Aerospace (KDA) and Danyard, (DAA). The
joint venture must have financial back-up from their mother companies.
K-5
All information necessary to design, build, operate and support the Viking
submarines should be stored according to a common logical data structure
The information shall be such that configuration management can be performed
during the entire life-cycle.
The information shall be such that codification can be performed during the entire
life-cycle
The information structure and format shall be developed according to international
standards or open de-facto industrial standards.
Necessary commercial software should be available to support the chosen standards.
The information should be adaptable to different actors with different needs.
All information necessary to design, build, operate and support the Viking
submarines should be available on-line
Affected actors in the Viking program should be able to work with the same
information simultaneously.
Both classified and unclassified information shall be available on-line
Information quality and accuracy through life shall be secured:
The Viking information system shall not contain any duplication of approved original
information.
The information shall be extensive enough so that adequate traceability can be
performed between different data-elements, requirements, functions, and solutions.
The information should have a logical structure and format so that it does not require
reformulation with regard to exchange and sharing.
A shared data environment and related working processes should be introduced
amongst all participating parties, both on the industry side and on the government
K-6
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.
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
K-8
Linking
Configuration
and
Structure
Support
Product
ID
Design
Produce
Management
ManagementInformation
Information
K-9
K-10
Obj
Ops req
Acquisition
strategy
Master
Budget
plan
PMP
StoW
ILS-Plan
SSS
VIKING
SSS
IPC
(P01)
SSS
SSS
IWS
SSS
P02 - P09
Detailed specifications
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
AP 215 Arrangements
AP 216 Molded Forms
AP 217 Piping
AP 218 Structures
AP 226 Mechanical Systems
All of these Application Protocols have reached a stage where they are technically stable.
However, the Ship Product Model is not covering all areas necessary to hold all necessary
K-12
K-13
1.
2.
3.
4.
In addition to the specific information for each of the four areas, there is a set of information
that is common. This is called the core information.
4.2.3.1 Information scope for support activities
The information scope for the support activities is:
Maintenance: Maintain, test, calibrate, repair, and modify the Viking submarine,
including schedules, resources, and feedback.
Supply chain: Buy, store, pack, move, issue and dispose of physical items for the
Viking submarine and its support systems.
Configuration management/Change control: Manage change to a configured item
through-out the life cycle, including tracking of serial number where applicable.
Support engineering: Provide and sustain the support infrastructure.
The information scope is to provide the necessary information for the support activities. The
core information is described in chapter 4.1 Common Aspects for the Viking Life Cycle
Information
4.2.3.2 Maintenance Information
This section defines and structures the information needed to prevent or respond to
predictable failures of the physical product instance (single individual), in a specified usage
scenario. This information includes:
The identification and configuration of the product instance including its physical and
functional breakdown.
The required product performance, to the level needed for maintenance,
Failure modes and diagnostic characteristics,
Relevant usage and operating history,
Maintenance task descriptions and associated resources (parts, tools, skills and
facilities),
A sufficient description of the product to support the maintenance activity
(e.g., drawings, video clips etc),
Test and calibration procedures, following product maintenance,
Information on the return or safe disposal of items no longer required.
Note: Most of this data is generated by the Design and Support Engineering processes.
4.2.3.3 Supply Chain Information
Operational availability cannot be sustained without access to appropriate spare parts. This
K-14
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.
K-15
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.
None of the three alternatives described above are recommended for the Viking program.
However, they should be kept in mind if further work shows that it is more difficult than
expected to base the common logical data structure on STEP.
4.2.4 Operation
This implies information necessary to conduct Operational Logistics, including co-operative
logistics with other elements and weapon systems.
4.2.4.1 Operational Information Requirements
The Viking Information Management System should provide necessary information to the
Operational support activity during operational missions. Information elements according to
Logistical messages in the ADatP-3 (Allied Data Publication nr 3) will define the detailed
information requirements. This has to be taken into account when finalizing the support
phase information system.
No further detailed requirements will be determined at this point in time, due to significant
development in the Operational Command and Control area concerning information
requirements and handling.
5. Hardware requirements inclusive basis SW.
At present, no specific requirements have been identified.
K-16
Design/Construction
Support/Operation
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
K-18
K-19
K-20
PG Viking
NATO CALS
FMV
FKO
SFK
DNV
Sweden
Denmark
Norway
Information Owner:
Information users:
PMO
Naions (N)
Prime contractor (PC)
Steering Committee (SC)
Support organizations (SO)
K-21
TLBM Leaf
Processes
A111
Analyse Candidate
Solutions
K-22
A112
Derive And
Allocate
Requirements
Inf.
Manager
PMOIM
Inf. Users
PMOIM
PMO, PC
PMOIM
PMO, SC
PMOIM
PMO, SC
PMOIM
PMO, SC
PMO, SC,
PC
PMO, SC,
PC
PMO, SC
PMO, PC
PMO
PMOIM
PMO, PC
PMO
PMOIM
PMO, PC
PMO
PMOIM
PMO, SC,
PC
PMO, PC
PMO
PMOIM
PMO, SC,
PC
TLBM Leaf
Processes
A113
Evolve System
Architecture
K-23
A115
Integrate System
Necessary disciplines
Current Req
Inf.
Manager
PMOIM
Inf. Users
PMO, PC
PMO
PMOIM
PMO, SC,
PC
PMO, SC,
PC
PMO, PC
PMO, PC
PMO
PMOIM
PMO
PMO, PC
PMO
PMOIM
PMO, SC,
PC
PMO, PC
PMO
PMOIM
PMO, SC,
PC
PMO, PC
PMO
PMOIM
PMO, SC,
PC
PMO, PC
PMO
PMOIM
PMO, PC
PMO, PC
PMO
PMOIM
PMO, SC,
PC
PMOIM
TLBM Leaf
Processes
A121
Define Lc
Strategy
And Policies
A122
Define
Acquisition
Strategy
K-24
Approach to be taken in
acquiring a service or
VIKING component,
initially
Approach to be taken in
acquiring a service or
VIKING component, for resupply.
Method of acquisition
Acq Strat
Program approach to
identifying, assessing and
managing risk
Inf.
Manager
PMOIM
Inf. Users
PMO, PC
N R&R,
SC, PMO
N R&R, SC
PMOIM
PMO, PC
N R&R,
SC, PMO
N R&R, SC
PMOIM
PMO, PC
N R&R,
SC, PMO
N R&R,
SC, PMO
N R&R,
SC, PMO
N R&R,
SC, PMO
N R&R, SC
PMOIM
PMO, PC
N R&R, SC
PMOIM
PMO, PC
N R&R, SC
PMOIM
PMO, PC
N R&R,
PMO
PMOIM
PMO, PC,
SC
PMO
SC
PMOIM
PMO, PC,
SC
TLBM Leaf
Processes
A124
Develop Ils
Strategy
Inf.
Manager
PMOIM
Inf. Users
N, PMO, PC,
SC
K-25
A125
Develop Cm
Strategy
And Plan
CM Strategy
PMO, N
R&R, PC
PMO
PMOIM
N, PMO, PC,
SC
A126
Develop Qa
Strategy
And Plans
QA Strategy
PMO, N
R&R, PC
PC, PMO
PMO
PMOIM
PC, PMO
PMOIM,
PCIM
N, PMO, PC,
SC
PC, N, PMO
TLBM Leaf
Processes
A127
Develop TLIM
Strategy and Plan
K-26
A131
Manage
Program
Schedule
A132
Establish
Roles And
Relationships
Program WBS
Inf.
Manager
PMOIM
Inf. Users
PMOIM
PC, PMO,
SC
PMO, SC
PC, PMO,
SC
PMO, PC
PMO
PMOIM
PMO, SC
PMO, SC
PMOIM
PMO, PC,
PMO, PC
PMOIM,
PCIM
PC, PMO,
N
SC
PMO
PMOIM
SC
PMOIM
PMO, SC,
N
PMO, N
PMOIM,
PCIM
PMO, N, PC
PMO, SC,
N
PMO, SC,
N
PMO, N
PMOIM
PMO, PC, N
PMO, N
PMOIM
PMO, PC, N
PMO, SC,
PC
PMO, PC,
SC, N
PMO, PC, N,
SC
PMO, PC, N
TLBM Leaf
Processes
A1331
Develop Contract
Strategy
K-27
A1332
Issue Solicitation
Invitation to Tender
PMO, SC
PMO
Inf.
Manager
PMOIM
Inf. Users
PMOIM
PMO, PC
PMOIM
PMO, N
PMOIM
PMO, N
PMOIM,
PCIM
PMO, PC
PMO, PC
TLBM Leaf
Processes
A1333
Assess Proposals
A1334
Run Contract
K-28
A134
Manage
Viking Lc
Funding
A135
Manage Human
Resources
Budget Req
Available Funding and
Predicted LCC
Allocated Manpower
Inf.
Manager
PCIM,
PMOIM
PMOIM
Inf. Users
PMO, SC
PMO, SC,
PC
PMO, PC
PMO
PMOIM
PMO, PC,
SC
PMO, SC
PMO
PMOIM
PMO
PMO, PC,
SC, N
PMO
PMO
PMOIM
PMOIM
PMO, SC,
PC
PC
PMO, PC,
SC, N
PMO, SC
PMO
PMOIM
PMO, N, SC
PMO, PC
PMO, N
PMOIM
PMO, SC, N
PMO, N
PMO
PMOIM
PMO, N, SC,
PC
TLBM Leaf
Processes
A1361
Develop
Im Plan
K-29
A1362
Establish and
Operate
Program Sde
A1363
Provide
Information
Services
Contract Information
Req and
Program SDE
Describe Information
Services
Information Services
Inf.
Manager
PMOIM
PMOIM
PMOIM
PMO, N,
PC
PMO, N,
PC
PMO, N,
PC
PMO, N,
PC
PMO
PMOIM
PMO
PMOIM
PMO
PMOIM
PMO
PMOIM
PMO, PC
PMO, PC
PMOIM,
PCIM
Inf. Users
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N,
SC
PMO, PC, N
TLBM Leaf
Processes
A14
Compare Actual
System State and
Performance With
Required
K-30
A211
Develop
Conceptual
Options
Inf.
Manager
PMOIM,
PCIM
Inf. Users
PMOIM,
PCIM
PMOIM,
PCIM
PMOIM,
PCIM
PMO, PC, N
PMOIM,
PCIM
PMO, PC, N
PMOIM,
PCIM
PMO, PC, N
PMO, N, PC
PMO, PC, N
PMO, PC, N
PMO, N
PMO
PMOIM
PMO, SC
PMO, N,
PC
PMO, SC
PMO
PMOIM
PMO
PMOIM
PMO, SC,
PC, N
PMO, PC, N,
SC
TLBM Leaf
Processes
A212
Define
Viking
System
K-31
A213
Engineering
Design
Inf.
Manager
PMOIM,
PCIM
PMOIM,
PCIM
Inf. Users
PMOIM,
PCIM
PMO, PC,
SC, N
PMOIM,
PCIM
PCIM
PMO, PC,
SC, N
PMO, PC,
SC, N
PMO, PC,
SC, N
PMO, PC,
SC, N
PC
PC
PCIM
PMO, PC, N
PC
PC
PCIM
PMO, PC, N
PC
PC
PCIM
PMO, PC, N
TLBM Leaf
Processes
A214
Failure
Analysis
K-32
Inf.
Manager
PCIM,
PMOIM
PCIM,
PMOIM
Inf. Users
PCIM,
PMOIM
PC, PMO, N
PCIM,
PMOIM
PCIM,
PMOIM
PC, PMO, N
PC, PMO, N
PC, PMO, N
PC, PMO, N
TLBM Leaf
Processes
A215
Design The
Support
System
K-33
Inf.
Manager
PMOIM
Inf. Users
PMOIM
PMO, PC, N
PMOIM
PMO, PC, N
PMOIM
PMO, PC, N
PMOIM
PMO, PC, N
PMOIM
PMO, PC, N
PMOIM
PMO, PC, N
PMO, PC, N
TLBM Leaf
Processes
Predicted Perf
A22
Produce
Viking
System
A23
Conduct Testing
K-34
A216
Predict Life Cycle
Performance
Inf.
Manager
PMOIM
Inf. Users
PMOIM
PMO, PC, N
PMO, PC, N
PMO, PC
PMO
PMOIM
PMO, PC, N
PMO, PC
PMO
PMOIM
PMO, PC, N
PC
PC
PCIM
PMO, PC, N
PC
PC
PCIM
PMO, PC, N
Test Findings
PMO, N
PMO
PMOIM
PMO, PC, N
PMO, N
PMO
PMOIM
PMO, PC, N
TLBM Leaf
Processes
A24 Deploy Viking
System
K-35
A 31
Plan Support
A32
Store
Transport and
Issue Items
Inf.
Manager
PMOIM
Inf. Users
PMO, N, PC
PMO, N
PMO, N
PMOIM.
NIM
PMO, N, PC
PMO, N
PMO, N
PMOIM.
NIM
PMO, N, PC
N, PMO
PMOIM
PMO, N, PC
TLBM Leaf
Processes
A33
Maintain,
Update and
Provide
Feedback
K-36
Inf.
Manager
NIM
Inf. Users
NIM
NIM
NIM
A34
O&S Tasks
NIM
A35
Manage
Facilities
Returned Items
NIM
A36
Train
Support
Staff
Trained People
N, PMO
NIM
TLBM Leaf
Processes
A37
Conduct
Evaluations
A4
Dispose Or
Recycle
K-37
Inf.
Manager
NIM
Inf. Users
PMO, N
NIM
NIM
NIM
Inputs to the I2 process is plans, strategies and descriptions of existing and planed:
Output is strategies, specifications, work breakdown structures and plans to produce the
Information Solution.
I2-analyse
98-12-21
TLBM, PLCS
Realisation
PLCS, TLBM
Business process
analyse
Business
processes
MIL-STD
490A
961D
Design
process
Informationanalyse
Information
Tailoring
K-38
Techniques
Informaticsanalys
Information
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:
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
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:
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
K-41
Relationships should be
product_
requirement
product_
requirement_
product_
concept_
association
product_
concept
product_
instance_
product_
concept_
association
product_
instance
product_
concept_
product_
design_
association
product_
requirement_
product_
design_
association
product_
design
K-42
product_concept
product _instance
product _design
In fact, there is a
In this way, the effectivity of configuration, technical data, and logistic tasks to
product_instance is explicitly defined through relationships.
Product Concept
A product_concept is the idea of a product as conceived by the user. It will often
correspond to the items supplied to the user (e.g., an item in the catalog of a supplier). The
definition of product_concept(s) is driven by users needs and by user defined usage
scenario. It represents the idea of a product based on user viewpoint and NOT as it might be
designed or manufactured.
The basic relationships of product_concept are described in Figure 3.
K-43
usage_
scenario
classification _of_
usage_scenario
class_of_
product_
concept
product _concept_
usage_scenario_
association
class_of_
usage_
scenario
classification _of_
product_concept
product _concept
product_
concept_
succession
(ABS)
product_concept_
relationship
product_
concept_
composition
class_of_product_
concept_relationship
classified_
product_concept_
relationship
Product Requirement
A product_concept in a specific usage_scenario may be characterized by a set o required or
expected product features, performance or behaviors identified by the user or derived by the
users needs.
K-44
product_
concept
product_concept_
usage_scenario_
association
usage_
scenario
applies_to
is_realized_by
product_
requirement
product_
physical_
design
A typical
K-45
Product Design
The product_design object has a number of relationships with the other views of the
product (see Paragraph 6.1 and Figure 5).
1,3 product_concept
1,1 product_requirement
1,2 product_instance
product_concept_product_
design_association
product_
requirement_
product_design_
association
product_
functional_
design
functional_
design_
physical_
design_
relationship
(ABS)
product_design
product_
physical_
design
product_instance_
product_design_
association
physical_
design_
support_
design_
relationship
product_
support_
design
functional_design_
support_design_
relationship
K-46
product_
requirement
product_requirement_
product_concept_
association
applies_to
is_realized_by
product_
physical_
design
product_concept_
usage_scenario_
association
usage_
scenario
product_
functional_
design
K-47
K-48
class_of_
product_
functional_
design
classification_
of_product_
functional_
design
product_requirement_
product_concept_
association
(ABS)
product_functional_
design_relationship
identification_of_
functional_design
organization
control_of_
functional_design
product_
physical_
design
functional_design_
physical _design_
association
product_
support_
design
functional_design_
support_design_
association
1,3 property_
representation
product_
functional_
design
functional_
breakdown
causal_
relationship
causal_
chain
classified_
relationship
class_of_
relationship
functional_
design_
control_port_
association
functional_design_
property_
association
control_
port
functional_design_
property
K-49
K-50
many
many
product_
concept
product_
functional_
design
functional _design_
usage _scenario_
association
product_concept_
usage_scenario_
association
in_the_context_of
product_
physical_
design
failure _of
usage_
scenario
failure
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).
K-51
failure 1
consequential_
failure_
relationship
failure 2
causes
xor_consequential_
failure_relationship
Failure 4
consequential_
failure_
relationship
failure 3
K-52
product_
functional_
design
functional _design_
usage_scenario_
association
product _concept_
usage_scenario_
association
usage_
scenario
in_the_context_of
product_
physical_
design
task_
failure_
association
failure_of
failure
product_
physical_
design
in_scenario
applies_to
task
Task(s) may be classified. Servicing Tasks, Scheduled Tasks, Occasional Tasks are
examples of task classes;
A task may relate to another task for a particular reason;
The possible rationale for two task(s) to be related should be defined. Alternate
task(s) is an example of this rationale;
Maintenance level, criticality, and other qualifications may be assigned to a task;
Some task characteristics such as time to perform and cost may be derived by the rollup of sub-task attributes;
When and whether to perform a task depends on conditions. A simple condition may
define, for example, that a task is to be performed every three months (e.g., do task
A IF date(current)-date(task_A_last_done)>90);
Simple conditions may be combined with AND, OR and XOR logical operators to
define more complex conditions (e.g., do task A IF date(current)date(task_A_last_done)>90 .OR. mileage(current) mileage(task_A_last_done) >
3000 );
Condition monitoring may require that certain parameters of product_instance and
support_scenario be measured and recorded. Where data is collected automatically,
the source sensor should be identified.
A task is usually decomposed in elementary task stages or steps that may be seen as
modular building blocks. Tasks may be defined by assembling the elementary (base)
K-53
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;
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
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:
K-55
K-56
The diagram in Figure 11 is a high level model that covers most of the above requirements.
K-57
product_instance_
characteristics_
assignment
class_of_product_
instance_
characteristics
classification_of_
class_of_
characteristics
1,3
characteristics_
representation
class_of_product_
instance
product_design
location
product_
operating_
scenario
classification_of_
product_instance
product_instance
product_
instance_
identification
organization
product_
instance_
ownership
product_concept
product_
instance_
control
product_instance_
relationship
product_
instance_
assembly
product_
instance_
succession
product_
instance_
collection
product_
instance_
alternative
K-58
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
K-60
GC-991
GC-082
GC-076
GC-354
AS-REQUIRED
AS-MANUFACTURED
AS-DESIGNED
Truck Req.
RN-01
Tech Data
Truck
PN -011
Truck
SN-4030
Support Data
AS-USED
Truck
UI-3210
RN-11
RN-12
Engine
PN-02950
Engine Req.
RN-110
Chassis
PN-02398
Engine
SN-33030
Tech Data
Tech Data
Support Data
Support Data
Tech Data
Truck
PN -012
Support Data
Engine Req.
RN-115
RN-1151
Engine
PN-02960
Chassis
PN-02398
Tech Data
Tech Data
Support Data
Support Data
Chassis
SN-00631
Engine
SN-00323
Chassis
SN-00340
Engine
SN-54890
Chassis
SN-00631
Truck
UI-3212
Truck
SN-3908
RN-1152
RN-1153
Engine
SN-54890
Engine
SN-33030
Truck
UI-3211
Truck
SN-3907
RN-1101
RN-1102
Chassis
SN-00340
Chassis
SN-9001
Engine
NSN-2219
Chassis
SN-001
The Engine mounted on Truck with Plate Number UI-3212 has a NATO Stock Number as
user defined ID. In this case its completed identifier would be:
GC-991.RN115.GC-082.PN-02960.GC-354.SN-00323.GC-076.NSN-2219
K-61
The configuration change activity results in the creation of new data instances, such as new
part/assembly identifications and new relationships. Diagram in Figure 12 illustrates, for
each of the above triggers for change, the product objects that are affected.
ENHANCEMENT
FUNCTIONAL DESIGN DISCREPANCY
PHYSICAL DESIGN DISCREPANCY
SUPPORT DESIGN DISCREPANCY
MISSION NEED
REPAIR ACTIVITY
functional
physical
product_requirement
support
product_instance
product_design
For example:
K-62
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
Most of the above requirements are addressed in the high level model in Figure 13.
product_
concept
product_
requirement
product_
design
product_
instance
target_select
request_
directive_
relationship
(ABS)
request
implementation_
directive
directive_
resolution_
relationship
identifier
initial_
issue
(ABS)
change_
request
approval
organization
enhancement
(ABS)
configurantion_
change _item
label
date _and_
time
discrepancy
text _select
K-64
actual_
resolution
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
K-66
K-67
K-68
Abstract
How many of us today are members of some type of Integrated Product Team (IPT)? How many
of us are members of more than one? How many of us feel we are over loaded with the
administrative burden that keeping all member informed places on us? How many of us wish
our IPT could operate more effectively? Peter Drucker said that effectiveness is the foundation
for success. He also said effectiveness is doing the right things. Leadership has also been
defined as doing the right things. In this paper, I will present my ideas on how integrated data
environments can be coupled with teamwork and used to do the right things to enable the teams
we participate in to become more effective.
1. Characteristics of an IDE
As with every new concept in government, it seems different people define the same term
different ways. IDE is no exception. Therefore, to clarify what the IDE looks like, Ive included
the following list of characteristics and examples to enable us to gain a common understanding.
Shared information: create once, maintain at the source, use throughout the life-cycle
All stakeholders have access to data at the right time and place
Greater IPT efficiency is enabled through work flow, on demand data is accessed through
a common operating environment
Automated configuration management process is integrated with acquisition and
sustainment community data requirements
Data management system ensures timely, accurate control
Single work station access to distributed data
Delivery-in-Place method for CDRL data
Policies exist and are followed concerning how to treat data as corporate assets, integrate
it and maintain it
In this kind of environment information is created electronically, and is no longer printed out for
signature. No longer sending hard copy only to be received and re-entered once again into the
recipients computer system. For those of you who use email systems extensively, you would no
longer send attachments to lists of people, constrained by bandwidth and sometimes bringing
down the server that receives multiple copies of the same huge file. Distribution of data is
eliminated, providing access to the data as soon as it is available to all parties at once with an
access time of seconds instead of days or weeks, without incurring any transportation costs or
printing costs. Instead of endless email tennis matches, where we bounce messages back and
forth until someone decides to take action, a work flow tool is provided to more effectively send
the task to action officers, based on the process and task descriptions assigned. All data and
tools needed for research and resolution of the problem are immediately available to the user on
the users desktop. IDE eliminates the need for special terminals used to get into each database,
L-1
sometimes located in special rooms in far away buildings. For product data, configuration
management is central to and integrated with operations of both acquisition and sustainment
communities. The data management system ensures integrity of data and control, to ensure the
right information gets to the right person at the right time. IDE enables delivery-in-place as
described in the DoD 5000 series directives, for delivering contract data to the government. This
environment can reduce CDRLs almost entirely. In the IDE project implemented by the Project
Manager for Combat Mobility Systems (PM CMS), the number of CDRLs went from over 230
to 18 across four major contracts. Thats a 92% improvement! The data was provided through
working relationships in the IPTs and shared via the Delivery In Place (DIP) server, so CDRLs
were no longer needed. However, an IDE will not help a poorly run organization if it continues
to be poorly run. Policies must be established and enforced to ensure teams are doing the right
things to use the IDE effectively. Processes should not be merely automated, they should be
innovated to take advantage of the power of the new environment and tools is offers.
2. Current Status of Defense System Data
Much of the data in defense systems today is not available in a timely manner. It is either
walking around in someones head, forgotten about in a file somewhere, or locked on someones
hard drive. Corporate knowledge is often tied to individuals. Is is not is frustrating to be the one
on Friday afternoon who has to respond to a budget what if drill when everyone else is off who
would have had that last information paper that was submitted on their computer? Now you
have to come up with something up in a hurry and hope it does not contradict what your team
submitted last time. It would be great to have a library of information that can easily be searched
to find all the budget related documents that were ever written on your program? IDE can
provide such off the shelf tools to enable teams to share information more effectively, so that you
can find it when you need it. Today data structures inhibit sharing of information and valuable
data.
Even when PM CMS standardized on one office software package for routine
correspondence, different versions made it difficult. The life span of data is too short today.
Many of our processes repeat themselves over and over. People want the same information over
and over, maybe with a slightly different twist. The mountains of data created early in product
life-cycles is somehow lost when the next crew cannot find the digital copy and it must be recreated. In the past, we have created boundaries and built walls that inhibit information sharing.
Today through the use of IPTs we have seen some progress in removing the organizational
barriers that exist, however, we must ensure the information system architecture also
accommodates an open flow of information across those boundaries. In addition, you would be
amazed at how different each persons perspective is pertaining to how a process is
accomplished. Often very few, if any understand the whole process. Those that thought they
did, find that what is actually happening is not even close to what they thought was happening.
3. Information sharing enables teams to work better
In an IPT environment the IPT has proponency for the CDRL data that is delivered. In an IDE
the distribution, administration and feedback on that data is greatly simplified. The data is
placed on the server, the workflow is launched to team members asking them to comment on it,
and the data is available through a folder that appears on each team members desktop.
Delivery-in-place eliminates hours of duplication and distribution that is done in a paper world.
If you operate in an email world, it eliminates the need for multiple messages, overcomes the
difficulty with sending large files over the Internet and through email systems, and prevents the
L-2
potential for email system failure or significant degradation in performance when sending large
attachments to several people on the same server all at once. The folder that now appears on the
desktop may contain a read-only master copy and a copy for editing, for example. Using off the
shelf standard commercial software tools comments from each member are added to the copy for
editing. All comments appear in a single document and all team members can see everyone
elses comments. Once everyone agrees on the final edit, the document becomes the approved
version and supersedes the previous. Oh, if you are wondering how you clean up the mess of
mark ups from everyone who has left comments, one click of the mouse reformats the document
and removes all the text marked for deletion. These tools offer many options and can be
employed many different ways. The key here is to use integrated off-the-shelf capability to
enhance team performance, not to degrade it. Some other ways the IDE can improve
collaborative productivity are listed below.
Share more information to ensure the best-informed decisions can be made by the team or
enables them to use a consistent decision baseline. This is key to empowering the team
to take action.
Provide greater understanding and visibility into the process, eliminate black holes and
wait states.
Maintain life-cycle consistency, decision traceability, corporate memory, and
buy/maintain only the information that is needed.
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.
Improved quality of systems and system support through sharing of current and accurate
data
Improved weapon system life-cycle management processes
Through reading the Coopers and Lybrand study on IDE implementations, 1996 and the book
Process Innovation by Davenport. I have observed the following statistics. Typically when a
company implements an improved team work approach alone the results range from 10 to 50
percent improvement. However, when you combine team empowerment with the power of the
IDE as the force multiplier and innovate the processes instead of improving them, the result is
anywhere from 50 to 90 percent improvement in most cases. The variation in the ranges seems
to come down to how effective the leadership was in implementing the overall strategy.
6. Summary
DoD and industry now have experience and guidance available to assist leaders wanting to
implement IDE. DoD information can be found at http:\\www.acq.osd.mil/cals, which has links
to other sites with additional information. Of particular interest may be an IDE Handbook that is
available on the Web and on the Acquisition Deskbook CD ROM. Two other good sources of
information are Process Innovation by Davenport, which describes the risks involved in
innovating, many success stories as well as failures and outlines what to expect. And most
significantly for me is the book by John Kotter and Harvard Business Press titled Leading
Change. Leading Change is an excellent culmination learned into a of best practice guide.
The process for leading lasting change outlined in his book held true for me when I, together
with Jack Paul, implemented the first IDE for the Army, which we affectionately called the
Paperless PM. The book also serves as an outstanding desk reference.
In closing, Ill leave you with a quote from Albert Einstein The significant problems we face
cannot be solved from the same level we were at when we created them. Operating in an IDE
involves thinking differently about how teams can do business to create less burden and greater
results.
IDE + Team work = High Performance
Ms. Nancy A. Moulton has over twenty years of logistics, acquisition, and project management
experience with the Army. She is currently Chief of the Training, MANPRINT, Fielding and
Support Branch of PM STCCS. She has recently served as IDE Project Manager for OSD and
prior to that led the IDE effort for PM CMS. Ms. Moulton will earn her Masters Degree in
Systems Management with a focus on Information Technology in Oct 97 and has been board
selected as the Project Manager for Light Tactical Vehicles. She will be transitioning to PM
LTV in the spring of 1998.
L-4