- Email: [email protected]
A Product Data Management architecture for integrating hardware and software development
Computers in Industry 62 (2011) 854–863
Contents lists available at SciVerse ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
A Product Data Management architecture for integrating hardware and software development Namchul Do *, Gyoengseok Chae 1 Dept. of Industrial and Systems Engineering, ERI, Gyoengsang National University, 900 Kajwa-dong, Jinju City, Gyoengnam 660-701, Republic of Korea
A R T I C L E I N F O
A B S T R A C T
Article history: Received 13 March 2010 Received in revised form 20 May 2011 Accepted 6 September 2011 Available online 25 September 2011
This paper proposes an architecture of Product Data Management (PDM) for integrating Software Configuration Management (SCM). The proposed architecture extends its data model to support version items for SCM. Its applications support both PDM and SCM functionalities, as well as integrate hardware parts and software items in product configurations and engineering change management. The architecture is implemented by using a commercial Product Lifecycle Management (PLM) system. The implementation enables hardware engineers and software programmers to share the same user environment, on a consistent database during the collaborative product development. ß 2011 Elsevier B.V. All rights reserved.
Keywords: Product Data Management Software Configuration Management Integration of PDM and SCM PDM/SCM architecture Product Lifecycle Management
1. Introduction The current manufacturers actively introduce software components into their hardware products in order to efficiently enhance their performance and flexibility. These cause an elevated need for new types of product development management, which allow hardware and software engineers to share and exchange consistent product data during the product development life cycle. However, the two disciplines have developed independent management approaches: hardware development depends on Product Data Management (PDM) and Software development uses Software Configuration Management (SCM). There have been several approaches to integrate or interface PDM and SCM. Commercial PDM systems provide an interrelationship between their document objects and software items of outside SCM systems. These approaches create duplications of product data and heterogeneous user interfaces that lead to critical errors and tedious reworks during collaborations. Conceptual architectures proposed by academic researches also fail to support the collaborations. This is in large part, due to the lack of considerations on product configurations and engineering changes that involve company-wide collaborations in order to determine official and sharable product design specifications across the company.
This paper examines the possibilities of an extended PDM architecture that can support both PDM and SCM. The architecture ought to provide functionalities of PDM and SCM respectively, while allowing collaboration functions between the two disciplines. The proposed functions include integrated product configuration and engineering change management, for both hardware and software products. PDM systems can implement the architecture, along with its product data model, to satisfy the needs for consistent product data or the development of hardware and software integrated products. Since the architecture delivers a unified product data model, paired with collaboration functionalities for hardware and software development, the implemented PDM/SCM systems can introduce a common product database. This database is used in conjunction with an identical user interface, for both the hardware and software engineers. As a result, errors and reworks due to data duplications or heterogeneous user environments can be eliminated. The remainder of this paper is organized as follows: Section 2 gives an overview of related work. Section 3 introduces a comparison study on PDM and SCM. Section 4 presents the PDM/SCM architecture, and describes extensions of its document management and product structure, along with engineering changes. Section 5 addresses illustrative examples of an implementation of the architecture. Finally, Section 6 draws conclusions. 2. Related work
* Corresponding author. Tel.: +82 55 772 1703; fax: +82 55 772 1699. E-mail addresses: [email protected] (N. Do), [email protected] (G. Chae). 1 Tel.: +82 55 772 1703; fax: +82 55 772 1699. 0166-3615/$ – see front matter ß 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2011.09.001
From the view of PDM and SCM integration, Estubliers [1] compared PDM and SCM on Fundamentals, Product Model,
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
Versioned Product Model, Workspace and Process Model. The research provides only various comparisons, without proposing processes or data models for the integration. Westfechtel and Conradi [2] also made a comparison between PDM and SCM. They reported that main objects in SCM are text-oriented source codes which require various version operations. Crnkevic et al. [3] provided frameworks and examples for PDM and SCM integration. They consider integrated product data models to be a critical factor for the successful PDM and SCM integration. The industrial example introduced in the book, shows an integration of PDM with SCM for the representation of meta data for software version items. An additional approach to the integration of PDM and SCM [4] proposed an integrated product structure model which includes hardware and software products. However, there are two integral components that the product structure model does not take into account. These components include product configurations and engineering changes. They enable stakeholders of product development, across companies, to collaborate on shared product data through the development life cycle. So, they should be considered for supporting collaborations between hardware and software engineers. ConIPF (Configuration of Industrial Product Families) [5,6] provides an integrated product configuration model that includes both hardware and software components. The proposed rulebased product configuration model enables customers to specify their own product configurations which have both hardware and software products. This research focuses primarily on the product configuration management, being a small portion of the PDM and SCM integration. It does not deal with other issues on the PDM and SCM integration, such as: representation of meta data, version operations for source codes, sharing product data model, product configuration management and engineering change management. El-Khoury [7] focuses on the model-based approach that allows for integration of various engineering tools for hardware and software development. It also introduces a commercial PLM system in order to integrate PDM and SCM. However, the research cannot offer how to integrate hardware and software products, during product configuration management and engineering changes. In addition, they postponed the implementation of SCM operations for version items, in the integrated environment, to the future work. Major commercial PLM systems [8,9] provide interfaces to commercial SCM systems such as IBM ClearCase. They provide special types of data objects that can interface to version items in the target SCM. For example, TeamCenter Engineering, a Product Lifecycle Management System (PLM) from a major PDM system vendor, SIEMENS PLM Software [8] provides the SCMVersionObjects in its product data, which can interface corresponding version items in IBM ClearCase database. However, they should manage independent PDM and SCM databases with heterogeneous applications which are interfaced to one another. These interfaces can cause data mismatches in the two independent databases, thus providing hardware and software engineers with heterogeneous user environments. Compared with other approaches, the proposed architecture can manage integrated hardware and software products for product configurations and engineering changes. Both product configurations and engineering changes are in need of consistent product data across the hardware and software products. It extends the existing product data model for PDM in order to integrate SCM operations. These SCM operations include version control, branch/merge as well as configuration selections. The architecture can base the PDM, SCM and collaboration applications on the integrated PDM/SCM database, providing basic functionalities for each discipline, as well as operations for collaborative product development. Therefore, it can support an integrated and
855
consistent PDM database with a common user environment for hardware and software engineers, devoid of duplicating of their product data. 3. Comparisons between PDM and SCM functionality 3.1. Introduction to PDM and SCM As an information tool for managing product development processes and associated product data, PDM have been applied to development of mechanical products. The main functionality of PDM systems can be divided into five categories: Data vault and document management; workflow and process management; product structure management; classification management; and program management [3,10]. Among them, the document management and the product structure management are related to the integration with SCM. The data vault and document management lets users to access all types of consistent product information in the centralized data repositories. The product information stored in the data vault is engineering documents generated by various applications. The meta data for describing the properties of the documents is also managed by the vault. The product structure comprises components and the constituent relationships between them. The product structure management includes identification and control of product configurations, management and selection of product variants, linking the engineering documents to the structure, and allowance of domain specific views of a product structure. SCM can automate activities for software development and its changes. Its main functionality includes version control for managing series of changed software items, configuration selections for identifying a set of specific versions of items, build management for specifying orders of selected version items for compiling software products, and release management for managing relationships among released software products. 3.2. Comparisons on document management One similarity between PDM and SCM, is that both systems specify product definitions with their documents. The shapes of products, or the source codes for programs within versions of engineering documents (in order to manage development progresses and design alternatives), are examples of these specified product definitions. The two systems differ when it comes to metadata management for hardware parts, software items and branch/merge operations for managing version items. Additionally, only SCM supports source code comparisons between different versions of items. Fig. 1 illustrates the differences between PDM and SCM, in terms of document management. On the left side of Fig. 1, PDM manages detailed metadata with the product objects (see the ‘part A’ and the ‘part B’ products in Fig. 1(a)) and attaches documents as associated objects (see the ‘dwg01’ and the ‘dwg02’ documents) to the product objects. On the right side of Fig. 1, SCM directly manages source codes in document objects (see the document objects in Fig. 1(b)) without objects for metadata such as the product objects in PDM. This prohibits SCM to maintain additional metadata for version items (source code files) which contains limited metadata supported by basic file systems. The amount of metadata for version items, in SCM, is not sufficient enough to manage the development of complex, software intensive hardware products. As a result, some companies have tried to integrate PDM and SCM for the purpose of enhancing metadata for software version items [3].
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
856
part B
code 03
dwg 02
part A
merge
code 02
code 02.1
code 01
branch
dwg 01 documents
products (a)
documents association
(b)
version up
Fig. 1. Comparisons between PDM (a) and SCM (b) on document management.
SCM supports branch/merge operations on its source codes (see branch/merge operations on the version items in Fig. 1(b)). However, most PDM systems do not support the branch/merge operations on their documents. An additional operation which only SCM supports, is source code comparisons. These comparisons are unique in that they are made between two different version items, whereas most PDM systems do not support these kinds of operations.
‘config B’, are built by combinations of the predefined modules (see the module 01 to 03 in Fig. 2(a)). When compared with PDM, SCM directly selects version items without the configuration modules, in order to build product configurations (see the SCM configuration selection on the right side of Fig. 2). Product configurations, based on combinations of predefined modules in PDM, are known as a more advanced approach than those found in SCM. The PDM modules have the ability to provide a shareable product data unit for complex product configuration management and collaborative product development. The product families and the product lines approach in SCM [6,11] tried to import the module concepts in PDM as their basic models for software configuration selections. Generally, the configuration modules in PDM are variants that can change their product structures with specific validation conditions; the effectivity data (see the ‘effectivity data’ in Fig. 2(a)). In Fig. 2, the effectivity data in PDM are specified on the constituent relationships, between the configuration modules and the products that are the roots of assembly structures. On the other hand, the product configurations in SCM simply select the participating version items, through one level product structures, without the flexible condition and verification mechanism (see Fig. 2(b)). 3.4. Result of comparisons
3.3. Comparisons on product structure management
After having compared these two disciplines, we have found PDM has a more expressive product data model than SCM. It can manage the data for supporting SCM functionalities with extensions to the following two directions:
Both PDM and SCM represent their product structures with constituent relationships among the participating hardware products or software items. In addition, they both specify product configurations by using product structures with associated conditions, thus validating correct product structures for specific product configurations. PDM typically supports product configurations as combinations of predefined product modules. These modules are standardized across a company and are shared by other departments, such as: manufacturing, purchase, or customer services. As such, these modules perform as standard information units for communication across the company. The left side of Fig. 2 shows an example of product configurations in PDM, whereas the ‘config A’, and the
Direction one is the extension of document management in PDM to allow SCM version control operations, such as branch/merge and code comparisons. This enables software engineers to manage their source code items utilizing the document objects in PDM databases. Additionally, it enables them to take advantage of the expressive meta data management functionalities of PDM document objects. Direction two is the extension of effectivity applications to document objects. Both product configurations, as well as engineering changes, need to specify effectivity data on their product structure. The effectivity data for product configurations identify product structure that belongs to the specific product configuration. Effectivity data specified on product variants, can
(a)
(b) config A
config B
config A
config B
effectivity data module 01
module 02
module 03 code 01
PART A
PART D
PART B
code 02
PART C
PART E
Fig. 2. Comparisons between PDM (a) and SCM (b) on product structure and product configurations.
code 03
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
manage histories of product structure changes as an engineering change history. If the effectivity data can specify valid documents (i.e. extension of effectivity data to documents of the software product), they cannot only identify hardware products, but also software items that constitute specific product configurations or engineering changes. As a result, hardware and software engineers can meaningfully collaborate, to devise efficient design decisions by reviewing product configurations and engineering changes, containing consistent hardware and software product information.
4. PDM/SCM system architecture 4.1. Overall architecture Fig. 3 shows the main components of the PDM architecture. The architecture consists of two major parts, including: the PDM/SCM unified database with the integrated database model and applications for PDM, SCM and collaborations with the common user interface. The unified database stores all of the PDM, and the SCM data, in addition to their integrated data (see the PDM/SCM unified database in Fig. 3). The PDM/SCM database model specifies the structure of the database, in a formal database language (see the PDM/SCM database model in Fig. 3). We describe the database model with an extended standard data model for PDM systems. The database model is a key enabler to the architecture, given that it supports the database to provide the applications with the PDM and the SCM data, necessary for both hardware and software development. Given a database definition language and high level query functions, the current PDM systems can easily implement the PDM/SCM database model into its PDM databases. In order to take the advantage of the existing standard data model for PDM, we have based the PDM/SCM database model on the STEP PDM Schema [12]. The STEP PDM Schema is a set of application protocols in the ISO STEP standard, for specifying general PDM applications. It provides a standard product data model for specifying product identifications, along with associated documents, product structures, product configurations and engineering changes. The standard guarantees the PDM/SCM database model can directly support the general PDM functionalities. Extending the standard model, we can also represent SCM and PDM/SCM integrated functionalities, in the proposed database model. In Section 4.2 we will further discuss the model. As we have discussed in the introduction section, the proposed PDM/SCM system ought to provide both PDM and SCM functionalities respectively. In addition, the system should manage the collaborations, of both hardware and software engineers, for the hardware engineer
software engineer
common user interface PDM app.
Collaboration app.
SCM app.
PDM/SCM applications
utility functions PDM/SCM database model
PDM/SCM database
PDM/SCM unified database
Fig. 3. The main components of the PDM architecture.
857
product configuration and engineering change management, which are indispensable elements of the current collaborative product development process. In order to realize the functionalities, the architecture classifies the PDM/SCM applications into the following three categories: the PDM, the SCM, and the collaboration applications (see the PDM, the SCM and the collaboration applications in Fig. 3). The PDM and the SCM applications access and manage their data receptively, providing their own independent functionalities to either hardware or software development. The collaboration applications access both the PDM and SCM data, in the database, through the integrated database model. The applications handle this data, for supporting collaborations among hardware and software engineers during product configuration or engineering change management. The utility functions are common tools for supporting operations of PDM, such as access controls, communication between users, and data interfaces (see the utility functions in Fig. 3). Both hardware and software engineers alike, have access to the applications and databases through the common user interface to the system (see the common user interface in Fig. 3). Providing the common user interface, leverages the benefits of the unified database to the collaboration. Both hardware and software engineers can share the unified database through the common user interface, which extends the current user environment provided by the PDM clients. Since most PDM clients provide interfaces to external applications, software engineers can easily add their SCM utilities or application programs to the common user interface. 4.2. PDM/SCM database model 4.2.1. Extended document management The PDM/SCM database model, being based on the existing PDM standard, needs to create new types of entities and associated operations for supporting version management of software items. As we mentioned in Section 3.2, the version management in SCM needs different operations from that of PDM. These differences include branch/merge and comparisons of their source codes. In order to support the version management of SCM based on the PDM database model, the database model provides data entities for the software products and associated documents with the branch/ merge and code comparison operations. The software product entity can also store rich meta data for software items, since it uses an extended product object that can manage various meta data. Existing SCM systems manage only source code files with only a few additional attributes. Fig. 4 shows the extended STEP PDM Schema, that represents the product and associated document, of the PDM/SCM database model in EXPRESS-G notation [13]. The PDM/SCM database model extends the ‘sw_document’ entity from the ‘document’ entity in the STEP PDM Schema, which contains the SCM operations for source code management. Since the product concept in the STEP PDM schema represents not only the end product, but also subcomponents of the end product, the model shares the ‘product’ entity to represent software items of SCM. If the software items need additional attributes, the ‘product’ entity can extend its set of attributes for the purpose, creating its sub-entities. Based on the ‘product’ entity, the ‘product_definition_formation’ entity represents version information of the product. The ‘product_definition’ entity represents application views of the product (see the ‘product’, the ‘product_definition_formation’ and the ‘product_definition’ entities in Fig. 4). The STEP PDM Schema regards the document as a product in representations, so that the product with its view and version entities, can represent the document. The ‘document_product_equivalence’ entity in Fig. 4, shows that the document is represented by the product related entities.
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
858
Id
document product
Id name
releating _document
sw_document
of_product product_document _equivanlance
assigned _document
applied_document _reference
related _product
product_definition _formation
items[1:?] product_definition
id
formation product_definition_with _associated_document
id documentation _ids[1:?]
Fig. 4. The PDM/SCM database model implementing the extended document management. Modified from [12].
The association relationship between a product, and related documents, is specified with the ‘applied_document_reference’ entity. The entity associates the ‘product_definition’ entity (a view of a product) with the ‘document’ entity. The software product will associate a specific type of documents for managing software source codes, the ‘sw_document’ entity, a sub-entity of the ‘document’ entity. It inherits all of the attributes and relationship of the super entity, the ‘document’ entity (see the ‘sw_document’ entity in Fig. 4), while additionally containing special SCM operations, the branch, merge and comparison operations. The STEP PDM schema and the EXPRESS (a formal specification language in the STEP standard), fail to have notations for specifying the member operations of an entity. Therefore, we will describe the SCM applications that represent the SCM operations in Section 4.3. 4.2.2. Extended product configurations and engineering changes In order to support meaningful collaborations between different disciplines, design management systems ought to allow participating engineers, from different disciplines, to share the integrated and consistent product configuration and engineering change data, during their collaborations. This is because the product configuration and engineering change management in the product development process, gather all product data from different stakeholders for the development. In addition, they are integrated by the management as official and sharable product specifications, across the company. This section shows how the PDM/SCM database model supports the consistent product configuration and engineering change data for the collaborations of hardware and software development. Engineering changes generate different product structure of the same product, and the differences between each product structure represent a history of the changes. In hardware development, product variants can specify the history of engineering changes, by validating specific product structure with the effectivity data. The effectivity data, accompanied with the modules of product structures, also have the ability to determine product structures for a specific product configuration. Therefore, if a system can support effectivity data, determining both hardware and software products within a specific product structure, it can provide proper product data for product configurations. It also has the ability to provide engineering change management, during the collaborations among hardware and software development.
As we mentioned in Section 3.3, the PDM/SCM database model extends the application of the effectivity data to the document objects of the software products. Through identical effectivity specification, the extension allows hardware and software engineers, or the collaboration applications, to select product structures containing both hardware and software products. This enables all participating engineers to collaborate, based on the same product configurations, in addition to engineering changes. Fig. 5 shows entities of the PDM/SCM database model for product configurations, which extends a part of the STEP PDM Schema [12]. The model supports product configurations with the ‘configuration_item’ and the ‘configuration_design’ entities, as well as the ‘effectivity’ and the ‘applied_effectivity_assignment’ entities. The ‘configuration_item’ entity provides identifiers of each product configurations, while the ‘configuration_design’ entity, associates product configurations with participating products represented with the ‘product_definition_formation’ entity (see the ‘product_definition_formation’ entity in Figs. 4 and 5). The effectivity can be specified on the ‘configuration_design’ entity through its ‘configuration’ attribute. It can be additionally applied on the ‘product_definition_relationship’ entity, of which inheritance hierarchy contains the ‘next_assembly_usage_occurrence’ entity. The ‘next_assembly_usage_occurrence’ entity is used for expressing the product structure between versions of the products in the STEP PDM Schema. In order to expand applications of effectivity data, to documents, as we mentioned in Section 3.4, the ‘effectivity_items’ entity should contain the ‘applied_document_reference’ entity in its inheritance hierarchy. This represents association relationship between products and linked document objects (see the ‘applied_document_reference’ entity in Fig. 4). Therefore, we add the ‘applied_document_reference’ entity as a sub-entity of the ‘effectivity_items’ in Fig. 5 (see the gray colored entity in the figure). Fig. 6 shows how to specify product configurations and engineering changes, which have both hardware and software products, with one simple example. At the beginning of the product structure, the product configuration, ‘config A’, has a hardware product, ‘part 10 A’, and a software product, ‘part 20 A’. The software product associates a document instance, ‘doc 10’, as it’s managed source code item. The initial effectivity data, the ‘1–current’ (meaning that it is valid through the 1st product to the current product) can be instantiated with the effectivity entity, and
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
id purpose name
configuration_item
859
usgae effectivity
assigned _effectivity
configuration configuration_design configuration
applied_effectivity _assignment Items[1:?]
design
effectivity_items
product_definition _formation
product_definition
applied_document _reference
product_definition _relationship
next_assembly_usage _occurrence Fig. 5. The PDM/SCM database model implementing the product configurations and effectivity data. Modified from [12].
links the constituent relationship, associating the ‘config A’, the ‘part 10 A’ and the ‘doc 10’ of the ‘part 20 A’. The product needs an engineering change that replaces the ‘part 10 A’ and the ‘doc 10’, with the ‘part 10 B’ and the ‘doc 20’, respectively. The engineering change alters the product structure with updated effectivity ‘1–99’ and new effectivity ‘100–current’. There are constituent relationships between the ‘config A’, the ‘part 10 B’, and the ‘doc 20’ of the ‘part 20 A’ (see the product structure and effectivity data in Fig. 6). Fig. 6 shows how to determine the valid hardware and software versions in the product structure of the ‘config A’, through the effectivity data, which has 95 as its value. The effectivity condition can be interpreted as, selecting a product structure for the product, which has a serial number 95 (or the 95th product). The thick lines in Fig. 6 show the result of the selection. The version of the hardware product, ‘part 10 A’, is selected by the effectivity data on product structure, between the configuration and the products (see the effectivity data specified on product structures in Fig. 6) seeing as the effectivity condition validates the product structure (1 < 95 < 99). The software versions, associated with the hardware Effectivity = 95 config A
100-current
4.3. The PDM, SCM and collaboration applications
1-99 1-current
part 10 A
part 10 B
part 20 A
doc 10
products, can be determined with the effectivity data, specified on the documents attached to the software products (see the ‘doc 10’ in Fig. 6). Subsequently, the engineers can determine the valid versions of hardware parts and software source codes, through the product structure selection. The example products and their versions, along with the associated documents, can be represented with the product and document related entities in Fig. 4. The product structures and applied effectivity data, can be instantiated with entities specified in Fig. 5. The appendix specifies the instance model for the example (after the engineering change) in STEP Part 21 format [14], which shows that the PDM/SCM database model can represent the data structure for version items of the software products and product selections for both hardware and software products. As a result, we found the STEP PDM schema is expressive enough to represent almost all the data structure needed for the PDM/SCM database model. However, it doest not provide the SCM operations on software products and extended effectivity data specified on relationship between products and associated document objects. As we mentioned on the ‘sw_document’ entity and effectivity application cases, the database model ought to extend the STEP PDM schema with the operations and new sub entity for the effectivity applications.
doc 20
Fig. 6. An example instantiation of the PDM/SCM database model.
4.3.1. The SCM applications The SCM applications enable software engineers to manage their software versions, within the same PDM system as product data is managed by hardware engineers. A software engineer can launch the SCM application on a software product, in the PDM client. The client serves as the default user environment of the PDM system, which is also used by the hardware engineers. The SCM application, lists all the documents containing version items of software source codes of the target software product. Furthermore, this application provides a user environment for the basic SCM operations. The software engineer can apply the SCM operations including revision, branch/merge, comparisons and version up, on the version items in the list provided by the application.
860
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
Fig. 7. Product configurations and assembly modules of the example product.
4.3.2. The collaboration applications In order to provide integrated product configurations and engineering changes for hardware and software development, the collaboration applications ought to support configuration selection functionality. This should be supported as a basic operation for the collaboration applications, which can determine both hardware and software products. The implemented system provides extended configuration selections based on the PDM/SCM database model for product configurations and the engineering changes. A product engineer, who is concerned with whole Product Data Management, including hardware and software, can select specific product structures from the PDM/SCM database, through specifications of effectivity data. By using the extended configuration selection functionality, the user can select a specific product structure for a product configuration or an engineering change history, which contains both hardware and software products. The selected product structure contains both hardware products, as well as specific version items of software codes, managed by document objects of selected software products. Therefore, the configuration selection operation can be used to manage a specific product configuration, consisting of both the hardware and
software parts. This operation also has the ability to manage engineering changes, involving both hardware and software changes, during collaborations between hardware and software development. 5. Implementation of the architecture We have implemented the proposed PDM/SCM architecture, based on a commercial PDM system, Dassault Systems Enovia SmarTeam [15]. The database model is translated to the PDMs database schema and the SCM and collaboration applications are developed by using utilities and API libraries supported by the PDM system. Since general PDM applications are provided by the PDM system, this section will describe only the SCM and collaboration applications developed based on the PDM database. We have developed a robotics system based on the implemented PDM/SCM architecture. Fig. 7 shows the product configurations and assembly product structure of the robotics example. It has two product configurations, the ‘Argos Type 1S’ and the ‘Argos Type 1D’, which select specific components from the several different modules. The modules consist of five hardware modules
Fig. 8. Selection of a specific hardware and software product structure with effectivity data.
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
861
Fig. 9. Windows of configuration selections for the hardware and software integrated products.
(from the ‘Web CAM’ to the ‘Double Bumper’ in Fig. 7) and two software modules (the ‘Software Single Bumper’ and the ‘Software Double Bumper’). The hardware modules have assembly parts and effectivity data specified on the product structure. The software modules have software parts that contain the source codes in their
document objects. The software parts represent the control software for the sensors and actuators of the robotics system. Fig. 8 shows how to determine the valid hardware and software versions in product structure of the ‘Argos Type 1S’ through the ‘2010.1.13’ effectivity data. The thick lines and arrows in Fig. 8
Fig. 10. Windows of SCM operations on the documents of the software part.
862
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
show the result of the selection. The versions of the hardware part under the modules of the ‘Argos Type 1S’ are specified by effectivity data on product structure between the assembly parts and the modules (see the effectivity data bubbles on the product structure in Fig. 8). The software versions under the same effectivity data can be determined with effectivity data specified on the documents attached to the software parts. Then product engineers can determine the valid versions of hardware parts and software source code for the ‘2010.1.13’ effectivity data through the product structure selection. Fig. 9 shows how designers can select the product structure with the collaboration application implemented based on he proposed architecture. The configuration selection window in Fig. 9 shows the selection of the product configuration with four hardware and one software modules through the ‘2010-01-13’ effectivity data. The selected software module, the ‘PO0000001_SW Single Bumper’, has three software parts with specific version of source codes, ‘Main Singe Bumper’, ‘Head Track’, and ‘Escape_0.1’, which implement the behavior of autonomous obstacle avoidance of the robotic system. Fig. 10 shows windows of the SCM application during a merge operation on software version items. It manages source code of the ‘Escape’ program selected in the configuration selection application in the same PDM client shared by hardware engineers. 6. Conclusion In order to satisfy the needs of the current hardware and software integrated product development, this paper proposes a PDM architecture that can manage both hardware and software development based on an integrated product data model. The proposed architecture consists of two main components: the unified PDM/SCM database and the PDM, SCM and collaboration applications based on the database. To allow the unified database to manage all the data used for PDM and SCM, the database model specifies data entities, and their relationship, for hardware and software products. To take advantages of the existing standard PDM data model, the database model extends the STEP PDM Schema, representing product data for PDM and SCM. It also extends the standard data model, to support SCM operations, in the same database that hardware engineers can share for their product development. By extending the application of effectivity data to document objects, of software products, and synchronizing them with hardware products, the database model enables engineers in collaborations, to manage both hardware and software products during the product configuration and engineering change management. The architecture provides independent PDM and SCM applications that support hardware and software development, respectively. However, since the database manages both PDM and SCM data, the architecture can base the heterogeneous applications on a unified database, containing an identical user environment. In addition, it can support the collaboration applications that access and control, both hardware and software data, on the view of integrated product model during product configuration and engineering change management. While the PDM and the SCM applications support hardware and software engineers to manage their own development, the collaboration applications allow the engineers to verify their comprehensive design works, by integrating them into the same product configurations and engineering changes. This paper proposed a unique product data model that can represent two different disciplines, PDM and SCM, based on international product data standards. It also supports the product configuration and engineering change management for the
integrated product development. The implication of the paper to industry is that the architecture can be implemented with the current commercial PDM systems. The prototype implementation in the paper showed the possibilities of the architecture. These can satisfy the needs of integrated hardware and software development, without problems or errors from inconsistent product data and heterogeneous user environments.
Appendix A. STEP P21 specifications for the example in Fig. 6 /* config A */ #10 = configuration_item(‘config A’, ‘a product configuration’, ‘config A’); /* part 10 A */ #100 = product(‘part 10’, ‘part 10’); #110 = product_definition_formation(‘A’, #100); #120 = product_definition(‘AS DESIGN’, #110); /* part 10 B */ #130 = product_definition_formation(‘B’, #100); #140 = product_definition(‘AS DESIGN’, #130); /* part 20 A */ #200 = product(‘part 20’, ‘part 20’); #210 = product_definition_formation(‘A’, #200); #220 = product_definition(‘AS DESIGN’, #210); /* constituent relationship between ‘config A’ and ‘part 10 A’, ‘part 20 A’, ‘part 10 B’*/ #1000 = configuration_design(#10, #110); #1010 = configuration_design(#10, #210); #1020 = configuration_design(#10, #130); /* doc 10 */ /* representing document file */ #30 = document_file(‘doc10.prg’); /* representing the document object ‘doc 10’ */ #300 = product(‘doc 10’, ‘document 10’); #310 = product_definition_formation(‘001’, #300); #320 = product_definition_with_associated_document(‘AS DESIGN’, #310, (#30)); /* equivalence the product definition formation ‘doc 10’ to the document ‘doc 10’ */ #330 = document(‘doc 10’); #340 = document_product_equivalence(#310, #330); /* relationship between the product definition ‘part 20 A’ with the document ‘doc 10’ */ #350 = applied_document_reference(#220, (#330)); /* doc 20 */ /* representing document file */ #40 = document_file(‘doc20.prg’); /* representing the document object ‘doc 20’ */ #400 = product(‘doc 20’, ‘document 20’); #410 = product_definition_formation(‘001’, #400); #420 = product_definition_with_associated_document(‘AS DESIGN’, #410, (#40)); /* equivalence the product definition formation ‘doc 10’ to the document ‘doc 10’ */ #430 = document(‘doc 20’); #440 = document_product_equivalence(#410, #430); /* relationship between the product definition ‘part 20 A’ with the document ‘doc 10’ */ #450 = applied_document_reference(#220, (#430)); /* representing the effectivity data */ #910 = effectivity(#1000, 1, 99,’’);/* config A – part 10 A */ #920 = effectivity(#1010, 1, CURRENT,’’);/* config A – part 20 A */ #930 = effectivity(#1020, 100, CURRENT,’’);/* config A – part 10 B */ #940 = effectivity(’’, 1, 99,’’);/*for part 20 A – doc 10 */ #945 = applied_effectivity_assignment(#940, (#350)); #950 = effectivity(’’, 100, CURRENT,’’);/* for part 20 A – doc 20 */ #955 = applied_effectivity_assignment(#950, (#450)); /* EOF */
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
References [1] J. Estublier, J.M. Favre, P. Morat, Toward SCM/PDM integration, in: System Configuration Management, SCM-8, Lecture Notes in Computer Science, No. 1439, Springer, 1988, pp. 75–94. [2] B. Westfechtel, R. Conradi, Software configuration management and engineering data management: differences and similarities, in: SCM-8, Lecture Notes in Computer Science, No. 1439, Springer, 1998, pp. 96–106. [3] I. Crnkovic, U. Asklund, A.P. Dahlqvist, Implementing and Integrating Product Data management and Software Configuration Management, Artech House Publishers, 2003. [4] A.P. Dahlqvist, C. Ivica, M. Larsson, Managing complex systems – challenges for PDM and SCM, in: 23th ICSE, Toronto, Canada, 2001. [5] T. Krebs, L. Hotz, A. Gunter, Knowledge-based configuration for configuring combined hardware/software systems, in: PuK 2002, 2002. [6] T. Krebs, K. Wolter, L. Hotz, Trends model-based configuration support for product derivation in software product families, in: PuK 2005, 2005. [7] J. El-Khoury, Model data management – towards a common solution for PDM/ SCM system, in: ACM 2005, Lisbon, Portugal, September 5–6, 2005. [8] SIEMENS PLM Software, SIEMENS TeamCenter Engineering, http://www.plm. automation.siemens.com/en_us/products/teamcenter/index.shtml, accessed 12 December, 2009. [9] PTC, PTC WinChil, http://www.ptc.com, accessed 12 December, 2009. [10] CIMdata, PDM: The Definition, CIMdata Report, 1997. [11] T. Mannisto, T. Soininen, R. Sulonen, Configurable software product families, in: ECAI 2000 Configuration Workshop, 2000. [12] PDM Implementer Forum, Usage Guide for the STEP PDM Schema V 1.2, PDM Implementer Forum, 2002. [13] ISO, ISO 10303-11:2004 Industrial Automation Systems and Integration – Product Data Representation and Exchange. Part 11. Description Methods: The EXPRESS Language Reference Manual, ISO STEP, 2004. [14] ISO, ISO 10303-21:2002 Industrial Automation Systems and Integration – Product Data Representation and Exchange. Part 21. Implementation Methods: Clear Text Encoding of the Exchange Structure, ISO STEP, 2002.
863
[15] Dassualt Systems, Dassault Systems Enovia SmarTeam, http://www.3ds.com/ products/enovia/mid-market/smarteam-engineering-express/overview/, accessed 12 December, 2009. Namchul Do has a B.S., a M.S. and a Ph. D. in Industrial Engineering from Pohang University of Science and Technology (POSTECH), Pohang, Korea. Do is currently an associate professor of industrial and systems engineering department at Gyeongsang National University in Korea. He conducts research on product data models for engineering change propagations, rulebased product configurations, integration of product data management (PDM) and software configuration management (SCM), and sustainable product development. He also has co-worked on PDM research and applications with several leading Korean institutes and companies. He is the author of ‘‘An introduction to Product Lifecycle Management (PLM) and its applications’’ (Saengneung Press, 2007, in Korean). In the book, he documented his industrial experiences on PLM in Samsung Heavy Industries and Volvo Construction Equipments Korea and result of government research projects on Collaborative Product Commerce in ETRI. Gyoengseok Chae was received the B.S (2006) and M.S. (2008) in Industrial Engineering from Gyeongsang National University in Korea. His research interests include product database modeling, PDM application development and engineering change management.
Contents lists available at SciVerse ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
A Product Data Management architecture for integrating hardware and software development Namchul Do *, Gyoengseok Chae 1 Dept. of Industrial and Systems Engineering, ERI, Gyoengsang National University, 900 Kajwa-dong, Jinju City, Gyoengnam 660-701, Republic of Korea
A R T I C L E I N F O
A B S T R A C T
Article history: Received 13 March 2010 Received in revised form 20 May 2011 Accepted 6 September 2011 Available online 25 September 2011
This paper proposes an architecture of Product Data Management (PDM) for integrating Software Configuration Management (SCM). The proposed architecture extends its data model to support version items for SCM. Its applications support both PDM and SCM functionalities, as well as integrate hardware parts and software items in product configurations and engineering change management. The architecture is implemented by using a commercial Product Lifecycle Management (PLM) system. The implementation enables hardware engineers and software programmers to share the same user environment, on a consistent database during the collaborative product development. ß 2011 Elsevier B.V. All rights reserved.
Keywords: Product Data Management Software Configuration Management Integration of PDM and SCM PDM/SCM architecture Product Lifecycle Management
1. Introduction The current manufacturers actively introduce software components into their hardware products in order to efficiently enhance their performance and flexibility. These cause an elevated need for new types of product development management, which allow hardware and software engineers to share and exchange consistent product data during the product development life cycle. However, the two disciplines have developed independent management approaches: hardware development depends on Product Data Management (PDM) and Software development uses Software Configuration Management (SCM). There have been several approaches to integrate or interface PDM and SCM. Commercial PDM systems provide an interrelationship between their document objects and software items of outside SCM systems. These approaches create duplications of product data and heterogeneous user interfaces that lead to critical errors and tedious reworks during collaborations. Conceptual architectures proposed by academic researches also fail to support the collaborations. This is in large part, due to the lack of considerations on product configurations and engineering changes that involve company-wide collaborations in order to determine official and sharable product design specifications across the company.
This paper examines the possibilities of an extended PDM architecture that can support both PDM and SCM. The architecture ought to provide functionalities of PDM and SCM respectively, while allowing collaboration functions between the two disciplines. The proposed functions include integrated product configuration and engineering change management, for both hardware and software products. PDM systems can implement the architecture, along with its product data model, to satisfy the needs for consistent product data or the development of hardware and software integrated products. Since the architecture delivers a unified product data model, paired with collaboration functionalities for hardware and software development, the implemented PDM/SCM systems can introduce a common product database. This database is used in conjunction with an identical user interface, for both the hardware and software engineers. As a result, errors and reworks due to data duplications or heterogeneous user environments can be eliminated. The remainder of this paper is organized as follows: Section 2 gives an overview of related work. Section 3 introduces a comparison study on PDM and SCM. Section 4 presents the PDM/SCM architecture, and describes extensions of its document management and product structure, along with engineering changes. Section 5 addresses illustrative examples of an implementation of the architecture. Finally, Section 6 draws conclusions. 2. Related work
* Corresponding author. Tel.: +82 55 772 1703; fax: +82 55 772 1699. E-mail addresses: [email protected] (N. Do), [email protected] (G. Chae). 1 Tel.: +82 55 772 1703; fax: +82 55 772 1699. 0166-3615/$ – see front matter ß 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2011.09.001
From the view of PDM and SCM integration, Estubliers [1] compared PDM and SCM on Fundamentals, Product Model,
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
Versioned Product Model, Workspace and Process Model. The research provides only various comparisons, without proposing processes or data models for the integration. Westfechtel and Conradi [2] also made a comparison between PDM and SCM. They reported that main objects in SCM are text-oriented source codes which require various version operations. Crnkevic et al. [3] provided frameworks and examples for PDM and SCM integration. They consider integrated product data models to be a critical factor for the successful PDM and SCM integration. The industrial example introduced in the book, shows an integration of PDM with SCM for the representation of meta data for software version items. An additional approach to the integration of PDM and SCM [4] proposed an integrated product structure model which includes hardware and software products. However, there are two integral components that the product structure model does not take into account. These components include product configurations and engineering changes. They enable stakeholders of product development, across companies, to collaborate on shared product data through the development life cycle. So, they should be considered for supporting collaborations between hardware and software engineers. ConIPF (Configuration of Industrial Product Families) [5,6] provides an integrated product configuration model that includes both hardware and software components. The proposed rulebased product configuration model enables customers to specify their own product configurations which have both hardware and software products. This research focuses primarily on the product configuration management, being a small portion of the PDM and SCM integration. It does not deal with other issues on the PDM and SCM integration, such as: representation of meta data, version operations for source codes, sharing product data model, product configuration management and engineering change management. El-Khoury [7] focuses on the model-based approach that allows for integration of various engineering tools for hardware and software development. It also introduces a commercial PLM system in order to integrate PDM and SCM. However, the research cannot offer how to integrate hardware and software products, during product configuration management and engineering changes. In addition, they postponed the implementation of SCM operations for version items, in the integrated environment, to the future work. Major commercial PLM systems [8,9] provide interfaces to commercial SCM systems such as IBM ClearCase. They provide special types of data objects that can interface to version items in the target SCM. For example, TeamCenter Engineering, a Product Lifecycle Management System (PLM) from a major PDM system vendor, SIEMENS PLM Software [8] provides the SCMVersionObjects in its product data, which can interface corresponding version items in IBM ClearCase database. However, they should manage independent PDM and SCM databases with heterogeneous applications which are interfaced to one another. These interfaces can cause data mismatches in the two independent databases, thus providing hardware and software engineers with heterogeneous user environments. Compared with other approaches, the proposed architecture can manage integrated hardware and software products for product configurations and engineering changes. Both product configurations and engineering changes are in need of consistent product data across the hardware and software products. It extends the existing product data model for PDM in order to integrate SCM operations. These SCM operations include version control, branch/merge as well as configuration selections. The architecture can base the PDM, SCM and collaboration applications on the integrated PDM/SCM database, providing basic functionalities for each discipline, as well as operations for collaborative product development. Therefore, it can support an integrated and
855
consistent PDM database with a common user environment for hardware and software engineers, devoid of duplicating of their product data. 3. Comparisons between PDM and SCM functionality 3.1. Introduction to PDM and SCM As an information tool for managing product development processes and associated product data, PDM have been applied to development of mechanical products. The main functionality of PDM systems can be divided into five categories: Data vault and document management; workflow and process management; product structure management; classification management; and program management [3,10]. Among them, the document management and the product structure management are related to the integration with SCM. The data vault and document management lets users to access all types of consistent product information in the centralized data repositories. The product information stored in the data vault is engineering documents generated by various applications. The meta data for describing the properties of the documents is also managed by the vault. The product structure comprises components and the constituent relationships between them. The product structure management includes identification and control of product configurations, management and selection of product variants, linking the engineering documents to the structure, and allowance of domain specific views of a product structure. SCM can automate activities for software development and its changes. Its main functionality includes version control for managing series of changed software items, configuration selections for identifying a set of specific versions of items, build management for specifying orders of selected version items for compiling software products, and release management for managing relationships among released software products. 3.2. Comparisons on document management One similarity between PDM and SCM, is that both systems specify product definitions with their documents. The shapes of products, or the source codes for programs within versions of engineering documents (in order to manage development progresses and design alternatives), are examples of these specified product definitions. The two systems differ when it comes to metadata management for hardware parts, software items and branch/merge operations for managing version items. Additionally, only SCM supports source code comparisons between different versions of items. Fig. 1 illustrates the differences between PDM and SCM, in terms of document management. On the left side of Fig. 1, PDM manages detailed metadata with the product objects (see the ‘part A’ and the ‘part B’ products in Fig. 1(a)) and attaches documents as associated objects (see the ‘dwg01’ and the ‘dwg02’ documents) to the product objects. On the right side of Fig. 1, SCM directly manages source codes in document objects (see the document objects in Fig. 1(b)) without objects for metadata such as the product objects in PDM. This prohibits SCM to maintain additional metadata for version items (source code files) which contains limited metadata supported by basic file systems. The amount of metadata for version items, in SCM, is not sufficient enough to manage the development of complex, software intensive hardware products. As a result, some companies have tried to integrate PDM and SCM for the purpose of enhancing metadata for software version items [3].
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
856
part B
code 03
dwg 02
part A
merge
code 02
code 02.1
code 01
branch
dwg 01 documents
products (a)
documents association
(b)
version up
Fig. 1. Comparisons between PDM (a) and SCM (b) on document management.
SCM supports branch/merge operations on its source codes (see branch/merge operations on the version items in Fig. 1(b)). However, most PDM systems do not support the branch/merge operations on their documents. An additional operation which only SCM supports, is source code comparisons. These comparisons are unique in that they are made between two different version items, whereas most PDM systems do not support these kinds of operations.
‘config B’, are built by combinations of the predefined modules (see the module 01 to 03 in Fig. 2(a)). When compared with PDM, SCM directly selects version items without the configuration modules, in order to build product configurations (see the SCM configuration selection on the right side of Fig. 2). Product configurations, based on combinations of predefined modules in PDM, are known as a more advanced approach than those found in SCM. The PDM modules have the ability to provide a shareable product data unit for complex product configuration management and collaborative product development. The product families and the product lines approach in SCM [6,11] tried to import the module concepts in PDM as their basic models for software configuration selections. Generally, the configuration modules in PDM are variants that can change their product structures with specific validation conditions; the effectivity data (see the ‘effectivity data’ in Fig. 2(a)). In Fig. 2, the effectivity data in PDM are specified on the constituent relationships, between the configuration modules and the products that are the roots of assembly structures. On the other hand, the product configurations in SCM simply select the participating version items, through one level product structures, without the flexible condition and verification mechanism (see Fig. 2(b)). 3.4. Result of comparisons
3.3. Comparisons on product structure management
After having compared these two disciplines, we have found PDM has a more expressive product data model than SCM. It can manage the data for supporting SCM functionalities with extensions to the following two directions:
Both PDM and SCM represent their product structures with constituent relationships among the participating hardware products or software items. In addition, they both specify product configurations by using product structures with associated conditions, thus validating correct product structures for specific product configurations. PDM typically supports product configurations as combinations of predefined product modules. These modules are standardized across a company and are shared by other departments, such as: manufacturing, purchase, or customer services. As such, these modules perform as standard information units for communication across the company. The left side of Fig. 2 shows an example of product configurations in PDM, whereas the ‘config A’, and the
Direction one is the extension of document management in PDM to allow SCM version control operations, such as branch/merge and code comparisons. This enables software engineers to manage their source code items utilizing the document objects in PDM databases. Additionally, it enables them to take advantage of the expressive meta data management functionalities of PDM document objects. Direction two is the extension of effectivity applications to document objects. Both product configurations, as well as engineering changes, need to specify effectivity data on their product structure. The effectivity data for product configurations identify product structure that belongs to the specific product configuration. Effectivity data specified on product variants, can
(a)
(b) config A
config B
config A
config B
effectivity data module 01
module 02
module 03 code 01
PART A
PART D
PART B
code 02
PART C
PART E
Fig. 2. Comparisons between PDM (a) and SCM (b) on product structure and product configurations.
code 03
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
manage histories of product structure changes as an engineering change history. If the effectivity data can specify valid documents (i.e. extension of effectivity data to documents of the software product), they cannot only identify hardware products, but also software items that constitute specific product configurations or engineering changes. As a result, hardware and software engineers can meaningfully collaborate, to devise efficient design decisions by reviewing product configurations and engineering changes, containing consistent hardware and software product information.
4. PDM/SCM system architecture 4.1. Overall architecture Fig. 3 shows the main components of the PDM architecture. The architecture consists of two major parts, including: the PDM/SCM unified database with the integrated database model and applications for PDM, SCM and collaborations with the common user interface. The unified database stores all of the PDM, and the SCM data, in addition to their integrated data (see the PDM/SCM unified database in Fig. 3). The PDM/SCM database model specifies the structure of the database, in a formal database language (see the PDM/SCM database model in Fig. 3). We describe the database model with an extended standard data model for PDM systems. The database model is a key enabler to the architecture, given that it supports the database to provide the applications with the PDM and the SCM data, necessary for both hardware and software development. Given a database definition language and high level query functions, the current PDM systems can easily implement the PDM/SCM database model into its PDM databases. In order to take the advantage of the existing standard data model for PDM, we have based the PDM/SCM database model on the STEP PDM Schema [12]. The STEP PDM Schema is a set of application protocols in the ISO STEP standard, for specifying general PDM applications. It provides a standard product data model for specifying product identifications, along with associated documents, product structures, product configurations and engineering changes. The standard guarantees the PDM/SCM database model can directly support the general PDM functionalities. Extending the standard model, we can also represent SCM and PDM/SCM integrated functionalities, in the proposed database model. In Section 4.2 we will further discuss the model. As we have discussed in the introduction section, the proposed PDM/SCM system ought to provide both PDM and SCM functionalities respectively. In addition, the system should manage the collaborations, of both hardware and software engineers, for the hardware engineer
software engineer
common user interface PDM app.
Collaboration app.
SCM app.
PDM/SCM applications
utility functions PDM/SCM database model
PDM/SCM database
PDM/SCM unified database
Fig. 3. The main components of the PDM architecture.
857
product configuration and engineering change management, which are indispensable elements of the current collaborative product development process. In order to realize the functionalities, the architecture classifies the PDM/SCM applications into the following three categories: the PDM, the SCM, and the collaboration applications (see the PDM, the SCM and the collaboration applications in Fig. 3). The PDM and the SCM applications access and manage their data receptively, providing their own independent functionalities to either hardware or software development. The collaboration applications access both the PDM and SCM data, in the database, through the integrated database model. The applications handle this data, for supporting collaborations among hardware and software engineers during product configuration or engineering change management. The utility functions are common tools for supporting operations of PDM, such as access controls, communication between users, and data interfaces (see the utility functions in Fig. 3). Both hardware and software engineers alike, have access to the applications and databases through the common user interface to the system (see the common user interface in Fig. 3). Providing the common user interface, leverages the benefits of the unified database to the collaboration. Both hardware and software engineers can share the unified database through the common user interface, which extends the current user environment provided by the PDM clients. Since most PDM clients provide interfaces to external applications, software engineers can easily add their SCM utilities or application programs to the common user interface. 4.2. PDM/SCM database model 4.2.1. Extended document management The PDM/SCM database model, being based on the existing PDM standard, needs to create new types of entities and associated operations for supporting version management of software items. As we mentioned in Section 3.2, the version management in SCM needs different operations from that of PDM. These differences include branch/merge and comparisons of their source codes. In order to support the version management of SCM based on the PDM database model, the database model provides data entities for the software products and associated documents with the branch/ merge and code comparison operations. The software product entity can also store rich meta data for software items, since it uses an extended product object that can manage various meta data. Existing SCM systems manage only source code files with only a few additional attributes. Fig. 4 shows the extended STEP PDM Schema, that represents the product and associated document, of the PDM/SCM database model in EXPRESS-G notation [13]. The PDM/SCM database model extends the ‘sw_document’ entity from the ‘document’ entity in the STEP PDM Schema, which contains the SCM operations for source code management. Since the product concept in the STEP PDM schema represents not only the end product, but also subcomponents of the end product, the model shares the ‘product’ entity to represent software items of SCM. If the software items need additional attributes, the ‘product’ entity can extend its set of attributes for the purpose, creating its sub-entities. Based on the ‘product’ entity, the ‘product_definition_formation’ entity represents version information of the product. The ‘product_definition’ entity represents application views of the product (see the ‘product’, the ‘product_definition_formation’ and the ‘product_definition’ entities in Fig. 4). The STEP PDM Schema regards the document as a product in representations, so that the product with its view and version entities, can represent the document. The ‘document_product_equivalence’ entity in Fig. 4, shows that the document is represented by the product related entities.
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
858
Id
document product
Id name
releating _document
sw_document
of_product product_document _equivanlance
assigned _document
applied_document _reference
related _product
product_definition _formation
items[1:?] product_definition
id
formation product_definition_with _associated_document
id documentation _ids[1:?]
Fig. 4. The PDM/SCM database model implementing the extended document management. Modified from [12].
The association relationship between a product, and related documents, is specified with the ‘applied_document_reference’ entity. The entity associates the ‘product_definition’ entity (a view of a product) with the ‘document’ entity. The software product will associate a specific type of documents for managing software source codes, the ‘sw_document’ entity, a sub-entity of the ‘document’ entity. It inherits all of the attributes and relationship of the super entity, the ‘document’ entity (see the ‘sw_document’ entity in Fig. 4), while additionally containing special SCM operations, the branch, merge and comparison operations. The STEP PDM schema and the EXPRESS (a formal specification language in the STEP standard), fail to have notations for specifying the member operations of an entity. Therefore, we will describe the SCM applications that represent the SCM operations in Section 4.3. 4.2.2. Extended product configurations and engineering changes In order to support meaningful collaborations between different disciplines, design management systems ought to allow participating engineers, from different disciplines, to share the integrated and consistent product configuration and engineering change data, during their collaborations. This is because the product configuration and engineering change management in the product development process, gather all product data from different stakeholders for the development. In addition, they are integrated by the management as official and sharable product specifications, across the company. This section shows how the PDM/SCM database model supports the consistent product configuration and engineering change data for the collaborations of hardware and software development. Engineering changes generate different product structure of the same product, and the differences between each product structure represent a history of the changes. In hardware development, product variants can specify the history of engineering changes, by validating specific product structure with the effectivity data. The effectivity data, accompanied with the modules of product structures, also have the ability to determine product structures for a specific product configuration. Therefore, if a system can support effectivity data, determining both hardware and software products within a specific product structure, it can provide proper product data for product configurations. It also has the ability to provide engineering change management, during the collaborations among hardware and software development.
As we mentioned in Section 3.3, the PDM/SCM database model extends the application of the effectivity data to the document objects of the software products. Through identical effectivity specification, the extension allows hardware and software engineers, or the collaboration applications, to select product structures containing both hardware and software products. This enables all participating engineers to collaborate, based on the same product configurations, in addition to engineering changes. Fig. 5 shows entities of the PDM/SCM database model for product configurations, which extends a part of the STEP PDM Schema [12]. The model supports product configurations with the ‘configuration_item’ and the ‘configuration_design’ entities, as well as the ‘effectivity’ and the ‘applied_effectivity_assignment’ entities. The ‘configuration_item’ entity provides identifiers of each product configurations, while the ‘configuration_design’ entity, associates product configurations with participating products represented with the ‘product_definition_formation’ entity (see the ‘product_definition_formation’ entity in Figs. 4 and 5). The effectivity can be specified on the ‘configuration_design’ entity through its ‘configuration’ attribute. It can be additionally applied on the ‘product_definition_relationship’ entity, of which inheritance hierarchy contains the ‘next_assembly_usage_occurrence’ entity. The ‘next_assembly_usage_occurrence’ entity is used for expressing the product structure between versions of the products in the STEP PDM Schema. In order to expand applications of effectivity data, to documents, as we mentioned in Section 3.4, the ‘effectivity_items’ entity should contain the ‘applied_document_reference’ entity in its inheritance hierarchy. This represents association relationship between products and linked document objects (see the ‘applied_document_reference’ entity in Fig. 4). Therefore, we add the ‘applied_document_reference’ entity as a sub-entity of the ‘effectivity_items’ in Fig. 5 (see the gray colored entity in the figure). Fig. 6 shows how to specify product configurations and engineering changes, which have both hardware and software products, with one simple example. At the beginning of the product structure, the product configuration, ‘config A’, has a hardware product, ‘part 10 A’, and a software product, ‘part 20 A’. The software product associates a document instance, ‘doc 10’, as it’s managed source code item. The initial effectivity data, the ‘1–current’ (meaning that it is valid through the 1st product to the current product) can be instantiated with the effectivity entity, and
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
id purpose name
configuration_item
859
usgae effectivity
assigned _effectivity
configuration configuration_design configuration
applied_effectivity _assignment Items[1:?]
design
effectivity_items
product_definition _formation
product_definition
applied_document _reference
product_definition _relationship
next_assembly_usage _occurrence Fig. 5. The PDM/SCM database model implementing the product configurations and effectivity data. Modified from [12].
links the constituent relationship, associating the ‘config A’, the ‘part 10 A’ and the ‘doc 10’ of the ‘part 20 A’. The product needs an engineering change that replaces the ‘part 10 A’ and the ‘doc 10’, with the ‘part 10 B’ and the ‘doc 20’, respectively. The engineering change alters the product structure with updated effectivity ‘1–99’ and new effectivity ‘100–current’. There are constituent relationships between the ‘config A’, the ‘part 10 B’, and the ‘doc 20’ of the ‘part 20 A’ (see the product structure and effectivity data in Fig. 6). Fig. 6 shows how to determine the valid hardware and software versions in the product structure of the ‘config A’, through the effectivity data, which has 95 as its value. The effectivity condition can be interpreted as, selecting a product structure for the product, which has a serial number 95 (or the 95th product). The thick lines in Fig. 6 show the result of the selection. The version of the hardware product, ‘part 10 A’, is selected by the effectivity data on product structure, between the configuration and the products (see the effectivity data specified on product structures in Fig. 6) seeing as the effectivity condition validates the product structure (1 < 95 < 99). The software versions, associated with the hardware Effectivity = 95 config A
100-current
4.3. The PDM, SCM and collaboration applications
1-99 1-current
part 10 A
part 10 B
part 20 A
doc 10
products, can be determined with the effectivity data, specified on the documents attached to the software products (see the ‘doc 10’ in Fig. 6). Subsequently, the engineers can determine the valid versions of hardware parts and software source codes, through the product structure selection. The example products and their versions, along with the associated documents, can be represented with the product and document related entities in Fig. 4. The product structures and applied effectivity data, can be instantiated with entities specified in Fig. 5. The appendix specifies the instance model for the example (after the engineering change) in STEP Part 21 format [14], which shows that the PDM/SCM database model can represent the data structure for version items of the software products and product selections for both hardware and software products. As a result, we found the STEP PDM schema is expressive enough to represent almost all the data structure needed for the PDM/SCM database model. However, it doest not provide the SCM operations on software products and extended effectivity data specified on relationship between products and associated document objects. As we mentioned on the ‘sw_document’ entity and effectivity application cases, the database model ought to extend the STEP PDM schema with the operations and new sub entity for the effectivity applications.
doc 20
Fig. 6. An example instantiation of the PDM/SCM database model.
4.3.1. The SCM applications The SCM applications enable software engineers to manage their software versions, within the same PDM system as product data is managed by hardware engineers. A software engineer can launch the SCM application on a software product, in the PDM client. The client serves as the default user environment of the PDM system, which is also used by the hardware engineers. The SCM application, lists all the documents containing version items of software source codes of the target software product. Furthermore, this application provides a user environment for the basic SCM operations. The software engineer can apply the SCM operations including revision, branch/merge, comparisons and version up, on the version items in the list provided by the application.
860
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
Fig. 7. Product configurations and assembly modules of the example product.
4.3.2. The collaboration applications In order to provide integrated product configurations and engineering changes for hardware and software development, the collaboration applications ought to support configuration selection functionality. This should be supported as a basic operation for the collaboration applications, which can determine both hardware and software products. The implemented system provides extended configuration selections based on the PDM/SCM database model for product configurations and the engineering changes. A product engineer, who is concerned with whole Product Data Management, including hardware and software, can select specific product structures from the PDM/SCM database, through specifications of effectivity data. By using the extended configuration selection functionality, the user can select a specific product structure for a product configuration or an engineering change history, which contains both hardware and software products. The selected product structure contains both hardware products, as well as specific version items of software codes, managed by document objects of selected software products. Therefore, the configuration selection operation can be used to manage a specific product configuration, consisting of both the hardware and
software parts. This operation also has the ability to manage engineering changes, involving both hardware and software changes, during collaborations between hardware and software development. 5. Implementation of the architecture We have implemented the proposed PDM/SCM architecture, based on a commercial PDM system, Dassault Systems Enovia SmarTeam [15]. The database model is translated to the PDMs database schema and the SCM and collaboration applications are developed by using utilities and API libraries supported by the PDM system. Since general PDM applications are provided by the PDM system, this section will describe only the SCM and collaboration applications developed based on the PDM database. We have developed a robotics system based on the implemented PDM/SCM architecture. Fig. 7 shows the product configurations and assembly product structure of the robotics example. It has two product configurations, the ‘Argos Type 1S’ and the ‘Argos Type 1D’, which select specific components from the several different modules. The modules consist of five hardware modules
Fig. 8. Selection of a specific hardware and software product structure with effectivity data.
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
861
Fig. 9. Windows of configuration selections for the hardware and software integrated products.
(from the ‘Web CAM’ to the ‘Double Bumper’ in Fig. 7) and two software modules (the ‘Software Single Bumper’ and the ‘Software Double Bumper’). The hardware modules have assembly parts and effectivity data specified on the product structure. The software modules have software parts that contain the source codes in their
document objects. The software parts represent the control software for the sensors and actuators of the robotics system. Fig. 8 shows how to determine the valid hardware and software versions in product structure of the ‘Argos Type 1S’ through the ‘2010.1.13’ effectivity data. The thick lines and arrows in Fig. 8
Fig. 10. Windows of SCM operations on the documents of the software part.
862
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
show the result of the selection. The versions of the hardware part under the modules of the ‘Argos Type 1S’ are specified by effectivity data on product structure between the assembly parts and the modules (see the effectivity data bubbles on the product structure in Fig. 8). The software versions under the same effectivity data can be determined with effectivity data specified on the documents attached to the software parts. Then product engineers can determine the valid versions of hardware parts and software source code for the ‘2010.1.13’ effectivity data through the product structure selection. Fig. 9 shows how designers can select the product structure with the collaboration application implemented based on he proposed architecture. The configuration selection window in Fig. 9 shows the selection of the product configuration with four hardware and one software modules through the ‘2010-01-13’ effectivity data. The selected software module, the ‘PO0000001_SW Single Bumper’, has three software parts with specific version of source codes, ‘Main Singe Bumper’, ‘Head Track’, and ‘Escape_0.1’, which implement the behavior of autonomous obstacle avoidance of the robotic system. Fig. 10 shows windows of the SCM application during a merge operation on software version items. It manages source code of the ‘Escape’ program selected in the configuration selection application in the same PDM client shared by hardware engineers. 6. Conclusion In order to satisfy the needs of the current hardware and software integrated product development, this paper proposes a PDM architecture that can manage both hardware and software development based on an integrated product data model. The proposed architecture consists of two main components: the unified PDM/SCM database and the PDM, SCM and collaboration applications based on the database. To allow the unified database to manage all the data used for PDM and SCM, the database model specifies data entities, and their relationship, for hardware and software products. To take advantages of the existing standard PDM data model, the database model extends the STEP PDM Schema, representing product data for PDM and SCM. It also extends the standard data model, to support SCM operations, in the same database that hardware engineers can share for their product development. By extending the application of effectivity data to document objects, of software products, and synchronizing them with hardware products, the database model enables engineers in collaborations, to manage both hardware and software products during the product configuration and engineering change management. The architecture provides independent PDM and SCM applications that support hardware and software development, respectively. However, since the database manages both PDM and SCM data, the architecture can base the heterogeneous applications on a unified database, containing an identical user environment. In addition, it can support the collaboration applications that access and control, both hardware and software data, on the view of integrated product model during product configuration and engineering change management. While the PDM and the SCM applications support hardware and software engineers to manage their own development, the collaboration applications allow the engineers to verify their comprehensive design works, by integrating them into the same product configurations and engineering changes. This paper proposed a unique product data model that can represent two different disciplines, PDM and SCM, based on international product data standards. It also supports the product configuration and engineering change management for the
integrated product development. The implication of the paper to industry is that the architecture can be implemented with the current commercial PDM systems. The prototype implementation in the paper showed the possibilities of the architecture. These can satisfy the needs of integrated hardware and software development, without problems or errors from inconsistent product data and heterogeneous user environments.
Appendix A. STEP P21 specifications for the example in Fig. 6 /* config A */ #10 = configuration_item(‘config A’, ‘a product configuration’, ‘config A’); /* part 10 A */ #100 = product(‘part 10’, ‘part 10’); #110 = product_definition_formation(‘A’, #100); #120 = product_definition(‘AS DESIGN’, #110); /* part 10 B */ #130 = product_definition_formation(‘B’, #100); #140 = product_definition(‘AS DESIGN’, #130); /* part 20 A */ #200 = product(‘part 20’, ‘part 20’); #210 = product_definition_formation(‘A’, #200); #220 = product_definition(‘AS DESIGN’, #210); /* constituent relationship between ‘config A’ and ‘part 10 A’, ‘part 20 A’, ‘part 10 B’*/ #1000 = configuration_design(#10, #110); #1010 = configuration_design(#10, #210); #1020 = configuration_design(#10, #130); /* doc 10 */ /* representing document file */ #30 = document_file(‘doc10.prg’); /* representing the document object ‘doc 10’ */ #300 = product(‘doc 10’, ‘document 10’); #310 = product_definition_formation(‘001’, #300); #320 = product_definition_with_associated_document(‘AS DESIGN’, #310, (#30)); /* equivalence the product definition formation ‘doc 10’ to the document ‘doc 10’ */ #330 = document(‘doc 10’); #340 = document_product_equivalence(#310, #330); /* relationship between the product definition ‘part 20 A’ with the document ‘doc 10’ */ #350 = applied_document_reference(#220, (#330)); /* doc 20 */ /* representing document file */ #40 = document_file(‘doc20.prg’); /* representing the document object ‘doc 20’ */ #400 = product(‘doc 20’, ‘document 20’); #410 = product_definition_formation(‘001’, #400); #420 = product_definition_with_associated_document(‘AS DESIGN’, #410, (#40)); /* equivalence the product definition formation ‘doc 10’ to the document ‘doc 10’ */ #430 = document(‘doc 20’); #440 = document_product_equivalence(#410, #430); /* relationship between the product definition ‘part 20 A’ with the document ‘doc 10’ */ #450 = applied_document_reference(#220, (#430)); /* representing the effectivity data */ #910 = effectivity(#1000, 1, 99,’’);/* config A – part 10 A */ #920 = effectivity(#1010, 1, CURRENT,’’);/* config A – part 20 A */ #930 = effectivity(#1020, 100, CURRENT,’’);/* config A – part 10 B */ #940 = effectivity(’’, 1, 99,’’);/*for part 20 A – doc 10 */ #945 = applied_effectivity_assignment(#940, (#350)); #950 = effectivity(’’, 100, CURRENT,’’);/* for part 20 A – doc 20 */ #955 = applied_effectivity_assignment(#950, (#450)); /* EOF */
N. Do, G. Chae / Computers in Industry 62 (2011) 854–863
References [1] J. Estublier, J.M. Favre, P. Morat, Toward SCM/PDM integration, in: System Configuration Management, SCM-8, Lecture Notes in Computer Science, No. 1439, Springer, 1988, pp. 75–94. [2] B. Westfechtel, R. Conradi, Software configuration management and engineering data management: differences and similarities, in: SCM-8, Lecture Notes in Computer Science, No. 1439, Springer, 1998, pp. 96–106. [3] I. Crnkovic, U. Asklund, A.P. Dahlqvist, Implementing and Integrating Product Data management and Software Configuration Management, Artech House Publishers, 2003. [4] A.P. Dahlqvist, C. Ivica, M. Larsson, Managing complex systems – challenges for PDM and SCM, in: 23th ICSE, Toronto, Canada, 2001. [5] T. Krebs, L. Hotz, A. Gunter, Knowledge-based configuration for configuring combined hardware/software systems, in: PuK 2002, 2002. [6] T. Krebs, K. Wolter, L. Hotz, Trends model-based configuration support for product derivation in software product families, in: PuK 2005, 2005. [7] J. El-Khoury, Model data management – towards a common solution for PDM/ SCM system, in: ACM 2005, Lisbon, Portugal, September 5–6, 2005. [8] SIEMENS PLM Software, SIEMENS TeamCenter Engineering, http://www.plm. automation.siemens.com/en_us/products/teamcenter/index.shtml, accessed 12 December, 2009. [9] PTC, PTC WinChil, http://www.ptc.com, accessed 12 December, 2009. [10] CIMdata, PDM: The Definition, CIMdata Report, 1997. [11] T. Mannisto, T. Soininen, R. Sulonen, Configurable software product families, in: ECAI 2000 Configuration Workshop, 2000. [12] PDM Implementer Forum, Usage Guide for the STEP PDM Schema V 1.2, PDM Implementer Forum, 2002. [13] ISO, ISO 10303-11:2004 Industrial Automation Systems and Integration – Product Data Representation and Exchange. Part 11. Description Methods: The EXPRESS Language Reference Manual, ISO STEP, 2004. [14] ISO, ISO 10303-21:2002 Industrial Automation Systems and Integration – Product Data Representation and Exchange. Part 21. Implementation Methods: Clear Text Encoding of the Exchange Structure, ISO STEP, 2002.
863
[15] Dassualt Systems, Dassault Systems Enovia SmarTeam, http://www.3ds.com/ products/enovia/mid-market/smarteam-engineering-express/overview/, accessed 12 December, 2009. Namchul Do has a B.S., a M.S. and a Ph. D. in Industrial Engineering from Pohang University of Science and Technology (POSTECH), Pohang, Korea. Do is currently an associate professor of industrial and systems engineering department at Gyeongsang National University in Korea. He conducts research on product data models for engineering change propagations, rulebased product configurations, integration of product data management (PDM) and software configuration management (SCM), and sustainable product development. He also has co-worked on PDM research and applications with several leading Korean institutes and companies. He is the author of ‘‘An introduction to Product Lifecycle Management (PLM) and its applications’’ (Saengneung Press, 2007, in Korean). In the book, he documented his industrial experiences on PLM in Samsung Heavy Industries and Volvo Construction Equipments Korea and result of government research projects on Collaborative Product Commerce in ETRI. Gyoengseok Chae was received the B.S (2006) and M.S. (2008) in Industrial Engineering from Gyeongsang National University in Korea. His research interests include product database modeling, PDM application development and engineering change management.