INT. J. COMPUTER INTEGRATED MANUFACTURING, 2002, VOL. 15, NO.

1, 1–17

STEP-based data schema for implementing product data management system
SHEN-CHOU YEH and CHUN-FONG YOU

Abstract. Currently, the challenge of implementing a product data management system (PDMS) is how to ensure system integration and product data exchange is shared between heterogeneous systems. In this research, an integrated data models and implementation approach for PDMS is proposed that uses the STEP (Standard for the Exchange of Product) model data standard and schema as proposed by the Object Management Group (OMG). The objective of migrating these data schemas is to propose a standardized product data management (PDM) data schema that fulfils its functionality, including product structure management, configuration management, document management, workflow/process management, effectivity management, and engineering change management. The PDM-related data schema that is defined in the STEP standard, the PDM schema, and the Joint Product Data Management (JPDM) Enablers is identified, discussed, compared and migrated in this paper. To solve the barrier of product data exchange and sharing within and between enterprises, a robust and standardized PDM data schema fulfilling the functionality of PDM can be constructed with the proposed migrated data models. The implementation issues of a STEP-based system via these data schema are also discussed. With the proposed approach and architecture, the integrated data models fulfilling the functionality of PDM for PDMS, as well as the methods of implementing STEP-based PDMS, have been demonstrated.

1. Introduction A product data management system (PDMS) stores and manages complete information of all its products and related activities to ensure a concurrent engineering environment, which facilitates easier and more efficient product development. Currently, an important issue in enterprise integration is the implementation of information systems that facilitate concurrent engineering (Wu et al. 1992, Reddy et al. 1993, Chaxel et al. 1997, Chen and Hsiao 1997). Together with widespread
Authors: Shen-Chou Yeh and Chun-Fong You, Department of Mechanical Engineering, National Taiwan University, Taipei, Taiwan, Republic of China.

computer network applications and standard product data representations, PDMS enables an enterprise to conduct its business activities in a more efficient way (Czerwinski and Sivayoganathan 1994, Gu and Chan 1995). By referencing the PDM-related data schema that was proposed in the Joint Product Data Management (JPDM) Enablers and the Standard for the Exchange of Product model data (STEP) standard, the product data representation is defined and managed via PDMS. The functionality of PDM is the unit of functionality that defines the migrated data models for PDMS implementation. However, the information lost during a product data exchange following data mapping is evident. Although the scope of STEP is expanding, defining the robust data models for PDMS does not include the entire functionality of PDMS. The Application Interpretation Model (AIM) in the STEP standard derives from the Application Reference Model (ARM) of the Application Activity Model (AAM) in a specific application scope. Currently, application protocol to implement an entire PDMS does not exist. Furthermore, the PDM-related data models within STEP are based on the configuration management Unit of Functionality (UoF ), which is simply a portion of the PDM functionality. Therefore, the STEP standard fails to provide a complete product representation of PDMS. This paper proposes to solve the requirement of product data exchange as well as the sharing issue of PDMS. Furthermore, to ensure the conformance between the proposed data schema and STEP standard, a PDM-related information definition is employed. The PDM schema (ProSTEP and PDES, Inc. 1998), abstracted from AP203, AP210, AP212, AP214 and AP232 within the STEP standard, is a vital reference data model for exchanging PDMS product definition data. The PDM schema is also a solution for product data exchange in PDMS to/from PDMS, and PDMS to/from an Enterprise Resource Planning (ERP) system. The

International Journal of Computer Integrated Manufacturing ISSN 0951-192X print/ISSN 1362-3052 online # 2002 Taylor & Francis Ltd http://www.tandf.co.uk/journals DOI: 10.1080/09511920010029263

Furthermore. Section 2 discusses a review of PDMS functionality (CIMdata Inc. Fujitsu Limited. including data storage. relationship. were submitted to the Object Management Group (OMG). defined in STEP standard. effectivity and product configuration define the essence of the definition. 1997. effectivity. Each star indicates the relative completeness. Finally. item property. 2. and configuration. Through these comparisons. Based on the experiences of these companies or organizations. Yeh and C. the data schema of PDMS.-C.-F. 1997) and the comparison of the PDMrelated data schema defined in STEP and JPDM. PDM-related data schema in STEP The PDM-related data schema available in STEP can be derived from integrated resources and application protocols. This section will illustrate the difference by comparing the PDMrelated UoF (unit of functionality) elements of these data schema. the JPDM data schema should be robust. 1997. Moreover. Combined with the PDM schema. Matrix One. 2. and process plan. while a blank indicates the lack of the UoF element data model. classification. the completeness of these data schema can be identified and the proposed migrated data schema for PDMS is depicted in section 3. and JPDM. Fujitsu Limited 1997. You utility functions. source control. To depict the differences and robustness of each data schema. authorization. work. 43 (ISO 1994c). Product identification. User functionality. classification. to illustrate the differences among the data schema. Furthermore. Inc. AP203 (ISO 1994e). The objective of migrating these data schema is to construct a PDMS that is robust and standardized. Inc. is identified. International Business Machines Corporation. are employed. and 44 (ISO 1994d). excluding those that are different. compared and migrated in section 3. validity and configuration of the product JPDM data schema proposed by Digital Equipment Corporation. and Sherpa Corporation. and to maintain a robust correlation among them. Sherpa Corporation 1997). provides the users’ interface to the PDM system’s capabilities. specification control. for PDMS application. including product identification. shape representation. Review of PDM functionality and data schema in STEP and JPDM Table 1 presents a robust PDMS composed of an electronic data repository as well as a set of user and Table 1.2 S. Functionality Items User functionality Configuation management Document management Workflow management Process management Product structure management Classification Program/project management Effectivity management View management Audit Functionality of PDMS. To provide robust data models for product data management and exchange. The migration of these data models is to enable integration of the overlapped portion.. and AP214 (ISO 1997) are applied to define the migrated data model for the exchange of PDMS information. which implements a PDMS to solve the barrier of product data exchange and sharing among enterprises. specification control.. source control. Metaphase Technology. 42 (ISO 1994b). discussed. 14 PDM-related UoFs. PDM schema. the implementation of a STEP-based system via these data schema is discussed in section 4. Product structure. Utility functionality Communication Notification Data transport Data translation Image/models service System administration Data vault Check-in/check-out Access authorization Release management Meta-data storage Data location tracking .1. which is the primary functionality discussed here. to show the scope and ability of each data PDM-related schema. Digital Equipment Corporation et al. and document management. structure. Parts 41 (ISO 1994a). Structural Dynamics Research Corp. This was a response to a request for proposal (RFP) from Product Data Management Enablers (Dassault Systemes 1997. retrieval and the management of product data. table 2 identifies the scope of each data schema. a comparison of the PDM-related data schema in STEP and JPDM is discussed. the conclusion of this work contains a discussion and summary of the migration and implementation of these data schema. and item property define the core of the product data within PDMS.

Configuration ManTable 3. classification and shape representation provides a reference mechanism to specify the associated external documents. To demonstrate the variation between AP214 and JPDM. which indicate the acceptance and authorization of certain product data within PDMS. these data models fail to fulfil the requirement of PDMS product data representation. Index UoF element 1 2 3 4 5 6 7 8 9 10 11 12 13 Product identification Product structure Shape representation Product configuration Effectivity Specification control Authorization Source control Work management Document management Classification Item property Process plan IR’s AP203 AP214 PDM schema * * * * * * * * ** * * * * ** * ** ** ** ** ** ** * ** ** * * ** * ** * * * * * * * * * 3 the standardized AIM for product data management and exchange. is more robust for implementing a STEP-based PDMS. Comparisons of PDM-related UoF in STEP and PDM schema. the PDMS-related data models in AP214. Effectivity. while empty indicates the lack of the data model of UoF element. Framework. Figure 1 illustrates the context and dependency of the UoFs defined in AP214. the work management and process plan defines the data models. which represent activities in one project. table 3 illustrates the scope based on the items derived from these two data models. categories. 1998). the data models in JPDM are employed. The authorization defines the data structures. which define Table 2. Manufacturing Implementation. View. AP214 * * * * * * JPDM * * * * * * * * * * PDM’s functionality Configuration management Document management Workflow/process management without change management Product structure management Classification Project management Effectivity management View management Audit Change management * Each star mark indicates the relative completeness. Comparisons of JPDM and AP214 based on PDM’s functionality. and process-related data in PDMS. . including Responsibility. Foundation. The document management.1 (table 2). To modify these static data models. Dependency of the PDM-related UoFs defined in AP214. Change Management. PDM-related data schema in JPDM data schema Based on the comparison in section 2. Finally. Figure 1. and shape information. Baseline. the functionality representation and I/O interfacing should be enhanced. Product Structure Definition.STEP-based data schema structure. Compared with the functionality of PDMS. To modify and enhance the PDM-related data models in AP214.2. Document Management. Figure 2 illustrates the context and dependency of 13 JPDM modules (Digital Equipment Corporation et al. 2.

and view functionality are included in these data models. agement. and engineering change. iteratable. derived from the framework module. The migration of these two data schema. Yeh and C. AP214 provides robust data models for product data representation. while JPDM focuses on data models for implementation of the PDMS functionality. The proposed PDM data schema is not intended to standardize the implementation of the data schema residing in each PDMS. assemblies. The engineering change module is another significant factor for PDMS application in enterprises. document. The foundation module in JPDM defines the essential class that controls the data management for subsequent PDMS classes. project management. to enforce appropriate constraints. Moreover. the view module in JPDM provides a framework and explicit classes. controls the data vault and version control of documents. That is. revisionable. . including the management of product structure. and product structure definition modules can be applied to enhance the capability of those in AP214. Dependency of the UoFs defined in JPDM. Similarly. framework relationship. effectivity. Migration of these PDM data schema Migrating these data schema provides a standardized PDM data schema. documents. it includes issue collection. configuration management. Table 3 illustrates a comparison between the data models defined in AP214 and the functionality of PDMS. which is discussed in section 3. workflow/process management. configuration. Six basic foundation classes (manageable. or suppliers. as well as the implementation and changes to products. Varying applications and situations require additional models and modifications. The baseline module in JPDM is the definition of items and their relationships that were established to reconstruct and audit their configurations.-F. components. in specific contexts. it supports companies’ requests. Rather. requesting change. The framework. Finally. With the qualification mechanism. The classification. 3. specific business or implementation rules can be added to the baseline. users can access the context qualified by the specific view. You Figure 2. manufactured or purchased parts.4 S. effectivity. and notification of change. responsibility. lockable. processes. implementing change. the proposal is a suggested conceptual data schema for each module. which indicate applicable items and relationships.-C. Furthermore. stateable and classifiable) have been defined from that which the PDMS objects will inherit. ensures product data exchange and fulfils the PDM functionality requirement. and STEP module. The document module. which fulfils the functionality of PDMS.

and a list of the components required to assemble the part. the essential data models were organized (figure 4) via Unified Modelling Language (UML) (Booch et al.STEP-based data schema Since the PDM data schema adheres to the PDMrelated one defined in STEP. which is based on basic models. 1997). part. Figure 3 presents the product data exchange via standardized and traditional PDMS data schema. Configuration Management (CM) is the process of defining and controlling a product structure and its related documentation. processes. technical document. and design variation. Product structure management 3. links between suppliers and parts. such as Bills Of Material (BOM). instance and location information (McKay et al. revision. data models facilitate the management of product definition and structure. data models represent the product structure as well as the enterprise that is selling the product (Digital Equipment Corporation et al. sub-assembly. . as well as CAD model references. effectivity. and the standardized data models that are defined in AP214 and JPDM. this module defines parts and the bill of material relationships between items for the 5 whole life cycle of the product data. and related parts revision. via usage models. 1996). Therefore. These distinct components of the product definition are known as product data objects. ‘Revision’. and tooling. and other design information to be Figure 3. such as material. 3. Migration of the data models. A product definition may consist of engineering attributes. the substitute and BOM definitions can be attained. typical product structures contain attribute. assembly. alternative part. 1998). 1997) thus defining the distinguishing features or specifications and rules used to select specific components based on these features. CM includes maintaining revisions and history information of all changes to a document or product (CIMdata Inc. This. are generated with the related member function of the data models. A product/item may represent one of a variety of physical entities. which is based on the PDMS requirement. As products change over time due to engineering change. Within configuration management. Configuration management and part classification Within product structure management. which is the most complicated task of system integration. the PDMS tracks the version.1. As the kernel of the PDMS data schema. which is a combined pair of part masters. Figure 5 shows the migrated data models for product structure management. The migrated data models define the association relationship of the part master. reduces the mapping effort. is defined and then extended to accomplish the product structure. is discussed in subsequent sections. ‘Parts classification’ allows similar or standard parts. data exchange and sharing can be implemented easily. Comparison of product data exchange using traditional and standardization data schema of PDMS. Part 21 files. in turn. optional part.2. as illustrated in figure 5. To define the required and common data structure for PDMS data items. without mapping. The STEP exchange files. In addition to standard BOM data. ‘Exporter’ defines the view and group of classes of the data schema for product data exchange.

Migrated core data models for product structure management representation.-C. You Figure 4. Figure 5.6 S.-F. . Migrated core data models for item representation. Yeh and C.

It then creates a new file. to store the version and iteration information of documents. and controls document versions. to accomplish data vaulting. Workflow and project management The data models of workflow management define the process specification and its relationships among the items produced. Furthermore. its manufacturing location and its engineering change order. which is based on the requirement and the standardized data models defined in AP214 and JPDM. document definition revises.3. which are. Migrated core data models for configuration management representation. Document management ‘Document management’ provides the data models required to manage product-related documents. the document iteration is applied to make a copy of the original document. Figure 7 illustrates the migrated data models for document management. as shown in figure 6.4. Combined with part masters. Finally. which is defined by function. iterates. associates it with the Document 7 Iteration. fewer redesigns and accurate inventories. To perform a check-in. The process plan models defined in AP214 are applied as Figure 6. Figure 6 illustrates the migrated data models. Finally. this facilitates a more efficient mechanism for parts location. Notably. revisions and iteration. 3. the data models define the document’s item master. specification and item solution. process operations.STEP-based data schema grouped by common attributes. The configuration information of a part includes product class. . the relationship between document revision and part revision is linked. the dated lot number and serial number configuration are employed to define the configuration information. To provide an added level of planning and tracking. Project management provides a breakdown structures and allows resource scheduling and projects tracking. Processes employed in a business are varied and modified over time (figures 8 and 9). and properties of processes. and transfers the contents from the client to the PDM server. based on the requirement and the standardized data models defined in AP214 and JPDM. resources and managed data are linked. This can then be used to determine the effectivity of the item. version tracking process plans. 3. They represent process plans. in turn. Inherited from item definition. the file is unlocked.

Yeh and C. Migrated core data models for document management representation.8 S. Figure 8.-C. Migrated core data models for workflow management representation.-F. You Figure 7. .

and to provide management reporting. engineering change request (ECR). The deliverable items are referred to as ECO deliverables. serial numbers or lot numbers.6. ECO represents a directive to implement an approved ECR. problem tracking and resolution. engineering change order (ECO). The engineering change data models in PDMS support the management of engineering change information. other workflows exist for design release management. they are considered as a parent–child relationship within the . engineering changes occur frequently. In addition. vendors. the ECN provides information regarding the effectivity of the ECO. as shown in figure 10. The most practical strategy for maintaining this information currently is to complete the corresponding tables. Migrated core data models for project management representation. ‘Change control’ is a common workflow in most business. prior to ECO completion. the basis of the models. a work item. such as other engineering change items. Repetitive workflow and processes can be employed in a PDMS to route data and packages automatically. Items within said tables include engineering change issue (ECI). 3. This represents a single-order action item of a change or task to be complete. However. as well as to control and monitor processes. ECN represents a notification to manufacturers. migrated data models focus on the static data storage. purchasing. Effectivity management The data models of effectivity management define an indicator within a product structure that specifies the versions of the component part applied (CIMdata Inc. marketing. Engineering change management In an enterprise. distributor. Normally.STEP-based data schema 9 Figure 9. and contract management. Notably.5. and may result in one or more ECRs. or customer. rather than dynamic process information. An ECR is created after one or more ECIs are evaluated and deemed to be necessary technically. and it describes the implemented change of a single ECO. manufacturer. that is. Generally. ECR represents a request for engineering change. and engineering change notice (ECN) (figure 10). The issue may derive from various sources. the field. which normally addresses one or more ECIs. 3. engineering reviews. or other entities. these indicators specify a range of dates. 1997). ECI represents an identified and collected engineering issue.

manufacturing will then use subsequent information. An effectivity range can be expressed through dates.10 S. This specifies a range in which an item revision. .-F. such as the availability of parts. Migrated core data models for change management representation. or through lot numbers for the products product structure. component. to determine its validity. through the serial number. You specifies a planned effectivity. Migrated core data models for effectivity management representation. or other qualified item should be applied in production. thus. Typically. The corresponding models define the qualification and context models from the Views model of figure 11. Figure 11. engineering Figure 10. Yeh and C.-C.

To implement a tool-independent and functional STEPbased PDMS. Implementing the migrated models into the conceptual layer Enterprise modelling is important in the integration of information systems that are applied in current enterprises. wherein it determines the range in which the revision can be conducted. The communication barrier between these two layers can be reduced. The C++ models. The view context specifies a particular constraint. 4. Migrated core data models for view management representation. is a new trend in object-oriented modelling languages. such as Standard Data Access Interface (SDAI) protocol. or purpose. OMT. these two techniques perform data modelling identically. it can generate multi-language codes. which combines Booch. conditions. develop the three-tiered layers of the STEP-based 11 system. The object-oriented modelling techniques applied here are EXPRESS and UML language. in the conceptual layer and Object-oriented DataBase Management System (ODBMS) in the physical layer. First. the wide-ranged standardized information model. robust and flexible data models are required. STEP is an international standard that can reduce the incompatibility in product data exchange and sharing. Since they are designed for information modelling. which ensures system integration. To capture the information within the enterprise. Secondly. in which case it ascertains that the component used is in that range. The ensuing section proposes an implementation approach for the data models in section 3. it may be applied to a part structure usage relationship. derived from EXPRESS data modelling. effectivity may be applied to any qualified item. A qualification is determined based on the purpose or a set of constraints. The migrated data models applied in the previous section demonstrate the UML notation. .1.STEP-based data schema being manufactured. such as Rational Rose. Furthermore. aids the capture of complex PDMS information models. the migrated data models were developed here (section 3). are identical to those in section 3. the reusability of models can also reduce the development cycle and provide the extensibility for future development. Figure 12. EXPRESS. with some Computer Aided Software Engineering (CASE) tools. the object-oriented modelling language. and CASE. As with other qualifications. Finally. UML. The migrated View models (figure 12) provide a framework and explicit classes to indicate that items and relationships apply or qualify in particular contexts. The enabling technology. 4. UML notation is employed in the majority of engineer software and. such as part revision. and multi-language biding ability. Implementation of the proposed data schema The benefits of applying the STEP standard to establish PDMS can be summarized by three factors.

To construct the physical layer of the system. The benefits of object-oriented modelling language include robustness.12 S. However. it promotes the development of a STEP-based system. or EXPRESS models management system. EXPRESS is employed to establish a STEP-based system. which designs the conceptual models. or a virtually shared database Prior to the release of EXPRESS language version 2. You 4. such as PDM and CAD/CAM systems. Notably. as shown in figure 13. flexibility. . which enhances the behaviours and process definition of version 1. extensibility. Implementing the physical layer of PDMS Figure 13 reveals that the physical layer contains the construction of kernel database and network communication media. UML notation and C++ language was employed to implement the proposed data models (Spiby and Sanderson 1998). Currently. three issues arise.-F. the generated C++ codes are applied to develop the applications in the presentation layer. Proposed approach for constructing an application layer and a physical layer from a conceptual layer. data models will attach themselves to the development of a STEPbased system firmly.2. ODBC can then integrate legacy data into the ODBMS of our system. Notably. via employing an ODBC driver of ODBMS. this is the method used by most STEP-based system developers. are placed into the UML modelling tool. proposed in section 2. Yeh and C. By capturing the schema of legacy data and placing these new models into a STEPbased system. ODBMS. the conceptual data models are translated to the Relational DataBase Management System (RDBMS). To generate programmable C++ codes and an object-oriented database (POET). whereas the latter is suitable for large quantities of data. due to its representation of complex information models when developing the STEP-based system. the physical layer of STEP-based PDMS should be equipped with a data exchange method. the migrated data models. directness and reusability. The first issue is the integration of legacy data (Bernosky 1997). an external shared database method. Figure 13. while an object-oriented database is ready for use. The former is suitable for complex data. For compatibility with relational databases and to ensure the effectivity of data retrieval.-C. To ensure product data exchange and sharing. Open DataBase Connectivity (ODBC) is a popular solution for this issue. With this methodology. When RDBMS is adopted as the kernel of the STEPbased system. the data resided therein can also be shared by RDBMS. In addition. Via the support of an object-oriented programming language. the ODBMS provides a strong mechanism. changes to the conceptual models reflect directly on the presentation and physical layers to ensure the consistency of the data models. The bold lines in figure 13 indicate the solution applied here to develop the STEP-based system. Since the object-oriented conceptual data models in the conceptual layer affect the construction of the database. and then constructs the application layer via object-oriented and EXPRESS-C languages. Conversely. RDBMS is included after object-oriented modelling. The choice of either ODBMS or RDBMS is based on the complexity of the information to be stored.

Ke and Yeh 1998). including the migrated data models of section 2. The latter focuses on the establishment of a network communication interface. Thus. 4. Figure 14 illustrates the approach for constructing a STEP-based distributed database management system. the shared database environment can then be achieved (Spooner 1994. The most popular approach to address the PDMS server side is via TCP/IP protocol. 1993. generate parser codes.3. 1997). This can then be employed to construct the database. 1995) in plain text. However. popular database preprocessor tools resolve this shortcoming. which produce a flexible data structure and instances in database. Gradually. database communication. The external shared database method is a method designed to access a common database between companies on a contract basis. Essentially. The data exchange method enables product data within a PDMS to be extracted and exchanged with physical files (An et al. Figure 15 presents three mechanisms of network communication with their operation methods. although the data shared are distributed physically. These three are associated with an ODBMS that is recommended for STEP-based PDMS. the virtually shared database may be the ultimate in product data sharing. the former adopts distinct requirements from varying enterprises. In this method. Application layer The primary issue with the application layer is to connect the physical layer application to those of the conceptual layer. Finally. This method facilitates setting specifications and conducting tests. to accomplish distributed PDMS. Furthermore. which include flexible modelling and better communications interface. To integrate all information systems within an enterprise.STEP-based data schema method. Database communication relies on the ODBMS. It recommends changes to conceptual models. The latter are compiled by ODBMS to append the management functions into original C++ codes. Tanaka et al. The left-hand side indicates the generation of internal representation of EXPRESS codes. and CORBA/ COM. data within a PDMS can also be extracted as Part 21 files. PDMS Figure 14. and is applicable to various systems. a STEP-based PDMS has two main attributes in this layer. and implementable C++ codes. so that prototyping applications can be developed rapidly and then be connected to target the database easily. includ- 13 ing ODBC. it appears to the user as if the distributed PDMS were virtually one. Similarly. Within the virtually shared database method is a method through which the product data distributed among the PDMS of companies can be accessed concurrently for sharing (Urban et al. The application layer. the CORBA/COM mechanism permits the distributed objects to communicate with each other. 1994. With the ODBC driver provided by ODBMS. the schema dictionary and its related codes are generated and managed by ODBMS. or presentation layer. . In this method. which is intended to create a concurrent working environment. one solution is the implementation of a STEP-based system via ARM and AIM (Rahimifard and Newman 1996). ODBC provides the link to these systems. data are copied from the PDMS into the common database and then shared. is accomplished by referencing models within the conceptual layer to adopt various requirements. Proposed approach for constructing STEP-based distributed database management system. Notably. The effectivity of data management and compatibility with STEP are always in opposition.

the STEP database. The process was repeated until the final design was approved and the manufacturing and ordering information was readied for production. Industry A translated the engineering data and CAD models of a product via a STEP-based interface and then forwarded them to industry B. Since the STEP-based system is an object-oriented system. it can be used effectively in productivity or practical utilization. A and B. which stores and shares the product data independent of the physical layer of the system.4. including OODBMS or the serialization mechanism of object-oriented language.14 S. product structure. The data models were translated and built into the Oracle databases of the repository system.-F. must manage and share information throughout the entire enterprise. Industry A had the entire repository system. such as CAD or PDMS. without either SDAI or AIM. configuration information. based on these databases. You Figure 15. including CAD models and related technical data. 1994. Through the STEP-based exchanger application. and definition of the migrated data models. Via the HLDAI parts generated. 4. Rather than SDAI or HLDAI to develop STEP-based PDMS and manage the corresponding information. Botting and Godwin 1995). each application had a corresponding conceptual data model. the databases incorporated the data structure. drawings. the object-oriented management mechanism. A STEP data exchange system is constructed according to APM. which is a user-friendly interface with an application view. these two industries collaborated to enable product data co-design. Yeh and C. Industry B evaluated the conceptual design or engineering change and then responded with designs or recommendations. the first-tiered supplier of industry A. Proposed approach for constructing network communication interface. and then transferred the information. Since SDAI operates via EXPRESS. STEP specifies SDAI. To ensure consistency. had merely a portion of the STEP-based data exchange. the communication interface is important for PDMS. or DCOM to achieve a distributed environment. PDMS managed documents. most communication interfaces rely on Java. Figure 16 illustrates the working process of the PDMS. thus. Finally. to industry B. It should be noted that the co-design between these two industries with different CAD and operation systems was the application scenario. the repository applications were developed. . CORBA. In industry A. Case study To verify our migrated data models. The new approach applied to manage STEP data is via a High Level Data Access Interface (HLDAI). a PDM system with the proposed data models in this paper was implemented and applied in two manufacturing industries.-C. was employed here. workflow. schema. classification. and engineering change. Based on the data models proposed here. while industry B. SDAI is an Application Programming Interface (API). which is a data structure definition of application. is accessible. which realizes an integrated system by sharing the AIM product data of applications such as a CAD system and PDMS (Goh et al. Industry A employed a conceptual design or engineering change case.

the urgent requirement of concurrent engineering is magnified by the requirement of product data exchange and sharing. Codes generating from proposed migrated data models of PDMS. Obviously. to generate STEP P21 files. it also resolves the mapping issue between ARM and AIM within product data exchange. this kind of system can be employed to meet the requirement of product data exchange and sharing. Therefore.STEP-based data schema 15 Figure 16. Discussion and conclusions Figure 18. Figure 17. The proposed models abstract the data models from AP214 and JPDM. these data schema were migrated. To standardize and thus fulfil the functionality of PDM. However. Figure 17 illustrates the product data . Working process of the applications of the repository system. 5. Three approaches for product data exchange and sharing in PDMS. The migrated data schema discussed in section 3 fulfils the run-time requirement of the practical functionality of PDMS.

FUJITSU LIMITED . S. 11 June. K. Computer Standards & Interfaces.. Concurrent Engineering: Research and Applications. K. 29. support by ProSTEP and PDES... LEEP. CZERWINSKI. 1998. P. Orlando. STRUCTURAL DYNAMICS RESERARCH CORP. 1997. 17. 13. Documentation Set 1. To accomplish thorough information exchange and sharing between departments.. Figure 18 illustrates PDMS implementation via the migrated data models.0. and WANG. Computer-Aided Design. F. applicable product data models are required. J. A product data exchange integrated structure using PDES/ STEP for automated manufacturing application. PARSAEI. provides essential data integration for configuration management information.0. The pilot system for STEP-based product data exchange. A. V. CHAXEL. Proceedings of CALS/EC EXPO Japan. integrated. INTERNATIONAL BUSINESS MACHINES CORPORATION .. METAPHASE TECHNOLOGY DIVISION . The International Journal of Advanced Manufacturing Technology. ISO SC4/WG10 Document N58.. 1997. 16. With UML modelling tools. A study of SDAI implementation on object-oriented databases. 1998. 1998. and RICHARD. and HSIAO.. ISO 10303: Product data representation and exchange – Part 42: Integrated generic resource: Geometric and topological representation. Mobile databases nodes for manufacturing information management: a STEP based approach. Product Data Management Enablers Proposal.. B. Turning legacy data into enterprise information.. 12 April... Product Data Management Enablers Proposal. 2.-F.0. Product Data Management: The Definition (USA: CIMdata Inc.. 5. 1994. S. HUI. 1994. Research in Engineering Design. Computers Industry Engineering. Revision 1. S. and YEH. YATABE. 1994. C. You DIGITAL EQUIPMENT CORPORATION . 63–80. STRUCTURAL DYNAMICS RESERARCH CORP. 9. 12–16. and SIVAYOGANATHAN . R. I.. and GODWIN.. Florida. and SHERPA CORPORATION . ISO 10303: Product data representation and exchange – Part 43: Integrated generic resource: Representation structures. R. Revision 1. 26. S. 33–43. ISO 10303: Product data representation and exchange – Part 41: Integrated generic resource: Fundamentals of product description and support. Yeh and C. P. BOOCH. 197–206. and CHAN. which in turn promotes concurrent engineering and systems integration. and RUMBAUGH. Tokyo. 711–715. and KARINTHI. TANAKA.16 S. Development of CIM applications from PDES/STEP information models. and NYALUKE. 1994. The PDM schema. MASEGAWA. 1995. the proposed data models can accomplish this requirement. R. 446–469.). 1998. 14 April. exchange and sharing of the proposed standardized data schema.. REDDY. GOH ..1.0.. Product Data Management Enablers Proposal. L.. ISO. Proceedings of 21st Century Commerce & CALS EXPO International Conference. PROSTEP and PDES. J.. SPIBY. DIGITAL EQUIPMENT CORPORATION . ISO. 1995. Proceedings of CALS EXPO International. Introduction to EXPRESS 2. K. M.. References AN.. JACOBSON. INC. Version 1. 1994. ISO. M. T. G. S. N. S. INC. FUJITSU LIMITED.. JAGANNATHAN. and NEWMAN .. to ensure this. Product Data Management Enablers Joint Proposal.. ISO. 1997. 1995. BAJIC. 1994. 1994.. FUJITSU LIMITED. and BLOOR. 1997. 1994. the data consistency of PDMS plays a significant role. The Unified Modeling Language. Product data sharing among distributed heterogeneous PDMs. Notably. within an enterprise and between enterprises. 1994. METAPHASE TECHNOLOGY DIVISION . P. the working form of the proposed data models can be generated... 1996. 61–72. 1997.. K. H. Y. S. and OBETA. ISO 10303-214 CDII – Core Data for Automotive Mechanical Design Processes. ISO. A. H. INC. N. A STEP-based PDM-related data schema was proposed to fulfil the functionality requirement and ensure the product data exchange and sharing. October 1997. D. R. Y.... The selection of the programming language depends on PDMS developers. 1997. INTERNATIONAL BUSINESS MACHINES CORPORATION . Unified PDM Schema. Revision 1... 1993. K. ERENS. Relating product definition and product variety. and SHERPA CORPORATION .. 125–133. 2. INC.. 437–455. GU. Product modeling using STEP. Y. SPOONER. 1997. A. .. RAHIMIFARD . ISO 10303: Product data representation and exchange – Part 44: Integrated generic resource: Product structure configuration. Computer support for concurrent engineering.. 1997... 13–21. Y. R. E. 14 April. 15 April. L. 1997. SHERPA CORPORATION . 1997.. MCKAY. F. 1994. 1997. Y.. SRINIVAS.. A collaborative data management framework for concurrent product and process development. ISO.4. 1997. Version 1. 163–179. BOTTING. Revision 1. D. CHEN . CIMDATA INC. Computer Standards & Interfaces. MATRIX ONE. ISO 10303: Product data representation and exchange – Part 203: Application protocol: Configuration controlled design. Journal of Intelligent Manufacturing. However. Product Data Management Enablers Proposal. standardized. November 1997. 1997. Analysis of the STEP standard data access interface using formal methods. 2 February. 14 April.T. An object-oriented product database using ROSE.-C... A.. Product Data Management Enablers Proposal. S. Tokyo. SONG .1 (Rational). 133–136. pp. Computer. International Journal of Computer Integrated Manufacturing System. 1994. A.. C. MATRIX ONE. Inc. KE. K. 1994. and SANDERSON. November 1998. International Journal of Computer Integrated Manufacturing System.. such as Rational Rose. 10. BERNOSKY. 27. METAPHASE TECHNOLOGY . A methodology to develop EXPRESS data models. DASSAULT SYSTEMES. 1996.. D. F.. 1994.

SHAN . D. 179–187.. LIU. M. P. SHAN.STEP-based data schema URBAN. K. RAVI. ROGERS . Computing & Control Engineering Journal. J..K. and FISCHER. M. International Journal of Computer Integrated Manufacturing System. 1992. JEON.. active database architecture for engineering data management. 7. 1993.... . J. P.... and ROGERS. 119– 126. J. 17 WU. S. T. G. T. The Second International Conference on Automation Technology. H. An integrated PDES/STEP based information model for CAE and CAM applications. D. 1994. J. and BLIZNAKOV.. URBAN. 2. W.. S. J. 276–293. D. A heterogeneous. Engineering data management archieving integration through database technology.. 4.