NISTIR 7339

Analysis of Standards for Lifecycle Management of 

Systems for US Army --- a preliminary investigation

Sudarsan Rachuri 

Sebti Foufou 

Sharon Kemmerer 

 
U.S. DEPARTMENT OF COMMERCE 

Carlos M. Gutierrez, Secretary 

TECHNOLOGY ADMINISTRATION 

Michelle O'Neill, Acting Under Secretary of Commerce for Technology 

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 

William Jeffrey, Director

NISTIR 7339

Analysis of Standards for Lifecycle Management of 

Systems for US Army --- a preliminary investigation

Sudarsan Rachuri 

Sebti Foufou 

Sharon Kemmerer 

 August 2006 

 
i

Analysis of Standards for Lifecycle 

Management of Systems for US Army 

--- a preliminary investigation 

Executive summary 

The need to exchange data among multiple business partners, developers, suppliers, users, and 

maintainers is the normal day-to-day complex business environment for the U.S. Army and 

other Department of Defense (DoD) Services. Product lifecycle management (PLM) is a 

function or a business strategy for creating, sharing, validating, and managing information 

about product, process, people, and services within and across the extended and networked 

enterprise covering the entire product lifecycle spectrum. 

A number of institutions including the National Institute of Standards and Technology (NIST), 

Department of Defense (DoD), the European Ministries of Defense and, more recently, by the 

vendor and end-user communities have recognized the importance of interoperability across the 

phases and functions in PLM. A 1999 study commissioned by NIST estimated that imperfect 

interoperability of engineering data costs at least $1 billion per year to the members of the U.S. 

automotive supply chain. By far, the greatest component of these costs is the resources devoted 

to repairing or reentering data files that are not usable for downstream applications. This is 

parallel to the Army’s lifecycle logistics support costs for any given weapon system and its 

components. As reported in a Government Accounting Office report for DoD, operating and 

support costs make up about 60-70 percent of a weapon system’s total lifecycle costs. Many of 

the current ground weapon systems will continue to be in service for another 20-30 years. The 

Army needs the ability to support systems after production while reducing sustainability costs. 

The PLM challenge faced by the Army is to implement standards and protocols that allow 

legacy systems as well as future technological innovations to interoperate seamlessly. 

To meet its responsibilities, the Army has committed to a Single Army Logistics Enterprise 

(SALE) framework. SALE is designed to correct a long-standing problem in the Army’s 

logistics information management, notably: lack of a common operating process for measuring 

and analyzing materiel readiness and combat posture. Using SALE, the Army intends to 

integrate its national and tactical logistics systems into one fully integrated, end-to-end 

enterprise. SALE will bring together three component systems: the Global Combat Support 

System-Army (GCSS-Army) Field Tactical (F/T), the Logistics Modernization Program 

(LMP), and GCSS-Army PLM+. PLM+ is the technical enabler proposed to link the field-level 

logistics system, GCSS-A with the National-level logistics system, LMP, and to establish a 

single access point interface to integrate all the Army’s external systems. 

Such a commitment to the concepts of SALE is no longer an option for the Army, but a 

logistics imperative. The US Army Materiel Command (AMC) is responsible for this logistics 

support. To achieve their goal AMC Headquarters has formed the Army Product Data and 

Engineering Working Group (PEWG). 

The PEWG is chartered to provide solutions and a plan of action for the Army solutions to 
ii

address the complexities of the engineering and logistics supply chains within the Army, and to 

integrate these with Original Equipment Manufacturers (OEMs) and their associated enterprises 

that create and maintain the data in today’s global business environment. 

This report is in response to two milestones for PEWG’s Work Package 2: 

• Identify standards that could be used for lifecycle product data standardization, 

interoperability, and exchange among Army’s and its OEMs’ enterprise systems (e.g., 

SALE, Future Business System). 

• Help build a business case for using standards. 

Today’s standards, particularly in the area of computer-aided design (CAD), have produced 

direct improvement in productivity, especially in the manufacturing arena, by reducing 

transaction costs and increasing the richness of interactions between suppliers and customers. 

The initial use of ISO 10303, informally known as the STandard for the Exchange of Product 

model data (STEP), has brought proven cost savings in the automotive industry. In research 

conducted in another NIST-commissioned economic impact study on the cost of doing business 

if STEP were not implemented, it was found that the biggest impact was felt lower in the 

supply chain than by the OEMs. First tier suppliers estimated a $250 million savings per year 

from adopting STEP standards; and sub-tier suppliers estimated almost $200 million in savings. 

Achieving efficient PLM requires being able to understand the ecosystems supporting the 

lifecycle logistics. We propose a standards typology (i.e., a classification system) for the 

Army to use to identify the suite of standards best suited to meet its product lifecycle needs. 

Given the proven savings from implementing STEP, NIST believes STEP standards could 

provide a strong foundation supporting PLM, and be developed within the typological 

framework described in Section 5. 

This report (primarily in Section 4) provides a preliminary investigation of a selected set of 

standards and frameworks. These were mentioned during our site visits and interviews at 

various US Army Research Centers (See Appendix A) and also cited in DoDD 5000.1 or 

identified for defense use by memoranda. The standards included in the scope of this report 

are: 

• ISO 10303, Product data representation and exchange, is a suite of standards used to 

exchange product model data. 

• ANSI/GEIA-927, Common data schema for complex systems, is an integrated multidomain data schema for representing product and process data. 

• EIA-836, Configuration management and data exchange and interoperability, provides a 

means to create a central source of configuration management information for exchange 

among necessary partners. 

• ANSI/EIA-649, National consensus standard for configuration management, describes 

configuration management functions and principles and defines a neutral terminology. 

• MIMOSA OpenO&M is intended to provide a harmonized set of information 

technology standards for the exchange of operations and maintenance information. 

• ASD/AIA-S1000D, International specification for technical publications utilizing a 

common source database, pulls together the use of other international standards to 

support the production and use of electronic documentation. 
iii

• DoD architecture framework (DODAF) defines a common approach for DoD 

architecture description development, presentation, and integration. 

In general, the use of internationally developed, industry-driven, and industry-maintained 

standards allows the maximum freedom of choice for the AMC; and will drastically reduce 

expense across the product lifecycle. Information technology standards are a key enabler to 

manufacturers and participants in the lifecycle management of the product’s data for bridging 

the gap between the multitude of enterprise systems and the asset management systems. This 

aspect is critical to the U.S. Army as most of its asset management systems and associated 

product data still lie within the ownership, or at least physically located with, the OEM 

delivering the product and associated support. A movement toward the adoption and 

implementation of data representation and exchange standards to support fully the product’s 

lifecycle processes has proven a good business practice. 

 

Based on our analysis of the list of standards selected for review, we made the following 

observations: 

• Some of the standards are extensions of the others, e.g., EIA-836 complements the wellestablished ANSI/EIA-649 standard for configuration management and incorporates its 

principles. 

• Some of the standards are built as an integration of others, e.g., GEIA-927 is an 

integration of ISO 15926, PAS20542, ISO 10303-AP212, and AP239; and more 

standards are currently being integrated into GEIA-927. 

• A number of the same functionalities are supported by more than one standard, e.g., 

configuration management is included in ANSI/EIA-649, EIA-836, 10303-AP203, ISO 

10303-214, and 10303-AP239. To compound this overlap, several standards are being 

developed within the United States, while similar development efforts are, or have 

occurred, in the international arena, e.g., GEIA-0007 and ISO 10303-239, EIA-836 and 

ISO 10303-203, and ANSI/EIA-649 with ISO 10007. (The latter is not covered in the 

scope of this report.) 

• EIA-836 appears to be a thorough and good start for managing configuration data 

within the Army, but it appears the funding of the work and the interest in the work is 

only by the government. Without much industry buy-in, such a project and direction in 

employing standardization will be an expensive approach for longer-term maintenance 

and enhancement by the Army. 

• ISO 10303 appears to have the most breadth and depth of coverage for product lifecycle 

data. ISO 10303-239 (Product Lifecycle Support, PLCS) is currently the only 

international standard available that covers the entire lifecycle spectrum. NIST believes 

that PLCS has great potential to handle the Army’s PLM requirements, but recommends 

the Army resolve certain challenges before firmly committing to its adoption. More 

technical details on AP239 and recommendations for its use can be found in Section 4 

and Section 7 respectively. 

We offer the following recommendations for the Army: 

• Review its investments and pilot results for various STEP AP projects, and investigate 

further integration of these application protocol commitments with AP239 for full 

product lifecycle support. The Army has been investing in the development and piloting 
iv

of several other ISO 10303 application protocols, including AP203 edition 2; and a 

“manufacturing” suite comprised of at least AP203, AP219, AP223, AP224, AP238, 

and AP240. 

• Investigate and understand more fully the ramifications and long-term effects regarding 

issues associated with maintenance and ownership of existing OASIS Data EXchange 

Sets (DEXs) and Reference Data. If OASIS standardization in PLCS is determined the 

best viable solution, the Army should: 

− Assess the coverage by existing OASIS DEXs and reference data to meet the 

Army’s needs. 

− Participate in the development of necessary DEXs and reference data sets within an 

international standards development forum. 

• Promote the transfer of national standards into the international standards development 

arena. The Army has invested significant resources into developing national standards 

such as EIA-836, GEIA-927, and GEIA-0007. Adoption and use of these standards 

may improve if this work is incorporated into the international standards development 

efforts. For example, the business rules available in EIA-836 could possibly be turned 

into a configuration management DEX within OASIS. Similarly, the business rules 

being developed in GEIA-0007 could be turned into a logistics support analysis DEX. 

• Ensure standards-based product lifecycle support by vendors and users by developing a 

template of contractual language that consistently and expressly calls out the 

recommended standards of choice and commits the Army to a standardized solution as 

the only way to do business. 

• Act upon Under Secretary of Defense Krieg’s recommendation in his memorandum of 

June 23, 2005, “Standard for the Exchange of Product Model Data (STEP) --- ISO 

10303” to review and implement STEP as the Army’s interoperability standard. 

The time allowed for this report did not permit a uniform in-depth study of the standards 

investigated in this report; nor on the full suite of prospective PLM-related standards --- their 

use, their maturity, and supporting software tools; or the gaps and the overlap of the standards 

through a formal approach using a typology and information models. NIST proposes in 

Section 8, as a follow-up to this report, several additional short and long-term joint efforts with 

the Army, which include providing a more in-depth assessment of a larger suite of candidate 

PLM standards, identifying the gaps, and producing a formal process that will assist the Army 

in its selection of necessary standards. As part of this extended assessment, NIST would 

include review of the linkage or overlaps between PLCS and S1000D, and PLCS with 

MIMOSA. 

Additionally, NIST could work with the Army to: 

• Develop strategies for the creation of common and discrete ontologies that best 

facilitate the interoperability and fluidity of information flow between the Army, its 

OEMs, and other allied countries. 

• Develop a reference model for the Army’s product lifecycle information ecosystem. 

• Develop a methodology to create test beds for evaluating information standards and 

their implementations. 

• Investigate application and potential benefit for the Army from NIST’s Long Term 

Knowledge Retention project that deals with digital technical product documentation. 
v

Table of contents

Executive summary.......................................................................................................................i

List of abbreviations.................................................................................................................. viii

1. Background.......................................................................................................................... 1

1.1 Need and mandate for lifecycle support ................................................................... 1

1.2 The AMC drive for lifecycle support efficiencies .................................................... 2

1.3 Report content............................................................................................................. 4

2. Product Data Related Activities and Issues in the US Army: a Current Perspective ....... 4

2.1 Product data delivery from contractors ................................................................... 6

2.2 Collaborative product development.......................................................................... 7

2.3 Depot manufacture and overhaul.............................................................................. 7

2.4 Condition-Based maintenance and failure feedback............................................... 7

2.5 Performance-Based logistics support........................................................................ 8

2.6 Item unique identification.......................................................................................... 8

2.7 Configuration management ....................................................................................... 8

3. Why standards?.................................................................................................................... 8

3.1 Categories of standards.............................................................................................. 9

3.1.1 As Defined by Congressional Authority .................................................................................. 9

3.1.2 As Supplemented by the Executive Branch ........................................................................... 10

3.2 Standardization methods ......................................................................................... 11

3.3 Voluntary consensus standards............................................................................... 11

3.4 Importance of industry-driven standards ............................................................. 12

4. Preliminary analysis of standards for lifecycle management .......................................... 14

4.1 Product lifecycle management................................................................................. 14

4.2 Standards relevant to the Army’s product data management ............................. 16

4.2.1 ISO 10303 STandard for Exchange of Product model data (STEP) ...................................... 17

4.2.2 GEIA-927 Common data schema for complex systems......................................................... 35

4.2.3 ANSI/EIA-649 National consensus standard for configuration management........................ 37

4.2.4 ANSI/EIA-836 Configuration management data exchange and interoperability................... 38

4.2.5 MIMOSA Open Operations & Maintenance (O&M) framework .......................................... 40

4.2.6 ASD/AIA-S1000D International specification for technical publications utilising a Common 

Source DataBase.............................................................................................................................. 42

5. An initial typology of information standards................................................................... 43

Type Zero: Standards for implementation languages....................................................... 43

Type One: Information modeling standards...................................................................... 43

Type Two: Content standards - domains of discourse...................................................... 44

Product information modeling and exchange standards.................................................................. 44

Product visualization standards ....................................................................................................... 45
vi

Type Three: Architectural framework standards ............................................................. 45

5.1 Convergence of PLM support standards................................................................ 47

6. Implementation issues and strategies................................................................................ 48

6.1 Challenges in standards development for PLM..................................................... 49

7. Observations and recommendations ................................................................................. 50

8. Proposed next steps............................................................................................................ 55

9. Acknowledgements............................................................................................................. 58

10. Disclaimer ...................................................................................................................... 59

11. References ...................................................................................................................... 59

Appendix A: Product lifecycle and the supply chain management: An investigative study... 67

Appendix B: Army-Related Projects Employing PLM Standards ........................................... 85

A sampling of projects specific to the Army ...................................................................... 85

HMMWV data exchange with AM General.................................................................................... 85

Bradley data exchange with BAE.................................................................................................... 86

Abrams UID Pilot with GDLS ........................................................................................................ 87

U.S. Army National Automotive Center (NAC), N-STEP.............................................................. 87

LEAN munitions ............................................................................................................................. 87

TACOM/Army Ground systems integrated lean enterprise (AGILE) ............................................ 88

Electronic Logistics Information Trading Exchange (ELITE)........................................................ 88

Some tri-Service initiatives .................................................................................................. 88

CALS............................................................................................................................................... 89

JEDMICS ........................................................................................................................................ 89

Rapid acquisition of manufactured parts (RAMP) .......................................................................... 89

Appendix C: Product lifecycle-related integration standards.................................................. 91

Type One: Information Modeling Standards..................................................................... 91

Type Two: Content standards - domains of discourse...................................................... 97

Type Three: Architecture Frameworks Standards ......................................................... 103

Standards Development Organizations or Communities of Practice (beyond ANSI and 

ISO) ...................................................................................................................................... 105

Appendix D: DOD policies, procedures, and guidelines on the use of national and 

international standards associated with defense product lifecycle management.................. 112

Appendix E: NIST’s Economic Impact Studies Related to Manufacturing ......................... 177
vii

List of Figures & Tables

Figure 1: Interfaces versus translators among systems................................................................ 6 

Figure 2: The Defense Acquisition Management Framework (source: [32])............................. 17 

Figure 3: Measuring the impact of STEP in the automotive industry (source:[36]) .................. 18 

Figure 4: STEP data specifications............................................................................................. 20 

Figure 5: The scope of AP203 (source:[48]) .............................................................................. 21 

Figure 6: ISO/CD AP203 edition 2 (source: [51])...................................................................... 23 

Figure 7: The scope of AP214 (source: [54]) ............................................................................. 25 

Figure 8: The scope of AP224 (source: [57]) ............................................................................. 27 

Figure 9: Modules of AP233 (source: [64]) ............................................................................... 28 

Figure 10: DEX architecture (source: [86])................................................................................ 31 

Figure 11: From information model to exchange (source: [63]) ................................................ 34 

Figure 12: AP240 (source: [91])................................................................................................. 35 

Figure 13: Initial components of the GEIA-927 standard .......................................................... 36 

Figure 15: EIA-836 focuses on data elements and business objects .......................................... 39 

Figure 16: OpenO&M framework reduces the number of interfaces (source: [110])................ 41 

Figure 17: Examples of content standards.................................................................................. 45 

Figure 18: Linkages among views [137] .................................................................................... 47 

Figure 19: An example of current standards and their coverage ................................................ 48 

Table 1: Similar efforts by GEIA and ISO ................................................................................. 52 

Figure 20: Epicycles nature of PLM........................................................................................... 67 

Figure 21: Data Exchange between AM General & TACOM [154].......................................... 86 

Figure 22: Data exchange between BAE Systems and TACOM ............................................... 87 
viii

List of abbreviations1

Acronym Meaning 

AECMA European Association of Aerospace Industries 

AIA Aerospace Industry Association 

AMC Army Materiel Command 

ANSI American National Standards Institute 

AP Application Protocol 

ASME American Society of Mechanical Engineers 

BOM Bill of Material 

B-Rep Boundary Representation 

CAD Computer-Aided Design 

CAE Computer-Aided Engineering 

CALS Computer-aided Acquisition and Logistics Support, or Commerce at Light 

Speed 

CAM Computer-Aided Manufacturing 

CD Committee Draft 

CGM Computer Graphics Metafile 

CM Configuration Management 

CORBA Common Object Request Broker Architecture 

DAMF Defense Acquisition Management Framework 

DEX Data EXchange Set 

DIS Draft International Standard 

EIA Electronic Industries Alliance 

ERP Enterprise Resource Planning 

GEIA Government Electronics & Information Technology Association 

GSC Global Standards Collaboration 

IS International Standard 

ISA Instrument Society of America 

ISO International Organization for Standardization 

IT Information Technology 

NATO North Atlantic Treaty Organization 

NC Numerical Control 

NGS Non-Government Standard 

NIST National Institute of Standards and Technology 

NTTAA National Technology Transfer and Advancement Act 

OASIS Organization for the Advancement of Structured Information Standards 

OEM Original Equipment Manufacturer 

OMB Office of Management and Budget 

PAS Publicly Available Specification 

PDM Product Data Management 

PLM Product Lifecycle Management 

RAND Reasonable and Non-Discriminatory 

 

1

 Acronyms associated with product lifecycle standards are defined in Appendix C. 
ix

Acronym Meaning 

SALE Single Army Logistics Enterprise 

SCRA South Carolina Research Authority 

SGML Standard Generalized Markup Language 

Tcl/Tk Tool Command Language/Toolkit 
1

1. Background 

The objective of this report is to provide the results of a preliminary investigation of selected 

standards and related technologies that might support the Army’s lifecycle management of 

products and services necessary to maintain the mission-readiness of its troops. A secondary 

objective is to provide input to the U.S. Army Materiel Command (AMC) through its Product 

Data and Engineering Working Group (PEWG). The PEWG is determining AMC’s direction 

forward and making implementation decisions for future contracts. 

1.1 Need and mandate for lifecycle support 

The need to exchange data among multiple business partners, developers, suppliers, users, and 

maintainers is the normal day-to-day complex business environment for the U.S. Army and other 

DoD Services. Product lifecycle management (PLM) is a function or a business strategy for 

creating, sharing, validating, and managing information about product, process, people, and 

services within and across the extended and networked enterprise covering the entire product 

lifecycle spectrum. 

DoD 4140.1-R [2003], “DoD Supply Chain Materiel Management Regulation,” outlined 

product support data requirements and procedures for defense sustainability and lifecycle 

support. The few excerpts from [1] exemplify what is necessary for product support, and 

brings the responsibility for lifecycle support home to bear on AMC and other DoD agencies: 

“Product support data consists of weapon system and equipment program, 

configuration, and performance data and technical manuals; weapon system 

reparable item test, failure, and usage data and repair manuals; and weapon 

system item support cost data. The DoD Components or a third party with 

guaranteed access shall collect and maintain product support data to ensure 

lifecycle sustainment and continuous improvement of product affordability, 

reliability, and supportability.” 

“Product support data users should have online access to product support data, 

regardless of the geographical location of that data.” 

“To warehouse product support data where necessary, the DoD Components 

should provide for data repositories, data management systems, and related 

access capabilities. The data management system for product support data 

should control the technical baseline (e.g., configuration documentation, 

technical data, and technical manuals) for weapon systems and other 

equipment.” 

“The DoD Component shall provide the capability to exchange product support 

information with allies to enhance international interoperability and 

cooperation.” 
2

As cited in IDS Sheer Group, 2005 [2], “the logistics process inefficiencies have resulted in: 

• Ineffective theater distribution capability 

• Inadequate bandwidth and communications infrastructure 

• Lack of asset visibility, leading to: 

− $1.2 billion discrepancy between material shipped vs. material received 

− Backlogs of hundreds of pallets and containers 

− Requisitions duplicated and supply system worked around 

− Inability to locate parts in theater pipeline led to the cannibalization of vehicles and 

a reduction in equipment readiness.” 

To meet its responsibilities and resolve these costly inefficiencies, the Army has committed to a 

Single Army Logistics Enterprise (SALE). SALE is designed to correct a long-standing 

problem in the Army’s logistics information management, notably: lack of a common operating 

process for measuring and analyzing materiel readiness and combat posture. Within the 

context of SALE, the Army intends to integrate its national and tactical logistics systems into 

one fully integrated, end-to-end enterprise. SALE will bring together three component systems: 

the Global Combat Support System-Army (GCSS-Army) Field Tactical (F/T), the Logistics 

Modernization Program (LMP), and GCSS-Army PLM+ [3]. PLM+ is the technical enabler 

proposed to link the field-level logistics system, GCSS-A with the National-level logistics 

system, LMP, and establish a single access point interface to integrate all their external 

systems. The components that comprise PLM+ are implemented by the combination of 

SAP©’s Product Lifecycle Management and NetWeaver© products. 

Such a commitment to the concepts of SALE is no longer an option for the Army, but a 

logistics’ imperative. As reported in the Government Accounting Office report [4], operating 

and support costs make up about 60-70 percent of a weapon system’s total lifecycle costs. 

Many of the current ground weapon systems will continue to be in service for another 20-30 

years. The Army needs the ability to support systems after production while reducing 

sustainability costs. The AMC is responsible for this support. 

1.2 The AMC drive for lifecycle support efficiencies 

The following quotes from AMC’s website underscore the breadth and depth of AMC’s critical 

role in the entire spectrum of product and services that it provides for US Army: 

“If a soldier shoots it, drives it, flies it, wears it, or eats it, AMC provides it.”

“AMC operates the research, development and engineering centers, Army 

Research Laboratory, depots, arsenals, ammunition plants, and other facilities; 

and maintains the Army’s pre-positioned stocks, both on land and afloat. The 

command is also the DoD Executive Agent for chemical weapons stockpile and 

conventional ammunition. To develop, buy, and maintain materiel for the 

Army, AMC works closely with Program Executive Officers, the Army 

Acquisition Executive, industry and academia, the other services, and other 

government agencies. 

AMC’s main effort is to achieve the development, support, and sustainment of 

the future force in this decade. At the same time, AMC is key to supporting and 
3

sustaining the interim force and to sustaining and recapitalizing the current 

force. Its maintenance depots continue to restore weapon systems continuously 

needed as the Army makes its way to full transformation. The command’s 

overhaul and modernization efforts are enhancing and upgrading major weapon 

systems – not just making them like new, but inserting technology to make them 

better and more reliable. 

AMC handles diverse missions that reach far beyond the Army. For example, 

AMC manages the multi-billion dollar business of selling Army equipment and 

services to friends and allies of the United States, and negotiates and implements 

agreements for co-production of U.S. weapons systems by foreign nations. 

AMC also provides numerous acquisition and logistics services to the other 

components of the DoD and to many other government agencies [5].” 

Changes in DoD acquisition and sustainment strategy are impacting AMC’s product and 

technical data business processes and enablers. To achieve its goal AMC headquarters has 

formed the Army Product Data and Engineering Working Group (PEWG). The PEWG is 

chartered2

 to: 

• Provide solutions and a plan of action to implement the spirit of such standards as DoD 

4140.1-R. 

• Address the complexities of the engineering and logistics supply chains within the 

Army. 

• Integrate these with original equipment manufacturers (OEMs) enterprises that create 

and maintain the data in today’s global business environment. 

The mission for PEWG is to: 

• Support HQ AMC by providing an Army-wide forum for determining requirements for, 

and resolving issues associated with management, and use of product data. 

• Develop strategies and approaches for lifecycle management of engineering, technical, 

and product data across all Army business domains and throughout the weapon system 

or part lifecycle. 

• Develop contractual policy, procedures, and guidance to order access or delivery of data 

on any Army contract. 

• Support enterprise IT system efforts to ensure a seamless flow of product data 

throughout the lifecycle of any weapon system. 

To carry out this mission, the product data user community has identified significant issues, 

which were grouped and mapped into four Work Packages: 

1. Define Product Data 

2. Identify Data Standards 

3. Clarify/Develop Product Data Policies & Training 

4. Define Product Data Business Processes 

This report is in response to two milestones for PEWG’s Work Package 2: 

 

2

 PEWG Charter of 31 MAR 2005. 
4

• Identify standards that could be used for lifecycle product data standardization, 

interoperability, and exchange among Army and its OEM enterprise systems (e.g., 

SALE, Future Business System ) 

• Help build a business case for using standards 

To this end, the National Institute of Standards and Technology (NIST) conducted a 

preliminary investigative study in collaboration with Army personnel to assess the level of 

current pilot or production use of various military, national, or international standards during 

the lifecycle support of any given weapon system component or part. The investigative study 

questions found in Appendix (A) were used to engage Army and OEM personnel in discussion 

to better understand the role of standards in their activities. The questions were used to 

encourage dialogue and solicit insight into processes and standards the AMC sites may be 

employing – whether in prototype or production fashion. Note that no direct questionnaire 

results are being provided in this report since the survey was used only for discussion. 

1.3 Report content 

The report is organized as follows; Section 2 presents Army product data processes that are 

important for this study. Section 3 provides a general background on standards and 

standardization. A review of relevant product data standards is discussed in Section 4. Section 

 5 highlights the results of NIST’s research on state-of-the-art application of selected product 

lifecycle standards, and offers a way the Army may want to approach it’s selection of PLM 

standards for use. The convergence and integration of PLM standards are also discussed in this 

section. Section 6 discusses implementation issues and presents the current and future 

challenges in standards development for PLM. Section 7 provides some observations and 

recommendations to the PEWG, and Section 8 on next steps and areas in which NIST could 

help. Acknowledgements, NIST’s disclaimer, and references conclude this report as sections 

9-11 respectively. Several appendices are at the end of the report. They provide general 

information to supplement the report’s content. 

While numerous acronyms are used in this report to enhance readability, many are 

subsequently spelled out only in the List of Acronyms, found in the beginning of this report. 

2. Product Data Related Activities and Issues in the US 

Army: a Current Perspective 

The United States Army holds one of the largest volumes of product data to build and support 

its fleet of combat vehicles. Efficient management of such large volumes of product data that 

is geographically distributed between government agencies and private industry contractors 

cannot be done without extensive use of product data representation, product data management, 

and product data exchange standards. This section discusses the specifics of product data 

management within the US army. 
5

The Army has a number of PDM systems that store weapon system technical data. These 

distributed systems are managed by Program Managers (PMs), Research Development and 

Engineering Centers (RDECs), depots, and system support; and are mostly based on 

Commercial off the Shelf (COTS) and Government-developed products. Furthermore, on many 

programs, the PMs have made the contractual decision to have the OEMs or other support 

contractors manage the product technical data. As a result there is currently no single system 

that stores data relating to the entire weapon system. 

As a weapon system goes through the acquisition lifecycle, various organizations have primary 

responsibility for the technical data generated during the acquisition process. It is clear that as 

the product advances through different phases of the lifecycle, new supporting product data is 

being continuously generated. The COTS solutions that are used in various phases are not 

standardized as each organization uses a system that best fits its requirements. This leads to 

silos of product data locked up in proprietary systems that cannot be exchanged easily among 

the various organizations that generate and use the data. A standards-based Product Lifecycle 

Management framework would allow the Army to exchange product data from proprietary 

systems using open architectures and standards to achieve interoperability. The Defense 

Acquisition Management Framework (DAMF) (a brief explanation of DAMF is provided in 

Section 4.2) illustrated in Figure 2 is one such effort. 

Unlike private industry, the Army cannot mandate the use of a single homogeneous system for 

its entire supply chain. Not only is this cost prohibitive and impractical, in most cases it would 

not result in the best value for the government. It therefore makes sense to allow Army 

organizations and OEMs to continue to use their product data generation and management tools 

of choice that meet individual program requirements. For example, on the Stryker program, 

Pro/ENGINEER♣ and Windchill♣ may be the systems selected by General Dynamics Land 

Systems; whereas the HMMWV program and AM General Corporation may elect to use 

Unigraphics NX♣ and Teamcenter Engineering♣. A standards-based Army PLM strategy can 

address these diverse geographically distributed product data formats and systems to manage 

the data. 

In general, the lifecycle of Army combat systems is much longer than lifecycles of commercial 

products like automobiles. It is not uncommon to see weapon systems in use today that are over 

50 years old. Combat vehicles such as the Abrams tank and Bradley Fighting Vehicle are 

expected to be in active service for another 25-30 years and are an integral part of the Army’s 

transformation to the future combat systems brigade combat teams [6]. It is estimated that 

weapon system sustainment costs are as much as $50 billion per system [7]. An extended 

lifecycle implies that the system will go through constant change to adapt to the war-fighting 

environment. Extended lifecycles also require long-term data retention and archiving where 

product data needs to be usable decades after the data were originally created and potentially 

after vendor products used to generate the data have gone out of business. Again standards can 

provide a solution for long term data retention since they are open, published and forward 

compatible. In March 2006, NIST held a workshop on “Long Term Knowledge Retention 

(LTKR)” [8]. The purpose of the workshop was to identify challenges, research, and 

implementation issues in digital preservation of information with an emphasis on design and 

 

♣ See Disclaimer Section 10. 
6

manufacturing. It brought together researchers and practitioners from disciplines including 

manufacturing engineering, library sciences, knowledge representation, and space science. 

It is clear that a number of PDM and logistics systems have to be integrated as part of a total 

Army PLM solution. Many excellent commercial Enterprise Application Interface (EAI) 

middleware solutions are available today to connect these enterprise solutions, but they have 

three major drawbacks: 

1. They are proprietary one-to-one mappings between enterprise solutions. Such interfaces 

add an additional level of proprietary data to the existing systems making them difficult 

to manage and maintain. 

2. They are version dependent and have to be migrated along with upgrades to the systems 

being integrated. When there are a number of systems being integrated this can turn into 

a very complex problem. 

3. They are very expensive to develop and maintain. Each interface can cost upward of $1 

million to develop and an additional $300,000 per year to maintain [7]. 

Below is more detail on some of the Army’s business processes routinely conducted within the 

product’s lifecycle. By using standards in these activities, the number of interfaces required is 

greatly reduced because each system will only require an import and export translator from the 

internal data format of the commercial system to the standard data model. This is illustrated in 

Figure 1. 

Figure 1: Interfaces versus translators among systems 

2.1 Product data delivery from contractors 

When DoD cancelled many of the MILSPECs and MILSTDs during Acquisition Reform [9] it 

offered to contractors the opportunity to deliver product data to DoD in contractor formats. 

While this potentially reduced costs associated with delivery of data it also turned into a 

challenge for DoD to handle a large variety of contractor formats that could not be directly used 

SAP 

Teamcente

MatrixOne

CMStat 

Enovia 

Windchill 

SAP 

Teamcente

MatrixOne

CMStat 

Enovia

Windchill

SAP 

Teamcente

MatrixOne

CMStat 

Enovia 

Windchill 

SAP 

Teamcente

MatrixOne

CMStat 

Enovia

Windchill
7

with existing DoD systems. Such a transition in data exchange has made it imperative for DoD 

and the Army to adopt international standards that are well supported by the private sector. This 

will enable the Army to use the best commercially available implementations of standards 

without imposing DoD-specific standards on the contractors and OEMs. Product baseline 

definitions to the Army are typically delivered as two separate deliverables – engineering or 

technical data (drawings, CAD models, etc.), and logistics supportability data (Logistics 

Support Analysis Record (LSAR) - provisioning, maintenance requirements, training material, 

reliability, availability and maintainability, etc.). There is still widespread use of MILSPEC1388-2B3

 for LSAR within DoD, and a multitude of proprietary formats to represent CAD data 

today that are not interoperable. 

2.2 Collaborative product development 

Most weapon systems today are developed by OEMs in an iterative mode with the Army. This 

requires the Army and its OEM engineers to work collaboratively while potentially using 

disparate commercial software for such collaboration. Standardizing on a single commercial 

software solution is not an option since most OEMs select CAD and PDM systems that meet 

their internal business process requirements. Due to a lack of interoperability between these 

systems today, data and data exchange processes are being reduced to the lowest common 

denominator - typically exchange of drawing images on CDs. This inefficient and timeconsuming process cannot work in rapid field projects to support the war fighter. Manual entry 

and re-entry of data between systems can lead to serious human errors, duplication of data, 

poor data integrity, and lack of configuration management. It is important for the Army to 

enable interoperability and automation of processes using standards to obviate the need for 

manual intervention. 

2.3 Depot manufacture and overhaul 

The Army is currently unable to efficiently balance the work load across the various depots and 

arsenals as a result of non-standard systems, applications, and processes in place at each depot. 

While it is not reasonable to replace and align all systems across the depots to one vendor or 

one solution, the use of standards to enable the effective exchange of manufacturing process 

data among the depots is a viable alternative. 

2.4 Condition-Based maintenance and failure feedback 

There are a number of databases and systems today that collect failure feedback information 

from either on-board sensors or maintenance tasks but are unable to be analyzed collectively as 

a result of disconnected and separate databases. While it is reasonable to expect multiple 

databases to store such information it is also important to be able to consolidate and integrate 

this information in order to perform an effective analysis of the data. Such standardized data 

can then be fed back into product improvement processes to enable proactive redesign of parts. 

Failure and maintenance feedback information is another area that requires examination for 

applying product lifecycle standards within the Army. 

 

3

 Military Specification 1388B, Logistics Support Analysis Data, was cancelled for use by the Department of 

Defense November 26, 1996. 
8

2.5 Performance-Based logistics support 

For lifecycle support of a weapons system, it is important for the Army to have visibility and 

on-demand access to data from the OEMs or other support contractors to ensure that readiness 

levels are being met. This business process requires the weapons system program manager to 

continually monitor key performance metrics and the data supporting such metrics. Using 

standards to enable the access to data between organic systems and contractor systems would 

allow the data to continue to reside on the contractor's systems while allowing the Army 

program manager a more effective way to provide logistical support. 

2.6 Item unique identification 

A major aspect of the DoD's mandate for a Unique Identification (UID) initiative includes the 

standardization of UID information using international standards such as ISO 103034. As Army 

assets are uniquely identified, this information relating to parts, assemblies, and systems need 

to be propagated to "as-built" and "as-maintained" configurations of the systems to enable audit 

tracking. Standardization of such information can enable this data to be exchanged across a 

number of cross-domain applications such as manufacture, maintenance, asset valuation, and 

disposal. 

2.7 Configuration management 

End-to-end configuration management of a weapon system across organizations and systems is 

a tremendous undertaking for the Army. While product data can be quite effectively managed 

within a Product Data Management (PDM) or Enterprise Resource Planning (ERP) system, 

such software can only manage data that is resident within the system. Configuration 

management requirements involve the entire lifecycle of the weapon system starting with "asplanned," "as-designed," "as-built," "as-maintained” through “as disposed of” configurations. 

Change propagation that is initiated outside of the system cannot be handled by most 

commercial systems today, so it is not realistic to expect that all configuration management 

requirements will be managed within a single software system. 

3. Why standards? 

Standards are the bridge to communicating information among recipients with diverse user 

requirements, and as Section 2 noted, diverse and proprietary systems where key critical data 

reside. The Global Standards Collaboration (GSC) initiative saw the merits of collaborating to 

build such bridges [10]. GSC is comprised of national participating organizations around the 

world who are concerned with the promotion of global standards in areas of common interest. 

In a key resolution passed in October 2004, GSC defined that a standard should: 

• Support fair trade and fair competition. 

• Increase user, consumer, and government confidence. 

• Facilitate interoperability. 

 

4

 See Jun 23, 2005 memorandum, Krieg, Kenneth J., Under Secretary of Defense, “Standard for the Exchange of 

Product Model Data (STEP) --- ISO 10303,” found in Appendix D. 
9

• Stimulate innovation. 

While many unfortunately perceive standards to be a barrier to technology advancement, 

standards can actually enable innovation by proving a stable platform: 

• On which to build vertical applications. 

• For expanding existing markets and creating new markets. 

• For propagating innovation across industries [11]. 

The critical role that standards play in all of the activities that we engage in is emphasized by 

CSA International: “Standards touch our lives every day, affecting nearly every product or 

service we encounter--- from the pipes in the wall to the lights overhead. When you sit down at 

your desk, plug in an appliance, drive over a bridge, or put on a helmet, standards are at work. 

Standards help to ensure that products and services live up to our expectations. In many cases 

they define safety and quality requirements; in some cases they focus on efficiency or 

environmental practices. For manufacturers, standards help to lower production costs. They 

promote interconnectivity and harmonization among products and components, and help open 

doors to new markets. For consumers, this means a wider selection of goods and services and a 

more competitive marketplace. It also means greater convenience and consumer confidence 

[12].” 

So what exactly is a standard? How can standards help the AMC reduce weapon system 

lifecycle sustainability costs and facilitate better digital information transfer among its users? 

In this report, we attempt to answer these and other important questions. 

3.1 Categories of standards 

A standard can be classified into different categories based on purpose, based on the specific 

requirements, and process by which it was developed. In this and the following section we 

briefly discuss the different categories of standards and the rationale behind this categorization. 

3.1.1 As Defined by Congressional Authority 

The term "standard” or "technical standard" as cited in the National Technology Transfer and 

Advancement Act (NTTAA) of 1995 [13], includes all of the following: 

• Common and repeated use of rules, conditions, guidelines, or characteristics for 

products or related processes and production methods, and related management systems 

practices. 

• The definition of terms; classification of components; delineation of procedures; 

specification of dimensions, materials, performance, designs, or operations; 

measurement of quality and quantity in describing materials, processes, products, 

systems, services, or practices; test methods and sampling procedures; or descriptions of 

fit and measurements of size or strength. 

 
10

3.1.2 As Supplemented by the Executive Branch 

The Office of Management and Budget (OMB), in its Circular A-119 Section 3 [14] further 

elaborates on standard classifications. This Circular classifies standards according to their 

purpose and manner in which standards specify requirements: 

Based on Purpose 

• A basic standard has a broad ranging effect in a particular field, such as a standard for 

metal, which affects a range of products from cars down to screws. 

• Terminology standards (or standardized nomenclature) define words permitting 

representatives of an industry or parties to a transaction to use a common, clearly 

understood language. 

• Test and measurement standards define the methods to be used to assess the 

performance or other characteristics of a product or process. 

• Product standards establish qualities or requirements for a product (or related group of 

products) to assure that it will serve its purpose effectively. 

• Process standards specify requirements to be met by a process, such as an assembly line 

operation, in order to function effectively. 

• Service standards, such as for repairing a car, establish requirements to be met in order 

to achieve the designated purpose effectively. 

• Interface standards, such as the point of connection between a telephone and a computer 

terminal, are concerned with the compatibility of products. 

• Standards on data to be provided contain lists of characteristics for which values or 

other data are to be stated for specifying the product, process or service. 

 

International Standards have been developed through a process that is open to participation by 

representatives of all interested countries, transparent, consensus-based, and subject to due 

process. The existence of non-harmonized standards for similar products, processes, and 

services in different countries or regions create barriers to trade. Therefore, export-minded 

countries and industries have recognized the need for internationally accepted standards to help 

rationalize the international trading process. 

Based on manner in which standards specify requirements

• Performance standards describe how a product is supposed to function. A performance 

standard for water pipe might set requirements for the pressure per square inch that a 

pipe must withstand, along with a test method to determine if a specimen meets the 

requirement. 

• Design standards define characteristics or how the product is to be built. The 

specification that a pipe is made of a given gage of copper would characterize a design 

standard. 

Government agencies are encouraged to write technical regulations and standards in terms of 

performance, rather than design characteristics. 
11

3.2 Standardization methods 

As there are different classes of standards [15; 16], there are also different processes to develop 

standards. 

• De Facto: De facto standards are those set by the marketplace; it is usually a 

proprietary application used so universally as to become a standard for exchange of 

information across trading partners, e.g., Microsoft Word©. A de facto standard is 

usually in production use, evolving from the bottom up according to the forces that 

drive the market. Global exchange among partners is only as effective as the de facto 

standard will allow. Users do not have access to the source code of the application 

(closed source) to improve upon exchange or to better ensure interoperability; this is left 

to the desires and priorities of the corporation or entity owning the de facto standard to 

add into their product. 

• Voluntary Consensus: Standards can be set through organizational processes that reduce 

transaction costs and facilitate information exchange and negotiation among trading 

partners. Such processes can provide better coordination and security when the levels of 

uncertainty are high, when there are frequent recurring exchange activities among the 

partners, or when information exchange is complex. The most known international 

voluntary consensus process for thousands of standards is under the direction of the 

International Organization for Standardization (ISO). 

• Regulatory: Standards also result from political choices. Such standards are often 

referred to as regulatory standards [17]. 

3.3 Voluntary consensus standards 

Under the provisions of Public Law 104-113 signed into law by the 104th Congress, the 

NTTAA of 1995 [18] requires that all federal agencies are required to use voluntary consensus 

standards in preference to agency- or government-specific standards for procurement and rulemaking activities, except where such use is impossible or inappropriate [19]. 

OMB issued a revised version of OMB Circular A-119 entitled, “Federal Participation in the 

Development and Use of Voluntary Consensus Standards and in Conformity Assessment 

Activities,” to implement the provisions of NTTAA. It states, “The use of voluntary consensus 

standards, whenever practicable and appropriate, is intended to achieve the following goals: 

• Eliminate the cost to the Government of developing its own standards and decrease the 

cost of goods procured and the burden of complying with agency regulation. 

• Provide incentives and opportunities to establish standards that serve national needs. 

• Encourage long-term growth for U.S. enterprises and promote efficiency and economic 

competition through harmonization of standards. 

• Further the policy of reliance upon the private sector to supply Government needs for 

goods and services." [14] 

ISO is a collaboration among the national standards institutes of 156 countries5

. Each country 

is given a single vote on any given standards development and approval. ISO standards aid in 

 

5

 The American National Standards Institute (ANSI) is the United States member and voting representative to ISO. 
12

more efficient, safer, and cleaner development, manufacture, and supply of products and 

services. ISO as a non-governmental organization is able to act as a bridging organization in 

which consensus can be reached on solutions that meet both the requirements of business and 

the broader needs of society, such as the needs of stakeholder groups like consumers and users. 

ISO has a supporting Central Secretariat located in Geneva Switzerland that is responsible for 

the coordination of all the standards’ development activities, and the publication and 

distribution of resulting standards [20]. 

3.4 Importance of industry-driven standards 

The United States Standards Strategy (a revision of the National Standards Strategy for the 

United States [20] that was approved in August 2000) states the following to underscore the 

critical role that standards play in all our activities: “Standards are essential to a sound national 

economy and to the facilitation of global commerce. The global standards landscape is rich 

with entities, systems and processes, and both the U.S. government and private sector 

participate in international standards activities in a variety of ways: through treaty organizations 

where governments are members; through private, voluntary organizations where the United 

States is represented by a single ‘national body’ organization; through professional and 

technical organizations whose membership is on an individual or organizational basis; and 

through consortia, whose membership is typically technology based. ... The government 

should recognize its responsibility to the broader public interest by providing financial and 

legislative support, and by promoting the principles of our standardization system globally. 

Global competitiveness of U.S. industry depends critically on standardization, particularly in 

sectors that are technology driven.” 

Standards make trade between countries easier and fairer. Internationally developed standards 

such as those in ISO serve to simplify the lives of, and safeguard consumers of products and 

services. You will read later in this report the benefits specific to the prototype and 

implementation of international, industry-driven standards. 

In [21], C.F. Cargill states that the use of standards also provides the user with a more solid and 

long-enduring technology, independent of the system on which the data resides. Mergers and 

bankruptcies are becoming commonplace worldwide, and there are no guarantees that the 

system you use today will be available or supported tomorrow. Being able to repeatedly and 

consistently translate and interpret intelligently the data independent of the commercial system 

on which it resides, is a strong argument for the use of mature international, industry-driven, 

standards. 

In contrast to the openness and international participation of vendors, users, academia, and 

government in the ISO community, is the cultural and historical precedent use of military 

specifications and standards. DoD has been called the most diversified and largest developer 

and user of standards in the United States, and possibly the world. DoD primarily uses 

standards for procurement purposes, requiring equipment and parts suppliers to provide 

products that conform to detailed product specifications. But these defense-specific product 

specifications have far-reaching impact and expense on the lifecycle support of that product. 

DoD has also been the most active government agency in standards reform, and has its own 

historical examples of quantitative benefits resulting from its reform away from militaryspecific specifications and standards [19]. 
13

The proliferation of DoD-specific standards and specifications was a post World War II 

response to inadequate or nonexistent private-sector standards. Thus military specifications 

(MILSPECs) and standards (MILSTDs) were born. A MILSPEC describes the essential 

technical requirements for purchased material that are military-unique or are substantially 

modified from commercial items. A MILSTD establishes uniform engineering and technical 

requirements for military-unique or substantially modified commercial processes, procedures, 

practices, and methods [22]. For products that were common to military and civilian uses, 

MILSPECs in most cases did not simply adopt the industry standards, and thereby the unique 

military requirements specified in the MILSPEC required suppliers to develop separate 

methods and machinery to accommodate both a supplier’s commercial and defense markets. A 

study of military contractors by the management consulting company Coopers & Lybrand 

determined that the use of a group of 120 MILSPECs increased the price DoD pays for industry 

goods and services by about 18 percent. 

Since 1962, DoD has been working to reduce unnecessary defense-specific requirements and 

associated excess costs by supporting the use of private-sector standards; and in fact, the 

original 1982 version of OMB Circular A-119, mentioned in Section 2, was based on DoD’s 

established policy at that time. These ongoing efforts have accelerated since 1994, when 

Secretary of Defense William Perry ordered the MILSPEC Reform Initiative. (This 

correspondence can be found in Appendix D.) This reform’s immediate purpose was to review 

the current military-unique specifications and determine if any of those specifications could be 

replaced reasonably by industry standards. Since the beginning of MILSPEC Reform, DoD has 

reviewed over 29,000 agency-specific standards and has cancelled or replaced 9,600 of them. 

These profound efforts continue today under the direction of the Defense Standardization 

Program Office. Additional Defense correspondence and brief examples of several initiatives 

in DoD and the Army further exemplify this reform in Appendices (D) and (B) respectively. 

Today, the DoD has created the Defense Standardization Program under the auspices of the 

Defense Logistics Agency [23]. Its mission is to champion standardization throughout DoD 

that will lead to a reduction in costs and improved operational effectiveness. Consistent with 

the legislation of NTTAA and OMB Circular A-119, the DoD is committed to be proactive in 

the adoption and use of non-government standards, wherever possible, instead of developing 

new or updating existing government specifications and standards. To this end, DoD policy 

encourages its employees to collaborate with the private sector and other government 

employees on technical committees of non-government standards (NGS) development 

organizations. Such participation best ensures proper consideration of DoD requirements, 

enhances the technical knowledge of DoD personnel, and allows DoD employees to contribute 

their considerable technical capabilities to the development of world class standards. At the 

same time, it allows defense personnel to recognize and better understand the requirements and 

priorities of those outside the defense environment, learning through experience, the old adage, 

“we are more alike than we are different.” 

In review, “Standards enable products, systems, and even organizations to work together. 

Standards can promote competition. They can stimulate innovation. And they can also promote 

our well-being and improve our quality of life.” [24]. “It’s not about whether or not to use 

standards, but knowing which standards from the existing plethora best meets your 
14

requirements.” [25]. Appendix (C) provides a starter list of possible product lifecycle -related 

standards, and some of the supporting standards development organizations.6

4. Preliminary analysis of standards for lifecycle 

management 

In this Section, we will discuss various standards that may contribute toward the 

interoperability of various systems that manage product lifecycle information and provide 

administrative and operational support. 

4.1 Product lifecycle management 

Product lifecycle management (PLM) is a function or a business strategy for creating, sharing, 

validating, and managing information about product, process, people, and services within and 

across the extended and networked enterprise covering the entire product lifecycle spectrum. 

The importance of interoperability across the phases and functions in PLM has been recognized 

by a number of institutions including NIST, DoD, the European Ministries of Defense and, 

more recently, by the vendor and end-user communities [26; 27]. While there has been 

articulation of the need, the issue has not been fully addressed due to the divergence of interests 

on how interoperability should be achieved. The challenge is to create standards and protocols 

that allow legacy systems as well as future technological innovations to interoperate 

seamlessly. This requires dealing with a multiplicity of computer languages that can represent 

the complete product description. 

A 1999 study commissioned by NIST [4] estimates that imperfect interoperability imposes at 

least $1 billion per year on the members of the U.S. automotive supply chain7. By far, the 

greatest component of these costs is the resources devoted to repairing or reentering data files 

that are not usable for downstream applications. This is parallel to the Army’s existing lifecycle 

logistics practices. The report’s estimate is considered conservative because the study could not 

quantify all sources of interoperability costs. Members of the automotive industry that 

participated in this impact study generally acknowledge that imperfect interoperability is an 

important and expensive problem. A number of potential solutions have been developed over 

the years. These include: 

• Standardization on a single system for each OEM and its suppliers and sharing of files 

in native format. 

• Development of point-to-point translators. 

None of the solutions that have been widely used in the past has been successful at significantly 

reducing interoperability problems. Single system standardization forces suppliers to maintain 

 

6

 Another complementary source for hundreds of standards in the database and network communication domains 

can be found in “Survey of Languages, Specifications, and Standards for Database and Network 

Communications,” by David L. Brock, Auto-ID Center, MIT-AUTOID-WH-015, November 1, 2002. 

7

 The full executive summary from this report and other related economic impact reports prepared by NIST can be 

found in Appendix E. 
15

redundant systems and does not eliminate interoperability problems. Point-to point translators 

work reasonably well for some well-defined data translation tasks, but each combination of 

sending and receiving systems requires a different translator. Neutral format translators such as 

the Initial Graphics Exchange Specification (IGES) [28] and Data eXhange Format8

 have 

proven successful in some limited applications, but have a number of identified weaknesses; 

hence, standardization initiatives such as ISO 10303, informally known as STEP – the 

STandard for Exchange of Product model data have emerged. 

Today’s standards, particularly in the area of CAD, have produced direct improvement in 

productivity, especially in the manufacturing arena, by reducing transaction costs and even 

more so by increasing the richness of interactions between supplier and customer [29; 30]. 

Before assessing the worthiness of any investment in a maturing international standard such as 

ISO 10303 (STEP), one has to reconcile the current state of interoperability – both what level 

of interoperability is necessary to manage effectively the lifecycle of a product, and whether the 

technology is there to support the need. The real cost of the lack of interoperability is generally 

difficult to measure and is often buried in day to day operations of individuals needing the 

information or needing to transmit the information. 

The big picture must effectively account for all the necessary integration links necessary to 

support a product throughout its life, even when that lifecycle is 20 or more years. It is also 

important to first recognize the problem, and then build a business case for the solution. Dr. 

Dale Hall, the Director of NIST’s Manufacturing Engineering Laboratory, further underscores 

this: 

“The interoperability of computing systems is emerging as a top priority issue 

for productivity increases in the U.S. manufacturing sector, including the 

aerospace industry. Computer usage has helped reduce inefficiencies and 

improve performance of manufacturing systems, but this reliance has come with 

enormous costs associated with a lack of interoperability. For systems to be 

interoperable requires the ability to share and exchange information between and 

among dissimilar computer systems. Often the incompatibilities among such 

systems alter or lose information. 

Different participants in the manufacturing supply chain use different software 

systems for similar manufacturing functions. And within individual companies, 

multiple, often complex software systems are used to conduct different business 

and technical tasks. Software systems tend to use proprietary data 

representations that are frequently incompatible with those used by other 

software vendors. Recent studies have shown that the economic (inefficiency) 

costs of this incompatibility in the automotive supply chain alone are estimated 

to exceed $1 billion a year.”9

How big is the problem faced by supporting components of the product’s lifecycle support 

supply chain? The following are some examples of how big the problem really is: 

 

8

 DXF is AutoCad’s proprietary format. 

9

 Presentation to the National Research Council Assessment Panel, by Dr. Dale Hall, Director, Manufacturing 

Engineering Laboratory, NIST, 2002. 
16

“Of 13 million engineering hours spent on (a recent aircraft program), 8 million were spent on 

data correction and administration.”10

"Imperfect interoperability imposes at least $1 billion per year on the members 

of the U.S. automotive supply chain.” [4] 

“U.S. aerospace industry estimates that $10M of capital equipment takes 100 person-years to 

integrate.”11

“The lack of integrated data systems also hampered U.S. reconstruction efforts in Iraq, Smith 

said. ‘I can’t begin to tell you how much of that $18 billion was spent on just trying to get 

systems to talk to one another.’”12

In the context of PLM the need for standards at different levels of expressiveness becomes 

critical in supporting the processes of information exchange. The role of Standards in PLM 

support has been discussed in a recent study conducted at NIST [16]. The study presented a 

model of communication between two partners and extended it to the PLM context and 

described the current support for PLM and the need for information exchange in supporting 

PLM. 

4.2 Standards relevant to the Army’s product data management 

The fundamental principles and procedures that DoD is expected to follow in achieving its 

objectives are described in DoD Directive 5000.1, “Defense Acquisition Guidebook” and DoD 

Instruction 5000.2, “Operation of the Defense Acquisition System” [31]. These directives also 

mention various standards that are relevant and important for DoD. These directives define 

policies and procedures for DoD to rapidly acquire quality products that satisfy user needs with 

measurable improvements to mission capability at a fair and reasonable price. These two 

directives also outline various standards that are essential to achieve these goals. Our study 

focus (questions found in Appendix A) re-emphasized the policies of DoD-5000 directives in 

terms of DoD standards implementation and policies. 

The acquisition process is structured by DoDI 5000.2 into discrete phases separated by major 

decision points (called milestones or decision reviews) with a number of key activities to 

provide the basis for comprehensive management and informed decision making. The number 

of phases and decision points are tailored to meet the specific needs of individual programs. 

This is called the Defense Acquisition Management Framework (DAMF) and is illustrated in 

Figure 2. The key activities shown in Figure 2 include the following: 

• Concept Refinement (CR) 

• Technology Development (TD) 

• System Development and Demonstration (SDD) 

 

10 STEPTools Inc., Weekly Newsletter, 13 April, 2000. 

11 J. Evans, NIST ISD, 2001 GATE-M Presentation 

12 Quote by Gen. Lance Smith, Commander U.S. Joint Forces Command, in Josh Rogin FCW.com article, “DoD 

Seeks Common Data Strategy,” August 21, 2006. 
17

• Production and Deployment (PD) 

• Operations and Support (OS) 

Figure 2: The Defense Acquisition Management Framework (source: [32]) 

To realize the Defense Acquisition Management Framework, DoD needs to use various 

standards and frameworks that cover the entire lifecycle spectrum as shown in Figure 2. For 

this report we limited the scope of our review of relevant standards and frameworks to several 

called out in DoD 5000.1 or that were mentioned during our site visits and interviews. We also 

included MIMOSA OpenO&M as it is mandated for Defense use by Defense Adoption Notice 

of MIMOSA OSA-EAI-2004, December 20, 2004; and GEIA-927 --- a later effort supported 

by DoD resources: 

• ISO 10303, Informally known as STEP --- STandard for the Exchange of Product 

model data (covers all the DAMF activities) 

• GEIA-927, Common data schema for complex systems (CR+TD+SDD) 

• EIA-836, Configuration management and data exchange and interoperability (CR+TD) 

• ANSI/EIA-649, National consensus standard for configuration management (CR+TD) 

• MIMOSA OpenO&M, Information standards (PD + OS) 

• ASD/AIA-S1000D, International technical publication specification (OS) 

We have mapped each of these standards to its functional applicability to satisfy a portion or 

the whole of the lifecycle spectrum in Figure 2 (within parentheses after each standard in the 

above list). The complexity within the army context is to define a system-to-system approach 

for PLM where the main goal is to make the Army systems understand each other, and 

seamlessly interoperate. 

4.2.1 ISO 10303 STandard for Exchange of Product model data (STEP) 

ISO 10303, or STEP, deals with product structure, geometry, and part-related information [33]. 

It uses the EXPRESS information modeling language to define a generic product model [34]. 

ISO 10303 is a complex standard comprised of many parts. STEP has been officially approved 

as an international set of standards since 1994, but it became more trustworthy (accurate, 

effective, and popular) to implement and use two or three years later. Acceptance and adoption 

of STEP by manufacturers and software developers has been very slow because the user 

community that would benefit from its implementation contractually adopt more short-term 

IOC - Initial Operational Capability, 

FOC - Full Operational Capability, 

FRP - Full-Rate Production, 

A, B, C are Milestones
18

solutions; also, perhaps because of the perceived (or real) view that STEP is an expensive 

solution to implement. While real dollar figures for the cost to implement STEP could not be 

found by NIST, as [35] suggests, imagine the economic benefits to the Army if: 

• Product configuration information was always accurate, up to date and immediately 

accessible. 

• Maintenance information was precisely tailored to the specific task(s) to be performed, 

i.e., reflecting resources skills, facilities, and material available. 

• Spares and inventory costs were minimized through vendor involvement in an 

integrated reliable supply chain. 

• In-service feedback was accurate, including the operating context under which it was 

gathered and was readily available to product designers and support managers. 

• Change was easy to manage throughout the lifecycle and the impact of change 

proposals could readily be evaluated. 

• Unscheduled maintenance events could be dealt with efficiently and effectively. 

NIST commissioned an economic impact study [36] on the cost of doing business if STEP is 

not implemented13. The impact down the supply chain was more intense than at the OEMs. 

Figure 3 shows what the study discovered in those interviewed from the automotive industry. 

Figure 3: Measuring the impact of STEP in the automotive industry (source:[36]) 

STEP, or more appropriately, specific standards under the umbrella standard, ISO 10303, has 

proven to save efficiencies in time, material, and staff. In NIST’s planning report 02-5, there 

 

13 The complete executive summary from this study can be found in Appendix E of this report. 
19

were projections for the Transportation Equipment Industries that STEP has the potential to 

save $928M/year by reducing interoperability problems in automotive, aerospace, and 

shipbuilding industries. Testimonials cited that the benefits would accrue to end users through 

increased interoperability of computer-aided design, engineering, and manufacturing; and 

product data management systems. 

In [37], industry examples of savings have also been cited: 

• Lockheed Martin has found in their business analysis that by using STEP (AP203, 

AP219 [38], AP232 [39], and AP233), it has shown a reduction in model rework, 

improved model quality, and lower span times with activities such as design 

integration/collaboration, procurement activities with suppliers (bidding/build), and 

integration with complementary tools (e.g., numerical control and analysis). Lockheed 

Martin has already realized significant savings using STEP: During engineering design, 

pilots show a 10% improvement in reliability of data exchange, 10% process savings for 

non-composite parts, and 50% process savings for composites. For manufacturing, 

projected savings for tool design on CAD/CAM systems is 27% and 38% for NC CAM 

systems due to elimination of data re-entry. 

• Raytheon’s pilot use of STEP demonstrated significant labor and cycle reduction for the 

preparation and delivery of technical data packages to its suppliers using STEP: 50% - 

88% labor and 59% cycle time savings at Raytheon, with a 42% labor and 95% cycle 

time savings at the suppliers’ end. 

• EPM pilots using AP239 (mentioned later in this section) resulted in data discrepancies 

having dropped from over 20% to less than 2%, the number of engineering change 

orders was dramatically reduced, and the time required to distribute data has dropped 

from weeks to hours. 

As introduction to the technical discussion on several STEP application protocols that follows, 

Figure 4 provides a very cursory summary of the historical integration concepts across the 

whole of STEP and its various international specifications. For a more detailed introduction to 

STEP, please refer to [33]. 

In the modular approach of STEP [40], information models form modules and integrated 

resources (IRs), from which specific content standards (called application protocols or APs) are 

developed. Each AP has a scope that indicates what is and what is not addressed in the AP, and 

an associated set of conformance classes (CC) that can be implemented within an application. 

In the following sections, we present a subset of STEP APs that may be important from the 

PDM/PLM point of view. For each presented AP we indicate its scope, conformance classes, 

and give known examples of implementations of it. 

The programs that convert data from proprietary formats to STEP and vice-versa are called 

translators. To verify the conformance of STEP AP translators, a joint industry/government 

consortium for accelerating the development and implementation of STEP, called PDES, 

Inc.[41], started testing STEP translators for conformance and interoperability within and 

among CAD systems. Interoperability continues to be tested within the CAx Implementor 

Forum [42], which is jointly run by PDES, Inc. and ProSTEP iViP [43]. 
20

Figure 4: STEP data specifications 

In the context of this report, “STEP implementation” is a software application that offers the 

functional capability of one or more APs of ISO 10303 to exchange product information, or 

makes it possible for other applications to do so. Thus, STEP implementations include software 

applications that run on CAD systems, PDM systems, bill of materials systems, stand-alone 

translators, and other packages that make it possible to develop the above systems [44]. 

STEP implementations are abundant for several conformance classes of AP203 (primarily 

CC6a, along with CCs 2a & 4a) and CC1 and CC2 of AP214, which is essentially AP203 with 

a different set of configuration management data. The conformance classes of each AP are 

briefly explained below. These are the AP/CC implementations that most of the CAD/CAM 

vendors have chosen to implement. There are many successful commercial STEP translators 

available on the market today that can produce digital product data that is compliant with STEP 

APs. A summary of commercially available STEP translators for most of the major 

CAD/CAM/CAE vendors and comments on some of their near term future implementation 

plans are given in the fourth chapter of the STEP application handbook [45]. An updated list 

can also be found on the PDES, Inc. or STEP Tools, Inc. web sites [46; 47]. 

In the spirit of embracing STEP, DoD, in its memorandum of June 23, 2005 (Appendix D), 

requested the secretaries of the Army, Army Materiel, and Air Force implement a similar 

approach to that implemented within the Navy for adopting ISO 10303 to enhance 

interoperability. 

1) AP203 Configuration controlled 3D designs of mechanical parts and assemblies 
21

This application protocol defines the information model for the exchange of parts and 

assemblies as well as for configurations. AP203 belongs to the first standardized set of 

specifications of ISO 10303 and became an international standard in 1994. It looks at the 

definition of product as an integration of the specification of its shape, the specification of its 

configurations, and the applicability of its possible multiple definitions to a particular 

configuration. It defines the exchange of product definitions with 3D shape representations 

together with the data, which defines and controls the configuration of those product 

definitions. In this AP, the configuration is about what parts compose a product and how they 

are composed together. This configuration management is based on ANSI/EIA-649, but it does 

not cover all the configuration management principles that are defined in EIA-836. 

Figure 5 shows the scope of AP203 structured around four topics: configuration management, 

geometric shapes, product structure, and specifications. 

Figure 5: The scope of AP203 (source:[48]) 

AP203 can be used to represent product definition data for mechanical parts and assemblies. It 

captures information of design activities (shape, material, process, surface specification) and 

change control (data that are necessary for the tracking of a design's release, or for the approval 

of a design; a design aspect, or a configuration control aspect). Analysis or test data of a design 

is captured only if it is necessary as evidence for a design change. The shape of a product can 

be described using five types of shape representations (wireframe and surface without 

topology, wireframe geometry with topology, manifold surfaces with topology, faceted 

boundary representation, and boundary representation). AP203 provides alternate 

representation of the data by different disciplines (different views on the manufacturing 

processes) during the product's lifecycle. Security and organizational data such as 

responsibilities, approvals, suppliers, and contractors are also in the scope of this AP. 
22

From the design point of view, AP203 does not cover product definition data and configuration 

control data pertaining to any lifecycle phase other than the design phase. The data that is used 

in, or results from, the analysis or test of a design that is not used as evidence for consideration 

of a change to a design, and the data that results in changes to the design during the initial 

design evolution prior to its release are also not covered in this AP. From the product shape 

point of view this AP does not cover the use of constructive solid geometry for the 

representation of objects and the data that pertains to the visual presentation of the product. The 

business data for the management of a design project is also out of the scope of this AP. 

AP203 has 12 conformance classes (CCs) noted 1a, b through 6a, b. AP203’s CCs are 

characterized as follows: 

• the CC 1a, b is dedicated to configuration controlled-design information without shape 

(CC 1a is a specified "product identification" subset of CC 1b). This class is also part of 

the remaining classes. 

• CC 2a, b is composed of CC 1a, b and 3D geometrically bounded wireframe and/or 

surface models. 

• CC 3a, b: CC 1a, b and 3D wireframe models with topology. 

• CC 4a, b: CC 1a, b and manifold surface models with topology. 

• CC 5a, b: CC 1a, b and faceted B-Rep. 

• CC 6a, b: CC 1a, b and advanced B-Rep. According to [45] very few vendors who 

claim to have an AP203 translator have implemented CC 5a,b; most have implemented 

CCs 2a, 4a & 6a (i.e., with a "minimal” subset of configuration management data). 

The first edition of AP203 was approved in 1994; this edition is now mature and well adopted 

by various industrial sectors. It has been used as a replacement for IGES for successfully 

transferring geometric data between various CAD systems. Several uses of note for AP203 can 

be found in [37]: 

• The automotive OEM Delphi Delco Electronics Systems, was using STEP to exchange 

solid model data with Chrysler and Saturn corporations in 1997. Those files imported 

into CATIA that did have problems, required about 30 minutes of rework to remove 

unwanted reference geometry. Even with this rework, using STEP dramatically reduced 

the design cycle time and costs, and increased the accuracy and quality of the geometry 

input into, and output from, CATIA. For example, 12 files transferred using STEP 

saved approximately 50 hours of manual intervention [49]. 

• It has been used in the aerospace industry with considerable success. Boeing routinely 

uses STEP in everyday production activities throughout the company. It uses AP203 

first edition for collaboration across project participants and information delivery to 

customers.

• A STEP-based pilot project developed within the PDES, Inc.’s Aerospace Engine 

Alliance (AEA) is used in production at Pratt & Whitney and AIRBUS. This pilot was 

initiated in 1999 with the participation of AIRBUS, Pratt & Whitney, General Electric, 

Theorem Solutions, PTC, and Unigraphics Solutions. The pilot included a “Validation 

Properties,” process that allows fully validated assembly exchange capable of validating 

the position of each component within an assembly or sub-assembly. In addition, the 

pilot incorporated a mechanism to break up very large CAD models using external 

references. 
23

• At IBM, STEP comprises over 25% of IBM's global e-procurement design data 

exchange. In the area of collaborative design, IBM is focused on a process of Common 

Building Blocks (CBB) to help drive down costs. STEP is used to enable the CBB 

process, which requires sharing designs between CATIA V5 and other CAD systems. 

• Lockheed Martin has adopted AP203 as a primary means for exchanging CAD data 

with suppliers. 

• Electric Boat uses AP203 for the exchange of data for thousands of solid models each 

year. It is also using XML and STEP for the Web to demonstrate production and 

development efforts using AP203 (and AP216, AP218 and AP227). 

• Rockwell Collins is using AP203 (and AP210) for simulation for flexible manufacturing, 

computer integrated manufacturing, integration of electrical/mechanical design, and 

capturing the product definition.

The second edition of AP203, currently published as a technical specification. is now a 

Committee Draft (CD) and going through the ISO subcommittee to make it an international 

standard [50]. This second edition of AP203 offers a modular approach to ISO 10303 AP 

development. The intent is to eliminate the proliferation of APs that are creating “islands of 

APs,” and move more toward a plug-and-play integration where users could choose from a set 

of capabilities to satisfy their product data exchange needs. 

 

Figure 6: ISO/CD AP203 edition 2 (source: [51]) 

Based on experiences gained through early development and implementation of other STEP 

APs, some of the high-level industry requirements that were identified for future APs were to: 

• Reduce the high cost and lengthy time to develop an AP. 

• Allow implementation of a combination of multiple APs or extension of AP 

implementations with additional capabilities. 

• Enable application software reuse. 
24

• Eliminate duplication and repeated documentation of the same requirements in different 

APs. 

• Reuse data generated by an implementation of one or more APs, by an implementation 

of one or more different APs (AP interoperability) [52]. 

Figure 6 shows the current functional coverage of ISO/CD 10303-203E2, which includes: the 

original international standard 10303-203, what was added in the approved technical 

specification (ISO/TS 10303-203E2), and what is being added to the specification before ISO 

distributes to its member countries for a draft international standard ballot. The primary focus 

of AP203 Edition 2 is tracking and managing the product. It defines the context, scope, and 

information requirements for the exchange of 3D designs of mechanical parts and assemblies in 

a configuration-controlled manner. While still a technical specification, several vendors have 

committed to building tools to handle importing or exporting geometry (solids, open shells, 

curve wire surfaces, facets, and wireframes), colors and layers, and annotation [46]. Boeing is 

using STEP AP203 Edition 2 for long-term data retention in development for its 787 and C-17 

programs. 

2) AP214 Core data for automotive mechanical design processes 

This AP is targeted at the automotive mechanical design processes; it covers the product and 

resource data of development process chains. It was approved and published as an ISO standard 

in 2001. This AP is the result of 7 years of work on which most of the automotive 

manufacturers have contributed through manufacturers’ associations such as GALIA for 

France, VDA for Germany, Odette Sweden for Sweden, JAMA for Japan, and AIAG for 

United-States. (A copy of this memorandum of understanding can be found at [53].) Figure 7 

shows the scope of AP214 classified in six categories including geometry, presentation, 

analysis, manufacturing specification and configuration, and technology data. 

From the product structure point of view, AP214 covers the product definition data (part, 

assembly, shape) and configuration control data pertaining to the design phase of a product's 

development. The notion of product includes parts, assemblies of parts (with tolerances and 

kinematics), tools, and assemblies of tools. The tools include those specific to the product 

produced and used by various manufacturing technologies. Shape information includes data 

that pertains to the form features’ representation of the shape of the whole product, as well as 

its parts. This AP extends the five types of shape representation of AP203 to include eight types 

of representation (2D-wireframe, 3D-wireframe, geometrically bounded surface, topologically 

bounded surface, faceted-boundary—known as faceted boundary representation (B-Rep), BRep, compound shape, and constructive solid geometry—known as CSG). Hybrid geometry 

representations for parts and tools defined as a mixture of these types are also possible. Another 

major contribution of this AP is its coverage of the notion of form-features, which allows the 

use design and manufacturing features for product descriptions. Change management is 

captured through the tracking of the versions of a product and data related to the documentation 

of the change process, and the management of alternate representations of parts and tools 

during the design phase. 
25

Figure 7: The scope of AP214 (source: [54]) 

From the processes side, the AP covers process planning information to manage the 

relationships among parts and the tools used to manufacture them. It also manages the 

relationships between intermediate stages of parts or tools, referred to as in-process parts. 

Supported processes include product definition, styling, design, prototyping, production 

planning, tool design, tool production, and quality control. 

From the resources point of view the AP covers product documentation represented by explicit 

and associative draughting; references to product documentation represented in a form or 

format other than that specified by ISO 10303; and organizational and administrative data that 

allow the identification of persons, responsibilities, approvals, suppliers, and contracts. 

Although the shape representation was enhanced by this AP compared to AP203, it is still not 

possible to have a general parametric representation of the shape of the part or tool. The AP 

does not cover any product data that is not related to the design phase, the financial data for the 

management of a design project, or the data that describes the pneumatic, hydraulic, electric, 

or electronic functions of a product. The capture of data for continuous kinematics simulations 

over time and for describing the input or output of finite element analysis are also outside the 

scope of this AP. 

AP214 has a set of 20 conformance classes that cover essentially the entire spectrum of 

automotive design. Each CC is specialized in some particular sub-domain. CC 1 to 5 are 

dedicated for CAD/CAM applications, CC 6 to 10 for product structure and configuration 

management, CC 11 to 13 for process planning, CC 14 and 15 for feature based design, CC 16 
26

and 17 for simulation and quality control, CC 18 and 19 for configuration control of process 

planning with 3D digital mockup data exchange and sharing, and CC 20 for complete data 

storage and retrieval. According to [45], most vendors who claim to have an AP214 translator 

have only implemented CC1 and/or CC2 that are essentially identical to AP203 

geometry/topology with a somewhat different set of configuration management data. 

AP214 is recognized as the basis for a number of data exchange tools and product data 

management (PDM) systems as it also comes with a data model that covers a large number of 

sub-domains. This data model captures various types of data related to design activity and 

relevant to these PDM systems. Reference [52] states the Defense Logistic Agency’s interest in 

looking at using AP214 data for mechanical system spares acquisition; and the Naval Sea 

Systems Command intends to use AP214 as a migration strategy to overcome technical, 

contractual, and cultural resistance. Also, the Joint Engineering Data Management Information 

Control System (JEDMICS) (described in Appendix B) is looking at AP214 data storage for 

mechanical systems, and is preparing to accept AP214 3-D data for long-term DoD support. 

Daimler-Chrysler is using AP214, CC8 for exchanging BOM data [55]. The EADS Military 

Air Systems has decided to use AP214 for archiving their construction data on the Eurofighter 

project [56]. 

 

3) AP224 Mechanical product definition for process planning using machining features 

This AP includes information needed to manufacture and assemble a machined part. In addition 

to part geometry (shape, dimension and tolerance) information, AP224 captures part features, 

material, surface finish, and other notational information needed in manufacturing. In AP224, 

the product definition includes the representation of the product shape, the definition of the 

machining features, and the initial shape of the material before machining. Figure 8 shows the 

scope of AP224 categorized into six application areas: machining features, measurement 

limitations, part administration data, manufacturing part properties, feature definition items & 

profile, and shape representation. The first two editions of this AP were approved as 

international standards in 1999 and 2001. 

AP224 Edition 2 extended the scope of the first edition to address the representation of 

manufactured assemblies, so the content of the new AP224 is expanded to include a new set of 

machining features (cutout, recess, rib top, and shape profile). Several already existing 

machining features (planar face, n-gon profile, n-gon base shape, and the addition of a 

rectangular boss subtype) were enhanced. This edition allows the grouping of features. 

Features, dimensions, and tolerances are harmonized with AP214. The third edition of AP224 

will expand the scope of this AP to include Gears. 

AP224 covers information regarding product definition (for a single mechanical part 

manufactured by machining processes), and information regarding machining features and 

processes (products that are to be manufactured by either milling or turning processes. 

machining features for defining shapes necessary for manufacturing, and machining features 

definition items necessary for creating machining form features). AP224 tracks a large set of 

administrative data (needed to identify requirements and track the status of materials and 

equipment needed to manufacture a part; customer order data to track receipt of an order for a 

part to the shop floor, but not including tracking of the order on the shop floor; and approval 

data to authorize the manufacture of a part). Data for the tracking of the state of raw stock for 
27

documenting the manufacturing history of a part and the tracking of design exception notice of 

a part are also within the scope of this AP. 

Figure 8: The scope of AP224 (source: [57]) 

The scope of AP224 does not cover data resulting from process planning. Information 

regarding design features of a part, schedule for completing a work order through the 

manufacturing process, configuration control, and various representations (assemblies, 

composite and sheet material parts, part pedigree) are also not covered. 

AP224 has a single conformance class: feature-based process planning and shape represented 

by advanced B-Rep. AP224 is tailored for downstream manufacturing; it is used in the designto-manufacturing phase as it provides a computer-interpretable data that can be re-used. It is 

also used for the exchange of design and manufacturing analysis data between CAD systems. A 

set of reports about AP224 implementations can be found in [58]. Interested readers can refer to 

[59] for an example of a STEP AP224-based design and manufacturing evaluation system. The 

Army has invested heavily in the development of this standard and pilots that emerged from 

this standard. AP224 was developed and implemented as part of the Rapid Acquisition Of 

Manufactured Parts (RAMP) Project (described in Appendix B) that has been in existence since 

1986, to address standards-driven applications for the manufacture of mechanical and electrical 

parts and assemblies. Standards-driven applications were developed in an R&D environment 

and put into production at DoD Depots and several commercial sites. 

While the STEP manufacturing suite comprised of a set of manufacturing related APs (AP203, 

AP219 [38], AP223 [60], AP224, AP238 [61], AP240) has tremendous potential to reduce 
28

manufacturing costs and lead times at the Army depots, challenges remain that need to be 

addressed before adopting these application protocols for use in a production manufacturing 

environment. It is in the Army’s interest that an integrated process oriented approach be 

adopted to better leverage the capabilities of these standards. 

4) AP233 Systems engineering data representation 

AP233 is targeted to support the needs of the systems engineering community. It provides 

neutral data models as communications pipelines to exchange and integrate information 

between systems engineering tools. It is built from a set of reusable information model 

“modules” for compatibility across application domains. This AP was registered as Publicly 

Available Specification (PAS) 20542 within ISO TC184/SC4, but its standardization process is 

not yet finished, its publication as an international standard is planned for January 2008. 

However, even though not yet an ISO standard, a large number of applications and tools have 

already implemented some parts of this AP. For more information on AP233 please refer to 

[45; 62; 63]. This AP is structured around a set of modules as shown in Figure 9. These 

modules cover the following functionalities: requirements, structural models, behavioral 

models, validation and verification, data representation, risk analysis, analysis interfaces, 

scheduling, cost models, organizational structure, PDM, security, and rules. Some of these 

modules are still under development. 

 

Figure 9: Modules of AP233 (source: [64]) 

This AP looks at systems engineering data from discipline views as well as from the data type 

point of view. Discipline views focus on the definition of other systems the system interacts 

with; the context for the system in each lifecycle phase; the support of hierarchical break down 

and object-oriented modeling techniques, the functional and non-functional requirements of the 

system in each lifecycle phase, the definition of the static and dynamic behavior of the system. 

From the data type point of view, the following types of data are within the scope of this AP: 

requirements 

text-based 

property-based 

breakdowns

static

structure

PDM 

analysis rules behaviour 

product 

structure 

system

sub-system

functional

breakdown

verification &

validation

state-based 

function-based 

model presentation

config

control

security 

risk measuremen

person &

org 

WBS 

(Schedule)
29

data to describe the system, its requirements, and its static and dynamic behaviors; data to 

support the physical architecture, the partitioning of the system, and configuration 

management; data to support the verification and validation of the system; and data to support 

project and industrial management; 

AP233 does not cover the following lifecycle stages: support the feasibility assessment of the 

system; domain engineering; realization, operation, maintenance, and decommissioning of the 

system. Also, the following types of data are outside the scope of this part of ISO 10303: data 

used solely in the domain engineering; and data used solely in the lifecycle stages feasibility 

assessment, realization, operation, maintenance and decommissioning of the system. AP233 

provides a set of 25 conformance classes noted CC-A through CC-G, and CC1 through CC19. 

As an example of the options covered by these CCs, here is the specialization of the first set: 

CC-A for Administrative information; CC-B for Work management; CC-C for Change 

management; CC-D for Document reference; CC-E for Element classification; CC-F 

for Element prioritization; CC-G for Graphics. For a full description of all CCs we refer 

interested readers to [65]. 

AP233 is well integrated with other existing standards. It uses DODAF to classify the different 

views on a system, Systems Engineering Modeling Language (SysML) to represent the 

information in each view [66], and AP233 to exchange data between DODAF, SysML, and 

legacy tools. Industries that can benefit from using AP233 are automotive, aerospace, 

shipbuilding, process planning (e.g., petroleum), electronics, and others with complex products 

and processes. Some industries have already started implementing or incorporating AP233 

modules in their applications: AP233 was used by UGS to update customer requirement data 

for the transition from TeamCenter v4 to v5 [67], Telelogic integrated recent AP233 modules 

in their requirement management applications [68]. Eurostep has also implemented a number of 

AP233 modules in Share-A-space [63; 69]. ThreeSL Cradle included an AP233 demonstration 

tool on a distribution CD to enable customers to move requirements data between formats [70]. 

PTC developed a prototype implementation driving parametric models from AP233 propertybased requirements [71]. AP233 interfaces have also been developed to a number of different 

tools: DOORSTM from Telelogic [68], SlateTM from EDS [72], CradleTM from 3SL [73], CoreTM 

from Vitech [74], Requisite ProTM from IBM-Rational [75], StateMateTM from iLogix (as part 

of SEDRES project) [76], Software Through PicturesTM from AONIX (as part of SEDRES 

project) [77]. 

DoD Open System Joint Task Force [78], INCOSE [79], BAE Systems [80], NASA [81], and 

the UK MOD [82] are supporting the development of more and more AP233 interfaces with 

many other systems. More information regarding AP233 implementations can be found in [40; 

64; 66; 82-84]. 

5) AP239 Product Life Cycle Support 

ISO 10303-239 (AP239) became an international standard in 2005. The development of 

AP239, also known as Product Life Cycle Support (PLCS) 14, has been motivated by the 

growing need to keep the information required to operate and maintain a product aligned with 

the changing product over its lifecycle. PLCS grew out of work on the NATO CALS 

 

14 We use AP239, ISO 10303-239, and PLCS interchangeably throughout this report. 
30

(Appendix B) project in the late 1990s and a growing recognition by industry that ISO 10303 

could be extended from its current applications in the concept, design, and manufacture of 

products where it is already in use. In [84], the authors describe the PLCS startup initiative as, 

PLCS, Inc. was an international consortium established to develop an ISO standard (ISO 

10303-239). The consortium comprised: US Department of Defense, UK Ministry of Defence, 

Finnish Defence Forces, Norwegian Ministry of Defence, FMV (Swedish Ministry of defence), 

DNV, Boeing, BAE SYSTEMS, Rolls Royce, Lockheed Martin, SAAB, Hagglunds Vehicles, 

BAAN, LSC, PTC, Aerosystems International, Pennant. Eurostep Limited provided the 

technical leadership and program management for the consortia. 

Although STEP is adopted by many for information exchange in the early phases of equipment 

life, it needed to be more robust to embrace the in-service and disposal lifecycle phases. PLCS 

provides a significant aspect of this coverage. PLCS has its roots firmly in the standards that 

have evolved over the past decade or so. It specifies an information model to represent support 

of a product throughout its lifecycle, and a mechanism to maintain the information needed to 

support complex products, systems, and assets. This information model is represented by 

using the EXPRESS information modeling language. AP239 defines an extension to the 

capabilities of AP203, AP214, and the Product Data Management (PDM) Schema and Modules 

[85], to define the requirements for Configuration Management over the complete product life. 

AP239 also addresses the information requirements needed to define and deliver lifecycle 

support for complex assets. 

The following functionality is enabled by the standard: 

• Activity Management - Functionality to request, define, justify, approve, schedule, and 

capture feedback on activities (work) and related resources. 

• Product Definition - Functionality to define product requirements and their 

configuration, including relationships between parts and assemblies in multiple product 

structures (as-designed, as-built, as-maintained). 

• Operational Feedback - Functionality that describes and captures feedback on product 

properties, operating states, behavior and usage. 

• Support Solution and Environment - Functionality to define and maintain the necessary 

support solution for a product in a specified environment including the opportunity to 

provide support (scheduled downtime), tasks, facilities, special tools and equipment, 

and personnel knowledge and skills required. PLCS will also relate organizations, 

personnel, and facilities with the product needing support. 

As part of the ISO STEP series of standards, AP239 defines an application-specific, but flexible 

and extensible, information model. The information model can be modified by specific industry 

and organizations through the use of Reference Data Libraries (RDL). The role of RDL is to 

complete the semantics of the PLCS model necessary for implementation in a specific industry. 

The benefit of AP239 is its integrated view. It has a large and generic information model that is 

larger in scope than most business processes require or most IT applications can manage; 

therefore, it allows better flexibility. AP239 handles scoping for specific IT applications by 

defining Data EXchange Sets (DEXs). 
31

PLCS DEXs: 

A DEX provides a way of extracting the PLCS information model into sections suited for a 

specific business process. A DEX provides a subset of the PLCS information model and usage 

guidance. A DEX can be used to contract against, or for setting conformance to, but AP239 

implementations do not have to use DEXs. While AP239 was published as an ISO standard in 

2005, the DEXs are initially being standardized by publishing the subset of ISO 10303-239 and 

associated usage guidance material as OASIS standards [86]. Conformance classes in AP239 

are different in concept from those of earlier APs, in the sense that AP239 provides one single 

CC called “CC1: Product Life Cycle Support,” but includes extensively used DEXs as CCs. 

The DEX architecture is shown in the following figure. 

Figure 10: DEX architecture (source: [86])

The PLCS DEXs can be used to: 

• Automate the process of populating one single Lifecycle PDM system. 

• Automate an ongoing exchange of data between different IT systems that are PLCS 

compliant and share the same information management rules. 

• Demonstrate compliance of a software application to an agreed set of information 

management rules, based on the PLCS standard. 

Each DEX consists of a scope and the business process and description of the business process 

that the DEX is supporting. It also includes identification of the process in the AP239 activity 

model supported, usage guidance for the model, DEX-specific Reference Data, and the subset 

of the Information model supported by the DEX. The DEX will contain the EXPRESS 

information model and XML Schema (derived from the EXPRESS). The following are the 

initial set of OASIS DEX specifications: 

• D001 - Product Breakdown for support: Exchange of the relationship of the parts 

assembly structure, derived from a PDM system, to an LSI/LCN structure used to 

manage support, and the links to relevant documents 

PLCS 

Ref data 

Business 

specific 

ref. data 

Capability

(Usage guide)

Business

specific

concepts

DEX

Exchange 

contract

ConformanceClass

How to 

represent

Whatto 

represent

Based on
32

• D002 - Faults related to product structures: Exchanges the output from Fault Analysis 

programs in a form that can be used to identify required diagnostic and maintenance 

tasks, and to provide coherent fault reporting 

• D003 - Task Set: Exchange of a set of task descriptions, to support a work plan, or for 

use in multiple support solution definition. 

• D004 - Work Package Definition: Exchange and negotiation of a work package for a 

specific support opportunity including the list of required tasks, location, dates, products 

and resources. 

• D005 - Maintenance plan: Exchange for defining and communicating the work required 

to sustain a product over time including the results of any Logistic Support Analysis. 

• D007 - Operational Feedback: The exchange of the observed configuration, location, 

state or properties of an actual product, and the communication of work requests to 

resolve issues arising from feedback on its usage 

• D008 - Product as Individual: Exchange and collation of manufacturing and serialised 

part information and its relationship to the product assembly structure from which it 

derived. 

• D009 - Work Package Report: The exchange to support the reporting of work 

completion against a work package definition. 

• D010 - System requirements: The exchange of requirements information related to a 

system. 

There are a number of parts of the PLCS model that will be common to many DEXs. (e.g., date 

and time). Rather than each DEX replicating the usage guidance for these, they are packaged 

into chapters called "Capabilities" that are reused across different DEXs. 

PLCS Capabilities: 

The Capabilities are the building blocks from which a DEX is constructed [87]. DEXlib, owned 

and managed by OASIS, is the development environment used to develop the PLCS DEX 

(Data Exchange Sets). It contains up to date versions of all the PLCS DEXs and their 

constituent components. 

Capabilities perform a similar function to STEP application protocols’ modules although there 

is no one-to-one correspondence. They are used to accelerate DEX development and to avoid 

different interpretations of equivalent concepts in different DEXs. Each Capability contains: an 

introduction, explaining the nature and purpose of the Capability; a business overview; a 

description of the information model used by the Capability, with examples of its use; and a 

full specification of the information model used by the Capability, derived from the relevant 

AP239 implementation module. 

A Capability is a portion of the PLCS data model that is reused in instantiations of the data 

model. A Capability is independent of business context and domain of the instantiations. 

Reusability is solely based on the structural similarity of the instantiations; a Capability 

consists of a fixed set of entities, relationships, and internal, fixed-value attributes. A Capability 

may be regarded as a macro-entity with a set of parameters. Its purpose is not in data modeling, 

but in describing typical instantiations of a portion of a data model. 
33

Capabilities ensure a common interpretation of PLCS, avoid multiple dialects of PLCS, reduce 

the amount of documentation for the PLCS usage guide, and simplify instantiation of the PLCS 

data model. 

Reference Data: 

Reference Data is defined to be lifecycle data that represents information about classes or 

individuals which are common to many facilities, or of interest to many users. A Reference 

Data Library (RDL) is a managed collection of reference data. Reference Data is a key success 

factor for consistent sharing and integration of data, i.e., to ensure the consistent meaning of 

data. The reference data add semantics to the AP239 model. 

• PLCS Reference Data: The standardized PLCS Reference Data is created and published 

using the W3C Web Ontology Language called OWL [88], which became a W3C 

Recommendation in February 2004. While OWL may have any of several formats, the 

OWL XML syntax is used for the PLCS Reference Data. This allows the use of XMLrelated languages and tools for the creation and management of the Reference Data. 

• Business-specific Reference Rata: These reference data are business specific and will 

not be subject for standardization through OASIS. 

The overall PLCS information model, DEX, and RDL is shown in Figure 11. The numbers in 

brackets denote the number of PLCS architecture elements available. For example, there are 20 

DEXs, approved or in-progress, available from OASIS as of today. 

DEX, Capability, Business concept, and PLCS RDL in the DEX architecture are subjects for 

standardization. The standardization of Reference Data may take place before, during, or after 

the development of the data model (or application) which uses it. Applications using the same 

data model but with different Reference Data will not interoperate until the two sets of 

Reference Data have been harmonized or mapped. The ISO community has a good procedure 

for Reference Data management but no business model to support its implementation. 

The US Army TACOM is working with General Dynamics Land Systems in its Abrams 

Unique Identification project, to set up a process to access the BOM information using AP239. 

The United Kingdom Ministry of Defence (UK MoD) is mapping PLCS into their UMMS 

(Unit Maintenance Management System. The work they have completed to date: 

• Mapping of the existing UMMS export data set to the AP239 data model 

• Development of an XML-based architecture to implement an AP239 compliant 

exchange 

• Embedding the new PLCS capability into the UMMS application 

• Building matching PLCS capability into the Devonport Dockyard ERP System (PEPS ) 
34

OASIS

ISO

DEXs Capabilities (20)

(131)

Exchange file

Using

Basis

for

Controls

Modules

(135 PLCS) Building

blocks

Using

RDLs

(>1)

Business Rules (terms, agreements, traditions, etc)

Business

Concepts

specifies

uses

(subset) specifies

Exchange

Agreement

Exchange

Agreement

According to

Restricts

Access to

Usage guide

specifies

OASIS

ISO

DEXs Capabilities (20)

(131)

Exchange file

Using

Basis

for

Controls

Modules

(135 PLCS) Building

blocks

Using

RDLs

(>1)

Business Rules (terms, agreements, traditions, etc)

Business

Concepts

specifies

uses

(subset) specifies

Exchange

Agreement

Exchange

Agreement

According to

Restricts

Access to

Usage guide

specifies

Figure 11: From information model to exchange (source: [63])

The UK MoD work still in progress on this mapping: 

• Developing a Reference Data Library and RDL Service in support of the exchange 

• Revising the existing mapping to reflect the newly developed Work Package Definition 

Data Exchange Specification (DEX 4) 

• Developing an architecture to implement the PLCS DEX and RDL compliant revised 

interface [89]. 

Lockheed Martin has a pilot implementation plan for adopting PLCS on the F-35 program 

beginning in 2006. EPM has initiated pilots with Aerospace and Defense organizations to 

measure the value of using STEP for Long Term Data Retention and Product Life Cycle 

Support [37]. 

6) AP240 Process plans for machined parts 

ISO 10303-240 [90], which was approved as an international standard in 2005, complements 

the missing link between design and manufacturing in machinery manufacturing. With design 

based on 3-D CAD systems becoming popular, ISO 10303-203 and ISO 10303-214 are being 

implemented. In addition, the CNC data model now being developed at ISO TC 184/SC 1 is 

also moving toward practical use. With the international standardization of ISO 10303-240, the 

entire flow from design through manufacturing will become seamlessly linked, making possible 

the development of an innovative design-manufacturing process. Figure 12 highlights the 

functional capabilities of AP240. 
35

Figure 12: AP240 (source: [91]) 

With this standard, design and manufacturing-system information without drawings will 

become available for sharing. In addition, a mechanism for improved reuse of the data can be 

created. This means that a mechanism can be created for keeping in storage production-floor 

expertise that cannot be stored in existing information systems. ISO 10303-240 is expected to 

enable the communication of information concerning work results of process design, which 

requires mostly processing expertise, so that the evolution of machine processing itself can be 

promoted to lay the foundation of new machinery manufacturing. 

SCRA and the Army have conducted demonstration pilots using AP240 in the N-STEP project, 

and have shown a reduction in process planning lead-time for machined parts and assemblies. 

4.2.2 GEIA-927 Common data schema for complex systems 

The Government Electronics & Information Technology Association (GEIA) [92] is an ANSIaccredited standards development organization that focuses on supporting its electronic and IT 

membership. One of the many standards GEIA has developed is GEIA-927, “Common Data 

Schema for Complex Systems.” GEIA-927 became a standard in 2006, and is now in 

continuous maintenance. The standardization activity has been a collaborative effort 

supported and funded by DoD [93; 94]. The GEIA-927 working group consisted of 

representatives from industry (e.g., Lockheed Martin, Raytheon), universities (e.g., Johns 

Hopkins University) and the Army. The primary aim of this project is to provide a unified 

schema that integrates the best available schemas for data representation for modern complex 
36

systems. The GEIA-927 is intended to be a key enabler for product data representation and 

exchange within complex systems. 

The elaboration of GEIA-927 started by choosing ISO 15926, Integration of lifecycle data for 

oil and gas production facilities [95], as the basic building block on which a set of other 

standards is integrated. 

Figure 13 shows the order in which these standards are added one after the other to constitute 

GEIA-927. Data models from PAS20542 (ISO/CD 10303-233, Systems engineering data 

representation) [96], AP212 (ISO 10303-212 electrotechnical design and automation) [97], and 

AP239 have been integrated [98]. The most recent version of GEIA-927 passed ballot in April 

2006; other APs will be integrated in the next version of the standard. 

 

Figure 13: Initial components of the GEIA-927 standard 

GEIA-927 addresses product data exchange and sharing across the entire product lifecycle 

within a complex system from viewpoints of multiple disciplines such as functional and nonfunctional requirements of the system, definition of static and dynamic behavior of the system, 

and the context of the system in each lifecycle phase. Lifecycle phases included in the scope of 

GEIA-927 are system engineering, feasibility assessment, requirement definition, domain 

engineering, system realization, system operation, system support, system maintenance, and the 

decommissioning of the system. 

Although a large spectrum of data types may be needed to cover all the product lifecycle 

phases, the data types included within the scope of the standard should “at least theoretically” 

be sufficient to represent the full range of information generated and treated during the entire 

product lifecycle. Among these various data types we have: data to describe the system, data to 

specify the requirements of the system and their allocation to functional object, physical objects 

and physical implementation, data to specify the dynamic behavior of the system, data to 

describe the functional decomposition of the system, and data to support the physical 

architecture of the system. Such types of data allow the analysis of requirement/function/form 

mapping and function/behavior studies --- two very useful operations for complex systems. 

GEIA-927 is organized into a set of functional views: functional/system/physical architectures, 

activity, common, documentation, product, product lifecycle, requirement, property, logistics, 

and effectivity views.. Each view is structured around a set of key entities. Functionally 

important entities are shared between multiple views. Structures which are useful to all other 

views are grouped within the Common view. The physical description of a product/system is 

ISO 15926

ISO 10303:PAS20542

ISO 10303: AP212

ISO 10303: AP239

ISO 15926 GEIA-927

ISO 10303:PAS20542

ISO 10303: AP212

ISO 10303: AP239

GEIA-927
37

defined in the Physical Architecture view. The structure of the product is represented by the 

Product view; this view may be seen as a limited version of the Physical Architecture view in 

which versioning information is added. The functional description of a system/product is given 

by the Functional Architecture view. These three views (Product, Physical Architecture, and 

functional Architecture) can be used together to provide a complete representation of a system 

or product. 

As recently as January 2006, a second standard, GEIA-927-1, focused on logistics product data, 

and was still intended to be an accompanying standard to GEIA-927. GEIA-927-1 in its initial 

drafts included an implementation model of the LSAR Data, LSAR XML Schema, LSAR Data 

Definitions, implementation element mappings to GEIA-927 [94]. GEIA-927-1 has since been 

evolved into an independent standard under development, called GEIA-0007, “Logistics data 

implementation model.” GEIA-0007 defines logistics product data generated during the design 

of a system, end item, or product; and provides data exchange mechanisms as it is shown in 

Figure 14. The purpose of GEIA-0007 is to provide an industry standard for acquisition and 

exchange of logistics product data by industry and DoD, re-establishing industry and DoD’s 

ability to exchange LSAR. GEIA-0007 represents a DoD business DEX, and the Army hopes to 

work with OASIS to incorporate GEIA-STD-0007 logistics data into the appropriate DEXs (1-

5), and create new DEXs where gaps exist. The Army Logistics Support Activity (LOGSA) is 

a voting member of OASIS. [94] GEIA-0007 is currently under development and is anticipated 

to be accepted as a standard within this calendar year. 

4.2.3 ANSI/EIA-649 National consensus standard for configuration 

management 

ANSI/Electronic Industries Alliance (EIA) Standard 649 (EIA-649) was last published April 1, 

2004 as ANSI/EIA-649-A. The purpose of ANSI/EIA-649 is to provide Configuration 

Management (CM) principles that are applicable to a broad range of industries [99]. The 

standard describes CM functions and principles and defines a neutral CM terminology for use 

with any product line. Among the described CM functions there are: CM planning, 

configuration identification, configuration change management (change control), configuration 

status accounting, and configuration verification. 

ANSI/EIA-649 was issued in 1998 to replace MIL-STD-973, and was adopted in 1999 for use 

by the Department of Defense (DoD). To facilitate the implementation of this standard, a 

handbook (HB-649, “Implementation Guide for Configuration Management”) was released in 

2005 [100]. It provides implementation guidance for: 

• Tailoring to fit various applications regardless of industry 

• Preparation of CM plans 

• Evaluation of CM systems 

• Creating CM Metrics 

• Demonstrating compliance with principles 
38

Figure 14: Types of logistics product data generated during design (source: [101]) 

A few companies have software application implementations for ANSI/EIA-649: 

• InSync’s integrated support systems (ISS) provides support for legacy and current CM 

standards such as MIL-STD-973, MIL-STD-2549, and ANSI/EIA-649 [102]. 

• PTC Windchill’s Aerospace & Defense Module and Windchill PDMLink Enhanced 

compliance with configuration management standards ANSI/EIA-649, MIL-HDBK61A and CMII [103]. 

4.2.4 ANSI/EIA-836 Configuration management data exchange and 

interoperability 

The Government Electronics & Information Technology Association (GEIA) launched (in the 

year 2000) a standardization project, in partnership with the DoD and several industry 

participants, to develop a new configuration management (CM) data exchange and 

interoperability standard. The proposed ANSI/EIA-836 standard includes a CM data element 

dictionary and reference schema, and a set of XML schemas and XML document templates for 

CM business objects. The standard has a configuration management focus, specifically with 

respect to the transfer of controlled information and data required to perform CM functions 

throughout a product's life cycle. It provides fundamental reference information to facilitate 
39

CM data exchange and interoperability regardless of specific data encoding and transport 

methods. 

The level of interoperability between dissimilar systems is determined by trading partner 

agreement. XML [104] is used to facilitate data sharing and exchange among different systems. 

Some key characteristics of EIA-836 include: 

• It embodies a data dictionary that lets all participants speak a common CM language. 

The data dictionary contains the complete set of technically credible CM data element 

definitions [105]. It supplies a fundamental reference vocabulary for access, sharing and 

exchange of CM data, and for developing CM data management tools, databases, and 

systems. 

• It applies the principles in ANSI/EIA-649, but does not dictate how to practice CM in 

any given organization. A set of rules is established for the mapping of the content of 

EIA-836 to the underlying principles in ANSI/EIA-649. 

• It embraces Web-based communications technology in the form of eXtensible Markup 

Language (XML), which allows the exchange of data across diverse hardware, 

operating systems, platforms, languages, and applications. 

• It facilitates interoperability regardless of specific schema or specific method of data 

transfer. 

Figure 15 from [106] shows that the main focus of EIA-836 is on data element definitions, 

relationships, and business objects for product information exchange. Templates are created 

and provided for exchange of CM business objects. As in ANSI/EIA-649, a product is any item 

including any of the generic categories of hardware, software, document, processes, data, 

materials, or services. 

EIA-836 provides

CM data element 

definitions and 

relationships

Data Exchange Elements

Business Process

Business Objects

Transport Mechanism

Data Elements

EIA-836

Focus

EIA-836 supports the 

business process defined 

in ANSI/EIA-649

EIA-836 defines

templates for CM 

business objects to

be exchanged

EIA-836 is data 

transport 

technology and 

database neutral

EIA-836 provides

CM data element 

definitions and 

relationships

Data Exchange Elements

Business Process

Business Objects

Transport Mechanism

Data Elements

EIA-836

Focus

EIA-836 supports the 

business process defined 

in ANSI/EIA-649

EIA-836 defines

templates for CM 

business objects to

be exchanged

EIA-836 is data 

transport 

technology and 

database neutral

Figure 15: EIA-836 focuses on data elements and business objects 

Information such as product definition geometry, topology, tolerances, features, specification 

requirements, and process description details are considered out of the scope of the EIA-836 

standard. For these types of information one can use other standards such as ISO 10303 [33], 

ASME Y14.5 [107], ISO 1101 [108], and ASME Y14.41 [109]. EIA-836 provides a 
40

comprehensive reference vocabulary [106]. It includes definitions of all CM data elements and 

attributes considered to be within the CM domain that address: 

• Product identification and relationships 

• Configuration identification 

• Configuration change management 

• Configuration status accounting 

• Configuration verification and audit 

• Data and document management 

The content and structure of EIA-836 business objects can be used as defined in the standard or 

modified to be tailored to suit specific partner situations or domains. Additional business 

objects may also be created. The data element schemas may also be adapted or extended to 

capture new business rules and definitions. To obtain tailored views of CM data, XML style 

sheets need to be developed by the standard’s users and used to visualize their CM data and 

business objects. EIA-836 has been designed to be used within networked environments, 

through Internet, WWW, and related information technologies and e-business frameworks such 

as XML and ebXML – electronic business XML [100]. 

According to the EIA-836 reference document [106], the standard supports the PLCS activity 

data models and complements ISO 10303, STEP application protocols so that data may be 

exchanged with users of these standards. 

The initial release of EIA-836 was published 15 June 2002. Revisions are ongoing as the 

development of EIA-836 continues to be a collaborative project involving the GEIA G-33 

(Configuration and Data Management) Committee, DoD, the ManTech Enterprise Integration 

Center in Fairmont, WV (under the guidance of the Systems, Standards and Technology 

Council (SSTC), and an Oversight Group providing advisory partnerships with other 

associations such as the Aerospace Industries Association). To harmonize related efforts the 

EIA-836 team plans to collaborate with other e-business initiatives including STEP (ISO 

10303), the Product Life Cycle Support (PLCS) Program, and the Aerospace Industries 

Association Electronic Enterprise Working Group. While EIA-836 appears to be a thorough 

and good start for managing configuration data within the Army, its developmental effort 

within an industry standards development organization appears to be primarily funded by the 

Army for the Army. By the publication time of this report, we were unable to find any 

examples of EIA-836 software tools development to support its use. 

4.2.5 MIMOSA Open Operations & Maintenance (O&M) framework 

A joint effort by MIMOSA, OPC foundation, and ISA is underway to harmonize their 

standards and specifications and establish an architecture framework for operation and 

maintenance activities. The three organizations are collaborating to provide the standards and 

technology that form an interoperable framework for the exchange of O&M information. Such 

a single interface, called Open O&M [110], intends to enable easy integration of operations and 

maintenance systems through a free information exchange between applications across 

manufacturing, processes, and maintenance. 
41

From the organizational point of view, Open O&M is a virtual organization maintained by 

MIMOSA. From the technical point of view, the Open O&M framework is built around the 

following set of standards from the three participating organizations: 

• MIMOSA Open Systems Architecture for Enterprise Application Integration (OSAEAI) 

• MIMOSA Open Systems Architecture for Conditioned-Based Maintenance (OSACBM) 

• ISA-95 – Enterprise/Control System Interface Standard [111] 

• ISA-99 – Control System Cyber-Security Standard [111] 

• ISA-OMAC – Open Modular Architecture Controls group standardizing packaging 

machinery interfaces [111] 

• OPC interface specifications and data transport standards [112] 

Open Operations & Management Interface Specification

Periodic & Online

Condition

Monitoring Systems

MIMOSA OSA-EAI

Diagnostic /

Prognostic Asset

Health System

MIMOSA OSA-EAI

Enterprise Asset

Management

(EAM) Systems

(Asset Registry) &

Maintenance Work

Mgmt.

MIMOSA OSA-EAI

Asset Capability

Forecasting &

Asset Optimization

DSS

MIMOSA OSA-EAI

Physical Asset Resource Management Systems

Control Systems,

Operational Data

Historians & HMIs

OPC XML &

MIMOSA OSA-EAI

Operational

Forecasting, Planning

& Scheduling Systems

ISA-95, OPC XML &

MIMOSA OSA-EAI

Order/Mission Mgt.,

Raw Material Mgt.,

Personnel & Financial

Systems (ERP)

ISA-95

Open Operations & Management Interface Specification

Periodic & Online

Condition

Monitoring Systems

MIMOSA OSA-EAI

Diagnostic /

Prognostic Asset

Health System

MIMOSA OSA-EAI

Enterprise Asset

Management

(EAM) Systems

(Asset Registry) &

Maintenance Work

Mgmt.

MIMOSA OSA-EAI

Enterprise Asset

Management

(EAM) Systems

(Asset Registry) &

Maintenance Work

Mgmt.

MIMOSA OSA-EAI

Asset Capability

Forecasting &

Asset Optimization

DSS

MIMOSA OSA-EAI

Physical Asset Resource Management Systems

Control Systems,

Operational Data

Historians & HMIs

OPC XML &

MIMOSA OSA-EAI

Operational

Forecasting, Planning

& Scheduling Systems

ISA-95, OPC XML &

MIMOSA OSA-EAI

Order/Mission Mgt.,

Raw Material Mgt.,

Personnel & Financial

Systems (ERP)

ISA-95

Figure 16: OpenO&M framework reduces the number of interfaces (source: [110]) 

Figure 16 shows how the Open O&M framework is used as a single interface to reduce the 

number of interactions between O&M systems. Open O&M integrates MIMOSA’s OSA-EAI 

and OSA-CBM and the ISA-95 data exchange formats and utilizes the OPC interface 

specifications as the pipe to transport the information between systems. The client/server 

technology of OPC will be used to exchange OSA-EAI and ISA-95 format data. The use of 

OPC also enables the use of state of the art technologies such as web services and the ability to 

provide secure data exchange [110]. 

OSA-EAI implements Conditioned-Based Maintenance (CBM) and Conditioned-Based 

Operation (CBO) through a set of XML schemas to facilitate the exchange of critical 

maintenance information related to condition based monitoring, asset based registry, 

maintenance work & parts management, etc.

The ISA-95 standard supports vertical exchange of manufacturing data between business and 

control systems. The ISA-95 standard has been accepted by the IEC and ISO as the joint-logo 

international standard. In some literature, it is also referenced as ANSI/ISA-95.
42

For a given multi-manufacturing site enterprise, the Open O&M framework is an enabler for 

CBO and CBM and collaborative asset lifecycle management (CALM) strategies. The 

framework can also be used in a wider scale through to the entire enterprise supply chain and 

supporting infrastructure covering fleets, facilities, and manufacturing plants in both public and 

private sectors. 

Various vendors, such as ABB, Emerson Process Management, Invensys, Microsoft, 

PeopleSoft, Rockwell Automation, Yokogawa, and many others are supporting the idea of one 

single architecture. Open O&M is also attracting major end-users in the refining, utilities, and 

manufacturing industries as well as the military services [113]. The US Army Product Manager 

of the Test, Measurement, and Diagnostic Equipment program at Redstone Arsenal, AL, is a 

corporate member of MIMOSA. OpenO&M has been adopted by DoD (see Appendix D). 

British Petroleum (BP) in its project to integrate fourteen majority-owned BP refineries 

committed to using MIMOSA OpenO&M to connect maintenance, laboratory, document 

management, drawing management, and other remote database management systems [114]. 

4.2.6 ASD/AIA-S1000D International specification for technical 

publications utilising a Common Source DataBase 

S1000D is an international specification for technical publications developed by the European 

Association of Aerospace Industries (AECMA). It uses international standards such as the 

Standard Generalized Markup Language [115], XML, and Computer Graphics Metafile [116] 

for the production and use of electronic documentation. Implementations of S1000D should be 

able to handle a wide range of information types such as descriptive, procedural, maintenance 

schedules, fault isolation, and crew/operators. 

S1000D is organized in a modular approach based on the Common Source Data Base (CSDB) 

principle for data creation and storage. A data module is defined as a “self contained unit of 

data” and has two sections: one containing the data required by the user (the content section), 

the other containing all the metadata necessary to control the data module and its configuration 

(the identification and status section). A Data Module Code (DMC) is associated to each 

module and permits the use of a database to store and manage the complete information set. It 

also ensures that the information is not duplicated in the CSDB. Any shared information is 

stored only once as a single data module and used many times in different contexts. 

Two groups made up of representatives from France, Germany, Italy, Spain, Sweden, UK, and 

USA are responsible for the technical development (the Electronic Publication Working Group 

EPWG) and maintenance (the Technical Publication Specification Maintenance Group - 

TPSMG) of the specification. 

According to [117] the benefits of using the specification are: 

• It reduces maintenance costs for technical information. 

• It allows a subset of information to be generated to meet specific user need. 

• It can generate many different output forms from the same base data set, which ensures 

strong and efficient data configuration at the user interface level. 

• It allows neutral delivery and data management. 
43

The potential of S1000D to unify the large number of documentation approaches and delivery 

mechanisms is driving interest in this standard. Earlier use of S1000D in Europe could ease its 

adoption in the United-States through its NATO partners. 

According to [118], S1000D will soon be adopted by DoD as the new standard for US military 

documentation: “Unlike many European defense organizations, the Department of Defense 

hasn't officially signed up for the specification. But growing numbers of U.S. defense programs 

are using the specification, and there are a number of pilot projects in progress. Many believe it 

is only a matter of time before the DoD officially adopts S1000D. At the recent Aerospace 

Industries Association’s product support conference (May 13,2005), titled: Logistics 

Transformation, A Systems Approach. Jerry Beck of the Office of the Assistant Deputy Under 

Secretary of Defense, Logistics Plans & Programs emphatically stated that OSD will be 

adopting S1000D as the new standard for the US Military.” 

S1000D standard claims to offer many advantages. It reduces support costs, enables modularity 

and content reuse, makes it easy to share data across different computing platforms, and allows 

users to view electronic documentation via a common web browser or text viewer. However, 

one of the major S1000D challenges will be the task of converting legacy documentation. 

A number of tools that support authoring, publishing, viewing, and distributing manuals are 

already available through the European adoption of S1000D. Raytheon Missile Systems has 

incorporated S1000D implementation capabilities in its Non Line-Of-Sight-Land Systems 

(NLOS-LS) program. NLOS-LS is in development for the US Army by Netfires LLC, a joint 

venture between Raytheon and Lockheed Martin, under a $1 billion contract. NLOS-LS is 

anticipated to be a key element in the US Army Future Combat Systems (FCS) warfighting 

transformation concept [119]. General Dynamics Canada has also implemented S1000D [120]. 

 

5. An initial typology of information standards 

The proposed typology primarily reflects the content to be communicated and implies the 

appropriate expressiveness and language choices for each type of content. Within each type, 

individual standards may be classified as to origin, intent, development process and, to some 

extent, scope by the typologies listed below. This typology is based on the one initially 

presented in [121]. For illustration, we give some examples of standards in each type below, 

and a more thorough list of standards that may apply can be found in Appendix C. 

Type Zero: Standards for implementation languages 

These standardized languages include programming, scripting, assembly level and other 

computable languages used to implement the Type One, Type Two, and Type Three standards. 

Examples include: Basic, FORTRAN, C, C++, Java, C#, Prolog, Perl, Tcl/Tk, OpenGL. 

Type One: Information modeling standards 

Semantically rich modeling language standards, based on different forms of logic, include the 

Knowledge Interchange Format (KIF), OWL, and RDF that support reasoning over the 

information representing a content domain [88; 122; 123]. OWL includes the RDF/XML 
44

interchange syntax and has three sub-languages of different expressiveness and complexity 

(OWL Lite, OWL DL, OWL Full). All of these efforts are directed towards building formal 

ontologies that are expected to aid semantic interoperability. 

EXPRESS [124] and UML (Unified Modeling Language) are two examples of information 

modeling languages. EXPRESS is used in the STEP-based systems [125], while UML is based 

on the object-oriented methodology [126]. UML is primarily intended for specifying, 

visualizing, constructing, and documenting components of software systems as well as for 

business modeling and other non-software systems. The expressive power of EXPRESS is 

comparable to the combination of UML and the Object Constraint Language (OCL), a formal 

language used to describe expressions in UML models [127]. XML Schema is becoming 

popular for expressing the structure and typing constraints for data embedded in XML 

documents. XML Schema offers a higher level of expressiveness than the earlier XML DTD 

(Document Type Definition) descriptions. 

A NIST focus area is the standardization of the representation of manufacturing processes, 

called the Process Specification Language (PSL) [128]. Process data is used throughout the 

lifecycle of a product, from early indications of manufacturing process flagged during design; 

through process planning, validation, production scheduling and control. PSL uses first order 

logic and OWL-like representations [88]. 

Type Two: Content standards - domains of discourse 

Content standards pertain to information models specifically defined for particular domains 

using a generic information modeling language (Type One) or an extension of one (for 

example, UML with its extension, SysML). SysML is directed towards the specific domain of 

systems engineering. SysML is derived from the basic UML to cover the requirements, 

structure, behavior, parametrics, and the relation of structure to behavior (allocation) [129]. 

Content standards subdivide into several categories based on the specialization of the content 

addressed. To keep it in context further clarification on the typology, the principal categories 

are briefly described below. Content standards might use general Type Zero languages for 

implementation. Product information modeling and exchange standards are used to model the 

information necessary to support the product. Visualization standards are used to extract 

adapted views of the information. 

Product information modeling and exchange standards 

ISO 10303 deals with product structure and geometry and part-related information [33]. As we 

know STEP uses the EXPRESS information modeling language to define a generic product 

model. In the modular approach of STEP, information models form modules and integrated 

resources (IRs), from which specific content standards (application protocols or APs) are 

developed (for example, AP214 [130]). These specific content standards can use specific 

catalogs. As another example, UML and its extension SysML, can be used to define specific 

system (say, control system) standards. This hierarchy is illustrated in the following figure 

(The arrows represent “uses”). 
45

Figure 17: Examples of content standards 

AP239 is dedicated to product support and is based on an extension to the STEP PDM Schema 

capability [85]. PLCS provides mechanisms to maintain the information needed to support 

complex assets (such as ships, aircraft, or engines). PLCS builds upon the functionality defined 

by other standards relevant to product support.

Product visualization standards 

The U3D graphics standard is a simple format for interactive viewing and sharing of 3D data 

and is being standardized in ISO [131]. X3D is an XML-enabled 3D standard to enable realtime communication of 3D data [132]. JT is a CAD-neutral data format for product 

visualization, collaboration and data sharing [133]. JT Open is a library of Java classes 

supporting the client/server and Internet programming models. JT2Go is a JT format viewer. 

OpenGL (Open Graphics Library) is a low-level graphics library for 3D data visualization 

[134]. OpenML (Open Media Library) is a programming environment that supports the 

creation and playback of digital, audio, video and graphics [135]. 

Type Three: Architectural framework standards 

To achieve interoperability between the standards within the PLM context, it is imperative that 

the different types of standards described in this section be reconciled and made convergent. In 

integrating these types of standards, it is necessary to take into consideration the architectural 

frameworks for creating integrated support systems. A number of architecture framework 

standards have been proposed, such as the Zachman Framework [136], the Department of 

Defense Architecture Framework (DODAF) [137] and the Federal Enterprise Architecture 

Framework (FEAF) [138]. These frameworks do not yet provide the full spectrum of 

viewpoints needed to address the overall interoperability concerns. Another interesting 

framework is the ISO RM-ODP Reference Model for Open Distributed Processing [139]. This 

EXPRESS

Modules and IRs

Application 

protocol (AP) 

Catalog/repository 

UML 

SysML 

Control system design tool

standard Automotive design tool 

standard
46

model has been used as a framework for CORBA-based [140] distributed applications 

management, and defines five architectural viewpoints that address a wide range of 

interoperability concerns from policies and procedures to engineering solutions: the enterprise, 

information, computational, engineering, and technology viewpoints. 

The Department of Defense (DoD) Architecture Framework (DODAF), Version 1.0, defines a 

common approach for DoD architecture description development, presentation, and integration. 

The Framework enables architecture descriptions to be compared and related across 

organizational boundaries, including multinational boundaries. DODAF is the implementation 

chosen by DoD to gain compliance with the Clinger-Cohen Act and United States Office of 

Management and Budget Circulars A-11 and A-130. All major DoD weapons and information 

technology system procurements are required to develop an enterprise architecture and 

document that architecture using a number of predefined views. DODAF was formerly named 

C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and 

Reconnaissance). Other derivative frameworks based on DODAF include the NATO 

Architecture Framework (NAF) and Ministry of Defence (United Kingdom) Architecture 

Framework (MODAF). 

Though DODAF is aimed at military systems, it has broad applicability across the private, 

public, and voluntary sectors involved around the world. It is especially suited to large systems 

with complex integration and interoperability challenges, and is apparently unique in its use of 

"operational views" detailing the external customer's operating domain in which the developing 

system will operate. 

The Framework supports the development of interoperating and interacting architectures as 

referenced in DoD issuances. It defines three related views of architecture: Operational View 

(OV), Systems View (SV), and Technical Standards View (TV) as depicted in 

Figure 18. Each view is composed of sets of architecture data elements that are depicted via 

graphic, tabular, or textual products. The All-DoD Core Architecture Data Model (CADM) 

defines the entities and relationships for architecture data elements. 

Like other Enterprise Architecture (EA) approaches, DODAF is organized around a shared 

repository to hold work products. The repository is defined by the Core Architecture Data 

Model (CADM -- essentially a common database schema) and the DoD Architecture 

Repository System (DARS). A key feature of DODAF is interoperability, which is organized as 

a series of levels, called Levels of Information System Interoperability (LISI). The developing 

system must not only meet its internal data needs but also those of the operational framework 

into which it is set. 
47

Figure 18: Linkages among views [137] 

5.1 Convergence of PLM support standards 

The importance of interoperability across the phases and functions in PLM among the 

multiplicity of languages dealing with the varied contents comprising the complete product 

description has been recognized by a number of institutions including NIST, the US 

Department of Defense (DoD), the European Ministries of Defense and, more recently, by the 

vendor and end-user communities [26; 27]. While there has been articulation of the need, the 

issue has not been yet fully addressed due to the divergence of interests on how interoperability 

should be achieved. The challenge is to create standards and protocols that allow legacy 

systems as well as future technological innovations to interoperate seamlessly. 

Today’s standards, particularly in the area of CAD, have produced direct improvement in 

productivity, especially in the manufacturing arena, by reducing transaction costs and even 

more so by increasing the richness of interactions between supplier and customer [29; 30]. The 

real cost of the lack of interoperability is difficult to measure and is often buried in day to day 

operations of individuals needing the information or needing to transmit the information. 

It is clear from Figure 19 that there is no standard that provides full coverage of the PLM 

support spectrum. One can see that some standards, e.g., SysML and PSL cover some aspects 

of PLM with notable discontinuity in their scope. Please note that this figure is not intended to 

show the full set of important standards for PLM support, but to give examples of current 

standards and their coverage e.g., for STEP only a very limited subset of APs is shown. STEP+ 

denotes lifecycle functional coverage by existing ISO 10303 APs, including AP239. 
48

Design organization

Conceptual design

STEP+

Design evaluation

GEIA-927

Product Process

Enterprise services

Ideation

Detailed design

Manufacturing

Supply

chain

Product use

Disposal

SCOR

SysML

PSL

EDI ebXML

SysML STEP PSL

AP203

AP 224

AP214

AP233

GEIA-927

MIMOSA

S1000D

PLCS

PLCS

STEP+ STEP+

GEIA-927

Figure 19: An example of current standards and their coverage 

6. Implementation issues and strategies 

In general, the use of internationally developed, industry-driven, industry-maintained standards 

allows the maximum freedom of choice for the AMC, and will drastically reduce expense 

across the lifecycle of the product. Information technology standards are a key enabler to 

manufacturers and participants in the lifecycle management of the product’s data for bridging 

the gap between the multitude of enterprise systems and the asset management systems. This 

aspect is critical to the U.S. Army as most of its asset management systems and associated 

product data still lie within the ownership, or at least, physical domain of the OEM delivering 

the product and associated support. A movement toward the adoption and implementation of 

data exchange standards to fully support the product’s lifecycle processes has been proven to be 

a good business practice as referenced earlier in this report. As the Army considers the use of 

such standards, the PEWG should factor into their recommendations that any given standard 

should ensure the U.S. Army has: 

• Commercial, off-the-shelf, multi-vendor purchasing power. 

• Intra-enterprise product data and process integration; automatic plug-and-play. 

• Inter-enterprise product data and process integration; automatic plug-and-play. 

• Cross-industry-domain integration, allowing the supply chain sub tiers to remain 

competitive in pricing to U.S. Army-specific customers. 

• Remote, “same-view” online access to the product’s data. 

• Opportunities for data to be created once, used many times, and in many ways. 
49

Historically, the Department of Defense has had a vested interest and proactive support in the 

use of international standards for data exchange, system integration, and more joint force 

cooperation for system readiness. Probably one of the most notable initiatives for joint service 

collaboration and commitment to international standards emerged from the Computer-aided 

Acquisition and Logistics Support (CALS) program. This program began in the fall of 1985, 

and actively pursued improved information digitization and data integration through the midto-late 1990s. While the US commitment to CALS as an initiative has since been folded into 

other initiatives, worldwide activities still fan the flame of CALS and its concept to adopt 

industry standards. Some of the DoD initiatives that have committed to using industry 

standards (Appendix D) were a direct result of the CALS initiative, while others have 

continued to spring from the momentum and interest started by CALS. The most landmark of 

edicts in breaking new ground for its time was Secretary of Defense Perry’s June 29, 1994 

memorandum stressing the minimization of development and use of military specifications and 

standards and maximizing the use of industry or commercial standards. While more than a 

decade has passed since his memorandum was released, many of the tenets of the memorandum 

continue to motivate DoD toward industry standards today [141]. 

6.1 Challenges in standards development for PLM 

As the type and scope of the standards needed for PLM support becomes clearer, there is 

increased interest in the models that have emerged in the distributed internet world for 

standards development and software production. Specifically, it is increasingly clear that a 

combination of open source models and TCP/IP-like open standards approaches is needed [26; 

142]. The Internet Engineering Task Force (IETF) [143] open standards approach ensured that 

the features incorporated were demonstrated to be useful not just for one organization but for 

all who are affected and interested enough to participate in the process. Open source models 

that have evolved with the rise of the internet have addressed the large scale distributed design 

of complex products. The primary reason for success of the open source model has been its 

ability to scale that transcends “Brooks’ Law” [144]. According to Brooks’ law, the propensity 

for errors increases geometrically when resources are added linearly. In the case of open 

source, this constraint on the use of resources is resolved through the voluntary nature of 

participation and task selection [26]. Further, the availability of the complete record of the 

decision-making process and of the results of testing and use allows for the design-usemaintenance cycle to be rather quick in turnaround. The major success of open source comes 

from the recognition of the scale and diversity of skills through modular design; minimizing 

costs of bad local decisions; and the ability to mobilize people of diverse skills [26]. 

The development of standards for PLM support requires many people with different skills and 

expertise to participate. These people cannot be assembled in one place -- virtual or real -- to 

create a centralized top-down set of standards. Standards are best created in an open process 

and within a voluntary participatory model. Earlier experiences with standards development in 

the distributed, connected world point to open standards and open source models as an 

alternative model of consensus building and production [27]. Who should be responsible for 

creating these communities is an open question. Many existing standards have been created by 

individuals or groups of individuals. Some of these efforts also involve regional economic 
50

development zones. A few of these organizations have been mentioned in the context of some 

of the standards we reviewed in Section 4. 

There are enormous benefits due to network effects that can be realized socially by open 

approaches; this will continue to allow university, industry (small, medium, and large), and 

laboratories to draw out of the same well (ISO model), minimizing incompatibilities and 

increasing the ability to create a plug-and-play system. This approach will foster innovation at 

the modular level without requiring a drastic redesign of the overall system. Repeated drastic 

design changes for both standards and software lead to increased costs in the creation, training, 

maintenance and archiving of the information and knowledge created in the life of a product. 

The open source and open standards models seem to address these issues in the best manner 

given the scale and scope, and provided us with alternative models for standards development. 

Maintenance and use require conformance to standards and at times certification of the same. 

Institutions such as NIST can play a major role in being the honest broker and archivist of the 

process of standards creation, maintenance, and evolution; and with follow-on validation and 

conformance and interoperability testing of implementations. To encourage this process, the 

Manufacturing Interoperability Program of the Manufacturing Engineering Laboratory at NIST 

is working on achieving convergence among standards. Beyond the convergence of the types of 

standards referred to in this paper, standards for other aspects such as traceability, validation, 

verification and other audit and archival functions will have to be considered in the support 

system for PLM [145]. A good example is the Open Archival Information System (OAIS) 

reference model which facilitates a much wider understanding of what is required to preserve 

and access information for the long term [146]. 

The current disparate standards with differing assumptions and purposes are not easily 

reconciled; neither can they be resolved economically by any single entity. The extraction of 

positive network externalities in the networked manufacturing economy can only be achieved 

by the free flow of ideas and the exchange of knowledge in a public or semi-public space to 

create new innovations in the new knowledge economy [147]. To exploit the efforts of a large 

number of researchers, practitioners, users, and students to continuously integrate their work 

into the larger vision of full PLM support, there is no choice but to develop a pragmatic 

mechanism for supporting the development of standards in an open environment where the 

participation of all parties concerned will become critical. 

Any convergence of standards that might be necessary can only take place in an open 

environment given the complexity of the task ahead. This realization can be seen in the 

publications of information technology vendors such as IBM, end users such as DoD, and 

engineering consultants making a case for open standards for the information base required to 

support the underlying IT infrastructure to accommodate legacy and changing technologies 

[148-150]. 

7. Observations and recommendations 

The product data exchange standards and best practices that were preliminarily investigated by 

NIST for this report are: 
51

• ANSI/EIA 649, National Consensus Standard for Configuration Management 

• EIA-836, Configuration Management Data Exchange and Interoperability 

• ASD/AIA S1000D International Specification for Technical Publications Utilizing a 

Common Source Database 

• ISO 10303, Industrial automation systems and integration -- Product data representation 

and exchange Application Protocols: 

− 203 Configuration Controlled Design

− 214 Core Data for Automotive Mechanical Design Processes 

− 224 Mechanical Product Definition for Process 

− 233 Systems Engineering Data Representation 

− 239 Product Life Cycle Support 

− 240 Process Plans for Machined Parts

• MIMOSA OpenO&M, Information standards 

• GEIA-927, Common data schema for complex systems 

• DoD Architecture framework, 9 February 2004: 

− Volume 1: Definitions and guidelines 

− Volume 2: Product descriptions 

Based on our analysis of the list of standards selected for review, we have the following 

observations: 

• Some of the standards are extensions of the others, e.g., EIA-836 complements the wellestablished ANSI/EIA-649 standard for configuration management and incorporates its 

principles. 

• Some of the standards are built as an integration of others, e.g., GEIA-927 is an 

integration of ISO 15926, PAS20542, ISO 10303-AP212, and AP239; and more 

standards are currently being integrated into GEIA-927. 

• A number of the same functionalities are supported by more than one standard, e.g., 

configuration management is included in ANSI/EIA-649, EIA-836, 10303-AP203, ISO 

10303-214, and 10303-AP239. To compound this overlap, several standards are being 

developed within the United States, while similar development efforts are, or have 

occurred, in the international arena, e.g., GEIA-0007 and ISO 10303-239, EIA-836 and 

ISO 10303-203, and ANSI/EIA-649 with ISO 10007. (The latter is not covered in the 

scope of this report.) (See Table 1) 

• EIA-836 appears to be a thorough and good start for managing configuration data 

within the Army, but it appears the funding of the work and the interest in the work is 

only by the government. Without much industry buy-in, such a project and direction in 

employing standardization will be an expensive approach for maintenance and 

enhancement by the Army. 

• ISO 10303 appears to have the most breadth and depth of coverage for product lifecycle 

data. ISO 10303-239 (Product Lifecycle Support, PLCS) is currently the only 

international standard available that covers the entire lifecycle spectrum. NIST believes 

that PLCS has great potential to handle the Army’s PLM requirements, but recommends 

the Army resolve certain challenges explained below) before firmly committing to its 

adoption. 
52

GEIA standards efforts ISO standards efforts 

927 Common Data Schema 10303 Standard for The Exchange of 

Product Model Data (STEP) 

0007 Logistics Data Implementation 

Model 

AP239 Product Life Cycle Support –

PLCS 

859 Data Management 10032 Reference Model of Data 

Management 

836 Data Standard for Configuration 

Management 

AP203 Configuration –Controlled Design 

649 Configuration Management 10007 Configuration Management 

Table 1: Similar efforts by GEIA and ISO 

Although in some cases, we can consider that standardization efforts complement each other, in 

most of the cases the standardization efforts are inefficiently repeated, creating a proliferation 

of standards. Such a volume of standards from which to choose is often a source of confusion 

for the users and project leaders or managers to decide which standard to use for a particular 

task. This problem is especially pressing and needs to be quickly addressed in the case of PLM 

where the diversity of data and its distribution in time and place require a large number of 

standards to be used and there are so many from which to choose. 

This set of standards addresses data standards covering the various phases of the Defense 

Acquisition Management Framework (see Section 4.2 and Figure 2 for a brief presentation of 

the DoD 5000 directives and DAMF). These set of standards are consistent with DoDD5000.1. DoDD-5000.1 does not elaborate on specific STEP APs and does not specify GEIA927 (GEIA-927 is a later effort supported by DoD). GEIA-927 is an integrated multi-domain 

data schema for representing system product and process data. The data schema is the 

organization and interrelationships of system data essential for developing an advanced 

integrated environment. It remains to be seen what role GEIA-927 will play if the STEP 

application protocols are adopted more widely across the supporting industrial sectors (e.g., 

automotive, aerospace, electrical/electronic, construction, numerical control) and supporting 

software vendors. GEIA-927 is attempting to compensate for the lack of modular structure 

available across the existing STEP APs. It may become obsolete if industry and vendors 

implement the new STEP modularized application protocols. Most recently, ISO 10303 

AP203ed2, AP236 (furniture industry) and AP239 are already internationally standardized as 

modularized APs. 

ISO 10303-239 (AP239 or PLCS) defines an application-specific, but flexible and extensible, 

information model. The information model can be modified by specific industry and 

organizations through the use of Reference Data Libraries (RDL). The role of RDL is to 

complete the semantics of the PLCS model necessary for implementation in a specific industry. 

The benefit of AP239 is its integrated view. It has a large and generic information model that is 

larger in scope than most business processes require or most IT applications can manage; 

therefore, it allows better flexibility. To subset the information model to suit a specific 

business process, a DEX is developed. These DEXs are outside the scope of ISO 10303-239. 

A DEX provides a subset of the PLCS information model, along with usage guidance. A DEX 

can be used as a contract specification or for setting conformance but AP239 implementations 

can exist without using DEXs. 
53

The OASIS Product Life Cycle Support Technical Committee is currently committing the 

resources to develop DEXs, and their supporting infrastructure using AP239. The OASIS 

Technical Committee will consider any data exchange specifications, capabilities, and 

reference data developed by outside projects for adoption by OASIS. 

ISO 10303 represents a powerful capability for engineering product information and PLCS 

extends ISO 10303 into through-life support processes. Early PLCS implementations have 

already begun to validate the standard and its use. Even though PLCS may not solve all the 

problems of product data interoperability today, it is currently the only international standard 

available that covers the entire lifecycle spectrum. PLCS extends the functionality of ISO 

10303 in many ways including mechanisms for schema evolution; both top-down and bottomup (instance-based) information models, and semantics interoperability. There are, however, 

some caveats related to PLCS that NIST recommends the Army think through and resolve 

before committing organizationally to the use of ISO 10303-239: 

• Different applications using the same data model but with different Reference Data will 

not interoperate until the two sets of Reference Data have been harmonized or mapped. 

NIST recommends the Army centrally defines and mandates the Reference Data for 

AMC. 

• The ISO community has a good procedure for Reference Data management but no 

business model to support its implementation. NIST recommends the Army work with 

the ISO community to define a good business model to support its implementation. 

• The DEXs, Capabilities, and Reference Data that are under OASIS development might 

face problems of nonstandardized modification and proliferation. The issues of 

maintenance and ownership for those under OASIS also need to be addressed. NIST 

recommends the Army investigate and understand more fully the ramifications and 

long-term effects regarding issues associated with maintenance and ownership. 

• There could be potential intellectual property rights (IPR) issues related to these 

specifications. OASIS IPR policy (see OASIS.IPR.3.2. OASIS Specifications (c) ) 

specifies Reasonable and Non-Discriminatory (RAND) terms for IPR. A careful study 

of potential RAND-related problems is critical as these could affect the future of data 

access and data integrity. While NIST has no direct recommendation on how to assess 

and resolve the potential problems associated with OASIS IPR, it is important for the 

Army to be aware of this potential barrier to the way the Army would like to do 

business. 

Beyond our recommendations for the use of ISO 10303-239, NIST recommends the PEWG 

consider implementing other ISO 10303 application protocols if prototype testing under current 

projects as Army’s AGILE and Lean Munitions successfully prove cost-effective. APs under 

these projects include AP203, AP214, AP224, and AP240. As the PEWG selects from the 

possible candidates to be implemented within the AMC’s product lifecycle support, it is critical 

to the success of these selections that contractual requirements are clear, consistent, and 

pervasive in support of the standards selected; and that proprietary vendor solutions – 

equipment and software – are avoided. 

In summary, the achievement of the Army’s PLM objectives requires a clear understanding of 

all its supporting logistics’ systems to ensure sound decision-making. As was observed by 

Herbert Simon in his essay, “The Architecture of Complexity” [151], and extending his 
54

observation to our present context, we agree that the complexity of the information exchange 

issue and the diversity of participants and their perspectives make it highly improbable that a 

single disciplinary perspective can accomplish the task of supporting PLM. For these reasons, 

and the associated short and long-term economic impact of “islands of isolation” decisions, we 

believe that much of the stable part of the information base supporting PLM should be 

developed within the framework of open standards. 

Also in the course of this study, NIST had a preliminary introduction to the Army’s SALE 

initiative. For the long-term success of this critical initiative (more than $60M in FY2006 

alone), NIST recommends the use of a selected set of mature international standards become 

part of the SALE architecture and contract mandate. NIST was unable to access the business 

case study that was done, which supported adopting a proprietary software product as part of 

the SALE architecture; therefore, NIST recommends the Army have a clear understanding of 

the long-term ramifications of this proprietary decision by reviewing its business case for such 

decisions as analyzed and reported per DoDD 5000.1, (cf. Section 4). 

Earlier in this report, in our discussion on good characteristics of a standard, we suggested one 

should look for standards that: 

• Support fair trade and fair competition. 

• Increase user, consumer, and government confidence. 

• Facilitate interoperability. 

• Stimulate innovation. 

These are also considerations when assessing the long-term solutions, expense, and necessary 

resources for maintaining a fully integrated, tri-service logistics lifecycle support network. We 

also have the following recommendations for the Army. That it: 

• Review its investments and pilot results for various STEP AP projects, and investigate 

further integration of these application protocol commitments with AP239 for full 

product lifecycle support. The Army has been investing in the development and piloting 

of several other ISO 10303 application protocols, including AP203 edition 2; and a 

“manufacturing” suite comprised of at least AP203, AP219, AP223, AP224, AP238, 

and AP240. 

• Investigate and understand more fully the ramifications and long-term effects regarding 

issues associated with maintenance and ownership of existing OASIS DEX and 

Reference Data. If OASIS standardization in PLCS is determined the best viable 

solution, the Army should: 

− Assess the coverage by existing OASIS DEXs and reference data to meet the 

Army’s needs. 

− Participate in the development of necessary DEXs and reference data sets within an 

international standards development forum. 

• Promote the transfer of national standards into the international standards development 

arena. The Army has invested significant resources into developing national standards 

such as EIA-836, GEIA-927, and GEIA-0007. Adoption and use of these standards 

may improve if this work is incorporated into the international standards development 

efforts. For example, the business rules available in EIA-836 could possibly be turned 
55

into a configuration management DEX within OASIS. Similarly, the business rules 

being developed in GEIA-0007 could be turned into a logistics support analysis DEX. 

• Ensure standards-based product lifecycle support by vendors and users by developing a 

template of contractual language that consistently and expressly calls out the 

recommended standards of choice and commits the Army to a standardized solution as 

the only way to do business. 

• Act upon Under Secretary of Defense Krieg’s recommendation in his memorandum of 

June 23, 2005, “Standard for the Exchange of Product Model Data (STEP) --- ISO 

10303” to review and implement STEP as the Army’s interoperability standard. 

As defined in Section 1, Background, the objective of this report was twofold. To provide to 

the U.S. Army Materiel Command through its PEWG: 

• An introduction and review of standards and related technologies that might support the 

Army’s lifecycle management of products and services necessary to maintain the 

mission-readiness of its troops. 

• Recommendations that will assist the Army in its selection of product lifecycle support 

standards. 

To this end, our investigative study focused primarily on the Army’s use of a selected set of 

standards and best practices in product data representation, and in the exchange of product data 

between various divisions within US Army and their OEMs. NIST discussed how the Army 

meets its requirements for materiel and logistics support, primarily focusing on the lifecycle 

requirements of a product. A complete list of those with whom we had contacted is included 

under Acknowledgements. 

8. Proposed next steps 

The time allowed for this report did not permit a uniform in-depth study of the standards 

investigated in this report, nor of the full suite of prospective PLM-related standards. NIST 

proposes in this section, as a follow-up to this report, several additional short and long-term 

possible joint efforts with the Army, which include providing a more in-depth assessment of a 

larger suite of candidate PLM standards, identifying the gaps, and producing a formal process 

that will assist the Army in its selection of necessary standards. As part of this extended 

assessment, NIST would include reviews of the linkage or overlaps between PLCS and 

S1000D, and PLCS and MIMOSA. 

• As mentioned earlier, the ISO community has a good procedure for reference data 

management but no business model to support its implementation. NIST recommends 

that the Army work with the ISO community to define a good business model to 

support its implementation. Such a collaborative activity could be conducted using 

Army resources or Army-sponsored representatives. 

• Develop strategies for the creation of common and discrete ontologies that best 

facilitate the interoperability and fluidity of information flow between the Army, its 

OEMs, and other allied countries. 
56

While this study focused primarily on product data standards called out in several DoD 

missives, there are many other and sometimes, more mature standards identified in the 

typology of standards (Type 0 through 3) as discussed earlier. Appendix C provides a sampling 

of standards to illustrate what might be used in populating a typology. NIST recommends the 

Army take initial steps to assess standards in the lower levels of the typology, and begin 

implementing their use; start with the fundamental foundations offered by Type 0 standards. 

This could eliminate the need and resources currently invested in developing primarily Army or 

government-unique standards such as EIA-836 or GEIA-927. 

The incompatibilities and gaps that exist among current standards arise at different typology 

levels of the necessary data exchange process supporting the Army’s logistics demands. These 

incompatibilities require further research and can be studied using the typology defined in 

[16], and introduced in Section 5. 

In addition to the recommendations above, the following are other areas of research and 

development NIST believes may be of interest to the Army, particularly for product lifecycle 

management of its product and process data. 

• A reference model for the Army’s product lifecycle information ecosystem 

A key requisite to a manufacturer leveraging strategies for competitive advantage is a 

common product description that is shared among all stakeholders throughout the 

lifecycle of the product. Detailed product information cannot be kept isolated within 

the boundaries of any one single entity within the extended networked enterprise. This 

information must now be shared in a collaborative and secure manner across the global 

enterprise and its extended value chain.

The challenges of the product-engineering environment are to support the creation, 

exchange, archiving, and management of information about product, process, people, 

and services within and across the networked and extended enterprise covering the 

entire product lifecycle spectrum. It is critical to the success of companies and their 

suppliers that this sharing is done correctly, efficiently, and inexpensively. To achieve 

this we need a reference model as a framework for understanding significant 

relationships among the entities, and for the development of consistent standards or 

specifications supporting this environment. This reference model would be based on the 

reference model for Open Archival Information System (OAIS), which consists of a 

small number of unifying concepts. OAIS can be used as a basis for education and 

explaining standards to a non-specialist. 

• A methodology to create test beds for evaluating information standards and their 

implementations 

The lack of complete interoperability is a pervasive problem in today’s information 

systems and the cost of managing systems under these conditions is a major economic 

drain in most industries. Support of interoperability requires developing standards 

through which different systems can communicate with each other. However, multiple 

systems intended to interoperate will have to be tested for conformance, 

implementation, and interoperability among each other. These tests will have to 
57

encompass syntactic, content, and semantic aspects of exchange between the systems. 

NIST has prior experience in developing test beds and testing services for some of these 

aspects for specific standards such as ebXML, STEP, SQL, XML, and other 

information technology measurement and testing activities at NIST. While there has 

been considerable experience with developing test beds, testing methodologies, and test 

suites, there has not been a systematic synthesis of these experiences into a 

methodology. A joint NIST and Army research effort to synthesize a methodology for 

test beds based on prior experiences at NIST, and to develop a reference test bed 

architecture would be very useful to the Army and to US industries in general. The test 

bed architecture could be designed to address all levels of interoperability covering 

syntax, content, semantics, and visualization. We would apply the architecture derived 

to create an exemplar for the Product Lifecycle Management (PLM) support system. 

The potential outcomes could be to: 

− Ensure the manufacturing industry end-users and software vendors conform to 

exchange standards. 

− Create an industry/vendor neutral private entity to verify, validate, and certify 

vendor implementations of standards, with help from NIST leadership, and hence 

create opportunities for vendors to provide additional services. 

− Create a generalized architecture and test models and regimes for test bed design 

and implementation in various domains. 

− Allow vendors to commercialize tools for standards integration and system 

interoperability testing to ensure integration of legacy tools. 

• Long term knowledge retention for digital technical product documentation 

Data has always been a critical asset to manufacturing. Increasingly, data is in digital 

form with no corresponding analog equivalent. For example, 3D digital models have 

become the preferred method for specifying designs in the transportation sector. With 

product life cycles often far longer (i.e., aircraft fifty years) than the expected lifetime of 

a manufacturing software application used to interpret the data (approximately three 

years), or of the technologies used to store and retrieve the data (approximately ten 

years), searching for archived information is routinely problematic. 

Data access, retrieval, and reuse is necessary for such information-based activities as 

initial manufacturing, design reuse, liability and legal issues, incident investigation, and 

regulatory and contractual compliance. Current practices include converting the 3D 

models to 2D, and archiving the result on microfiche; migrating data off storage 

systems before they become obsolete and/or unreliable; and maintaining legacy 

hardware and software for the sole purpose of accessing old data. These practices are 

expensive, labor-intensive, and still result in a loss of information over time. 

Recognizing the importance of electronic records for its mission of preserving 

“essential evidence,” the National Archives and Records Administration (NARA) 

launched a major new initiative, the Electronic Records Archives (ERA) initiative, in 

1998. The recommendations of the Consultative Committee for Space Data Systems 

(CCSDS) established a common framework of terms and concepts which comprises the 

Open Archival Information System (OAIS), later adopted as the ISO 14721:2003 

standard. Other efforts have also undertaken to address the needs for long term 
58

knowledge retention in specific areas such as manufacturing, health care, life sciences 

and legal and military applications. The importance of digital preservation is clearly 

emphasized by these efforts and more specifically the Digital Preservation Project of 

US Library of Congress [152]. 

In all these efforts, standards play a crucial role. In the area of engineering informatics, 

NIST’s Knowledge Retention project and the Long Term Data Retention (LTDR) 

project [153] dealing with digital technical product documentation, such as 3D-CAD 

and PDM data, studied the applicability of international standards such as ISO 

14721:2003 and ISO 10303. This research effort will concentrate on representation of 

form, function, and behavior of complex engineering designs to maximize long-term 

information access, retrieval, and reuse. 

9. Acknowledgements 

The resources involved to develop this report were sponsored by the United States Army Tank 

Automotive RDE Center (TARDEC), 6501 E. 11 Mile Rd, MS 268, Warren, MI 48397-5000. 

The authors of this report would also like to thank Eswaran Subrahmanian, Ram Sriram, Peter 

Denno, Ed Barkmeyer, Josh Lubell, Simon Frechette, and Steve Ray for their consult and 

insight in developing the content of this report. Also, our thanks to Enterprise Integration, Inc. 

for their contributions, along with the several Army personnel who took the time to respond to 

our queries or meet with us to discuss their lifecycle logistics processes: 

Organization Name Primary Type of Interaction

(meeting, teleconference, written) 

AM General Mike Peters Teleconference 

AMCOM Gayle Booker Web Conference 

AMCOM Jerry Austin, Steve Gaver, 

Glenn Williams, Steven Ross 

Written 

AMCON/CIO/G6 Patrick Smith, Jerry Austin Meeting 

AMRDEC Deborah Cornelius, Carla 

Crawford, Ray Morgan, Russ 

Miller, Mike Campe, W. Odis 

Nickoles (AMREC detail) 

Meeting 

AMRDEC Mellisa Barnett, Ray Morgan, 

Carla Crawford, Mike Campe 

Written 

AMSAA Tom Schneider, Gordon Ney, 

Dave Collum, Art Heyderman, 

Willie Feli,Eric Bakk 

Web Conference 

ARDEC John Hummel, Art Heyderman Web Conference 

ARDEC Neil Stern, Fred Johnson, Mark 

Napolitano 

Meeting 

ARDEC Joe Mokey, Brenda Pettenger, 

Dave Robinson 

Teleconfernce 

Boeing, C-17 Reginald Gates Teleconference, Written 

ECBC Willie Felix Web Conference 

EDMS PMO John Montgomery Meeting 
59

Organization Name Primary Type of Interaction

(meeting, teleconference, written) 

Enterprise 

Integration, Inc. 

John Hunter, Martin Malis Meeting 

Ford Gahl Berkooz Meeting 

General 

Dynamics Land 

Systems 

Carol Tierney Meeting 

LCMC IMMC Louis R. Washington Meeting 

LOGSA Lou Sciaroni, Meeting 

LOGSA John Colsen Teleconference 

TACOM Dennis Dunlap Written 

TACOM-IBO Eric Bakken Web Conference 

TARDEC Raj Iyer Meeting 

10. Disclaimer 

Mention of commercial products or services in this paper does not imply approval or 

endorsement by NIST nor does it imply that such products or services are necessarily the best 

available for the purpose. 

11. References 

 1. "DoD 4140.1-R Supply Chain Materiel Management Regulation, Office of the Deputy 

Under Secretary for Logistics and Materiel Readiness Section C7.4," US Department of 

Defense, May 2003. 

 2. Army Materiel Command. http://www.amc.army.mil/G3/org/e/esfaq.htm . 7-13-2006. 

 3. Single Enterprise Concept Sets "SALE" Under New Contracts. Army Logistician. 

http://www.findarticles.com/p/articles/mi_m0PAI/is_4_37/ai_n15648706 . 2005. 

 4. Interoperability Cost Analysis of the U.S. Automotive Supply Chain. 

http://www.nist.gov/director/prog-ofc/report99-1.pdf . 1999. Research Triangle 

Institute, NIST Planning Report . 

 5. AMC web site. http://www.amc.army.mil/ . 2006. Army Materiel Command. 

 6. Defense Update, International Online Defense Magazine, Issue 3. http://www.defenseupdate.com/products/f/fcs.htm . 2005. 

 7. Iyer, R. G., and Gulledge, T., "Product Lifecycle Management for the US Army 

Weapon Systems Acquisition," Inderscience Publishers, PLM: Emerging solutions and 

challenges for Global Networked Enterprise, ISBN 0-907776-18-3,2005, pp. 553-564. 

 8. Interoperability week @ NIST. http://www.mel.nist.gov/div826/msid/sima/interopweek

. 2006. 

 9. Acquisition Reform. http://www.dod.mil/execsec/adr95/acq_.html . 2006. US 

department of Defense (DoD). 

 10. GSC: Global Standards Collaboration. www.itu.int/ITU-T/gsc/index.html . 2006. 

 11. Saunders, M., "International Standards and Innovation - What are the Linkages?," NIST 

Sigma Xi Lecture Series, 2006. 

 12. CSA International. http://www.csa-international.org/consumers/why_standards_matter/

. 2006. 
60

 13. NTTAA: National Technology Transfer and Advancement Act. 

http://standards.gov/standards_gov/index.cfm?do=documents.NTTAA . 3-7-1996. 

 14. Office of Management and Budget Circular A-119. 

http://standards.gov/standards_gov/index.cfm?do=documents.A119 . 2006. 

 15. Allen, R. H. and Sriram, R. D., "The Role of Standards in Innovation," Technological 

Forecasting and Social Change, Vol. 64, 2000, pp. 171-181. 

 16. Subrahmainain, E., Sudarsan, R., Bouras, A., Fenves, S. J., Foufou, S., and Sriram, R. 

D., "The role of standards in product lifecycle management support," National Institute 

of Standards and Technology, NISTIR 7289, 2006. 

 17. "Global Standards: Building Blocks for the Future, TCT-512," U.S. Congress, Office of 

Technology Assessment, U.S. Government Printing Office, Washington, DC, Mar. 

1992. 

 18. NTTAA: National Technology Transfer and Advancement Act. 

http://standards.gov/standards_gov/index.cfm?do=documents.NTTAA . 2006. 

 19. White, W. J.. Measuring Benefits from the National Technology Transfer and 

Advancement Act. 

http://ts.nist.gov/ts/htdocs/210/nttaa/pubs/MeasuringBenefits_Aug04Finalrpt.pdf RTI 

Project Number 08628. 2004. 

 20. United States Standards Strategy. 

http://public.ansi.org/ansionline/Documents/Standards%20Activities/NSSC/USSS2005%20-%20FINAL.pdf . 2005. ANSI. 

 21. Cargill, C. F., Information Technology Standardization Theory, Process, and 

Organizations, Digital Press, Digital Equipment Corporation1989. 

 22. "Report of the process action team on military specifications and standard. 

http://www.acq.osd.mil/ . 1994. OUSDA&T: Office of the Under Secretary of Defense 

for Acquisition, Technology, & Logistics. 

 23. Defense Logistics Agency. http://www.dsp.dla.mil/ . 2006. 

 24. Remarks by Dr. William Jeffrey, Director, National Institute of Standards and 

Technology, National Technology Transfer Act Standards Luncheon, Washington, 

D.C.. 3-6-2006. 

 25. Conversation with Gahl Berkooz, PhD, Ford, Tech Leader, Systems Engineering & 

Production Creation Complex Reduction. 2006. 

 26. Weber, S., The Success of Open Source, Harvard University Press, Cambridge, 

MA2004. 

 27. Krechmer, K., "Open Standards requirements," The International Journal of IT 

Standards and Standardization Research, Vol. 14, No. 1, 2006. 

 28. US Product Data Association. https://www.uspro.org/ . 2006. 

 29. Robertson, D. and Allen, T. J., "CAD system use and engineering performance," IEEE 

Transactions on Engineering Management, Vol. 40, No. 3, 1993, pp. 274-282. 

 30. Liker, J. K., The Toyota Way: 14 Management Principles from the world's greatest 

manufacturer, Mc Graw Hill2004. 

 31. The Defense Acquisition System. 

http://akss.dau.mil/dag/DoD5000.asp?view=document&doc=1 . 5-12-2003. 

 32. Defense Acquisition University. http://www.dau.mil/index.asp . 2006. DAU web site. 

 33. Kemmerer, S., "STEP: The Grand Experience, (Editor)," NIST Special Publication 939, 

National Institute of Standards and Technology, Gaithersburg, MD 20899, USA, 1999. 

 34. ISO 10303-11: 1994, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 11. Description methods: the EXPRESS language 

reference manual. 
61

 35. Product Life Cycle Support (PLCS), Frequently Asked Questions. 

http://xml.coverpages.org/PLCSInc-FAQv2-20030804.pdf . 4-8-2003. 

 36. Gallaher, M., O'Connor, A., and Phelps, T., "Economic Impact Assessment of the 

International Standard for the Exchange of Product Model Data (STEP) in 

Transportation Equipment Industries," National Institute of Standards and Technology, 

Department of Commerce, USA, 2002. 

 37. STEP Success Stories. http://pdesinc.aticorp.org/success_stories.html . 2006. PDES, 

Inc. 

 38. ISO/DIS 10303-219, Industrial system-Product data representation and exchange - Part 

219, Dimensional inspection information exchange. International Organization for 

Standardization (ISO), Geneva, Switzerland. 

 39. ISO 10303-232, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 232, Application Protocol: Technical data 

packaging core information and exchange. 2002. International Organization for 

Standardization (ISO), Geneva, Switzerland. 

 40. Feeney, A. B., "The STEP Modular Architecture," Journal for Computing and 

Information Science in Engineering, Vol. 2, No. 2, 2002, pp. 132-135. 

 41. PDES, Inc. http://www.pdesinc.com/ . 2006. 

 42. CAx Implementor Forum. http://www.cax-if.org/ . 2006. 

 43. ProSTEP iViP Verein. http://www.prostep.org/en/ . 2006. 

 44. Loffredo, D.. Fundamentals of STEP Implementation. 

www.steptools.com/library/fundimpl.pdf . 2000. Website STEP tools, Inc., New York. 

 45. ISO 10303 STEP Application handbook Version 2. http://www.isgscra.org/STEP/STEPHandbook.html . 12-21-2001. SCRA. 

 46. CAD System Translators. http://pdesinc.aticorp.org/vendor/CAD_vendor.html . 2006. 

PDES, Inc. 

 47. STEP ISO 10303. http://www.steptools.com/library/standard/ . 2006. STEP Tools, Inc. 

 48. Developed APs and Modules: AP203. 

http://pdesinc.aticorp.org/aps_modules.html#assemblies . 2006. PDES, Inc. 

 49. STEP: Will It Finally Hit Stride? http://www.autofieldguide.com/articles/109902.html . 

1999. 

 50. ISO 10303-203: 1994, Product Data Representation and exchange - AP 203: 

Configuration controlled 3D design of mechanical parts and assemblies. International 

Organization for Standardization (ISO), Geneva, Switzerland. 

 51. Briggs, D., and Hendrix, T.. AP203 Edition 2, Configuration Controlled 3D Design of 

Mechanical Parts and Assemblies. 

http://www.isd.mel.nist.gov/projects/metrology_interoperability/imis/presentations/Hen

drix.pdf . 3-28-0006. Boeing Technology. 

 52. kassel, B., and Mays, J. L.. ISO 10303 AP 214 and DoD. 

www.nsrp.org/panels/systems/downloads/STEP_3D_Model_Mays.pdf . 2006. 

 53. Memorandum of Common Understanding and Cooperation on Standardized CAProduct Data. http://pdesinc.aticorp.org/mous/automotive.html . 2006. 

 54. Developed APs and Modules: AP214. 

http://pdesinc.aticorp.org/aps_modules.html#ap214 . 2006. PDES, Inc. 

 55. Feltes, M., Kornmueller, M., Oster, K., Hug, H., Weinmann, M., and Schreinert, S.. 

How DaimlerChrysler uses one STEPping stone to exchange bills of material. 

http://www.iso.ch/iso/en/commcentre/isobulletin/articles/2003/pdf/step03-05.pdf . 

2003. DaimlerChrysler AG. 
62

 56. EPMT provides long-term 3D archiving software for the Eurofighter project. 

http://www.epmtech.jotne.com/newsletter/ew106/eurofighter.html . 2006. 

 57. Developed APs and Modules: AP224. http://isg.scra.org/products/step_ap224.html . 

2006. PDES, Inc. 

 58. STEP & ISG on the SCRA website. http://www.isg-scra.org/STEP/STEP_AP224.html . 

2006. 

 59. Sharma, R. and Gao, J. X., "A progressive design and manufacturing evaluation system 

incorporating STEP AP224," Computers in Industry, Vol. 47, No. 2, 2002, pp. 155-167. 

 60. ISO/CD 10303-223, Industrial system—Product data representation and exchange—

Part 223, Exchange of design and manufacturing product information for casting parts. 

International Organization for Standardization (ISO), Geneva, Switzerland. 

 61. ISO/DIS 10303-238, Industrial system-Product data representation and exchange - Part 

238, Application interpreted model for computerized numeric controllers. International 

Organization for Standardization (ISO), Geneva, Switzerland. 

 62. An Overview of AP233 STEP's Systems Engineering Standard, Jim U'Ren, 

Presentation available online. syseng.nist.gov/aerospaceworkshop/slides/Tuesday/uren1.ppt. 2003. 

 63. STEP AP233, Eurostep web site. http://ap233.eurostep.com . 2006. 

 64. Price, D.. Creating an AP233 Systems Engineering Scripting Language in Ruby. 

conferences.esa.int/pde2006/presentations/pde2006_price_ruby-for-ap233.ppt . 2006. 

 65. ISO 10303-233, Industrial automation systems and integration -- Part 233: Systems 

engineering data representation. 2006. International Organization for Standardization 

(ISO), Geneva, Switzerland. 

 66. Bailey, I.. Eurostep Technology White Paper, DODAF and AP233. 

www.eurostep.com/files/DODAF%20and%20AP233%20White%20Paper.pdf . 2003. 

 67. UGS TeamCenter. http://www.ugs.com/products/teamcenter/ . 2006. 

 68. Telelogic DOORS. http://www.telelogic.com/corp/products/doors/doors/index.cfm . 

2006. 

 69. Eurostep. Share-A-Space. http://www.share-a-space.com . 2006. 

 70. ThreeSL, Cradle 5 requirements mangement. 

http://www.threesl.com:8080/pages/requirements-management-home.php . 2006. 

 71. PTC: Product Lifecycle Management (PLM) Software Solutions. www.ptc.com . 2006. 

 72. EDS Slate web site. http://www.bitpipe.com/detail/PROD/1017064915_186.html . 

2006. 

 73. ThreeSL, Cradle 5 requirements mangement. 

http://www.threesl.com:8080/pages/requirements-management-home.php . 2006. 

 74. Vitech Corporation. http://www.vtcorp.com/ . 2006. 

 75. IBM Rational RequisitePro. http://www-306.ibm.com/software/awdtools/reqpro/ . 2006. 

 76. ILogix StateMate-Embedded Systems Design Software. 

http://www.ilogix.com/sublevel.aspx?id=74 . 2006. 

 77. Aonix-Software through Pictures. www.aonix.com/stp.html . 2006. 

 78. The Open Systems Joint Task Force. http://www.acq.osd.mil/osjtf/overview.html . 

2006. 

 79. The International Council on Systems Engineering (INCOSE). www.incose.org . 2006. 

 80. BAE systems. http://www.baesystems.com/ . 2006. 

 81. NASA-National Aeronautics and Space Administration. 

http://www.nasa.gov/home/index.html?skipIntro=1 . 2006. 
63

 82. U'ren, J.. Implementations of the STEP Systems Engineering Standard (AP233). 

http://conferences.esa.int/pde2006/presentations/pde2006_uren_ap233-

implementations.ppt . 8-28-2006. 

 83. U'ren, J.. AP233 Implementations. 

conferences.esa.int/pde2006/presentations/pde2006_uren_ap233-implementations2006-04-28.xls . 4-27-2006. 

 84. Product Life Cycle Support. http://www.plcsresources.org/#Background+to+PLCS+Inc . 2006. eurostep. 

 85. The STEP PDM Schema Home Page. http://www.pdm-if.org/pdm_schema/ . 2006. 

 86. OASIS: Organization for the Advancement of Structured Information Standards. 

www.oasis-open.org . 2006. 

 87. DEXLib. http://plcs.eurostep.com/dexlib/dex_index.htm . 2006. 

 88. Web Ontology Language (OWL). http://www.w3.org/2004/OWL/ . 2005. 

 89. Gibson, M.. UK MOD Implementations of PLCS and Lessons Learned ILS and 

Engineering Policy, Technical Enabling Services, UK MOD, Presentation given at DoD 

PLCS Meeting, Arlington, VA. www.acq.osd.mil/dpap/UID/attachments/wawf-uidrfid/3-plcs-meeting-arlington-20060216.ppt . 2-15-2006. 

 90. ISO 10303-240, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 240: Application protocol: Process plans for 

machined products. 2005. International Organization for Standardization (ISO), 

Geneva, Switzerland. 

 91. SCRA. The STEP Manufacturing Suite, White paper V3. http://www.isgscra.org/STEP/files/STEP_MfgSuiteWhitePaper.pdf . 3-5-2004. 

 92. Government Electronics & Information Technology Association. 

http://www.geia.org/index.asp?sid=13 . 2006. 

 93. GEIA 927 Overview. http://63.249.145.5/sstc/G47/GEIA-927/index.htm . 2006. 

 94. Colson, J.. GEIA-927 Standard Common Data Schema for Complex Systems. 

http://www.ndia.org/Content/ContentGroups/Divisions1/Systems_Engineering/PDFs18/

Modeling_Committee_PDFs/Colson_John.pdf . 2006. 

 95. ISO 15926-1: Industrial automation systems and integration -- Integration of life-cycle 

data for process plants including oil and gas production facilities -- Part 1: Overview 

and fundamental principles. ISO . 2004. Geneva, Switzerland, International Standards 

Organization. 

 96. ISO TC 184/SC4. ISO/WD PAS 20542: Industrial automation systems and integration - 

Product data representation and exchange - Systems engineering data representation. 

2001. ISO, Geneva, Switzerland. 

 97. ISO. ISO 10303:212. Industrial automation systems and integration -- Product data 

representation and exchange -- Part 212: Application protocol: Electrotechnical design 

and installation. 2001. ISO, Geneva, Switzerland. 

 98. STEP AP239: Product Life Cycle Support (PLCS). http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=plcs . 2006. 

 99. CMBoK - Configuration Management Body of Knowledge. 

http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/CMBoK . 2006. CM 

Crossroads. 

 100. ebXML. http://www.ebxml.org/ . 2005. ebXML. 

 101. Integrated Defense Acquisition, Technology & Logistics Life Cycle Management 

Framework Chart, Ver. 5.2. http://akss.dau.mil/ifc/ . 2005. Defense Acquisition 

University. 
64

 102. InSync Product Overview (continued). 

http://www.isscorp.com/html/insync_overview_continued.html . 2006. 

 103. PTC Develops New PLM Solution For The Aerospace & Defense Industry. Press 

Releases. 

http://www.ptc.com/appserver/wcms/standards/textsub.jsp?&im_dbkey=25838&icg_db

key=21 . 2006. 

 104. Extensible Markup Language (XML). http://www.w3.org/XML/ . 2005. 

 105. CMBoK - Configuration Management Body of Knowledge. 

http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/CMBoK . 2006. 

 106. EIA, "EIA-836: Configuration Management Data Exchange and Interoperability. Draft 

Version 1.2," Jan. 2004. 

 107. ASME, Dimensioning and Tolerancing Y14.5M, ASME1994. 

 108. ISO 1101:1983, Technical drawings -- Geometrical tolerancing -- Tolerancing of form, 

orientation, location and run-out -- Generalities, definitions, symbols, indications on 

drawings. International Organization for Standardization, Geneva, Switzerland. 

 109. ASME Y14.41: Digital Product Definition Data Practices. 8-1-2006. ASME. 

 110. Condition Based Operations for Manufacturing, MIMOSA OpenO&M. 

www.mimosa.org/papers/OpenO&M%20Whitepaper-CBO%20for%20ManufacturingFinal.pdf . 10-6-2004. Manufacturing Joint Working Group. 

 111. ISA: Instrument Society of America. http://www.isa.org/ . 2006. 

 112. OPC: open connectivity via open standards. http://www.opcfoundation.org/ . 2006. 

 113. Hoske, M. T.. http://www.manufacturing.net . 8-1-2006. Control Engineering 

Magazine. 

 114. Case Study: eRTIS Project and use of MIMOSA and Generic Web Services. 

http://www.mimosa.org/papers/Case%20StudyBP%20Refining%20Selection%20of%20O&M%20Information%20Standards.ppt#277,

12,Interfaces . 10-23-2004. BP Refining eRTIS Project. 

 115. ISO 8879:1986 Information processing -- Text and office systems -- Standard 

Generalized Markup Language (SGML). 1986. International Organization for 

Standardization (ISO), Geneva, Switzerland. 

 116. ANSI/ISO 8632.1-4:1992 Computer Graphics Metafile. 1994. International 

Organization for Standardization & American National Standards Institute. 

 117. S1000D - International specification for technical specification. http://www.s1000d.org/

. 1-5-2005. 

 118. S1000D: Five reasons why. http://www.dclab.com/s1000d_reasons.asp . 2006. Mikhail 

Vaysbukh, Data Conversion Laboratory. 

 119. Raytheon Missile Systems expands its use of iLog with acquisition of site license. 

http://www.lbs-ltd.com/LBSWeb/News/NewsDetails.aspx?Ar=Article&NewsID=50 . 

2006. 

 120. Robinson, M., Hennessey, and M.. The Implementation of AECMA 1000D. 

http://www.aecma.com/Presentation_Download/downloads/The_Implementation_of_A

ECMA_1000D_M_Robinson.pdf . 2006. LBS & General Dynamics Canada. 

 121. Subrahmanian, E., Sudarsan, R., Fenves, S. J., Foufou, S., and Sriram, R. D., 

"Challenges in Supporting Product Design and Manufacturing in a Networked 

Economy: A PLM Perspective," Inderscience Publishers, PLM: Emerging solutions and 

challenges for Global Networked Enterprise, ISBN 0-907776-18-3,2005, pp. 495-506. 

 122. RDF- Resource Description Framework. www.w3.org/RDF/ . 2006. 

 123. KIF-Knowledge Interchange Format. http://logic.stanford.edu/kif/kif.html . 2006. 
65

 124. ISO 10303-11: 1994, Industrial automation systems and integration -- Product data 

representation and exchange -- Part 11. Description methods: the EXPRESS language 

reference manual. 

 125. Schenck, D., and Wilson, P. R., Information modeling: the EXPRESS way, Oxford 

University Press, New York,1994. 

 126. Booch, G., Rumbaugh, J., and Jacobson, I., The United Modeling Language User 

Guide, Addison-Wesley1997. 

 127. OMG. UML 2.0 OCL Specification. http://www.omg.org/cgi-bin/doc?ptc/03-10-14 . 

2004. 

 128. Process Specification language (PSL) . http://www.nist.gov/psl . 2006. 

 129. Bock, C., "Systems Engineering in the Product Lifecycle," International Journal of 

Product Development, Special Issue on Product Lifecycle Management, 2004. 

 130. ISO/DIS 10303-214:2000, Product data representation and exchange: Integrated 

application resource: Application protocol: Core data for automotive mechanical design 

processes. International Organization for Standardization (ISO), Geneva, Switzerland. 

 131. Lubell, J., Peak, S. S., Srinivasan, V., and Waterbury, S. C., "STEP, XML, AND UML: 

Complementary Technologies," Vol. CIE-2004-141, Proceedings of DETC 2004: 

ASME 2004 Design Engineering Technical Conferences and Computers and 

Information in Engineering Conference September 28–October 2, 2004, Salt Lake City, 

Utah USA,2004. 

 132. Web3D: Open Standards for Real-Time 3D Communication. http://www.web3d.org/ . 

2005. 

 133. Wang, M. Y. and Wang, X., "A level-set based variational method for design and 

optimization of heterogeneous objects," Computer-Aided Design, Vol. 37, No. 3, 2005, 

pp. 321-337. 

 134. OpenGL - The Industry Standard for High Performance Graphics. 

http://www.opengl.org/ . 2006. 

 135. OpenML - The Standard for Dynamic Media Authoring. 

http://www.khronos.org/openml/ . 2006. 

 136. Sowa, J. F. and Zachman, J. A., "Extending and Formalizing the Framework for 

Information Systems Architecture," IBM Systems Journal, Vol. 31, No. 3, 1992, pp. 

590-616. 

 137. DoD Architecture Framework Working Group, DoD Architecture Framework Version 

1.0, Volume I: Definitions and Guidelines. 

http://www.defenselink.mil/nii/doc/DoDAF_v1_Volume_I.pdf . 2004. US department 

of defense. 

 138. A Practical Guide to Federal Enterprise Architecture. 

http://www.cio.gov/archive/bpeaguide.pdf . 2001. 

 139. RM-ODP: The Reference Model for Open Distributed Processing. http://www.rmodp.net/ . 2005. 

 140. CORBA. http://www.cs.wustl.edu/~schmidt/corba-overview.html . 2006. 

 141. The Standardization newsletter, No 46. 

http://www.dsp.dla.mil/newsletters/archive/news9407.pdf . 1994. US department of 

defense. 

 142. Galloway, A. R., Protocol, how control exists after decentralization, The MIT 

Press2001. 

 143. The Internet Engineering Task Force. http://www.ietf.org . 2006. 

 144. Brooks, F. P., The Mythical Man-Month: Essays on Software Engineering, 20th 

Anniversary Edition, Addison-Wesley Professional, Boston, MA, USA2005. 
66

 145. Denno, P. and Thurman, T., "Requirements on Information Technology for Product 

Lifecycle Management," International Journal of Product Development - Special Issue 

on PLM, Vol. 5, No. 1, 2005. 

 146. CCSDS 650.0-B-1: Reference Model for an Open Archival Information System 

(OAIS). Blue Book. Issue 1. ISO 14721:2003. 

http://public.ccsds.org/publications/archive/650x0b1.pdf . 2005. Consultative 

Committee for Space Data Systems. 

 147. David, P. A. and Foray, D., "Economic Fundamentals of the Knowledge Society, 

Policy Futures In Education," An e-Journal : Special Issue: .Education and the 

Knowledge Economy, Vol. 1, No. 1, 2003. 

 148. C4ISR Architecture Working Group, "Levels of Information Systems Interoperability 

(LISI): C4ISR Architecture Working Group Final Report," 1998. 

 149. Mick, R.. Defining and Measuring Interoperability. ARC Insights, Insight 2004-43 . 

2004. 

 150. Srinivasan, V.. Open Up PLM Systems. Design News . 2004. 

 151. Simon, H. A., "Architecture of complexity," Proceedings of the American 

Philosophical Society, Vol. 106, 1962, pp. 467-482. 

 152. The National Digital Information Infrastructure and Preservation Program. 

www.digitalpreservation.gov . 2006. 

 153. Long Term Data Retention (LTDR). 

http://pdesinc.aticorp.org/long_term_data_retention_pilot.html . 2006. PDES, inc. 

 154. Iyer, R.. PLM for the US Army, Presentation at 7th NASA-ESA Workshop on Product 

Data Exchange. http://www.marc.gatech.edu/events/pde2005/presentations/ . 4-18-

2005. 

 155. Rentz, R., "STEP Program Summary 2005," South Carolina Research Authority 

Integration Systems Group, Nov. 2005. 

 156. SCRA. http://scra.org/04_rr.shtml . 2006. 

 157. Mokey, J.. Teleconference. 4-12-2006. ARDEC, Picatinny Arsenal, NJ. 
67

 Appendix A: Product lifecycle and the supply chain 

management: An investigative study 

To understand clearly the status of PLM support and the role of standards in the related 

activities of US Army, we developed this questionnaire and discussed it during our site visits 

and interviews at various US Army Research Centers. 

NIST is investigating the full cross-functional process scope of Product Lifecycle Management 

(PLM) to better drive development of appropriate interoperability standards. As companies 

increasingly adopt outsourcing and globalization practices, they are focused on product 

development, sales and marketing and supply chain coordination. PLM becomes the critical 

mechanism to provide competitive advantage by bridging the gap between these functional 

silos to enable rapid and effective product launch, sustainment and disposal. 

Figure 20: Epicycles nature of PLM

However, the overall scope of processes comprising PLM, the specific needs across industries, 

and the priorities are not well understood. Also, it is believed that the available tools are limited 

in their ability to holistically support PLM in its entirety. 

We would greatly appreciate if you would provide your input to this study by responding to the 

questions that follow. All individual responses will be kept confidential. Only summary results 

will be published. Also, we will be glad to provide you with the summary results and the 

overall results of our study. 

z

z

z

z z

z

z

z

RESOURCES

 HUMAN

 INFORMATION

 COLLABORATION 

 INFRASTRUCTURE

– ORGANIZATION 

DESIGN ACTIVITIES, TOOLS

DESIGN ANALYSIS 

V&V

PERFORMANCE

QUALITY 

MANUFACTURING 

LOGISTICS

SUPPLY CHAIN

DISTRIBUTION 

PROCUREMNT

PRODUCT IN USE AND SOCIETAL 

FEEDBACK

PLM 

DESIGN 

 CONCEPTUAL 

 PRODUCT 

 PROCESS 

PRODUCT DESIGN, 

EVOLUTION, PRODUCT RESEARCH, 

DEMAND, NEED FOR SOCIETY, REWARD, DISPOSAL

SPECIFICATION BIRTH

TECHNOLOGY

FORMAL/INFORMAL REP.

MODELING LANGUAGES

ONTOLOGY, KR

STANDARDS& BEST PRACTICES
68

This questionnaire is divided into two parts. Part one deals with Product Data Exchange and 

Standards. To deliver a quantum improvement in OEM and supplier productivity, the 

Manufacturing Engineering Laboratory of the National Institute of Standards and Technology 

(NIST) and a private army contractor are conducting this study in the area of standards required 

for Product Lifecycle Management (PLM) on behalf of the United States Army Product Data 

and Engineering Working Group (PEWG). The US Army is interested in those aspects of PLM 

most critical to US industry and the US Army, in particular relating to development, 

manufacturing and sustainment of complex products. The purpose of these questions is to help 

the Army identify applicable data exchange standards. Part Two deals with current state of 

PLM challenges and requirements for supply chain integration issues. Specifically we are 

seeking to determine: 

• Current state of PLM challenges and requirements, including supply chain integration 

issues. 

• Identification of technology gaps, and critical development and interoperability needs. 

• Industry view of critical development areas in processes and technologies. 

GLOSSARY 

BOM Bill Of Materials 

CAD Computer Aided Design 

COGS Cost of Goods Sold 

CTO Configure To Order 

DfX Design for X, such as Design for Manufacturing, Design for Six Sigma

EAI Enterprise Application Integration 

ECO Engineering Change Order 

EII Enterprise Information Integration 

EOL End Of Life 

ETL Extract, Transform, Load 

ETO Engineer to Order 

IT Information Technology 

MTO Make To Order 

MTS Make To Stock 

NPI New Product Introduction 

OTD On-Time Delivery 

PDM Product Data Management 

PLM Product Lifecycle Management 

SCM Supply Chain Management 

SCOR Supply Chain Operations Reference 
69

PART ONE: PRODUCT DATA EXCHANGE AND STANDARDS 

The investigative study consists of 12 sections: 

1 RESPONDENT/ORGANIZATION INFORMATION

2 PLM DEFINITION

3 IMPORTANCE AND VALUE

4 EXCHANGE OF PRODUCT DATA

5 APPLYING STANDARDS TO ENABLE THE EXCHANGE OF PRODUCT DATA

6 CURRENT APPLICATION CAPABILITIES

7 REPRESENTATION OF INFORMATION

8 FUTURE CAPABILITIES

9 PLM-SCM INTEGRATION – IMPORTANCE AND VALUE

10 PROCESS

11 ORGANIZATION

12 TECHNOLOGY AND DATA

RESPONDENT/ORGANIZATION INFORMATION 

Name 

Title 

Name of Organization 

Job responsibility/Organizational level 

Phone Number 

E-mail 

Mailing Address 

Is the information provided in this study specific to the entire organization? 

 Yes No 

If no, please indicate what percentage of your organizations entire product data exchange 

that is associated with the response given in the following questions. 

 % 

PLM DEFINITION 

What is the best definition of Product Lifecycle Management as used in your company? 

A vision or a business strategy for creating, sharing, managing information about product, 

process, people and services within and across the extended and networked enterprise covering 

the entire lifecycle spectrum of the product. PLM in some companies is essentially the 

integrated product development function. In others it is used in the context of software 

solutions. As the importance and scope of the challenge gains increased recognition, definitions 

range from enabling capabilities such as information management to a complete crossfunctional activity. 

 Same as Product Development 
70

 A cross-functional activity that is responsible for all processes from concept to disposal 

 Management of product related information that is needed by different parts of the 

organization 

 An IT solution 

 Other, please specify 

IMPORTANCE AND VALUE 

What would you say is the importance of PLM to your company at this time? 

 One of the most important issues for current and future success 

 Important, but other issues take priority at this time 

 Not so important 

EXCHANGE OF PRODUCT DATA 

In general terms, please explain why Product Data is exchanged? 

 

What type of product data is exchanged in different lifecycle phases (Design, Prototype, 

Manufacturing, Maintenance and Retirement/Recycle) and how is it exchanged? 

Exchanged 

with 

Method for exchanging 

product data 

Inform

al 

Formal 

Product Data 

Types 

Lifecycle 

Phase 

SupplierCustomerInternalPhone/faxElectronic formatElectronic format (proprietary protocol)Electronic (standard based)

Frequency 

(files 

transferred 

per month) 

Product 

requirements, 

functions and 

behavior (non 

geometric) 

 

Geometrical 

representation of 

product (CAD) 

 

BOM information 

Manufacturing 

Process 

Build Order Info / 

Order 

Management 

 
71

Exchanged 

with 

Method for exchanging 

product data 

Change 

Management 

Repair and Service 

BOM 

Environmental 

Regulatory 

Other (please 

describe): 

 

Additional comments: 

 

APPLYING STANDARDS TO ENABLE THE EXCHANGE OF PRODUCT DATA 

If you are using standards for exchanging product data, please specify what standards are 

applied and what data they are used for. Also, please add the version of the standard. 

(Include standards and de facto formats such as: IGES, EIA, SET, VDA-FS, EDIF, 

POSC, DXF, S1000D and STEP. What application protocols are used?). 

 

Why do you apply the standards for exchanging data? 

 

What translation method is used (Standard-based, Point-to-point proprietary interface)? 

 

How significant would the financial impact be if international standards or open 

standards-based-transfer protocols were available for automatically and seamlessly 

sharing the following types of information with customers and suppliers? 

Negative Impact Positive Impact 

Type of activity 

Significant negative financial impact Considerable negative financial impactSmall negative financial im

pact 

No financial impact Small positive financial impact Considerable positive financial im

pact 

Significant positive financial im

pact 

Authoring Tool (CAD) 

Authoring Tool (CAM) 

Authoring Tool (PDM) 

BOM Processor 

Configuration Management 

Data Model 
72

Negative Impact Positive Impact 

Type of activity 

Significant negative financial impact Considerable negative financial impactSmall negative financial im

pact 

No financial impact Small positive financial impact Considerable positive financial im

pact 

Significant positive financial im

pact 

Database Management 

Data Integration 

Systems Integration 

Workflow for Process 

Planning 

Program Management 

Training Manuals 

Simulation 

User Interface 

Visualization 

Web-Enabled Networking 

Supply Chain and Logistics 

(Provisioning) 

Supply Chain and Logistics 

(Cataloging) 

Maintenance 

Prognostics / Diagnostics 

Readiness 

Recycling / Disposal 

Other: (please specify) 

 

What problems (e.g. lack of interoperability, overlapping/contradictory standards, and 

gaps between standards) have you encountered when applying standards for exchanging 

data? 

 

CURRENT APPLICATION CAPABILITIES 

Does your current application (CAD/PDM/PLM/ERP) allow you to export any type of 

information to be exchanged? 

 Yes No 

What type of IT tools constitutes your PLM system and what are their roles: 

Type of activity 

Toolset Name and 

Version Role 

Authoring Tool (CAD) 

Authoring Tool (CAM) 

Authoring Tool (PDM) 
73

Type of activity 

Toolset Name and 

Version Role 

BOM Processor 

Configuration Management 

Data Model 

Database Management 

Data Integration 

Systems Integration 

Workflow for Process Planning 

Program Management 

Training Manuals 

Simulation 

User Interface 

Visualization 

Web-Enabled Networking 

Supply Chain and Logistics 

(Provisioning) 

Supply Chain and Logistics 

(Cataloging) 

Maintenance 

Prognostics / Diagnostics 

Readiness 

Recycling / Disposal 

Other: (please specify) 

 

What capabilities do the IT systems of your organization have with respect to product 

requirements, functions, and behaviors? 

Yes No Don’t know Unimportant capability Important capability Very important capability 

Can your IT systems automatically 

generate a BOM for a product from a 

representation of product requirements, 

functions, or behavior? 

Can your IT systems see all requirements, 

functions, and behaviors affected by a 

swap of components? 
74

How flexible are the capabilities of your organization to share each of the following types 

of information with customers? 

Product Data 

Type 

Low 

flexibility: 

plant 

information 

systems are 

integrated with 

the 

information 

systems of a 

single 

customer

Medium 

flexibility: plants 

share information 

w/ customers based 

on a proprietary 

electronic protocol 

set up individually 

with each customer

High flexibility: 

plants share 

information with 

customers 

automatically using 

a generic, standards 

based transfer 

protocol

High 

(manual) 

flexibility: 

plants share 

information 

with 

customers 

through 

manual 

processes

Product 

requirements, 

functions and 

behavior (non 

geometric) 

Geometrical 

representation of 

product CAD) 

BOM 

information 

Manufacturing 

process 

information 

Build order 

information / 

order mgmt. 

Change 

Management 

information

Repair and 

service BOM 

information 

Environmental 

regulatory 

information 

 Different software products generate output for similar or related information using 

different XML forms (use different XML tags for the same information). Is there a need 

to map between XML streams (mapping meta schemas) when sharing data between 

software created by different vendors? 
75

How 

important 

is the XML 

output? 

Can you 

change 

the meta 

schema 

used to 

generate 

XML? 

Can you 

read an 

XML 

file? 

Are the 

XML input 

and output 

complete? 

 

Product Data 

Type 

No 

Don’t know 

Yes 

 (if Yes, 

please fill 

in the 

columns 

to the 

right) 

Low importance Medium importanceHigh importance Yes No Yes No Yes No 

Product 

requirements, 

functions and 

behavior (non 

geometric) 

Geometrical 

representation 

of product 

(CAD) 

BOM 

information 

Manufacturin

g process 

information 

Build order 

information / 

order 

management 

Change 

Management 

information 

Repair and 

service BOM 

information 

Environmenta

l regulatory 

information 

What software products do you presently use to create, store, and support Logistics 

Support Analysis Record (LSAR) information? 

 
76

What software products do you presently use to create, store, and support Interactive 

Electronic Technical Manuals (IETM)? 

 

What Data Standard/Specification (e.g. S1000D) do you use for IETM publications? 

 

Should it become a requirement of the Army, do you have the capability to 

handle/transmit all IETM publications in the S1000D data exchange format once the 

specifications are provided? 

 Yes No 

If you are an Original Equipment Manufacturer (OEM), do you provide digital 

publications, hard copy, or aperture cards to the client or are they strictly used for inhouse purposes? If yes, please specify which. 

 

REPRESENTATION OF INFORMATION 

How is the information represented? 

Product Data Type 

Spreadsheet 

or other 

generic tool 

Document 

Management 

System 

Custom 

application 

Commercial 

off-the-shelf 

application 

(COTS) 

Product 

requirements, 

functions and 

behavior (non 

geometric) 

Geometrical 

representation of 

product (CAD) 

BOM information 

Manufacturing 

process information 

Build order 

information / order 

management 

Change Management 

information 

Repair and service 

BOM information 

Environmental 

regulatory 

information 

Please add other existing representation forms: 

 
77

How do you represent product requirements, functions, and behaviors (non-geometric)? 

Information 

not 

represented 

Information 

modeling tool 

that tracks 

functional 

relationships 

between entities 

Text 

Document 

Don’t know 

What means are 

used to represent 

product 

requirements? 

What means are 

used to represent 

product 

functions? 

What means are 

used to represent 

product behavior? 

Other: 

 

If you are using or planning to use visual information modeling languages (for example 

UML) and ontologies for product modeling? (Ontology is defined as: A formal explicit 

specification of shared concepts), please describe the application? 

 

FUTURE CAPABILITIES 

Is your organization interested in representing and exchanging other information than 

current capabilities allow for at this time? 

 Yes No 

If yes, please specify what other information? 

 

At what level of detail? 

 

Please describe any future requirements to systems and applications. What are the key 

benefits in relation to data exchange? 

 

Please list standards for enabling product data exchange that you would consider 

applying in the future and for what aspect of PLM. 

 

Additional Comments (For Part One) 
78

Please add any additional comments: 

 

PART 2: PRODUCT LIFECYCLE AND THE SUPPLY CHAIN MANAGEMENT: A 

STUDY OF INDUSTRY PRACTICE 

PLM-SCM INTEGRATION – IMPORTANCE AND VALUE 

How many years have you been involved in PLM or SCM related functions? 

< 2 Years 2-5 Years 5-10 Years 10-20 Years > 20 Years 

Would you be interested in participating in a 1 hour phone conversation to discuss our 

findings and provide additional insight? 

Yes No 

Are you interested in receiving the final report of our study? 

Yes No 

Would you be interested in participating in a workshop to discuss future directions to 

advance knowledge, practices and technologies in PLM-SCM integration? 

Yes No 

What would be the value of better integration between PLM and SCM activities? 

From being ready to take advantage of higher than expected demand for new products, 

keeping procurement/manufacturing/fulfillment costs low during the entire lifecycle, and 

minimizing the markdown and inventory obsolescence costs during end-of-life stage, our 

hypothesis is that the potential impact on all financial drivers is significant. 

• Increase in revenue 1% 5% 10% >10% N/A 

• Increase in margin 1% 5% 10% >10% N/A 

• Lower development costs 1% 5% 10% >10% N/A 

• Lower supply chain costs 1% 5% 10% >10% N/A 

• Lower procurement costs 1% 5% 10% >10% N/A 

• Lower inventory write-offs 1% 5% 10% >10% N/A 

• Higher asset utilization 1% 5% 10% >10% N/A 

What key issues are driving or will drive the need for better PLM-SCM integration 

within your company? 

Companies today are faced with a variety of internal and external pressures that increase the 

complexity and variability in the product development and supply chain activities. We 

hypothesize that better PLM-SCM integration will be the most critical approach to handle 

these pressures and continue to gain business value 
79

 Off-shoring to low-cost regions 

 Outsourcing to contract manufacturing 

 Regulations and compliance 

 Increased competition from low-cost manufacturers 

 Rapid product commoditization 

 Financial issues (revenue/margin/cost/writeoffs) 

 Supply chain operational performance (OTD, turns) 

What metrics are used for Product Lifecycle Management? Which parts of the 

organization are measured on these metrics? 

The following metrics are those that are in common use in most companies. Because PLM 

is a cross-functional activity, it impacts and is impacted by a variety of metrics, depending 

on the product lifecycle stage. Standard metrics are based on the SCOR definition. For 

others, a basic definition is provided. 

Metrics Sales and 

Marketing 

Product 

Development 

Supply 

Chain 

Procurement 

Time to Market 

Product Development Cost 

Initial Promotion Cost (cost 

of promoting the new 

products to gain market 

recognition) 

 

Commoditization Rate 

(number of weeks or months 

after introduction when 

competitive products appear 

on the market and the 

premium margin opportunity 

is eroded) 

 

Number of ECOs 

New Component Percentage 

(ratio of new components to 

all components in the 

product) 

 

New Supplier Percentage 

(ratio of new suppliers 

needed versus all suppliers 

used for the product) 

 

Stockout Percentage 

(percentage of time product 

is unavailable) 

 

New Product Introduction (NPI) Metrics 

Stabilization Period (number 
80

Metrics Sales and 

Marketing 

Product 

Development 

Supply 

Chain 

Procurement 

 of weeks or months when 

product reaches mature 

stage, defined as a 

combination of demand 

stabilization and engineering 

change stabilization) 

Forecast Accuracy 

Inventory Turns 

OTD Performance 

Stable Lifecycle Metrics Logistics Cost 

Excess and Obsolescence 

Costs 

Markdown Cost 

Lifecycle Period (total 

number of weeks or months 

from product introduction to 

disposal) 

 

End of Life (EOL) Metrics 

Disposal Cost (cost 

associated with returns and 

disposal of product to meet 

compliance requirements) 

 

What are typical values for the following metrics? 

An aggregate estimate of metrics based on common experience is sufficient. 

Average Range 

Time to Market 

Forecast Accuracy 

Delivery Performance 

Average Product Lifecycle Period 

Inventory Obsolescence Cost as a percent of COGS 

Average Gross Margin over Lifecycle 

PROCESS 

What supply chain capabilities and constraints are explicitly considered during the 

product design process? 

During the design process, common practices for evaluating manufacturing, procurement 

and supply chain readiness usually involve concepts such as Concurrent Engineering and 

DfX. Increasingly, there is focus on design reuse, including component and supplier reuse. 

We hypothesize that effective PLM will require detailed understanding and reuse of 

existing supply chain capabilities and constraints. 
81

Conceptual Design Detailed 

Design 

Prototyping Testing

Approved Parts List 

Approved Vendor List 

Manufacturing Capability 

and Constraints 

Logistics Capability and 

Constraints 

Available Capacity 

Available Inventory 

What processes are used to evaluate the supply chain readiness during product 

development? 

As supply chains become more complex with increasing use of partners through 

outsourcing, preparing a supply chain for a new product can be involved and time 

consuming. We hypothesize that not only the PLM-SCM integration should be closed-loop 

to ensure that detailed supply chain readiness is assessed and required capabilities 

developed to keep up with the increasing pace of product development and shortening 

product lifecycles. 

 New Supplier/Component Qualification 

 Supply Risk Analysis (the potential need to establish new inventory points, 

transportation routes or production capabilities to meet design requirements) 

 Manufacturing Strategy Analysis (MTS, MTO, CTO, ETO) 

 Supply Bottleneck Analysis (identification of capacity and material constraints and 

corresponding impact on product launch plans) 

 Obsolescence Analysis (impact on existing inventory) 

 Up/down Volume Flex Analysis (internal and external capacity analysis to cope with 

demand variability during product introduction) 

During product launch, what information is used to make trade-offs between market 

opportunity and supply chain costs? 

The trade-off involves determining product launch timing that optimizes the overall margin. 

Earlier introduction provides greater price premium, while increasing costs of preparing the 

supply chain quickly, and markdown and write-off costs for products that are likely to be 

cannibalized. 

 Demand (Volume and Price) Elasticity 

 Inventory Markdown and Write-off Costs 

 Supply Ramp Cost 
82

In which SCM processes are product lifecycle issues currently considered? 

 Supply Chain Design 

 Strategic Sourcing 

 Customer Collaboration 

 Program Management 

 Demand Planning 

 Inventory Planning 

 Demand Supply Balancing 

 Supplier Collaboration 

 Factory Planning 

 Distribution Planning 

 Transportation Planning 

 Warehouse Management 

 Production Scheduling 

 Transportation Management 

 Service Parts Management 

 Returns Management 

Is the supply chain managed differently during the different stages of a product’s 

lifecycle? 

Supply chains employ business rules to account for variations in product characteristics. 

However, we hypothesize that these rules are established on an ad-hoc basis, without 

explicitly considering lifecycle issues. 

 Lower performance targets (longer lead times, lower service levels) during NPI/EOL 

stages versus higher targets during mature stage 

 ETO/CTO during NPI/EOL stages versus MTS during mature stage 

 Single inventory storage during NPI/EOL versus distributed inventory management 

during mature stage 

 In-house manufacturing during NPI/EOL versus contract manufacturing during mature 

stage 

ORGANIZATION 
83

Which business function has primary responsibility for PLM? 

 Product Development 

 Marketing 

 Product Line or Business Unit 

 Supply Chain 

 Procurement 

 IT 

 Not currently defined 

Is there an explicitly defined role for coordinating product lifecycle issues between the 

various functions? 

 Yes, resides in one of the functional areas. Please specify: Product Development, 

Marketing, Supply Chain, Procurement 

 Yes, is a separate cross-functional role 

 No, role does not exist. Coordination is ad-hoc 

TECHNOLOGY AND DATA 

Which commercial solutions, if any, are used to enable the following processes? 

 SCM 

 EAI 

 ETL 

 EII 

 Data Warehousing 

 Enterprise Reporting 

 Master Data Management 

How is PLM-SCM integration enabled? 

 Manual processes 

 MS Excel and other unstructured tools 

 In middleware such as EAI/ETL 

 Within SCM system with data imported from PLM system 
84

What product lifecycle information is used in SCM processes? 

 Design concept 

 Unreleased BOM 

 Component effectivity dates 

 Design alternatives 

 Engineering change orders 

 Other (Specify) 

What is the frequency of update of information from PLM to SCM? 

 Event-based as new designs are created 

 Weekly 

 Monthly 

 Quarterly 

 Combination, weekly for ECOs, monthly for demand elasticities and new requirements, 

quarterly for new design concepts 

 Other (Specify) 
85

Appendix B: Army-Related Projects Employing PLM 

Standards 

A sampling of projects specific to the Army 

The whole idea for the Army’s PLM strategy is to be proactive, not reactive. To this end, there 

have been several projects identified and pilot trials done. The following list is not intended to 

be exhaustive, but to give an overview of how the Army and DoD are addressing the 

integration of ISO 10303 into their product lifecycle process. 

HMMWV data exchange with AM General 

AM General, the Army’s contractor for the HMMWV (High Mobility Multi-Purpose Wheel 

Vehicle), used Teamcenter, UGS PDM software. AM General maintains the vehicle’s 

engineering CAD master database in a 3D Unigraphics format. Since the Army does not have 

any UG capabilities, it is accepting pdf files for the drawings on CD media, importing the data 

into the Army’s Windchill PDM system. A schematic diagram of the data exchange between 

AM General and TACOM is shown in Figure 21. Duplicating the data in an asynchronous 

fashion adversely impacts data integrity as version control and updates are managed by AM 

General, and not getting to the Army at the same time. TARDEC and AM General have begun 

to use ISO 10303-214, Conformance Class 6, PDM Schema for exchange with 10303-28 XML 

file formats. The Army is not doing any CAD translation of the information, only PDM 

translation; hence, still having two sources for product data. Federation, another participating 

software vendor, adapted its software to the PDM schema that is now being used to broker the 

exchange. Federation has an adaptor (extracts, converts) and a server (web-server broker). 

Using the Federation Servers allows automatic product data update notification to approved 

users (Army). Recently, AM General has migrated out of Teamcenter to SAP PLM. 

Measured Impact from Change: By progressing from pdf format/CD transport to web-servicebrokered product data exchange TARDEC anticipates measurable impact and cost-savings. 

With the current process it takes several days to receive the data, upload the data, and make 

the necessary changes to validate the data. This time can be cut down to a few hours when the 

proposed piloted solution is put into production. 
86

Teamcenter Federation

Server

Federation

Server Windchill

Internet

STEP

Data synchronization

Applications

Collaboration Design Review Provisioning Assembly Simulation UID Suppliers

Teamcenter Federation

Server

Federation

Server Windchill

Internet

STEP

Data synchronization

Applications

Collaboration Design Review Provisioning Assembly Simulation UID Suppliers

Figure 21: Data Exchange between AM General & TACOM [154].

Bradley data exchange with BAE 

Another STEP-based implementation at TARDEC involves the Bradley Fighting Vehicle. 

TARDEC is currently implementing a pilot project to show how data can be automatically 

exchanged between the OEM for the Bradley, BAE Systems, and TACOM (Figure 22). The 

Bradley configuration data is stored in a database called CMSTAT and it also serves as the 

master repository for the Bradley product data. TACOM would like for this data to be pushed 

to TACOM’s Windchill using the STEP PDM Schema, to enable various TACOM production 

and procurement functions. In this project, the two systems – CMSTAT and Windchill are not 

federated, but a push approach has been adopted because BAE Systems has not segregated the 

data among its various proprietary programs from the Government data. BAE is also in the 

process of moving to a PDM, Windchill, as required by the Army’s Future Combat Systems 

contract. The developed STEP functionality could also help BAE migrate their data to 

Windchill. 
87

Figure 22: Data exchange between BAE Systems and TACOM 

Abrams UID Pilot with GDLS 

The Abrams Tank project has 200 tanks coming in for RESET/RECAP15. TACOM is currently 

marking many of the components within the Abrams tank using UID. General Dynamics Land 

Systems (GDLS) is responsible primarily for the components’ marking for this project, and is 

using an Oracle PLM system to track the data. The Army is working with General Dynamics 

to set up a process to access the BOM information using ISO 10303-239. The same standard 

will also be used to transmit the UID embedded item information to the DOD UID Registry. 

Items being chosen for tagging must be great than $5K and mission critical (if item fails, the 

system fails). Once tagged, each tank’s UID can point to all the unique information, 

maintenance records, metadata, schedules, etc., in an RFID-readable way. 

U.S. Army National Automotive Center (NAC), N-STEP 

Considered the flagship initiative for Army’s piloting and use of ISO 10303 is the National 

Automotive Center STEP-Enabled Production of components program, or N-STEP. Started in 

FY2002, the intent of the N-STEP project was to improve the machined part supply to the 

Army’s ground combat systems. Initial efforts went into supporting the development of the ISO 

application protocols among international partners (historically AP224, and more recently 

AP240). Pilot demonstrations conducted showed a 40-55% process planning lead time 

reduction for machined parts and assemblies [155]. With the deployment of SCRA-developed 

technology and processes completed, the focus now is on the full-scale production of parts and 

assemblies, enhancement of SCRA’s STEP-enabling software tools, and the commercialization 

of those tools so that a broader spectrum of DoD’s partners and suppliers can benefit from them 

[156].

LEAN munitions 

ARDEC is leveraging the work previously accomplished under N-STEP to conduct its own 

spare parts delivery initiative. The Lean Munitions program started in FY2003, plans to put into 

production a 3-D "Lean Munitions" design and manufacturing lifecycle support system by 

 

15 RECAP activity strips and replaces everything in the vehicle and sets the vehicle’s odometer back 

to zero. RESET is about 80/20% ratio, bringing the vehicle back to 80% of its original 

performance.

STEP 

Part 21 File 

STEP PDM 

Translator 

for CMSTAT 

STEP PDM

Translator 

For 

Windchill

Windchill 

Export

Import 
88

applying some functionality from STEP APs 203, 224, and 240 to enable more timely and cost 

effective production of machined parts and assemblies needed for the Army’s munitions and 

armaments systems. To date, most of the exchange has focused on 2D Autocad and 

ProEngineer exchange [157]. With delivery time reductions of up to 55% already being 

realized, ARDEC envisions an annual cost savings of as much as $35M upon program 

completion [156].

TACOM/Army Ground systems integrated lean enterprise (AGILE) 

Started in 2005, AGILE is to establish the infrastructure and processes to enable STEP-based 

product data exchange between TACOM’s organic industrial sites for more efficient RECAP 

and RESET activities. The program is currently being executed at Rock Island Arsenal, 

Anniston Army Depot, and Watervliet Arsenal. The program intends to develop a common set 

of processes and data standards to enable sharing of work load among TACOM’s various 

depots and arsenals in support of surge requirements. AGILE has also successfully integrated 

two STEP APs – AP224 and AP238 to enable a seamless flow of data between CAD/ CAM 

systems. The output data will then be sent to NC machines for automated manufacturing. 

AGILE has processed 117 operational production parts through the system concentrating on 

complex parts that stretch the system, especially at Watrevliet. Another focus of AGILE is to 

apply AP223 to develop cast parts. 

Electronic Logistics Information Trading Exchange (ELITE) 

The Electronics Logistics Information Trading Exchange (ELITE) effort interconnects military 

services with private industry to share maintenance actions performed on aircraft and aircraft 

components. Currently, this data is shared in a proprietary format between a single 

manufacturer, Sikorsky Aircraft, and a single Army recipient system. ELITE expands the 

current effort in several key areas: 

• PLCS-based Data Exchange (DEX) format is being exploited as the standard canonical data 

exchange format 

• Additional service systems that conduct or track aircraft maintenance actions are 

participating 

• Expanded uses of the data beyond maintenance actions are being considered 

The ELITE effort expands the current data flow to transform the maintenance action data into 

PLCS-compliant DEX format prior to transmission. The Aviation DEX defines the structure of 

the PLCS compliant transactions. In addition to exploitation of a standard format, ELITE also 

expands the number of participants. The Navy Aviation Maintenance system, will also 

participate in data sharing. 

Some tri-Service initiatives 
89

CALS 

The Continuous Acquisition and Lifecycle Support16 (CALS) had it tri-service beginning in 

1985. In a response to a NIST report evaluating and recommending various international data 

exchange standards, the Office of the Secretary of Defense kicked off, what became a multidecade initiative. Building international military involvement and momentum over the last two 

decades, it is still alive as a multi-national initiative today. CALS encompasses a host of 

interrelated activities such as business process improvement, enterprise integration and 

information technology standardization. As an umbrella tri-service program, there were several 

programs contributing to the piloting and implementation of international standards, such as 

JEDMICS and RAMP mentioned below. 

JEDMICS 

The Joint Engineering Data Management Information and Control System (JEDMICS is the 

DOD standard engineering data management and repository system. A total of twenty-two 

Army, Navy, Air Force, Marine Corps and Defense Logistics Agency sites currently use 

JEDMICS to manage over 80 million engineering drawings for more than 36,000 users. 

Additionally, several external logistic systems depend on the JEDMICS application interface to 

obtain engineering drawing data. JEDMICS capabilities support DOD logistics business 

functions, such as maintenance, repair, procurement, and re-engineering by providing 

worldwide, on-demand access to digital engineering drawings and associated data. 

The JEDMICS provides the means to efficiently convert, store, protect, process, locate, receive 

and output data previously contained on aperture cards and paper. Large engineering drawings 

and related text are scanned and stored on network-accessible digital media, providing online 

access at distributed workstations. The JEDMICS application also provides the capability to 

accept data directly from various other digital media processes. Quoted from [159]. 

Rapid acquisition of manufactured parts (RAMP) 

Started in the late 1980s, and led by the Naval Air Systems Command, RAMP focused on the 

manufacturing system is to produce and deliver quality mechanical parts or printed wiring 

assemblies within an average of 27 days of receiving an order. Using the concepts of functional 

equivalence, modularity, standardized communications, and reduction of administrative lead 

times, the manufacturing runs proved concepts of large capability manufacturing (e.g., 15,000 

parts), ordered in very small lot sizes (e.g., 4). Quoted from [160]. 

Anniston Army Depot in Anniston, AL cited its experience with RAMP as a “Best Practice”17. 

In 1995, ANAD successfully completed the installation of the RAMP system, and started 

producing parts. Since the installation, the system has been used successfully and has reduced 

the average in-shop production time to less than 30 days with no increase in personnel. 

RAMP lasted for twelve years, with over $250M investment, with legacy implementations at 

over 35 installations across the United States, United Kingdom, and Japan. Manufacturing 

execution systems continue to operate at several DoD industrial facilities [155]. One pilot 

 

16 Those involved from industry preferred to refer to CALS as, “Commerce at Light Speed.” 

17 This best practice, “Flexible Computer Integrated Manufacturing/Rapid Acquisition of Manufactured Parts,” is 

described at http://www.bmpcoe.org/bestpractices/internal/anad/anad_3.html . 
90

project, conducted by Focus: HOPE Center for Advanced Technologies, demonstrated the 

feasibility and practicality of using STEP-based (AP203, AP224) Technical Data Packages 

(TDPs) when acquiring spare parts. “The data collected were from a 17-part sample: three 

from the Naval ICP - Philadelphia, nine from the Defense Logistics Agency, and five from the 

Tank - automotive and Armaments Command. An analysis of the data revealed: Focus: HOPE 

experienced from 30% to 42 % savings in the time required to prepare a bid using the bid 

module and GPPE software suites. An additional 25 % to 40 % savings were realized in micro 

level process planning utilizing the STEP files and the GPPE macro level process planning 

output. The RAMP-validated STEP files were observed to be 100% accurate. The use of STEP 

eliminated the time necessary to prepare a solid model prior to commencing micro level 

process planning. As a result of the accurate solid model, significant time was saved on the 

shop floor as compared to conventional operations. These savings were evident because the 

usual manufacturing problems experienced due to the typical Computer Aided Design (CAD) 

modeling errors were eliminated.” Quoted from [161]. 
Appendix C: Product lifecycle-related integration standards The proposed typology primarily reflects the content to be communicated and implies the appropriate expressivenes

for each type of content. Within each type, individual standards may be classified as to origin, intent, development pextent, scope. Type Zero is represented by standards for implementation languages, and is not exemplified in table 

standardized languages include programming, scripting, assembly level, and other computable languages used to im

Type Two, and Type Three standards. Examples of Type Zero include: Basic, FORTRAN, C, C++, Java, C#, Prolo

OpenGL. 

Type One: Information Modeling Standards Type One standards are for semantically rich modeling languages, and are based on different forms of logic.

Acronym Standard Functional Description 

CL Common Logic a language designed for use in the interchange of 

knowledge among disparate computer systems. It will be a logically comprehensive language with a declarative semantics, and it will provide for the representation of knowledge about knowledge. The standard will be divided into three parts. Part 1 (Knowledge Interchange Format and Conceptual Graphs) specifies the semantics of a language that extends first-order logic, together with two semantically equivalent syntaxes – the Knowledge Interchange Format (KIF) and Conceptual Graphs (CG). Part 2 (Sorted Language) is an expansion of the language of Part 1 that specifies the syntax and semantics of a sorted logic. Part 3 (Metalanguage) is an expansion of the language of Part 1 that formalizes the syntax and semantics of the meta-theory of first-order logic. 

http://cl.tamu

CWM Common standardizes a basis for data modeling commonality http://www.o
Acronym Standard Functional Description 

Warehouse Metamodel 

within an enterprise, across databases and data stores. Building on a foundation metamodel, it adds metamodels for relational, record, and multidimensional data; transformations, OLAP, and data mining; and warehouse functions including process and operation. CWM maps to existing schemas, supporting automated schema generation and database loading. This makes it the basis for data mining and OLAP across the enterprise. 

m/

CycL CycL is a formal language whose syntax derives from 

first-order logic. It was created and used by Doug Lenat's Cyc Artificial Intelligence project. Ramanathan V. Guha was instrumental in the design of the language. There is a close variant of CycL known as MELD. The original version of CycL was a frame language, but the modern version is not. Rather, it is based on classical first-order logic, with extensions for modal operators and higher order quantification. CycL is used to represent the knowledge stored in the Cyc Knowledge Base, available from Cycorp. The source code written in CycL released with the OpenCyc system is licensed as open source, to increase its usefulness in supporting the semantic web. 

http://en.wik

DL Description Logic Description logics are a family o knowledge 

representation languages which can be used to represent the terminological knowledge of an application domain in a structured and formally well-understood way. The name description logic refers, on the one hand, to concept descriptions used to describe a domain and, on the other hand to the logic-based semantics which can be given by a translation into first-order predicate logic. Description 

http://en.wikion_logic 
Acronym Standard Functional Description 

logic was designed as an extension to frames and semantic networks, which were not equipped with a formal logic-based semantics. Description logic was given its current name in the 1980s. Previous to this it was called (chronologically): terminological systems, and concept languages. Today 

description logic has become a cornerstone of the Semantic Web for its use in the design of ontologies. 

EXPRESS Information 

Modeling Language 

ISO 10303-11: 1994, Industrial automation systems and integration -- Product data representation and exchange -- Part 11: Description methods: The EXPRESS language reference manual. Consists of language elements which allow an unambiguous data definition and specification of constraints on the data defined and by which aspects of product data can be specified. Deals with data types and constraints on instances of the data types. Also defines a graphical representation (EXPRESS-G) for a subset of the constructs in the EXPRESS language. EXPRESS is not a programming language. 

http://www.i

FOL First Order Logic First-order predicate calculus (FOPC) or first-order logic 

(FOL) is a system of mathematical logic, extending propositional logic (equivalently, sentential logic) and in turn extended by second-order logic. First-order logic has sufficient expressive power for the formalization of virtually all of mathematics. 

http://en.wikorder_predic

KIF Knowledge 

Interchange Format 

A language designed for use in the interchange of knowledge among disparate computer systems (created by different programmers, at different times, in different languages, and so forth). KIF is not intended as a primary language for interaction with human users (though it can 

http://logic.s
Acronym Standard Functional Description 

be used for this purpose). Different computer systems can interact with their users in whatever forms are most appropriate to their applications (for example Prolog, conceptual graphs, natural language, and so forth). Nor is KIF intended as an internal representation for knowledge within computer systems or within closely related sets of computer systems (though the language can be used for this purpose as well). Typically, when a computer system reads a knowledge base in KIF, it converts the data into its own internal form (specialized pointer structures, arrays, etc.). All computation is done using these internal forms. When the computer system needs to communicate with another computer system, it maps its internal data structures into KIF. 

ODF Open Document 

Format, short for the OASIS Open Document Format for Office Applications 

is an open document file format for saving and exchanging editable office documents such as text documents (including memos, reports, and books), spreadsheets, charts, and presentations. This standard was developed by the OASIS industry consortium, based upon the XML-based file format originally created by OpenOffice.org. 

http://en.wik

cument

OWL Ontology Web 

Language 

is a Web Ontology language. Where earlier languages have been used to develop tools and ontologies for specific user communities (particularly in the sciences and in company-specific e-commerce applications), they were not defined to be compatible with the architecture of the World Wide Web in general, and the Semantic Web in particular. OWL uses both URIs for naming and the description framework for the Web provided by RDF to add the 

http://www.w
Acronym Standard Functional Description 

following capabilities to ontologies: • Ability to be distributed across many systems • Scalability to Web needs Compatibility with Web 

standards for accessibility and internationalization 

• Openess and extensiblility. OWL builds on RDF and 

RDF Schema and adds more vocabulary for describing properties and classes: among others, relations between classes (e.g., disjointness), cardinality (e.g., "exactly one"), equality, richer typing of properties, characteristics of properties (e.g., symmetry), and enumerated classes. 

There are three sublanguages of OWL, known as OWL DL (description language), OWL Lite, and OWL Full. 

PSL Process 

Specification Language 

defines a neutral representation for manufacturing processes. Process data is used throughout the lifecycle of a product, from early indications of manufacturing process flagged during design, through process planning, validation, production scheduling and control. In addition, the notion of process also underlies the entire manufacturing cycle, coordinating the workflow within engineering and shop floor manufacturing. The goal of PSL is to create a process representation that is common to all manufacturing applications, generic enough to be decoupled from any given application, and robust enough to be able to represent the necessary process information for any given application. This representation would facilitate communication between the various applications because they would all “speak the same language.” 

http://www.n

RDF Resource integrates a variety of applications from library catalogs http://www.w
Acronym Standard Functional Description 

Description Framework 

and world-wide directories to syndication and aggregation of news, software, and content to personal collections of music, photos, and events using XML as an interchange syntax. The RDF specifications provide a lightweight ontology system to support the exchange of knowledge on the Web. 

SOAP Simple Object 

Access Protocol 

Version 1.2 provides the definition of the XML-based information, which can be used for exchanging structured and typed information between peers in a decentralized, distributed environment. 

http://www.w

SUO-KIF Standard Upper 

Ontology Knowledge Interchange Format 

Standard Upper Ontology Knowledge Interchange Format (SUO-KIF) is a language designed for use in the authoring and interchange of knowledge. SUO-KIF has declarative semantics. It is possible to understand the meaning of expressions in the language without appeal to an interpreter for manipulating those expressions. 

http://suo.ieemlhttp://www.o

SysML Systems 

Engineering Modeling Language 

is directed towards the specific domain of systems engineering. SysML is derived from the basic UML to cover the requirements, structure, behavior, parametrics, and the relation of structure to behavior (allocation) 

http://www.s

U3D Universal 3 

Dimensional 

A graphics standard that is a simple format for interactive viewing and sharing of 3D data 

http://www.a

UML Unified Modeling 

Language 

standardizes representation of object oriented analysis and design. A graphical language, its dozen diagram types include Use Case and Activity diagrams for requirements gathering, Class and Object diagrams for design, and Package and Subsystem diagrams for deployment. UML lets architects and analysts visualize, specify, construct, and document applications in a standard way. 

http://www.u
Acronym Standard Functional Description 

XML Extensible Markup 

Language 

is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. 

http://www.w

XML Schema XML Schemas express shared vocabularies and allow 

machines to carry out rules made by people. They provide a means for defining the structure, content, and semantics of XML documents. 

http://www.w

Type Two: Content standards - domains of discourse Content standards pertain to information models specifically defined for particular domains using generic informati

(Type One) or an extension of one. 

Acronym Standard Functional Description 

AECMA 2000M International 

Specification for Materiel Management Integrated Data Processing for Military Equipment 

Developed by the aerospace industry (European Association of Aerospace Industries) and its defense customers to provide common business processes and electronic communications for the logistic support of complex systems from initial procurement through their entire lifecycle. 

http://ww.aeec2000/s200

AECMA S1000D 

International Specification for Technical Publications Utilizing a 

for the procurement and production of technical publications. Whilst the title restricts its use to technical publications, it has been found through application that the principles of the specification can be applied to nontechnical publications. 

http://www.s
Acronym Standard Functional Description 

Common Source Database 

This specification has been initially developed by the AeroSpace and Defence Industries Association of Europe (ASD) --former European Association for Aerospace Industries (AECMA). The current edition has been jointly produced by ASD and the Aerospace Industries Association of America (AIA), who form the Technical Publications Specification Maintenance Group (TPSMG) to establish standards for documentation agreed by the participating nations. 

BPML Business Process 

Modeling Language 

A meta-language for the modeling of business processes http://www.o

open.org/cov

CML Chemical markup 

language 

Is a new approach to managing molecular information. It has an extensible scope as it covers disciplines from macromolecular sequences to inorganic molecules and quantum chemistry. CML is new in bringing the power of XML to the management of chemical information. In simple terms it is "HTML for Molecules," but there is a great deal more to it than that. CML and associated tools allows for the conversion of current files without semantic loss into structured documents, including chemical publications, and provides for the precise location of information within files. 

http://cml.so

ebXML Electronic Business 

using eXtensible Markup Language 

Is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes. ebXML was started in 1999 

www.ebxml
Acronym Standard Functional Description 

as an initiative of OASIS and the United Nations/ECE agency CEFACT. 

GEIA – 927 Government 

Electronics and Information technology Association 927: Common Data Schema for Complex Systems 

Is being developed to achieve an unprecedented degree of interoperability among IT systems for complex engineerto-order systems, products and processes over their lifecycle. It specifies the data concepts to be exchanged to share product information pertaining to a complex system from the viewpoints of multiple disciplines. It supports the exchange of data across the entire lifecycle for the product from the concept stage through disposal. 

http://63.249927/index.ht

IGES Initial Graphics 

Exchange Specification 

Defines a neutral data format that allows for the digital exchange of information among computer-aided design (CAD) systems. CAD systems are in use today in increasing numbers for applications in all phases of the design, analysis, manufacture and testing of products. Since it is common practice for a designer to use one supplier’s CAD system and for the contractor and subcontractors use different systems, there is a need for the ability to exchange data digitally among all CAD systems. IGES provides a neutral definition and format for the exchange of specific data. Using IGES, a user can exchange product data models in the form of wire frame or solid representations as well as surface representations. Applications supported by IGES include traditional engineering drawings as well as models for analysis and/or various manufacturing functions. In addition to the general specification, IGES includes application protocols in which the standard is interpreted to meet discipline 

https://www
Acronym Standard Functional Description 

specific requirements. 

IPC-2570 series Shop Floor 

Communications (PDX) - IPC-257x 

PDX is the Product Data eXchange standard for the esupply chain. It is a multi-part standard, represented by the IPC 2570 series of specifications. The PDX standardization effort is focused on the problem of communicating product content information between Original Equipment Manufacturers, Electronics Manufacturing Services providers and component suppliers. The standard is based on XML because this provides a simple way to encode structured data into a format that is both human and machine-readable. PDX provides a way to describe product content (Bill of Materials (BOM), Approved Manufacturer Lists (AML), Drawings, etc.), Engineering Change Requests (ECR), Engineering Change Orders (ECO) and deviations. 

http://webstd

MatML Materials Markup 

Language 

An XML language developed especially for the interchange of materials information. It addresses the problems of interpretation and interoperability for materials property data exchanged via the World Wide Web 

http://www.oopen.org/cov

MML MOKA Modelling 

Language 

Provides for the representation of meta classes and relations between them as MOKA's main formal knowledge structuring facility. 

http://www.k/meta.htm 

OAGIS Open Applications 

Group Integration Specification 

Is an effort to provide a canonical business language for information integration. It uses XML as the common alphabet for defining business messages, and for identifying business processes (scenarios) that allow businesses and business applications to communicate. 

http://www.i/xml/library/

PDML Product Data being developed as part of the Product Data http://www.P
Acronym Standard Functional Description 

Markup Language Interoperability (PDI) project ml

PDX Product Data 

eXchange 

Please see IPC-2570 series above. http://webstd

PLCS Product Life Cycle 

Support 

ISO 10303-239: 2005, Industrial automation systems and integration -- Product data representation and exchange -- Part 239: Application protocol: Product life cycle support. Seeks to provide a mechanism to maintain the information needed to support complex products and systems such as ships, aircraft, engines, or oil platforms, in line with the changing product over its complete life cycle from concept through design and manufacture to operation and disposal. AP239 also addresses the information requirements needed to define and deliver life cycle support for complex assets. 

http://www.i

http://www.oopen.org/comg_abbrev=pl

PLM XML Product Lifecycle 

Management eXtensible Markup Language 

A set of XML schemas serving as a transport protocol. an emerging UGS format for facilitating product lifecycle interoperability using XML, it is open and based on standard W3C XML schemas. Representing a variety of product data both explicitly and via references, PLM XML provides a lightweight, extensible, and flexible mechanism for transporting high-content product data over the Internet, and aims to form the basis of a rich interoperability pipeline connecting UGS PLM Solutions products and third party adopter applications. 

http://www.p

STEP STandard for 

Exchange of Product model data 

ISO 10303 objective is to provide a means of describing product data throughout the lifecycle of a product that is independent from any particular computer system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing 

http://www.tsc4.org/SC4k%5FProduc%5F%28103
Acronym Standard Functional Description 

product databases and for archiving data. In practice, the standard is implemented within computer software associated with particular engineering applications and so its use and function will be transparent to a user. The descriptions are information models that capture the semantics of an industrial requirement and provide standardized structures within which data values can be understood by a computer implementation. 

STEP PDM Schema 

Standard for the Exchange of Product model data (STEP) Product Data Management (PDM) 

Iis a reference information model for a central, common subset of the data being managed within a PDM system. It represents a set of common requirements and data structures from a range of STEP Application Protocols all generally within the domains of design and development of discrete electro/mechanical parts and assemblies. It is not a specification for the functionality of the complete scope of all PDM system functionality. Important interfaces exist with functionality needed for comprehensive PDM services that exist in STEP but are not within the common scope of the core PDM schema. 

http://www.p

STEPml STEP markup 

Language 

A library of XML specifications based on the content models from the STEP standard 

http://www.s

UBL Universal Business 

Language 

The product of an international effort to define a royaltyfree library of standard electronic XML business documents such as purchase orders and invoices. Developed in an open OASIS Technical Committee with participation from a variety of industry data standards organizations, UBL is designed to plug directly into existing business, legal, auditing, and records management practices, eliminating the re-keying of data 

http://www.oopen.org/comg_abbrev=ub
Acronym Standard Functional Description 

in existing fax- and paper-based supply chains and providing an entry point into electronic commerce. 

U3D Universal 3 

Dimensional 

A graphics standard that is a simple format for interactive viewing and sharing of 3D data 

http://www.a

X3D XML-enabled 3D standard to enable real-time 

communication of 3D data 

Type Three: Architecture Frameworks Standards In integrating these Types of standards, it is necessary to consider the architectural frameworks for creating integratThree category of standards. 

Acronym Standard Functional Description 

DoDAF Department of 

Defense Architecture Framework 

DoD Architecture Framework Working Group, DoD ArchitectureFramework, Version 1.0, Volume I: Definitions and Guidelines , 2004 

http://www.d

oDAF_v1_V

FEAF Federal Enterprise 

Architecture Framework 

Was established in 1999 by the Chief Information Officers (CIO) in response to this mandate. The purpose of the FEAF is to facilitate shared development of common processes and information among Federal Agencies and other government agencies. The FEAF, like other frameworks, is essentially a guide for collecting common architecture information and building a repository to store this information. 

http://www.c

pdf

MDA Model-Driven 

Architecture 

MDA supports applications over their entire lifecycle from Analysis and Design, through implementation and 

http://www.o
Acronym Standard Functional Description 

deployment, to maintenance and evolution. Based on UML models which remain stable as the technological landscape changes around them, MDA-based development maximizes software ROI as it integrates applications across the enterprise, and one enterprise with another. 

MODAF Ministry of Defence 

(UK) Architectural Framework 

Defines a standardized way of modeling an enterprise. The purpose of MODAF is to ensure a consistent approach when developing enterprise architectures. 

http://www.m

NAF NATO Architecture 

Framework 

Part of the NATO C3 Technical Architecture (NC3TA), which provides the architectural building blocks in a functional, standards, and product-related form and their relationships necessary to develop the technical and system views of an architecture. 

http://nc3ta.nme_volumes3ta.nc3a.natomes.asp?men

OSA-EAI Open System 

Architecture for Enterprise Application Integration (OSAEAI) 

Is MIMOSA’s XML-based system specification for the integration of asset management information. A standard by which data flows from the monitored assets to the Enterprise Asset Management system. 

http://www.mm 

RM-ODP Reference Model 

for Open Distributed Processing 

An ISO/IEC 10746 standard, the model describes an architecture within which support of distribution, interworking, interoperability and portability can be integrated. The RM-ODP framework defines ODP concerns using five “viewpoints” (abstractions), namely enterprise, information, computational, engineering, and technology.

http://www.djects/ODP/re

SCOR Supply Chain 

Operations 

The supply chain council, supported by over 650 member organizations (both academia and industry) 

http://www.etions/2005b.
Acronym Standard Functional Description 

Reference worldwide, has developed the supply chain operations 

reference (SCOR) model. The SCOR model is a process reference model, which is intended to be an industrial standard that enables next-generation supply chain 

management. It contains a standard description of management processes, a framework of relationships among the standard processes, standard metrics to measure process performance, management practices that produce best-in-class performance, and a standard alignment to software features and functionality. 

http://www.s

VCOR Value Chain 

Operational Reference Model 

Aims at providing a unified and universal approach to organizational analysis and help in consolidating enterprise processes 

http://www.v

Zachman Framework 

 Draws upon the discipline of classical architecture to 

establish a common vocabulary and set of perspectives, a framework, for defining and describing today's complex enterprise systems. Enterprise Architecture provides the blueprint, or architecture, for the organization's information infrastructure. 

http://www.z

Standards Development Organizations or Communities of Practice (beyond ANSI an

Acronym Organization Name Scope of Development 

18 A much more thorough list of standards development organizations for well beyond product data-related activities, can be found at the Standard

http://www.ses-standards.org/displaycommon.cfm?an=9 . 
Acronym Organization Name Scope of Development 

ASME American Society of 

Mechanical Engineers 

Founded in 1880 as the American Society of Mechanical Engineers, today's ASME is a 120,000-member professional organization focused on technical, educational and research issues of the engineering and technology community. ASME conducts one of the world's largest technical publishing operations, holds numerous technical conferences worldwide, and offers hundreds of professional development courses each year. ASME sets internationally recognized industrial and manufacturing codes and standards that enhance public safety. 

http://www.a

CIDX Chemical Industry Data 

Exchange 

a non-profit organization dedicated to improving the ease, speed and cost of securely conducting business electronically in the Chemical Industry. CIDX is a membership-based organization serving the chemical industry, focused on the development of eBusiness standards, called Chem eStandards. 

http://www.c

FIATECH Fully Integrated and A consortium whose vision is a http://www.fi
Acronym Organization Name Scope of Development 

Automated Technology future state where capital projects 

are executed in a highly automated and seamlessly integrated environment across all phases and processes of the capital project lifecycle. 

GEIA Government Electronics and 

Information Technology Association 

Promotes the interests of the U.S. electronics, communications and information technology industries with regard to government markets, requirements, and technical standards. 

http://www.g

IEEE Institute of Electrical and 

Electronics Engineers Inc. 

The IEEE, a non-profit organization, is the world's leading professional association for the advancement of technology. IEEE has about 900 active IEEE standards and more than 400 in development.

http://www.ie

JT Open JT Open is a community of 

software users and software vendors committed to the widespread adoption of a single, open and preferred 3D visualization platform based on JT technology. 

“JT” is Engineering Animation 

Inc’s DirectModel (.jt) file format. 

http://www.jt

MIMOSA Machinery Information 

Management Open Systems 

A not-for-profit trade association dedicated to developing and 

http://www.m
Acronym Organization Name Scope of Development 

Alliance encouraging the adoption of open 

information standards for Operations and Maintenance in manufacturing, fleet, and facility environments. MIMOSA's open standards enable collaborative asset lifecycle management in both commercial and military applications. 

NEMA National Electrical 

Manufacturing Association 

A trade association in the U.S. representing the interests of electro industry manufacturers of products used in the generation, transmission and distribution, control, and enduse of electricity. 

http://www.n

OAG Open Applications Group A not-for-profit open standards 

group building process-based XML standards for both B2B and A2A integration. The Open Applications Group was formed in late 1994 as the first post-EDI organization focusing on improving the state of application integration. 

http://www.o

OASIS Organization for the 

Advancement of Structured Information Standards 

A not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. Founded in 1993, OASIS has more than 3,500 participants representing over 600 organizations and 

http://www.o
Acronym Organization Name Scope of Development 

individual members in 100 countries. 

OMA Open Mobile Alliance An alliance to facilitate global user 

adoption of mobile data services by specifying market driven mobile service enablers that ensure service interoperability across devices, geographies, service providers, operators, and networks, while allowing businesses to compete through innovation and differentiation. Maintaining an open organization is key to OMA’s vision for broad industry participation and adoption.Any interested party may join OMA and contribute to the technical specifications, and any entity (both members and non-members) may build applications and services in accordance with OMA’s open specifications and interfaces under the same conditions.

http://www.o

OMG Object Management Group Open, not-for-profit consortium 

that produces and maintains computer industry specifications for interoperable enterprise applications. 

http://www.o

RosettaNet A subsidiary of GS1 US (parent 

organization GS1 USTM, formerly 

http://www.ro
Acronym Organization Name Scope of Development 

the Uniform Code Council, Inc.®), is a non-profit organization dedicated to the collaborative development and rapid deployment of open, e-business process standards that align processes within global trading networks. RosettaNet standards and services provide a common language for ebusiness transactions and the foundation for integrating critical processes among partners within the global supply chain. Founded in 1998 in the heart of Silicon Valley, RosettaNet has affiliates in Europe, Asia, and Australia. 

STAR Standards for Technology in 

Automotive Retail 

A non-profit, auto industry-wide initiative to create voluntary IT standards for how manufacturers, dealers, and customers communicate with each other. 

http://www.st

Supply Chain Council A global, not-for-profit trade 

association open to all types of organizations. It sponsors and supports educational programs including conferences, retreats, benchmarking studies, and development of the Supply-Chain Operations Reference-model (SCOR), the process reference 

http://www.su
Acronym Organization Name Scope of Development 

model designed to improve users' efficiency and productivity. 

W3C World Wide Web 

Consortium 

An international consortium where Member organizations, a full-time staff, and the public work together to develop Web standards. W3C primarily pursues its mission through the creation of Web standards and guidelines. 

http://www.w
112

Appendix D: DOD policies, procedures, and guidelines on 

the use of national and international standards 

associated with defense product lifecycle management 

In our recent research of Department of Defense and Army-specific memoranda, directives, 

instructions, military standards, and military specifications, we found a plethora of existing 

guidelines, policies, or procedures for encouraging the use of, requiring the use of, and hoping 

for the use of industry-developed standards. The memoranda, letters, and documents that 

follow provide a sampling of the Department of Defense and Army’s commitment to use 

commercial standards, products, and services wherever possible. In addition to some of these 

overarching declarations of support below, there are several other documents that have 

influenced history and warrant mention, but are too voluminous to include more than a 

reference here: 

These are: 

• The DOD 5000 series found online: http://akss.dau.mil/dag/DoD5000.asp?view=framework 

o DoDD 5000.1, the Defense Acquisition Handbook 

o DoDI, 5000.2, Operation of the Defense Acquisition System 

o DoDI, 5000.2, Defense Acquisition Guidebook 

• MIL-DTL-31000C, Detail Specification Technical Data Package 

• DoD 4140.1-R, DoD Supply Chain Materiel Management Regulation 

The rest of the documents included below are in historical order. This report would be remiss 

if it did not acknowledge the historical precedence set by Secretary Perry, in his June 29, 1994 

memorandum, entitled, “Specification & Standards -- A New Way of Doing Business." His 

memorandum revolutionized the way the whole of Defense DoD thought about, and conducted, 

weapon system and service support. Secretary Perry’s modification to the June 29th

memorandum, and example follow-up tri-service policies and procedures continue to prescribe 

the spirit of the memorandum. 

• William J. Perry, Secretary of Defense Memorandum, 29 June, 1994, “Specification & 

Standards -- A New Way of Doing Business"19

• Andrew D. Certo, Chief Standardization Program Division, 18 March 1997, “Guidance on 

Development and Adoption of Non-Government Standards (NGS)”

• Richard V. Reynolds, Joint Logistics Commanders, Joint Aeronautical Commanders’ 

Group, 2 May 2002, “Strategy for Product Data Throughout the Life Cycle”

• Stenbit, John P., DoD/CIO, “The Department of Defense Architecture Framework 

(DoDAF), February 9 2004 

• Defense Adoption Notice of MIMOSA OSA-EAI-2004, December 20, 2004.

• John J. Young, Jr., Assistant Secretary of the Navy, Research and Development and 

Acquisition, “DON Policy on Digital Product/Technical Data,” October 23, 2004.

• Stevenson, Mitchell H., “Army Materiel Command (AMC) Logistics Modernization 

Program Data Implementation Policy, 4 April 2005.

 

19 This memorandum and several others were found at: http://www.amc.army.mil/amc/rda/milspec/policyguidance.html . 
113

• Ronald J. Davis, Jr., Headquarters, US Army Materiel Command, “Army Standardization 

Improvement Policy, Memo 95-1 and 95-1 change 1, ‘Waivers for Use of Specifications 

and Standards’,” 19 April 2005

• Kenneth J. Krieg, Under Secretary of Defense for Acquisition, Technology and Logistics, 

Jun 23, 2005, “Standard for the Exchange of Product Model Data (STEP) – ISO 10303 
114

THE SECRETARY OF DEFENSE 

WASHINGTON, DC 20301-1000 

29 Jun 94 

MEMORANDUM FOR SECRETARIES OF THE MILITARY DEPARTMENTS 

 CHAIRMAN OF THE JOINT CHIEFS OF STAFF 

 UNDER SECRETARIES OF DEFENSE 

 COMPTROLLER 

 ASSISTANT SECRETARY OF DEFENSE (COMMAND, CONTROL, 

 COMMUNICATIONS, AND INTELLIGENCE) 

 GENERAL COUNSEL 

 INSPECTOR GENERAL 

 DIRECTOR OF OPERATIONAL TEST AND EVALUATION 

 DIRECTORS OF THE DEFENSE AGENCIES 

 COMMANDER-IN-CHIEF, U.S. SPECIAL OPERATIONS 

 COMMAND 

SUBJECT: Specifications & Standards - A New Way of Doing Business 

To meet future needs, the Department of Defense must increase access to commercial 

state-of-the-art technology and must facilitate the adoption by its suppliers of business 

processes characteristic of world class suppliers. In addition, integration of commercial 

and military development and manufacturing facilitates the development of dual-use 

processes and products and contributes to an expanded industrial base that is capable of 

meeting defense needs at lower costs. 

I have repeatedly stated that moving to greater use of performance and commercial 

specifications and standards is one of the most important actions that DoD must take to 

ensure we are able to meet our military, economic, and policy objectives in the future. 

Moreover, the Vice President's National Performance Review recommends that agencies 

avoid government-unique requirements and rely more on the commercial marketplace. 

To accomplish this objective, the Deputy Under Secretary of Defense (Acquisition 

Reform) chartered a Process Action Team to develop a strategy and a specific plan of 

action to decrease reliance, to the maximum extent practicable, on military specifications 

and standards. The Process Action Team report, "Blueprint for Change," identifies the 

tasks necessary to achieve this objective. I wholeheartedly accept the Team's report and 

approve the report's primary recommendation to use performance and commercial 

specifications and standards in lieu of military specifications and standards, unless no 

practical alternative exists to meet the user's needs. I also accept the report of the Industry 

Review Panel on Specifications and Standards and direct the Under Secretary of Defense 

(Acquisition and Technology) to appropriately implement the Panel's recommendations. 

I direct the addressees to take immediate action to implement the Team's recommendations 

and assign the Under Secretary of Defense (Acquisition and Technology) overall 

implementation responsibility. I direct the Under Secretary of Defense (Acquisition and 

Technology) to immediately arrange for reprogramming the funds needed in FY94 and 

FY95 to efficiently implement the recommendations. I direct the Secretaries of the 
115

Military Departments and the Directors of the Defense Agencies to program funding for 

FY96 and beyond in accordance with the Defense Planning Guidance. 

Policy Changes 

Listed below are a number of the most critical changes to current policy that are needed to 

implement the Process Action Team's recommendations. These changes are effective 

immediately. However, it is not my intent to disrupt on-going solicitations or contract 

negotiations. Therefore, the Component Acquisition Executive (as defined in Part 15 of 

DoD Instruction 5000.2), or a designee, may waive the implementation of these changes 

for on-going solicitations or contracts during the next 180 days following the date of this 

memorandum. The Under Secretary of Defense (Acquisition and Technology) shall 

implement these policy changes in DoD Instruction 5000.2, the Defense Federal 

Acquisition Regulation Supplement (DFARS), and any other instructions, manuals, 

regulations, or policy documents, as appropriate. 

Military Specifications and Standards: Performance specifications shall be used when 

purchasing new systems, major modifications, upgrades to current systems, and nondevelopmental and commercial items, for programs in any acquisition category. If it is not 

practicable to use a performance specification, a non-government standard shall be used. 

Since there will be cases when military specifications are needed to define an exact design 

solution because there is no acceptable non-governmental standard or because the use of a 

performance specification or non-government standard is not cost effective, the use of 

military specifications and standards is authorized as a last resort, with an appropriate 

waiver. 

Waivers for the use of military specifications and standards must be approved by the 

Milestone Decision Authority (as defined in Part 2 of DoD Instruction 5000.2). In the case 

of acquisition category ID programs, waivers may be granted by the Component 

Acquisition Executive, or a designee. The Director, Naval Nuclear Propulsion shall 

determine the specifications and standards to be used for naval nuclear propulsion plants in 

accordance with Pub. L. 98-525 (42 U.S.C. §7158 note). Waivers for reprocurement of 

items already in the inventory are not required. Waivers may be made on a "class" or items 

basis for a period of time not to exceed two years. 

Innovative Contract Management: The Under Secretary of Defense (Acquisition and 

Technology) shall develop, within 60 days of the date of this memorandum, Defense 

Federal Acquisition Regulation Supplement (DFARS) language to encourage contractors 

to propose non-government standards and industry-wide practices that meet the intent of 

the military specifications and standards. The Under Secretary will make this language 

effective 180 days after the date of this memorandum. This language will be developed for 

inclusion in both requests for proposal and in on-going contracts. These standards and 

practices shall be considered as alternatives to those military specifications and standards 

cited in all new contracts expected to have a value of $100,000 or more, and in existing 

contracts of $500,000 or more having a substantial contract effort remaining to be 

performed. 

Pending completion of the language, I encourage the Secretaries of the Military 
116

Departments and the Directors of the Defense Agencies to exercise their existing authority 

to use solicitation and contract clause language such as the language proposed in the 

Process Action Team's report. Government contracting officers shall expedite the 

processing of proposed alternatives to military specifications and standards and are 

encouraged to use the Value Engineering no-cost settlement method (permitted by FAR 

48.104-3) in existing contracts. 

Program Use of Specifications and Standards: Use of specifications and standards listed 

in DoD Instruction 5000.2 is not mandatory for Program Managers. These specifications 

and standards are tools available to the Program Manager, who shall view them as 

guidance, as stated in Section 6-Q of DoD Instruction 5000.2. 

Tiering of Specification and Standards: During production, those system specifications, 

subsystem specifications and equipment/product specifications (through and including the 

first-tier reference in the equipment/product specifications) cited in the contract shall be 

mandatory for use. Lower tier references will be for guidance only, and will not be 

contractually binding unless they are directly cited in the contract. Specifications and 

standards listed on engineering drawings are to be considered as first-tier references. 

Approval of exceptions to this policy may only be made by the Head of the Departmental 

or Agency Standards Improvement Office and the Director, Naval Nuclear Propulsion for 

specifications and drawings used in nuclear propulsion plants in accordance with Pub. L. 

98-525 (42 U.S.C. §7158 Note). 

New Directions 

Management and Manufacturing Specifications and Standards: Program Managers 

shall use management and manufacturing specifications and standards for guidance only. 

The Under Secretary of Defense (Acquisition and Technology) shall develop a plan for 

canceling these specifications and standards, inactivating them for new designs, 

transferring the specifications and standards to non-government standards, converting 

them to performance-based specifications, or justifying their retention as military 

specifications and standards. The plan shall begin with the ten management and 

manufacturing standards identified in the Report of the Industry Review Panel on 

Specifications and Standards and shall require completion of the appropriate action, to the 

maximum extent practicable, within two years. 

Configuration Control: To the extent practicable, the Government should maintain 

configuration control of the functional and performance requirements only, givingcontractors responsibility for the detailed design. 

Obsolete Specifications: The "Department of Defense Index of Specifications and 

Standards" and the "Acquisition Management System and Data Requirements Control 

List" contain outdated military specifications and standards and data requirements that 

should not be used for new development efforts. The Under Secretary of Defense 

(Acquisition and Technology) shall develop a procedure for identifying and removing 

these obsolete requirements. 

Use of Non-Government Standards: I encourage the Under Secretary of Defense 
117

(Acquisition and Technology) to form partnerships with industry associations to develop 

non-government standards for replacement of military standards where practicable. The 

Under Secretary shall adopt and list in the "Department of Defense Index of Specifications 

and Standards" (DoDISS) non-government standards currently being used by DoD. The 

Under Secretary shall also establish teams to review the federal supply classes and 

standardization areas to identify candidates for conversion or replacement. 

Reducing Oversight: I direct the Secretaries of the Military Departments and the 

Directors of the Defense Agencies to reduce direct Government oversight by substituting 

process controls and non-government standards in place of development and/or production 

testing and inspection and military-unique quality assurance systems. 

Cultural Changes 

Challenge Acquisition Requirements: Program Managers and acquisition decision 

makers at all levels shall challenge requirements because the problem of unique military 

systems does not begin with the standards. The problem is rooted in the requirements 

determination phase of the acquisition cycle. 

Enhance Pollution Controls: The Secretaries of the Military Departments and the 

Directors of the Defense Agencies shall establish and execute an aggressive program to 

identify and reduce or eliminate toxic pollutants procured or generated through the use of 

specifications and standards. 

Education and Training: The Under Secretary of Defense (Acquisition and Technology) 

shall ensure that training and education programs throughout the Department are revised to 

incorporate specifications and standards reform. 

Program Reviews: Milestone Decision Authority (MDA) review of programs at all levels 

shall include consideration of the extent streamlining, both in the contract and in the 

oversight process, is being pursued. The MDA (i.e., the Component Acquisition Executive 

or his/her designee, for all but ACAT 1D programs) will be responsible for ensuring that 

progress is being made with respect to programs under his/her cognizance. 

Standards Improvement Executives: The Under Secretary the Secretaries of the Military 

Departments, and the Director of the Defense Logistics Agency shall appoint Standards 

Improvement Executives within 30 days. The Standards Improvement Executives shall 

assume the responsibilities of the current Standardization Executives, support those 

carrying out acquisition reform, direct implementation of the military specifications and 

standards reform program, and participate on the Defense Standards Improvement 

Council. The Defense Standards Improvement Council shall be the primary coordinating 

body for the specification and standards program within the Department of Defense and 

shall report directly to the Assistant Secretary of Defense (Economic Security). The 

Council shall coordinate with the Deputy Under Secretary of Defense (Acquisition 

Reform) regarding specification and standards reform matters, and shall provide periodic 

progress reports to the Acquisition Reform Senior Steering Group, who will monitor 

overall implementation progress. 
118

Management Commitment 

This Process Action Team tackled one of the most difficult issues we will face in 

reforming the acquisition process. I would like to commend the team, composed of 

representatives from all of the Military Departments and appropriate Defense Agencies, 

and its leader, Mr. Darold Griffin, for a job well done. In addition, I would like to thank 

the Army, and in particular, Army Materiel Command, for its administrative support of the 

team. 

The Process Action Team's report and the policies contained in this memorandum are not a 

total solution to the problems inherent in the use of military specifications and standards; 

however, they are a solid beginning that will increase the use of performance and 

commercial specifications and standards. Your leadership and good judgment will be 

critical to successful implementation of this reform. I encourage you and your leadership 

teams to be active participants in establishing the environment essential for implementing 

this cultural change. 

This memorandum is intended only to improve the internal management of the Department 

of Defense and does not create any right or benefit, substantive or procedural, enforceable 

at law or equity by a party against the Department of Defense or its officers and 

employees. 

 /signed/ 

 William J. Perry 
119

ACQUISITION AND 

TECHNOLOGY MARCH 18 1997 

OFFICE OF THE UNDER SECRETARY OF DEFENSE 

3000 DEFENSE PENTAGON 

WASHINGTON DC 20301-3000 

OASD(IA&I)AP 

Standardization Program Division 

5203 Leesburg Pike, Suite 1403 

Falls Church, Virginia 22041-3466 

MEMORANDUM FOR DOD STANDARDIZATION MANAGEMENT ACTIVITIES 

SUBJECT: Guidance on Development and Adoption of Non-Government Standards 

(NGS)

The heightened emphasis within the Department of Defense on the use of commercial 

items, practices, and processes, has resulted in extensive efforts to replace military 

and federal specifications and standards with NGS. Since our reform efforts began in 

June 1994, we have adopted an additional 1700 NGS, and have replaced or are in the 

process of replacing hundreds of military specifications and standards with these 

documents. We commend and encourage such efforts. 

We must keep in mind, however, that our goal is not to develop and use NGS for the 

sake of avoiding government specifications and standards. Our goal is to increase our 

access to commercial products and practices, and NGS are one way to achieve that 

goal. 

There is a very simple acid test for determining whether a government specification or 

standard is a good candidate to become a non-government standard. Will the resultant 

standard be used by the commercial sector? If the answer is yes, then it is a good 

candidate. If the answer is no, then the DoD still has many alternatives to nongovernment standards, including DoD performance specifications and commercial 

item descriptions. Any effort to develop a NGS that is not for a commercial product or 

does not specify a process or practice that truly will be used industry wide is 

discouraged. DoD should not participate in such efforts, nor should the NGS be 

adopted. In those instances where industry elects to develop a NGS for a canceled 

government document, the DoD must ensure a valid internal need exists for the NGS 

before a decision is made to adopt the document. 

Some NGS developing organizations have offered to cover sheet existing government 

specifications and standards in order to shift document maintenance responsibility in a 

rapid manner. This is acceptable, and the NGS may be adopted, if all of the following 

conditions apply: 

The government document is currently being used as the commercial industry 

standard. It is reformatted as a NGS with a new document identifier. Dual document 

identifiers which retain the military document number are not acceptable (e.g., 

NAS/MS 12345). However, it is acceptable for the NGS to retain the military Part 

Identification Number (PIN). It does not duplicate another NGS, which has already 

been adopted by the DoD. 
120

One of the proposed schemes for cover-sheet adoption by a NGS organization would 

require DoD personnel to sign the cover sheet acknowledging the new ownership. 

Preparing activities should not sign such cover sheets. Also, while there is pressure to 

develop NGS rapidly as replacement documents, DoD personnel should not request 

NGS developing organizations to circumvent their due processes for establishing 

standards development efforts. 

We hope you find this guidance useful, but if you require further clarification or an 

exception to this guidance, please contact your Departmental Standardization Office 

(DepSO). 

//signed// 

Andrew D. Certo 

Chief Standardization Program Division 

cc: DepSOs 
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177

Appendix E: NIST’s Economic Impact Studies Related to 

Manufacturing 

NIST invested in several economic impact studies since 1999 that researched and assessed the 

impact of various influences on the manufacturing community. The executive summaries of 

each are included here as an appendix for reference for the PEWG. The complete studies can 

each be found at http://www.mel.nist.gov/msidlibrary/impact_studies.html. 
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216