Lessons learned developing protocols for the industrial virtual enterprise

Transcription

1 COMPUTER-AIDED DESIGN Computer-Aided Design 32 (2000) Lessons learned developing protocols for the industrial virtual enterprise M. Hardwick a, *, K.C. Morris b, D.L. Spooner a, T. Rando c, P. Denno b a Rennselaer Polytechnic Institute, Center for Automation Technologies, 110, 8th Street, CII 7015, Troy, NY , 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 Elsevier Science Ltd. All rights reserved. Keywords: Computer aided design; Computer aided manufacturing; Computer aided engineering 1. Introduction The National Industrial Information Infrastructure Protocols (NIIIP) Consortium is a team of organizations that entered into a cooperative agreement with the US Government, in 1994, to develop inter-operation protocols for manufacturers and their suppliers (for more information on NIIIP see The selected protocols make it easier for engineering organizations to share technical product data over the Internet. 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 Engineering (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 * Corresponding author. Tel.: ; fax: address: hardwick@steptools.com (M. Hardwick). 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 implement 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 /00/$ - see front matter 2000 Elsevier Science Ltd. All rights reserved. PII: S (99)

2 160 M. Hardwick et al. / Computer-Aided Design 32 (2000) Fig. 1. Challenge problem for the three demonstrations. 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 coordinating 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 organization 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 similar to other data definition languages, but unique because it can describe the complex data structures and constraints 1 Copies of the STEP standards can be obtained from ANSI at a web site maintained by the US Product Data Association: 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 ISO 2 standards, and the fourth is being made into an Object Management Group 3 (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 IDL 4 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 repository, 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 Interface description language [11].

3 M. Hardwick et al. / Computer-Aided Design 32 (2000) operations. With these operations, an application can integrate 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 In Cycle 3, the four NIIIP protocols were used to define a VEPR for an end of cycle demonstration 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 demonstration, 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 external 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 relationships, and so on. The 40 objects were related to the 500 data definitions using EXPRESS-X mappings. Fig. 2. Configuration of the EBC Cycle 3 pilot. 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 integration 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 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. Fig. 3. VEPR architecture.

4 162 M. Hardwick et al. / Computer-Aided Design 32 (2000) Fig. 4. Cycle 1 demonstration. STEP data is found using web pages. 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 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 normalization. Processing STEP data is easier if it can be encapsulated 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 sharing. 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 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 illustrates 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

5 M. Hardwick et al. / Computer-Aided Design 32 (2000) 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 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 demonstration. 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 EXPRESSdefined 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 Fig. 5. Cycle 2 demonstration. STEP data is loaded into Java and IDL applications. 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 transferred 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 partners 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 externalization 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 translator 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 differences 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

6 164 M. Hardwick et al. / Computer-Aided Design 32 (2000) 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 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 enterprise 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 enterprises, 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 represented 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 enterprise. 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 information 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) New lessons for the deployment phase ( ) The research phase of NIIP ended in In the deployment phase, the protocols are being used to implement teaming databases at the US shipyards and to deliver Fig. 6. NIIIP deployment phase architecture. 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 database. 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

7 Table 1 Summary of the NIIIP protocols for product data M. Hardwick et al. / Computer-Aided Design 32 (2000) NIIIP protocol Standards role VEPR role SDAI Java [6] SDAI IDL [7] EXPRESS-X [8] Bindings of the SDAI for Java and CORBA applications. Protocol to transport product data between a VEPR and its client applications. Protocol to find data in a VEPR and map that data into the object model used by a client. Protocol for integrating data in a VEPR. A language for describing how information can be mapped between EXPRESS models. STEP services [9] An extension of the SDAI that provides a higher-level interface for manipulating STEP data. PDM enabler [10] A set of object definitions for Product Data Management Systems. Standard interface for VEPR s that contain product assembly information. 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 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 demonstrations, 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 www,epmtech.jotne.com, 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 specification usually leads to a complex result. The NIIIP program has implemented protocols to make easier for an organization 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 specifications 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 8

8 166 M. Hardwick et al. / Computer-Aided Design 32 (2000) 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 :1994. Industrial automation systems and integration Overview and fundamental principles. International Standard, ISO TC184/SC4, [2] Brunnermeier, SB, Martin, SA. Interoperability cost analysis of the US automotive supply chain, RESEARCH TRIANGLE INSTITUTE, March 1999, [3] Schenck DA, Wilson PR. Information Modeling the EXPRESS Way. Oxford: Oxford University Press, [4] ISO :1994. Industrial automation systems and integration product data representation and exchange Part 11: description methods: the EXPRESS language reference manual, ISO TC184/ SC4, [5] ISO :1999. Industrial automation systems and integration product data representation and exchange Part 22: implementation methods: standard data access interface, ISO TC184/SC4, [6] ISO Industrial automation systems and integration product data representation and exchange Part 27: implementation methods: Java language binding to SDAI. [7] ISO Industrial automation systems and integration product data representation and exchange Part 26: implementation methods: IDL language binding to SDAI, ISO TC184/SC4. [8] ISO 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 ( [10] Revised Submission (including errata changes)-pdm Enablers-Joint Proposal to the OMG in Response to OMG Manufacturing Domain Task Force RFP (URL: 02.pdf), [11] OMG, The Common Object Request Broker: Architecture and Specification (CORBA). Includes a definition for the Interface Description Language (IDL). (URL: [12] ISO :1994. Industrial automation systems and integration product data representation and exchange Part 203: configuration controlled design. International Standard, ISO TC184/SC4, [13] Hardwick M, Spooner D, Morris KC, Rando T. Sharing manufacturing 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 National Institute of Standards and Technology, Gaithersburg, MD, May ( [15] Hardwick M, Spooner D, Rando T, Morris KC. Data protocols for the industrial virtual enterprise. IEEE Internet Computing 1997;1(1) [16] Hartman J, Wernecke J. The VRML 2.0 Handbook. Reading, MA: Addison-Wesley, [17] ISO :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, [18] Morris, KC, Flater, D. Standards-based software testing in a netcentric world. Proceedings of the 1999 Software Technology and Engineering Practice (STEP 99) conference, September 1999, in press.