Int J Adv Manuf Technol (2011) 55:11491158 DOI 10.

1007/s00170-010-3130-4

ORIGINAL ARTICLE

Product data model for PLM system

Yumei Li & Li Wan & Tifan Xiong

Received: 20 January 2010 / Accepted: 29 December 2010 / Published online: 20 January 2011 # Springer-Verlag London Limited 2011

Abstract Product lifecycle management (PLM) is a new business strategy for enterprises product R&D. A PLM system holds and maintaining the integrity of the product data produced throughout its entire lifecycle. There is, therefore, a need to build a safe and effective product data model to support PLM system. The paper proposes a domain-based product data model for PLM. The domain modeling method is introduced, including the domain concept and its defining standard along the product evolution process. The product data model in every domain is explained, and the mapping rules among these models are discussed. Mapped successively among these models, product data can be successfully realized the dynamic evolution and the historical traceability in PLM system. Keywords Data model . Domain . Data mapping . Data traceability . PLM

1 Introduction With the emergence of the network firm and the network economy, product lifecycle management (PLM) has become a new business strategy for global manufacturing. As a management paradigm, PLM support entails the modeling, capturing, manipulating, exchanging, and using of information in all product lifecycle decision-making processes, across all application domains [1]. PLM emphasizes the collaborative product data driven by the processes
Y. Li (*) : L. Wan : T. Xiong National CAD Support Software Engineering Research Center, Huazhong University of Science and Technology, Wuhan 430074, China e-mail: liyumei0823@hotmail.com

collaboration. These data are an important basis of PLM, which is generated from all phases of a product's lifecycle, and engineers/managers/technicians inside an organization, as well as suppliers and customers [2]. In the context of PLM, product evolution is a phased and hierarchical running mode, which is across multidimensional coordination. Product data in PLM have various formats, such as figures, reports, tables, files, and data sets. With the evolution of product, product data are changing and evolutional in their structures and attributes. Data modeling is a key concern in PLM. Product data model should be constructed to describe, categorize, analyze, store, trace, and transit all product data in PLM. For different users in PLM system, they have not the same rights to visit the product data. So, creating a safe and effective data model to support PLM is a major challenge for implementing PLM system in a company. In order to ensure to send the right data to the right person in the right time, product data model should have integrality, consistency, safety, diversity, share, activity, traceability, and other characteristics. To address this issue, this paper emphasizes the importance of defining, managing safe data, and exploiting their relationships between different product data representations. The goal is to manage effectively and reuse the dynamic data generated from product lifecycle. The paper proposes a PPOD (product parameters-oriented domain) data modeling method to manage these data in product lifecycle. It relies on feature domain modeling and the proven mapping rules between product data. As a closed space, domain is a safe and effective data carrier, and achieves the right mapping between product data by its intelligent interface. The body of this paper is organized as follows: It begins with a short review on product data modeling in Section 2.

1150

Int J Adv Manuf Technol (2011) 55:11491158

Section 3 introduces the concept product data domain and defines many data domain along product lifecycle stage. Section 4 builds a domain-based data model. In this section, the product data information embodied in every data domain is exploited. In section 5, the evolution of product data in its lifecycle is described in detail, including the data dynamic evolution and historical data trace. Section 6 presents an illustrative example of this modeling approach for PLM system, and the last section summarizes the key elements.

tive components. The purpose of the approach is for design reuse in engineering-to-order products. Chen and Jin [9] proposed a product information model-based product multidisciplinary for collaborative design, integrating physical structure, design semantic, and collaboration management data. However, the above product data models based different modeling methods are deficient in describing and managing all data information throughout product lifecycle. Their disadvantages and limitations are summarized as follows: (1) They only consider product data, but do not pay attention to the resources information related to product in product evolution process. The resources information is important in PLM environment, which needs to be managed. (2) They only manage static product data, but do not consider dynamic product data information throughout the product evolution chain. (3) Product lifecycle unified model tries to express all product information through the whole lifecycle by using a single model. However, product unified model proposed may be static model, which does not describe dynamic data and process information. Or, it is dynamic and multi-dimension, but it can't be implemented for their complex structures. (4) They only guarantee single product data source, but they have deficiency of managing data integrity, security, and traceability. Domain engineering is known as software product line engineering, which aims at identifying, modeling, constructing, cataloging, and disseminating the commonality and variability allowed among applications in a specific domain [10, 11]. The domain model has been used as an effective tool to develop quality software in recent years. Now several domain modeling for software product line have been proposed over the years, (e.g., [1216]). There are different descriptions, definitions, and applications in these previous domain models, but they have the same goal to describe requirements, problems, capabilities, and solutions in software product families. They focused on reuse, validation, and knowledge representation [17]. In these proposed methods, featuring modeling has been considered a popular method for modeling software variability. However, domain modeling method has been researched for software product family, few used in modern mechanical and electrical product data modeling. In this paper, we are concerned about the data modeling method for modern mechanical and electrical product, and propose PPOD data modeling method. It is a composite modeling method which combines feature domain modeling with the product data modeling based on variability. PPOD modeling method overcomes the deficiencies of the

2 Related work In this section, several types of common product data modeling methods and domain modeling method will be reviewed. We begin by discussing product data modeling approaches proposed by the researchers. Then we summarize the shortcomings of these modeling methods to support PLM systems. Thereafter, we discuss the domain modeling application in software product lines. Finally, we describe the advantages of domain model and propose to build modern industrial product model throughout its whole lifecycle by combining domain modeling with product data modeling. Product data modeling techniques includes geometric solid modeling, product features modeling, integrated product information modeling, unified data modeling and other methods. Now, lots of research results and related literatures have been reported and published. Bellatreche et al. [3] presented the ontology-based data integration modeling approach. It ensures the automation of the integration process when all sources reference a shared ontology, and possibly extends it by adding their concept specializations. Peng and Trappey [4] constructed six Standard for the Exchange of Product (STEP)-compatible data models to demonstrate the integration of product structure data and engineering changes in an iterative design process using common STEP data modeling format. Giannini et al. [5] illustrated a product-modeling tool named Product Manager to support networks of small and medium enterprises collaborating in the design of a unique final product. Zhang et al. [6] presented a feature-hierarchy product-modeling method based on assembly unit, which supports the data consistency in product design process. Ghang et al. [7] described a data modeling case based on the Georgia Tech Process to Product Modeling.The method was initially developed in response to the need to integrate multiple use-cases with differing data definitions from different companies. Brire-Ct [8] described the adaptive generic product structure modeling, a dynamic structurebased product family modeling approach that enables the systematic aggregation of product variant and their distinc-

Int J Adv Manuf Technol (2011) 55:11491158

1151

traditional product data modeling methods in the above four points by using domain analysis features. In addition, PPOD modeling method can better support PLM system than other data modeling methods, because it can guarantee product data evolution and traceability throughout the lifecycle. A core in this method is to construct several data domains and manage product lifecycle data information through these data domains and the mappings between them.

3 Data domain definition and representation 3.1 Data domain representation Product development and evolution is divided into a multistage, multi-layer, and cross-tridimensional running mode in all product lifecycles. At the same time, these product stage data models can be integrated seamless by the data domain. Definition 1 Data domain is a closed unit management entity, which encapsulates the tools, data, models, methods, and other resource objects in a knowledge domain or a lifecycle stage, in order to manage and share varied heterogeneous data during collaborative product development processes. Data domain is described using the following formula: D P DM R II Here, P refers to the persons who visit data domain, and their operations in the data domain are limited and bound by R. R is a rule set, including data access control rules, the defining rules of data structure relationship, metadata mapping rules, and other rules. In this work, R is determined to control product data stage model in a data domain. II is the abbreviation for intelligent interface, and expresses the intelligent agent between the data domain and others, in order to achieve various resources sharing during product development. DM is denoted as the product data model in a data domain and is the core object of a data domain. DM is an information set including product data, product metadata, processes information, data domain environment information. Here, product data refers to the
Fig. 1 Data model in data domain and their mapping-based collaborative process

product complete information in a dynamic change period, which has complete product structure, product attributes, and lifecycle status. Process information describes the process data related to product data change and evolution in some product lifecycle stage. Environment information is the domain-specific product-related resource information. Although DM has different content in different data domain, it can be described and expressed by product structure tree and product attributes set in a right way in every data domain. Every data domain only seals a data model corresponding to some product lifecycle stage. However the data models in data domains are not alone in these data domains, they are relatively independent of each other, and they can establish mapping, achieve data resources sharing through the intelligent interface of data domain, as shown in Fig. 1. The associated domains not only express and manage effectively all product-related information, but also ensure a single product data source and source. As can be seen from Fig. 1, the mapping between data domains is achieved through the collaborative process. 3.2 Data domain definition in product lifecycle In theory, in order to accurately describe and manage product data and process information, numerous data domains can be established along the product evolution lifecycles. However, in practice, taking into account the granularity of the data management and the difficulty on their implementation, the number of data domains is limited. Thus, in the early stages of the data domain definition, these two concepts, data domain breadth and data domain depth, are mentioned as: Definition 2 Data domain breadth refers to the horizontal expansion extent of data domain on the product lifecycle stages. The optimal number of data domains can be defined along product lifecycle stages, according to product data grain size managed by engineers. Definition 3 Data domain depth refers to the vertical expansion extent of data domain-level division. Facilitating to control the operation access of the data information in data domain, a data domain can be divided into multiple sub-domains.
mapping Collaborative process

Data Domain A Data Model A

Data Domain B Data Model B

Product structure domain model B1 Product properties domain model B2

Product structure domain model A1

Product properties domain model A2

mapping

1152

Int J Adv Manuf Technol (2011) 55:11491158

Generally speaking, modern complex mechanical and electrical product starts with collecting and analyzing customer demands and market analysis, and ends with product recycle and disposal. Therefore, the paper defines many basic data domains along product evolution lifecycles, such as concept design domain, structure design domain, detailed design domain, process planning domain, manufacturing domain, sales and service domain, as shown in Fig. 2. The data models contain different product data content and controlling rules in different data domain. However, all the data domains are established in accordance with the uniform definition standards, following product development process. Figure 2 shows that these domains have similar definition method and the package has similar content type, including data model, data operators, intelligent interface, and rules. Therefore, here, we only introduce the definition of the detailed design domain as an example. It can be described as: Definition 4 Detailed design domain is a unit domain with rules and intelligent interface, which includes all resource objects in product detailed design stage, such as design tools, designers, product data model, parts data models, the structures information and attributes of product parts, and the association between these objects.

4 Product data model in data domain With product development evolution, product data will change in numbers and types. There are different product data models in different data domain. In the section, we introduce the basic content of product data model in every data domain and product data model structure tree. 4.1 Product data model information in data domain Figure 3 shows the product data model information in every data domain built in the previous Section 3. In support of
Fig. 2 A few basic data domains in product lifecycle

the collaborative processes, these product data models establish their mapping links by the intelligent interfaces, and the product lifecycle data model is formed in PLM environment. These specific data models are described as follows: The data model packaged in the concept design domain is product function data model [18]. It mainly shows that product should meet the functions and the capabilities to achieve the physical and chemical principles, methods, and role of the product functions, including function hierarchy delineation and function information definition. Function layer is a tree structure, which can be divided into multilayers, including function layer, sub-function layer, and basic function layer. The basic function is no longer a breakdown. The final leaf node is the basic function, which is not only the key to build product function data model, but also the importance to pass product function information to downstream data domain. Structure design domain is the successor of concept design. The data model in structure design domain reflects the specific results of product concept design, namely, each basic entity function in product. Therefore, the data model packaged in structure design domain is product assembly structure model, which includes the structure and function characteristic information, product structure layers information, the overall assembly constraint information and attribute characteristics information. Detailed design domain has the role of nexus, which the key to pass data information between the upstream domains and middle and lower domains. The upstream domains are concept design domain, structure design domain, and the middle and lower domains include process planning domain, manufacturing domain, and sales and service domain. The data model which is packaged in detailed design domain is parts data model, including product part function information, product part characteristics information, and its attributes information. Process planning domain and manufacturing domain package the data models for product manufacturing. The

Product

Concept design domain

Data model Data operators Interface Intelligent Rules

Structural design domain

Data model Data operators Interface Intelligent Rules

Detailed design domain

Data model Data operators Interface Intelligent Rules

Process planning domain

Manufacturing domain

Sales & Service domain

Data model Data operators Interface Intelligent Rules

Data model Data operators Interface Intelligent Rules

Data model Data operators Interface Intelligent Rules

Concept design Structural design Detailed design Process planning Manufacturing

Sales&Service

Product lifecycle

Int J Adv Manuf Technol (2011) 55:11491158

Basic functions definition Sub function division Function feature carrier Function feature set Structure characteristics Function characteristics Assembly entity Assembly relation tree
Assembly information Constraint characteristics informatattribute ion information

1153

Function-level division

Function information definition

Structure and function characteristics

Assembly structure hierarchy

Property information set

Product function model

mapping collaborative

Product structure model

Concept design domain

process mapping

Structure design domain

collaborative

mapping

Product data model

Components data model Part data model

Detailed design domain

mapping mapping mapping Customer information
Customer demand information Constraint Function Assembly Attribute information information information information Characteristics Parameters Attribute information information information

collaborative

Manufacturing methods

Product process planning model

Product data model
Craft Parts Craft parts assembly pats assembly sequences information relation

Process planning domain

collaborative mapping mapping process process

Final Parts Assembly manufacturing manufacturing producturing methods methods methods

Process information

Manufacturing domain
collaborative mapping

Parts Component Fixture Processing Parts Working Production processing assembling tools type equipment CAPP hours process aids operations

Product manufacturing model Sales & Service domain

Manufacturing Information model Product data model
Production Production Processing Manufacture Manufacture outline plan equipment resource workshop

Product Sales & Service model

Parts Parts Craft Parts Parts materials geometric pats batch number information information information

Product data model

Sales plan

Sales information

Accessories sales information

process

mapping

process

Customer service information

Fig. 3 Product data model in every data domain

data model in process planning domain is parts data model and product process data model. Here, parts data model describes the parts assembly sequence, craft parts definition, and the assembly relations between them. Process data model includes craft parts information and parts manufacturing methods. The data model in manufacturing domain

mainly describes the manufacturing information of parts, such as parts materials information, geometrical characteristics, processing equipments, parts batch, and parts numbers. The model packaged in sales and service domain is product service model, which is built by product sales plan

1154

Int J Adv Manuf Technol (2011) 55:11491158

and customer demands. The service model mainly records final product sales, part sales, as well as user service information. 4.2 Product data model structure tree and attributes set In this paper, product data model information is expressed by model structure tree, as shown in Fig. 3. The model structure tree can be described by product structure tree and feature attributes set. Figure 4 shows a product structure tree. It expresses a product assembly structure relationship. Product structure tree consists of nodes and connection lines. Nodes di (i=1, 2... n) represent product, components, and parts. Here, tree root node represents a product, tree lower nodes represent components and sub-components, and tree leaf nodes represent final parts. Connection lines between nodes represent the constraint relationships of product assembly structure. In the paper, these nodes di can be defined by data objects, and these connection lines can be defined relationship objects. The functionality and performance of a part is determined by its feature attributes. Product feature attribute set can describe completely product data information in a data domain. For a part in a product structure tree, there is a feature attributes set U fui ji 1; N g. Here, ui is the feature attribute of a part, N is the number of the part feature attributes.

In product dynamic evolution process, product data objects will bring the qualitative change and quantitative change, that is, the change in product data structure and its attributes. So, the mapping of product data models between data domains contains the mapping of product data structure tree and the mapping of product feature attributes. 5.1 The mapping of product data structure As mentioned earlier in the paper, product data structure tree describes the product structure organized by a series of part and components according to special assembling relationships. The structure tree consists of nodes and connection lines. Therefore, the mapping of product data structure tree includes the mapping of product data objects and the mapping of relationship objects. In Section 4.2, d and r are supposed to represent respectively data object and relationship object. Here d1, d2, r1, and r2 represent respectively the corresponding data object and relationship object in data domain 1 and data domain 2. m is supposed to represent the mapping object between data domain 1 and data domain 2. There are four types of mapping relationships between d1 and d2, and between r1 and r2: 11, 10, 01, and 00. Here 1 represents the object lies in the data domain, o represents the data domain does not contain the object. There are several methods to describe the mapping relationship between data domains, such as STEP rules method, switch matrix method, and relationship function method. Since product data structure tree can be described easily by matrix method, their mapping relationship between data domains can be expressed by matrix. We assumed product data object di (i=1, 2 n), and relationship object rj (j=1, 2 m). Supposed p={n, m}, and in the structure tree, n=m+1, so p=n. We cited variable a1t, a2t, b1t, b2t to represent mapping coefficients. Here, t=1, 2n; a1t, a2t represents respectively the mapping coefficient of data object, the mapping coefficient of relationship object in data domain 1; b1t, b2t represent the corresponding mapping coefficient in data domain 2. The values of four variables are 0 or 1. If the value is 1, the data object or relationship object lies in the data domain; or it does not lie in the data domain. We use D1 to represent product data structure tree matrix in data domain 1, and D2 represents the corresponding matrix in data domain 2.  a11 d1 a12 d2 ::: a1n dn 1 0  a21 r1 a22 r2 ::: a2n rn 0 1  b d b d ::: b1n dn 1 0 D2 11 1 12 2 b21 r1 b22 r2 ::: b2n rn 0 1 

5 The mapping between product data models Product data models can establish the mapping contact by the intelligent interface of the data domain in the supporting of product collaborative development process. Product data information in all lifecycles can be share and transmitted each other through the data models mapping between data domains. The mapping has two main roles: (1) It achieves the dynamic evolution of product data information throughout product lifecycle. (2) By the mapping between product data models, product data is implemented positive predictive tracking and reverse historical data traceability.

D1

Fig. 4 The local diagram of product structure tree

Int J Adv Manuf Technol (2011) 55:11491158

1155

M12 is the mapping matrix from D1 to D2, and D1 M12 D2 . We can educe that M12 is a n 2 n 2matrix from D1 and D2. It is denoted as:
1 6 0 6 6 ::: 6 6 0 6 4 b11 a11 d1 b12 a12 r1 2 0 1 0 b12 a12 d2 b22 a22 r2 ::: ::: ::: ::: ::: 0 0 1 b1n a1n dn b2n a2n rn 0 0 0 1 0 3 0 07 7 7 7 07 7 05 1

M12

T1 describes the data crossing between matrix D1 and D2, and T2 describes the data combination between matrix D1 and D2. It is obvious that all combination matrixes represent product data structure in product lifecycles, and all crossing matrixes represent the smallest product sharing data in all data domains. 5.2 The mapping between product features attributes Product feature attributes are called product metadata objects, describe product data objects. For a data domain, product feature attributes are a complete description for all the product data objects in the data domain. However, from the perspective of object-oriented technology, product feature attributes are integrated by the data subset of product data models in every domain. So when the mapping of product data structure between data domains occurs, the mapping of product featuring attributes will begin. The mapping between product feature attributes includes attributes items mapping and attributes values mapping. As mentioned above in Section 4.2, a part feature attributes can be denoted as set U. We supposed U1, U2 to represent respectively a part feature attributes in data domain 1 and data domain 2. For every u1 U1, there is a rule f and the rule determines a single u2 U1, then rule f is called a mapping of feature attribute from data domain1 to data domain 2. According to the feature attributes sets, product feature attributes mapping types include genetic mapping, derivative mapping, reduced mapping, aggregation mapping, separation mapping, educed mapping, and domain distribution mapping. These mapping types are described as following: When genetic mapping occurs, the product feature attributes don't have any change after mapping. For example, those public attributes, such as material identification (ID), are the same in every data domain. If there is a derivative mapping, product feature attributes in target data domain will add new attributes based on the corresponding attributes in source data domain. However, reduced mapping is opposite from derivative mapping. Aggregation mapping is a complex mapping type. When it occurs, product feature attributes in the other data domains will be combined to form a new data attribute describing product data in the target data domain. Separation mapping is partly opposite for aggregation mapping. When it occurs, several product feature attributes in target data domain are from one product feature attribute in source data domain. Educed mapping is the mapping that the product feature attributes in the other data domains are calculated to form a new data attribute in the target data domain. Domain distribution mapping suggests that every data domain has its own unique data attributes according to the management needs for data domain.

In order to simplify M12, we made the following substitution: S u p p o s e d c11 b11 a11 , c12 b12 a12 , , c1n b1n a1n , then it is obvious that c1t ={1,0,1}, t=1, 2, , n; Supposed c21 b21 a21 , c22 b22 a22 , , c2n b2n a2n , then it is obvious that c2t ={1,0,1}, t=1, 2, , n. Here, c1t and c2t are called the mapping coefficients; 1 represents that the mapping of the object is from significant state to implicit state; 0 represents that the object state does not change after the mapping; 1 represents that the object state is from implicit state to significant state after the mapping. After the above replacement, M12 is simplified as: 3 2 1 0 ::: 0 0 0 6 0 1 ::: 0 0 07 7 6 7 6 ::: 7 6 M12 6 0 0 ::: 1 0 07 7 6 4 c11 d1 c12 d2 ::: c1n dn 1 0 5 c21 r1 c22 r2 ::: c2n rn 0 1 We further simplify matrix M12, and use matrix M12 to denote the mapping matrix:   0 c d c d ::: c1n dn 1 0 M12 11 1 12 2 c21 r1 c22 r2 ::: c2n rn 0 1 Similarly, we can educe matrix T1 and T2 by matrix D1 and D2, and the two matrixes represent respectively the crossing matrix of matrix D1 and D2, the combination matrix of matrix D1 and D2. They can be denoted as:   w11 d1 w12 d2 ::: w1n dn 1 0 T1 D1 \ D2  w21 r1 w22 r2 ::: w2n rn 0 1  v11 d1 v12 d2 ::: v1n dn 1 0 T2 D1 [ D2 v21 r1 v22 r2 ::: v2n rn 0 1 Here w1t b1t a1t ; when b1t =1 and a1t =1, w1t =1, otherwise, w1t =0, t=1, 2, n; w2t b2t a2t ; when b 2t = 1 and a 2t = 1, w 2t = 1 otherwise, w2t =0, t=1, 2, n. v1t b1t a1t b1t a1t ; when b1t =0 and a1t =0, v1t =0, otherwise, v1t =1, t=1, 2, n; v2t b2t a2t b2t a2t ; when b2t =0 and a2t =0, v2t =0, otherwise, v2t =1, t=1, 2, n.
0

1156

Int J Adv Manuf Technol (2011) 55:11491158

6 Instance Based on the methodology research, a web-based PLM system (IntePLM) has been developed in National CAD Support Software Engineering Research Center of Huazhong University of Science and Technology. The software and hardware environment is as follows: Operating system: Microsoft Windows 2000 Server. Web Server: IIS6.0. Database Management System: Oracle 10 g. Programming language: VC++ 2005. Modeling tool: Rational Rose 2000. Developing tool: VC++ builder 2005.
model Drawing

This system provides fine-grained access to all the product data whenever and wherever it is recorded. The applications of above product data model can be expressed in many ways in IntePLM system. In this section, product structure tree mapping and product feature attributes mapping between data domains are selected as an example. Here, a toy car is showed to illustrate the mapping between data domains. Figure 5 shows the basic structure of a toy car. It consists of bottom, wheel, axle, frontlight, backlight, frontdoor, middoor, backdoor, body. d1,d2,...,d51 are the product data objects, and r1,r2,...,r50 are relationship objects. Since part middle door and component Asmbottom are outsourcing machining parts, they don't contain NC programs. Since part backdoor and component Asmmodel Drawing

d48
r47 r48

d49

d50

r49

r50 d51

Assembly model

Assembly drawing

Frontlight

Backtlight

d24

d25

d12
r21
Assembly model Assembly Assembly drawing plan

d13
r22 r23 r24

Asm_light

d21
r18

d22
r19 r20

d23
r3

d4

d3
Asm_Bottom

d1
r2 r17
toy car

r15

r4

r5

r6

r7

d39
model

d9
r38
Bottom

d10

r16

d11
Axle

d14
r1
Assembly model

d15

d16

d17

Wheel

r39 r40

r41

r41 r43

d40

d41

d42

d43

d44

d45

r44 r45

r46

Assembly Assembly help plan drawing

d46

d47

Drawing Processing model Drawing Processing model Drawing Processing

d2

Asm_Body

r8 r9 r10

r11

r12

r13

r14

d18
Assembly model

d19

d20

d5
Frontdoor

d6
Middoor

d7
Backdoor

Assembly Assembly plan drawing

d8
Body

r25

d26

d27

r26

r27

r28

r29 r30

r31

r32

r33

d28

d29

d30

d31

d33

d32

d34

d35

r34 r35

r36

r37

d36

d37

d38

NC model Drawing Processing programs

NC model Drawing Processing model Drawing model Drawing Processing programs

Fig. 5 The basic structure of a toy car

Int J Adv Manuf Technol (2011) 55:11491158

1157

light are purchased part, they don't processing plan and NC programs. Then product data structure matrix is denoted by matrix D, and  D d1 r1 d2 r2 ::: ::: d50 r50 d51 0 1 0 0 1 

Figure 4 shows that some components and parts are outsourcing machining parts or purchased parts. The processing plan and NC programs of parts are not considered in design domain, so matrix D1 in design domain does not contain data objects d28,d29,d32,d37,d38, d41,d44,d47, and relationship objects r27,r28,r31,r36,r37,r40, r43,r46. So these objects mapping coefficients are 0, the other coefficients are 1. Then matrix D1 can be represented. In manufacturing domain, outsourcing machining parts, purchased parts, some assembly model, assembly drawing, assembly plan and help are not mentioned. That is, matrix D2 in manufacturing domain doesn't contain data objects d6,d7,d9d25,d30d34,d39,d51, and relationship objects r4r7,r9r10,r12r24,r29r33,r38r50. These objects mapping coefficients are 0, and the others are 1. Then matrix D2 in manufacturing domain is educed. The mapping matrix M12 from design domain to manufacturing domain can be educed by matrix D1 and matrixD2. The

mapping coefficients of matrix M12 can be educed as followings: The mapping coefficients of data objects d1d5,d8,d26 d27,d32,d35d36,d41,d44,d47 are 0; the mapping coefficients of relationship objects r1r3,r8,r11,r25r26,r31,r34r35,r40,r43, r46 are 0; the mapping coefficients of data objects d6,d7,d9 d25,d30,d31,d34,d39,d40,d42,d43,d45,d46,d48d51 are 1; the mapping coefficients of relationship objects r4r7,r9,r10,r12 r24,r29,r30,r32,r33,r38,r39,r41,r42,r44,r45,r47r50 are 1; the mapping coefficients of data objects d28,d29,d33,d37,d38 are 1; the mapping coefficients of relationship objects r27,r28,r36, r37 are 1. The mapping matrix M12 is the bridge connecting product data structure between design domain and manufacturing domain. For the toy car instance, the mapping between product feature attributes in different data domains is the synthetic maps of above seven mapping types. For example, product public attributes, such as material ID, name, are the same when product data structure conversion between process planning domain and manufacturing domain. This kind of mapping is generic mapping. The mapping between the product material attribute, weight attribute in process planning domain and the manufacturing resource attribute in manufacturing domain is called derivative mapping. Product numbers attribute in manufacturing domain is

Fig. 6 The establishment and maintenance of product data structure and properties set in manufacturing domain in IntePLM

1158

Int J Adv Manuf Technol (2011) 55:11491158 2. Xiaoqing T, Yun Hu (2008) Data model for quality in product lifecycle. Comput Ind 59(23):167179 3. Bellatreche L, Dung NX, Pierra G, Hondjack D (2006) Contribution of ontology-based data modeling to automatic integration of electronic catalogues within engineering databases. Comput Ind 57(89):711724 4. Peng TK, Trappey Amy JC (1998) A step toward STEPcompatible engineering data management: the data models of product structure and engineering changes. Robot Comput-Integr Manuf 14(2):89109 5. Giannini F, Monti M, Biondi D, Monari PD (2002) A modeling tool for the management of product data in a co-design environment. Comput-Aided Des 34(14):10631073 6. Gang Z, Guofu Y, Kewen D (2005) Research on assemblyoriented characteristics-hierarchy modeling method. Comput Integr Manuf Syst 11(7):916920 7. Lee G, Sacks R, Eastman C (2007) Product data modeling using GTPPMa case study. Autom Constr 16(3):392407 8. Brire-Ct A, Rivest L, Desrochers A (2010) Adaptive generic product structure modeling for design reuse in engineering-toorder products. Comput Ind 61(1):5365 9. Liang C, Guodong J (2006) Product modeling for multidisciplinary collaborative design. Int J Adv Manuf Technol 30(78):589 600 10. Nakatani LH, Ardis MA, Olsen RG, Pontrelli PM (1999) Jargons for domain engineering. In: Proceedings of the 2nd Conference on Domain-Specific Languages, pp 1524 11. Addy EA (1998) A framework for performing verification and validation in reuse based software engineering. Ann Software Eng 5(1):279292 12. Kang KC, Kim S, Lee J, Kim K, Shin E, Huh M (1998) FORM: A feature-oriented reuse method with domain-specific reference architectures. Ann Software Eng 5(1):143168 13. Prieto-Diaz R, Arango G (1990) Domain analysis and software systems modeling. IEEE Computer Society, Silver Spring, pp 9 52 14. Leung KRPH, Leung HKN, Suk F (1999) A COTS selection method using domain model, TR-20, Department of Computing, Hong Kong Polytechnic University 15. Nordstrom G, Sztipanovits J, Karsai G, Ledeczi A (1999) Metamodeling- rapid design and evolution of domain-specific modeling environments. In: Proceedings of the IEEE Sixth Symposium on Engineering Computer-Based Systems (ECBS), pp 6874 16. Reinhartz-Berger I, Sturm A (2007) Enhancing UML models: a domain analysis approach. J Database Manag JDM 19(1):7494 17. Mernik M, Heering J, Sloane AM (2005) When and how to develop domain-specific languages. ACM Comput Surv 37 (4):316344 18. Tan Tongde, Tong Bingshu, Wang Tao (2000) The data model for product structure design [J]. Journal of Computer-Aided Design & Computer Graphics, 2000, 12(1):1116

calculated from the product numbers attribute and production plan attribute in process planning domain. The kind of mapping is aggregation mapping. The manufacturing workshop attribute in manufacturing domain is decided by the production type attribute in process planning domain. The kind of mapping is educed mapping. Node traversal algorithm is used for the mapping of toy car feature attributes in data domains with above mapping types. Figure 6 illustrated the mapping processes and rules of product data structure tree and their feature properties between design domain and manufacturing domain in IntePLM system.

7 Conclusions Product data model is the key core to support PLM system, and it is also the basic for collaborative data and processes through product development. As a solution, a domainbased product data model is here proposed on the base of the advantage of domain management and analysis of dynamic and changing data information in product all lifecycles. With the product data information model in data domain and the product data models mapping between data domains, product lifecycle data model does not only guarantee the manageability, integrality, consistency, security, and traceability of product data in all lifecycles, but can also share various and dynamic data information from product evolution chain. The mapping processes between product data models in all data domains provide a feasible approach for data conversion in its structure and attributes. Without explicit product structure in concept design domain, product data mapping method and rule cannot be used for it. Further studies will be made about the mapping rule between concept design domain and others.

References
1. Sudarsan R, Fenves SJ, Sriram RD, Wang F (2005) A product information modeling framework for product lifecycle management. Comput-Aided Des 37(13):13991411