OpenPDM-based product data exchange among heterogeneous PDM systems in a distributed environment

Transcription

1 Int J Adv Manuf Technol (2009) 40: DOI /s ORIGINAL ARTICLE OpenPDM-based product data exchange among heterogeneous PDM systems in a distributed environment Jeongsam Yang & Soonhung Han & Matthias Grau & Duhwan Mun Received: 19 May 2007 / Accepted: 11 January 2008 / Published online: 16 February 2008 # Springer-Verlag London Limited 2008 Abstract In a global product development environment, more and more companies are implementing distributed engineering processes in order to shorten the time to market and merge different core competences. One of the important issues in collaborative product development during the whole product creation is to easily and quickly access the digital product definition models and documents of relevant partners. The essential problems of product data distribution are that each partner has to know what information to find in which system, how to collect the necessary information from individual systems, and how to assemble partial information so that it becomes complete. Even more difficult is the need J. Yang (*) Division of Industrial & Information System Engineering, Ajou University, San 5, Wonchun-dong, Yeongtong-gu, Suwon , Republic of Korea jyang@ajou.ac.kr S. Han Department of Mechanical Engineering, Korea Advanced Institute of Science & Technology, 373-1, Gusong-Dong, Yusong-Gu, Daejeon , Republic of Korea shhan@kaist.ac.kr M. Grau PROSTEP ITS GmbH, Hein-Sass-Weg 19, Hamburg, Germany Matthias.Grau@prostep.com D. Mun Advanced Transportation System Research Division, Maritime & Ocean Engineering Research Institute, KORDI, 171 Jang-dong, Yuseong-Gu, Daejeon , Republic of Korea dhmun@moeri.re.kr to ensure the partner adapts to every change in the distribution model of information. To solve these problems, we propose the OpenPDM-based product data exchange method among heterogeneous PDM systems, which is a concept of a virtual data warehouse that provides data access to all partners in a distributed environment. The method is effective for partners who require real-time access to data residing in multiple heterogeneous PDM systems. We also implemented an integrated PDM system for logically linking product data which are physically distributed, and we used this system in a data exchange experiment. Keywords Data exchange. Distributed data management. OpenPDM. PDTnet. Product data management (PDM). STEP PDM schema 1 Introduction In the manufacturing industry, the system of product data management (PDM) consists of a co-axis system with enterprise resource planning (ERP). PDM is an information infrastructure that facilitates the collection, saving, and management of a variety of product data in the life cycle of a product. The data ranges from conceptual definitions of products to details of the design, development, manufacture, and delivery of products, as well as customer service. The ERP system offers a way of describing and executing business activities as well as storing data on business activities in an integrated database. In contrast, the PDM system offers a way of managing and providing reference data on various parts and products from the overall business activities. In other words, the reference data of products and parts are the most basic data in manufacturing; they are analogous to the way in which personal types of information, DO01399; No of Pages

2 1034 Int J Adv Manuf Technol (2009) 40: such as the details of someone s name, age, gender, and social security number, are the most basic data in human resources. Recently, many companies have studied and introduced the PDM system very competitively, focusing on costcutting and shortening the product development cycle. However, the PDM system has been used only in a limited way in companies with respect to the management of drawings and part data. This limited use is due to the fact that these companies are aware of the enormous difficulties and problems of linking and integrating the PDM system with the ERP, customer relationship management, and CAx (CAD/CAM/CAE) systems. In addition, as several companies begin to develop new products, there is a corresponding increase in the demand for product data integration in a distributed environment. We suggest the use of OpenPDM, which is a concept of a virtual data warehouse that provides data access to all partners in a distributed environment, as a way of exchanging product data among heterogeneous PDM systems. We also implemented an integrated PDM system for logically linking product data which are physically distributed, and we used this system in a data exchange experiment. 2 Related work Obstacles in the process of product data exchange among heterogeneous PDM systems include data inconsistencies between senders and receivers, heterogeneity of data, and loss of data quality. These problems are caused by the fact that people who are responsible for creating data generally stick to the former system and are unfamiliar with the methods of data sharing and re-creating data. Thus, in spite of some recent attempts to consolidate distributed product data, only a limited form of data exchange is available. A project of the German automotive industry called Product Data Technology and Communication in an OEM and Supplier Network (PDTnet) developed a uniform PDM interface based on a neutral data model for PDM data [1]. This PDM interface, called OpenPDM, is a PDM bridge that facilitates the horizontal interfacing of several PDM systems through a Web client, thereby providing users with a single view of product data in a distributed environment. However, OpenPDM is limited to single systems and is not applicable to a virtual view because it is hard to keep track of who has received what data and when; hence, collaboration is difficult. Another significant drawback of OpenPDM is the positioning of the unification in the client, which means that the virtual view can only be used for presentations. There is no chance of applying additional modules of business logic to the unified view. Nowachi and Lukas proposed a PDM federation interface in which a higher degree of flexibility can be achieved in the integration of product data by approaching the side of the server [2, 3]. Through the introduction of a single virtual PDM system, the concept of a PDM federation provides a method of receiving client queries and processing them in several concrete PDM systems. This approach conceals the internal complexity of the federation and offers a uniform view and access to the data. Furthermore, the virtual PDM layer does not replicate the product data but is responsible for distributing queries and collating partial results to produce an overall result based on the distribution model. However, given that a uniform data model for applying the virtual PDM system is under development, there are still a number of problems in the general use of the commercial PDM system. Stouffs et al. provides a framework for representing product data based on a standardized syntax for the data exchange [4]. It defines primitive data types that can be combined using formal compositional operators to form more complex data types. The resulting canonical representation allows comparing, mapping, and translating different product models. Morris et al. described a case study and solution of an IBM research project (called Hedwig) to investigate creating robust solutions for PLM [5]. They focused on several research issues, including information federation, data mapping, synchronization, and web services connections. They described a working system that allows access to several heterogeneous PDM systems that are used in the automotive and aerospace industries. Besides researching the integration of several PDM systems, researchers are examining approaches to the exchange of product data between two PDM systems by means of the interface called Standard for the Exchange of Product Model Data (STEP, ISO 10303). Goellnitz et al. proposed a method of integrating PTC s Windchill with Dassault Systemes ENOVIA VPM through a PDM backbone that includes a STEP PDM processor [6]. To exchange product data between UGS s Teamcenter and PTC s Windchill, the US Army developed, for both PDM systems, an interface adaptor that supports the STEP application protocol (AP) termed AP214 CC6 (where CC refers to conformance classes) [7]. 3 Product data exchange among heterogeneous PDM systems 3.1 Virtual PDM system The virtual PDM system is a multi-pdm bridge system that integrates product data to enable cross-enterprise engineering and synthesizes product data across PDM systems for the

3 Int J Adv Manuf Technol (2009) 40: exchange and interconnection of data, thereby providing data access to all partners in a distributed environment. We used the OpenPDM modules developed by ProSTEP AG as a virtual PDM system. OpenPDM is effective for partners who require real-time access to data residing in multiple heterogeneous PDM systems; it also presents a single, uniform view of all the product data of a company. OpenPDM, as shown in Fig. 1, consists of three layers [8]. The data exchange between PDM systems is executed through an instanced Extensible Markup Language (XML) file, which is based on the PDTnet schema derived from the STEP PDM schema. In other words, OpenPDM is an XML file-based system without an additional physical database. The backend layer provides a flexible mechanism for accessing PDM systems, such as SmarTeam of Dassault Systemes and Teamcenter of UGS, in an environment of heterogeneous systems. In addition, the backbend layer makes it possible to synchronize the individual PDM systems of a company by providing modules for a relational database that can be used to save persistent data. Those modules include the lightweight directory access protocol (LDAP) for user management and an intermediate storage file system for product data and physical CAD models. A STEP processor connected to OpenDXM, which is called a data exchange manager, maps the data of the STEP PDM schema and the PDTnet schema, both of which are internally defined in OpenPDM. The middleware and the backend layer in OpenPDM communicate through a proprietary protocol defined in relevant concrete PDM systems. As a frontend layer, the client performs on-line browsing of product data in connected concrete PDM systems. Moreover, it facilitates the import and export of data, the mapping of product structures, job persistence, and OpenPDM administration. The communication between a client and the middleware is executed via an external service bus by means of the data exchange protocols of HTTP and web-based distributed authoring and versioning (WebDAV), as well as the standard simple object access protocol (SOAP), which calls the internal OpenPDM module. To administer and configure OpenPDM, we need to use the HTTP of a web browser for the purpose of communicating with the middleware. The middleware of OpenPDM, which is an application that supports Java 2 Enterprise Edition (J2EE), has six major components. The first component is a connector that represents the interfaces to the backend, that is, the connector enables the data model to interface with a concrete PDM system in the backend layer. Because of the difficulty of accessing subtle data, such as the userdefined data model saved inside the PDM system, the connector gains data access by providing a connector server that is similar to a native server application of the operating system. The second component is a Amapping service that converts the backend data to the STEP format, which is represented in XML. The conversion and exchange of product data inside the middleware are executed through an internal data bus. Next, there is an OpenPDM administration Web interface (OPAWI), which facilitates the administration of the OpenPDM middleware. The fourth component is a file server for the exchange of a substantial amount of data, such as that pertaining to product structures, metadata, and CAD models. A protocol of the file server is WebDAV, which runs within the application server or as a separate service. The Fig. 1 OpenPDM architecture [8]

4 1036 Int J Adv Manuf Technol (2009) 40: clients and the middleware both need access to the WebDAV service. The fifth component is a license client, which verifies the available components in the OpenPDM that connect the license server to the backend layer. Finally, there is a configuration file loader for the middleware. Many configuration files are needed for the configuration of the middleware. These files exist in a file system and are loaded into the middleware by the class loader of the application server. In addition, there are several Web services which facilitate the connection of the internal data bus in the middleware to external clients by representing an interface to the client layer in the form of an external service bus. Moreover, the methods of particular standards such as the PDTnet and OMG PLM services, which are provided by Web services, also offer sufficient functionality. 3.2 Analysis of the STEP and PDTnet schemas The STEP PDM schema is a reference information model for exchanging the common data to be managed in a PDM system. The STEP PDM schema V1.1, which is derived from STEP AP214 CC6, was presented in 1998 by ProSTEP of Germany and by Product Data Exchange using STEP (PDES) of the United States [9]. We found that the STEP PDM schema V1.1 has almost the same scope as PDM Enablers V1.3 and partially includes configuration management. A new version, the PDM Schema V1.2 of STEP AP214 CC8, has been released with the additional function of configuration management, which is similar to the variant management of PDM Enablers V2.0 [10]. However, its use is limited to the exchange of product data because the STEP PDM schema is unable to represent either the functions required by general PDM systems or the contents of business documents as a data model. For these reasons, the STEP PDM schema can only be used properly for the exchange of real business information if its functions are extended [11 13]. The PDTnet schema in XML was developed in a joint PDTnet project of ProSTEP and German car manufacturers and industry suppliers [1]. The goal of the PDTnet project is to develop and implement solutions for the integration of inter-system and inter-company product data on the basis of XML technology. The PDTnet schema, which is derived from the STEP PDM schema and the relevant subset of STEP AP214, combines the advantages of STEP as a standardized data model for PDM data and XML; it also provides facilities for structured data access and makes STEP technology available for Web applications. The PDTnet schema, which combines the STEP standard for digital product descriptions with leading Internet standards for data communication, was derived from STEP AP214; thus, its expressions and construction are similar to that of AP214. However, because the PDTnet schema was developed for SOAP binding, which is used for on-line PDM Web integration, its structure was partly modified; that is, the information model of AP214, which is in the EXPRESS format, was changed into a definition of the W3C XML schema. In addition, some of the EXPRESS attributes were implemented as XML elements. Figures 2 and 3 show examples of how an explicit hierarchical product structure can be expressed in EX- Fig. 2 Data model of the product structure information in the STEP PDM schema as represented by EXPRESS-G

5 Int J Adv Manuf Technol (2009) 40: Fig. 3 XML schema element structure of the product structure information in the PDTnet schema as represented by XMLSpy of Altova PRESS-G and in the PDTnet schema. Figure 2 shows some of the product structure information that is instanced in the STEP PDM schema [8]. In addition to hierarchical product structures representing the constituents of assemblies, STEP PDM schema supports relationships between parts to characterize explicit alternates and substitutes for the assembly. Other relationships between part definitions exist to characterize the make from the relationship and for supplied part identification. This entity is a subtype of assembly_component_usage and represents a single individual occurrence of a component definition as used in an immediate next higher parent assembly. We can create an explicit assembly bill of material (BOM) by using the next_higher_assembly object that refers next_higher_assembly.relating to the super assembly design_discipline_ item_definition (DDID) and next_higher_assembly.relating to the subassembly or leaf (namely, the item_instance subtypes). Any structure can be created with this construct. The attribute item_instance.id contains a unique instance identifier for the occurrence of an individual component. The most frequently used item_instance subtypes are single_instance for single parts and quantified_instance for multiple occurrences. The element item_definition_relationship was changed by deleting the attribute relating. As shown in Fig. 3, this object in PDTnet is defined as an element of DDID. Moreover, the related attribute is used as defined in AP214 for referring to a child (leaf or subassembly). Table 1 shows a comparison of the STEP PDM schema and the PDTnet schema. 3.3 Product data exchange scenario In today s manufacturing environment, a single company rarely performs the entire manufacturing process of a product, but rather parts of the manufacturing process are distributed to specialist companies. This trend is especially evident in the automotive industry, where product data is actively shared from company to company. However, the Table 1 Comparison of the STEP PDM schema and the PDTnet schema STEP PDM schema PDTnet schema Objective For standardized neutral product data exchange For on-line PDM Web integration compatible on multiple platforms Contents Platform independent model representing business functionality and behavior Platform-specific model with XML/SOAP-binding but could be used directly by software development tools for a company-specific model Developer ISO SC4 TC184 (industrial automation systems and ProSTEP AG and German automotive industry group integration) Representation EXPRESS and XML document type definition XML schema definition method Superset specification STEP AP214 CC8 and PDM Enablers specification V2.0 STEP PDM schema V1.2 Features Even though the STEP PDM schema is widely accepted as the international standard for product information exchanges, it neither covers all the information in documents nor represents the content of most information models related to product development Web-enabling PDM schema Better suited for definition of interfaces to PDM systems Possible mappings to/from STEP PDM schema

6 1038 Int J Adv Manuf Technol (2009) 40: Fig. 4 Data exchange scenario for collaborative design in an automotive supply chain St andard schem a-based virtual PDM s ystem e.g. O penpdm OEM (Prim e c ontractor) e.g. using CATI A & ENOVIA Coll aborative De s ign 3rd T ier s upplier e.g. us ing a W eb brows er to a ccess ma nufacturing data OE M or 1s t Tier e.g. us ing Solid W orks & MatrixOne 2nd Ti er sup plier e.g. using CATI A & DynaPDM sharing of product data among companies causes many problems. The biggest problem is that each company likes to manage product data in accordance with its own standpoint and method. A data converter had to be developed to facilitate the exchange of product data among heterogeneous PDM systems but PDM systems are modified for many reasons. Thus, the data converter must be continually modified and improved accordingly. As companies form new partnerships, the burden of developing and maintaining the data converter continues to increase, and many problems arise in the system because of the system s ever-growing complexity. To execute a new car project, the original equipment manufacturer (OEM) should cooperate with relevant industry suppliers. However, because these suppliers use different CAx and PDM systems, the product data exchange causes interoperability problems that occur not only among different companies but also among different departments of the same company. In the field, there are two methods of data exchange. One method is a form of asynchronous file-based data exchange, where data is exchanged between PDM systems by the transfer of physical files such as an Excel document file or a neutral file. The other method is a form of synchronous data sharing, where data is exchanged between PDM systems by a direct translator in each PDM system. However, both methods suffer data loss in the data exchange, thereby adding to the cost of developing and maintaining the translator. Fig. 5 Configuration of the PDM integration system

7 Int J Adv Manuf Technol (2009) 40: An alternative method that overcomes interoperability problems, as shown in Fig. 4, is to introduce a standard schema-based virtual PDM system. In this method, data is exchanged through a virtual PDM system that acts as a PDM bridge system; this method is based on a schema with in-house standard specifications approved by the organizations engaged in the product data exchange or with the international standard STEP. To realize a virtual PDM system for product data exchange, we used middleware based on the SOAP internet protocol and the common object request broker architecture, which is an architecture and specification for creating, distributing, and managing distributed program objects in a network. We also used the standardized software technology of an XML-based Web service to connect the PDM systems of several partners through an open network accessible via the Internet. Using PDTnet schema-based OpenPDM, which is a virtual PDM system, we implemented an integrated PDM system that enables product data to be exchanged between three commercial PDM systems. We also experimented on the performance of this system with respect to product data exchange. 4 Implementation of the PDM integration system 4.1 System implementation The system configuration, as shown in Fig. 5, consists of three commercial PDM systems: SmarTeam of Dassault Systemes, DynaPDM of INOPS, and MatrixOne of Dassault Systemes. In addition, we linked the virtual PDM system OpenPDM to each of the three systems. Although OpenPDM, DynaPDM, SmarTeam, and MatrixOne are physically distributed, they are all logically connected together. The OpenPDM client that connects to the OpenPDM server executes an engineering change after Fig. 6 A data exchange process between OpenPDM and DynaPDM

8 1040 Int J Adv Manuf Technol (2009) 40: using WebDAV to read the product data stored in the OpenPDM file service. In addition, the client transfers commands to the OpenPDM server. The transfer of commands is to ensure the connection of the relevant PDM systems and to make XML-typed query commands. The client then transfers the commands to the server so that specific product information in these PDM systems can be checked. To enable SmarTeam and MatrixOne to be integrated with OpenPDM, we optimized the PDM connector module provided by ProSTEP and applied the module to the inside of the OpenPDM. The connector module, which was developed by using the API libraries provided by Smar- Team and MatrixOne, uses XML-type queries to search for specific product data of the server and then transfers the specific product data to relevant PDM systems via SOAP. The PDM systems subsequently return the query results to OpenPDM through the connector. Besides the connector, we implemented a bidirectional translator based on the PDTnet schema and, because OpenPDM doesn t support the internal connector for DynaPDM, we included the bidirectional translator in the DynaPDM for the sake of integration with the DynaPDM. Through this translator, the DynaPDM data is converted into an XML file and transferred to the OpenPDM server through a network, or the DynaPDM receives the Fig. 7 A UML sequence diagram of the product data exchange

9 Int J Adv Manuf Technol (2009) 40: OpenPDM data represented in XML and saves the data in an Oracle database of DynaPDM. Figure 6 shows the data exchange process between OpenPDM and DynaPDM. The transfer server of the network file is a server application for the exchange of XML files between two PDM systems through a network. A PDTnet schema-based XML parser plays a role in either converting the DynaPDM data into an XML file or enabling the XML file that is transferred from OpenPDM to be read in DynaPDM. A runtime engine of the Java architecture for XML binding (JAXB), which binds a Java object for logical handling of the XML schema, parses the XML instance file, changes it to a Java object, and then converts the Java object into an XML file. The XML binding Java object compiles the XML schema file by means of the JAXB compiler, and then generates the source code of the Java classes that are bound with XML elements. The source code generated by the XML binding Java object is modified to add routines that link to DynaPDM. The data importer and exporter read and write the DynaPDM data by using the APIs provided by the XML binding Java object and the DynaPDM framework. Besides using the type of client server data exchange mentioned above, local PC users who don t have a PDM system can access product data from other PDM systems through a Web browser; this process can be performed after an extensible-style language transformation of the XML product data in the OpenPDM server which converts the data into an XML document that uses formatting vocabulary. 4.2 Experiment on product data exchange By using our integrated PDM system, we conducted an experiment on the exchange of product data between SmarTeam, MatrixOne, and DynaPDM, mainly with OpenPDM. The experimental data used for the product data exchange are the metadata and physical files that were built in SmarTeam by a first-tier company of the Korean automotive industry. Fig. 8 Example of product data exchange from SmarTeam to MatrixOne by way of OpenPDM SmarTeam connected Retrieve product data from SmarTeam and transfer them to OpenPDM Transfer them to MatrixOne MatrixOne connected Store them to MatrixOne and compare with OpenPDM

10 1042 Int J Adv Manuf Technol (2009) 40: First, we exchanged the metadata of the bill of material regarding the product data structure; we also exchanged physical files, such as CAD files and document files, by linking OpenPDM and SmarTeam. Figure 7 shows a unified modeling language (UML) sequence diagram of the data exchange between four PDM systems. The OpenPDM client first makes a request to the OpenPDM server to connect the SmarTeam, MatrixOne, and DynaPDM servers; it then Fig. 9 Snapshot of the Smar- Team data (upper window) stored in OpenPDM through a Web browser (lower window)

11 Int J Adv Manuf Technol (2009) 40: acquires the desired product data from SmarTeam and takes that data to the OpenPDM server. Next, the OpenPDM client executes an engineering change in OpenPDM and returns the modified data back to SmartTeam. In this case, the modified data is transferred not only to SmarTeam but also to MatrixOne and DynaPDM. Lastly, the SmarTeam data, which is stored in OpenPDM, appears on a Web browser for local PC users. Figure 8 shows how product data is exchanged between SmarTeam and MatrixOne by way of OpenPDM. First, the OpenPDM server sends the SmarTeam and MatrixOne servers a message command to be connected to the OpenPDM. As shown in the first pane of Fig. 8, after the connection is completed, the product data of SmarTeam is called by the OpenPDM client with a passive mode. The product data that are read in OpenPDM with the passive mode can be visualized but not modified in the client. To transfer the SmarTeam data to MatrixOne, as shown in the second pane of Fig. 8, we should ensure that the metadata and physical data of SmarTeam are imported into the OpenPDM server. The SmarTeam data that are transferred to OpenPDM in accordance with the changing needs of the user are partially revised and passed on to MatrixOne, which (as shown in the third pane of Fig. 8) has a prior connection to OpenPDM. The final revisions of the product data, which reflect the changes made during the data exchange, can be verified by means of the comparative process shown in the fourth pane of Fig. 8. In addition, as shown in Fig. 9, a user may visualize the data stored in OpenPDM via the Web browser of a local PC. The data exchange with DynaPDM is conducted in the same way. 5 Summary and discussion Nowadays the development activities in industries such as automotive and aerospace are widely distributed. Furthermore, industry suppliers shoulder more and more responsibility, and partners tend to concentrate on their own particular areas of strength. However, the fact that each company manages its product data by its own method has become the biggest obstacle with respect to the sharing of product data. This problem arises because the owners of each business generally stick to existing systems and are unfamiliar with methods of data sharing and regeneration. These interoperability problems occur not only among different companies but among different departments of the same company. Hence, there is a growing demand for a common method of sharing standard product and design information, especially for those who request an exchange of product data in the product planning stage or the conceptual design stage. We analyzed the STEP PDM schema, which is an international standard for data exchange between PDM systems, as well as the PDTnet schema, which is derived from the STEP PDM schema. In addition, we introduced a data exchange scenario in which we applied these schemas to the supply chain of the automotive industry. Furthermore, to investigate the possibility of exchanging product data in a distributed environment, we implemented an integrated PDM system on the basis of the demand for logically integrated product data stored physically in a distributed environment. With this system, we proposed a method of data exchange based on OpenPDM, which is a kind of virtual data warehouse for heterogeneous PDM systems. Acknowledgement This work was supported by Ajou University, Korea through project no References 1. Ungerer M, Nielsen J, Maertensson P (2003) White paper for the use of standards based data communication methods in automotive industry. ProSTEP. Accessed 29 January Nowacki S, Lukas U (2003) Efficient and convenient federation of product data. Proceedings of ProSTEP ivip science days, Stuttgart, Germany, pp Lukas U, Nowacki S, Ruediger D (2003) Cross-enterprise exchange of product data. Computer Graphik 15: Stouffs R, Krishnamurti R (2002) Representational flexibility for design. Proceedings of artificial intelligence in design 02, Dordrecht, The Netherlands, pp Morris H, Lee S, Shan E, Zeng S (2004) Information integration framework for product life cycle management of diverse data. J Comput Inf Sci Eng 4: Goellnitz B, Priebe K, Schreiber A, Mechlinski T (2001) PDM data exchange between Windchill and ENOVIA VPM at Webasto. Prod Data J 2: Lyer R (2005) PLM for the US Army. Proceedings of the 7th NASA-ESA workshop on product data exchange (PDE 2005), Atlanta, Georgia, USA 8. ProSTEP (2005) ProSTEP solutions: OpenPDM. prostep.de/en/solutions/openpdm/herausforderung/. Accessed 29 January PDM Implementation Forum (2002) Usage guide for the STEP PDM schema release 4.3. Downloaded from org/pdm_schema/. Accessed 29 January PDM Implementation Forum (2003) PDM schema homepage. Accessed 29 January Lee JH, Chae SH, Suh HW, Kwon K-E, Choi Y, Cho SW (2003) The extension of STEP PDM schema for information sharing in a practical application. Proceedings of 10th ISPE international conference on concurrent engineering (ISPE CE 2003). Madeira, Portugal, pp Choi G-H, Mun D, Han S (2002) Exchange of CAD part models based on the macro-parametric approach. Int J CAD/CAM 2 (2): Kim B, Han S (2007) Integration of history-based parametric translators using the automation APIs. Int J Prod Lifecycle Manage 2(1):18 29