Ludovic Louis-Sidney
email: ludovic.louis-sidney@renault.com.

Vincent Cheutet

Samir Lamouri

Olivier Puron

Antoine Mezza

A conceptual model for the implementation of an Inter-Knowledge Objects Exchange System (IKOES) in automotive industry

Keywords: Parameterised knowledge objects, Redesign process, Data structuring, Data exchange. Data Activities Data structure Process

The level of efficiency achieved in the diffusion of knowledge within an organisation is acknowledged to be a competitive advantage. As a result, various means have emerged to help share this knowledge. Among the various existing solutions, the use of parameterised files consistently encapsulating data of a refined level of granularity (e.g. figures, words, etc.) is a well-known practice. However, these files -which we will call Parameterised Knowledge Objects (PKOs) -often exhibit redundancy. This has led to a need for mapping, a fastidious work with no added value, which slows down the product redesign process. The goal of this article is to propose a conceptual model for the implementation of an automated tool to manage exchanges between these PKOs. The implementable nature of the model was validated by the development of a demonstrator, tested on an application provided by our industrial partner -the Renault Powertrain Technology Design Department.

Introduction

In the automotive industry, the success of a design project is mainly based upon the diffusion of knowledge -not only between the stakeholders contributing to the current design project, but also between stakeholders contributing to different projects. As a consequence, knowledge management systems are born to provide required knowledge at the right time, to the right agent, in the required form [START_REF] Tichkiewitch | Methods and Tools for Effective Knowledge Life-cyclemanagement[END_REF].

In this context, many approaches exist to manage and optimise the diffusion of knowledge and information during a product development process: personalisationoriented approaches on one hand, and codification-oriented approaches on the other (MacMahon et al., 2004). Personalisation-oriented approaches focus on the setup of communities of practices [START_REF] Amin Ash | Knowing in action: Beyond communities of practice[END_REF]. Stakeholders in the design process are able to share their knowledge by setting up organisational structures (sector meetings, project platforms, websites for sharing data, etc). Codificationoriented approaches focus on the formal expression of knowledge via models that are sufficiently complete and consistent for subsequent use. There are many types of solutions. They range from solutions aiming solely to take over the knowledge expressed by an individual (e.g. a book, an article) to those intended to give significant assistance to the individual in his task, or even replace him in carrying it out -e.g. knowledge-base engineering applications using Artificial Intelligence technology [START_REF] Moka | A framework for structuring and representing engineering knowledge[END_REF]. The increase in data volumes in engineering [START_REF] Triantaphyllou | A focused issue on data mining and knowledge discovery in industrial engineering[END_REF] suggest that the solutions preferred today are those backed by digital technology.

In this article, we examine a digital solution which is halfway between those described above, and is simple to implement. It relies on the use of parameterised files which are frequently used in redesign processes -design processes encompassing routine and innovative design, as described by [START_REF] Gero John | Design Prototypes: A knowledge Representation schema for design[END_REF]. Such solutions are not new; but to our knowledge, there is no dedicated name for them in a knowledgecentric view. Here; we will call them Parameterised Knowledge Objects (PKOs). This terminology is discussed in section 2.1.

Based on the state of the art presented in section 2, we point out the following facts for this study:

• Fact 1 (discussed in section 2.1): PKOs are widely used and encapsulate part of the company knowledge. This knowledge is not static but dynamic in nature. It is completed during the product development process itself. • Fact 2 (discussed in section 2.2): KMTs (Knowledge Management Tools) and PDM (Product Data Management) only manage files by using metadata. The user is therefore totally responsible for their content: project stakeholders must open the file in order to access a required piece of knowledge. The level of granularity of these tools is not refined enough for a good use of these PKOs in a design project. • Fact 3 (discussed in section 2.3): Knowledge expressed in PKO is redundant and few approaches exist to make them interact.

Based on these three facts, our motivation for this paper is to develop an information system enabling the automated exchange of parameters between PKOs. This system will save users from the fastidious, error-prone and timeconsuming work of transferring information and knowledge between these objects. We propose a conceptual model, i.e. a model making it possible for its authors to bridge the gap between their mental representations of the solution their proposed and the solution itself (Ben-Ari and Tzippora, 2006). This conceptual model is characterised by the integration of a semantics-oriented static representation of all the parameters encapsulated in the PKOs, and of a dynamic representation of the exchange of these parameters in a heterogeneous project environment -since there exist numerous applications to process these files. The model aims to help with the implementation of IKOES: an Inter-Knowledge Objects Exchange System.

Section 2 details the state-of-the-art summarized above. Section 3 is dedicated to presenting the conceptual model. The implementable nature of this model is validated in Section 4 through the presentation of a demonstrator tested on an application provided by our industrial partner, the Renault Powertrain Technology Design Department.

Knowledge objects and support tools

Knowledge and knowledge objects

The work of various researchers has dealt with the characterisation of knowledge in a conceptual approach [START_REF] Tsuchiya | Improving Knowledge Creation Ability through Organizational Learning[END_REF][START_REF] Ermine Jean-Louis | Méthode pour la gestion des connaissances[END_REF][START_REF] Baizet Yoan | La gestion des connaissances en conception-Application à la simulation numérique chez Renault-DIEC[END_REF]. A consensus seems to have been reached, on the fact that knowledge is reflected by adding a semantics level and a contextualisation level to tangible or intangible data. The formal expression of knowledge therefore resides in a representation of the whole -data, semantics and contextualisation -that is as faithful as possible. To convey this representation, a support medium is required. Knowledge objects are one such medium. The notion of knowledge objects has already been developed in the literature. [START_REF] Baizet Yoan | La gestion des connaissances en conception-Application à la simulation numérique chez Renault-DIEC[END_REF], based on work by [START_REF] Prudhomme | Activités de conception et instrumentation de la dynamique des connaissances locales, Ingénierie des Connaissances[END_REF] describes them as artefacts that enable an individual to construct his own knowledge. In this work, a knowledge object is defined in a relatively generic manner. It can refer to a book, a calculation report, an equation, a simulation method, etc. More recently, following the same approach, [START_REF] Cacciatori | Memory objects in project environments: Storing, retrieving and adapting learning in project-based firms[END_REF] has developed the notion of "memory objects". The author makes a distinction between two types of memory objects. On one hand, objects of a static nature containing "recommendations", as well as relatively fixed representations of knowledge that remain unchanged from project to project. Above all, their goal is to enable the individual to construct his knowledge without the systematic assistance of the people who hold this knowledge. On the other hand, objects of a reconfigurable nature are "constructed through the recombination of relatively immutable components". They do not replace dialogue between project stakeholders but are intended to provide them with a well-defined context. They "enable firms to build on experience, while maintaining the flexibility necessary to adapt to the specificities of each project." The author thus demonstrates how knowledge of a strategic nature (e.g. how to make a bid in a private finance initiative project) can be formally expressed and used by means of an Excel file.

In this article, we focus on these reconfigurable memory objects. However, [START_REF] Cacciatori | Memory objects in project environments: Storing, retrieving and adapting learning in project-based firms[END_REF] specifies that the terms used ("memory", "remembering") have connotations. They are intended to represent the fact that the author is focussing on the processes of knowledge storage and extraction, not on those of creation and modification. On the other hand, we are interested in this dynamic aspect of knowledge. We will therefore use the term "knowledge object" which tends to represent the same concept from a different perspective. In light of the generic nature of this concept, we will make it more specific by using the term "parameterised". Parameterised Knowledge Objects (PKOs) are therefore defined as digital files that enable a predetermined set of data (or parameters) to be specified, in order to produce a result. The predetermined set of data and the expected result, together with the relationship between this data and this result constitute a representation of a certain part of the company's knowledge. These PKOs are used to specify the data and to obtain the result, in a given project, in the context of a product redesign process (as defined in Section 1).

Knowledge Management Tools and Product Data Management Tools

PKOs encapsulate part of the company's knowledge in a distributed manner. Their flexible nature generates possibilities for the dissemination of this knowledge, both inside and outside the company. Tools are therefore required in order to maintain control over this asset in the context of product design, namely KMTs and PDM.

KMTs are dedicated to managing a company's knowledge assets. In view of the rapid development of this discipline since the Nineties (Grundstein, 2002), a particularly wide variety of technologies has been adopted. Nonetheless, authors who have carried out analyses of these tools all agree that they notably consist of databases in which the documents evidencing company knowledge can be stored and shared [START_REF] Ngai | Evaluation of knowledge management tools using AHP[END_REF][START_REF] Joo | Adoption of the semantic web for overcoming technical limitations of knowledge management systems[END_REF][START_REF] Vaccaro Antonino | Knowledge Management Tools, Inter-Organizational Relationships, Innovation and Firm Performance[END_REF]. [START_REF] Joo | Adoption of the semantic web for overcoming technical limitations of knowledge management systems[END_REF] endeavour to describe the causes of dissatisfaction of the users of such tools. One element of dissatisfaction is the lack of integration in terms of accessibility to the documents' internal data, which constitutes an acknowledged limit to these tools. They propose the use of Semantic Web technology to circumvent this limit, but they accept that present tools do not enable the automatic extraction of unstructured data from sources such as spreadsheet files.

PDM, originally dedicated solely to the management of CAD files, is now being used to manage all product data and related information [START_REF] Hsu Ching-Chih | A study of interface design improvement in an engineering data management system on the world wide web[END_REF][START_REF] Cimdata | cPDm -The Key to Harnessing Innovation in an E-Business World[END_REF]. Nowadays, these tools appear to have the "ability to capture and manage enterprise intellectual assets throughout the product definition lifecycle" [START_REF] Cimdata | cPDm -The Key to Harnessing Innovation in an E-Business World[END_REF]. It is therefore positions itself as a possible competitor for knowledge management tools. However, an analysis conducted by [START_REF] Pikosz | Possibilities and Limitations when using PDM Systems to support the product development process[END_REF] refers to the same limitations as those of knowledge management tools in terms of integration. These tools "can only see metadata, which is data about data (e.g. document ID, version, creator, status, etc.), whereas the document is treated as a black box". Our bibliographic study has not revealed any sources more recent than the work of [START_REF] Pikosz | Possibilities and Limitations when using PDM Systems to support the product development process[END_REF] mentioning these shortcomings of PDM. However, although their analysis is not very recent, our use of tools such as Windchill (PTC), Enovia (Dassault Systèmes) and TeamCenter (Siemens) has confirmed these limitations.

KMTs and PDM, although they are necessary to the management of PKOs, do not propose mechanisms that address optimisation of the use of the content of these files.

Working towards an inter-knowledge objects exchange system

The knowledge encapsulated in tangible objects such as PKOs is necessarily incomplete, heterogeneous and redundant [START_REF] Michel | Reinforcing decision aid by capitalizing on company's knowledge: Future prospects[END_REF]. The incompleteness is due to their synthetic objective and their limited storage capacity. As a PKO often act as boundary objects between various professional sectors [START_REF] Cacciatori | Memory objects in project environments: Storing, retrieving and adapting learning in project-based firms[END_REF], this leads to heterogeneity. And because of these two facts, redundancy appears when a same professional sector is involved with different PKOs. In this context, the more PKOs there are in the design project environment, the more it will be time-consuming and tedious to manually transfer information and knowledge between them. Nevertheless, there is currently no global approach to enable automatic sharing of knowledge expressed in these files. The scientific field of Knowledge-Based Engineering (KBE), which "concerns computerisation of processes associated with industrial products -usually routine design" [START_REF] Moka | A framework for structuring and representing engineering knowledge[END_REF], is appropriate to situate this approach. However, it should differ from approaches which aim to design actual KBE applications. Indeed, these application, developed according to the MOKA methodology [START_REF] Skarka | Application of MOKA methodology in generative model creation using CATIA[END_REF], the Common KADS methodology (Sutton and Patkar, 2009), or more ad hoc methodologies [START_REF] Chapman Craig | The application of knowledge based engineering approach to the rapid design and analysis of an automotive structure[END_REF][START_REF] Yoshioka | Physical concept ontology for knowledge intensive engineering framework[END_REF], aim to solve very specific problems and broadly lead to developing rich ontological models. Creating and maintain these models required the appropriation of a significant level of expertise, which does not match with the initial context of a need for simplification, which surrounds PKOs.

Moreover, literature mentions few tools whose goal is to share knowledge between PKOs. This type of approach appears to be taking shape in the work of [START_REF] Badin Julien | Moving toward a product model to manage data, information and knowledge for mechanical design and simulation[END_REF] in the context of the ADN (Alliance des Données Numériques) project. The authors propose a product model to interrelate files relating to CAD models and parameterised simulation models. This model should enable users to capitalise on parameters, mathematical relations, rules, limit conditions and discrete values according to several configurations of parameterised models. The implementation of this model is referred to but not in great detail. In addition, although the model is particularly complex, no consideration has been given to the stage at which the knowledge is formally expressed within the tool (this stage is viewed as being completed).

Proposed conceptual model

Our work positions itself on the grounds described in section 2.3 but in a broader perspective in terms of the PKO formats considered (Excel files in particular), and a more restricted perspective in terms of the complexity of the underlying model -it must be possible for information to be fed into the model using quickly accessible expertise. These requirements relate to the industrial context for the implementation of our work, in close collaboration with a major manufacturer.

In this article, we propose a CIM (Computational Independent Model)-type of conceptual model following an MDA (Model Driven Architecture) approach [START_REF] Omga | MDA Guide Version 1.0.1[END_REF]. The purpose of this model is to describe a design solution from a design point of view. Specifically, it aims to be translated into a PIM (Platform Independent Model) and then into a PSM (Platform Specific Model), in order to allow the implementation of IKOES. Throughout the description of the proposed conceptual model we will use the product example of a screwed assembly, to make this description more concrete. This example is based on the parameters described in Figure 1 and is reused in section 4 (validation section).

Conceptual model architecture

To make the automated exchange of parameters between PKOs possible, our conceptual model is based on four pillars (cf Figure 2) which enable: • the representation of the data (data pillar),

• the structuring of the data (data structure pillar),

• the representation of the activities using this data (activities pillar),

• the sequentialisation of these activities (process pillar).

The data and data structure pillars develop a static focus to represent the parameters as well as the relations between parameters from a semantic point of view. The activity and process pillars develop a dynamic focus to represent exchanges of parameters between one PKO and another. This dynamic focus is essential, since it underlies the added value of the IKOES information system, which we wish to implement. It represents the actual work of cross-matching and copying parameters, carried out by PKO users. Relatively to this focus, the static focus is necessary. We will describe each of the pillars of this architecture in the following sections. In terms of completeness, the model has been evaluated, regarding whether it contained the basic bricks to enable exchanges. This evaluation is materialised by the development of a demonstrator tested on an industrial application presented in Section 4.

Data structure

The UML data structure model [START_REF] Omgb | OMG Unified Modeling Language Superstructure version 2.2[END_REF]) is shown in Figure 3. Its aim is to enable the specification of parameters by a user in such a way as to describe its semantics. It reflects a compromise between the rich ontological models which can be found in a KBE application, and classic descriptive methods such as classifications.

The datum class represents the parameter to be shared without any particular reference to semantics. It enables the qualitative nature of the characteristics of the parameter to be described (e.g. its type: "numerical" or "text"). The datum definition class represents the first level of semantic description associated with a datum (e.g. the parameter is a "diameter"). A datum can only be associated with one single datum definition. The aim of this constraint is to avoid the possibility of a misunderstanding. In this article we consider the set [datum definition / datum] as one piece of information. In order to complete this first level of semantics, a piece of information may be contextualised. To achieve this contextualisation, we use the principle of a faceted classification [START_REF] Ranganathan | Classification, coding and machinery for search[END_REF]. We consider three contextualisation facets: organisational, functional and structural. These facets are evidenced by means of context objects organised in a hierarchical form. Hierarchical structures are defined beforehand and cannot be modified by the user. The organisational context enables the PKOs to which the information belongs to be specified (e.g.: a CAD screwed assembly model). This localisation viewpoint relates to the fact that our work takes place in a heterogeneous environment (cf. Section 1). The functional context enables information to be channelled into the professional sector environment where the information is used and generally refers to a group of project stakeholders sharing a common activity (e.g.: the static testing sector). The structural context is intended to specify which product element this information belongs to (e.g.: the cylinder head). It is possible to specify several context classes of the same nature for a piece of information, except for the structural context. The restriction is justified by the need to maintain control over the specification of synonymous parameters by partly curbing the possibilities for contextualisation. Before defining a parameter, the user only needs to check that it has not already been defined for the product element involved -the choice of the structural context as the exclusive context is linked to our product data-oriented working environment in the context of a redesign process. We consider the set [contexts [datum definition / datum]] as being knowledge representation (cf Section 2.1). Knowledge representation therefore consists of n organisational contexts, m functional contexts, one structural context, one datum definition and one datum with n 2 1 and m 2 1.

The flow objects enable relations between the parameters to be defined. These relations apply to the values of the parameters which are to be specified over the course of the project. They are therefore not known beforehand. As is the case for data objects, flow objects are defined by the user. A compromise has therefore been made in this model, between the possibility of defining complex relations, and the user's ability to model and subsequently manage these relations. Thus the inter-data definition flow class corresponds to the representation of a one-direction relation with only one resulting datum definition (parameter semantics). The simple nature and analysis possibilities of flows defined in this manner (i.e. simple association rules) have been the subject of several studies [START_REF] Chen Guoqing | Simple association rules (SAR) and the SARbased rule discovery[END_REF][START_REF] Alfonso Iodice | Exploratory data analysis leading towards the most interesting simple association rules[END_REF]. This relation can be mathematical or rule-based (if structure). It will then become the subject of formal interpretation by a calculation tool which can execute this type of The functional context class provides information on the professional sector environment in which this flow is defined. Structural contextualisation is not necessary since the information ([datum definition / datum]) is exclusively classified according to this context. Figure 4 gives an example of an instance for flow-type knowledge representation. The dotted lines in the hierarchical structures express the fact that they are not fully represented for space and confidentiality reasons. It should be noted that this example highlights the fact that there is no notion of implicit inheritance relative to the hierarchical structures. Indeed, these structures use a subsumption relationship, the semantics of which are more conceptual (i.e. relative to a shared set-oriented logic) than formal. This inheritance must therefore be explicitly specified.

Data

The UML model relative to data is shown in Figure 5. The aim of this model is to accurately describe the parameters present in each PKO. It differs from the structure model, the aim of which is to reconcile the parameters present in a distributed manner in each PKO. This model uses the semantic annotation concept. This is a concept known from the Semantic Web [START_REF] Ranabahu | REST: Semantic Annotation of Web Resources[END_REF]. Its goal is to represent the semantics of a concept defined within an ontology, by means of a string of characters. An instance of a semantic annotation model is thus linked to a well-defined numerical parameter and evidenced within a PKO. It is made up of an ordered series of identifiers with separators taken from the data structure model. This series of identifiers is selected in such a manner as to model the semantics and the exact level of contextualisation of the selected parameter. Thus a semantic annotation is composed of h organisational contexts (since the selected parameter is located in an identified environment), p functional contexts (since the parameter can be shared by several professional sector environments), one structural context (since the data structure model is exclusive to this context), one datum definition and one datum with n 2 h 2 1 (n being the number of organisational contexts associated with knowledge representation that have the same datum definition in the data structure model) and m 2 p 2 1 (m being the number of functional contexts associated with knowledge representation which have the same datum definition in the data structure model). It should be noted that a semantic annotation is less contextualised than the knowledge it refers to. This is due to the fact that a knowledge object has been constructed in a particular context and, this context does not encompass all the semantics reconciled in the data structure model which corresponds to that of several PKOs. A semantic annotation can thus be seen as a fragment of knowledge representation. In certain cases, a PKO parameter may be generic over several structural contexts. This is the same PKO parameter that can be used to specify different products (e.g. a diameter parameter which corresponds to the diameter of part 1 or part 2, depending on the ongoing study). In view of the exclusive nature of the structural context (cf section 3.2), this parameter can not be described by just one semantic annotation concept. We propose to semanticise this type of parameter by defining several parameters on different structural contexts in the data structure model and then, use several semantic annotations. This method enables us to compensate for the descriptive limit of our data structure model. Figure 6 shows an example of a semantic annotation instance. This example is applied to the diameter parameter of a well-identified, parameterised CAD model. In a dynamic approach, activities are intended to represent the operations that enable exchanges between knowledge objects based on our static approach (data structure model, data model). They are represented by means of BPMN models (OMGc, 2011) in Figure 7. In these models, preparation activities for the exchange, publication and management of annotations require the assistance of a user. The others are automatic. The exchange preparation activity (a) enables the user to select the supplier's organisational context, the client's organisational context and the functional context in which the exchange is to take place.

Activities

Semantic annotation

The publication activity (b) enables the user to select a list of parameters to be exchanged. It enables the recovery and publication of a list of semantic annotations and related parameter values to be supported, from a PKO.

The aim of the semantic annotation management activity (c) is to handle the processing of simple and multiple semantic annotations (cf Section 3.3 on the generic parameters relative to several structural contexts). In the case of simple annotations, it reduces the number of context identifiers in the annotations published. For the organisational contexts, only the supplier's organisational context specified in the preparation task is retained. For the functional contexts, only the functional context, specified in the preparation task, is retained. Should multiple annotations exist, user intervention is requested to specify the current structural context. Based on this information, only the semantic annotation corresponding to the specified structural context is retained. This semantic annotation is then processed in the same way as a simple semantic annotation. The aim of the extraction activity (e) is to update a list of parameter values within a PKO, from a list of semantic annotations and related values. A simple mapping mechanism between the identifiers contained in the semantic annotations is used: for a given semantic annotation in the list, the annotation for the matching PKO parameter must contain at least the same identifiers. It can contain more (cf definition of a semantic annotation in Section 3.3).

The close-off activity (f) enables us to indicate the end of the exchange.

The model indicates that the entry and/or output list artefacts for the first three activities are the subject of a contract. This contract relates to the fact that, although the model enables a certain level of semantics for a parameter to be taken into account, it does not cover the value of this parameter, which is specified during the project. This implicit contract requires that the value associated with the semantic annotation in the list artefact correctly matches the value related to the parameter in the PKO.

The process

The objective of the process model is to describe how activity sequences are established and to attach them to an executing application. Its implementation must enable user interventions to be kept to a minimum during an exchange between PKOs. Figure 9 shows the BPMN model of the process.

The exchange process starts with an initialisation event triggered by the user from his/her professional application interface. The user then specifies the exchange conditions by means of the "prepare the exchange" activity in the IKOES central module. From this point, one application takes on the role of the client, and the other, that of the supplier. These roles can be reversed in subsequent exchanges. Activities are subsequently rolled out in sequence by means of events with the assistance of the user, when required (cf Section 3.4). This model proposes a distributed vision of IKOES, the system we aim to implement. It supposes the need to customize professional sector applications and does not facilitate control over the life cycle of semantic annotations. [START_REF] Uren | A Semantic annotation for knowledge management : Requirements and a survey of the state of the art[END_REF] have already proposed that the centralised management of annotations should enable greater control over the life cycle of these annotations. However we have endeavoured to propose this solution for the following reason: access to PKOs in a project context is frequently regulated by means of PDM or KMTs. By using semantic annotations supported by PKOs we do away with difficulties such as: managing access rights to annotations (which are assumed on files by PDM or KMTs) and maintaining links between documents and their annotations (which would be fastidious depending of the life cycle of the file itself). In addition, giving the application which handles PKOs the role of publishing and extracting these semantic annotations and the value of the associated parameters, enables us to limit interoperability problem -since the IKOES central module does not have to carry out the task of searching for these elements inside the file.

Table 1 shows the demonstrator elements, their relationship with the conceptual model, and the implementation technology used.

Demonstrator elements Relation with the conceptual model

Implementation technology

Dictionary

This element encapsulates the data structure model.

Excel file (the hierarchical structure of concepts was smoothed for ease of representation reasons).

Semantic attributes

This element corresponds to the container of the data model's semantic annotations.

Field for comments on the parameters of the studied PKO (cf Figures 11 and12) The semantics manager This element encapsulates the semantic annotations management task of the activity model. In the context of the demonstrator, it also carries out syntactical verification of the annotations contained in the vector, with respect to the dictionary. The purpose of this verification is to overcome the fact that they can be easily modified by users.

VBA module.

Propagators

This element encapsulates the publication and extraction task of the activity model.

Demonstrator tests

We implemented and tested this demonstrator at Renault Powertrain Technology Design Department, our industrial partner for this work. Details of the application case study are given below.

The PKOs proposed are as follows:

• a parameterised CAD model, representing a screwed assembly (cf Figure 11),

• a parameterised Excel file to calculate tolerance stake-up for a screwed assembly (cf Figure 12).

The applications used which enabled the processing of these PKOs were an offthe-shelf CAD application (CATIA V5) and the Excel application. The first stage of our work involved the formal expression of knowledge in the dictionary, based on the following scenario:

• a PKO manager manually completes the PKO parameters in the Excel dictionary file. The contexts defined are as follows: two organisational contexts (a CAD screwed assembly template, a screwed assembly dimension chain file), three structural contexts (screw, exhaust manifold and cylinder head) and a functional context (static test). Figure 13 shows an extract from this file where O1, O2 ,F1 , S2 are respectively the identifiers for CAD screwed assembly template, screwed assembly dimension chain file, static test and cylinder head, • the PKO manager manually completes the formulas (in the form of VBA methods) in the converter then enters the identifiers for these formulas in the Excel dictionary file -i.e. in the "relation" attribute of the inter-data definition flow class (cf Figure 3), • the PKO manager constructs the semantic annotations by retrieving the identifiers of elements from the dictionary and fill in the PKO semantic attributes (cf Figures 11,12). The second stage of the work consisted in the actual specification of the PKO parameter values. This work constitutes an every day task of a designer in a redesign process. The following design loop was implemented:

• a designer sets the dimensions for the screwed assembly in the CAD model,

• the designer automatically transfers the defined parameters (nominal dimensions) via the IKOES demonstrator to the tolerance stake-up file, • the designer calculates the tolerance stake-up in the appropriate PKO and thus balances the nominals, • the designer automatically transfers the tolerance stake-up file parameters to the CAD model, via the IKOES demonstrator.

Following this stage, some research gaps have been highlighted for our conceptual model:

• The first research gap relates to the data structure model. The simultaneous transfer of several instances of the same parameter is not supported. This case occurs when a PKO is able to process several configurations of a parameter with the aim of retaining only one of them.

• The second research gap relates to the data structure model. The use of several syntaxes for the same datum is not supported (e.g.: value x of the diameter parameter can be written as "x" or "Øx", depending on the PKO). In fact, our data structure model allows a datum definition to be associated with only one datum, cf Figure 3.

• The third research gap relates to the activity model:

The algorithm for the conversion of semantic annotations and the exchange preparation activity can be optimised in order to manage the definition of relations, whose input parameters are distributed between several PKOs -as may be the case in an assembly.

• The fourth research gap relates to the process model. At the time of an exchange, the considered parameters are necessary "pushed" from the supplier PKO to the client PKO. If the client PKO is not well-known by the user, it is therefore possible to transmit more parameters than is strictly necessary. Although the converter implements a filter (via the conversion algorithm, cf. Section 3.4) to ensure that only parameters that can be understood by the PKO are transmitted, this exchange is not optimal. A possibility for improvement of this point would be to define a parameter request process from the client PKO.

Discussion

Relatively to our motivation expressed in section 1, the feedback from professional sector groups was positive. An information system of this type does not modify the initial objective of PKOs, which is to act as boundary objects and adaptable memory devices across projects [START_REF] Cacciatori | Memory objects in project environments: Storing, retrieving and adapting learning in project-based firms[END_REF]. As shown in the case study, it does not imply any strong modification in the way knowledge is formulated and structured in the file due to the parameter approach. It is therefore possible to reuse existing PKO's. Moreover by reducing the lead time and by making it less tedious to transfer parameter values between PKOs, this system should enable PKOs to be used further upstream in redesign projects.

Beyond these goals, the IKOES data structure model spawns elicitation of knowledge. Indeed, its enables the construction of a map on interrelated parameters; at level of granularity which is not usually tackled by off-the-shelf tools (PDM and KMTs). This cartography supposes the preliminary identification of the PKOs sharing same parameters or parameters that can be deduced from one another following simple association rules. The complete identification of these files does not seem trivial to our industrial partner. Tools used to manage these files today, do not always show a sufficient descriptive quality to be used in this intent. For example, it can be difficult to extract from such tools, the overall parameterised files concerning a particular product part (these files likely having common or linked parameters). The works of [START_REF] Joo | Adoption of the semantic web for overcoming technical limitations of knowledge management systems[END_REF], which mention the limitations of KMTs in terms of search capacity, tends to generalise this point. In addition, setup interviews in specific professional sectors can be particularly long. Indeed, as the use of these files is strongly fragmented, they cannot be identified by only a few individuals. A progressive supply of parameters in the system seems necessary (this would contribute to justify the simplicity requirement of the underlying model). Nevertheless, this last approach seems to be moderate insofar as the profitability associated with IKOES implementation has to be proven by first elements of cartography: to assess the overall gain in terms of lead times, a study is in process at Renault Powertrain Technology Design Department to map relevant PKOs. The time and resource-intensive nature of this work can be seen as an obstacle to the development of a system aiming at parameters management and probably justify that there is currently not much work done on this topic. Nevertheless, we believe that it constitutes an important step for industrial organizations, enabling them to achieve a global approach of their knowledge considering a granularity level often out of control.

Conclusion

In large manufacturing companies, optimising the diffusion of knowledge is a lever towards improving the success of product redesign processes. Various approach strategies exist to contribute to this optimisation. Among them, the use of parameterised knowledge objects is a simple, flexible and often-used practice.

In this article, we have proposed a conceptual model to implement IKOES: an Inter-Knowledge Objects Exchange System. This system enables users to avoid the fastidious work of copying or adapting parameter values from one PKO to another and thus reduces the resulting lead times and risks of error. Our conceptual model was evaluated by implementing a demonstrator and testing it in the context of a scenario proposed by our industrial partner, Renault Powertrain Technology Design Department.

Various prospects for future work have been proposed for this conceptual model. The aim of this work will be to enable the model to support the simultaneous exchange of several parameter instances, the management of several syntaxes for the same parameter, and the integration of a "pull processing" parameter exchange.

Figure 1 .

 1 Figure 1. Description of three parameters of a screwed assembly

Figure 2 .

 2 Figure 2. Conceptual model architecture

Figure 3 .

 3 Figure 3. Data structure model

  for data, a level of semantics and contextualisation must be added to a flows. The flow definition class represents the semantics level (e.g. "physical law"). It must be contextualised. The organisational context class allows us to specify which supplier PKOs and which client PKOs can be brought into play in the inter-parameter relation. All the relation entry parameters must be available for a given supplier PKO.

Figure 4 .

 4 Figure 4. Example of an instance for flow-type knowledge representation between parameters

  Figure 5. Data model

Figure 6 .

 6 Figure 6. Example of a semantic annotation instance

Figure 7 .

 7 Figure 7. Inter-knowledge objects exchange activities model

Figure 8 .

 8 Figure 8. Conversion algorithm for semantic annotations and related parameter values

Figure

  Figure 11. CAD PKO

Figure 13 .

 13 Figure 13. Extract from the Excel dictionary file

Table 1 .

 1 Description of the demonstrator elements

	Visual Basic for Application
	Module (VBA).

Acknowledgment

This work is part of a PhD thesis project jointly undertaken with our industrial partner Renault (Powertrain Technology Design Department).

Validation of the conceptual model

Demonstrator architecture

To validate the implementable nature of our conceptual model, we have produced a demonstrator, the distributed architecture of which is shown in Figure 10 (the textures of the different boxes in Figure 10 are linked to those in Figure 2).

Details of demonstrator elements and implementation technology


Dr Thomas Paviot
email: thomas.paviot@ensam.eu

Dr Vincent Cheutet
email: vincent.cheutet@supmeca.fr

Samir Lamouri
email: samir.lamouri@ensam.eu

Pr Samir Lamouri

A PLCS framework for PDM/ERP interoperabilty

Keywords: PLM, Product Lifecycle Management, Interoperability, PDM, Product Data Management, ERP, Enterprise Resource System, PLCS, Product Lifecycle Support, Standards, STEP, Standard for Product Data Exchange, SOA, Service Oriented Architecture

Wide diffusion of methodologies and software relevant to Product Lifecycle Management (PLM) in industrial companies faces heterogeneity of information technology (IT) systems. Especially, the lack of interoperability between Product Data Management (PDM) systems, that drive virtual product development, and Enterprise Resource Planning (ERP), which manages real product, cannot lead to a global description of the product development process. We demonstrate that a mediator approach is pertinent for the coordination of these two systems. The use of open standards, and more precisely STEP Application Protocol 239, known as Product Lifecycle Support (PLCS), allows overcoming issues related to semantic part of this interoperability. The last part of the study focuses on implementation issues, in order to develop an interoperability framework based upon a consistent product data model, whether the viewpoint is from the design or logistics businesses.

Introduction

The current trend of complexification in the development of new products in industrial companies leads to many issues. Complexification is understood here as the multiplication of partners (subcontractors, suppliers, customers located all over the world), the stronger integration between the actors of a project (design, production, marketing, maintenance etc.) as well as the huge amount of data produced, exchanged and stored during the development phase. Furthermore, although the economical environment is very constraining, the main goals remain to reduce the time-to-market, the costs, and improve the product quality. In this paper, we focus on companies in the field of aeronautics and defense industry, which can be characterised by the fact that (AIAA (2005)):

• the products (aircrafts, military vehicles, satellites) have long lifecycles (up to fifty years),

• they evolve in a context of strong regulation (security, traceability, long term data retention and preservation),

• these complex products require the participation of many specialized companies, some of them being considered as small and medium business enterprises,

• according to the nature of the project, many new partners may be included in the project team,

• some major companies can acquire other companies to get specific technologies,

• the IT system is highly heterogeneous due to economical or historical reasons.

The IT system that drives the product related data from design to retirement is then a strategic tool. The industrial deployment of this IT must satisfy the needs of three main type of actors:

• the design engineer, maintenance operator, manufacturer, salesman, must be insured that the coherency of the product data for its whole lifecycle,

• the IT manager must ensure the flexibility and the agility of the IT architecture, in order to allow a quick and efficient integration of the IT from a new partner,

• the head must reduce the total cost of ownership (TCO) of the IT, TCO including initial investment as well as maintenance.

In such industrial companies, the choice, deployment, use and maintenance of an efficient IT must then associate both of these actors. In a few words, the systems composing the IT have to interoperate at the lowest cost and with the best quality, i.e. ensure product data coherency. However the dispersion of information over heterogeneous models requires new solutions to preserve the overall coherence of the company information system [START_REF] Roucoules | The PPO Design Model With Respect to Digital Enterprise Technologies Among Product Life Cycle[END_REF]). The purpose of this paper is to demonstrate that the definition and the deployment of an industrial IT architecture as well as a suitable product model are deeply connected. The exclusive focus on one or the other point fails to achieve both goals previously mentioned. As a consequence, the paper is organized according to these two viewpoints: section 2 first introduces the PDM/ERP specific interoperability issue. Section 3 deals with interoperability general statements and then demonstrates the need of PLM standards, thus enabling to propose, in this section, a suitable service oriented functional architecture. Section 4 deals with the semantic issue of product representation and the way it can be overcame with the use of the STEP standard, especially the 239 Application Protocol known as Product Lifecycle Support. Section 5 proposes a framework, that instanciates the general architecture previously presented, and implements an AP239 based multiview data model validated with a simple scenario. The implementation is described in the section 6, as well as a study case. Section 7 finally concludes this work with the further work required to achieve the PDM/ERP interoperability.

PDM/ERP interoperability issue

Product Data Management tools and functional scope

The product design process is structured around two families of systems: authoring tools and Product Data Management (PDM) systems. Authoring tools are related to creation/modification of design documents: 3D MCAD, ECAD, requirements etc. These authoring tools supply data to the Product Data Management (PDM) system. The PDM system is designed to manage product design data lifecycle.

According to [START_REF] Audrain | Management of industrial assets: integration of a PDM software with an EAM tool[END_REF], a PDM tool must have the following features:

• the exhaustive list of parts that composes the product,

• parts and documents maturity state management,

• integration with authoring tools,

• product breakdowns and multiview access (as-designed, as-built, as-planned, as-maintained) However, PDM system is not intended to manage spare parts neither physical parts (nor parts as individuals), which is rather the role of the ERP system (see next subsection).

Enterprise Resource Planning tools and functional scope

According to [START_REF] Parr | A Taxonomy of ERP Implementation Approaches[END_REF], ERP systems are comprehensive packaged software solutions which aim for total integration of all business processes and functions. [START_REF] Holland | A critical success factors model for ERP implementation[END_REF] report that ERP software automates core corporate activities, such as manufacturing, human resource, finance, supply chain management, sourcing, maintenance, orders/service forecasting, production planning by incorporating best practices to facilitate rapid decision-making, cost reductions, and greater managerial control. ERP is however not suitable for access design information, or to organize the technical data as well as engineering processes, althgough there is a narrow link between what has been developed during the design phase and how it is produced [START_REF] Roucoules | The PPO Design Model With Respect to Digital Enterprise Technologies Among Product Life Cycle[END_REF]).

Need of an interoperability between PDM and ERP system

There is a deep relationship between the systems dedicated to design and production lifecycle stages: they must interoperate to enable information exchange and sharing between the design and production. Unfortunately there is no native integration or interoperability support between PDM or ERP commercial products, although the needs expressed by end users are well known: engineering bill-of-material (EBOM) to manufacturing bill-of-material (MBOM) bidirectional conversion, inventory level accessibility for designers, access to design information for maintenance operators and As-Maintained/As designed issues [START_REF] Cimdata | PLM and ERP Integration: Business Efficiency and Value[END_REF]). One crucial step towards an ERP/PDM integration is then to build a semantic bridge between PDM parts/product breakdowns and production management concepts related to Material Requirement Planning (MRP), e.g. billof-materials, routings and work centers (cf. Figure 1).

Interoperability attempts in the PLM field

Although the PDM/ERP interoperability issue is depicted as opened, it is not wideley covered by the literature. [START_REF] Galeta | Product model suited for the erp system[END_REF] propose an as-designed The product model on which this solution relies is however not described. The main interoperability issue in the design phase seems to be the CAD/PDM integration and has been studied by [START_REF] Guyot | Product data and digital mock-up exchange based on PLM[END_REF], [START_REF] Oh | Mapping product structures between CAD and PDM systems using UML[END_REF] or [START_REF] Paviot | MultiCAD/MultiPDM integration framework[END_REF]. There are also a few works related to ERP/MES interoperability (see for instance [START_REF] Baïna | New paradigms for a product oriented modeling: Case study for traceability[END_REF]). However, according to the state of our work, it appears that the PDM/ERP interoperability field is still opened. These two families of systems involve people of different cultures that do not share the same semantic view of the product: while designers work to define a virtual product (i.e. a representation of the product using digital information) that fits the customer requirements, logistics focuses on the real product considered as a the incoming/outgoing piece of a set of time based activities (cf. Figure 1). This semantic issue is hereby considered as the major issue to be solved in order to achieve the PDM/ERP interoperability (as defined in the subsection 3.1).

3 Interoperability and standards

General statements about interoperability

According to the surveys of [START_REF] Kosanke | ISO Standards for Interoperability: a comparison[END_REF], [START_REF] Wegner | Interoperability[END_REF] and [START_REF] Panetto | Towards a classification framework for interoperability of enterprise applications[END_REF], five different definitions of interoperability can be found. Among them, in the following of this paper, interoperability will be defined as the ability of two or more systems to exchange information and have the meaning of that information accurately and automatically interpreted by the receiving system. This definition is particularly suited to the presented issue since it merges the technical and semantic concepts related to interoperability. When analyzed from the IT viewpoint, these close concurrent definitions can be merged in a multi-level interoperability approach [START_REF] Euzenat | Towards a principled approach to semantic interoperability[END_REF]). This author stands that five levels of interoperability must be completed in order to make an exchangeable representation understandable by two different systems: encoding (segment the representation in characters), lexical (segment the representation in words), syntactic (structure the representation in sentences), semantic (construct the propositional meaning of the representation), and semiotic (construct the pragmatic meaning of the representation, or its meaning in context). This typology can be compared to the study of EIF ( 2004), which defines three levels for interoperable enterprise systems: the technical level (data and message exchange), the semantic level (information and service sharing) and the organizational level (e.g. business unit, process and people interactions across organization borders).

Considering products with long lifecycles, it's necessary to ensure the product data coherency over the time, up to decades. As a consequence, the product description must be robust whenever a change occurs in the enterprise organization and/or business processes. Due to the dynamic property of economical environment, these processes may be volatile whereas product information must remain stable over time. [START_REF] Baïna | New paradigms for a product oriented modeling: Case study for traceability[END_REF] introduce the concept of "product-oriented interoperability", i.e. the ability of different enterprise systems to manage, exchange and share product information in a complete transparency to the user.

In that sense, the enterprise system interoperability issue must be driven by the semantic level, i.e. the product representation. The use of standards is underlined in the literature as a way to help overcoming issues in the interoperability field. According to [START_REF] Chen | Standards on enterprise integration and engineering -A state of the art[END_REF] and [START_REF] Lee | A system integration framework through development of ISO 10303-based product model for steel bridges[END_REF], enterprise interoperability requires a fair amount of open standards to be able to share and exchange information in a distributed organization and heterogeneous computer environment. Furthermore, there also are economical arguments in favour of standards. The American National Institute for Standards and Technology (NIST ( 2002)) identifies three costs of interoperability: avoidance costs, migration costs and delay costs. The NIST estimates that the use of the STEP standard [START_REF] Pratt | ISO 10303: the STEP standard for product data exchange, and its capabilities[END_REF]) has the potential to save up to one billion dollars per year by reducing interoperability costs in the automotive, aerospace, and shipbuilding industries.

The technical and economical considerations related to standards lead to investigate STEP as a possible way to stand as the basis of the product driven interoperability (cf. section 4) approach.

A mediator based interoperability architecture

When attempting to implement interoperability between two systems without changing them, two different approaches can be listed: a point-to-point integration or an Enterprise Application Interface (EAI) based interoperability. Assuming a set of n systems to connect, point-to-point integration requires a number of translators equals to n(n -1). This is thus unacceptable in terms of software development and maintenance costs [START_REF] Guyot | Product data and digital mock-up exchange based on PLM[END_REF]).

The EAI solution, i.e. a central subsystem responsible for the communication between all other systems, is pertinent from an economical viewpoint since the number of required translators decreases to n. This approach has been recently extended with the "IT mediator" concept (Benaben et al. (2008)). Assuming the systems are Service Oriented Architecture (SOA) based, the mediator organizes data conversion, process orchestration and application management. This hypothesis is here validated since current trend is to make commercial products becoming SOA based (e.g. TeamCenter, Windchill, SAP, Adonix, MatrixOne etc.), and this approach is a possible and efficient way to consider PLM interoperability in general and design/logistics in particular. The 2.0 release of the OMG PLM Services (http://www.omg.org/spec/PLM/) provides a wide range of available services in the field of PLM: part identification, product structure, documentation management, shape/transformation, classification, properties, alias identification, authorization, configuration management, change and work management, process planning and a multi language support. The product structure interchange and conversion part of this mediator is the core of this study. The next section of this paper explains how the use of standards can drive the work related to this topic.

4 Product model driven interoperability using Product Lifecycle Support standard

Standards in PLM

In a recent survey on standards in PLM fields, [START_REF] Rachuri | Information sharing and exchange in the context of product lifecycle management: Role of Standards[END_REF] propose a four-level hierarchical typology of standards:

• Type 0: standards for implementation languages,

• Type 1: information modelling standards (like EXPRESS, UML, XML for instance),

• Type 2: content standards, domain of discourse: product information modelling and exchange standards (STEP), information exchange standards, product visualization standards, e-business and value chain support standards, security standards,

• Type 3: architectural frameworks standards.

The semantics part of interoperability is here adressed by the category of "Type Two" standards. According to this typology, the authors map the scope of the major current Type Two (content) standards of the PLM field along two dimensions (products life cycle major stages, complementary aspects of the information). They conclude that there is no standard that provides full coverage of the PLM support spectrum because it is fragmented and incomplete (cf. Figure 2). Considering the design/logistics interoperability context we focus in this paper, it is clear that there is no intersection in the Design/Production/Supply area that could lead to a consistent product representation. In the next subsection, we focus on the way to overcome this issue. The international standard ISO 10303 [START_REF] Pratt | ISO 10303: the STEP standard for product data exchange, and its capabilities[END_REF]) known as STandard for the Exchange of Product model data (STEP) covers computer-interpretable representation of product data, and its exchange. The objective of ISO 10303 is to provide a means of describing product data throughout the lifecycle of a product that is independent from any particular computer system. The really first STEP developments were lead by CAD data representation and exchange. STEP became after that a set of specific content standards known as Application Protocols (APs). At that time, STEP coverage scope did not permit to describe the whole lifecycle of a given product. It only allowed to structure specific industrial environment around one activity or product typology. Two major events then occurred in the early 2000s:

• In 2002, the STEP PDM Schema [START_REF] Machner | Mapping the user requirements from the VDAORG with the STEP PDM Schema[END_REF]) was released. It is a core set of entities in STEP that supports the mapping of concepts for Product Data Management (PDM), and built as a subset of APs 203, 214, 212 and 232. It is the first attempt of merging product semantics and data model from these differents APs,

• In 2005, the International Standard Organization released the AP239, known as Product LifeCycle Support (PLCS) [START_REF] Rosen | Federated through life-cycle support[END_REF]). PLCS is the first STEP Application Protocol addressing a wider scope than other APs and also proposing a generic and extensible product data model. This AP is thus discussed in detail because it is identified as a way to cover both design and logistics semantics.

AP239 offers a framework for the integration, exchange and management of technical data necessary for the support of a complex product and its evolution along its whole lifecycle (ISO ( 2005)). Its rich semantics offers information model required to define a complex product and its support solution, to maintain this product, and describe configuration change management of a product and its support solution.

PLCS is structured around the concepts of product and activity. In the PLCS semantics, a product can either be a product existing in the real world, a product that may come into existence as a consequence of some realization process, or a set of functions. As well, an activity is defined as the occurrence of an action that has taken place, is taking place, or is expected to take place in the future (change, distilling, design, a process to drill a hole are example of activities). PLCS data model then includes following descriptions:

• product modeling: representation of product assemblies, product through life and product history. This representation is based on the PDM Schema,

• process modeling: specification and planning of activities for a product, representation of the activity history of a product.

Aware that it would be impossible to fit all the specific needs of potential PLCS users, the steering comittee designed PLCS as en extensible standard [START_REF] Rosen | Federated through life-cycle support[END_REF]). PLCS thus offers a generic data model that can be specialized, under the condition of a methodology conformance, for specific business domains. This specialized data model is released in a Data Exchange Set (DEX) that defines how to use it. The OASIS consortium is responsible for the development and standardization of these DEXes. These statements lead to two observations for our purpose:

• on the Figure 2, the small axis of the ellipsis representing PLCS location in the (lifecycle, PPE) referential should be longer, since PLCS includes a rich and extensible data model for product representation,

• The scope of PLCS seems a priori suitable for PDM/ERP interoperability: the product representation, build upon the PDM Schema, match the PDM semantics whereas the activity model adds a temporal parameter that makes possible the description of design processes, manufacturing processes or routings. However, the Figure 2 shows figures out that PLCS is limited in scope to the enterprise services representation.

A graphical representation of PLM standards

The attempt of [START_REF] Rachuri | Information sharing and exchange in the context of product lifecycle management: Role of Standards[END_REF] to map PLM standards to a two dimensional chart misses the fact that PLCS provides an extensible generic data model. This extensibility can be regarded in an other dimension related to business domain. A 3D map representation of STEP standards is proposed (cf. Figure 3), along the three following dimensions:

• lifecycle stage (LC) : this item defines the lifecycle stage of the product (e.g. design, manufacturing etc.), • granularity: some APs offer a more detailed product representation than others. Regarding all STEP APs, the wider is the scope, the less granular is the product model,

• business domain (BD): this item defines a specific business domains like automotive industry or ship building.

This representation shows that the PLCS data model, unlike other APs, can be extended to fit required granularity or business domain. The holes of Figure 2 can then be filled in with the appropriate data model specialization.

5 Proposed framework for PDM/ERP interoperability

Functional architecture

This section presents the PDM/ERP interoperability framework (cf. Figure 4) based on a service oriented mediator (cf. subsection 3.2) and the PLCS product data model (cf. section 4). A first draft of this architecture was presented by [START_REF] Paviot | Design and logistics IT federation through Product Lifecycle Support standard[END_REF]. To avoid the redundancy of data, a volatile mapping between ERP and PDM objects is performed. Data flow and workflows orchestration are driven by business needs, i.e. fit the end-user of one system to grab from or populate data to the other system. This framework is composed of (from bottom to top on Figure 4):

• a set of PLCS translators, that convert the PDM or ERP requested object to or from a PLCS object,

• a data mapping director, which merges the information from the translators in a coherent PLCS description,

• a complete PDM and ERP semantic representation using the PLCS specialized data model. This data model feeds the data mapping whenever needed,

• a public layer intended to receive user queries and return appropriate information. This layer is the webservices part of the framework,

• a STEP file handler able to encode the product data into a STEP Part 21 file, as well as to retrieve information from such a file.

Technical architecture

The previous functional architecture is implemented according to the diagram presented in Figure 5. The PDM and ERP systems chosen are those available in the LISMMA laboratory: Windchill PDMLink/Project link as the PDM solution and OpenERP (http://www.openerp.com), a free and open source ERP system developped with the Python progamming language. The double lined box of the Figure 5 represents the boundary of the implementation part, which is composed of:

• an eXtended Markup Language/Remote Procedure Call (XML/RPC) based pipe for data transfer from/to OpenERP. OpenERP server/client built-in communication implements this protocol, and the server-side can easily be accessed with the Python xmlrpclib module to create parts, MBOMS, get information etc.,

• a SOAP based pipe from data transfer from/to the PDM enabling webservices access. Both PDMLink and ProjectLink offer a set of about 40 webservices to enable interoperability with third-part tools (workflow creation, parts and products creation, information extraction etc.). The Zolera SOAP Infrastructure (http://pywebsvcs.sourceforge.net/), which is a Python library dedicated to webservices implementation, was used to parse the WSDL file and communicate with the system,

• the "Mapping Kernel" is intended to merge data coming from the systems and responsible for the consitency of design/production data. It is based upon an AP239 based data model whose implementation is detailed in the next section. The Python programming language is also used for the development of this part,

• handling of STEP AP239 objects (entities, types, functions, STEP file generation etc.) is performed with respect to the Standard Data Access Interface (SDAI) (ISO (1998)), that enables software applications to have dynamic access to a repository of data. The JSDAI library (http://www.jsdai.net) is a free and open source implementation of SDAI for the Java programming language, thus enabling reading, writing and runtime manipulation of object oriented data defined by an EXPRESS based data model. The EXPRESS file encoding the AP239 data model is parsed by this library which generates a set of Java classes. These objects are accessed through a java based Python implementation, known as Jython, to ensure consistency of the source code,

• at last, a set of webservices are implemented to give the user a total control over the behaviour of the solution.

PLCS based implementation of the mapping component

In this section, the implementation of the "Mapping Kernel" is presented, the explanation being based on a simple test case presented in the following subsection.

Case study

In order to explain the implementation process, a very simple study case is defined hereafter: a bicycle front wheel, which is assumed to be composed of only two parts, one tire and one rim. Although this product could obviously be breakdown in more pieces, the purpose of this example is to be as simple as possible. The Engineering Bill of Material (EBOM) and Manufacturing Bill of Material (MBOM) are isomorphic: the EBOM defines a wheel as being composed of two parts in an organic view, where as the MBOM defines the assembly process of the rim and the tire to produce the wheel. As a consequence, although the EBOM and MBOM seem similar, they are quite different from a semantic viewpoint. Figure 6 shows the design view, as defined in Windchill Project Link, and the manufacturing view from OpenERP. This file can then be used to populate empty or corrupted databases. In the second one (Scenario 2), EBOM is extracted from the PDM, mapped to a MBOM whithin the previous data model, and the ERP product structure is created from this MBOM. The Table 1 represents each scenario over the technical architecture (cf. Figure 5 ) and the associated algorithm (note that for the scenario 1, queries to PDM and ERP run in two separate parallel processes).

Implementation methodology

Although the generic STEP AP239 data model defined in the arm EXPRESS file can be used as-is, a set of rules or best practices are available to implementors. Conforming these prescriptions will ensure later that the implentation is compliant with the one from partners or suppliers. Indeed there are so many possible ways to implement PLCS that we must conform with those best practices. Those best practices are available from the PLCS dexlib project (http://www.plcsresources.org) that defines a set of capabilities and templates. A capability provides usage guidance on how the PLCS information model should be used to represent a particular set of concepts, such as parts or properties. The templates have

Multiview part representation

Windchill PDMLink/ProjectLink multiview features are quite simple: for a part, the view is defined as a metadata that can be set to "Design" or "Manufacturing". According to the selected view, the corresponding product structure will be displayed. On the ERP side, OpenERP does not provide any multiview feature. That means a view, as defined in PLCS, has to be considered as a point (or a viewpoint) that can be represented on a 2D chart (cf. Figure 8), rather than a simple boolean state ("Design" or "Manufacturing") as defined in Windchill. For the bicycle front wheel scenario presented above, two view points are defined:

PDM VIEW CONTEXT = ("design", "mechanical engineering") ERP VIEW CONTEXT = ("manufacturing","production")

The second step is then to instanciate two Product view definition

Product structure representation

The product representation data model of PLCS is much more complete that the PDMSchema, used for instance by [START_REF] Tursi | Ontological approach for products-centric information system interoperability in networked manufacturing enterprises[END_REF] to structure the product. The representing assembly structure capabilitiy/templatey was used.

The STEP Part21 outcoming file generated by the framework, for the related scenario, is shown on the Figure 9 .

Conclusion and further works

The PDM/ERP interoperability is still an issue for most industrial companies, especially those dealing with long lifecycle products. However, an approach based on open standards can overcome these economical as well as technical issues. The use of the STEP PLCS standard can reconcile the design and logistics viewpoints.

The framework proposed in this study transfers product data from PDM to ERP (or the opposite), and can also merge data coming from these systems and export them to a compliant STEP Part 21 file. However this basic implementation still misses essential features related to other issues: the management of product diversity, changes and propagations mangement (the EBOM and MBOM being dynamic objects), as well as a more advanced mapping technique/algorithm able to handle a wide variety of product structures.

Figure 1

 1 Figure 1 The need of a PDM/ERP interoperability

Figure 2

 2 Figure 2 Rachuri et al. PLM standards 2D map

Figure 3

 3 Figure 3 3D Map representation of STEP Application Protocols

Figure 4

 4 Figure 4 The PLCS/IT mediator based functional architecture

Figure 5

 5 Figure 5 Technical architecture

Figure 6

 6 Figure6The bicycle front wheel simple study case -EBOM/MBOM

  provide more precision to this usage guidance. They specify the exact instantiation of a collection of entities and attribute values. It is an unambiguous specification of how to use a collection of PLCS entities, attributes and reference data for a certain purpose within the context defined by a capability, thus ensuring consistent interpretation of use. To achieve the experiment, two specific templates are used and instanciated among the 45 available from the dexlib project: representing part and representing assembly structure. The graphical representation of the related data model are given as an EXPRESS-G file for each template. The Figure7shows a UML diagram mapping this representation(Lubell et al. (2004)) (the reference data are omitted) in a consistent view (the entity Product view definition being the common component between those templates).

Figure 7

 7 Figure 7 UML class diagram for the representing part and representing assembly structure DEX templates

FigureFigure 9

 9 Figure 8 AP239 multiview representation

Table 1

 1 Data flow/algorithm for each scenario (cf.