Lessons learned developing protocols for the industrial virtual enterprise
M. Hardwicka,*, K.C. Morrisb
, D.L. Spoonera
, T. Randoc
, P. Dennob
Rennselaer Polytechnic Institute, Center for Automation Technologies, 110, 8th Street, CII 7015, Troy, NY 12180-3590, USA
National Institute of Standards and Technology, USA
Electric Boat Corporation, USA
Accepted 2 September 1999
The protocols selected and developed by the NIIIP Consortium have been validated in three end-of-cycle demonstrations. In each cycle, a
team with expertise in technical product data, object modeling, workﬂow management, security, and knowledge representation came
together and demonstrated how technical barriers to the dynamic creation, operation and dissolution of “virtual enterprises” are overcome
by the NIII protocols. This paper describes the protocols that were selected and developed by the product data team and makes predictions
about how they will affect the future development and deployment of standard product data. ᭧ 2000 Elsevier Science Ltd. All rights reserved.
Keywords: Computer aided design; Computer aided manufacturing; Computer aided engineering
The National Industrial Information Infrastructure Proto-
cols (NIIIP) Consortium is a team of organizations that
entered into a cooperative agreement with the US Govern-
ment, in 1994, to develop inter-operation protocols for
manufacturers and their suppliers (for more information
on NIIIP see http://www.niiip.org).
The selected protocols make it easier for engineering
organizations to share technical product data over the Inter-
net. They do this by building on the Standard for The
Exchange of Product model data (STEP) . STEP provides
common deﬁnitions for product data that can be read and
written by many Computer Aided Design (CAD), Computer
Aided Manufacturing (CAM), Computer Aided Engineer-
ing (CAE) and Product Data Management (PDM) systems.
If engineering organizations can share data using STEP,
then suppliers are no longer constrained to own and operate
the same systems as their customers. The potential beneﬁt is
large. Suppliers are spending a lot of money buying the
systems of their customers, more money training people to
use those systems, and even more money re-entering data
from their preferred systems into the system required by
each customer .
Fig. 1 shows the challenge problem of the NIIIP project
from the perspective of the product data team. In the
problem, multiple organizations supply technical product
data to a virtual enterprise. The client program shown in
the ﬁgure needs to perform an operation on this data. In
Cycle 1 the operation was “CAD Visualization.” In Cycle
2 the operation was “Engineering Change”. In Cycle 3 the
operation was “Create Assembly.” To implement these
operations, the client application had to access product
data across the Internet, modify product data across the
Internet, and integrate product data across the Internet.
Cycle 3 was the last and most ambitious demonstration.
For this demonstration, product data belonging to three
enterprises was transmitted to a Virtual Enterprise Product
data Repository (VEPR) where it was integrated to create a
uniﬁed product data set for access and modiﬁcation by other
applications. Section 2 describes properties that the NIIIP
Product Data team determined were desirable for a VEPR.
Section 3 describes the protocols the team used to imple-
ment its VEPR. Section 4 describes how the VEPR was used
in the Cycle 3 demonstration. Section 5 describes the
lessons learned in each of the three NIIIP end-of-cycle
demonstrations, how these lessons inﬂuenced the design
of the VEPR and how they are inﬂuencing the deployment
phase of NIIIP. Section 6 summarizes the protocols and
makes predictions about future developments.
2. Properties desired for a virtual enterprise product
As deﬁned in this paper, a VEPR integrates product data
Computer-Aided Design 32 (2000) 159–166
0010-4485/00/$ - see front matter ᭧ 2000 Elsevier Science Ltd. All rights reserved.
* Corresponding author. Tel.: ϩ1-518-276-6752; fax: ϩ1-518-276-2702.
E-mail address: email@example.com (M. Hardwick).
from many organizations. It exists for the duration of a
virtual enterprise and is deleted when the enterprise is
dissolved. A VEPR is not expected to store very large
volumes of data or be a database for an individual member
of a virtual enterprise. Instead the VEPR is a neutral place
where the members can work together without requiring
each other to adopt foreign systems or procedures. A
VEPR is required to have at least the following properties:
• data standards so that an organization can contribute data
to many different virtual enterprises;
• access control standards so that a data producer can keep
control of its data;
• programming standards so that applications can operate
on product data stored in the repositories of many
different virtual enterprises.
If a VEPR has these properties, then organizations can
use it to support cooperative activities. Examples of such
activities include creating a design that is the combined
response of a team to a request for proposals, and coordinat-
ing design and manufacturing. In the ﬁrst example, multiple
organizations put their technical data into a VEPR so that
they can build their response to a proposal. In the second
example, manufacturing applies its applications to product
data stored in the VEPR of different design organizations.
The ﬁrst example needs data standards so that each organ-
ization can insert its data into the VEPR and access control
standards so that each organization can keep control of its
data. The second example requires programming standards
so that manufacturing can apply its applications to new
design repositories as necessary.
3. Description of the NIIIP protocols for product data
STEP deﬁnes an integrated suite of information models
for the life cycle of a product.1
The information models are
described in a language called EXPRESS [3,4] that is simi-
lar to other data deﬁnition languages, but unique because it
can describe the complex data structures and constraints
needed for properties such as geometry and topology.
Today, STEP information is usually exchanged using ﬁles.
However, STEP information can also be shared using an
EXPRESS-driven programming interface called the
Standard Data Access Interface (SDAI) . The SDAI lets
an application program access STEP data in a repository.
When the NIIIP program began the repository and application
programs were assumed to be operating in the same process.
Four NIIIP protocols were layered onto STEP to deﬁne a
VEPR. The ﬁrst two are being made into new ISO2
standards, and the fourth is being made into an Object
(OMG) standard. An appropriate
standardization body has yet to be selected for the third
protocol. Table 1 summarizes the four protocols with
respect to their roles within a standard and within a
VEPR. Open issues for the four protocols are discussed at
the end of this paper.
SDAI Java and SDAI IDL4
are programming bindings of
the SDAI that unlike previous bindings of the SDAI (in C
and Cϩϩ) transport product data between applications. The
SDAI Java binding lets applications transport product data
to Java applets and applications over the Internet. Similarly,
the SDAI IDL binding allows applications written in a
variety of programming languages to access remote data.
With these two bindings, an application can open a repo-
sitory, access data, and transport it to a remote client. For
this reason the SDAI Java and IDL bindings are classiﬁed
the same within the NIII protocols. An implementation will
choose one or the other, but not both.
EXPRESS-X is a language for ﬁnding and mapping data
between EXPRESS models. It can be used to ﬁnd the data
needed by a client in the standard database stored in a server
and map that data from the generic model deﬁned by STEP
into the application speciﬁc model needed by a client. For
example, an EXPRESS-X mapping can be deﬁned to ﬁnd
the bill of material that describes the quantity of each kind
of component used in a product and map it into the data
structure used by a Java list widget on the Internet.
The STEP Services protocol deﬁnes data integration
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166160
Fig. 1. Challenge problem for the three demonstrations.
Copies of the STEP standards can be obtained from ANSI at a web site
maintained by the US Product Data Association: http://www.uspro.org.
Interface description language .
operations. With these operations, an application can inte-
grate objects from multiple sources to create a database. The
services deﬁne how an application can traverse a set of
objects, ﬁnd new objects, copy them to another data set,
and integrate those copies with the existing objects in the
The PDM Enablers are a set of interfaces for Product Data
Management systems. Unlike STEP, which provides very
detailed deﬁnitions for data, these interfaces are deﬁned at a
user-oriented level. OMG plans to deﬁne similar standards
in many other areas also related to STEP, such as MES and
One can view the NIII protocols as a bridge between
industry speciﬁc object models such as the ones being
deﬁned by OMG and the industry neutral standards being
developed by STEP.
4. Cycle 3 demonstration
Cycle 3 was the last of three demonstrations in Phase 1
(the research phase) of NIIIP. This cycle began in July 1996
and ended in July 1997. In Cycle 3, the four NIIIP protocols
were used to deﬁne a VEPR for an end of cycle demonstra-
tion given at Electric Boat Corporation (EBC) called the
EBC Cycle 3 pilot.
In the EBC pilot, piping data was stored in servers at the
National Institute of Standards and Technology (NIST) in
Gaithersburg, Maryland and International Business
Machines (IBM) in Boca Raton, Florida. During the demon-
stration, data from these sites was downloaded to a VEPR at
Electric Boat Corporation (EBC) in Groton, Connecticut
and integrated to create a virtual enterprise product. Fig. 2
shows the conﬁguration of the pilot. A World Wide Web
(WWW) browser was used to communicate with the exter-
nal servers. Data was downloaded to a machine outside the
EBC ﬁrewall. It was then brought over the ﬁrewall, loaded
into the VEPR and joined with data from an internal CATIA
Data Manager (CDM)6
The VEPR was deﬁned by STEP Application Protocol
203 (AP-203) . AP-203 deﬁnes an information model
for the conﬁguration controlled assemblies and their designs
as used by aerospace and automobile manufacturers. The
model contains approximately 500 data deﬁnitions. The
external interface for the VEPR was deﬁned using 40
objects. These objects described properties of interest to
an end-user, such as people, organizations, products,
product versions, shapes, parent–child assembly relation-
ships, and so on. The 40 objects were related to the 500
data deﬁnitions using EXPRESS-X mappings.
For the Cycle 3 demonstration it was important to make
the objects from the prime contractor database (i.e., EBC)
virtual so that master data was not duplicated in the integra-
tion site. Virtual objects were implemented by writing
custom functions and custom mappings to fetch objects
from a database (in this case the CDM database) and convert
them to STEP. The virtual objects were represented in the
repository as ‘stubs’ that contained the address of the data in
the database. The custom functions allowed the virtual
objects to be queried using the STEP Services interface in
the same way as the “real” objects. When a virtual object
was chosen for export, the custom EXPRESS-X mappings
converted data from the CDM database to the required
STEP representation. Making objects virtual in this way
was effective because it eliminated duplication, but
expensive in terms of programmer time.
Applications were connected to the VEPR at EBC over
the Internet by a Java Remote Method Invocation (JRMI)
binding of the STEP Services protocol. Fig. 3 shows two
applications developed for the Cycle 3 demonstration: the
Loading Dock Server and the Product Structure Server.
Both servers were implemented by customizing the STEP
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166 161
Fig. 2. Conﬁguration of the EBC Cycle 3 pilot.
Fig. 3. VEPR architecture.
Names of companies and products, and links to commercial pages are
provided to adequately specify procedures and equipment used. In each
case identiﬁcation does not imply recommendation or endorsement by
the National Institute of Standards and Technology, nor does it imply
that the products are necessarily the best available for the purpose.
The Loading Dock Server let a user browse the three
areas of a VEPR and decide what to import and export. In
an import transaction, the Server loaded a STEP ﬁle into the
Import Area and displayed the set of objects found in the
ﬁle by the EXPRESS-X ﬁlter. The user picked objects
containing new information for the VEPR and they were
transferred to the core area. In an export, a list of the objects
in the core area was shown to the user. The user picked the
objects needed by the application, they were transferred to
the output area and converted into a STEP ﬁle by the
The Product Structure Server and Client let a user create
and edit piping assemblies. The Server contained algorithms
to edit the product structure of an assembly. The Client
contained a user interface to change assemblies by pointing
at visualizations. The server communicated with the client
using the SDAI Java protocol. In the demonstration, the
Product Structure Server and Client were used to create a
new piping assembly that contained sub-assemblies from
the two suppliers and the CDM database. The client was a
Java application to edit trees and did not know anything
5. Experience with the protocols
The four NIIIP protocols used in the VEPR were deﬁned
as a result of experiences gained during three end-of-cycle
demonstrations prepared by the members of the NIIIIP
5.1. Before cycle 1 (before 12/94)
The NIIIP project began with the reasonable assumption
that a combination of the Common Object Request Broker
Architecture (CORBA) and STEP could provide an
environment for product data sharing over the Internet. In
this architecture, CORBA provides connectivity and STEP
provides a language for communication. The NIIIP Product
Data team was tasked with discovering and eliminating
barriers to this solution. They considered barriers in the
STEP technology and the other NIIIP teams considered
barriers in Internet communication, object technology,
knowledge representation and workﬂow.
STEP provides a strong basis for product data sharing, but
three aspects of STEP proved to be barriers in the sense that
they made implementing a Virtual Enterprise more difﬁcult
than necessary so we hoped to overcome these barriers using
• The normalization of information models. Normalization
was a barrier because it divides data into smaller
elements that are harder to process in a program. For
example, the 40 end-user objects in AP203 of STEP
are represented as 500 data deﬁnitions after normaliza-
tion. Processing STEP data is easier if it can be encapsu-
lated as 40 objects (or fewer if the application does not
need all of the objects) instead of as 500 deﬁnitions.
• The restricted domain of the EXPRESS language.
EXPRESS was a barrier because it is not well supported
outside of the CAD/CAM/CAE and PDM systems of the
product data community. For example, most World Wide
Web browsers cannot process EXPRESS-deﬁned data.
Processing this data in the wider community is easier if
it is converted into another form (such as Java classes or
XML) before it is sent to a client.
• The focus on ﬁxed-point data exchange versus data shar-
ing. Data exchange was a barrier because if each member
of an enterprise makes its data available via data
exchange then multiple sets of information must be
processed by the VE applications. If these sets contain
related information then each application must compute
the relationships. Writing the applications is easier if the
sets are merged to create a virtual enterprise product.
5.2. Cycle 1 lessons (1/95–10/95)
In the ﬁrst NIIIP cycle, the team built a data access
demonstration that loaded STEP data into a variety of
Computer Aided Design (CAD) systems . Fig. 4 illus-
trates the basic features of the demonstration. A CAD
system was used to design a product. The data produced
by the CAD system was converted into a set of web
pages. A second user browsed the data, found something
of interest, and loaded the ﬁle described by the web pages
into his or her CAD system. It was assumed that this CAD
system was different from the ﬁrst CAD system .
Three CAD systems were wrapped using CORBA
protocols for the demonstration. When the user wanted to
manipulate data, the CORBA protocols found and activated
the appropriate CAD system for that user. STEP was used to
communicate information between the CAD systems. The
product created using the ﬁrst CAD system was stored as a
STEP ﬁle and the data selected by the user was loaded into
the other CAD systems using a STEP ﬁle. In all cases the
data was read and written by commercial off-the-shelf STEP
translators sold by the CAD system vendors.
The technical issue addressed in the demonstration was to
develop a user-oriented way to ﬁnd the product data.
Because of the Normalization-Barrier, the STEP ﬁle for a
product model contains lots of small data deﬁnitions. When
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166162
Fig. 4. Cycle 1 demonstration. STEP data is found using web pages.
each one is converted into a Hyper-Text Markup Language
(HTML) page the result is many difﬁcult-to-understand
pages. Something was needed to bridge the “semantic
gap” between the users high-level understanding of the
data and the low level (normalized) deﬁnitions provided
The barrier was addressed by inventing a mapping
language to extract the information needed for a web page
from the “sea” of entities deﬁned by a STEP ﬁle. The
language made it possible for a programmer to code a set
of conditions that must be met for a user-oriented object to
exist in a STEP ﬁle. In the demonstration, it was used to
recognize objects that represent shapes and assemblies in a
product model. The recognized objects were then displayed
as icons on a web page so that a user could select the ﬁle that
contained the right objects for loading into his or her CAD
The mapping language invented in Cycle 1 was named
EXPRESS-V (for EXPRESS Views). After Cycle 1, it was
discovered that similar efforts were underway in Europe,
Japan and the US. As a result of these efforts, a new standard
language for mapping EXPRESS data, called EXPRESS-X,
is being added to STEP.
5.3. Cycle 2 lessons (11/95–6/96)
Cycle 2 of the NIIIP Program demonstrated how different
kinds of applications process STEP data over the Internet
. Fig. 5 shows the basic architecture of this demonstra-
tion. Four Client programs operate against a Database
Server. Two of these Client programs (i.e., the Part Client
and the Shape Client) use the Cycle 1 techniques to map
STEP data into HTML and VRML . The other two
clients (i.e., the Cost Client and the Analyst Client) were
the focus of this demonstration. They show how product
data can be loaded into heterogeneous clients on the
The two new clients in Cycle 2 were a Java application
and an IDL application. Both clients were implemented
using prototype bindings of the STEP Data Access Interface
(SDAI). As discussed above, the SDAI is a standard that
deﬁnes a set of operations for manipulating EXPRESS-
deﬁned data in application programs. The programs can
open repositories, ﬁnd data items, navigate between data
items, and change data values. The SDAI operations are
language neutral. C and Cϩϩ bindings for the SDAI were
in the process of being created by ISO STEP when the NIIIP
Program started. New bindings have since been started for
IDL and Java as a result of the NIIIP project.
Cycle 2 used the IDL and Java bindings to manipulate
STEP data over the Internet. The Java and IDL bindings
allow a client application to mix local and remote function
calls. In a typical transaction, an application uses remote
function calls to ﬁnd a data set of interest and transfer that
set to local memory. The application then uses local calls to
traverse and modify the data set. Finally, the application
uses remote calls to put the modiﬁed data back into the
server at the end of a transaction.
The technical issue addressed in Cycle 2 was transfer of
data from the server to the client. In CORBA, data is trans-
ferred from a server to a client using an object service called
externalization. In Java, a similar facility is called Java
Object Serialization (JOS). Both services make it possible
for a set of objects to be transferred from a server to a client
for local processing. However, the CORBA version of the
service requires a set of classes to be prepared in the client to
receive the objects. In Java this is not necessary because a
set of classes to receive the data can be sent from the server
to the client at run time.
Also, the CORBA externalization service requires part-
ners to deﬁne a format for “externalizing” each data type.
For example, the most efﬁcient method to transfer a select
type may be to require an explicit label ﬁeld to distinguish
the underlying type. Alternatively, the label may not be
necessary because the application knows what type to
expect from other data. The NIIIP partners discussed several
alternatives for how to transmit STEP using the externaliza-
tion service. Deﬁning a new format was an option but would
have been a lot of redundant work since an exchange format
already exists for STEP, yet this format would not work
because it requires two passes across the data. On the
other hand, the format needs to be as exhaustive as STEP’s
to make it comprehensive . In the end, a custom trans-
lator written by Rensselaer Polytechnic Institute allowed the
data to be instantiated in one pass but it was speciﬁc to the
data model of the application used in the demonstration.
Therefore, all of the software to support the format had to
be recompiled whenever a change or extension was made to
the data model.
The Java application was much easier to write for two
reasons. First, the JOS format can be used to transfer STEP
data between a server and client without modiﬁcation.
Second, Java allows a set of classes to be sent from the
server to the client just before the data is sent. These differ-
ences have large logistic beneﬁts because only one class
library has to be built and managed. This library is compiled
from EXPRESS by the server and used by the client without
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166 163
Fig. 5. Cycle 2 demonstration. STEP data is loaded into Java and IDL
requiring any EXPRESS processing facilities to be in the
client. Eliminating the requirement for client applications to
know about EXPRESS eliminates the second barrier in
5.4. Cycle 3 lessons (7/96–7/97)
Cycle 3 focused on deﬁning and building the Virtual
Enterprise Product data Repository. In previous cycles,
data was distributed across the virtual enterprise without a
single enterprise server. This worked well for a single data
sharing session; however, it did not address a product
development process involving multiple partners.
Two new issues were addressed in Cycle 3. The ﬁrst,
getting data from an existing enterprise into a virtual enter-
prise server, was an outgrowth of the previous two cycles.
The second, the integration of data when it comes in from
multiple enterprises, was addressed by implementing the
VEPR described earlier. The VEPR eliminates the third
barrier in Section 5.1 by integrating data from multiple
sources into one site where it has a single context that can
be processed with less effort by client applications. For
example without a VEPR, if three products are in three
enterprises then an application must go to each of the enter-
prises, open the data, and traverse that data until it ﬁnds the
required information. This becomes quite complicated if
one enterprise deﬁnes an assembly and another enterprise
deﬁnes a component of the assembly because the identity of
the component must be found in the ﬁrst repository and then
processed in the context of the second repository. A VEPR
eliminates this problem by putting all the data into one
context where the assembly is directly connected to its
The three partners in the Cycle 3 demonstration repre-
sented a prime contractor (EBC) and two suppliers (IBM
and NIST). Each partner employed different methods to
make their data available to the virtual enterprise server.
At NIST the internal database was based on STEP AP 203
for conﬁguration-controlled product design. The internal
database used a commercial object-oriented database
management system and was accessed via the SDAI Cϩϩ
and IDL standards. A web server was used as a front-end to
the database to allow it to participate in the virtual enter-
prise. By basing the internal database on standards, a
customized front-end was quickly tailored to bring NIST
into the virtual enterprise. The front-end was based on infor-
mation requirements speciﬁed for the demonstration and
presented an application view of the AP 203 data. By
using off-the-shelf security measures implemented in the
web server, NIST was able to participate in the demo
through two ﬁrewalls (one at NIST and the other at EBC).
5.5. New lessons for the deployment phase (1998–2001)
The research phase of NIIP ended in 1998. In the deploy-
ment phase, the protocols are being used to implement
teaming databases at the US shipyards and to deliver
product data objects to manufacturing execution systems.
In this phase the protocols are being made into ISO and
OMG standards, methods are being developed for testing
those standards and the ﬁnal touches are being made to the
NIIIP architecture for product data .
Three requirements for the NIII protocols were listed in
Section 2—data standards, access control standards and
programming standards. At the end of the research phase
we are able to address the data standards using STEP, the
programming standards using OMG and bridge between the
two using the NIII protocols.
However, the requirement for access control standards is
not being adequately addressed. The Cycle 3 VEPR relied
on custom code to control data access to the legacy data-
base. This was an unsatisfactory solution. During the
deployment phase a new architecture is being tried to
address this problem. Fig. 6 shows it with two databases
one for the internal data of an enterprise and the other for
data that it shares with suppliers. Both databases supply data
to an object component framework. The object component
framework is a mediator at runtime to direct applications to
the objects to which they are allowed access and to prevent
them from accessing secure information. Data is moved into
and out of the framework from the VEPR database using the
EXPRESS-X and SDAI Java protocols. Data is moved into
and out of the framework from the internal database using
SQL and JDBC.
The new architecture allows enterprise applications to
use a common framework to access both databases. The
architecture addresses the access control issue because an
enterprise gives authorized users access the legacy database,
while suppliers are restricted to the VEPR. Both sets of
users can use the same applications because of the object
framework. If necessary the VEPR can be transported and
installed at a supplier site using data exchange, and the
VEPR can integrate data from the enterprise and the
suppliers to create a virtual enterprise product.
To support the new architecture the NIII protocols are
being extended as follows:
• The EXPRESS-X Data Mapping protocol is being
extended to update STEP databases.
• The SDAI Java Data Transport protocol is being
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166164
Fig. 6. NIIIP deployment phase architecture.
extended to interface to the Enterprise JavaBean
• The STEP Services protocol is being replaced by
improvements to EXPRESS-X.
• The OMG PDM Enabler interface has been completed.
The OMG Manufacturing Task Force is deﬁning
standards for other areas of manufacturing. The NIII
protocols will be tested to see if they bridge between
these standards and STEP.
Software to implement the protocols is being developed
in the United States and Europe.7
6. Conclusions and lessons for the future
This paper describes the efforts of the NIIIP consortium to
provide a bridge between product data standards and
product object standards. In the deployment phase, the
protocols are being used to implement teaming databases
at the US shipyards and to deliver product data objects to
manufacturing execution systems. In parallel the protocols
are being promoted as standards within ISO and OMG.
During the preparation for three end-of-cycle demonstra-
tions, the NIIIP Product Data team found barriers that made
it difﬁcult for organizations to display product data in World
Wide Web pages, transfer product data to applications from
remote servers, and integrate product information from
multiple sources. To address these problems, the team
invented the EXPRESS-X protocol to make data mapping
easier, the SDAI Java and SDAI IDL protocols to make
transport of product from servers to clients easier, and the
STEP Services protocol to make data integration easier. In
addition, the team used the OMG product data management
protocol to deﬁne a standard interface for its VEPR.
Early results from the deployment phase are showing that
the new protocols make it possible for enterprises to share
STEP data over the Internet. The surge in interest in the
Internet is causing many organizations to examine their
operations to look for artiﬁcial barriers that may prevent
them from participating in global teaming projects.
Requiring your partners to use your systems is an important
example of such a barrier. STEP is equally available to all
but before NIIIP there were three problems preventing its
wide spread deployment:
• relatively few CAD systems had STEP interfaces;
• STEP deﬁned protocols sufﬁcient for data exchange, but
not sufﬁcient for data sharing;
• STEP did not include deﬁnitions for every kind of
product data activity.
The ﬁrst problem has been solved during the research
phase of NIIIP by organizations such as PDES, Inc. in the
United States and ProSTEP in Germany. They have held a
series of interoperability workshops for the CAD system
vendors that enabled them to test progressively more
complex data exchange.8
As a consequence nearly all
CAD systems have a STEP interface. The new protocols
introduced by NIIIP (Table 1) address the second problem.
The third problem is being addressed by allowing advanced
industry standards to be deﬁned in advance of the ISO
NIIIP’s deployment phase is showing that the main
contribution of the NIIIP program may be that it has made
standard product data easier to use. Addressing the needs of
many organizations is a signiﬁcant problem for product data
developers. Folding all the requirements into one speciﬁca-
tion usually leads to a complex result. The NIIIP program
has implemented protocols to make easier for an organiza-
tion to map standard data into their own object models.
We predict one result of this improvement will be more
STEP speciﬁcations. There is a large appetite for new speci-
ﬁcations because design and manufacturing data is so
important to enterprises. One example is a new effort to
let machine tool controllers read an extended STEP
standard. The existing machine control standard has been
in place for more than 30 years and communicates cutting
vectors to a controller. The proposed new standard allows a
controller to access all the information known about a
product including its design, its manufacturing features
and the manufacturing strategies selected to machine
those features. The problem facing the new standard is
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166 165
Summary of the NIIIP protocols for product data
NIIIP protocol Standards role VEPR role
SDAI Java 
SDAI IDL 
Bindings of the SDAI for Java and CORBA applications. Protocol to transport product data between a
VEPR and its client applications.
EXPRESS-X  A language for describing how information can be mapped between
Protocol to ﬁnd data in a VEPR and map that data
into the object model used by a client.
STEP services  An extension of the SDAI that provides a higher-level interface for
manipulating STEP data.
Protocol for integrating data in a VEPR.
PDM enabler  A set of object deﬁnitions for Product Data Management Systems. Standard interface for VEPR’s that contain
product assembly information.
www,epmtech.jotne.com, www.prostep.de. 8
that it must include deﬁnitions for so many different kinds of
information. Without the NIII protocols it is very difﬁcult
for an application to ﬁnd the data it needs in all of these
deﬁnitions. With the NIIIP protocols an EXPRESS-X
mapping can be written to put the required data into an
object model that meets the requirements of the application.
 ISO 10303-1:1994. Industrial automation systems and integration—
Overview and fundamental principles. International Standard, ISO
 Brunnermeier, SB, Martin, SA. Interoperability cost analysis of the
US automotive supply chain, RESEARCH TRIANGLE INSTITUTE,
March 1999, http://www.rti.org/publications/cer/7007-3-auto.pdf.
 Schenck DA, Wilson PR. Information Modeling the EXPRESS Way.
Oxford: Oxford University Press, 1994.
 ISO 10303-11:1994. Industrial automation systems and integration—
product data representation and exchange—Part 11: description
methods: the EXPRESS language reference manual, ISO TC184/
 ISO 10303-22:1999. Industrial automation systems and integration—
product data representation and exchange—Part 22: implementation
methods: standard data access interface, ISO TC184/SC4, 1999.
 ISO 10303-27. Industrial automation systems and integration—
product data representation and exchange—Part 27: implementation
methods: Java language binding to SDAI.
 ISO 10303-26. Industrial automation systems and integration—
product data representation and exchange—Part 26: implementation
methods: IDL language binding to SDAI, ISO TC184/SC4.
 ISO 10303-14. Industrial automation systems and integration—
product data representation and exchange—Part 14: EXPRESS-X
Mapping Language, ISO TC184/SC4.
 Hardwick, M. The STEP Services Reference Manual, Tech. Report
96004, Laboratory for Industrial Information Infrastructure,
Rensselaer Polytechnic Institute, Troy, New York, 1995 (http://
 Revised Submission (including errata changes)-PDM Enablers-Joint
Proposal to the OMG in Response to OMG Manufacturing Domain
Task Force RFP (URL:http://www.omg.org/arch2/mfg/98-02-
 OMG, The Common Object Request Broker: Architecture and Speci-
ﬁcation (CORBA). Includes a deﬁnition for the Interface Description
Language (IDL). (URL:http://www.omg.org/corba/c2indx.htm).
 ISO 10303-203:1994. Industrial automation systems and integra-
tion—product data representation and exchange—Part 203: conﬁg-
uration controlled design. International Standard, ISO TC184/SC4,
 Hardwick M, Spooner D, Morris KC, Rando T. Sharing manufactur-
ing information in virtual enterprises. Communications of the ACM
 Morris, KC, Mitchell, M, Feeney, AB. Validating STEP application
models at the national PDES Testbed, NISTIR 5196. National
Institute of Standards and Technology, Gaithersburg, MD, May
 Hardwick M, Spooner D, Rando T, Morris KC. Data protocols for the
industrial virtual enterprise. IEEE Internet Computing 1997;1(1)
 Hartman J, Wernecke J. The VRML 2.0 Handbook. Reading, MA:
 ISO 10303-21:1994. Industrial automation systems and integration—
product data representation and exchange—Part 21: implementation
methods: clear text encoding of the exchange structure. International
Standard, ISO TC184/SC4, 1994.
 Morris, KC, Flater, D. Standards-based software testing in a net-
centric world. Proceedings of the 1999 Software Technology and
Engineering Practice (STEP’99) conference, September 1999, in
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166166