Manel Brichni
email: manel.brichni@g-scop.grenoble-inp.fr

Sophie Dupuy-Chessa
email: sophie.dupuy@imag.fr

Lilia Gzara
email: lilia.gzara@g-scop.grenoble-inp.fr

Corinne Jeannet
email: corinne.jeannet@st.com

Manufacturing Reporting knowledge representation: A case study at STMicroelectronics

This paper addresses the problem of manufacturing Reporting knowledge representation in manufacturing companies. An approach to characterize these knowledge is proposed. The solution is applied to the Reporting process at STMicroelectronics for capitalizing knowledge in the Wiki of the company and responding to users' needs. In such an approach, the user participates throughout the knowledge representation definition process, even in choosing knowledge characteristics to represent it. For that aim, three dimensions are taken into consideration: the know What, the know Why and the know How .

Introduction

The rapid growth of companies and their business needs, the departure of employees, the complexity of new technologies and the rapid proliferation of information, are reasons why companies seek to capitalize their expert knowledge. In the Reporting team at STMicroelectronics, the number of created reports is highly growing, while knowledge about their creation is lost. Consequently, this requires to capture and to capitalize knowledge about their creation in order to help not only users to understand the purpose of the report but also engineers to analyze the way it was created, in less time. Among other solutions, STMicroelectronics has opted for the use of a Wiki to capitalize its expert knowledge, called Stiki . In a previous publication [START_REF] Brichni | A wiki for knowledge sharing : A user-centered evaluation approach[END_REF], an evaluation of Stiki use for knowledge sharing was performed. One of the evaluation findings concerns the importance of pages structuring in Wiki . This helps readers searching for knowledge, but also contributors capitalizing their work, in an appropriate and effective way. However, this depends on the way knowledge is represented. Our aim, therefore, is to propose a way to represent knowledge while including its different aspects. In this paper, the definition of knowledge characteristics is proposed to integrate those required by users in the capitalization tool and to promote their reuse and exploitation. The proposed solution is applied to the Reporting process at STMicroelectronics that encounters capitalization issues.

Before presenting the proposed solution for knowledge characteristics representation (section 3), we present, firstly, related work and background (section 2). We end this paper with a conclusion and some perspectives (section 4).

Background and related work

This section describes related work in knowledge representation and motivates the need for a new solution. The capitalization process involves knowledge capture, representation, storage, sharing and reuse [START_REF] Bera | Knowledge requirements analysis: A case study[END_REF][START_REF] Mathieu | Knowledge management appliqué à la rénovation d'une unité de production de produits biologiques[END_REF][START_REF] Schreiber | Knowledge enineering and management[END_REF]. Many approaches have discussed the capitalization issue [START_REF] Malvache | Mastering corporate experience with the rex method[END_REF][START_REF] Matta | How to capitalize knowledge with the mask method?[END_REF]. For example, the CommonKads approach is based on the construction of a collection of models, where, each one captures specific aspects of knowledge [START_REF] Bera | Knowledge requirements analysis: A case study[END_REF][START_REF] Schreiber | Knowledge enineering and management[END_REF]. Even tough our goal is not to develop expert systems, we can retain from it the construction of a collection of models in order to capture different aspects of knowledge (The UML models for example). The AKM (Active Knowledge Modeling) [START_REF] Lillehagen | Active knowledge modeling of enterprises[END_REF] is an other approach supporting the knowledge capitalization. Being able to support collaborative work and participative learning in managing knowledge will decide of its quality. That is why, in addition to using different and complementary models to represent knowledge, our approach should support the user participation through the whole process. Among steps described in the knowledge capitalization process, in this paper, we focus on the representation problem [START_REF] Blaise | Formalisation of normative knowledge for safe design[END_REF][START_REF] Horkoff | Making data meaningful : The business intelligence model and its formal semantics in description logics[END_REF], as discussed in the following. Knowledge presents three different and complementary characteristics: What, Why and How . Each one describes knowledge in a different level and should be modeled in an appropriate way. First, the What corresponds to the conceptual level of knowledge. It represents manipulated objects and their relationships. Second, the Why is described in the behavioral level of knowledge which involves an understanding of principles behind processes. Finally, the How addresses the level of the knowledge configuration and integration in systems as well as How it could be used by different types of users. We note that these characteristics are generalized so that they could include other ones (when, who, etc.). We note that these three different characteristics are related through sharing common concepts, mainly manipulated Reporting objects.

Know-What: According to the author's thesis, [START_REF] Frey | Quality of Human-Computer Interaction: Self-Explanatory User Interfaces by Model-Driven Engineering[END_REF] considers that the know-What concept treats procedural aspects of knowledge, while [START_REF] Mathieu | Knowledge management appliqué à la rénovation d'une unité de production de produits biologiques[END_REF] describes the know-What as a set of concepts, knowledge and experience. In both cases, it concerns describing what knowledge to be considered throughout the execution of a task. In the literature, the What model is represented in different ways: Symbolic models [START_REF] Bombardier | Expert knowledge modeling and expert knowledge integration for defect identification by fuzzy linguistic rules[END_REF] or a UML diagram based on classes and associations [START_REF] Page | Representation de connaissances au moyen de classes et d'associations[END_REF]. In fact, our aim is to describe effectively and simply the manipulated objects and their relationships during the Reporting processes at STMicroelectronics while involving different types of users (experts or simple users). That is why during our representation process, complex solutions like [START_REF] Bombardier | Expert knowledge modeling and expert knowledge integration for defect identification by fuzzy linguistic rules[END_REF] are not favorite, but we retain the simplicity and efficiency of proposals like [START_REF] Page | Representation de connaissances au moyen de classes et d'associations[END_REF], while involving users throughout the capitalization process, even in defining knowledge characteristics.

Know-Why: Generally, the reasons for design decisions, can change throughout the designing business process and context, which could make them easily lost. Usually, a system is defined in terms of specifications to describe the way it works, but it does not include a description of Why it is designed the way it is, which forms the basis for a causal ambiguity. In the literature, the Why model is represented in different ways: Expert systems could be a solution, but mainly in problem resolving, which is not our goal, or design rationale notations [START_REF] Frey | Quality of Human-Computer Interaction: Self-Explanatory User Interfaces by Model-Driven Engineering[END_REF] such as QOC (Questions, Options, Criteria) or DRL (Decision Representation Language) [START_REF] Lee | What's in design rationale?[END_REF]. As our goal is to provide users with a comprehensible way to represent the know Why, design rationale could be adapted to our case study.

Know-How : it can represent both knowledge spaces (types, accesses, configurations, etc.) and business processes. Generally, it is neglected compared to the know What and Why. Our solution is based on a user centred approach requiring, therefore, accessible languages and solutions. For this purpose the IRTV solution (Information-Roles-Tasks-Views) [START_REF] Marthinusen | The active knowledge modeling approach-to configurable product and process design[END_REF] deals, among other objectives, with platform configurations, delivery, extension and improvement. Technical consultants build this model to design and implement systems, to define how knowledge is stored, roles access control is enforced, tasks should be executed, views are presented in workplaces, etc. In this paper, we will study how this methodology could cover our know How representation. As we have seen in the previous section, studies in the literature do not define (ie with the same names) and represent knowledge aspects similarly (know What, Why and How ). In the following, we present our proposal for defining knowledge characteristics that we will apply it later to the Reporting activity at STMicroelectronics.

Our proposal for knowledge representation: a case study on manufacturing Reporting process

Our approach consists in exploring current uses, users' expectations and needs, in co-designing with them a new solution and in validating it by applying it on real problems. Because of the lack of space, we do not detail these steps.

To create a report, the Reporting engineer at STMicroelectronics has to define his/her objectives, to access to data, to select his/her data, to define his/her objects (indicators, dimensions, etc.), to create the report, share and capitalize it and to exploit it. Throughout the process, many objects interact via their relationships which are of different natures. The main ones are the "Indicators" or "Dimensions", where, a dimension is an analysis parameter that carries the analysis in a query and an indicator provides numerical information used to quantify a dimension object. Generally, it is the calculation result on data from databases, for example, the evolution of the turnover of different product lines within an organization. In this case, "the turnover" represents the indicator that is calculated according to the dimensions "years" and "product lines". In the following, we describe each characteristic representation (What, Why and How ). The know What representation By describing the know What related to the Reporting activity, we aim at representing manipulated objects through the process and their relationships. Such a model will not only facilitate the comprehension of objects interaction but also will guide the way knowledge should be simply and effectively capitalized and shared. In the business intelligence domain, the relationship between Indicators and Dimensions is represented with a cube, where edges of the cube are made of dimensions and the content of the cube cell corresponds to the value of the indicator according to the combination of the selected dimensions. [START_REF] Maniatis | Olap presentation modeling with uml and xml[END_REF] demonstrated how the cube presentation can be modeled using UML to be more easily perceived by designers and programmers.

In our work, we are interested in the meta level of the cube, i.e, not the cube but its concepts. We propose in the following our representation of the know What with a UML model applied to the Reporting process. Since in the Reporting process, engineers and users manipulate expert objects of different nature, we choose therefore to represent our know What by a class diagram (figure 1).

As depicted in figure 1, a report belongs to a Universe and one or more Domains in order to classify them according to their content description. It is composed of objects that can be indicators measuring a production activity (for example, the number of products successfully achieved) or an expert attribute representing an expert object. For example, a report describing the number of achieved products per technology, is composed of an indicator measuring the "number of products", as well as the expert attribute "technology group" representing the expert object "technology". In this case, the "technology group" is the dimension representing analysis parameter that carries the analysis of the report. In the Business Intelligence domain, depending on the objective of the report, the engineer has the possibility to filter objects (data, indicators, dimensions) in order to restrict results and target specific knowledge (about a specific type of products, for example). That what makes the Business Intelligence interpreting voluminous data friendly, properly and effectively. One particularity of the reports at STMicroelectronics, is that an indicator could be calculated by several Calculation Formulas according to its Context of use. For example, in the Crolles300 manufacture, an indicator could be differently calculated from Crolles200 manufacture, while having the same name and the same objective of use. This could be due to the difference between data used in the manufacturing process between the two sites. Thus, the location could be a Context that differentiates the way an indicator is calculated. Besides, an Indicator Result varies according to the selected set of dimensions. For example, the number of finished products per technology is not the same as the number of finished products per month. The UML model could present only the way objects are designed together, but not Why are they designed in that way? This will be the goal of the Why characteristic.

The know Why representation Our aim is to represent the behavioral aspect of knowledge in order to effectively capitalize explanations about decisions that were made while performing tasks. Therefore, keeping track of the know-Why will provide help to users and designers to resolve problems and to explore more design options. Relying on knowledge described in the conceptual level through objects interaction in the Reporting process, we particularly consider, Why creating a report? Why is an indicator differently created? Why choosing a formula instead of another to calculate an indicator? Why an indicator could not be calculated or associated to a specific dimension? etc. As in our work, we aim at studying the various directions explored during the Reporting process, identified alternatives or why certain options have been made (for the calculation of indicators for example). Therefore, we decided to study the QOC model, present our vision of a possible solution, as well as discuss how we could represent it to deal with the know What, previously described. It is composed of questions about certain design options which represents alternative solutions and criteria to explicitly justify the options' selection. The model presented in figure 2 is based on the QOC model (Questions-Options-Criteria). Based on the know What model described above (figure 1), the principles behind the use of manipulated objects through the Reporting process are detailed.

This example (figure 2) treats the indicator object and the principles behind its use. We will study in the future if this model could be applied or adapted to treat other objects of the What model. The indicator WIP (Work In Progress), which is an object of the know What model, calculates the number of lots being processed in the clean room at STMicroelectronics. It could be calculated by more than one formula according to its context of use. Therefore, one of the most important questions asked when selecting an indicator is "Why is the WIP indicator calculated in that way?". Such an indicator is one of the most used for creating reports. It is important to understand its behavior. In fact, the first part of the QOC model used in figure 2, treats the Question part that corresponds to the Indicator WIP. Options presents its second part. In our For example the indicator WIP could be calculated by either Formula 1, 2 or 3. For each one, Criteria explain its selection. In our case, contexts of selection of formulas correspond to the Criteria in the QOC model. For example, if the user is in the Context 3 when he/she wants to calculate the WIP, then he will select the Formulas 3 to calculate it. The particularity of this example is that logically, the obtained result of an indicator should be the same whatever the formulas, when considering the same conditions and goal. For example, in both calculation formulas 1 and 2 of the WIP, the objective is to calculate the number of achieved lots at the end of the day. However, the results of both formulas are different. Besides, while studying some existing indicators, we realized that the existence of different calculation formulas is due to the selection of the indicators' names. This is the case of WIP indicator where even having the same name, the formulas 1 and 2 are actually used to calculate different types of indicator. It could generate a misunderstanding problems between users. To this end, in the future, we will study how the QOC Model could be adapted to deal with such a problem. Using the QOC model facilitates the formulas selection and understanding, depending on their context of use, but understanding How each formula was created and integrated in the production system, is considered as a technical knowledge. Such knowledge is not necessarily capitalized and risks to be lost. This will be the goal of the How model.

The know How representation As we have discussed above, the know How treats the knowledge integration and configuration in systems. Capitalizing such knowledge in industrial contexts is a crucial step since the technology evolves and important configuration process could be easily lost. Keeping track of technical details facilitates engineers' work and saves time. The IRTV (Information-Roles-Tasks-Views) methodology deals with platform configuration, delivery, extension and improvement [START_REF] Marthinusen | The active knowledge modeling approach-to configurable product and process design[END_REF]. In figure 3, the IRTV solution is applied to describe the know How related to the use of a report (the WIP Status Report) that actually represents an expert object of the know What model, as follows: Information: considers knowledge required for the users to create, to manage or to use a report and knowledge produced by them (inputs and outputs). This is not what we described in the What model, but, technical knowledge required by an IT member. For example, to create a report, inputs are passwords, access rights, etc. Outputs are scripts or the final report category and nature. Roles: represents different users who are confronted with the use of a report (Owner, developer and simple user). Tasks: each role is in charge of specific tasks. For example, as depicted in figure 3, a developer is in charge of evaluating requests of users (the owner role in the Figure , for example) in terms of relevance, priority, gain, etc. He/she needs also to detail data technical specifications (databases, tables, attributes and how to extract them). In addition to documenting these technical knowledge, he/she is in charge of specifying exceptions, alternatives and tests. If needed, he/she has to contact the owner since he is in charge of the request. Views: Each role accesses to a specific view. As depicted in figure 3, a developer performing technical tasks needs to have a technical view which is different from the view needed by a simple user. He/she needs to have a clearer view about the environment he/she should work on (platforms, tools, etc.), as well as requirements and specification definition, etc. These knowledge need to be capitalized and shared with other users, particularly between the same category, for an eventual reuse in an effective way.

Conclusion

Applied to the Reporting process at STMicroelectronics, three complementary characteristics know What, Why and How were defined and represented. Our short-term goal is, first, to study how the QOC Model can be adapted to deal with the confusion problem in the know Why representation, as well as if it could be applied to other objects of the What model or if it has to be completed with other methods. Second, the representation of the know How will be improved in order to involve both process modeling and control mechanism. Finally, the relationship between knowledge representation and its sharing and reuse in Stiki will be studied. The idea consists in providing, automatically through proposed models, Stiki templates for objects, where each one treats all knowledge characteristics, according to the concerned models. In the long term, we aim at studying the semantic aspect of knowledge representation, as well as knowledge reuse and evolution as other stages of our capitalization process, through which, we will discuss how capitalized knowledge could be reused in an effective way by users. Eventually, we will discuss how new users can search for information while learning existing vocabulary. At STMicroelectronics, such an approach for knowledge capitalization could be generalized to other contexts.

Fig. 1 .

 1 Fig. 1. Know What representation through Reporting process

Fig. 2 .

 2 Fig. 2. Know Why representation with the QOC model

Fig. 3 .

 3 Fig. 3. How modeling using the IRTV methodology (the WIP Status Report)


Juan Diego Botero
email: juan.boterolopez@enit.fr

Cédrick Béler
email: cedrick.beler@enit.fr

Daniel Noyes
email: daniel.noyes@enit.fr

Juan Diego

Botero Lopez

BPRM Methodology: Linking Risk Management and Lesson Learnt System for Bidding Process

Keywords: bidding process (BP), risk management (RM), project lifecycle, lesson learned system (LLS)

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

Introduction

In recent years, bidding process (BP) has become a key practice for almost all professional sectors. This practice is based on the competition of potential providers. Each one of them spends time and resources to make proposals that will not always be accepted or even, that will penalize the bidder during the product development. A successful BP is one that allows achieving both client and provider goals. To be efficient, proposals must meet client quality requirements while minimizing costs and time. These constraints make BP risky and complex. Since it is a widely used procedure, it is necessary to develop support management tools in order to assist this process. Depending on the project advancement, two risk families are distinguished. The first one is associated to the BP itself in relation with the non-acceptance of the offer, and the second one is related with the project execution. An incorrect assessment by the bidder of the difficulties associated with the realization (inadequate estimation of development context, evaluation errors) can distort the offer. If it is accepted, the bidder may be engaged in a very penalizing process (cost overruns, non-compliance of technical requirements, non-compliance of deadlines...).

To effectively solve these major problems, a BP instrumentation is proposed by coupling a suitable risk management engineering with a dedicated lesson learnt system. This instrumentation and the underlying methodology (called BPRM "Bidding Process Risk Management") aims to assist BP by taking into account BP risks through a lesson learned system (LLS).

The central principle of BPRM approach is the capitalization of past BP cases including all project cycles, focusing on risks. This goal is achieved through a fact sheet featuring all relevant information to facilitate posterior exploitation. These fact sheets are called "experiences" and they include information about a project: its context, its analysis, its solution, its deployment and its closure. All these experiences are stored in a database to be reused, once adapted, in new cases.

The paper is organized in five sections. ─ In section 2, the general principles of BP are presented. BP is positioned in a project management frame and set as the initial phase of the project. ─ In section 3, the concept of BP risk is shown and a risk model called "CEMDEx" is proposed to store all relevant information dedicated to risk management. ─ In section 4, the BP experience is presented and put in relation with the risk management process. ─ The general approach of BPRM methodology is detailed in section 5. Here, the operating mechanisms of the proposed LLS are explained. ─ Conclusion and perspectives are discussed in the last section.

Bidding process and project cycle

Bidding is a global process in which two entities are involved. The first one is the customer who makes a call for tenders for works, supplies or services; and the second one are the different bidders who respond to this request based on formal client requirements [START_REF] Botero | Integration of experience feedback into the product lifecycle: An approach to best respond to the bidding process[END_REF]. This process includes the steps of receipt of invitation to tender, feasibility study, decision making (go / no go), technical offer development, cost estimation and negotiation [START_REF] Botero | Risk analysis in project early phase taking into account the product lifecycle: Towards a generic risk typology for bidding process[END_REF]. BP is part of a more global process, which is the actual project cycle [START_REF] Wang | Research on project selection system of pre-evaluation of engineering design project bidding[END_REF]. A descriptive BP model and its positioning in the project cycle are introduced in Fig. 1. This model presents the classic project steps (client process) and their correlation with BP extended to development cycle (supplier process). The project steps related to BP are: expression of needs, feasibility and, if the offer is accepted, development.

For a project that involves a call for tenders' procedure, the request is made during the phases of expression of needs and feasibility study (cf. Fig. 1). In these steps, formal requirements are established, criteria on which the project will be evaluated are defined, and the call for tenders is issued. This invitation is received by several bidders who respond depending on their capability and their interest in the project.

For bidder, BP includes the request analysis (from call for tenders to "go / no go" decision) consisting of a feasibility study and decision-making steps. This decision is based on the ability to meet customer demand but also on bidder competitive and commercial strategy. The next step, technical offer design, which consists in drawing up the client proposal, is essential because future design scenario must be considered in order to develop an adapted proposal that meet both client specifications and sup-plier constraints. Then, costs are estimated in order to establish the price of the offer based on resources to be used and on expected gain. The negotiation phase consists in sending the offer to the client and discussing with him on technical and economic issues that can arise. This last step leads to a positive or negative response from the client.

Fig. 1. BP and project cycle

If the bidder's offer is accepted, the development phase begins. This product development cycle includes the steps of preliminary design, detailed design, production and delivery [START_REF] Cross | Engineering design methods: strategies for product design[END_REF]. A control phase from the client process to the bidder process occurs to inspect the expected characteristics. Finally, the product is delivered for its use by the client.

BP has several critical features. This process has a short duration (bidders often have little time to prepare the proposal) and, very especially, it is conducted under uncertainty (since the product does not exist yet and since the available information is not always reliable). It has a big impact on the whole project since BP set up the conditions for future development [START_REF] Chalal | An approach for a bidding process knowledge capitalization[END_REF]. These characteristics impose severe constraints and expose the bidder to different kinds of risk. The first level of risk is associated with the client decision (acceptance or rejection) and the second one is related to the project development where bidder can be penalized (several reasons are possible: lack of skills, cost overruns, delays…). Note that an upstream risk can also be associated with the "go / no-go" decision in relation to the project interest the bidder may have.

BP risk and CEMDEx model

A classic view of risk is related to the perception causes / consequences of an unwanted event. Risk is associated to the occurrence of this event correlated with the consequences it induces [START_REF] Gouriveau | Risk management-dependability tools and case-based reasoning integration using the object formalism[END_REF]. The occurrence context of an unwanted event establishes the hazard and, depending on this, the potential consequences can be more or less serious.

A risk model that integrates this characteristic has been developed in previous work [START_REF] Botero | Risk analysis in project early phase taking into account the product lifecycle: Towards a generic risk typology for bidding process[END_REF]. This approach takes into account external factors present in the context (that may increase or reduce the consequences). In addition, the "control" aspect is integrated to represent actions carried out on causes and on consequences.

In order to manage BP risks, it is very important to define risk in this context. Since BP is an upstream phase of a project and since the whole project cycle is considered for risk management, definitions of risk in the broad sense and of project risk in particular have been used to establish the following BP risk definition: "BP risk is associated with the occurrence of an unwanted event whose occurrence affects, firstly, acceptance objectives and, secondly (if the proposal is accepted), the objectives of quality, cost and timeliness".

Regarding an unwanted event, several properties characterize the associated risk and its possible management. In this regard, an adapted risk model has already been developed [START_REF] Botero | Modèle des risques pour les soumissionnaires aux appels d'offres[END_REF]. It allows understanding all the useful features to inform the processes involved in BPRM methodology. Five aspects are highlighted in this representation, forming the five dimensions of the CEMDEx model (Causes, Effects, Mapping, Description, and Experience) introduced in Fig. 2.

Effects or consequences (<E>).

As was done for the causes, effects of unwanted event are split up according to the partition "external / internal effects". In this case, external effects include all effects affecting the bidder outside context in relation with

FORM OR MAPPING <M>

• Anticipated event that did not occurred ( )

• Anticipated event that occurred ( )

• Unanticipated event that occurred ( )

EXPERIENCE CATEGORY <Ex>

• conservation

• avoidance • reduction • transfer 4. DESCRIPTIVE CHARACTERISTICS <D> • Occurrence • Impact • Detectability • Risk level • Trust-level

MANAGEMENT ACTIONS

the current BP. The internal effects include all effects affecting the bidder context. Effects in relation to the client and the environment are identified as external effects, and effects related to the project and the product are identified as internal ones. Like for causes, subclasses (organizational, technical, financial, human and juridical) may be associated with each effect.

Form or "mapping" (<M>). This dimension allows clarifying the number and form of dependencies between the possible causes of an unwanted event and its effects. Four basic forms may be considered with respect to the generic risk representation: i) one cause to one effect, ii) one cause to multiple effects, iii) multiple causes to one effect, and iv) multiple causes to multiple effects. Considering "multiple causes to multiple effects", aggregation operators (conjunctive or disjunctive) must be defined and have an important impact on the adopted risk management strategy. For instance, the application of "cause avoidance" techniques is, a priori, more favorable to conjunctive causes than those of disjunctive (in the first case, avoidance of one possible cause is sufficient to exclude the occurrence of the unwanted event).

Descriptive characteristics (<D>).

The main descriptive characteristics in quantitative terms are the following properties: i) occurrence (often expressed with probabilities), ii) impact or severity (often expressed with scale of values), iii) detectability (expressed as binary or gradual value), iv) risk level (often expressed by the product of occurrence and impact), and v) trust-level (confidence level expressed as gradual value). Qualitative characteristics are those that describe the management actions carried out (or likely to be carried out). This description combines classically choices and actions of conservation (passive risk acceptance), avoidance (actions to avoid causes), reduction (actions to limit consequences), and transfer (insurance).

Experience category (<Ex>)

. This last dimension refers to risk scenarios already found in past experiences; it is directly related to the LLS. In the context of past BP, several risk scenarios for the project development have been identified. Starting from risk associated with an unwanted event, a risk can be: i) anticipated and not occurred (a risk that should not have been considered or, on the contrary, a risk for which actions carried out avoided its occurrence), ii) anticipated and occurred (a risk for which actions carried out were not enough), and iii) unanticipated and occurred (a risk in which the analyst did not think).

This generic BP risk model can be refined according to the system to be developed (product/service). This representation is exploited in decision-making processes involved in the BP different phases. For more information about CEMDEx see [START_REF] Botero | Modèle des risques pour les soumissionnaires aux appels d'offres[END_REF].

Experience concept and BP guideline

In order to carry out activities related to LLS (capitalization, processing and exploitation) [START_REF] Rakoto | Integration of experience based decision support in industrial processes[END_REF], an experience vector (set of structured information eventually nested) has been proposed. It allows to record all relevant information to the implementation of a LLS towards BP risk management and is made of five elements: i) the "context" describing the current BP framework, ii) the "analysis" conducting feasibility studies and risk analysis, iii) the "solution" describing the technical and commercial offer, iv) the "deployment" presenting the product development as well as the encountered difficulties (if the offer is accepted), and v) the "closure" giving the final risk analysis and synthesis of the project. This experience vector has been implemented in a LLS computerized fact sheet that allows capitalizing and exploiting experiences in a practical way. This sheet aims to trace BP (extended to the project) in order to facilitate the extraction of information and to simplify the mechanisms for its reuse during a new BP. A key aspect of this tool is to provide the full traceability of the expert reasoning when dealing with risks during a BP. In particular, special information fields have been developed to include (eventually) expert comments.

Based on this experience frame, a guideline with six stages for processing a new BP is offered: i) fact sheet assignment, ii) similar experiences lookup, iii) risks extraction and analysis, iv) offer estimation (quality, cost and timeliness), v) solution deployment, and vi) final risk analysis and project closing. Coupling between the BP stages, the experience vector and the offered guideline is given on Fig. 4.

General approach for BP risk management

The previous guideline for BP risk management allows both to lead BP effectively and to lead risk management in accordance with ISO 31000 [START_REF]Risk management -Principles and guidelines[END_REF]. Indeed, our BPRM methodology follows, in an original manner, the stages of risk management, which are: communication, context set up, risk appreciation (identification, analysis and evaluation), treatment and monitoring. Fig. 5 illustrates risk management mechanisms involved in the BPRM methodology via the LLS. The first step consists in requesting the LLS database in order to find relevant experiences for a new case . This request may use three lookup mechanisms: i) similarity of experiences (considered as a whole), ii) similarity of risks associated to specific context elements of experiences (stored in past experiences for each risk) iii) search for peculiar risks (according to the expert knowledge and know-how).

Step 2 returns inferred risks to be studied drawn up from full experiences and specific risks . This risks list can be completed by letting the analyst add new risks (no previous occurrence). Such risks are conformant to the CEMDEx model.

The third step involves the transition from assessed risks to retained risks (risks to be considered in current BP) . Each risk component must be adapted to the current case. This can be done through the analyst expertise (or eventually by using automated rules). Again, a particular attention has been paid to capitalize the analyst reasoning trace for each risk analysis ("risk trace" history is available) .

Finally, step 5 concerns the transition between considered risks (in BP phase) to effective risks occurred during the project execution . Here, the provider can see if the implemented risk strategy was adequate (pertinence of retained risks and effectiveness of the corresponding risk management actions).

Note that, even if last step of risk management cycle (monitoring) is not explicit in Fig. 5, it is implicit in the methodology because, through the LLS implemented, risks are under control, and revision and updates are systematically carried out when the risks adaptation for new cases of BP is made.

Conclusion and perspectives

Bidding process (BP) is an unavoidable and risky practice for companies that respond call for tenders. The BPRM methodology was proposed so as to give such companies a tool to control the different kinds of risk associated to tenders. The originality of this work is the coupling of risk management with a lesson-learnt system (LLS).

The first contribution was to define what essentially is a BP Risk. A generic model called CEMDEx has been used for this purpose. The second contribution is the proposition of a guideline that helps following BP while capitalizing all related information in concordance with, not only BP, but with the whole product cycle. This ends up in an information vector called "experience" that is stored for later reuse and which is the central part of the LLS.

Up to now, a fact sheet representing an experience has been implemented and several lookup mechanisms have been designed. Capitalization of the expert reasoning (trace) was our first concern and although exploitation mechanisms are not yet implemented. The usage of a flexible model and its associated meta-model have been decided to be able to implement different lookup strategies (based on similarities).

Fig. 2 .

 2 Fig. 2. CEMDEx modelCauses (<C>). According to the classification of risk factors for an unwanted event proposed in[START_REF] Alquier | Analysis of external and internal risks in project early phase[END_REF], a partition "external / internal causes" has been created. In this approach, external causes include all causes from the bidder outside context in relation with the current BP. Internal causes include all causes which are specific to the bidder context. Classes included in these two categories are respectively client causes, competition causes and environment causes for external causes, and strategy causes, project causes and product causes for internal ones. Each class may have other specific subclasses, which are typically: organizational, technical, financial, human and juridical ones.

R

  BP = {<C>, <E>, <M>, <D>, <Ex>}

Fig. 3 .

 3 Fig. 3. Experience vector

Fig. 4 .

 4 Fig. 4. Matching between Experience, RM and LLSNote that correspondence between these three elements is straightforward. Each BP stage (extended to project) matches an element of the LLS fact sheet (the description of the experience) and a phase of the advisable guideline.

Fig. 5 .

 5 Fig. 5. Operating mechanisms of LLS database for risk management in BP


Onur Yildiz
email: oyildiz@audros.fr

Nada Aouadi

Aimad Karkouch

Philippe Pernelle
email: philippe.pernelle@univ-lyon1.fr

Lilia Gzara
email: lilia.gzara@grenoble-inp.fr

Michel Tollenaere
email: michel.tollenaere@inpg.fr

MDA based tool for PLM' models building and evolving

Keywords: PLM system, MDA, metamodel, constraint, OCL, transformation, ATL

Product Lifecycle Management (PLM) systems are sufficiently generic to propose models adapted to companies' specific needs without additional development. However, the implementation of such systems and their multiple reconfigurations may introduce coherence problems. To ensure structural and functional coherence while creating and evolving PLM models, a methodological approach is described in this paper. The proposed approach is based on Model Driven Architecture (MDA) principles in order to allow : [1] models' creation while respecting syntactic and semantic constraints, [2] models' evolution while respecting dependencies between the various PLM syste' components. This approach is being prototyping based on Eclipse framework.

Introduction

Nowadays, industrial companies using PLM systems need to deploy models which are adapted to their requirements. PLM are information systems dedicated to managing the entire lifecycle of a product, from inception, through engineering design and manufacture, to service and disposal of manufactured products. In this research, we are focusing on these models' building and reconfiguration, more precisely from a PLM editor/integrator point of view. These models are generic enough to propose ones that can be adapted to each company' needs by doing some additional developments. However, in the case of initial PLM deployment, the elaboration of a PLM system that complies with the company's activities often requires one or more specific data models and a set of specific functions (processing).

Usually, the idea is to adapt the generic model, based on a set of templates which correspond to typical business needs (such as Catia data management, ProEng data management, MS Office reporting, etc.) so to reduce workload. Data model definition must be validated in order to avoid inconsistencies. This validation step consists of respecting a set of structural and functional predefined constraints. Thus, any new data model creation can be used permanently after the validation of data coherency.

Similarly, the various evolutions of already deployed systems made to adapt or add new functions in the data model are very difficult to perform for a company. In order to achieve this, companies are often accompanied by an editor or an integrator. In fact, a company must adapt to the ongoing development of its market or to any changes in its working methods. Therefore, it's often required to change the existent data model or system functionalities. But, in most often cases, these companies are not able to identify the impact of these changes ; there isn't any tool allowing them to have a global vision of the deployed PLM system in terms of components' dependencies. Without this global vision, changes may cause coherence problems or side effects. Thus, the phases of models' creation and evolving imply setting up a methodological approach for creating or maintaining the implemented system with a structural and functional coherence.

This research work aims at helping companies when they configurate or evolve their PLM system. The proposed approach consists of building a generic business model and providing a set of mechanisms to transform this generic business model into specific models according to each company' specificities. This approach is based on MDA. The rest of the paper is organized as follows. Section 2 describes the foundations of proposed approach using MDA. Section 3 gives the principles of proposed approach deployment. Section 4 describes the software prototype developed to support eh approach and finally section 5 gives some conclusions and perspectives.

2 Proposed approach foundations [START_REF] Bezivin | Towards a precise definition of the omg/mda framework[END_REF] is an architecture derived from MDE (Model Driven Engineering) approach proposed by OMG (Object Management Group). MDA uses the concepts of MOF (Meta-Object Facility) [START_REF]OMG: Meta object facility[END_REF] and UML (Unified Modeling Language). It is based on multilevel modeling (or metamodels) and mechanisms for models' transformations. The MDA logic is to propose a refinement of models from a high level of abstraction to executable code. The fundamental rule of MDA is to separate the business logic from the implementation one. According to the three level approach proposed in MDA, models or metamodels are defined by a process of abstraction towards target platforms : Computation Independent Model (CIM), Platform Independent Model (PIM) and Platform Specific Model (PSM). In the rest of this section, we will describe these levels and mechanisms of transition between models of different levels.

MDA [6] [7]

Metamodeling within MDA

A metamodel aims to define the main concepts to be used in the PLM models [START_REF] Terzi | A holonic metamodel for product lifecycle management[END_REF] [START_REF] Duigou | Framework for plm integration in smes networks[END_REF] . These concepts must be independent of the PLM system. They are used to characterize the conformity of the lower level models. The proposed elements in our metamodel [START_REF] Yildiz | Mda approach for plm system design[END_REF] (fig. 1) describe the structural, behavioral and invariant concepts to be used in a PLM system. The diagram below shows the generic reduced metamodel with basic concepts for modeling business model. The fundamental metamodel elements make it possible to structure concepts in order to be used and deployed in a company. These concepts are structured according to descriptive elements (BusinessObject, AttrSpecific), structural relationship (FunctionnaLink), dependency relationship (RelationalLink) and Life cycle Management elements (LifeCycle). Business Rule concepts (BusinessRule) have to be considered as constraints that ensure business model consistency.

These concepts would enable building compliant business models. The business model includes business as in the activity sector and information system. This is justified by the fact that final implementation should respect PLM concepts (regardless of the platform). Therefore we believe to be consistent with the MDA approach "spirit" (the CIM is independent of execution platforms).

Validation and Conformity of models

The metamodel described in previous section is part of the proposed approach for building and reconfigurating PLM models process.It is one element among others that allow developing consitent models . There is no standard metamodel. However, several studies have attempted to propose reference models [START_REF] Sudarsan | A product information modeling framework for product lifecycle managemen[END_REF] [START_REF] Eynard | Pdm system implementation based on uml[END_REF] .The proposed metamodel in this paper is generated from an abstract approach of these reference models . Concepts defined in metamodel are not always enough for the construction of robust models (they are not very sensitive to the context modifications). In fact, we used constraints in order to successfully express restrictions on built models [START_REF] Cabot | Transformation techniques for ocl con-straints[END_REF], constraints must be defined.

A constraint represents a boolean-valued expression which can be attached to any metamodel element. It generally indicates a limitation, or gives further information on the model. They are used in most cases to specify invariants on the meta classes. These constraints complete existing diagrams by implementing business rules and making relationships more precise (without ambiguities). To add constraints on proposed models, we choose to use the Object Constraint Language (OCL) [START_REF]OMG: Object constraint language omg available specification ver-sion[END_REF].

The model is a level (PIM) of modeling which has to enable implementing business concepts within a PLM system. In the context, the modeling is not unique and can evolve in time. The business concepts defining the models of this level characterize a contextual business terminology. Here the contextual meaning implies a low level of invariance for two reasons. On one hand concepts treated are very specific for industrial sector and the concepts used involve a certain ambiguity, on the other hand concepts treated are evolving over time

Model transformations

The aim of our proposal is to facilitate the conception and implementation of business models in PLM systems. Therefore, Meta Models of proposed approach (PIM level) have to be transformed into models that are dependent on target platforms (PSM level) according to the main steps of MDA approach. The last level, achieved by PSM generation, is then obtained by transformations between different levels, from CIM to PIM and from PIM to PSM A PIM to PIM transformation consists of transforming a metamodel while respecting associated constraints. Likewise, a PIM to PSM transformation corresponds to the transformation of an independent functional model into a platform compliant model (with constraints specific to the chosen platform).

The transformation process could be described as a succession of 2 stages. In the first stage, the target metamodel is defined, and then mapped with the source meta-model. Mapping task is implemented using transformation rules. These rules allow producing a target model (conform to the target metamodel) starting from a source model (conform to the source metamodel). The second stage consists of executing the model transformations rules in a particular language (in our case, in SQL (Structured Query Language) script). Indeed, the PLM system configuration and data are stored in a database. Then, the last step of transformation process should make it possible to add, delete and update these data within the database. To sum up, a source model allows producing a target code thanks to the transformation process with Atlas Transformation Language (ATL) As stated previously, providing generic concepts is not of much help when it comes to identifying enterprise's business concepts. This is because, most of the time, the experts to set up the PLM, are either business experts or IT experts but rarely both. On the one hand, our modeling's approach is independant of software tools and highlights the generic concepts of a PLM information system and business domains. On the other hand, we strongly believe that it should be supported by a methodological approach where various experts may simultaneously contribute to the business models' construction.

The suggested approach is based upon business-domain segmentation. Some business objects are well standardized to be used, as they are, in the enterprise. The main existent systems offer preconfigured models to ease building enterprise own business models and thus accelerating domain-specific model creation. The above-mentioned approach consists of building, progressively, parts of models by IT and business experts using each domain's invariant elements and business rules validation.

Specific templates

The domain is used to group concepts with adaptable granularity. In addition, some domains are sufficiently invariant (or normalized) in companies to be used as they are. We could mention for example : changes management domains, Engineering Change Request (ECR), Engineering Change Order (ECO) are CAD (Computer Aided Design) data management domains (part, assembly, ...). These domains can be elaborated by IT or business experts and then integrated progressively into the construction of the global PIM.

Business rules

Business rules Business rules characterize PIM or PSM concepts constraints and are, as mentioned before, described using OCL [START_REF] Dang | Automating inference of ocl business rules from user scenarios[END_REF]. In the proposed methodological approach, they are used during the explicit validation, in addition to metamodels' implicit validation. Thus, business rules can be defined during every step during PIM and PSM construction. Similarly to domains, there could be two types of business rules : information system rules, business activity rule.

Models updates

In order for a company to continuously take into account economical environment changes, its information system and therefore its PLM system should be adapted. Updates can be identified at two levels : PSM's level and particularly its instance within the PLM (for example : adding some specific script) , PIM's level (for instance : business object modification, adding links, ...)

The advocated methodological approach is dual. On one hand, it is to make reverse transformations from instantiated PSM to PIM. On the other hand, it is to provide PIM comparisons. This approach will enable experts to measure the impact of changes applied to the PLM.

Application

The suggested approach based on MDA is supported by a framework implementing models transformations and constraints validation mechanisms [START_REF] Yildiz | A framework for plm model design[END_REF]. This framework is built on top of Eclipse platform and its extending capabilities likes EMF (implementation of the MOF providing tools for implementing DSLs (Domain-Specific languages). This framework is a way to verify and validate concepts introduced in the first part of this article.

Business model modeling

The construction of business model is done thanks to a graphical editor based on Eclipse GMF (Graphical Modeling Framework). This editor allows user creating his own business concepts based on a generic metamodel. The following diagram (Fig. 2) represents a business model with constraints. A violated constraint is marked with a red cross (i.e a BusinessObject can not have an empty name).

Audros metamodel

In order for the model to be exploitable, an SQL script needs to be generated and applied to the PLM system. To achieve this, a metamodel defining Audros PLM's concepts have been created

The main goal is to generate an Audros model conform to the Audros metamodel from a business model edited with GMF conform to the business metamodel (introduced in the first part) by means of ATL transformation. The transformation results in a compliant Audros model. The transformation is done by iterating over the input model's content, comparing this content with the source patterns (correspondence rules defined in the .atl file) and producing target patterns in the target model whenever a matching occurs.

The following figure (Fig. 3) shows a case of ATL correspondence rule defined between the two metamodels. This rule takes a BusinessObject (defined by Audros metamodel) as an input and transforms it into an Object Class (defined by Database metamodel). The whole transformation process is used to translate and inject the Business Model into the database, to become accessible and usable within the PLM. The obtained specific model is not yet exploitable in Audros PLM. It needs to be transformed into an SQL script to inject into the system database using existent tools in Eclipse (Acceleo and Liquibase).

The following figure (Fig. 4) illustrates Audros PLM's final state after the transformations' sequences applied to the model introduced earlier in this paper (the objects are usable within the PLM).

Conclusion

The research work described in this paper aims at helping companies when they configurate or evolve their PLM system. The proposed approach consists of building a generic business model and providing a set of mechanisms to transform this generic business model into specific models according to each company' specificities. The proposed approach is based on a model-driven architecture (MDA). One of the main goals of this approach, besides creating adequate models, is providing controlling mechanism in case of models evolution in order to keep total consistency in PLM systems. In the proposed approach, companies' specific needs are implemented through a refinement of models from a high level of abstraction to executable code. For that aim, three modeling levels are defined (CIM, PIM, PSM) and a set of transition mechanisms between levels is given. This approach is supported by software prototype which allows implementing concepts proposed in this paper. In this article, we concentrated on business model creation methodology. Now, a reflexive posture is conducted to address business model evolution methodology that ensures semantic and syntactic coherence with already existing PLM components.

Fig. 1 .

 1 Fig. 1. Extract from Business metamodel

Fig. 2 .

 2 Fig. 2. Business model with constraints

Fig. 3 .

 3 Fig. 3. ATL rule

Fig. 4 .

 4 Fig. 4. Audros PLM result