Sylvain Kubler

Andréa Buda

Jérémy Robert

Kary Främling

Yves Le Traon

Building Lifecycle management System for Enhanced Closed Loop Collaboration

Keywords: Product Lifecycle Management, Internet of Things, Building lifecycle management, Interoperability, Quality Function Deployment

In the past few years, the architecture, engineering and construction (AEC) industry has carried out efforts to develop BIM (Building Information Modelling) facilitating tools and standards for enhanced collaborative working and information sharing. Lessons learnt from other industries and tools such as PLM (Product Lifecycle Management) -established tool in manufacturing to manage the engineering change process -revealed interesting potential to manage more efficiently the building design and construction processes. Nonetheless, one of the remaining challenges consists in closing the information loop between multiple building lifecycle phases, e.g. by capturing information from middle-of-life processes (i.e., use and maintenance) to re-use it in end-oflife processes (e.g., to guide disposal decision making). Our research addresses this lack of closed-loop system in the AEC industry by proposing an open and interoperable Web-based building lifecycle management system. This paper gives (i) an overview of the requirement engineering process that has been set up to integrate efforts, standards and directives of both the AEC and PLM industries, and (ii) first proofs-of-concept of our system implemented on two distinct campus.

Introduction

Building Information Modeling (BIM) is not a new concept, but rather one that is playing an increasingly larger role in the architecture, engineering and construction (AEC) industry. From design to construction, the concept of BIM has been a feature across many industries for nearly 30 years [START_REF] Succar | Building information modelling framework: A research and delivery foundation for industry stakeholders[END_REF]. It remains a strong and important player in the field because of its ability to allow designers to go beyond representing the physical space of a new or retrofitted building to the intrinsic properties of the structure as well. BIM is not just about the design of new buildings, it also plans for years of use. This is because designing, scheduling, constructing and evaluating a building is done in the BIM model long before any construction actually takes place. Although it is true that the future of the construction industry is digital and that BIM facilitating tools and standards (e.g., IFC) will foster long-term facility management, there are still technological and managerial challenges ahead [START_REF] Azhar | Building information modeling (BIM): Now and beyond[END_REF]. The nature of these challenges depend on the building lifecycle, which is generally defined as a three-phase process [START_REF] Dave | Opportunities for enhanced lean construction management using Internet of Things standards[END_REF]: (i) Beginning-of-Life (BoL) including design, manufacture and construction of the building; (ii) Middle-of-Life (MoL) including its use and maintenance; and (iii) End-of-Life (EoL) including its disposal and recycling. Our research puts special emphasis on post construction challenges.

One of the major challenges after the delivery of the building (i.e., when starting MoL) lies in the difficulty to close the information loop between all phases of the building lifecycle. For example, due to the lack of system integration and other factors such as the non-maturity of the IoT (Internet of Things), it is not that easy to collect, capitalize, and share information/knowledge acquired from MoL (e.g., during use and maintenance activities) with other building lifecycle stakeholders, and vice-versa [START_REF] Främling | Universal messaging standards for the IoT from a lifecycle management perspective[END_REF]. This is all the more important since such information could result in enhanced decision-making in BoL (e.g., to improve the next generation of buildings and boost the innovation process by capturing new business and user needs), or in EoL (e.g., to guide decision-making about the reuse of components by having information related to the building use conditions). The establishment of such a closed-loop information/collaboration structure throughout the asset lifecycle is not only facing the AEC industry but other sectors, too, e.g., manufacturing where concepts such as Closed-loop PLM1 [START_REF] Kiritsis | Closed-loop PLM for intelligent products in the era of the Internet of Things[END_REF][START_REF] Jupp | Similar concepts, distinct solutions, common problems: learning from PLM and BIM deployment[END_REF] emerged over the last decade.

Given the above, the contribution of our work is twofold: (i) design/develop an open & interoperable building management system that integrates efforts, outcomes (technologies, standards...) and directives of both the AEC industry and adjacent sectors such as Closed-loop PLM and IoT; (ii) set up an effective and evolutive requirement engineering framework for ensuring successful system component development. Sections 2 and 3 deal respectively with these two contributions, Section 4 presents proofs-of-concept of our system, conclusion follows.

2

When BIM meets Closed-loop PLM

The differences between BIM and PLM chiefly surround their capacity for technical and organizational integration. However, they both share a number of similarities relative to their approach to data sharing and project management activities [START_REF] Kiritsis | Closed-loop PLM for intelligent products in the era of the Internet of Things[END_REF]. Although there is only a few documented efforts of implementing PLM in AEC companies, the challenges that follow on from these shared characteristics may provide fertile grounds for sharing lessons learned. Section 2.1 focuses on BIM throughout the building lifecycle, while giving insights into current Closed-loop PLM research and practices. Against this background, section 2.2 discusses the importance of having accurate requirements to transfer those practices to the AEC/BIM industry, and how this can be achieved using an evolutive requirement engineering framework.

Whole lifecycle approach

Managing vast amounts of disparate information throughout an asset lifecycle (car, airplane, building...) is an enormous challenge for organizations, particularly in terms of enforcement and compliance. Information governance enforces desirable behavior in the creation, use, archiving, and deletion of corporate information. By closing the loop, rules and policies are defined, policies are managed and enforced, authorized records are accessed when and as needed, and metrics are available to audit the current rules and policies. All this provides a way to continuously assess and update the process for optimum results. Unlike this vision has been widely explored in PLM, it has only been in the last 5 to 7 years that an increasing focus on the application of BIM throughout the whole building lifecycle has emerged, and the significance of business process integration been acknowledged [START_REF] Kiritsis | Closed-loop PLM for intelligent products in the era of the Internet of Things[END_REF]. BIM servers are now being developed to provide a large integrated data-and knowledge-base that can be leveraged not only in design and engineering, but also in construction operations (BoL), facilities maintenance (MoL), and disposal activities (EoL) [START_REF] Dave | Opportunities for enhanced lean construction management using Internet of Things standards[END_REF]. Such a building lifecycle's vision is depicted in Fig. 2, where research efforts are increasingly focused on "closing the loop" to foster collaborative processes, shared resources and decisionmaking [START_REF] Aram | Integration of PLM solutions and BIM systems for the AEC industry[END_REF]. Although some challenges remains to be addressed in BoL, the major challenge in the context of 'closed-loop' information starts from the delivery of the building, where BIM and other BoL models fall into oblivion. This means that all the knowledge generated in BoL is not, or at least cannot easily be re-used in MoL and EoL, while some reports highlight substantial profits that could accrue from such information loops [START_REF] Jupp | Similar concepts, distinct solutions, common problems: learning from PLM and BIM deployment[END_REF]; for example, Barlish and Sullivan highlight the fact that 85% of the lifecycle cost of a facility occurs after construction is completed [START_REF] Barlish | How to measure the benefits of BIM -A case study approach[END_REF] and, in this respect, that using BIM-related information in downstream processes could help to save money.

As mentioned above, the concept of closed-loop PLM (or CL2M) has developed theories and tools to enable closing the information loop between multiple lifecycle phases [START_REF] Laplante | Requirements engineering for software and systems[END_REF][START_REF] Främling | Sustainable PLM through intelligent products[END_REF]. This concept emerged from the PROMISE EU FP6 project, where real-life industrial applications required the collection and management of product instance-level information for many domains involving heavy and personal vehicles, household equipment, etc. Information such as sensor readings, alarms, assembly, disassembly, shipping event, and other information related to the entire product lifecycle needed to be exchanged between products and systems of different organizations. Based on the needs of those applications, requirements for data exchange were identified and, as no existing standards could be identified that would fulfill those requirements without extensive modification, new messaging interfaces were proposed (see e.g. [START_REF] Främling | Sustainable PLM through intelligent products[END_REF]). Those specifications have since then been further developed by the IoT WG of The Open Group and implemented by several EU project consortia (e.g., LinkedDesign FP7, bIoTope H20202 ). Recently, The Open Group published those specifications as two distinct -but complementary -standards, namely the Open Messaging Interface (O-MI) and Open Data Format (O-DF) standards [START_REF] Främling | Sustainable PLM through intelligent products[END_REF].

Our research work and contribution originate from this state-of-the-art with the specific aim of developing a user-friendly building lifecycle management system relying on open and interoperable standards like O-MI/O-DF. To this end, it is of the utmost importance to select and/or set up an effective and evolutive requirement engineering framework for the development of successful system components, especially in new and cross-domain contexts, as is the case in our study (combination of standards/directives from the AEC/BIM and Closed-loop PLM & IoT sectors). The next section briefly discusses such a requirement engineering framework.

Requirement engineering framework

Accurate requirements provide the foundation for successful product development. Three main steps can be identified in requirements engineering [START_REF] Popescu | Home "Smartness"-helping people with special needs live independently[END_REF]:

1 Requirements inception: start the process (business need, market opportunity…); 2

Requirements management: to capture new needs/contexts over time.

In our context, customer needs must be transferred into product and process requirements without necessarily developing all possible technical characteristics, but only the ones that fulfil the needs for efficient closed-loop information and collaboration in a building's lifecycle context. Let us add that the production activity is supposed to be traceable back at least indirectly to customer requirements.

Given this, our research work develops an hybrid framework based on the synthesis of well established techniques from software engineering and management theory and tools [START_REF] De Gea | Requirements engineering tools: Capabilities, survey and assessment[END_REF]. An overview of this hybrid engineering framework is provided in Fig. 2, which combines (i) a functional analysis (using the Octopus diagram); (ii) a requirement prioritization technique (using AHP -Analytic Hierarchy Process) [START_REF] Succar | Building information modelling framework: A research and delivery foundation for industry stakeholders[END_REF]; (iii) a method that transforms prioritized requirements into quantitative parameters/specifications (using QFD -Quality Function Deployment) [START_REF] Chan | Quality function deployment: A literature review[END_REF]; and (iv) a spectral algorithm method for clustering specification conflicts identified through the QFD matrices [START_REF] Atkins | A spectral algorithm for serialization and the consecutive ones problem[END_REF]. These phases are followed up by the software development phase, as well as the definition of KPIs (key performance indicators) to assess whether the system is free of defects, meets the user needs that may evolve over time, and so on. In the context of smart buildings, similar approaches for the development of smart home components was followed, e.g. Durrett et al. [START_REF] Durrett | A hybrid analysis and architectural design method for development of smart home components[END_REF] used QFD to effectively satisfy customers' needs as part of an integrated smart home environment. Popescu et al. [START_REF] Saaty | The Analytic Hierarchy Process[END_REF] used QFD combined with AHP to identify a set of functions of lighting, heating, security, furniture, etc., that could have a critical contribution to the independent living capacity of people with special needs, if receiving smart abilities. However, none of these frameworks and analyses consider needs related to the whole building lifecycle, along with the imperative to enable closed-loop information and collaboration among distinct lifecycle stakeholders. As a consequence, an appropriate hybrid engineering framework that enables to integrate such needs, and appropriate technology enablers from the AEC and PLM industries, is defined and proposed in this study, as will be discussed in section 3.

A hybrid engineering framework for development of building lifecycle management system components

As previously stated, and depicted in Fig. 2, our framework starts with a functional analysis using the Octopus diagram that identifies the Primary Functions (denoted PF) as well as the Constraint Functions (CF) between the system to be developed and its environment (e.g., actors, directives, services, etc.). Fig. 3 provides insight into the Octopus diagram related to our building lifecycle management system, where the different PF and CF functions are further described in Table 2. Based on these PF and CF functions, high-level requirements are formulated in the form of a hierarchy representing distinct categories (e.g., CF2, CF3 and CF5 falls within the scope of "Building lifecycle"-related requirements, etc.). Due to space limitation, the final requirement hierarchy is not presented in this paper, but a first insight into the categories are illustrated through the Octopus's color code in Fig. 3.

There are number of software requirements prioritization techniques, but according to a recent survey [START_REF] Achimugu | A systematic literature review of software requirements prioritization research[END_REF], AHP is the most widely used technique. Although we do not present the AHP process in this paper, one should know that AHP provides -as output -the list of requirements ranked in order of priority. Such a requirement ranking, associated with the priority weights, are used as input of the QFD. QFD is both a requirement definition and conceptual design tool that systematically documents customer needs, benchmarks, competitors, and other aspects, and then transforms the list of prioritized requirements into design specifications. The QFD methodology flow involves four basic phases that occur over the course of the product development process. During each phase one or more matrices are generated (cf. block in Fig. 2 entitled "Turning initial requirements into specifications using QFD"), where the specifications (including their respective weight) resulting from the QFD matrix of phase n feed the matrix of phase n + 1. Fig. 3 provides insight into the specifications resulting from the first QFD matrix, which all bring first technological or scientific enablers to fulfil one or more requirements. For example, Fig. 3 shows that the two most important enablers with respect to our initial requirements are (i) Data & service discovery: to enable any building stakeholder to discover and access, when and as needed, information sources and associated knowledge; (ii) Dynamic service composition: to enable building end-users to create their own services using a portfolio of "processing blocks" (including diagnosis, maintenance prediction, event-detection, storage…).

As highlighted in our requirement engineering flow (see Fig. 2), a spectral method for clustering conflicts that arise from the QFD matrices' roof3 is further applied, followed up respectively by a validation phase of the specifications and the development of the software components. To guarantee that our system remains competitive over the short and long term, specific Key Performance Indicators (KPIs) are defined to assess in a quantitative manner several aspects such as the software bugs, the user satisfaction and new needs, etc. Although not presented in this paper, it is important to note that these KPI metrics continuously feed the QFD matrices (see Fig. 2), thus helping to produce new releases of the system/software with added or rectified features.

Proof-of-concept -Building Lifecycle Management System

The first releases of our building lifecycle management software have been supplied 4 , enabling any developer to deploy and instantiate it in his/her own environment/buildings. Two proofs of concept of such an instantiation are today available online, namely in Aalto University 5 and Luxembourg University 6 .

Fig. 4 provides screenshots of the web-based dashboard that any building enduser/stakeholder can access and use as they see fit. First, stakeholders are able to discover (in a city or region) all the buildings that are compliant with our system, or more specifically compliant with the IoT standards used for data exchange (i.e., O-MI/O-DF in our case). The discovery can be achieved both in a visual manner (Google Map, as shown with the dashboard view denoted by 1 in Fig. 4) or automated manner (using the RESTful discovery mechanism supported by O-MI, see e.g. [START_REF] Främling | Universal messaging standards for the IoT from a lifecycle management perspective[END_REF]). From this stage, the stakeholder can access both the Floor/2D model (see arrow denoted by 2) as well as the 3D model of the building (see arrow denoted by 3). Those views have been directly generated using -as input -the integrated BIM/IFC file, which is now able to be enriched with live sensor data, e.g. the room "Cafeteria" collects Co2, Humidity, Occupancy and Temperature sensor data. Along with this 2D/3D views, another view -a 360 's picture of the room (see arrow denoted by 4) -is supported wherein there is a twofold benefit (i) a building manager can notify the system that a new smart-connected object has been added, but also where it has been added in the room (e.g., a new smart coffee machine), but can also and foremost link the virtual sensor with the real-life information sources (i.e., physical sensors in this example); (ii) any end-user can see where the information source is located, which is a key contextual information that can be further used when developing additional services that rely on or use this information (e.g., if a sensor is located above an oven, the developer can identify it, integrate it to his/her knowledge, and handle it as needed). Finally, our system provides initial Analytics' services (see arrow denoted by 5) such as basic plotting of sensor data over a certain period of time regarding one or a group of rooms, but also more complex/cognitive services like the prediction of specific events (energy, failures, etc.). As a final step, we sum up in Table 2 the set of features -based upon the specifications resulting from the QFD matrix Level 1 (see Fig. 3) -that have been fulfilled in the first release of our building lifecycle management software (see column denoted "Today's System features" in Table 2), but also the ones that will be addressed through the H2020 bIoTope project and that will be integrated later on (next releases). It can be observed that, in this first software/system release, the specifications having received the highest priorities with respect to the initial requirements (note that the specifications in Table 2 are listed in order of priority).

Conclusion

It is still challenging to close the information loop between multiple building lifecycle phases (e.g., by capturing information and knowledge from MoL for reusing it in BoL and/or EoL processes), which opens up opportunities for enhanced decision-making and cost saving (e.g., in facilities management). Our research addresses this lack of closed-loop system by developing an open, interoperable and integrated Web-based building lifecycle management system that integrates efforts, directives and technological enablers from both the AEC and PLM/IoT. This paper gives insight into the requirement engineering framework that has been set up for the development of system components, as well as the first proofs-of-concept of the system implementation (running on two distinct campus).

Fig. 1 :

 1 Fig. 1: Building Lifecycle Management System combining BIM & adjacent sectors' efforts

  /otaniemi3d.cs.hut.fi/otaniemi3d/#/

Fig. 2 :

 2 Fig. 2: Evolutive requirement engineering framework for system development

Fig. 3 :

 3 Fig. 3: Illustration of a part of the requirement elicitation & specification steps

Fig. 3 :

 3 Fig. 3: Illustration of a part of the requirement elicitation & specification steps

Table 1

 1 Primary & Constraint Functions (PF-CF) formalized through the Octopus Diagram

This concept is also referred to as CL2M: http://cl2m.com

http://biotope-h2020.eu/

The QFD roof emphasis whether two specifications positively or negatively impact on each other.

https://github.com/AaltoAsia/Otaniemi3D

http://otaniemi3d.cs.hut.fi/otaniemi3d/

http://biotope.sntiotlab.lu:8080/html/snt3d/index.html

Acknowledgements. The research leading to this publication is supported by the National Research Fund Luxembourg (grant 9095399) and the EU's H2020 Programme (grant 688203).


Felix Nyffenegger
email: felix.nyffenegger@hsr.ch

Louis Rivest
email: louis.rivest@etsmtl.ca

Christian Braesch
email: christian.braesh@univ-smb.fr

Identifying PLM themes, trends and clusters through ten years of scientific publications

Keywords: Bibliometric analysis, PLM, Review, Mapping study, Trends, Overview

PLM encompasses a wide array of expertise, from designing green products to digital factories, with perspectives ranging from an IT standpoint to business strategies, encompassing products, processes and services. Hence, identifying the contours of PLM as a science through the themes, trends and clusters of its scientific literature is very challenging. At the same time, being able to portray PLM will benefit the PLM community, including researchers and practitioners, and should help foresee its future. This work examines PLM research bibliometric trends over the last ten years. We review the scientific literature published in English from 2005 to 2014 in peer-reviewed journals and conferences. Paper keywords are analyzed so as to identify trends and reveal the clusters of related themes based on the occurrences of words and the frequency of associations between them. Amongst the findings we observe that PLM coverage is both very large (2847 keywords being used over a decade) and very thin (2134 of these keywords appear only once in the decade). We also observe that the keyword showing the highest increase is Building Information Modeling (BIM).

Introduction

Product Lifecycle Management (PLM) has gained momentum over roughly the last 15 years, both in industry and in the research community. It can be stated that PLM encompasses a vast array of expertise, from designing green products to continuous manufacturing processes management, and that its perspectives range from Information Technology (IT) and Knowledge representation to Managementoriented works. This variety makes it challenging to define the contour of the very nature of PLM today and where it is headed.

This paper therefore presents a mapping of the PLM scientific literature published from 2005 to 2014 in peer-reviewed conferences and journals. It focuses on assessing a decade of PLM-related research work so as to establish a portrait of what themes and topics researchers have been working on over the last decade and detect underlying trends, if any. This paper also examines some clusters of themes and topics that are connected within PLM by studying the relationships between keywords found in the PLM literature. The first section reviews the literature relevant to our work. The methodology used for paper selection and the analysis technique are presented next, followed by the highlights of our findings. These findings are then analyzed and discussed, and we end with some conclusions and views on future work.

Related research

Kitchenham [START_REF] Kitchenham | The Value of Mapping Studies: A Participant-observer Case Study[END_REF] distinguishes systematic literature reviews from mapping studies. While the former aim at answering specific research questions, mapping studies are suitable to answer general questions, which are more relevant to research trends. Mapping studies aggregate and classify the relevant literature. One important factor for a mapping study is that a stringent search process be used.

Shepperd [START_REF] Shepperd | Combining Evidence and Meta-analysis in Software Engineering[END_REF] suggests elaborating systematic reviews in the following steps: problem formulation, locating evidence, appraising evidence quality, evidence synthesis and interpretation and lastly, reporting. Our working methodology implements all of these steps, as described below.

Aside from the scientific literature that may guide our work towards constructing a high quality mapping study, we also searched for general PLM literature reviews or state-of-the-art summaries, and found very few. Bhatt et al. [START_REF] Bhatt | Scientometric Study of Product Lifecycle Management International Conferences: A Decade Overview[END_REF] published a PLM review in 2015 identifying some of the most frequent PLM research themes, but it was limited to papers published in PLM International Conference (IC) proceedings.

In 2015, Varandas et al. [START_REF] Varandas Junior | Product life cycle management and product development: bibliometric analysis and literature classification[END_REF] published an analysis of PLM literature published from 2006 to 2010, with a focus on the concepts of Product Life Cycle Management, New Product Development, Environmental Sustainability and their interfaces (in Portuguese). Also in 2015, Mas et al. [START_REF] Mas | A Review of PLM Impact on US and EU Aerospace Industry[END_REF] published a review of PLM from the perspective of its impact on the aerospace industry in which they presented selected PLM topics from the developments in aerospace over roughly the last fifty years. Just a few years earlier (in 2013), Nappi and Rozenfeld [START_REF] Nappi | Sustainability performance indicators for product lifecycle management[END_REF] published a PLM literature review focusing on sustainability performance indicators.

Cao & Folan [START_REF] Cao | Product life cycle: the evolution of a paradigm and literature review from 1950-2009[END_REF] reviewed the evolution of Product Life Cycle literature from 1950 to 2009, showing how it led to PLM. In 2005, Ming et al. [START_REF] Ming | Towards Collaborative Innovation Via Product Lifecycle Management (PLM): Status Review and Technology Trend[END_REF] also presented a PLM review, which now dates back to over a decade. Some papers have promising titles but their contents do not help us in our work [START_REF] Laumond | Motion planning for PLM: state of the art and perspectives[END_REF], [START_REF] Antti | PLM state of the practice and future challenges in globally networked manufacturing companies[END_REF].

The excellent paper from Terzi et al. ( 2010) [START_REF] Terzi | Product lifecycle managementfrom its history to its new role[END_REF] shares some of our aims and describes the constituent elements of PLM, and classifies them into three fundamentals themes: information and communication technologies, business processes, and methodologies. The findings presented below could clearly be classified along the same lines.

None of the above-mentioned papers exposes global PLM themes, trends and clusters over the years through a systematic PLM literature review based on keywords analysis. Hence, this paper offers a unique, fact-based, perspective on PLM.

Our objective is to draw a general portrait of PLM scientific literature over the last decade. This general portrait is designed to:

 identify the major themes being studied in the PLM scientific literature, thereby revealing what researchers consider to be part of PLM science;  identify trends amongst these major themes so as to recognize both the 'rising stars' and those that are in decline over a ten-year period;  identify in what countries PLM research is being conducted and observe if this research effort is stable, declining or increasing, by country; and  identify clusters of ideas that are logically connected within the PLM domain. From there, we should be able to answer, in a next step, questions such as: is CAD (Computer-Aided Design), as a topic, at the heart of PLM? Is BIM (Building Information Modeling) equivalent to PLM but applied exclusively to construction?

The working methodology established to achieve our objectives is described in the next section.

Methodology

This study addresses trends in the research fields of PLM and its objectives have a general character. Thus a mapping study was selected as the general methodology to achieve our goal. As noted by Kitchenham [START_REF] Kitchenham | The Value of Mapping Studies: A Participant-observer Case Study[END_REF], particular care has to be taken with a proper selection process to identify the relevant literature and a well-defined and reliable classification system.

We should stress here that even though mapping studies traditionally include a step for the classification of the collected information based on the domain knowledge of experts, the working methodology adopted here avoids any such biased classification. Hence, the general steps suggested by Shepperd [START_REF] Shepperd | Combining Evidence and Meta-analysis in Software Engineering[END_REF] for unbiased evidence based studies were followed. The procedures and methods for locating evidence, appraising evidence quality and evidence synthesis and interpretation for this study are explained in the following sections.

For this initial study we decided that the entity of evidence is keywords. We argue that the authors are best qualified to explain their own work based on keywords and, thus, this is an adequate starting point to analyze what topics are being researched and how they are linked to each other. Keywords may be biased by trends or explicit calls for conferences. This effect should be considered when interpreting the results. In upcoming works, the analysis is planned to be extended to abstracts or even full paper texts, rather than keywords only; those efforts would more precisely reveal the publications' contents.

Paper selection was conducted in three steps. First, a set of selection criteria was established and appropriate databases were searched for relevant papers. The duplicates from different sources were identified and eliminated in the second step. In the third and final selection step, the publication guidelines of the corresponding journals and conferences of all the remaining papers were checked to assure an acceptable scientific standard. These criteria include a neutral (not vendor-influenced) publisher and a peer-review process.

The following selection criteria were used for paper selection: Criteria 6 implies that all papers included in our work could be said to be 'PLMtagged research'. Hence, papers that could have otherwise been classified as belonging to PLM because of their content, such as, for example, 'collaboration and interoperability in product development', were not included if they were not PLMtagged by their authors. As a consequence, all publications included in our analysis are considered as PLM-related by their authors. This is consistent with our intent to delineate the nature of PLM research.

Papers for this study were selected from four sources:  International Journal of Product Lifecycle Management (IJPLM);  Product Lifecycle Management International Conference (PLM IC);  Web of Science and Science Direct -These databases are two of the largest database for scientific publications. It can be emphasized that all the papers from the IJPLM and PLM IC satisfy all our criteria, even when a paper does not use PLM in its title or keywords. In addition, keywords added by editors had to be removed for our study, since our hypothesis is based on author's keywords.

Appraising and Improving Data Quality

Several steps were taken so as to appraise and improve the quality of our data. As mentioned above, we tried to execute these steps with a minimum of bias. Initially all records were captured into Zotero as a common literature database, where we could identify (and eliminate) duplicates. Next, data exporting was done in order to process the data. Finally, the processed data was merged into the final database with a schema that supports our analysis. The merging and creation of the final database was done automatically by an algorithm developed for that purpose. This algorithm follows the rules identified during the steps of metadata alignment, data enrichment and keyword normalization, as explained below. The automation of this process allows the full process to be repeated in the future, so as to easily include new publications and keep our database up to date.

The most critical step was normalization. The journal and proceedings names, and most importantly, the keywords had to be transferred into a normalized form. This transformation included some interpretation by the authors. However, we conducted this step following a clear set of rules.

 Metadata alignment -Metadata from the different sources needed to be aligned, so that equivalent fields of different records have the same meaning, such as, for example, a journal's name or the name of a conference.  Metadata enrichment -Since we aimed to offer a geographic perspective to our data, the publications needed geo location. Hence, each publication was tagged by the country of the first author's institution.  Normalization -A critical step in our analysis was the normalization: Each keyword was translated into a normalized form, so that keywords with the same meaning are unique. We needed to select and apply some rules for this process, including: o American English is chosen over Britain English (e.g. 'modelling' is normalized to 'modeling', 'visualisation' to 'visualization', etc.); o Plurals become singular except when a word is usually used in plural, such as 'logistics'; o Lifecycle is always written as one word. Particular care was spent on acronyms. The same acronym can have different meanings, and tracing back from the acronym to the correct keyword led at least to searching through a paper's abstract.

Synthesis and interpretation

An efficient method with which to present aggregated data from different perspectives and at different levels is necessary to allow its interpretation. At this stage we decided on three main perspectives: geographic distribution, a co-occurrence based keyword graph, and the trends of keywords based on their 10 years' of history.

Geographic distribution.

As mentioned above, during data quality improvement, we added a country of origin to each publication, according to first author affiliation. Hence, we can provide histograms showing the evolution of the number of publications per year per country over the selected ten-year period.

Building Clusters based on a Co-Occurrence Network. Co-occurrence networks are used to visualize the connections between concepts expressed by terms in text sources. In this context, co-occurrence is defined as the paired presence of two terms in a specified unit of text. Two co-occurring terms can be called "neighbors" and these are grouped into "neighborhoods" based on their interconnections.

In this study, two keywords become neighbors if they appear in the same publication. A co-occurrence network then helps to visualize the relationships between keywords and highlights clusters of keywords by identifying their neighborhood. As suggested by HuaJiao et al. [START_REF] Li | Evolutionary features of academic articles cokeyword network and keywords co-occurrence network: Based on two-mode affiliation network[END_REF], in our keyword co-occurrence network each keyword is represented by a node. The size of a node correlates to the number of total occurrences of a keyword in all publications. Co-occurrence relationships are represented as edges; hence the number of co-occurrences of a given pair of keywords influences the weight of this edge. McSweeney [START_REF] Mcsweeney | Gephi Network Statistics[END_REF] and the community around the graph visualization tool Gephi [START_REF] Heymann | Gephi Statistics[END_REF] discuss different alternatives to measuring the importance of a node in a graph. For our purpose, the most appropriate measure seems to be the degree. The degree corresponds to the number of edges that are attached to a node. Nodes with a high degree play a central role in the network.

To identify clusters, we decided to focus on first-level neighborhoods (all direct co-occurrences of a specific keyword). We used the ForcAtlats2 algorithm [START_REF] Jacomy | ForceAtlas2, a Continuous Graph Layout Algorithm for Handy Network Visualization Designed for the Gephi Software[END_REF] to lay out our graph. However, if all nodes and edges are visualized, the graph becomes a so-called "hairball". To remove complexity from the graph and thereby reveal clusters, controlling the displayed nodes by filtering the degrees and the occurrences of nodes is essential, as shown below.

Analyzing trends.

A third perspective on the data is to extract keyword trends. The trend is retrieved by looking at the number of their occurrences per year in a histogram. The linear regression of this histogram gives us an indication about the trend of each keyword. However, the number of occurrences per year per keyword is, in many cases, rather low, so the measure of a trend by linear regression must be looked at critically. In future work, we will extend the study to abstracts or full paper texts, and so the results might be more robust.

Some results and findings

General Findings

Table 1 below summarizes the number of contributions considered in the review according to the criteria described above (peer-review, presence of keywords, etc.), and their sources. We observe that IJPLM is by far the leading PLM journal with 45% of the papers published (146 out of 326), followed by Computers in Industry with 12% (38) of the journal contributions. The PLM International Conference series is the major scientific PLM conference with 69% (571 out of 827) of the conference papers; the second one having published only 1% (10) of these contributions. Histograms expressing the evolution of contributions by country over time (Figure 1) suggest that scientific production from France is maintained over the tenyear period. The same could be stated for Germany and Italy, even though peaks can be observed. These peaks correspond with the country hosting the PLM IC (France 2013; Germany 2010; Italy 2007). We also note that the number of contributions from the USA seems to have decreased in the second half of the ten-year period.

Analysis from Geographical data

PLM Themes as Revealed by Keywords

As indicated in Table 1, the 1153 papers that met our criteria used a total of 2847 normalized keywords. Figure 2 shows the distribution of the normalized keywords degree. The figure shows a distinct L-shape since some keywords are very common, while most of them only occur in a single paper. In fact, 2134 normalized keywords are used only once in the 1153 papers, while 713 were used more than once. Hence, it could be argued that the PLM community is spread both wide and thin.

Table 2 shows the list of the 15 top-ranking keywords, based on their degree, found in the considered literature. We should note that the Keyword PLM (normalized as 'product lifecycle management') is not used by all papers; this can be deemed as reasonable for papers published via a medium dedicated to PLM (IJPLM and PLM IC) where PLM as a keyword may be considered implicit.

Considering that both ontology and knowledge management refer to Knowledge Management, it is reasonable to consider that this is a fundamental topic to PLM (ranks 3 and 4). In a similar manner, product development, product design and new product development all refer to Product Development, which is clearly a topic of importance to PLM (ranks 2, 6 and 13). And last and not surprisingly, interoperability, collaboration, collaborative design and concurrent engineering all refer to Collaboration, which is important to PLM (ranks 8, 9, 11 and 12). It can also be stated that product data management and computer aided design are two classes of tools that are central to PLM.

These top-ranking keywords describe PLM in a very generic way. Hence, keywords that appear farther down on the list are 'less obvious' and may describe second-level ideas. For example, product lifecycle management system (rank 14) is a subset of product lifecycle management. Thus, filtering out the top level keywords helps unveil the less obvious topics. This filtering is illustrated later where we show how the computer aided design cluster is revealed. Further filtering helps to reveal clusters. For example, Figure 5 shows the keywords with a degree less than 102 (which serves to hide the five top keywords from Table 2) and an occurrence superior to 10. This tool reveals the clusters of keywords associated with a specific one. The first-level neighbors of computer aided design are displayed, hence revealing the CAD cluster. Interestingly, but not surprisingly, this cluster includes STEP, digital mockup, data exchange, collaboration and product design, amongst others.

PLM

Havi

Figure 6 shows the cluster around building information modeling, previously identified as a rising star. This cluster reveals that building information management has a strong connection with building information modeling, and that digital mockup is connected with maintenance (but not with design), suggesting that the considered scientific literature sees digital mockup as a tool for building maintenance, but that using digital mockups for building design is not explored. Of course, the reader should remember that the BIM literature surveyed here is limited to a small number of papers that were PLM-tagged so as to be included in our work. Hence, this cluster tells a story about BIM/PLM research, one that would probably differ if based on 'pure' BIM literature.

  Each of the 1153 scientific contributions was associated to the country of the first author's institution. A few observations can be made. First, France is the top contributor with 206 papers over the 2005-2014 period. Bhatt et al. made a similar observation while considering only contributions to the PLM International Conference [3]. Germany is second with 160 contributions. Italy and China are next with 96 contributions each.

Figure 1 .

 1 Figure 1. Contributions by France and USA over the 2005-2014 period

Figure 3

 3 Figure 3. Besid Internet occurrenc

Figure 5 .

 5 Figure 5. Computer aided design cluster of keywords

Figure 6 .

 6 Figure 6.

Table 1 -

 1 Number of scientific contributions and their sources

	Property	Figure
	Number of publications	1153
	Number of journals involved	63
	Number of publications from journals	326
	Top 3 journals	International Journal of PLM (146)
		Computers in Industry (38)
		Computer-Aided-Design (13)
	Number of conferences involved	153
	Number of publications from conferences 827
	Top 3 conferences	International Conference on PLM (571)
		CIRP Design Conference (10)
		International Conference on Digital Enterprise
		Technology (9)
	Number of normalized keywords	2847

6 Co

	. Building info formation mod deling cluster o of keywords
	onclusion a nd some fu uture work
	This	paper presen nts a method t to analyze a l	arge corpus o of 10 years of f scientific
	publicatio ons in order	to characteriz ze PLM. The e 1153 public cations includ ded in this
	corpus w were filtered ac ccording to a	list of criteria a, such as peer r-review. The e proposed
	approach h builds on ke eywords selec cted by the a authors of the ese publicatio ons. These
	keywords s were normal lized to limit v variations due e to American n or British En nglish, and
	so on. Th hat process yie elded a total o of 2847 norm malized keywo ords, 2134 of t them used
	only once e. It can be co oncluded from m these numbe ers, and from t the L-shape di istribution
	of the no ormalized key ywords, that P PLM as a rese earch domain n has a covera age that is
	both wid de and thin. I It would be	interesting to o conduct sim milar analysis	on other
	research d domains so as s to compare t the distribution n of keywords s.
	Char racterizing PL LM through n normalized ke eywords also	allows to ob bserve the
	evolution n of keywords s over a ten-y year period, an nd to identify y the keyword ds that are
	gaining o or declining in n popularity. T The data clearl ly shows, for	example, that t 'building
	informati ion modeling'	is now being g considered a as a part of PL LM by its com mmunity of
	researche ers.
	The p presented wor rk also used th he co-occurren nces of keywo ords in a given n paper so
	as to cap pture relations s between key ywords. If m multiple papers s use the sam me pair of
	normalize ed keywords,		the intensity	of this relatio on is reflected	in this associ iation. We
	are theref fore able to id dentify keywo ords that belon ng to the sam me cluster as w well as the
	intensity	of the pairs		within cluste ers. In future	work we wi ill characteriz ze clusters
	related to o any significa ant keyword a and even com mpare clusters. . We can even n envision
	character rizing the evol lution of clust	ers over time. .
	One	challenge of f the selected	approach is	that the num mber of occur rrences of
	keywords s is low and		hence comp	romises the s statistics and	trends. How wever, this

About 60 papers published by ASME were not included because no keywords were available.

limitation could be overcome by conducting a similar analysis of abstracts and even full-text analyses. Amongst the other steps of this ongoing project, publications from 2015 will be added, and the graphic analysis tools will eventually be made available to colleagues through a dedicated website.


Arun Kumar Singh
email: arunsingh_aks@yahoo.com

B Gurumoorthy

Latha Christie

Cloud Based Meta Data Driven Product Model

Keywords: Cloud, PLM, Core Product Model, Open Assembly Model

Product model using Core Product Model (CPM) and its extension Open Assembly Model (OAM) has been implemented with cloud compatible open source technologies. Implementation focuses on data structure for capturing assembly hierarchy, part details, part features and feature associations. Super Constraint Tolerance Feature (SCTF) model has been used to extract information from STEP file. A case study on Cylinder cap assembly has been taken to showcase the data structure and classes. Entity Attribute Value (EAV) model has been used to manage and store the product metadata and product data. Parts and assemblies are defined as entities, product metadata as attributes and product data as values has been stored in separate tables. Methods to populate product model at different stages of design has also been discussed.

Introduction

Cloud compatible technologies are gaining popularity in recent times. Most of the traditional Product data models were developed keeping in mind single-user model based environment at single/multiple location installations. With the advent of the Internet more and more products are designed and manufactured globally in a distributed and collaborative environment. Cloud compatible platforms also ena-ble to incorporate open source web technologies. Web based systems can be used to take advantage of social networking tools for knowledge capturing.

Product model should be able communicate with other systems in a plug and play manner by providing standard definitions for interfaces. For example system will be interoperable if Geometry is captured or translated using STEP from/to traditional CAD tools. Incorporation of already existing standards like STEP to define geometry will reduce efforts in system compatibilities and import/export of geometry data in/out of product model at different stages of product life. STEP is a mature and widely used standard for the exchange of product data. In practice, STEP tends to be invoked only late in the product development process, after all design decisions have been made and when the product is ready to be manufactured or assembled. Thus, STEP is used for the exchange of information that is the outcome of design activities, rather than for the information produced and used through the development of the design. STEP provides no support for design evolution, for the early phases of design when descriptive information is sparse.

The product model presented here may be seen as the precursor for STEP in the lifecycle of a product, capturing all the information relevant to the ongoing design process until the product design is firmed up, approved and committed to manufacturing.

Product Models

Core Product Model (CPM)

National Institute of Standards and Technology (NIST) proposed Core Product Model (CPM) to cater issues of interoperability and having a product model, which can cater needs of Product Lifecycle Management (PLM) from conceptual design stage to end of product life. The objective of the NIST CPM [START_REF] Fenves | CPM2: A Core Model for Product Data[END_REF] was to provide a base-level product model that is: not tied to any vendor software; open; non-proprietary; simple; generic; expandable; independent of any one product development process; and capable of capturing the engineering context that is most commonly shared in product development activities. CPM focuses on artifact representation including function, form, behavior and material, physical and functional decompositions, and relationships among these concepts. The model is heavily influenced by the Entity-Relationship data model [START_REF] Foufou | A Core Product Model for PLM with an illustrative XML implementation[END_REF].

The model consists of two sets of classes, called object and relationship. The two sets of classes are equivalent to the Unified Modeling Language (UML) terms of class and association class, respectively. CPM supported the notions of form, function, and behavior.

Open Assembly Model (OAM)

An object-oriented definition of an assembly model called the Open Assembly Model (OAM) is explored, which is as an extension to the CPM. The assembly model represents the function, form, and behavior of the assembly and defines both a system level conceptual model and associated hierarchical relationships. [START_REF] Rachuri | A Model for Capturing Product Assembly Information[END_REF] The schema incorporates information about assembly relationships and component composition; the representation of the former is by the class AssemblyAssociation, and the model of the latter uses part-of relationships. The class AssemblyFeatureAssociation represents the association between mating assembly features through which relevant artifacts are associated. The class ArtifactAssociation is the aggregation of AssemblyFeatureAssociation.

Cloud Computing

Cloud-based Product model refers to a service-oriented networked product development model in which service consumers are enabled to configure, select, and utilize customized product realization resources and services ranging from CAE software to reconfigurable manufacturing systems. This is accomplished through a synergetic integration of the four key cloud computing service models: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Hardware-as-a-Service (HaaS), and Software-as-a-Service (SaaS) [START_REF] Wu | Cloud-based design and manufacturing: status and promise[END_REF].

Cloud-based Product model refers to a networked design model that leverages cloud computing, service-oriented architecture (SOA), Web 2.0 (e.g., social networking tools), and semantic web technologies to support cloud-based engineering design services in distributed and collaborative environments [START_REF] Wu | Cloud-based design and manufacturing systems: a social network analysis[END_REF].

The key issue in improving design communication is the extent to which design engineers fully understand a complex design process, in particular, design tasks that need to be finished or identification of individuals from whom specific information can be accessed. In traditional collaborative design systems, communication can be seen as a one-way process with a linear sequence of design. Because of the use of social media in cloud based system, design communication can be im-proved through multiple information channels (e.g., social networking tools and product review tools) in which information flow can take place in multiple directions [START_REF] Wu | Cloud-based design and manufacturing systems: a social network analysis[END_REF]. In traditional systems, computer-aided application tools are standalone systems and are designed for single user without communicating and collaborating with others [START_REF] Red | Emerging design methods and tools in collaborative product development[END_REF]. In Cloud based system, engineering design requires more communication and collaboration within and across organizations on the modeling, analysis, and optimization of a design.

Designers can access manufacturing information like process sheets, inspection reports, issues associated in manufacturing product components and all the related information of a product while designing new products or modifying the existing products. Manufacturing personnel can communicate with the designer and all the communication data can be associated with the product form (artefact attribute) and can be saved for future references.

Attribute sets (Meta data) Driven Product Model

A cloud based/compatible data structure of CPM/OAM has been created, which can be used by designers to capture, store and retrieve product data. In early stages of product development when detailed geometry information is not available, it becomes difficult to associate function and behavior information to the product. There can be scenario where product is to be designed from sketch and scenario, where some reference/existing product was designed in the same environment, is available and only needs to be modified for better performance, cost reduction or new added features. Product model should be able to adapt and work in both the situations and provide methods which can be used to capture, store and retrieve design rational, assembly and tolerance information from the conceptual design stage up to the timeline where designer deals with the function and performance of product.

In situations where reference product is available and products only need feature modifications, old product design repository should be able to create new instances of whole project either with class structure skeleton model (without form, function, behavior data) or with full product history including data. A data driven attribute repository has been proposed which can be a platform to add new features for existing product designs. This repository can act as base model to define artefact. Any artefact definition would need attributes to define the form, function or behavior. Artefact may have one set of attributes for form (Geometry and topology) and others to define artefact's function and behavior. Data driven approach is adopted having EAV (Entity Attribute Value) model to capture the product information. Flow chart for attribute set creation and selection has been shown in figure 1. These methods include functionality to make a connection to database and run required database queries like INSERT/UPDATE/SELECT or DELETE.

In Entity Attribute Value (EAV) model Entity definitions, attribute definitions and attribute values are stored in separate tables of database. This makes attribute set (meta-data) definition flexible as entities and attributes can be added or deleted on the fly whenever need arises. The product model need not be changed for addition or deletion of domain specific attributes. Product model, Meta Data and product data exists separately. Product models can grow from conceptual design level having very few entities & attributes into fully developed attribute set at the advanced stages of Product Design.

Implementation

Programming Platform and Data Structure

Meta-Data Driven Product model is implemented on Cloud compatible platform. Open source resources are used to implement product model. Programming language PHP has been chosen on Apache web server. PHP is capable of implementing Object Oriented Class structure / instances from UML defined diagrams. UML diagram has been generated using open source code ArgoUML. MySQL is the database server to store product metadata and product data.

SCTF model has been taken to extract information from neutral file format STEP and to suffix constraints and features in addition to assembly hierarchy [START_REF] Shen | Analysis Neutral Data Structure for GD&T[END_REF]. The model content includes nominal geometry (features), constraints (including dimensions, mating conditions, and assembly constraints), tolerances (including datum reference frames), degrees of freedom (DOFs), and assembly hierarchy. The model is named Super-Constraint-Tolerance-Feature-Graph-Based Model (or the SCTF Model for short). The whole model is created from top down, and lower level data is gradually populated when the higher-level data is available. The order is "The general tree, parts, features, constraints, tolerances, DOFs".

MySQL Table Structure for Assembly Hierarchy

The first step to implement data structure for SCTF is assembly hierarchy definition. Assembly hierarchy is implemented using General Tree. Data Structure for general tree needs definition of Tree node class and general tree class. General tree node needs data member variable (data) and three pointers -its parent, its child and its siblings. Classes need to be defined to traverse, modify and retrieve data from the general tree.

General tree represents a hierarchical data. MySQL is a relational database. Tables of relational database are not hierarchical (like XML), but are simply a flat list. Hierarchical data has a parent-child relationship that is not naturally represented in relational database table. Hierarchical data is a collection of data, where each item has a single parent and zero or more children (With the exception of the root item, which has no parent). There are two models for dealing with hierarchical data in relational database management systems (RDBMS) -adjacency list model and the nested set model.

Adjacency List Model

In the adjacency list model, each item in the table contains a pointer to its parent. The topmost element has a null value for its parent. The adjacency list model has the advantage of being simple.

Nested Set Model

In the nested set model, we can look at hierarchy in new way, not as nodes and lines but as nested containers. Hierarchy is still maintained, as parents envelop their children. These can be represented in a table through left and right values to represent the nesting of nodes. We start numbering at the leftmost side of the outer node (Main assembly) and continue to the right. This approach is called modified preorder tree traversal algorithm. The full tree can be retrieved through the use of a self-join query that links parents with nodes on the basis that a node's left value will always appear between its parent's left and right values. Functions for finding all the leaf nodes, retrieving a single path, finding the depth of nodes, depth of a sub-tree, finding the immediate subordinate of a node, adding new nodes, deleting nodes are easy to implement compared to adjacency list model.

Next Layer of SCTF Graph consists CTF graph, which is a nested doubly-linked list data structures. At the first layer, it is a list of "parts" contained in the assembly / subassembly node. At the second layer, each "part" is composed of a list of geometric "features" .At the third layer, each geometric "feature" contains its basic geometric data, a list of geometric constraints, a list of tolerances, a list of DoFs, and a list of associated points.

Case Study -Cylinder Cap Assembly

A cylinder-cap assembly has been taken to implement product model. 3D modeling software SolidWorks is used to model the assembly. A STEP translated model has been taken. Assembly consisting of 4 unique parts (subartifacts) namely cylinder, cap, key and bolts, is shown in figure 3.

Assembly hierarchy is implemented using nested set model shown in Table 1. Nested set model makes it easy to query the parts contained in an assembly. Like any part which is having its Comp_left and Comp_right values in-between 1 and 18 will be a part of Assem_0.

ArtifactEntities in Table 2 is listing all the assemblies and parts associated with Cylinder Cap Assembly. In CPM, to store artifact data information instance has been mentioned which can hold the values of Properties. EAV (Entity Attribute Value) model is used to store these values. For example Table 3 is defining the ArtefactFeature Entities. Table 4 is holding attributes for these entities and Table 5 contains the attribute values (Product Specific data). Table 3 & 4 are containing the Meta data for product, whereas the real product data is in table 5. When designing a new Cylinder Cap Assembly (Conceptual), it can be started with the Meta data i.e. entities and attributes. These tables can be built based on the information available with the designer at different stages of Product Lifecycle. Designers have flexibility to add new form or function feature attributes. The AssemblyFeatureAssociation information is shown in Table 6. It lists Part feature's association with other part's feature. These can be implemented by doubly linked list.

Conclusion

The data structure has been created using CPM and its extension OAM. STEP File containing geometric data is used to extract the assembly hierarchy and part details. Case Study implementation shows that CPM / OAM can be implemented using open source cloud compatible technologies. Data structure containing Meta data and Product data for assembly hierarchies, parts, features and its associations (Constraints) has been implemented and demonstrated in Cylinder Cap assembly case study. The subsequent steps to SCTF graph are data structure for tolerances and artefact feature's DOFs, which can assist in Assembly planning and Goal based Tolerances allocation.

Fig. 1 .

 1 Fig. 1. Flow Chart for preparation of Product Model Attribute set (Meta data)Semantic development is fully domain driven approach and it cannot be prebuilt in Product model, which will make it domain specific product model. Main focus for developing the product Meta data in form of attribute set comes on designer. In multi domain design scenario, designers from different domain expertise can prepare their respective domain attribute sets, which in turn forms a collective attribute set definition.

Fig. 2 .

 2 Fig. 2. Extended Geometry and Function Class having methods for attribute sets and data holders Geometry_Meta_Data class has been inherited from CPM's geometry class. Geomtery_Meta_data contains variables to define attribute sets, attributes name and types. It contains functions AddAttribute(), AddDataToAttribue(), and ShowAttributeData() to store/retrieve attribute sets and attribute data to database. AssemblyFeature and CompositeFeature, which are inherited from OAM's Feature class, have been further extended to AssemblyFeature_Meta_data and Com-positeFeature_Meta_data. Class structure and its functions are shown in figure 2.

Fig. 3 .

 3 Fig. 3. Cylinder Cap assembly with Part Details and Constraints (AssemblyFeatureAssociations)

The class AssemblyAs- sociation represents

  the component assembly relationship of an assembly. It is the aggregation of one or more ArtifactAssociation.An Assembly is a composition of its subassemblies and parts. A Part is the lowest level component. Each assembly component (whether a sub-assembly or part) is made up of one or more features, represented in the model by

OAMFea- ture. The Assembly and Part classes are sub-classes of the CPM Artifact class and OAMFeature is a subclass of the CPM Feature class. In CPM, Geometry and Material aggregate into Form. Form and Function aggregate into CPM Fea- ture class.

Table 1 .

 1 Nested Set Model Table for assembly hierarchy

	Artefact_id	Artefact_name	Comp_left	Comp_right
	1	Assem_0	1	18
	2	Part_0	2	3
	3	Part_1	4	5
	4	Part_2	6	7
	5	Part_3	8	9
	6	Part_4	10	11
	7	Part_5	12	13
	8	Part_6	14	15
	9	Part_7	16	17

Table 2 .

 2 ArtefactEntities

	Artefact_id	Artefact_name	Artefact_Type	Artefact_Label
			(Part/Assembly)
	1	Assem_0	Assembly	Cylinder Cap Assembly

Table 3 .

 3 ArtefactFeature_entity

	ArtefactFeature_id	Artefact_id	ArtefactFeature_name	ArtefactFeature_type
	1	2	Centre_hole	Hole
	2	2	Fastening_hole_0	Tapped Hole
	3	2	Fastening_hole_1	Tapped Hole
	4	2	Fastening_hole_2	Tapped Hole
	5	2	Fastening_hole_3	Tapped Hole
	6	2	Fastening_hole_4	Tapped Hole
	7	5	Threaded_bolt_0	Threaded Pin
	8	6	Threaded_bolt_1	Threaded Pin

Table 4 .

 4 ArtefactFeature_attributes (For Fastening_hole_1)

	ArtefactFeature_attribute_id	ArtefactFeature_id	ArtefactFeature_attribute_name
	1	3	Centre
	2	3	Axis
	3	3	Radius
	4	3	Height
	5	3	thread_size

Table 5 .

 5 ArtefactFeature_value (For Fastening_hole_1)

	ArtefactFeature_value_id	ArtefactFeature_Attribute_id	ArtefactFeature_value
	1	1	22.6873
	2	2	0,0,1
	3	3	5
	4	4	15
	5	5	M5

Table 6 .

 6 AssemblyFeatureAssociation

	ArtefactFeature_id1	ArtefactFeature_id2	Association