1. Lessons learned developing protocols for the industrial virtual enterprise
M. Hardwicka,*, K.C. Morrisb
, D.L. Spoonera
, T. Randoc
, P. Dennob
a
Rennselaer Polytechnic Institute, Center for Automation Technologies, 110, 8th Street, CII 7015, Troy, NY 12180-3590, USA
b
National Institute of Standards and Technology, USA
c
Electric Boat Corporation, USA
Accepted 2 September 1999
Abstract
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, workflow 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
1. Introduction
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) [1]. STEP provides
common definitions 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 benefit 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 [2].
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 figure 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
unified product data set for access and modification 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 influenced the design
of the VEPR and how they are influencing the deployment
phase of NIIIP. Section 6 summarizes the protocols and
makes predictions about future developments.
2. Properties desired for a virtual enterprise product
data repository
As defined in this paper, a VEPR integrates product data
Computer-Aided Design 32 (2000) 159–166
COMPUTER-AIDED
DESIGN
0010-4485/00/$ - see front matter ᭧ 2000 Elsevier Science Ltd. All rights reserved.
PII: S0010-4485(99)00098-6
www.elsevier.com/locate/cad
* Corresponding author. Tel.: ϩ1-518-276-6752; fax: ϩ1-518-276-2702.
E-mail address: hardwick@steptools.com (M. Hardwick).

2. 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 first 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 first 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 defines 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 definition 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 files.
However, STEP information can also be shared using an
EXPRESS-driven programming interface called the
Standard Data Access Interface (SDAI) [5]. 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 define a
VEPR. The first two are being made into new ISO2
standards, and the fourth is being made into an Object
Management Group3
(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 classified
the same within the NIII protocols. An implementation will
choose one or the other, but not both.
EXPRESS-X is a language for finding and mapping data
between EXPRESS models. It can be used to find the data
needed by a client in the standard database stored in a server
and map that data from the generic model defined by STEP
into the application specific model needed by a client. For
example, an EXPRESS-X mapping can be defined to find
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 defines data integration
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166160
Fig. 1. Challenge problem for the three demonstrations.
1
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.
2
www.iso.ch/infore/intro.html#whatsISO.
3
www.omg.org.
4
Interface description language [11].

3. operations. With these operations, an application can inte-
grate objects from multiple sources to create a database. The
services define how an application can traverse a set of
objects, find new objects, copy them to another data set,
and integrate those copies with the existing objects in the
database.
The PDM Enablers are a set of interfaces for Product Data
Management systems. Unlike STEP, which provides very
detailed definitions for data, these interfaces are defined at a
user-oriented level. OMG plans to define similar standards
in many other areas also related to STEP, such as MES and
ERP.5
One can view the NIII protocols as a bridge between
industry specific object models such as the ones being
defined 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 define 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 configuration 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 firewall. It was then brought over the firewall, loaded
into the VEPR and joined with data from an internal CATIA
Data Manager (CDM)6
database.
The VEPR was defined by STEP Application Protocol
203 (AP-203) [12]. AP-203 defines an information model
for the configuration controlled assemblies and their designs
as used by aerospace and automobile manufacturers. The
model contains approximately 500 data definitions. The
external interface for the VEPR was defined 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 definitions 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
Services protocol.
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166 161
Fig. 2. Configuration of the EBC Cycle 3 pilot.
Fig. 3. VEPR architecture.
5
www./omg.org/homepages/mfg.
6
Names of companies and products, and links to commercial pages are
provided to adequately specify procedures and equipment used. In each
case identification 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.

4. 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 file into the
Import Area and displayed the set of objects found in the
file by the EXPRESS-X filter. 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 file by the
EXPRESS-X filter.
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
about STEP.
5. Experience with the protocols
The four NIIIP protocols used in the VEPR were defined
as a result of experiences gained during three end-of-cycle
demonstrations prepared by the members of the NIIIIP
Consortium.
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 workflow.
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 difficult
than necessary so we hoped to overcome these barriers using
CORBA.
• 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 definitions 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 definitions.
• 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-defined 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 fixed-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 first NIIIP cycle, the team built a data access
demonstration that loaded STEP data into a variety of
Computer Aided Design (CAD) systems [13]. 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 file described by the web pages
into his or her CAD system. It was assumed that this CAD
system was different from the first CAD system [14].
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 first CAD system was stored as a
STEP file and the data selected by the user was loaded into
the other CAD systems using a STEP file. 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 find the product data.
Because of the Normalization-Barrier, the STEP file for a
product model contains lots of small data definitions. When
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166162
Fig. 4. Cycle 1 demonstration. STEP data is found using web pages.

5. each one is converted into a Hyper-Text Markup Language
(HTML) page the result is many difficult-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) definitions provided
by STEP.
The barrier was addressed by inventing a mapping
language to extract the information needed for a web page
from the “sea” of entities defined by a STEP file. 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 file. 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 file that
contained the right objects for loading into his or her CAD
system.
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
[15]. 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 [16]. 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
Internet.
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
defines a set of operations for manipulating EXPRESS-
defined data in application programs. The programs can
open repositories, find 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 find 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 modified 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 define a format for “externalizing” each data type.
For example, the most efficient method to transfer a select
type may be to require an explicit label field 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. Defining 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 [17]. In the end, a custom trans-
lator written by Rensselaer Polytechnic Institute allowed the
data to be instantiated in one pass but it was specific 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 modification.
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 benefits 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
applications.

6. 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
Section 5.1.
5.4. Cycle 3 lessons (7/96–7/97)
Cycle 3 focused on defining 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 first,
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 finds the
required information. This becomes quite complicated if
one enterprise defines an assembly and another enterprise
defines a component of the assembly because the identity of
the component must be found in the first 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
components.
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 configuration-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 specified 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 firewalls (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 final touches are being made to the
NIIIP architecture for product data [18].
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.

7. extended to interface to the Enterprise JavaBean
Framework.
• 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 defining
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 difficult 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 define 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 artificial 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 defined protocols sufficient for data exchange, but
not sufficient for data sharing;
• STEP did not include definitions for every kind of
product data activity.
The first 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 defined in advance of the ISO
standards.
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 significant problem for product data
developers. Folding all the requirements into one specifica-
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 specifications. There is a large appetite for new speci-
fications 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
Table 1
Summary of the NIIIP protocols for product data
NIIIP protocol Standards role VEPR role
SDAI Java [6]
SDAI IDL [7]
Bindings of the SDAI for Java and CORBA applications. Protocol to transport product data between a
VEPR and its client applications.
EXPRESS-X [8] A language for describing how information can be mapped between
EXPRESS models.
Protocol to find data in a VEPR and map that data
into the object model used by a client.
STEP services [9] An extension of the SDAI that provides a higher-level interface for
manipulating STEP data.
Protocol for integrating data in a VEPR.
PDM enabler [10] A set of object definitions for Product Data Management Systems. Standard interface for VEPR’s that contain
product assembly information.
7
www.steptools.com, www.mel.nist.gov/msid/msidprod.htm,
www,epmtech.jotne.com, www.prostep.de. 8
www.stepnet.org.

8. that it must include definitions for so many different kinds of
information. Without the NIII protocols it is very difficult
for an application to find the data it needs in all of these
definitions. 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.
References
[1] ISO 10303-1:1994. Industrial automation systems and integration—
Overview and fundamental principles. International Standard, ISO
TC184/SC4, 1994.
[2] 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.
[3] Schenck DA, Wilson PR. Information Modeling the EXPRESS Way.
Oxford: Oxford University Press, 1994.
[4] 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/
SC4, 1994.
[5] 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.
[6] ISO 10303-27. Industrial automation systems and integration—
product data representation and exchange—Part 27: implementation
methods: Java language binding to SDAI.
[7] 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.
[8] ISO 10303-14. Industrial automation systems and integration—
product data representation and exchange—Part 14: EXPRESS-X
Mapping Language, ISO TC184/SC4.
[9] Hardwick, M. The STEP Services Reference Manual, Tech. Report
96004, Laboratory for Industrial Information Infrastructure,
Rensselaer Polytechnic Institute, Troy, New York, 1995 (http://
www.steptools.com/projects/niiip/STEPServices.html).
[10] 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-
02.pdf), 1998.
[11] OMG, The Common Object Request Broker: Architecture and Speci-
fication (CORBA). Includes a definition for the Interface Description
Language (IDL). (URL:http://www.omg.org/corba/c2indx.htm).
[12] ISO 10303-203:1994. Industrial automation systems and integra-
tion—product data representation and exchange—Part 203: config-
uration controlled design. International Standard, ISO TC184/SC4,
1994.
[13] Hardwick M, Spooner D, Morris KC, Rando T. Sharing manufactur-
ing information in virtual enterprises. Communications of the ACM
1996;39(2).
[14] 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
1993. (http://www.mel.nist.gov/msidlibrary/doc/morris93.ps).
[15] Hardwick M, Spooner D, Rando T, Morris KC. Data protocols for the
industrial virtual enterprise. IEEE Internet Computing 1997;1(1)
http://www.computer.org/internet/ic1997/w1toc.htm.
[16] Hartman J, Wernecke J. The VRML 2.0 Handbook. Reading, MA:
Addison-Wesley, 1996.
[17] 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.
[18] 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
press.
M. Hardwick et al. / Computer-Aided Design 32 (2000) 159–166166