Haiqing Zhang
email: haizhang@mail.univ-lyon2.fr

Aicha Sekhari
email: aicha.sekhari@univ-lyon2.fr

Yacine Ouzrout
email: yacine.ouzrout@univ-lyon2.fr

Abdelaziz Bouras
email: abdelaziz.bouras@qu.edu.qa

PLM Maturity Evaluation and Prediction Based on a Maturity Assessment and Fuzzy Sets Theory

Keywords: PLM maturity model, Triangular fuzzy elements, Key performance indicators, PLM maturity evaluation, PLM components maturity assessment (PCM A)

Companies adopt PLM maturity models to evaluate PLM implementation and recognize relative positions in PLM selection to better harness PLM benefits. However, the majority traditional PLM maturity models are relative time-consuming and energy-consuming. This work focuses on proposing a fuzzy extended PCM A (PLM Components Maturity Assessment) maturity model to brightly evaluate the gradual process of PLM maturity accompaniment with time changes, which aims to reduce the efforts spent on maturity evaluation. The proposed PCM A uses triangular fuzzy elements to express maturity levels that can solve vague and complexity issues in PLM evaluation. The proposed fuzzy PCM A is tested by two Chinese firms. The first evaluation uses PCM A maturity model to obtain the maturity levels for a Chengdu company in 2010. The PLM maturity for this company from 2011 to 2013 is conducted by the fuzzy extended PCMA maturity model through inputting the KPIs" value. Fuzzy extended PCM A is also used to predict the maturity level for a Shanghai company. A comparison of the results obtained by fuzzy extended PCM A model and the real-life situation verify the effectiveness of the proposed model.

Introduction

Product Lifecycle Management (PLM ) manages a company's product from its early conception stages to the final disposal stages. PLM drives cost reductions, facilitates reducing lead time, and imp roves product quality [START_REF] Stark | Product Lifecycle M anagement -21st Century Paradigm for Product Realization[END_REF][START_REF] Stark | Product Lifecycle M anagement, in: Product Lifecycle M anagement, Decision Engineering[END_REF]. To pave the way toward obtaining the true benefits of PLM, the users should have a clear understanding of PLM defin ition, PLM co mponents, PLM functionalit ies, and the relat ive position of PLM imp lementation. To address full PLM functionalities, Vengugopalan et al.'s work [START_REF] Vengugopalan | Application of AHP for PLM Tools Selection. Product Lifecycle M anagement: Fostering the culture of innovation[END_REF] deco mposes the functionalities of PLM into four major dimensions based on the TIFO Framework (TechnoWare, InfoWare, FunctionWare, and OrgaWare). Vengugopalan et al.'s work focus es on the functionalities in beginning of life phase and middle of life phase. The functionalities in the end of life phase, in terms of: DFE (Design for Environ ment), TRIZ (Theory of Inventive Problem Resolution), and LCA (Life Cycle Assessment), need to be integrated and collaborated with PLM to satisfy performance requirements. Thus zhang et al. [START_REF] Zhang | PLM Components Selection Based on a M aturity Assessment and AHP M ethodology[END_REF][START_REF] Zhang | Selection of product lifecycle management components based on AHP methodologies[END_REF] extends the TIFO framewo rk into TIFOS framework by adding a new dimension called SustainWare in consideration of sustainability.

Several basic co mponents construct PLM functionalities. Stark et al. [START_REF] Stark | Product Lifecycle M anagement[END_REF] state that PLM is a holistic approach and PLM contains nine PLM co mponents , which consist of products, data, applications, processes, people, work methods, and equip ment. Abramovici et al. [START_REF] Abramovici | Decision Support Framework for PLM Harmonization Projects within Industrial Companies[END_REF] define five PLM levels, and each PLM level has several concrete PLM co mponents that can have interdependencies with other co mponents .

Fifteen different types of PLM co mponents in TIFOS framework is collected and described by zhang et al. [START_REF] Zhang | PLM Components Selection Based on a M aturity Assessment and AHP M ethodology[END_REF], which include techniques & practices, PLM software & applications, strategy & supervision, quality management, business management, maintenance management, BOM management, PDM, financial management, people, distributed collaboration management, workflow & process management, eco-friendly & innovation, life cycle assessment, and green conception. This work will adopt these fifteen PLM components to analyze PLM implementation.

Many co mpanies start to enlarge investment of PLM to reap PLM benefits. Decision-makers have yet to clarify PLM adoption and imp lementation, because of PLM being large and co mplex. Measuring PLM components adoption, running condition, and maturity situation, can reflex imp lementation of PLM and provide guidelines for decision-makers in a co mpany. Th is work aims to solve the following research questions:

1. How companies can self-evaluate a PLM implemented situation and recognize the gradual process of PLM adaptation in present and future years?

How to guide companies to automatically evaluate a PLM implemented situation based on the existing value instead of setting new values for exhausted evaluation criteria to measure maturity level every year?

To solve the two questions we study literature works as well as experimental research. In literature studies, PLM maturity models [START_REF] Stark | Product Lifecycle M anagement -21st Century Paradigm for Product Realization[END_REF][START_REF] Alfaraj | Operationalising CM M I: integrating CMM I and CoBIT perspective[END_REF][START_REF] Team | CMMI for Development[END_REF][START_REF] Chrissis | CMM I for Development®: Guidelines for Process Integration and Product Improvement[END_REF][START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF][START_REF] Pels | PLM maturity assessment[END_REF][START_REF] Sääksvuori | Product lifecycle management[END_REF] identify different maturity growth stages that can evaluate PLM adoption; but these maturity models are still weaker to aid co mpanies in self-evaluation PLM and to recognize the gradual process of PLM acco mpaniment through time changes. Most of the PLM maturity models define several maturity levels and describe the differences between each level by using linguistic terms. The linguistic terms have a feature of uncertainty and vagueness, which makes the decision-makers, not able to input accurate values for each maturity level. The third research question is:

How can companies maximally keep and express decision-makers' intentions, while evaluating PLM implementation by using PLM maturity models?

A fuzzy extended PCMA maturity model is proposed to be able to resolve these research questions. This model is used to evaluate and predict the gradual process of PLM maturity by using the first year's evaluation results and the KPIs values to reduce the efforts spen t on PLM evaluation. The proposed maturity model is examined by a structured survey. The experimental research is conducted to validate the survey and the fuzzy extended PCMA maturity model. The survey was conducted in two Chinese firms in 2013. The work is structured as follows: section 2 gives the literature view of PLM maturity models and fuzzy sets theory; section 3 describes the running mechanis m of PCMA maturity model; section 4 proposes a fuzzy extended PCMA maturity model to automatically evaluate PLM maturity; section 5 examines the proposed fuzzy extended PCMA by two case studies; section 6 concludes our work.

State of the art

PLM maturity models

PLM maturity models provide guidelines to PLM implementation for any given company. CMMI (Capability Maturity Model Integration) [START_REF] Alfaraj | Operationalising CM M I: integrating CMM I and CoBIT perspective[END_REF][START_REF] Team | CMMI for Development[END_REF][START_REF] Chrissis | CMM I for Development®: Guidelines for Process Integration and Product Improvement[END_REF] has the potential to significantly improve the organization "s profitability, because it has the abilities to evaluate an organization"s maturity and process area capability. CMMI defines multiple process areas, and provides the goals for each level of implementation. Yet it has not proposed a roadmap to implementati on or identification of key process improvement areas . A company usually needs to prepare lots of documents to suit CMMI assessment in China . These prepared documents are specially used for one-time assessments. Strategies have not been given to analyze the weaker items obtained from the assessments, which makes the companies cannot receive the true benefits of maturity assessments. Besides the whole assessment process is quite time-consuming and energy-consuming. Stark [START_REF] Stark | Product Lifecycle M anagement -21st Century Paradigm for Product Realization[END_REF] proposes a PDM (product data management) maturity model with four stages of evaluation, and defines the activities that a company needs to carry out at each stage. Batenburg [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF] develops a PLM framework to assess and guide PLM implementations for organizations in terms of five dimensions: Strategy and policy, Monitoring and control, Organisation and processes , People and culture, and Information technology. Henk and Kees [START_REF] Pels | PLM maturity assessment[END_REF] apply Batenburg model in 20 companies to analyze PLM implementation of these companies . Sääksvuori Model [START_REF] Sääksvuori | Product lifecycle management[END_REF] determines the maturity of a large international corporation for a corporate-wide PLM development program and develops business and PLM related issues. Yet, it should be mentioned that most of these maturity models are qualitative analysis, which cannot give a satisfactory impression of companies" relative position, and cannot solve research questions mentioned in introduction.

Applying fuzzy sets theory to describe maturity levels

Maturity models adopt linguistic terms to exp ress the content of maturity levels. The linguistic terms have to be changed into numbers to make the maturity results easier understand. Crisp numbers cannot precisely exp ress maturity results due to complex and vague features of linguistic terms. Fuzzy set theory is proposed by Zadeh [START_REF] Zadeh | Outline of a new approach to the analysis of complex systems and decision processes[END_REF] and this theory is a revolutionary way of solving the vagueness issues. Fuzzy sets theory allows objects to exist in more than one set. The membership function is proposed to demonstrate how much degree of an element belongs in a set, which means that the associated membership function of an object is mu ltivalued. Fu zzy triangular elements and the corresponding membership function of fuzzy sets theory is used to express performance evaluation of maturity levels , because the advantages of fuzzy triangular numbers in fuzzy sets [START_REF] Zhang | Optimal Inconsistency Repairing of Pairwise Comparison M atrices Using Integrated Linear Programming and Eigenvector M ethods[END_REF].

The running mechanism of PCMA Maturity Model

The goal of PCMA maturity model is to measure and monitor PLM dimensions. Key performance indicators (KPIs) are used to help define concrete actions in evaluation [START_REF] Rohloff | Case Study and M aturity M odel for Business Process M anagement Implementation[END_REF][START_REF] Wetzstein | Towards M easuring Key Performance Indicators of Semantic Business Processes[END_REF]. PCMA provides a holistic assessment for PLM dimensions based on a comprehensive set of KPIs in each maturity level. These KPIs are defined by the authors in collaboration with representatives from partner companies. We derive five dimensions based on TIFOS framework which are called 'TechnoWare', 'InforWare', 'FunctionWare', 'orgaWare' and 'SustainWare'. Fifteen PLM components are proposed based on the five dimensions. The maturity level of each PLM component is explained by linguistic terms in PCMA maturity model. This work determines the corresponding KPIs for each maturity level in PCMA and calculates the final maturity score based on these KPIs.

An example of outcome of PLM maturity evaluation is shown in Table 1. The evaluation concerns a PLM dimension called 'FunctionWare' in TIFOS framework. Five maturity levels are defined, based on 'standard' scale in PLMIG [START_REF] Ig | PLM M aturity Reference M anual (Version 1.0)[END_REF] and CMMI scale [START_REF] Alfaraj | Operationalising CM M I: integrating CMM I and CoBIT perspective[END_REF][START_REF] Team | CMMI for Development[END_REF][START_REF] Chrissis | CMM I for Development®: Guidelines for Process Integration and Product Improvement[END_REF]. The maturity score on each KPI is represented by a black rectangle. The maturity level of this dimension of the company is determined by the average score of all related KPIs. The relative weights among each KPI will be discussed in the future.

Fuzzy extended PCMA maturity model

Fuzzy sets is adapted to address PLM maturity levels to better express decision-makers' intentions in PLM maturity evaluation. Five out of nine level fundamental scales of judgments are described via the triangular fuzzy numbers to express the relative difference among maturity levels in Table 4. The triangular fuzzy numbers is made up of a triple of numbers (L, M, U), including the medium value (M) of the membership function μ(x), the lower (L) and the upper (U) bounds which limit the range of the maturity evaluation. represents the maturity value (M i ) of the i KPI in the j year (M j_year ) for a specific category(C). Then the ratio between two maturity levels in two selected years (j year and x year) can be gotten from the ratio of the j year to the x year for the same KPI. The formula to get the maturity level in x year is shown in the following:

__ __ __ = ( ) __ x year x year ii j year j year i ii C M C K fk C M C K (1)
To be more precise, the formula (1) can be replaced by formula (2):

_ __ _ _ _ = ( ) _ _ x year i x year j year j year i i i i CK C M f k C M CK (2)
This formula represents the maturity level in the x year that can be deduced from the maturity level in the j year. The ratio between the j year and the x year for the i KPI in C category determines the changing trend and the varying degree of the maturity level in j year.

"f(k i )" is the coefficient and the signal that express the influence degree of the changing value and the changing range. The value of f(k i ) is given based on the real-life problem. For instance, we select the first KPI value in 2010 and 2013 in Table 5. The maturity level in 2013 for the first KPI in cost category is calculated by formula (2) in the following:

(2013) _ 1 (2013) _ (2013) _ (2010) _ 1 1 1 1 _ [3, 4] _ = ( ) _ = ( ) [0.3,0.5,0.7] [35, 40] _ year year year year i Cost K Cost M f k Cost M f k Cost K  ( 3
)
The sign f(k i ) shows that formula (3) need to do numerical calculation and the value of f(k i ) equals to 1 in this case based on the information given by the company. Then the way to obtain the maturity level is The second example is the second KPI value in 2010 and 2013 in Table 5. The maturity level in 2013

for the second KPI in cost category is calculated by formula (2) in the following:

(2013) _ 2 (2013) _ (2013) _ (2010) _ 2 2 2 2 _ 10 _ = ( ) _ = ( ) [0.1,0.3,0.5] 2 _ year year year year i Cost K Cost M f k Cost M f k Cost K (5)
The sign f(k i ) shows that formula (5) needs to do range calculation. Every increase 'four' of 'Average Document using frequency per day ' from the year 2010, then the maturity level will go to the next higher level based on the information from the company. The extent of changing the maturity level in formula ( 5) is calculated in formula (6):

2 10 ( ) = (10 -2) / 4 = 2 2 fk (6)
The maturity in 2013 is increased two times of 'four', then it go to the second higher maturity level: [0.5,0.7,0.9].

The maturity levels for the cost category in four KPIs from 2011 to 2013 are calculated by formula [START_REF] Vengugopalan | Application of AHP for PLM Tools Selection. Product Lifecycle M anagement: Fostering the culture of innovation[END_REF]. The maturity level of cost for each year is the average value of the maturity value in total KPIs.

Case studies

This section concerns two parts: using fuzzy extended PCMA maturity model to pred ict maturity scores in different years; studying the effectiveness of the proposed fuzzy extended PCMA maturity model by comparing the predict maturity scores with maturity model evaluation scores . Experimental data and important information have been collected by interviewing the managers of two Chinese companies.

The first case study is related to a swimming industry in Chengdu (China) studied from 2010 to 2013.We calculate the final maturity score per each category including cost, time, quality, safety, defects, infrastructure, and profitability. The results can be seen in the radar chart (left figure 1) showing the level of achievement fo r each category. The maturity level for each category is co mbined by three parts: lower value (blue line), middle value (green line), and upper value (red line). For instance, the maturity value of cost in 2010 is: (0.3, 0.4, 0.7), which is read fro m blue line, green line, and red line respectively. The overall product data management maturity (right figure 1) can be obtained by the signed distance defuzzificat ion method [START_REF] Chou | A fuzzy simple additive weighting system under group decision-making for facility location selection with objective/subjective attributes[END_REF] that calculat ing the average score of the lower value, middle value, and upper value.

To examine the effectiveness of fuzzy extended PCMA maturity model, we evaluate maturity level for product data management in seven categories by using PCMA maturity model (right figure 2) and compare with the results which have been gotten from the proposed fuzzy extended PCMA model (left figure 2). The co mparing results show that the maturity levels for two models are the same. More data is studied to evaluate the maturity levels of th is company ; similarly, results of maturity level in 2012 and 2013can be obtained by the proposed model. The maturity evaluation shows that the introduced software and hardware in 2010 is getting out-of-date. The average time consuming and the quality of PDM is decreasing year by year; this company starts needing more energy to organize the documents in 2013, because of the safety of PDM is decreasing and the defects of PDM is increasing. The maturity analysis reveals that this company should imp rove PDM or introduce new PDM to satisfy the requirements of document management.

The second case study is to predict the maturity level in a company in which the industry control field is located in Shanghai, China. This company bought Aopeng PDM in 2007, the expected lifespan of this software is 10 years. But the company has to invest new software to satisfy the new requirements after five years later. Therefore, the company bought Windchill at 2012, in which using permission is two years, which means the company needs to make a decision of which software should be invested in 2014.

The general maturity level (Figure 3) shows that the new introduced PDM is acceptable in 2013 except the 'quality category' is relatively lower than the other categories.

.

Conclusion and Future Work

This work analyzes PLM co mponents that can fulfill PLM functionalit ies. To better handle PLM implementation, a PCMA maturity model is used to evaluate the maturity of PLM co mponents. PCMA maturity model first gives the maturity level, then proposes the detail description of each maturity level, and collects the corresponding KPIs based on the content of each maturity level; finally obtaining the values of KPIs through a survey. A fuzzy extended PCMA maturity model is proposed to reduce the energy that spends on maturity evaluation. This model builds the relationship between the ratio for a pair of maturity levels and the ratio for the corresponding KPIs in two selected years in formu la 2. A coefficient in formu la 2 can determine how to get the changing degree and changing range for an unknown maturity level. The co mparison results show that the proposed model can be used in real-life cases and can efficiently reduce the use of human resources, time, and expense in maturity evaluation.

The restrict ion of the proposed model is that the selected years must be in the same stage of the company. The results of the proposed model should be recalculated when the company has significant decisions changes. The future work will use more realistic data to examine the effectiveness of the proposed fuzzy extended PCMA maturity model. The realistic data that extracted fro m social med ia are diversity and comp lexity. Therefore, strategies will be g iven to demystify Big Data based on data structures (structured data, semi-structured data and non-structured data) that enhancing the credibility of the proposed PLM maturity model.

  arithmetic operation. The average data management cost range is from 3 to 4 in 2013, the lowest value in formula (3) is the lowest value of the range: (3/40)*0.3=0.06; the middle value is the average value of the possible middle numbers : (((3/35+3/40)+(4/35+4/40))*0.5)/4=0.046875; the upper value is the largest value of the range: 4/35*0.7=0.08. Then formula (3) is changed into formula (4), which indicates the maturity level is "Ad-hoc" in 2013.

Fig. 1 .Fig. 2 .Fig. 3 .

 123 Fig. 1. M aturity Score for product data management in seven dimensions in 2010

Table 1 .

 1 PLM components and corresponding key performance indicators

	PLM	PCM A	KPIs	Levels
	dimensions	maturity		Ad-hoc Repeatable Defined managed Optimized
			D1_K1: %of new products	■
		The detail	D1_K2: Produce accurate	■
		explanation	products
	D1:	of maturity	D1_K3: Running cycle time	■
	TechnoWare	levels for each	costs D1_K4: Installation Planning	■
		component	D1_K5: Clear Product
			Innovation Strategy

■

Several co mponents consist of 'FunctionWare' dimension. Product data management (PDM) is a set of functionalities which can fulfill the practical activit ies and provide technology solutions . Therefore, PDM is considered as one component of 'FunctionWare'. The maturity levels and maturity level contents for PDM are shown in table 2. We outline part of the KPIs for the 'PDM' based on three categories in terms of 'cost', 'time', and 'quality' in Table

2

. More categories including 'comp lexity' and 'distributivity' will be studied in the future. Maturity levels, indicators for PDM maturity, and KPIs have numerous mapping relationships in Table

2

. Similarly, we can obtain the maturity score of every PLM dimension.

Table 2 .

 2 PCM A M aturity Level and Corresponding Content conducted to obtain the values of KPIs . Four KPIs fro m cost category are selected, a detail description for each KPI is given, and the related questions are proposed to deduce the value of the KPIs in Table3.

	M aturity
	Levels		PCM A maturity level content for PDM component	KPIs
			The activity of product data management is done with	Cost
			expediency	1. Average Data storage cost
	1 ad-hoc		Nobody is responsible for product data management	2. Average Document using
			Documentation is at the lowest point to satisfy operational needs	frequency per day
			PDM system and the corresponding processes have deficiencies	3. Average Document finding
			The activity is defined and managed, but it is repetitious	time-to-cost
			Documentation and record is carefully studied	4. Average using cost per
	2 Repeatable			document
				Time
			No effort has been made to consider about recycling	1. Acceptance necessary time:



M utual actions are finished in processes and departments  PDM systems are involved and used in the proper places.

Table 3 .

 3 M aturity description of PDM and the corresponding key performance indicators

	KPIs	Description	Questions
			How much you pay for information storage
		M easure of all data storage/	(including hardware and software)?
	1. Average Data storage cost	number of documents	How many documents you have to manage?
		(categories)	How much memory you need to manage
			information? (GB)
	2. Average Document using	Number of document using frequency/ number of all	How many documents you used more than 30
	frequency per day	documents using frequency	minutes per day?
	3. Average Document finding	How many time it takes for users to find it in	How long you spend to find the documents you
	time-to-cost	seconds/minutes	use every day?
	4. Average using cost per	Average cost for printing and creating the pdf per	How much you spend to use these documents
	document	document	(including printing, creating the .pdf, ...)

Table 4 .

 4 PCM A maturity levels and the corresponding fuzzy scale PCMA maturity model in section 3 is used to do the first evaluation. The companies need to spend time, costs and human resources to evaluate PLM. To answer the first and the second research questions, a strategy should be proposed to help companies to predict the gradual process of PLM in the following years to reduce the amount of efforts that spend on evaluation PLM. A real case is analyzed for a swimming industry in China. The maturity situation of PDM in 2010 is gotten by PCMA and the values of KPIs from 2011to 2013 is obtained from the company, which is shown in Table5.

	M aturity levels	Ad-hoc		Repeatable			Defined			managed			optimized
		L M	U	L	M	U	L	M	U	L	M	U	L	M U
	Fuzzy Scale
		0 0.1 0.3	0.1	0.3 0.5 0.3	0.5 0.7	0.5	0.7	0.9	0.7 0.9 1

Table 5 .

 5 Primary data of KPIs and initial maturity level

	KPIs	2013	2012	2011	2010	M aturity Level (2010)
	1. Average Data management
	cost	3.0-4.0(range) 2.8-4.2(range) 8.0-10.0(range) 35-40(range) Defined [0.3,0.5,0.7]
	2. Average Document using					Repeatable
	frequency per day	10	7	5	2	[0.1,0.3,0.5]
	3. Average Document finding
	time-to-cost	managed	managed	managed	managed	managed [0.5,0.7,0.9]
	4. Average using cost per	10 RM B	40/7RM B	6 RM B	5 RM B	Defined [0.3,0.5,0.7]
	document
	A fuzzy extended PCMA maturity model is proposed to calculate the maturity levels from 2011 to
	2013 by adopting the data in Table 5. Set	_ _ j year i CK	is the i KPI (K i ) in the j year (K j_year ) for a specific
	category(C); let

_ _ j year i CM


Jan Erik Heller
email: 1heller@ikt.rwth-aachen.de

Manuel Löwer

Jörg Feldhusen

Future Product Development Cost Prediction Model for Integrated Lifecycle Assessment

Keywords: Product Lifecycle Management, Development Process Efficiency, Sustainability Analysis, Lifecycle Tool

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

For new product development projects, it is essential to acquire information about potential revenues as well as anticipated costs in order to predict the economic feasibility of the prospective product. However, the determination of the development costs already at project start is not reliably possible in a grand number of cases. Too many and unquantifiable factors make a forecast inaccurate and lead to mostly unrealistic cost information. Often, predictions are also restricted to an indication of only the expected production and assembly costs neglecting the costs for the product development process and the operating design departments. Numerous methods are known that aim at the estimation of the efforts that are defined by engineering departments. Wolfram's FEKIS [START_REF] Wolfram | Feature-basiertes Konstruieren und Kalkulieren[END_REF] or Horváth's XKIS [START_REF] Horváth | Vergleichende Betrachtung der bekanntesten Kalkulationsmethoden für das kostengünstige Konstruieren[END_REF] may serve as examples. Admittedly, in many cases, production and assembly efforts exceed those for design and development [START_REF] Ehrlenspiel | Kostengünstig Entwickeln und Konstruieren: Kostenmanagement bei der integr[END_REF]. Nevertheless, as a result of more and more contested market conditions because of globalisation, companies are increasingly forced to also cut their costs for design and development projects besides the reduction of the manufacturing costs [START_REF] Feldhusen | Methode zur Produktivitätsmessung für Entwicklung und Konstruktion[END_REF].

Existing methods for the determination of the development costs are often designed to determine comparably precise values. Therefore, they require correspondingly accurate input values. Some of them incorporate extrapolation techniques, which, for example, implement algorithms to predict the prospective costs based on the number of positions from the bill of materials. Others are based on the precise knowledge of specific parameters of the future product, such as precise masses of individual components. These approaches provide formulas for correlations between those values and the development costs. However, at the beginning of a development project neither the complete bill of materials is known nor are parts designed with their final shape and volume. Thus, the product is not yet sufficiently defined in order to provide the necessary input variables for the existing methods.

In order to still be able to obtain a forecast of the development costs at this stage, despite the prevailing stadium of indeterminateness, it is necessary to develop a method that only relies on few design parameters based on the requirements list.

Current Cost Estimation Methods and Tools

Methods for the cost estimation and the effort of product development projects that can be applied in early phases are hardly described in the course of conventional methodologies for systematic engineering design. Typical methods are based on estimates of the cost on the basis of experience from previous projects for the development of similar products. For example, it is common practice to estimate the number of necessary drawings and documents and to map them to a comparable number of so-called document square meters. With appropriate in-house experience for the time needed to create one square meter of documents, the actual effort can be concluded. However, this approach requires detailed knowledge of the product structure and in particular the number and type of components to be developed [START_REF] Hichert | Praktische Ansätze zur Termin-, Kapazitäts-und Kostenplanung in Entwicklung u. Konstruktion[END_REF]. Thus, this approach is considered unsuitable for a prediction of the anticipated costs prior to or during the early stages of the development process.

Other approaches consider the number of positions from the bill of materials. This number is then used to correlate with company specific effort factors that allow for a prediction of the typical workload for a single position. Often, characteristic figures like engineering hours per position from the bill of materials are implemented. Similar with the previously presented approaches is the necessity to have knowledge about an elaborated bill of materials in order to be able to estimate accurate cost values.

The software business uses methods to estimate the effort that arises during the development phase itself since several decades. In general, a software product invokes design and development costs. Opposed to that, its actual production typically evokes only costs for the manufacturing of the data storage medium and the package. Boehm introduced the Constructive Cost Model (COCOMO) in 1981 [START_REF] Boehm | Software Engineering Economics[END_REF]. Since then it has been constantly extended. However, the idea and the core remain the same: it is based on a prediction of the effort that is estimated based on the physical size of the program. This is mostly implemented as the number of expected source lines of code.

Besides that measure, Boehm has included another seventeen parameters that are required to be estimated before the approach can be used for effort prediction. Amongst others, characteristic figures describing the complexity of the product and the similarity with previous projects as well as indicators for the collaborative capabilities of the team are implemented [START_REF] Boehm | Cost Models for Future Software Life Cycle Processes: COCOMO 2.0[END_REF]. A transformation of the COCOMO method to the needs of mechanical engineering design processes has already been undertaken by the author [START_REF] Feldhusen | des Entwicklungsaufwands: Adaption des COCOMO Modells auf die Produktentwicklung[END_REF]. The seventeen factors of the COCOMO II model have been adapted to meet the specific needs of the discipline and combined into a total of seven parameters. For example, the degree of innovation in the sense of the expected novelty of the product is measurable both in software development and in conventional mechanical product development [START_REF] Hauschild | Zur Messung des Innovationsgrades neuartiger Produkte[END_REF]. This parameter could directly be applied. However, some of the seventeen original parameters do not have a direct correspondent. Thus, additional factors like the distribution of the engineering team over several sites have been included. Although many of the required factors are known in advance or their determination often can be achieved regardless of the product to be developed, yet the knowledge of the size (which can be considered the counterpart of the source lines of code, for example the number of positions in the bill of materials) of the product is essential. Thus, this method also does not provide itself as useful to adequately predict the development costs in advance with the use of only the design parameters.

Other methods exist, that are specially designed to be used for commercial and military aircraft development. They are characteristically focussing on the determination of lifecycle costs of aircraft. In particular, development costs are addressed as well.

Cost estimation relationships are a typical tool to predict development costs. For example, Raymer suggests a formula for the estimation of necessary engineering hours. Parameters like the mass of the aircraft, the maximum speed and the overall size of the vehicle are used. With company-determined factors, the resulting engineering hours can then be converted to the expected efforts [START_REF] Raymer | Aircraft Design: A Conceptual Approach[END_REF]. The drawback is that Raymer's equations are only valid for aircraft with vessel and wings made from aluminium. A simple adaption for current aircraft, that are to a large extent made from fibre reinforced plastics and metals, is unmanageable. Moreover, an adaption of the method for industrial sectors other than aerospace seems to be impossible without completely revising the formulas. Another approach that is presented by Raymer tries to anticipate development costs as a fraction of production expenses [START_REF] Raymer | Aircraft Design: A Conceptual Approach[END_REF]. However, this approach requires that the costs of production are well known. Typically, assessments are only available towards the end or even only after the development phase so that a prediction of the development costs in the early stages is difficult.

Also specific to aircraft development is the model presented by Roskam. It determines the development costs as a function of weights of individual key components of the aircraft to be designed. For example, it is necessary to know the empty weight of the aircraft as well as individual weights for wheels, brakes, engines, batteries, aviation systems, climate control systems, fire extinguishment systems and the auxiliary power unit before a cost estimate can be conducted [START_REF] Roskam | Airplane Design: Airplane Cost Estimation[END_REF]. In general, these detailed weight distributions are not known at the beginning of a new development project. As not all products can be considered new product development projects, Raymer's prediction approach cannot be utilised for follow-up designs. He suggests a difficulty factor that has to be incorporated on company-specific discretion [START_REF] Roskam | Airplane Design: Airplane Cost Estimation[END_REF]. Existing approaches allow for a prediction of the effort for development projects. However, the different methods require precise input values that generally are not accessible prior to or during the early phase. As a consequence, their application is restricted to advanced phases of the development process.

Methodology for Product Development Cost Prediction

A new methodology that intends to enable the prediction of development costs has to be conceptualised in order to improve this unsatisfying situation. The methodology has to be usable with only basic design parameters as input values. Another requirement is that the cost prediction must be enabled already during or even prior to the early phases of development process.

Setup of the Methodology

The methodology is set up by two methods. The first of which is aiming at building up and qualifying a data model that is used to store and supply lifecycle data for the second one. This method is applied when an actual cost prediction is conducted. The second method requires a working and validated data model. Thus, the first method has to be successfully executed at least one time prior to the first prediction runs. An overview of the structure of the methodology is given in Fig. 1. On the right side the general procedure for a product development process embedded in the product lifecycle is displayed including the coupling point for the cost prediction methodology that is comprised of the two basic methods. Two hypotheses are introduced: the fundamental one postulates that products can be described by physical parameters, for example by their mass or their volume. Moreover, correlations can be deducted between these parameters and the factors that economically determine lifecycle phases (e.g. the development phase). In addition to that, a similarity condition is established postulating products with similar parameters will evoke similar costs. Typically, three different kinds of correlations can be distinguished: economies of scales, statistical models or equation-based mathematical relations [12]. The last one will be implemented here. The second hypothesis is that the cost of the development project depends on the year in which it is performed. Due to technological progress, it is infera-ble that the development of a product in a specific year evokes less effort, compared to the development of the same product if it had taken place some years earlier.

Product Life Cycle Methodology

Method to define model

Method 1: Lifecycle Data Modelling

Before the second method for the cost prediction can be applied, it is essential to perform the lifecycle data modelling and set up the mathematical relationships between parameters and economic data. The steps that are necessary for this approach can be taken from Fig. 2. The identification of a set of suitable parameters forms the first step of the method. It is important to identify the parameters in a way that they unambiguously define the prospective product. In addition, the parameters must have a substantial influence on the development costs. The colour of a product is not as useful as the allowed mass. In most cases, colour does only have a low influence on the development costs.

Identification
Forming combinations of several single parameters is helpful in order to achieve indicators of a higher quality. Exemplarily, the length of the landing field that is necessary for an aircraft already is a good indicator for the effort. Vehicles that can operate with a short landing field generally are more difficult to develop. But, if the landing field length is divided by the maximum weight of the aircraft, the effect of the indicator is increased as it is more difficult to develop a vehicle that has a huge weight and operates with a short landing field length at the same time. Concluding, it is possible to choose any design parameter and any combination of them for the modelling step. However, the performance and the quality of the model are significantly increased with more meaningful parameters. The method analyses data ranging from lifecycles of already existing products and its predecessors in addition to data that is incorporated from similar competitor products. Thus, a sufficient amount of data has to be researched, estimated and prepared for the qualification of the model, before it is ready to be used by the second method. The second step of the method therefore addresses the preparation of data. The model has to be fed with characteristic values for the identified parameters from already conducted development projects. For all pa-rameters that have been selected values have to be retrieved and put in context with temporal information, i.e. the year, in which the original development project has taken place. After that, the parameter functions λ i (t) can be established for every identified parameter in the third step. This is achieved with the help of parameter value charts. An example is given in Fig. 3. The mathematical function is conceived by entering all pairs of parameter values and the corresponding year into the chart. Then, the maxima or minima for a defined time period are computed depending on the industrial sector or the type of the product. The length of the period can be chosen individually based on the typical duration of development projects in the industrial sector under consideration.

Fig. 3. Exemplary parameter value chart with parameter value function

For the example in Fig. 3, the maxima approach has been chosen. Thus, higher development costs are related to a higher parameter value. A line of best fit is derived and referred to as the parameter function λ. This parameter function can be interpreted as the average border of the technological progress of the respective parameters in the specific year in case enough and representative development projects are included in the chart. As a consequence, there are no other development projects surpassing this border significantly. For every identified parameter this step has to be performed. Finally, the fourth step serves to derive the mathematical representation of the development cost function. Similar to the parameter functions the cost function ζ is derived based on the same data. Likewise, a chart is conceived that contains all pairs of cost values and related years. A linear regression curve is estimated with the maxima. In order to allow for comparisons between the different results, all cost values have to be harmonised regarding inflation. The results of the first method are a number of parameter functions and the corresponding cost function with the according charts.

Method 2: Development Cost Prediction

After the successful execution of the first method, the model is qualified with lifecycle data of existing development projects. The second method which is used for the actual prediction of the effort for the development of future products can be performed. The required steps and the related results are given in Fig. 4. During the first step, the values of the design parameters for the new product have to be identified. These values are the key input for the method. The year in which the design project is undertaken is required as well. Typically, it is the current year. However, the method is capable of predicting effort for projects in the past as well as in the future, as long as the year value remains inside the specified system boundaries. The estimation of key figures based on the parameters is conducted in the second step. Key figures are implemented in order to investigate similarities between existing data points and the current development. The similarity indicators ξ i are calculated dividing the value Λ i of the design parameter by the value of the corresponding parameter value function λ i at the defined time. Each key figure locates the prospective product in relation to a theoretical product that resides on the border of the technological progress at a given time t. An innovation number φ is calculated in the third step. In the current implementation, φ is determined by the arithmetical average of all key figures ξ i . However, it is possible to train the model with a weighted emphasis on specific indicators if this enables a model of higher quality. The decision to opt for a weighted mean has to be carried out within the first method. The weighted mean can be advantageous compared to the arithmetic mean, in case the identified design parameters are describing similar technological difficulties. In this case, the forming of groups of similarity indicators that are weakened by appropriate weighting factors can be beneficial in order to maintain a balanced representation of the prospective product. The fourth step of the method for the prediction of the effort is defined by the determination of the actual cost value for the prospective development project. By multiplying the dimensionless innovation number φ with the year-dependent value of the cost function of the model ζ, the cost value can be predicted.

Λ ( ) ( ) t λ Λ t ξ i i i = n φ n ( ) t ξ i ∑ = i =1 ( ) t ζ φ c • = Identification of

Product Lifecycle Engineering Platform Integration

Typically, within engineering departments, the application of this methodology is not limited to a prediction of product development costs. Apparently, the majority of products for which the prediction has been performed will be realised after the design phase is completed. It is possible to then effectively determine the actual costs and compare them with the initially predicted costs. This brings with it two advantages: the feedback that is collected on this way can be used to verify if the model that has been set up with the first method is capable of reliable cost predictions. In addition to that, the feedback information can also be used to add new data points to the parameter value and cost charts aiming at a further refinement of the data base. With an increasing amount and extensiveness of interpolation points, the predictions gain accuracy. Fig. 1 also shows the established verification and feedback loops. When it is intended to permanently integrate this methodology in the product emergence process of a business it is necessary to continuously include new data points. Else the model would be out-of-date and thus unable to predict current project costs accurately.

A large scale lifecycle assessment project whose goal was the extensive investigation of the complete lifecycle of civil aircraft formed the framework for the methodology presented here [START_REF] Franz | Life Cycle Engineering in Preliminary Aircraft Design[END_REF]. In the course of the project, a lifecycle engineering platform has been implemented that allows for an assessment of different preliminary aircraft designs and their impacts on production, operation and end-of-life phases.

Application for Civil Aircraft Design and Development

Section 3 presented a model for the cost prediction of future products with a surrounding methodology. A prototypical application of both model and methodology has been undertaken as a part of design and development processes for civil aircraft that have a capacity of more than 100 passengers. Both the process steps for method 1 (for the qualification of the model) and for method 2 (for the actual cost prediction) have been conducted. A software demonstrator has been conceptualised to support the data handling. It has been designed to interact with the lifecycle engineering and assessment platform which has been addressed in the previous section. Conventionally, the key concept requirements in preliminary aircraft design are defined and referred to as TLAR (Top Level Aircraft Requirements) [START_REF] Risse | An Integrated Environment for Preliminary Aircraft Design and Optimization[END_REF]. In general, the TLAR are defined prior to the beginning of the actual design and development phase. For aircraft that are available on the market at present, the parameters constituting the TLAR can be determined from literature and manuals of manufacturers. Thus, it can be made sure that a set of suitable data is available. In the application example, the design parameters that are used for the model in method 1 have been taken from the set of TLAR. However, an adequate set of design parameters had to be extracted from the list of all top level requirements. After that, each parameter and every group of parameters had to be tested regarding the applicability for the intended cost prediction. The parameters that have been chosen for the implementation are displayed in Tab. 1. An exemplary discussion demonstrates the impacts: the maximum take-off weight has a huge impact on the costs, as expected. But to only rely on this design parameter did not produce satisfying prediction results. Although key factors in the aerospace sector are masses, other parameters do have significant impact on the development costs as well. Thus, more parameters are necessary in order to express the technological feasibility by the parameter value functions. Other design parameters that have been investigated did not have significant or unambiguous impact on the development costs at all. The allowed noise emission of an aircraft has a notable effect on the design of the geometry of the wings and the engines. But with the available data no feasible parameter function could be conceived. The set of projects included in the verification contained both projects being used for the model qualification and projects that have been left out on purpose. In our tests, the average deviation between predicted and actual costs was not exceeding 22 %. Thus, the initially postulated hypotheses can be considered true.

Conclusion and Prospects

This paper introduced one approach to predict the development efforts and accordingly the development expenses. The presented methodology relies only on a small number of available technical requirements that are already defined at or even before the start of the related development project. Because of its structure which separates data model and prediction method, the methodology is generally applicable in any industrial sector or for any specific product groups. Lifecycle assessment data from similar products is incorporated to allow for a prediction of the lifecycle impacts of future products. In order to validate the applicability of the methodology, investigations for the sector of civil aircraft design have been presented. In addition to that, a software demonstrator that enables the integration of the predicted data into a lifecycle engineering platform has been addressed in the last section.

The methodology presented here is subject to current research at RWTH Aachen University. Further research will be conducted regarding the generalisation of its application. The investigations will include the research for suitable sets of design parameters being largely valid for other industrial sectors. Moreover, it is intended to extend the validation of the underlying methods with other application examples.

Fig. 1 .

 1 Fig. 1. Structure of the cost prediction methodology

Fig. 2 .

 2 Fig. 2. Method for model qualification: steps and results

  i

design parameters 1 2 Calculation of innovation number 3 Determination of cost value 4 Fig. 4 .

 12344 Fig. 4. Method for effort prediction: steps and results

Tab. 1 .

 1 Overview of implemented parameter values and parameter functions λ , Λ and ξ Eventually, five parameters have been identified which have a notable impact on the development costs. Both single parameters and combinations of several values have been implemented in a software demonstrator. Fig. 5 displays the prototype that has been established with Excel. In addition, an xml interface was set up for the connection with the existing lifecycle assessment platform [15].

Fig. 5 .

 5 Fig. 5. Software demonstrator implementing the methodology with cost function chartActual aircraft development projects have been used for a verification of the method. The set of projects included in the verification contained both projects being used for the model qualification and projects that have been left out on purpose. In our tests, the average deviation between predicted and actual costs was not exceeding 22 %. Thus, the initially postulated hypotheses can be considered true.

Acknowledgments. The authors would like to thank the Federal Republic of Germany for funding the project "Air Transport Vehicle Life Cycle Analysis" through the German Universities Excellence Initiative.


Merja Huhtala
email: merja.huhtala@lut.fi

Mika Lohtander
email: mika.lohtander@lut.fi

Juha Varis
email: juha.varis@lut.fi

Product Data Management -Defining the Used Terms

Keywords: Product Data Management, PDM, data, product data 2 Method

The Product Data Management (PDM) system and its associated terminology have changed over the years. Product Lifecycle Management (PLM) has become the predominant system and tends to overshadow PDM. However, PDM remains relevant and is a system commonly used by design engineers; mainly as a storage place for drawings and a place where drawings can be found for further editing.

To obtain full benefit from the PDM/PLM systems, precise definitions are required. Without such definitions, the systems cannot function as they should and they cannot be used optimally. Furthermore, shortcomings in definitions may lead to a situation where the engineering community is unaware of the kind of help the systems can offer.

The main focus of this conference paper is definition of some of the terms inherent to PDM/PLM systems and their data.

Introduction

Industrial production has increased over the years, especially in China. Competition on global markets is intense and this has led to a situation where companies try to reduce design and manufacturing costs by moving such activities to low-cost countries. Figure 1 presents data for a number of different countries and shows how their industrial production has increased over the last decade. When looking at the situation from Finland's point of view, it can be seen that production, as elsewhere in the Euro area, has not increased greatly. The trend in Finland seems to be to that production and design are being moved to low-cost countries; especially to China, Korea and India.

[1] Increasingly competitive markets are putting pressure on engineering work: designs have to be completed in relatively short time periods. Robinson [START_REF] Robinson | How design engineers spend their time: Job content and task satisfaction[END_REF] recently researched time usage in the work of design engineers. He compared the latest results with earlier findings and made a surprising observation: time usage of design engineers remains the same as 20 years earlier. Technical tools have developed and new tools have become available to facilitate the work of design engineers, but nevertheless most of design engineers' time is taken up with something other than technical work. Figure 2 presents how design engineers' time is allocated. [START_REF] Robinson | How design engineers spend their time: Job content and task satisfaction[END_REF] Fig. 2. Engineers' time consumptions [START_REF] Robinson | How design engineers spend their time: Job content and task satisfaction[END_REF] The nature of modern markets and increased emphasis on product development means that companies can ill afford ineffective design practices, and effective data management is critically important. Product Data Management (PDM) is a system that can help companies remain competitive in rapidly changing markets and that can make engineers use time more effectively.

Introduction to PDM system

The Product Data Management system was created in the 1980s. Its main purpose was to help design engineers save time and get products faster to the production stage. In the first stages of PDM, it only served design engineers by being a storage place for drawings: drawings were easy to find and subsequent changes to drawings easier to handle. These features helped reduce engineering costs. In the 1990s most data became electronic and the PDM system spurred companies to realize the importance of data handling. [START_REF] Ahmed | Contributions of PDM Systems in Organizational Technical Data Management[END_REF][START_REF] Borrmann | Using Product Data Management Systems for Civil Engineering Projects -Potentials and Obstacles[END_REF] Concerns about product development and time usage of design engineers (Fig. 1 and Fig 2 .) led to pressure to use the PDM system more effectively. However, the use of this system did not affect the time spent on technical work as much as it should have. Documentation in industrial design should start from the very beginning of the design process. The Aberdeen Group [9] examined the point where companies' documentation is started. In most cases, documentation started when a product concept was initiated (60%) and when a conceptual product structure was developed (22%). However, some companies started the documentation after the BOM (Bill of Materials) was developed or finalized. It can be seen that companies have understood the significance of documentation; without documentation drawings may go missing, which may cause the design process to take more time. Mainly because designs are not final in the first draft, iterative changes to the drawings have to be possible. [9] In such iterative processes, the flexibility of the systems and subsystems is crucial for improved production and design. By utilizing the PDM system companies can make sure that designs are available to those who may need them; this is a stage of documentation flexibility. Workflow and product data can be managed more effectively. [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] The amount of used product data in companies has grown in recent years; consequently, storage capacity has also increased. For example, in 2000 global disk storage per person (GDSP) was 472 MB and in 2008 it was over 400% greater, 2000 MB. [START_REF] Könst | Product Data Management -A Strategic Perspective[END_REF] Production patterns have also changed: it is now common that products have many different variants. To handle these variants and associated changes to designs, it is crucial that data handling is fast. It is also important that the information is available for many years: many products are long-lasting and products may need spare parts and maintenance long after the original design was made. [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] In light of developments in industrial production, design engineers' time usage, documentation starting point and disk storage, it is important that the PDM system works as it should. PDM has certain key functions, which are shown in Figure 3. If the system works as it should, the benefits accruing from the system are, according to [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] and [START_REF] Burden | PDM : product data management : a guide to PLM: product lifecycle management[END_REF][START_REF] Liu | A review of web-based product data management systems[END_REF][START_REF] Sendler | CAD and PDM: optimizing Processes by Integrating Them[END_REF][START_REF] Storga | Reducing design development cycle by data management within the design office[END_REF]: the data can be better controlled; people have easy access to data; the latest versions of drawings are always available and change management thus easier to handle; all data are stored in one safe place; and the information is available in an easily accessible format (e. g. PDF) to whomever may need it. All people in the company have to be aware of the PDM system, from those involved in manufacturing to top managers. For this reason, the PDM system has to be a part of the business strategy of the company. PDM may be an individual system but it has to be integrated with other systems, e.g. design software and software used on the manufacturing plant floor and in purchasing operations. PDM has to be able to link all the systems together [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] but before the actual integration and the purchase of a system it has to be clear what kind of system is going to be purchased and what are the definitions of the system and its related terms.

Definitions of used terms

In the authors' opinion the most important terms in the context of this discussion are: data, product data and product data management. Firstly, to make sure that the PDM system works as it should it has to be clear what PDM actually is and what it stands for. Secondly, if the terms data and product data are unclear, it may mean that information entered into the system is not valid. Clearly, without valid information it may not be possible to manufacture the part or product.

Data -the definition

According to SFS-ISO standard 16792 [START_REF]Technical product documentation -digital product definition data practices[END_REF] the definition for data is "information represented in a formal manner suitable for communication, interpretation or processing by human beings or computers". The terms data and document are normally used as synonyms. The definition for document, according to SFS-EN ISO standard 11442:en [START_REF]European Committee for Standardization (CEN)[END_REF], is a "fixed and structured amount of information that can be managed and interchanged as a unit between users and systems".

Other sources define the term data differently and the definition of data can be different at different stages of the product, i.e. during different parts of its lifecycle. The prime function of data is to define the product: defined properties can be physical and/or functional properties. The data has informational value through its images and descriptions of its characteristics. The data can be lifecycle data: data between the starting point (of designing) and the end point (when the product is recycled). And the data can be handled as meta data, i.e. information about who has produced the data and where the data is located. [START_REF] Saaksvuori | Product Lifecycle Management[END_REF] Companies need information to enable operations, and companies' products include information that enables them to be manufactured. This information is data and includes, for example, information about the materials used and functionality of a product. Product data also include information about suppliers and vendors and should include information that has value for customers. Thus, the data comprise different types of information and this information together can be called master data. [START_REF] Loshin | Master Data Management[END_REF] It should be borne in mind that not only the product is important for the company, the data is also important. According to [START_REF] Wang | Manage Your Information as a Product[END_REF] the data should be treated like a product. When treating data as a product, Stark [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] claims: "The definition of the product does not have to be identical at all stages, but it does have to be consistent."

Although some standards attempt to define the term, there is no widely accepted definition of data that is considered valid throughout all areas of engineering and definitions given by design engineers, people involved in purchasing and those in manufacturing all differ. Not only do the individuals give different definitions, different design programs also handle and understand the word differently.

[10] This situation is described in Figure 4; the different units in a company see the definition of data differently, which means that also the product is seen differently [START_REF] Kemppainen | Introduction Product Data Ownership Network[END_REF].

Product Data -the definition

When starting to define the term Product Data, the product should first be defined. It can be seen from Figure 4 that the product can be seen differently in different departments within a company. Generally, the terms part and product are taken as meaning the same thing. But according to [START_REF] Mckay | A Framework for Product Data[END_REF], these two terms are different, although related. A part is an already manufactured object or soon going to be manufactured. While a product is an object which has been already sold, or is going to be sold soon. However, standard SFS-EN ISO 10303-210:en [START_REF]en: Industrial automation systems and integration. Product data representation and exchange. Part 210: Application protocol: Electronic assembly, interconnection, and packaging design[END_REF] gives the definition for a part as: "a product with operational functionality that is expected to be used as a component of one or more assembled products". According to Rueckel et al. [START_REF] Rueckel | Process Data Management for the Shortening of the Whole Product Creation Process[END_REF], a product description can include: CADmodels, simulation models, FEM structures, calculation results, CAD-drawings, object list, task schedules, NC-programs, test plans, assembly instructions, QAdocuments et cetera. By these different classifications the product can be fully described. It should be noticed that these are most common classifications and in every product all of these classifications may not exist. But the main key is that every product has to have some kind of information which describes the product so it can be identified and manufactured. [START_REF] Rueckel | Process Data Management for the Shortening of the Whole Product Creation Process[END_REF] The simplest definition for product data is given by Kropsu-Vehkapera [START_REF] Kropsu-Vehkaperä | Product structure and lifecycle management: A systematic literature review[END_REF]: product data is data that is related to the product. Product data can be divided to three different sectors: product description, lifecycle data and meta data. All these sectors are related to each other, e.g. lifecycle data does not exist if there is no description for the product. [START_REF] Kropsu-Vehkaperä | Product structure and lifecycle management: A systematic literature review[END_REF] Standard SFS-EN ISO 10303-210:en [START_REF]en: Industrial automation systems and integration. Product data representation and exchange. Part 210: Application protocol: Electronic assembly, interconnection, and packaging design[END_REF] has its own definition for product data: "all data that is used to describe aspects of a product." But according to Stark [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF]; "The term 'product data' includes all data related both to a product and to the processes that are used to design it, to produce it, to use it and to support it." This means that product data is not created only by designing engineers, all units that are somehow connected to the manufacturing and selling of the product create product data. [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] Specifications depend on the product and therefore the product data depend on these specifications. The product includes not only the physical product itself but also the product specifications and product definition. These three aspects together create the product data. Process planning and materials are included in the data for the product definition, and data for the actual product describe the object physically (measurements) and from the point of view of the design process (e.g. the design date) [START_REF] Mckay | A Framework for Product Data[END_REF] A product data model is needed to define the term product data.

[23]

Product Data Management (PDM) -the definition

According to Burden [START_REF] Burden | PDM : product data management : a guide to PLM: product lifecycle management[END_REF]: "PDM is often defined differently by different industries and consequently it can be a rather difficult and elusive entity to grasp, implement, and measure." The main purpose of PDM is to handle product-related data, and this has led to a situation where the system can be given different names, such as Engineering Document Management, Technical Information Management etc. However, the system essentially concentrates on managing the data. The PDM system can be seen as a supporting tool for PLM. On the other hand, the PDM can be seen as a part of PLM. The reason why these two terms have become confused is not clear; from the point of view of some researchers, over the years PDM has grown to be PLM. [START_REF] Abramovici | Application of PDM technology for Product Life Cycle Management[END_REF][START_REF]COE[END_REF][START_REF] Cao | Product life cycle: the evolution of a paradigm and literature review from 1950-2009[END_REF] Figure 5 illustrates how the PDM system is linked to PLM. It can be seen that PDM supports the PLM concept and without PDM the PLM system cannot work properly. [START_REF] Storga | Reducing design development cycle by data management within the design office[END_REF] According to Könst et al. [START_REF] Könst | Product Data Management -A Strategic Perspective[END_REF] the definition for PDM is "a business wide methodology and strategy which makes the appropriate product-related and process-related information accessible to the appropriate people at the appropriate stage in the product lifecycle." Fig. 5. Position of PDM system according to PLM [START_REF] Storga | Reducing design development cycle by data management within the design office[END_REF] The PDM system can also be seen as an individual system, as in Bergsjö et al. [START_REF] Bergsjö | Architectures for mechatronic product data integration in PLM systems[END_REF] and Chan and Yu [START_REF] Chan | A concurrency control model for PDM[END_REF]. Although the system is separate it still helps to organize co-operation between different units in the company. Although PDM is its own application, Stark [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] states that PDM is always part of PLM. PLM could not work without PDM and the main task of PDM is to manage information during the product lifecycle. At the same time, PDM improves productivity: workflow in the company can be fully controlled. [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF] As mentioned earlier, the data should be available to all who may need it. Integration between PDM systems and different CAD software makes this possible. Effective integration is the only way to fully control the information created. [START_REF] Rueckel | Process Data Management for the Shortening of the Whole Product Creation Process[END_REF] Philpotts [START_REF] Philpotts | An introduction to the concepts, benefits and terminology of product data management[END_REF] points out that companies have many different kinds of management systems and claims that the PDM is a solution to integrate these systems together. All the information is in electronic format and safe in one place, and the data can be revised, used as a basis for new products, and viewed to get more information about the product. However, PDM is not just about handling data; PDM is a tool for communication and notification between system users. [START_REF] Philpotts | An introduction to the concepts, benefits and terminology of product data management[END_REF]

Conclusions

Based on the above discussion, the following conclusions can be drawn. Definitions for the terms vary greatly and depend on the source. Data can be handled as a product, but a common factor found in the literature is that it is important to handle data correctly within the company. Data is related to the product and products are parts that companies produce to get profit. Co-operation inside the company is crucial: the product should include data that is valid for each department such that they can all do their work on time and in an effective way. Data should thus not be from one point of view (e. g. from design engineers' point of view) alone: the main purpose of the data is to describe the product.

The system itself that handles the data is PDM. PDM, on the other hand, is the core of PLM. These two systems mainly occur together and which term should be used depends mainly on the lifecycle stage of the product. In the design stage engineers tend to use the PDM system, but after manufacturing of the product employees talk about PLM. However the main purpose of PDM/PLM is to store data and keep it available even for decades. The system should integrate all programs in the company, including those related with subcontractors.

The PDM/PLM system is used in many different ways and the system is different in every company. But to get full benefit from PDM/PLM, it is crucial that the terms are defined clearly: what is important and useful data for the company, what actually is product data, and last but not least, what is the PDM/PLM system and how should it be used.

Fig. 1 .

 1 Fig. 1. Industrial production development in different countries [2]

Fig. 3 .

 3 Fig. 3. Key functions of PDM[START_REF] Storga | Reducing design development cycle by data management within the design office[END_REF]

Fig. 4 .

 4 Fig. 4. Different points of view of the data (and the product) [19]