Linda Elmhadhbi
email: linda.elmhadhbi@enit.fr

Mohamed Hedi Karray
email: mkarray@enit.fr

Bernard Archimède
email: bernard.archimede@enit.fr

'()"*+,$'$-."/$)"012(+,34(''." 5+6(+41%"7+,1)$81)(93'3,."3+" *81)(,3$+('":3;(;,1)"<1;8$+;1"

9;,)(4,"

Up to now, the world has witnessed how inadequate communication capabilities can adversely affect disaster response efforts. There are various Emergency Responders (ERs) that potentially must work together towards a successful resolution of the disaster. However, the different terminologies and technical vocabularies that are being exchanged between the ERs may lead to a misunderstanding and lack of semantic integrity. Yet, understanding the semantics of the exchanged data is one of the major challenges. The purpose of this work is to define the complex knowledge of the ERs by proposing a common and modular ontology shared by all the stakeholders so as to come up with a common shared vocabulary in order to ensure semantic interoperability between ERs. In this paper, we present POLARISCO and we discuss how it was developed using Basic Formal Ontology as an upperlevel ontology and Common Core Ontology as a mid-level ontology to define each module.

=1.>$)%;!

Semantic interoperability,!modular ontology, upper-level ontology, mid-level ontology, disaster response. 7?@<*:AB@7*?" When a disaster occurs, a streamlined operational response organization is crucial to handle the disaster effectively. So as to respond within seconds, an appropriate and effective response depends on a detailed plan with clearly articulated roles and responsibilities. It involves a complex network of diverse Emergency Responders (ERs) from different Emergency Response Organizations (ERO) such as firefighters, police, health care services, etc. In fact, numerous after-action reports from major disasters (11 September 2001 and 13 November 2015 terrorist attacks, Hurricane Katrina, etc.) have cited communication difficulties among EROs as a major failing and challenge. The absence of adequate communication and information sharing between the involved actors in disaster response may lead to a break down at the operational response, stakeholders will not know what is happening exactly which will consequently extend the time required to bring a full resolution of the disaster while time is an important factor that has to be considered. Respectively, communication during a disaster is primordial. Information is the most valuable commodity during disaster response. ERs necessitate an ample need for timely information sharing and data exchange to obtain a real-time operational picture of the situation. But, each ERs has its own technical vocabulary. As a result, this discrepancy of information leads to a misunderstanding, a deficiency of semantic interoperability and lack of information sharing among the different actors. This can make the operational response process slow and inefficient. In this work, we aim to define the complex knowledge of the different ERs (firefighters, police, gendarmerie, health care services, etc.) so as to come up with a common shared vocabulary in order to provide the appropriate information at the right place and in the right moment (van Borkulo et al., 2006). Once this task is fulfilled, ERs can operate together and especially can understand each other in any critical situation which is the key to a better operational response [START_REF] Zlatanova | 3D technology for improving Disaster Management: GeoDBMS and positioning, S[END_REF]. To do so, a modular ontology has been developed to explore the semantics of the different ERs in the context of the project POLARISC (Plateforme OpérationnelLe d'Actualisation du Renseignement Interservices pour la Sécurité Civile) (Elmhadhbi et al., 2018). It is a French project which started in 2017. It proposes an interoperable inter-services software solution for reliable and timely information sharing for the operational management of large-scale crisis situations. The focus is about offering to all ERs a real-time operation picture of the situation in order to enable multistakeholders and multi-level coordination within the EROs including firefighters, police, gendarmerie, healthcare services, and public authorities. The proposed ontology POLARISCO (POLARISC Ontology) is the core of the system. It will be shared by all the stakeholders in order to enable semantically interoperable information exchange and a common understanding of what is happening on the field. Specifically, it employs Basic Formal Ontology (BFO) as an upper-level ontology and Common Core Ontology (CCO) as a mid-level ontology to present seven ontological modules. This paper is organized as follow. In section2, we overview the main ontologies related to operational disaster response. Section 3 goes into the details of the process of the development of POLARISCO then we present the proposed modules. In section 4, we discuss how POLARISCO is evaluated and is used as a shared vocabulary in a messaging service to enable semantically interoperable information exchange among ERs. Finally, conclusion and future work about our ontology use are presented.

<1'(,1%">$)C"

The different interpretations of data cause semantic heterogeneity. To overcome semantic heterogeneity and to guarantee a consistent shared understanding of the meaning of information, the use of ontologies is crucial (Antunes et al., 2013). Ontologies have been identified as an effective means to implement semantic integration and achieve information interoperability. Ontologies are expressed in a logic-based language, so that accurate, consistent, and meaningful distinctions can be made among the classes, instances, properties, attributes, and relations to reveal the implicit and hidden knowledge in order to understand the meaning of the data. Thus, they offer the richest representations of machine-interpretable semantics for systems and databases. They serve as both knowledge representation and as mediation to enable heterogeneous systems semantic interoperability. With the increasing amount of data coming from different sources, there is a strong need to determine the meaning of the information to be exchanged precisely enough that a software application can interpret them [START_REF] Nunavath | Data Sources Handling for Emergency Management: Supporting Information Availability and Accessibility for Emergency Responders[END_REF]. So many application of ontologies addresses the problem of semantic interoperability, in which we have different users using various software tools that need to cooperate by exchanging data with unambiguous, shared meaning. In the literature, different types of ontologies and meta-models have been proposed to define the concepts related to disaster response. However, these latter are restricted to one EROs or to a specific case or purpose [START_REF] Liu | Ontologies for crisis management: A review of state of the art in ontology design and usability[END_REF]. EMERGEL Ontology, proposed in the context of DISASTER project [START_REF] Casado | Data interoperability software solution for emergency reaction in the Europe Union[END_REF], mainly focusses on the mapping of different predefined information's artifacts, information representation and language between countries in Europe. It is composed of a core ontology (events, agents), a transversal module (time and space) and a vertical module (organization's specifications). It reuses the class event of the upper-level ontology DOLCE and other vocabularies such as FOAF [START_REF] Graves | Foaf: Connecting people on the semantic web[END_REF] (peoples in an emergency situation) and the Organization ontology. However, this ontology lacks specific operational information (technical vocabulary of each ER). It can be more useful in decision making at the strategic level rather than the operational level. Moreover, Authors in [START_REF] Fan | Exploring ontologies for semantic interoperability of data in emergency response[END_REF] looked for solving the problem of spatial data heterogeneity in emergency situations and their transmission to stakeholders by proposing an ontology. SoKNOS ontology (Babitski, 2011) includes resource planning, damages, and geo-sensor information. Regarding EDXL-RESCUER ontology [START_REF] Barros | EDXL-RESCUER ontology: Conceptual Model for Semantic Integration[END_REF], it employs EDXL (Emergency Data Exchange Language) to model the coordinating and exchanging of information with legacy systems. The focus is mainly on alerting people. Another ontology is proposed in [START_REF] Chehade | Data Interpretation Support in Rescue Operations: Application for French Firefighters[END_REF] for representing situations during rescue operations in order to support situations awareness. It aims to support French first responders in data interpretation during rescue operations. However, on one hand, the proposed ontology is not evaluated and implemented yet, on the other hand, it is dedicated only to firefighters and health care staff. In [START_REF] Chan | Public Safety and Emergency Management Communications Ontology[END_REF], authors proposed PS/EM Communication ontology (Public Safety and Emergency Management) in the context of IDA project (Institute for Defense Analyses). They were based on EDXL (Emergency Data Exchange Language) standards including resource messaging distribution element, hospital availability exchange and common alerting protocol. The ontology was constructed by adding specializations of the BFO and CCO classes. However, this ontology doesn't cover all type of communication between ERs, it is focused on alert messages. To summarize, during our literature review, we found several ontologies developed in the context of disaster response. However, from one hand, these ontologies don't cover the knowledge of the different involved actors (firefighters, health care services, public order forces, public authorities, etc.) in the disaster response process.

From the other hand, they don't define the technical vocabulary that is used in the operational response such as action centers, functional sectors, operational roles, specific means and so on. ! D*E!<70B*"*?@*E*FG"

In this work, we propose a modular ontology in order to capture the knowledge of the various stakeholders in a formalism reducible to a logic that expresses logical relationships between the different concepts, and to provide a foundation for semantic interoperability between diverse ERs. The aim is to ensure that all parties share the same extent of such derived information. That is, it aims to establish a common understanding of the shared information.

To build the proposed ontology, a methodology that guides and manages the development process is primordial. In fact, the efficiency of an ontology depends extremely on its development methodology. In [START_REF] Karray | A formal ontology for industrial maintenance[END_REF], authors discussed the various methodologies proposed in the literature. In this work, we adopted METHONTOLOGY [START_REF] Fernández-López | Methontology: from ontological art towards ontological engineering[END_REF] as a development methodology. According to [START_REF] Corcho | Methodologies, tools, and languages for building ontologies. Where is their meeting point?[END_REF], it is the most mature approach to build an ontology. This methodology consists of five main steps of development activities: specification, conceptualization, formalization, implementation, and evaluation.

08143/34(,3$+"

We started by identifying the purpose of defining this ontology. To do so, interviews were conducted with stakeholders and emergency experts so as to capture their needs and to analyze their experiences feedbacks. So, POLARISCO is a domain ontology built with the main goal of making the best possible definition of stakeholders' technical vocabulary. It was developed for establishing a common shared conceptualization that defines concepts and their relationships to support semantically interoperable information exchange among ERs involved in the process of operational disaster response. Afterwards, once the objectives are fixed, we used Competency questions (CQs) as a technique to define the ontology specifications. CQs consist of a set of question that the ontology must be able to answer [START_REF] Grüninger | The role of competency questions in enterprise engineering[END_REF]. SO, POLARISCO should be able to answer the following defined CQs: CQs1: When did the disaster [X] take place? CQs2: Where did the disaster [X] take place? CQs3: Who were the involved ERs in the intervention [X]? CQs4: Who was the operational commander of the intervention [X]? CQs5: Who was the public authority that commanded the intervention [X]? CQs6: What were the acts of the intervention [X] of the ER [Y]? CQs7: How many victims were resulting from the disaster [X]? CQs8: What was the state of the victim [X]? CQs9: What means were used in the intervention [X]? CQs10: What are the available means? CQs11: Where was located the action center [X] of the ER [Y]? CQs12: Who are the sender and the receiver of the message [X]? CQs13: What is the type of the message [X]? CQs14: How many beds are available in the hospital [X]?

Regarding the diversity of ERs' vocabularies and process of intervention which may lead to a complexity during the knowledge conceptualization, we adopted the principles of modularization to build our ontology. Modularization is considered as a way to structure and organizing ontologies. Thus, the construction of a large ontology is based on the combination of self-contained, independent and reusable modules [START_REF] D'aquin | Ontology modularization for knowledge selection: Experiments and evaluations[END_REF]. The main advantages of such a method, are manipulating smaller ontologies, reducing the complexity of ontologies development, and reusing each module independently. The idea is to develop separate ontological modules so that they could stand alone. Then, to acquire knowledge about the field of disaster response, we conducted interviews with stakeholders of each EROs (firefighters, health care services, police, gendarmerie and public authorities) and we studied their technical resources and feedback documents to get specific and detailed knowledge about concepts, their properties, and their relationships. On the other hand, we studied many ontologies proposed in the field of disaster response to identify the needed terms including EMERGEL and RESCUER-EDXL, EDXL-RM (Resources Messaging), etc.

B$+418,&('3H(,3$+"

In this phase, the domain knowledge is structured in a conceptual model. We first defined five modules to encapsulate the knowledge of the different involved stakeholders namely firefighters' module, health care services ! module, police module, gendarmerie module, and public authorities' module. Then, we defined a message module to represent the needed knowledge to formalize information exchange among ERs and to improve communication capabilities. After that, we built a Glossary of Terms (GT) for each module by referring to the knowledge elucidated during the acquisition step. Terms include classes, properties, instances, and relations that exist among the different classes. As a matter of fact, we found that there are several terms in common between the stakeholders' defined modules which led us to define a core module named PCO (POLARISC Common Core). It englobes the general terms that all stakeholders share (for example disasters, transmission means, victims, etc.) in order to ensure more semantic interoperability between the modules and to facilitate their integration. Next, we selected an upper level ontology as a foundation that provide the most abstract upper level classes to define the more specific information. In (Elmhadhbi et al., 2018), several upper level ontologies have been discussed and we argued our choice of BFO as an upper-level ontology and CCO as a mid-level ontology. In fact, BFO (Arp et al., 2015) is a realist, formal and domain-neutral upper-level ontology, it is designed to represent at a very high level of generality the types of entities that exist in the world and the relations that hold between them. It is utilized as a starting point for the categorization of entities and relationships by more than 250 domain ontology including an ontology-based system used by the US army. As a starting point, BFO uses the term entity as a common representation of anything then there are two main division of the class entity: Continuants and Occurrents in a single framework as a top level distinction between entities. Continuants are entities that persist through time including three axes; objects (Material entity) or and spatial regions (Immaterial entities) as Independent continuant, functions and qualities as Specifically independent continuant and finally, Generically dependent continuant. Occurrents are entities that happen or develop in time such as process. BFO was then supplemented with a set of mid-level ontologies CCO [START_REF] Rudnicki | An Overview of the Common Core Ontologies[END_REF] which are the Information Entity Ontology, the Agent Ontology, the Quality Ontology, the Event Ontology, the Artifact Ontology, the Time Ontology, the Geospatial Ontology, the Units of Measure Ontology, the Currency Unit Ontology, and the Extended Relation Ontology. So, in POLARISCO, classes of each module were classified according to BFO and CCO classes and properties. Figure 1 illustrates the structure of the proposed modules. The purpose behind the use of BFO and CCO is to provide a common ontological foundation for domain ontologies which describe the most general domainindependent categories of reality. It is advantageous to use a common upper layer of well-defined terms to develop the different modules since the ontology will be shared among the involved stakeholders. Indeed, the use of upperlevel ontologies facilitates the alignment between several domain ontologies and enable interoperability between them. In other words, if the ontologies to be mapped are driven from a standard upper-level ontology, this will make the mapping task very easy. In addition, upper-level ontologies play the same role as libraries in software programming tasks. Once they are used, one could reuse the defined concepts and relationships and so as to inherit the inferencing capabilities furnished by them. In this way, developing a domain ontology is an easier task that requires less time than usual. Moreover, the aim is to avoid having several incompatible domain ontologies. The usage of upper-level ontologies for integrating information and sharing knowledge among heterogeneous sources has been motivated in various related works [START_REF] Baumgartner | A survey of upper ontologies for situation awareness[END_REF] (Elmhadhbi et al., 2018). After defining the modules and the related GT, in this phase, the conceptual model is transformed into a formal model by establishing relations between concepts. To connect the different concepts, we used a hybrid approach, based on a top-down alignment to the upper-level ontology BFO and the mid-level ontology CCO and a bottom-up alignment to define classes of stakeholders' module and message module by reusing PCC module. That is to say, we approach in two ways by generalizing high-level concepts to lower levels and by abstracting the low-level data to the higher level concept. So, BFO and CCO are extended to define POLARISCO modules. In fact, CCO reuse the Relations Ontology (RO) [START_REF] Smith | Relations in biomedical ontologies[END_REF] which is a collection of OWL2 relations intended to be shared among various ontologies. Moreover, another ontology called RO-Bridge has been developed by adding domains and ranges constraints to the object properties defined in RO to be used to relate BFO classes. The relations of RO-Bridge that are reused in POLARISCO are presented in table 1. Independent continuant Independent continuant

In the following, we represent first the various classes and their relationships of PCC module that will be reused to define each stakeholder module. Figures 2 illustrate a partial view of PCC module. Classes reused from BFO and CCO are marked with a prefix. Concerning the occurrent entities, we first defined a disaster as a process, it can be natural (earthquakes, floods, tsunamis, wildfire, tornadoes, etc.) or human-made (explosion, terrorist attacks, chemical threats, etc.). Acts are performed to manage disasters in an action center which is a sub-class of spatial region. ERs' acts are done as part of a real intervention or training. These two classes are integrated as a process. Concerning the continuant entity, an act is characterized by a type depending on the nature of the disaster. Furthermore, a role is accorded to each organization member. An organization member or an ordinary person can have the role of a victim. A victim is characterized by a state. In addition, infrastructure (hospitals and digital radio networks), mean (transmission mean such as radio or telephone) and equipment (beds) are defined as an artifact. Concerning the stakeholders' modules, we formalized each one according to the PCC module. That is, we used PCC module as a starting point, and then we added the appropriate concepts related to each module. So, we defined the technical vocabulary of each ER (firefighters, health care services, police, gendarmerie, and public authorities) including mainly roles, commandment, and operational members, services, acts, means and their functions and availability, action centers, etc. Furthermore, we added the interventions' needs in terms of means and staff.!Figure 3 shows a partial view of the stakeholders' modules. Indeed, one of the principles to respect in building useful ontology is that any term of the ontology should be defined in a consistent manner (Arp et al., 2015). So, we defined annotation for each class (definition, the signification of the abbreviation, labels, etc.). Then, we defined relations that exist among the various modules and especially the equivalent classes. Each module has at least one relation with other modules. For example, the public authorities' module is linked to the rest of the stakeholders' modules with the relationship "supervises". That is to say, the interior minister supervises the commandment member of each ER. In fact, annotation and equivalent classes will have a key role later in the messaging service. Specifically, it will enhance communication capabilities and enable the transformation of the exchanged information from one stakeholder to another. So, each stakeholder will receive information according to his own vocabulary. Concerning the message module, it is related to the PCC module and subsequently to the stakeholders 'modules.

To defined it, we reused classes from PS/EM Communication Ontology [START_REF] Chan | Public Safety and Emergency Management Communications Ontology[END_REF]. Authors were based on EDXL-RM (Emergency Data Exchange Language-Resource Messaging) standards. Figure 4 shows a partial view of the proposed module. The reused classes are marked with the prefix EDXL. We defined a message as an information bearing artifact. There are three different types of messages that could be exchanged among ERs; informative message (information message, alert message, report message, etc.), request message (backup message, etc.) and response message (a response message "is_about" a request message). In addition, a message is characterized by a state (treated, untreated or ongoing), a confidentiality (public, private or limited) and a degree of criticality of the information to be exchanged (extreme, moderated or secondary). Moreover, a message is identified by an ID and the same for sender and receiver which are defined as an agent. The proposed formalization models are encoded in the ontology implementation language OWL and implemented using Protégé.

It is an open source ontology editor and framework that propose a set of tools to construct ontologies. It facilitates the definition of classes, properties, and rules, visualization and reasoning. First, we reused BFO and CCO to build the PCC and message modules by utilizing the "owl: import" feature of OWL2. Second, we imported PCC to construct the stakeholders' modules. Then the different modules are merged together and integrated into one ontology "POLARISCO". Table 2 presents the classes and relations of the global ontology. To evaluate the proposed ontology, from one hand, the consistency of POLARISCO modules was checked using the reasoner HermiT, which is an OWL2 reasoner included in Protégé. The aim is to ensure that the constructed ontology don't contain logical incoherencies or modeling issues such as contradictory relations between classes.

On the other hand, to check if the ontology responds to the fixed specifications, we translate the CQs into SPARQL (Simple Protocol and RDF Query Language) language so as to query the ontology. To do so, the ontology was instantiated using feedbacks and documents of "Richter-65". It is an exercise of simulation of an earthquake in France which involves all the ERs. One of the examples of the obtained results are presented in figure 5 to answer the following CQ: "Who are the operational commanders of the involved ERs in "Richter-65"?"

! Figure 5. SPARQL query and result of the CQ

To summarize, we proposed POLARISCO, a modular ontology that define ERs knowledge and the needed information to ensure a semantically interoperable information exchange among stakeholders. It concerns firefighters, health care services, police gendarmerie and also public authorities. The modular conceptualization of the ontology enables its reuse as separate modules. One strength point of the development of the ontology is the fact that the process of collecting information, testing and evaluating the ontology was made referring to stakeholders. In addition, the designed ontology is validated by the emergency experts. POLARISCO will be used in English or French, we are working on labelling each class of the ontology in the two languages. The global modular ontology described in this paper is available in OWL format on GitHub: https://github.com/LindaElmhadhbi/POLARISC-Ontology.

B*?BEA07*?"!?:"IA@A<5"K*<="

In operational disaster response, there are various ERs from different EROs that potentially must work together towards a successful resolution of the disaster. However, communication is still ineffective since each ER uses his own technical vocabulary without realizing that they can be referring to different concepts. As a result, a different interpretation of data may happen that handicap the response process and cause slower decision making. To resolve semantic heterogeneity among ERs, there is an ample need to define the complex knowledge of the different stakeholders. Therefore, the purpose of this work is to come up with a common shared vocabulary in order to ensure semantically interoperability between ERs. So, we proposed POLARISCO, a modular ontology that enables semantically interoperable communication among stakeholders a comprehensive operational picture of the field.

As future works, the proposed ontology can be extended to be used in the field of smart cities once it is aligned with existing standards and well-known models for smart city data. In addition, the ontology will be tested by means of a concrete use case to show how a communication act can be improved across different ERs and practitioner's feedbacks will be presented.

!B=?*KE5:F#5?@0"" This research was conducted as part of the POLARISC (Plateforme OpérationnelLe d'Actualisation du Renseignement Interservices pour la Sécurité Civile) project. It was funded by the regional operational program FEDER/FSE « Midi-Pyrénées et Garonne 2014-2020 » as part of the call for projects "Easynov2016".

<5I5<5?B50"

Antunes, G., Caetano, A., Bakhshandeh, M., Mayer, R., & Borbinha, J. (2013). Using ontologies to integrate multiple enterprise architecture domains. In International Conference on Business Information Systems (pp. 61-72). Springer, Berlin, Heidelberg. Arp, R., Smith, B., & Spear, A. D. (2015). Building ontologies with basic formal ontology. Mit Press. Babitski, G., Bergweiler, S., Grebner, O., Oberle, D., Paulheim, H., & Probst, F. (2011). SoKNOS-using semantic technologies in disaster management software. In Extended Semantic Web . Springer, Berlin, Heidelberg.

Figure

  Figure 1. The different modules of POLARISCO

Figure 2 .

 2 Figure 2. POLARISC Common Core (PCC) module

Figure 3 .

 3 Figure 3. Partial view of stakeholders' modules

Figure

  Figure 4. Message module

Table 1 . The reused RO-Bridge relations

 1

	Relation	Domain	Range
	"has_role"	Independent continuant	role
	"has_quality"	Independent continuant	Quality
	"supervises"	Person or organization Person or organization
	"has_participant"	Process	Person
	"located_in"	Material entity	Spatial region or site
	"occurs_on"	Process	Information entity
	"is_part_of"

Table 2 . Classes and relations of POLARISCO

 2

	Ontology	Number of Classes	Number of Relations
	Developed ontology
	POLARISCO	447	25
	Imported ontology
	BFO	27	-
	CCO	195	152
	Total	669	177
	5J('&(,3$+""


Carmen Martin

François Pérès

De

François Carmen Pérès

De l'incertitude sur le dimensionnement probabiliste des systèmes de production


DISASSEMBLY PROCESS PLANNING USING BAYESIAN NETWORKS

Keywords: Disassembly, modelling, Bayesian networks, uncertainties. 1

The management of end-of-life systems becomes more and more important due to the awareness of their environmental impact. In this context, the disassembly process requires more attention with the ultimate goal to make profit. In this paper, we propose a new approach to determine optimal disassembly plan of an end-of-life system by using bayesian network. To take advantage of some existing approaches that use Petri Net to model such process, a Petri Net model is first established and then translated to Bayesian Network in order to take into account inevitable uncertainties associated to such process.

INTRODUCTION

The end-of-life phase of systems life-cycle has become more and more important since several years. This is firstly due to the reinforcement of the government legislation with regard to environmental protection that forces the system manufacturers to take care of the disposal in an environmental conscious way. Different activities are required to achieve this goal. They allow bringing back the components of the end-of-life system to conditions that enable their reintroduction in the life-cycle of other systems. The principal activities are material recycling, remanufacturing or reusing. In this paper, we classify these activities in two generic classes:

-material recycling which consists in material recovery of the system elements;

-functional recycling which consists in functional recovery of the system elements.

These activities can generate profits for the actors of the end-of-life phase who manage the disassembly of the system. Today, the awareness of economic profit perspectives becomes one of the principal motivations for system manufacturers to set up and develop disassembly process.

The objective of the disassembly process is to generate parts and subassemblies that respect the specifications and conditions of the recovery activities (recycling, reuse, …) to which they are assigned to. The disassembly process includes sequences of separation actions that go from the whole end-of-life system to the valuable recycling products that the decisionmaker has selected. Different separation actions are possible to obtain each product (destructive, non-destructive, shredding, sorting, …) and different recycling options can be in conflict in one disassembly strategy.

The definition of a disassembly strategy begins with an analysis phase. We decompose this phase in three main tasks:

-identification of the component and subassembly of the end-of-life system: the purpose here is to represent the product topology and mating relationships;

-identification of the recycling actors who can evaluate different components with recycling viewpoints;

-analysis of the separation actions and resources in order to determine the precedence constraints between separation actions.

In the next step, decision-maker has to determine the optimal solution according to some criteria. The solution must establish for each component the best recycling option, the disassembly level (i.e. for each subassembly, what is the best option between recover and disassembly?) and for each subassembly the best type of separation actions. For a system with an important size, these tasks appear to be complex since the number of solutions might be important.

Furthermore, decision-maker has to manage the uncertainty of the disassembly process. Indeed, this is an important characteristic of this process but there are only few works that deals with it in the disassembly literature. The main uncertainties in the disassembly process are related to the states of the systems and components as well as the demand for the recovery products. There are two approaches to cope with this problem: predictive or reactive. The first one consists in selecting one solution that integrates the uncertain parameters. They can be taken into account in the decision model by introducing probabilities on success of disassembly operations [START_REF] Zussman | A methodology for modeling and adaptative planning of disassembly processes[END_REF] or by specifying parameter values by intervals [START_REF] Kang | Non-linear disassembly planning for increasing the end-of-life value of products[END_REF]. The second approach to take into account uncertainties consists in keeping alternative sequences in the disassembly process model in order to change the principal sequence if an operation fails [START_REF] Kanai | Representation of Product and Processes for Planning Disassembly, Shredding, and Material Sorting based on Graphs[END_REF] [10] [START_REF] Geiger | Probabilistic Reactive Disassembly Planning[END_REF].

The research issues we address in this work concern the modelling of the decision problem in disassembly planning with uncertainty. The remainder of the paper is organized as following: in the second section we present the necessary steps to modeling disassembly planning problem; in the third section we present our approach for solving such problem by using Bayesian network and in the last section we illustrate this approach on an example.

DISASSEMBLY PLANNING PROBLEM

Problem modelling framework

In this section, we present the different steps in modelling the disassembly planning problem that lead to an optimal disassembly sequences. In a determinist context, there are many works that address these problems in the literature (see for instance [2][7]). We present a way of linking these different approaches.

Generally, the modelling of the disassembly planning problem requires three main steps (see Figure 1). The first step concerns the structure modelling of the end-of-life system. The goal of these models is to represent the valuable parts and subassemblies and the connections between them. The input data can be generated from CAD (Computer Aided Design) systems as well as MRP (Material Requirement Planning) systems which facilitate the activity of identifying the components that can be reused. Several models are proposed in the literature ( [START_REF] Oliver | Parallel disassembly by onion peeling[END_REF][9] [START_REF] Moore | Disassembly Petri net generation in the presence of XOR precedence relationships[END_REF]).

The second step (denoted by Process models in Figure 1) of the disassembly planning problem concerns the modeling of the disassembly process. The obtained model represents the different operations that can be made on the system to obtain the valuable part and subassembly. After each disassembly operation, the state (or structure) of the end-of-life system is modified. If necessary, the process model integrates these intermediate structures. This is interesting when decision-maker wants to take into account the uncertainty of operation success. Indeed, if one operation fails, one has to manage the intermediate component generated previously. The problem is to generate all the sequences of disassembly operations that respect the precedence constraints identified in the structure model. The main difference between several sequences is due to the changes of tools and disassembly axis as well as varying accessibility of parts. The consequence is the variation of operation time and costs (see [START_REF] Kang | Non-linear disassembly planning for increasing the end-of-life value of products[END_REF][15] for instance).

The third step (Decision models in Figure 1) concerns the search of the optimal sequence among those identified in the process model. The purpose is to jointly determine the disassembly level and sequence. The model must take into account the preferences of the different stakeholders involved in the end-of-life phase of the system. Classic approaches model the decision problem as a linear program and solve it by existing algorithms ( [START_REF] Kang | Non-linear disassembly planning for increasing the end-of-life value of products[END_REF][8]).

Variables of the disassembly process

As we can see, solving disassembly planning problem involves different models and algorithms. Most of the works on this subject we encounter in the literature propose their own method and modelling language. In most cases, the considered Figure 1. Modelling approach approaches do not facilitate the integration of uncertainties. Our goal is not to propose one more approach to solve this problem but to integrate the uncertainties of the disassembly process on the basis of existing models in order to determine an optimal and robust solution. To achieve this objective, we will use concepts and entities utilized by different approaches and then add uncertainties using a modelling language that cope with uncertainties.

The main entities involved in the resolution of the disassembly planning problem are the following:

(i) components: they represent the composition of the end-of-life system and can correspond to parts, subassembly and/or intermediate disassembly states;

(ii) connections: in relation with the component, they complete the structural point of view by representing the joints and/or contact connections as well as relationships between components and subassemblies;

(iii) end-of-life variables: linked with each component, they describe the different recovery actions which can be recycling actions or disassembly operations;

(iv) contextual variables: attached to component and end-of-life variables, they model the recycling actors and other constraints on the recovery actions;

(v) decision variables: related to component and end-of-life variables, they represent the different actions of the decision-maker and give a framework to the decision process;

(vi) performance parameters: attached to end-of-life variables, they describe the consequences of the decision-maker actions.

On the basis of these entities, we propose in Figure 2 the generic framework of the modeling of disassembly planning problem (UML class diagram).

Figure 2. Structure of disassembly variables

At this stage, we have underlined the steps in solving disassembly planning problem and the different variables that decision-makers have to manage. We will introduce now Bayesian network to cope with uncertainties on some of these variables.

BAYESIAN NETWORKS FOR DISASSEMBLY PLANNING

Bayesian networks and influence diagram

We propose to use Bayesian networks as the modelling mathematical tool to solve the following decision problem: for a given end-of-life system, determine the disassembly levels and sequences on the basis of the process model while taking into account the uncertainties of the disassembly process.

We use the Bayesian network and their extension to influence diagrams because problems we want to solve have the following features [START_REF] Godichaud | Outils d'aide la décision pour la sélection des filières de valorisation des produits de la déconstruction des systèmes en fin de vie : application au domaine aéronautique[END_REF]:

(i) they can be represented graphically, (ii) there is necessity to integrate and manage uncertainties, (iii) there is necessity to solve an optimal uncertain problem.

The first reason (i) is important in a multi-actors context as in the case of the problem considered here. Indeed, the Bayesian networks and the influence diagrams facilitate the understanding of the problem by all the actors by means of a simple and natural graphical representation. Furthermore, they enable the interaction between these actors and the sharing of knowledge in a unique representation. Indeed, a Bayesian network is a graph model in which knowledge is modeled as variables and each variable correspond to a node in the graph. The directed arcs represent dependence relationship between the variables. The first step in developing a Bayesian network model consists in the elicitation of the interesting variables.

The second point (ii) corresponds to the purpose of our problem approach. The Bayesian networks enable inference that consists in the determination of probabilities for hidden variables of the problem given evidence. When decision-makers think there are uncertainties on some variables, they can evaluate them by probability formulation. Given the knowledge of the stakeholders, these probabilities can be conditional (they depend on some others variables) or marginal.

Once the uncertainties of the disassembly process have been evaluated, decision-makers have to determine the optimal solution according to several criteria. Decision and utility nodes are then added into the Bayesian network that becomes an influence diagram. It models the selection problem of end-of-life options for each component including the utility of these options. In [START_REF] Lauritzen | Representing and solving decision problems with limited information[END_REF] [5], the authors propose inference algorithms that determine the optimal solution.

Modelling disassembly decision problem using influence diagram

In this work, we propose to use influence diagrams (ID) as a decision tool to model disassembly problem and we suppose that a process model is given. The ID could be used directly to model the process ( [START_REF] Godichaud | Outils d'aide la décision pour la sélection des filières de valorisation des produits de la déconstruction des systèmes en fin de vie : application au domaine aéronautique[END_REF]) but we want to focus in this paper on the decision modelling. We use Disassembly Petri Nets (DPN) to model the disassembly process. The advantages of using Petri Nets in this context are highlighted in [START_REF] Zussman | A methodology for modeling and adaptative planning of disassembly processes[END_REF]. Briefly, the DPN clearly describe the precedence constraints between operations in the disassembly process. The places represent system, components and subassemblies and the transitions represent joints and disassembly actions. The purpose is to represent all the possible sequences of operations. The decision problem is to determine the best sequence according to one or more criteria.

Firstly, our approach will consist in translating the DPN model into a disassembly influence diagram. We illustrate the procedure on Figure 3. The following rules have to be applied:

1) Each place or transition in the DPN is a chance node in the ID (displayed as circles) (Figure 3(a));

2) The variables are linked in the same way in both models;

3) Decision variables are created in the ID whenever a firing conflict is identified in the DPN (Figure 3 The previous example represents a simple disassembly decision problem that is finally modelled as in Figure 3(c). We have to select the best option between recycling P1 and disassembling P1 (firing t1). The second option implies the recycling of P2 and P3. There is only one end-of-life option for each product. The proposed model looks more complex than the DPN because it takes into account more information into order to solve the decision problem.

Once the graph model has been generated, the variable domains and conditional probability tables (CPT) must be specified. We propose the following states for the place and transition variables:

-non-activate (na): the disassembly option corresponding to the variable is not selected; -success (s): the disassembly option is selected and successes (i.e. the output products are obtained); -failure (f): the disassembly option is selected but fails (i.e. the output products are not obtained or the product is stored waiting for a demand).

Consequences of the state 'f' are presented in the next part. For the decision nodes, the states correspond to all the disassembly options of the level at which the decision nodes is placed. At this stage, contextual variables can be integrated to the model to represent the cause of uncertainties. It could be the state of a joint that causes the failure of an operation or the demand for a product that causes the failure of recovery action.

The CPT must translate the firing rules of the DPN and integrate uncertainties. For a given place/transition variable, if the uncertainty is directly integrate in the variable (i.e. no contextual variable is used), the CPT is presented on Tableau 1. CPT modelling where p corresponds to the success rate of the recovery action or disassembly operation. The table should be adapted according to the context and graph model.

Tableau 1. CPT modelling

P T na s f na 1 0 0 s 0 p 1-p f 1 0 0
This CPT can be associated with the place variable P2 in Figure 3 if P corresponds to variable P2 and T corresponds to variable t1. The translation of the DPN firing mechanisms into the CPT is presented here: 1) for transition variables t i in the ID which correspond to the transition nodes t i in the DPN: a) state na (in ID) means that the transition (in DPN) cannot be fired or can be fired but we don't decide to (conflict resolution); b) state s means that t i can be fired and is fired (token are moved from input place to output place); c) state f means that t i can be fired but fails (not fired);

2) for place variables P i in the ID which correspond to the transition nodes P i in the DPN: a) state na means that there is no token in the place; b) states s and F means there is a token in the place and the output transition are not fired.

Once we have translated the DPN behaviour mechanisms into the CPT of ID variables (i.e. process model into decision model), we have to determine the states (retrieved components, subassemblies, joint states …) of the disassembly process according to different decision's configurations. Disassembly solutions are evaluated by means of utility nodes in the ID. They model the economical performance of the different recovery actions and disassembly operations. ID models enable the integration of utility in table forms as presented in Tableau 2. There are three types of nodes:

Evaluation of disassembly solutions

-disassembly cost nodes: linked to disassembly operation node, their value is function of disassembly operation realization,

-recycling cost nodes: they evaluate each recycling action realization mode of recycling node to which they are linked,

-recycling revenue nodes: they model economical flow that is generated when a recycling option is validated. An example of an evaluation of an operation is given on Figure 4. A cost parameter is associated with each realisation mode of the operation (t1 and t2 correspond to different duration and ar correspond to stoppage). Given the uncertainty on the operation realization, this operation is evaluated through expected utility calculation.

These different utility nodes allow optimization of a criterion for selecting a disassembly plan. This criterion is decomposed at each product in order to select the option or operation for each of them. To achieve this goal, decision node of each product indicates the evaluation of each option. The decision rule consists in selecting the option that maximise the expected utility of the product and it is called end-of-life policy.

The set of all polities forms the strategy. It gives the products that have to be generated from the end-of-life system, the recycling options for these products and the disassembly operations that are needed to generate them.

The purpose of optimization method is to determine the strategy for a given end-of-life system. There are different methods to solve decision graph (see [START_REF] Jensen | Bayesian network and decision graph[END_REF] for a presentation). In [START_REF] Lauritzen | Representing and solving decision problems with limited information[END_REF], the authors propose an algorithm to solve multistage decision problem represented as influence diagram. We use this algorithm which is implemented in BNT, a bayesian network toolbox for MATLAB (see [START_REF] Murphy | Dynamic Bayesian Networks: Representation, Inference and learning[END_REF] for the presentation of the algorithms used in this toolbox).

Predictive or reactive disassembly strategy

As we mentioned before, the disassembly strategies with uncertainties can be predictive or reactive. The advantage of disassembly ID is that it can manage the both cases. This is due to the fact that we can enter observation on the state of variables in the network as evidence. In a predictive context, no observation is made on variables and the optimal sequence is determined before the beginning of the process. The reactive case is encountered when the process has begun and a disassembly operation fails. The user may want to search a new sequence from the operations that have already been made. He can enter the following observations on transition variables: 1) t i = s for the operations that succeed, 2) t i = f for the operations that failed.

The searching for an alternative sequence takes into account these observations. Others observations could be integrated as contextual variables such as the state of a joint that might cause the failure of an operation.

In both predictive and reactive disassembly strategy, the user must determine the success rates of disassembly operations and the probability of demand for recovery products. For the case of disassembly operations, the success rate can be evaluated # , divided by the total number of execution,!! " , as presented in [START_REF] Zussman | A methodology for modeling and adaptative planning of disassembly processes[END_REF]. Then!$(" % ) = !! " # /! " . Parameter learning algorithms in Bayesian networks could also be used. Some of them are presented in [START_REF] Naïm | Réseaux Bayésiens[END_REF][13] for instance.

APPLICATION EXAMPLE

We use a telephone example to illustrate our approach of disassembly planning. It is extracted from [START_REF] Dutta | Contribution à l'étude de la conduite des systèmes de désassemblage[END_REF] or [START_REF] Zussman | A methodology for modeling and adaptative planning of disassembly processes[END_REF] where the authors propose a DPN to model the disassembly process that is presented in Figure 5. The telephone product consists of four parts A, B, C, D. The place P1 represents the first assembly state and P2, P3, P4 represent subassemblies. The parts are represented by P5, P6, P7, and P8. The transitions represent operations which consist in this example of removing joints. The end-of-life values and operation costs are denoted by r i and c i (see Figure 5 for numerical values). As explained before, the DPN displays the precedence constraints between operations.

We apply the transformation rules presented in this paper to obtain the ID model illustrated in Figure 5. The names of the variables correspond to the node's names of the DPN. We can see that there are four decisions nodes and each configuration of the decision node values is a disassembly solution. In fact, some configurations are the same due to the fact that when we stop the disassembly process at an intermediate stage, the successor decisions node are not necessary. Indeed, we want to determine disassembly level and sequence so P i variables means that the associated component is recovered (selected by means of D_P i variable) and the disassembly process can stop here.

We apply the solving algorithm for the case with non uncertain data (p=1 in the CPT of disassembly variables) and we obtain the following result:

1) Disassembly sequence: t1 -t3; 2) Disassembly level: {P4, P6, P8}; 3) MEU = -2.5. This result is not the same as in [START_REF] Moore | Disassembly Petri net generation in the presence of XOR precedence relationships[END_REF] since these authors add a constraint: parts A and D must be reused at the material level. We add this constraint in the ID by entering evidence to forbid the activation of the subassemblies containing A and D. We enter then P1 = NA, P2 = NA and P4 = NA. We obtain the same result as in [START_REF] Moore | Disassembly Petri net generation in the presence of XOR precedence relationships[END_REF]: 1) Disassembly sequence: t1 -t2 -t4; 2) Disassembly level: {P5, P6, P7, P8}; 3) MEU = -3.

In the same way, we can manage a reactive disassembly strategy. If operation t3 fails, we determine an alternative sequence after entering t3 = na. The solution is then the same as the later. Tableau 3. Success rate of operations t1 t2 t3 t4 t5 p 0.9 0.95 0.8 0.9 0.95

When applying a predictive disassembly strategy, the parameters p k have to be learnt for each disassembly variable (P k or t k ). To test our approach, we arbitrary set up parameters for CPT corresponding to transition nodes and we only enter uncertainties on disassembly operations. They are displayed on Tableau 1. CPT modelling. For the cost parameters, we consider here that the failure of an operation t j implies the stop of the process on the predecessor P i variable: cf j = r i + c j . Indeed, in this example, all the utility of intermediate sub-assembly are negative. The result of disassembly sequence and level is the same as the first one but with MEU = -3.29. Although the success rate of t2 is superior to that of t3, the optimal strategy takes t3. This is due to the important negative utility of P3 (BC) with regard to P4 (BD). If we had used the failure risk of the disassembly sequence as criteria, it could have been more interesting to take t2 instead of t3. Others criteria can be use to determine the optimal disassembly strategy such as inventory cost or demand for recovered products.

CONCLUSION

In this paper, we present an approach to cope with uncertainty in disassembly planning process. We propose to use Bayesian network and their extension to influence diagram as the underlying tool. The influence diagram model can either be constructed directly from the problem specification or be a translation of a Petri Net model. Our method consists in translating Disassembly Petri Net (DPN) into influence diagram to determine the disassembly strategy. We have tested this approach on an example of the literature. Future researches include the integration of multi-criteria approaches to solve the decision problem. Furthermore, we want to automate the translation from DPN to influence diagrams to decrease the modeling effort.

(b)); 4 )

 4 Utility nodes are created for each transition and end-of-life node. 5) End-of-life nodes are created for each product which represent the end-of-life option (they are noted Ox_P1with x=1,2,… in Figure 3(c));

Figure 3 .

 3 Figure 3. Disassembly process model using influence diagram

Tableau 2 .

 2 Performance parametersPi ri: profit of the recovery action associated with Pi cfi: cost of the failure of recovery or disassembly actions cj: cost of the disassembly action

  Expected utility of operation: EU(Operation) = Pr(t1)*c1 + Pr(t2)*c2 +

Figure 4 .

 4 Figure 4. Evaluation of a disassembly operation

Figure 5 .

 5 Figure 5. Disassembly models of a telephone


Elicitation, evaluation and recommendation in multi-criteria decision making process

Ayeley Tchangani, François Pérès

OATAO is an open access repository that collects the work of Toulouse researchers and makes it freely available over the web where possible Any correspondence concerning this service should be sent to the repository administrator: tech-oatao@listes-diff.inp-toulouse.fr

  This is an author's version published in: http://oatao.univ-toulouse.fr/23609 To cite this version: Tchangani, Ayeley and Pérès, François Elicitation, evaluation and recommendation in multi-criteria decision making process. (2017) In: 2017 4th International Conference on Control, Decision and Information Technologies (CoDIT'17), 5 April 2017 -7 April 2017 (Barcelona, Spain). Official URL: https://doi.org/10.1109/CoDIT.2017


Anne-Lise Benaben

Daniel Noyes

François Pérès

Keywords: Evaluation prévisionnelle de sûreté, satisfaction des exigences, modèle matriciel

Nous proposons dans ce travail une approche d'évaluation, en amont du cycle de développement d'un produit, de l'impact des exigences de sûreté de fonctionnement (SdF) sur la réalisation du projet associé. La nécessité d'allier les connaissances SdF et celles « métier » sur les dimensions fonctionnelles et structurelles du produit nous fait utiliser un formalisme de représentation matricielle. Nous présentons ce type de modèle et illustrons la démarche d'exploitation pour évaluer, tôt dans le projet, les effets de la dimension SdF du produit.

Evaluation prévisionnelle de l'impact de réalisation de la sûreté de fonctionnement d'un « produit »

I. INTRODUCTION

La sûreté de fonctionnement (SdF) des produits, des systèmes et des services est une préoccupation permanente de tous les acteurs industriels.

Les exigences SdF forment une part importante de la plupart des CdC de réalisation de ces entités et, souvent même, elles constituent la « partie dure » du CdC. C'est notamment le cas lorsque sont fixés des niveaux d'intégrité de sécurité (SIL) à valider par rapport à des objectifs de sécurité fixés. Dans ces situations, alors que le client n'était initialement intéressé que par les résultats, il requiert aujourd'hui, dès les négociations (dans l'appel d'offre (AO) par exemple), une information précise sur la démarche même que le prestataire prévoit de mettre en place pour satisfaire à ces exigences. De même, le soumissionnaire à un appel d'offre s'appuie souvent sur sa capacité à satisfaire les attentes SDF du client pour décider de sa participation à l'AO. Aussi, dans ce type de contexte, il devient essentiel de savoir identifier très tôt, en amont du cycle de développement du produit, l'impact des exigences SDF sur la réalisation et le devenir du projet.

La démarche SdF pour analyser, réaliser et valider les exigences SdF est assurée par l'engagement séquentiel ou combiné de méthodes SdF organisées autour des axes fonctionnel et dysfonctionnel de « l'objet » d'étude [START_REF] Noyes | Analyse des systèmes : Sûreté de fonctionnement[END_REF] (cf. figure 1).

Les différents travaux sur la SdF sont unanimes sur le fait que la phase préalable à toute analyse SdF est la réalisation d'une analyse fonctionnelle souvent formée d'une analyse fonctionnelle externe (AFE) suivie d'une analyse fonctionnelle interne (AFI) [START_REF] Medjoudj | Contribution à l'analyse des systèmes pilotes par calculateurs : extraction de scénarios redoutés et vérification de contraintes temporelles[END_REF] [START_REF] Demri | Analyse Qualitative et Quantitative d'un Système Mécatronique, 5ème confèrence internationale en Conception et Production intégrées CPI 2007[END_REF]. L'AFE permet de définir les limites du système ainsi que la définition des fonctions de service (ce pour quoi le système est conçu) et des fonctions contraintes (matérialisant l'intégration du système dans son environnement). L'AFI a pour but de raffiner les fonctions définies dans l'AFE afin d'atteindre un niveau de détail suffisant pour la définition des solutions techniques. En sortie, l'analyste dispose de l'ensemble des fonctions qui devront être reliées à leurs supports matériels afin de permettre, dans les étapes d'analyse suivantes, d'identifier, pour un mode de défaillance particulier, les causes et les effets de cette défaillance.

La phase suivante consiste à identifier les risques. Plusieurs méthodes peuvent être engagées, l'analyse préliminaire des risques (APR) étant la plus courante. La méthode consiste à identifier les points du système qui peuvent être critiques en termes de sécurité, à évaluer les risques correspondants, les scénarios associés et à définir des critères de conception à respecter. A ce niveau, l'étude des défaillances du « produit » pourra être menée à partir d'AMDEC(s) [START_REF] Wagner | Specification risk analysis: avoiding product performance deviations through an FMEA-based method[END_REF], [START_REF] Vems-Valeo | Exigences de fiabilité et leurs validations : Application au ECUs, Atelier[END_REF]. On obtient en sortie l'ensemble des dysfonctionnements potentiels associés à leur criticité (fréquence d'apparition, gravité des effets et probabilité de détection de la défaillance) et les plans d'actions à mettre en oeuvre afin de diminuer la criticité en faisant varier un des trois facteurs. Enfin, l'appui des arbres de défaillances (AdD), notamment pour la gestion de l'aspect sécurité, permettra pour un évènement donné, d'étudier les combinaisons de défaillances pouvant conduire à celui-ci. On obtient en sortie les scénarios de défaillance menant à l'événement dans le cas d'une étude qualitative et la fréquence d'apparition de l'évènement dans le cas d'une étude quantitative. Toutes ces phases sont « classiques » mais difficilement réalisables en phase préliminaire du projet (lors du processus de réponse à l'appel d'offre, par exemple) car : la réactivité souhaitée ne permet pas d'investigation fouillée au regard de la durée disponible mais plutôt une pré-étude des caractéristiques SdF, le niveau de définition du produit dans le PRAO nécessite un haut-niveau d'abstraction, les modèles utilisés dans les méthodologies SdF classiques ne correspondent pas à des "standards" connus de tous les acteurs projet et, notamment, des décideurs concernés ; les représentations du produit sont assez éloignées des représentations métiers classiques alors même que l'étude de la SDF ne peut être décorrélée des connaissances métiers intervenant pour la réalisation du produit, l'objectif visé est d'estimer l'impact des exigences SdF sur la base des principaux mécanismes de défaillances et des évènements redoutés et non l'étude exhaustive de ceux-ci. C'est à ce niveau qu'est située notre contribution qui concerne les phases amont du cycle de développement du produit, au stade des négociations client-prestataire, à l'intersection des domaines de la sûreté de fonctionnement et de la conception de produit.

Dans ce contexte, nous proposons « d'associer » aux méthodes classiques, l'emploi de modèles « produit », basés sur une représentation matricielle afin de : réaliser des études rapides pour affiner ou compléter une exigence SDF particulière, non analysable en l'état (car nécessitant des méthodes et outils utilisés lors des phases de développement), propager sur le produit l'impact de la prise en compte des exigences SdF par l'utilisation des supports de connaissance existants ou développés, notamment, en termes de choix de solutions, définir l'impact sur le développement futur de la vérification et de la validation de ces exigences par une démarche SdF complète et à appliquer.

Soulignons immédiatement que nous avons conduit cette étude dans un cadre partenarial avec un équipementier automobile, profession confrontée à des clients de plus en plus exigeants en matière de SDF.

Le papier est organisé en trois sections principales. Nous décrivons d'abord les éléments de représentation matricielle permettant d'appréhender les « dimensions » significatives du produit pour aider à l'estimation de l'impact de la SDF sur celui-ci. Nous présentons ensuite des éléments de saisie de l'expertise métier. Nous proposons enfin un scénario de traitement d'exigences de sécurité utilisant la connaissance ainsi formalisée.

II. MODELES MATRICIELS

Comme nous venons de l'évoquer, l'étude de la SdF d'un système consiste à identifier et analyser ses défaillances par le biais de méthodes appliquées qui partent soit d'une défaillance fonctionnelle pour déterminer les causes potentielles au niveau structurel soit d'une défaillance structurelle afin de définir l'impact sur le système complet au niveau fonctionnel. L'étude de la SdF nécessite donc au minimum une vue fonctionnelle, une vue structurelle et des informations concernant le lien entre les fonctions et leurs supports de réalisation.

Nous nous intéressons aux caractéristiques de fiabilité et de sécurité du produit que nous allons considérer à travers ces mêmes caractéristiques fonctionnelles (corrélées à la vue client), structurelles (proches de l'expertise métier) et comportementales (liées aux exigences SdF).

Nous retrouvons cette approche dans [START_REF] Zwingmann | Modèle d'évaluation de la fiabilité et de la maintenabilité au stade de la conception[END_REF] où l'auteur s'intéresse à l'intégration de la validation dans le processus de conception. Dans ce papier, Zwingmann fait état d'un manque de travaux concernant l'évaluation des performances dans la conception et propose une approche "FSC" couplant les mêmes caractéristiques fonctionnelles, structurelles et comportementales du produit afin d'en évaluer la fiabilité et la maintenabilité au stade de la conception.

A. Représentation matricielle

Nous voulons pouvoir choisir le niveau d'abstraction du modèle tout en conservant la possibilité de raffinements pour mettre en évidence certaines parties du système. Le modèle doit donc permettre de représenter sous le même formalisme plusieurs niveaux d'abstraction.

Au stade de la conception, nous cherchons à modéliser l'architecture fonctionnelle, structurelle et les liens qui unissent ces deux formes de caractérisation du produit. Dans [START_REF] Dumas | Vers la génération de modèles de sûreté de fonctionnement, 2ème Conférence Francophone sur les Architectures Logicielles (CAL 2008)[END_REF], les auteurs explicitent ces trois éléments.

La représentation de l'architecture fonctionnelle consiste à décomposer les fonctions en sous-fonctions, en interaction par rapport aux données échangées. De façon formelle, l'architecture fonctionnelle peut être assimilée à un graphe orienté (F, A_F) dans lequel les noeuds Fi représentent les fonctions et les arcs A_Fi→Fj les échanges de données de Fi à Fj.

De la même façon, l'architecture matérielle peut être vue comme un graphe orienté (BS, A_BS) dans lequel les noeuds BS représentent les supports ou "Blocs Structurels" réalisant les fonctions et les arcs A_BSi→BSj représentent les connexions entre les différents blocs du système.

Enfin, il faut modéliser la façon dont les fonctions sont supportées par les solutions matérielles en exprimant les liens d'allocations entre ces deux espaces de réalisation. L'allocation peut être définie comme une application qui associe à chaque fonction F la ressource BS qui la réalise. Pour que cette allocation soit cohérente, il faut que les moyens de communication entre les ressources permettent le flot de données entre les fonctions. Il existe différents types d'allocation entre les fonctions et les blocs structurels. En effet, comme proposé par Chakrabarti dans [START_REF] Chakrabarti | Sharing in design -categories, importance, and issues[END_REF], quatre types de relations sont possibles entre les fonctions et les blocs structurels qui les réalisent. Ces types de relations sont schématisés sur la Figure 2.

C. Matrices inter-domaines

Ce type de matrice consiste à modéliser les allocations ou les choix de conception effectués, i.e. la manière avec laquelle les fonctions vont être réalisées par le biais des blocs structurels.

Nous considérons qu'il existe des interactions de type : réalisation : la fonction nécessite le bloc structurel pour être réalisée, assistance : le bloc structurel ne réalise pas directement la fonction mais est nécessaire aux blocs qui la réalisent (exemple : alimentation), option : le bloc structurel n'est pas strictement nécessaire à la fonction mais il est présent de façon volontaire : protection de la fonction, surveillance,... -la première information i 1 représente l'existence d'un lien de réalisation R ou d'assistance A du BS envers la fonction : si la fonction est réalisée par le BS i 1 est égale à R, si la fonction est assistée alors i 1 est égale à A, -la seconde information i 2 représente l'existence d'un autre type de lien et est égale à S si le BS sécurise la fonction, à P s'il la protège, à D s'il détecte les défaillances de celle-ci ou à C s'il en contrôle le fonctionnement.

D. Choix de modélisation des interactions et notations utilisées

Nous illustrons ces notations matricielles par les exemples de la figure 3. avons analysé les blocs structurels pour identifier la structure cognitive utile à sa définition. Cette étude nous a orientés vers la définition d'attributs permettant de capitaliser l'ensemble des connaissances métier et SdF sur les BS. Les attributs que nous définissons sont de deux types. Certains explicitent les connaissances métiers mobilisées pour la sélection du bloc et des informations sur le bloc, d'autres les connaissances et informations SdF disponibles. Nous avons identifié huit attributs pour la problématique considérée mais leur nombre peut être étendu pour formaliser une connaissance ou une information supplémentaire.

Nous présentons les attributs dans la table I (colonnes 1 et 2) et donnons une illustration pour un bloc structurel de type « Alimentation » (colonne 3).

TABLE I. ATTRIBUTS DES BLOCS STRUCTURELS IV. APPLICATION DE SECURITE

L'étude de la sécurité implique de considérer les principaux mécanismes de défaillances du système afin d'identifier les évènements redoutés (ER) du système ou analyser les évènements redoutés donnés par le client. Un évènement redouté est, en effet, une conséquence d'une ou plusieurs défaillances affectant le système. Dans l'objectif d'identifier les éléments du système susceptibles d'être impliqués dans l'apparition d'un ER, il faut pouvoir relier cet ER aux fonctions ou aux blocs structurels du système considéré. Nous définissons pour cela une table de correspondance entre les évènements redoutés et les fonctions. Cette table de correspondance est assimilable à une analyse préliminaire des risques (évoquée dans l'introduction) dans la mesure où elle consiste : i) à définir les fonctions impliquées pour un évènement redouté donné (si le client donne les ER à traiter), ii) à définir les ER si le client ne les a pas fournis ou s'il stipule qu'il faut vérifier qu'il n'y ait pas d'ER supplémentaire.

En reprenant les principes de l'APR, il apparaît que les informations dont nous avons besoin sont les liens entre les états du système et les fonctions. Nous considérons donc l'état du système par rapport à l'état de ses fonctions. Cette relation peut être représentée par une matrice de conditions. Ce type de matrice consiste en une matrice dont les lignes représentent les différents ER et les colonnes l'ensemble des fonctions du système. Les termes égaux à 1 figurant aux intersections ligne/colonne représentent les défaillances de fonctions minimales conduisant à l'ER de la ligne correspondante [START_REF] Turinetti | Calcul de blocs diagrammes complexes de fiabilite par la méthode dite des "matrices de conditions[END_REF].

Nous présentons sur la table II un exemple de matrice de correspondance entre ER et F.

TABLE II. EXEMPLE DE MATRICE M[ER/F]

A. Démarche générale

Notre objectif est, rappelons le, d'obtenir la valeur d'impact de la prise en compte des exigences sûreté de fonctionnement sur le produit ainsi que sur la démarche à mettre en oeuvre. Cette valeur d'impact est définie par le biais de l'application de la méthodologie matricielle que nous résumons ci-après.

La démarche comprend cinq phases formées, chacune, de plusieurs activité permettant la définition et l'évaluation des conséquences de la prise en compte des exigences SdF. Nous ne donnons ci-après les trois premières que nous reprenons par la suite (table III). Le lecteur intéressé par l'ensemble de la démarche pourra consulter [START_REF] Benaben | de BS4 de BS3 ER2[END_REF]. défaillance du produit par rapport aux taux de défaillance des différents blocs structurels sélectionnés. La phase 3 porte sur l'analyse la sécurité du produit et est composée de plusieurs activités :

-le calcul du taux de défaillance résiduels en regard des différentes sécurités mises en place dans le produit, -l'analyse des fonctions du produit et de leur sécurité respective, -l'analyse des ER du produit, -des analyses en temps réel dans le PRAO afin de traiter certains points particuliers relatifs à la sécurité, -l'analyse des défaillances de mode commun du produit.

TABLE III. PHASES PRINCIPALES DE LA DEMARCHE

B. Analyse de sécurité

Cette phase correspond à la troisième phase de la démarche présentée dans la table 2. Plusieurs études peuvent être menées dans cette phase.

La première activité (3.1) concerne le calcul du taux de défaillances résiduelles par rapport aux mécanismes de sécurité implémentés (i.e. défaillances susceptibles de survenir malgré les mécanismes de détection des défaillances implémentés sur les différents blocs structurels). Cette activité est réalisée à partir des informations contenues dans les attributs.

La seconde activité (3.2) concerne l'étude des dysfonctionnements des fonctions avec ou sans prise en compte de la sécurité.

La troisième activité (3.3) s'intéresse aux mécanismes de défaillance qui conduisent à l'apparition d'un ER et à l'analyse des fonctions et blocs structurels potentiellement impliqués dans l'apparition de celui-ci.

Les activités 3.4 et 3.5 ont pour objectif respectif la réalisation d'étude SdF en temps réel dans le PRAO pour l'éclaircissement de point particulier et l'analyse des causes de modes communs.

Nous nous focalisons sur les activités 3.2 et 3.3 qui permettent d'illustrer les principes d'utilisation de la structure matricielle et des calculs y afférents tels qu'ils ont été présentés précédemment.

Soulignons que la démarche que nous présentons ici a été appliquée aux différents éléments de sécurité embarqués dans un environnement automobile pour réaliser les fonctions Suspension Active, ABS et Direction Assistée (figure 4). Pour plus de détails, le lecteur pourra consulter [START_REF] Benaben | de BS4 de BS3 ER2[END_REF]. Comme dans beaucoup de problèmes SdF, les calculs sur le système complet ne permettaient pas d'observer les points faibles du système ce qui justifiait l'utilisation des matrices qui permettent de procéder à des évaluations locales sur des fonctions ou des composants. Pour des raisons de limitation de place et de confidentialité, les résultats afférents ne seront pas exposés.

Analyse des fonctions hors et avec sécurité (Activité 3.2)

Différentes études peuvent être menées sur le fonctionnement du produit : l'analyse du bon fonctionnement des fonctions ainsi que le taux de défaillance associé à ces fonctions en ne considérant pas les mécanismes de protection ou de détection implémentés, l'analyse du fonctionnement en sécurité des fonctions et le taux de défaillance associé, l'analyse simplifiée de la sécurité des différentes fonctions du produit. 5). Sur l'arbre, la spécificité de stratégie de sécurité des produits considérés apparaît sous la forme de l'opérateur ET reliant les Blocs Structurels réalisant les fonctions (BS1, BS2 et BS3) à la stratégie de sécurité. L'ER apparaît dans le cas de l'occurrence d'une défaillance non détectée sur un BS ou pour laquelle BS6 ne serait pas en état de mettre en sécurité le produit.

Dans une forme pratique, il est possible, par l'analyse de la matrice M[F/BS], d'établir des relations logiques d'association des BS. Les BS réalisant la fonction sont liés entre eux par un opérateur OU ; ils sont liés aux blocs réalisant leur contrôle ou leur sécurité par un opérateur ET. Les BS assistant une fonction par apport d'énergie (informations issues de M[F/BS] et M[BS/BS]) induisent, dès l'occurrence d'une défaillance les affectant, la perte de la fonction assistée.

C. Conclusion

Nous avons proposé une approche d'évaluation prévisionnelle de l'impact des exigences SdF sur la réalisation d'un produit. Nous nous sommes appuyés pour cela sur une représentation de la connaissance « métier » sur les vues fonctionnelle, organisationnelle et comportementale du produit.

La représentation matricielle que nous préconisons fournit un support efficace pour les analyses SdF à partir d'une représentation facilement utilisable par les acteurs.

Cette méthodologie dont nous avons défini les principes mais aussi le mode de mise en oeuvre est applicable à de nombreux contextes dès lors que le produit décomposable en fonctions et en blocs structurels. Son instanciation pourrait conduire à la mise en oeuvre de bibliothèques dédiées constituées de primitives descriptives du produit ou de modèles de comportements situés au niveau le plus bas de généricité. Leur utilisation devrait favoriser très fortement la réactivité du processus d'analyse SdF dans les phases amont des projets.

Fig. 1 -

 1 Fig.1 -Processus d'analyse SDF

Fig. 2 .

 2 Fig.2. Types de relation F -BS adaptés de Chakrabarti

  Nous présentons les notations que nous utilisons pour les différents types de matrices. Afin de faire apparaître dans les matrices intra-domaines des relations orientées, nous faisons le choix d'utilisation des matrices temporelles dont le sens de lecture est « lignes vers colonnes ». Nous avons adopté l'exploitation de vecteurs pour la modélisation des liens. Nous détaillons ceux-ci. Relations Fonctions/Fonctions Nous utilisons un vecteur [L T N] formé de trois composantes : -L indique s'il existe un lien entre deux fonctions et le sens de ce lien : L = 2 si le lien est bidirectionnel, L = 1 à l'intersection ∩[Ei/Ej] si le lien existe de Ei vers Ej et L = 0 à l'intersection ∩[Ei/Ej] si le lien existe de Ej vers Ei, -T définit le type du lien : T = I à l'intersection ∩[Ei/Ej] dans le cas où Ei envoie des informations à Ej, T = E si Ei envoie de l'énergie à Ej et T = E/I dans le cas où Ei envoie des informations et de l'énergie à Ej, -N définit la (ou les) nature(s) du lien et peut comporter deux informations : i) A ou R pour l'existence d'un lien de réalisation R ou d'assistance A, ii) S, C ou P pour l'existence d'un lien pour la sécurité S, le contrôle C ou la protection P. Relations Blocs Structurels/Blocs Structurels On retrouve le même type de lien. Nous utiliserons par conséquent le même formalisme de représentation basé sur l'instanciation d'un vecteur [L T N]. Relations Fonctions/Blocs Structurels Un vecteur à n composantes caractérise le lien entre une Fonction et le (ou les) Bloc(s) Structurel(s) qui participe(nt) à sa réalisation. Souvent, une composante suffit à la caractérisation des liens F/BS. Le vecteur défini est noté [N] et la composante N peut comporter deux informations i 1 /i 2 :

Fig. 3 .

 3 Fig.3. Exemples de notation matricielle

  En explicitant cette matrice, on constate, par exemple que ER 1 apparaît si F1 et F3 sont défaillantes : peuvent cependant être à l'origine d'un évènement redouté comme, par exemple, pour ER2

La phase 1

 1 a pour objectif d'assister l'équipe acquisition dans le paramétrage des matrices et des attributs. Dans l'ordre, il faudra paramétrer : M[F/F], M[F/BS], M[BS/BS] et, enfin, les attributs (i.e. les choix particuliers à effectuer sur un bloc structurel particulier : robustesse, sécurité, etc.). Dans [12], Bénaben propose deux algorithmes de paramétrage, dédiés aux matrices [F/F] et [BS/BS] pour l'un et [F/BS] pour l'autre, pour assister l'analyste dans cette phase. La phase 2 concerne l'analyse prévisionnelle de la fiabilité du produit. Elle consiste à un calcul du taux de normes/expériences, permet d'évaluer la couverture de diagostic CD en fonction des mouens mis en place Vérification de la tension batterie (CD bas)

Fig. 4 .

 4 Fig.4. Cas d'application

3 )

 3 La première étude concerne l'estimation des taux de défaillance des différentes fonctions du système. La matrice M[F/BS] est utilisée pour la réalisation des calculs correspondants. Comme nous l'avons précisé dans les notations, on ne considèrera que les intersections non vides.Plusieurs calculs sont possibles. Le premier concerne l'analyse du fonctionnement d'une fonction sans considération des mécanismes de détection ou de protection des défaillances implémentés. Pour une fonction Fi particulière, il faut rechercher dans la matrice M[F/BS] l'ensemble des intersections ∩[i/j] telles que R = 1 ou A = 1. On ajoute entre eux les taux de défaillances des différents BS ainsi identifiés (en considérant que la perte d'un BS entraîne la perte de la fonction) pour obtenir le taux de défaillance de la fonction :M[F/BS] perte de Fi pour les BSk tels que, dans ∩[i/j], la première information de N est égale à R ou A. Etablissement M [F/F] (s/phase 1.1) Etablissement M [F/BS]] (s/phase 1.2) Etablissement M [BS/BS]] (s/phase 1.3) Attributs] (s/phase 1.4) Evaluation PPM ] (s/phase 2.1) Evaluation l] (s/phase 2.2) Calcul taux de défaillances résiduelles (s/phase 3.1) Analyse des fonctions hors et avec sécurité (s/phase 3.2) Calcul des fréquences d'appartion des ER (s/phase 3.3) Analyse Temps Réel (s/phase 3.4) Analyse des causes de mode commun (s/phase 3analyser le fonctionnement d'une fonction avec l'ensemble des mécanismes de détection et de protection implémentés. Il faut alors ajouter l'ensemble des taux de défaillance calculés en considérant la couverture de diagnostic et le taux de défaillance des éléments de sécurité. Dans ce cas, il faut rechercher dans la matrice M[F/BS] l'ensemble des intersections non vides de Fi et ajouter entre eux les taux de défaillances résiduels des différents BS identifiés comme défini ci-après : M[F/BS] perte de Fi pour les BSk tels que ∩[i/j] 0. On peut réaliser ce calcul de façon plus précise en identifiant les blocs communiquant. Le calcul est effectué en plusieurs étapes : on identifie, dans la matrice M[F/BS] tous les blocs participant à la fonction dans la réalisation ou l'assistance (R ou A égal à 1), dans la matrice M[BS/BS], on identifie ensuite les blocs dédiés à la surveillance, la protection ou la sécurisation (en recherchant les liens de type P, C, S) des blocs précédents. on étudie enfin les blocs BSi correspondant à la sécurité de la fonction. Calcul de la fréquence d'apparition des évènements redoutés (Activité 3.Nous avons montré (cf Table II) comment la matrice de condition M[ER/F] permet l'identification des différentes fonctions impliquées dans l'apparition d'un ER. Dans cet exemple, F1 était une fonction qui récupère les données des capteurs extérieurs au produit, F2 une fonction qui envoie la commande aux actionneurs, F3 est la fonction Alimenter et F4 contrôle le fonctionnement et assure la sécurité. La matrice M[F/BS] permet d'identifier les blocs structurels nécessaires à la réalisation des fonctions. Nous donnons celle-ci pour le même exemple (table IV) dans laquelle BS1 est le Dispositif de mise en forme des entrées, BS2 le Microcontrôleur, BS3 le Driver de sortie, BS4 l'alimentation, BS5 le Watchdog et BS6 le dispositif de mise en sécurité.TABLE IV. MATRICE INTER-DOMAINES M[F/BS]CONSIDEREE BS1 BS2 BS3 BS4 BS5 BS6 F1 [R/.] [R/.] [A/.] [C/.] [S/.] F2 [R/.] [R/.] [A/.] [C/.] [S/.] F3 [R/.]F4 [A/.] [R/.] [R/.] Dans cette matrice inter-domaines : -F1 est réalisée par BS1 et BS2, assistée par BS4, contrôlée par BS5 et sécurisée par BS6, -F2 est réalisée par BS2 et BS3, assistée par BS4, contrôlée par BS5 et sécurisée par BS6, -F3 est réalisée par BS4, -F4 est réalisée par BS5 et BS6 et assistée par BS4. L'occurrence de l'ER correspond également la perte de la fonction sécuritaire associée au bloc ; on utilisera la matrice intra domaine M[BS/BS] pour identifier les sécurités mises en place (table V). TABLE V. MATRICE INTRA-DOMAINE M[BS/BS] A/.] [1 I C/.] [0 . S/.] BS2 [0 . R/.] [1 I R/.] [0 . A/.] [1 I C/.] [0 . S/.] BS3 [0 . R/.] [0 . A/.] [1 I C/.] [0 . S/.] BS4 [1 E A/.] [1 E A/.] [1 E A/.] [1 E A/.] [1 E A/.] BS5 [0 . ./C] [0 . ./C] [0 . ./C] [0 . A/.] [1 I ./S] BS6 [1 I ./S] [1 I ./S] [1 I ./S] [1 I C/.] Il est mis en évidence dans la matrice V le fait que BS5 assure le contrôle du fonctionnement des blocs structurels BS1, BS2 et BS3 alors que BS6 permet d'assurer la sécurité en cas de détection de défaillance pour les blocs précédents. Suite à l'analyse des matrices, deux solutions sont envisageables pour représenter les mécanismes d'apparition de l'ER soit sous forme d'arbre de défaillances soit sous forme d'équation logique. En reprenant la matrice M[F/BS] et les liens définis dans celle ci, l'expression de ER2 devient : correspondant peut être établi pour les blocs structurels à partir des analyses précédentes (figure

Fig. 5 .

 5 Fig.5. Arbre de fautes