INTRODUCTION

The complexity of new systems has dramatically grown and continues to follow this trend. So, the intricacy of the development phase is clearly related to the number of different technologies embedded in the system. For instance, the necessity to integrate software raised many difficulties that have been tackled by numerous research teams. One origin of these difficulties is the difficult communication between the experts of each discipline. Ambiguities exist with discipline-specific models and languages. The synchronization and aggregation of technologyspecific models is a complicated task, error-prone and time-consuming. The dependability studies suffer of the same hindrance. Indeed, dependability evaluation or qualification need dedicated models not easily understandable by designers. Therefore, reliability studies and conception processes are too often considered as separated workshops in development projects. This leads to a lack of communication between the experts of both part of the system conception. To sum up, we can act that system designers and analysts must face two main issues: Inter-discipline communication and multi-technology integration. Thus, the challenge for efficient reliability studies in development phase is to combine and synchronize the design models and reliability analysis. In this paper, we will present a method and tools that we developed in order to link as fast as possible the design choices and their impacts on the global system reliability. In the remaining of this article, we will highlight the benefit of the use of UML/SysML for complex systems design. We will mention how those languages can be helpful for reliability studies. Then, we will introduce a method for reliability studies using UML/SysML diagrams. Namely, we will explain how to deduct the dysfunctional behavior of a system from its functional description, using an automatically generated FMEA. Finally, we will introduce future developments and underline the improvements brought by SysML.

UML AND SYSML FOR RELIABILITY ANALYSIS

Languages for multi-technologic system design

Communication problems were serious in software engineering, because of the very precise and specific language utilized by computer engineers. The end-Towards a better interaction between design and dependability analysis: FMEA derived from UML/SysML models P. David, V. Idasiak & F. Kratz

Institut PRISME/LVR, ENSI de Bourges, Bourges, France ABSTRACT: It is commonly admitted that one of the crux, during the design process of new complex systems, is the efficient communication between the experts. The OMG developed UML to tackle this problem in software design. For several years, many researchers have worked on adapting and reusing UML for whole kind of systems. These efforts led to the creation of SysML, a new modeling language for specifying, analyzing, designing and verifying complex multi-disciplinary systems. In this paper, we present how those modeling languages can be integrated to combine reliability study with the design process in order to compose a conception process close to dependability priorities. We have set up a method to conduct reliability studies without perturbing the classic procedures of designers. Our objectives were on the one hand to facilitate communication between functional and dysfunctional analyzers and to simplify the execution of reliability studies on the other hand. In this article, we raise the utility of FMEA for a non-intrusive modeling of dysfunctional aspects. We thus give our solution for an automatic synthesis of FMEA from UML/SysML models, which only describe the nominal behavior. We insist on the keystone of this automatic synthesis, namely the use and management of a database constructed from the information of the return on experience. The purpose of this article is thus to describe a new approach to enhance the realization of dependability studies by automating steps and using easily understandable models.

users, non-expert in computing method, had often difficulties to express their needs to the programmers. To tackle this issue, the computer science community developed several languages synthesized in a common language: UML. UML has been specified in order to describe, in an easy understandable way, software projects and complex systems embodying software. This language well fitted its objectives and is currently widely used in software industry. Since UML 2.0, this language is not restricted for software design; thanks to its objectoriented approach it is exploitable to describe any type of system. Many published works proposed the use of UML for system engineering and demonstrate all the advantages of object-oriented method in complex system design like [START_REF] Lykins | Adapting UML for an Object-Oriented systems engineering method (OOSEM)[END_REF]. Nevertheless, because of a semantic too software-oriented, it has not been much used for complex systems design. Therefore, system engineers always needed a modeling language allowing sharing and unifying discipline-specific parts.

That is why OMG created SysML (System Modeling Language) [START_REF] Omg | OMG systems modeling language (OMG SysML)[END_REF] for specifying, analyzing, designing and verifying complex systems. SysML has been constructed as an extension of UML adapted for system engineering. It brings new means for system modeling and requirements. In [START_REF] Willard | UML for systems engineering[END_REF] the author highlights the heritage from UML 2.0 and presents the new possibilities brought by SysML, he claims that the main benefit of SysML is "to provide system engineers with a standard and comprehensive system specification paradigm". In [START_REF] Hause | The SysML modeling language. 15 th European systems engineering conference[END_REF] the reader can find a good introduction to SysML and its new diagrams namely requirements diagrams, parametric diagrams. SysML uses UML 2.0 diagrams as class or object diagrams but adapts the semantic to avoid software vocabulary (e.g. class and object are replaced by blocks). Moreover, new diagrams are added to simplify requirements declaration and to build a bridge towards simulation-based design. Parametric diagrams describe the equations linking the multiple parameters of the model. In (Peak et al. 2007a,b), the authors introduce the background of the SysML parametric diagrams and their relation with Composable OBject (COB) technology; they explain how parametric diagrams will allow SysML to support simulation-based design. In fact, they demonstrate how the models can be exploited with analysis tools and equation solver as XaiTools (X-Analysis Integration Toolkit is a trademark of Georgia Institute of Technology).

Those two languages, and especially SysML, are then suitable to system engineering. The oriented object approach and the hierarchy and composition possibilities permit to model multi-technological systems. Moreover, it is widely noticed that their graphical description enhances understanding and reduces miscommunication. Finally, we have to mention that a crucial advantage of those languages is that many software tools support them.

UML/SysML for reliability study and risk analysis

Because UML caught the interest of system engineers, dependability analysts decided to explore how dependability study could combine with this kind of models. This leads to several works that are currently extended to SysML.

Integrating reliability requirements or conducting reliability or risk studies on UML models raise many challenges of model construction and information representation. The problem of modeling reliability using UML is presented for software systems in [START_REF] Leangsukun | Reliability modeling using UML[END_REF]. The authors notice that techniques utilized for dependability estimation are not well mastered by engineers. Consequently they have imagined a method to reduce the gap between conception practices and reliability analysis. They propose to define new UML stereotypes to describe the dysfunctional behavior of the system. This dysfunctional behavior is thus added to the model so that the two views of system activities are mixed. Thanks to the interchange file format (XMI) used by UML tools, the authors automatically extract the information needed to "feed" the SHARPE tool (Symbolic Hierarchical Automated Reliability and Performance Evaluator developed at Duke University) as failure and repair rate. Fault trees and Markov chains are then constructed and analyzed. The analysis of a two-tier client/server architecture illustrates their paper. Zarras and Issarny have already used a similar approach. In [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF] they present their stereotypes for reliability declaration. Moreover, they decide to specify the requirements with OCL (Object Constraint Language), which is another OMG specification for expressing special relationships in the model. In the two previous articles, the additional information concerning dysfunctional behavior is clearly constructed in order to be used by the analysis tools employed. In [START_REF] Zarras | Model-driven dependability analysis of web services[END_REF]) the approach is slightly different. The model is constructed in a similar way but the exploitation of the model is not a simple data transformation. In fact, algorithms are employed to automatically generate some artifacts usable for reliability analysis. Block diagrams, fault trees and Markov chains are thus created and analyzed to assess the functioning of a composite web service. Other works exploit UML models for risk analysis. In [START_REF] Guiochet | Toward a human-centered UML for risk analysis[END_REF]), the approach is fundamentally different. They analyze a medical robot for tele-echography. The model is not constructed to characterize the possible failure, but to conduct a risk analysis on the represented system. The authors define error models for the messages of UML sequence diagrams. Firstly, they model the task and mission of the system. Then, they use their message error model to product the FMEA of the tasks.

These multiple approaches showed that it is possible to express or deduct information about risks or dysfunctional behavior of systems modeled in UML. Nevertheless, those works are guided by specific goal. The modeling principles and the information given in models are conditioned by the analysis that users want to apply. Moreover, the information must respect a very strength semantic, which is difficult to follow, as the stereotypes defined in Zarras and Leangsukun works [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF][START_REF] Leangsukun | Reliability modeling using UML[END_REF]. In those cases reliability analysis add complexity to the model. Furthermore, to construct them the modeler must already know the dysfunctional behavior and be able to quantify the failures of each component. On the contrary, in his work Guiochet only uses the model to deduct risks from an only functional point of view. But, the model is only built to perform the risks analysis and not really used for the system design. In each case, we can say that the model is built for reliability study purpose, so that the models built by system engineers are not really analyzed.

The use of SysML mitigates some of those drawbacks by the mean of new diagrams. Actually, requirements diagrams will be precious to express reliability requirements without using complex OCL rules as in [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF]. Besides, modeling reliability aspects have been clearly an interest for SysML [START_REF] Omg | OMG systems modeling language (OMG SysML)[END_REF], parametric diagrams represent constraints on system property values such as reliability. Furthermore, in works as (Peak et al. 2007a,b), we see that it will be possible to connect parametric diagrams with function solver, allowing us to compute new reliability indicators. In the next section, we will present our method for reliability analysis, which aims at bringing new solutions in order to reduce the gap between design practices and reliability analysis methods.

CONNECTING DESIGN PROCESS AND DEPENDABILITY STUDY

As we exposed in the preceding section, the current works, on bringing together design process and reliability studies, are certainly perfectible but demonstrate huge possibilities and really encouraging results. Since UML is the main trend in design activities, we are persuaded that developing method exploiting UML models is the right solution. Moreover, an adaptation to SysML is necessary for these techniques, in order to deal with system engineering. The aim of our research is not to find how to model reliability in UML or SysML, but to be able to analyze real conception models expressed in those languages and to obtain new information concerning the dependability of the system. A major drawback of reliability study is that it delays and complicates the design process. Consequently, we develop a method that does not interfere with the model created by the designer. We set up a software tool that helps an engineer to perform this task as easily as possible. We thus propose a deductive and iterative method in three steps:

• Deduction of the dysfunctional behavior with a FMEA • Construction of the dysfunctional model • Analysis and quantification Each step of this approach requires dissimilar models and methods. Our role is thus to enhance as much as possible the link between each activity. That is why we are currently creating tools to automatically conduct risk and reliability studies from the designer model written in UML/SysML. The goal of each step is to generate new knowledge or to automatically create new models for various analyses. A diagram representing the approach is shown on Figure 1 and details the successive models. The first step of the instrumented method is the establishment of a FMEA. This FMEA is generated from the study of UML/SysML models. We use a FMEA to find the dysfunctional behavior of the system. In fact, in our approach we do not consider that the dysfunctional behavior is already known as [START_REF] Leangsukun | Reliability modeling using UML[END_REF] and [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF][START_REF] Zarras | Model-driven dependability analysis of web services[END_REF] do. Therefore, this step is very critical in our approach because it has to highlight the failure modes that will be qualified and quantified in the rest of the study. In order to generate the FMEA from UML/SysML models, we use techniques of data translation using files exploiting XML (eXtensible Markup Language). The creation of the FMEA is detailed in the fourth section of this article.

We do not want to add the dysfunctional behavior to the first model. We thus build a model in mode automata [START_REF] Rauzy | Mode Automata and their compilation into Fault tree[END_REF] to depict the whole behavior of the system. We have chosen the mode automata formalism because of its structure. With mode automaton, it is easy to represent for each component of the system their reachable states and the treatment of the flow that they receive and transmit. The construction of the model is done component by component, so that the decomposition established in the FMEA can be naturally reused. Moreover, this modeling formalism highlights the error propagation between components by describing the flow ports and the state of the flow. Then, with a mode automata model it is possible to derive models in Al-taRica (programming language implementing mode automata) or Generalized Stochastic Petri Nets (GSPN). The main concern of those models is to show the influence of data and energy transmission throughout the architecture of the model. The rules of creation of those models will be given in future communications Both AltaRica and GSPN models are used in software tools (respectively the OCAS module of Cecilia workshop and Jagrif edited by Dassault Data Services). Those software tools permit to quantify reliability indicators, such as global failure rate or mean time to failure. Solutions to compute fault trees also exist (e.g Aralia Sim Tree) and give a mean to find failure scenarios and also to compute failure rates. The last step of our approach is thus to use those kind of tools on the previously obtained models in order to compute the necessary results for the design evaluation.

In order to render this approach efficient, we develop tools for the automatic creation of each model and for the construction of the files needed by the reused tools. We try to construct a bridge as short as possible between a functional design and the evaluation of the reliability characteristics of the proposed architecture. A software tool is developed in order to integrate the different phases in a single application. In the next section, we will discuss the realization of the first step. We will present the problems raise by the automatic synthesis of FMEA and mention the existing works. Then, we will describe our policy for an automatic synthesis of FMEA.

AUTOMATIC SYNTHESIS OF FMEA DERIVED FROM UML/SYSML FUNCTIONAL MODELS

FMEA is the standard method for risk analysis in the design phase [START_REF] Tumer | Requirement for a failure mode taxonomy for use in conceptual design[END_REF]. It is a well-known inductive and qualitative method that proposes to explore the system component by component. For each one the analyst searches their failure modes and their effects on the system, detailing their severity and occurrence rate, in order to underline their weak points.

Works on FMEA automation

Over the past few years, many authors have mentioned the obstacles against FMEA execution. In fact, many organizational and operational constraints reduce its efficiency. FMEA is often seen as a time consuming and error prone analysis. For industrial user, it is frequently difficult to link the results of FMEA with the execution of corrective procedures.

The main interest of FMEA, which brings up information to direct design efforts, is thus lost. The heaviness of the method seems to have many origins, as the difficulty to call together the participants or the huge amount of information to produce, represent and understand. Nevertheless, this method, created to satisfy precise needs in system analysis, has sufficient advantages to justify works on it. The method provides a systematic detection of risk and failure at an early stage of the design process. It guarantees the exhaustive identification and the classification of risks. Finally, it allows to identify the weak points of the system only from a functional view.

The benefits of this analysis are important enough to justify the employment of new techniques to enhance its utilization. There are two options to improve FMEA, which are: to ameliorate the organization or to support the study with software. Bassetto, in (Bassetto 2005), thanks to an experiment on a whole plant, gives organizational advises to involve the engineers and enhance their perception of FMEA:

• Define the analysis limits and objectives.

• Constitute team with experts and user of the analyzed system. • Teach the method to the participants.

• Impose regular meetings.

• Obtain the interest of the management and operational teams by underlying their benefits in using the method. To improve those dispositions, it seems very important to support FMEA with a software tool. Many authors and normative documents have pointed the lack of adapted software for FMEA management. By the way, many researchers have explored how software could be useful for FMEA development. Therefore, it exists various helps brought by software tools:

• Maintaining a return on experience database (Bassetto 2005). • Help to fill the FMEA table.

• Automatic synthesis of parts of the FMEA table (Papadopoulos et al. 2004a), [START_REF] Bull | A computational tool for failure modes and effects analysis of hydraulic systems[END_REF]). • Organizing and highlighting the relevant elements [START_REF] Price | AutoSteve: automated electrical design analysis[END_REF]. • Help for the use and creation of failure taxonomy [START_REF] Tumer | Requirement for a failure mode taxonomy for use in conceptual design[END_REF], (Bassetto, 2005). • Model generation from FMEA table (Papadopoulos 2004b). • Managing simultaneous failures [START_REF] Price | Automated multiple FMEA[END_REF], (Papadopoulos, 2004b).

The automatic synthesis of FMEA is treated in multiple works. Some of those are centered on the exploitation of a database and on making it sustainable. Others deal with the automatic generation of information by causal reasoning. In the two main works [START_REF] Price | Automated multiple FMEA[END_REF], (Papadopoulos et al. 2004b), the requisites for automatic synthesis of the FMEA are the modeling of each failure for each components. The real benefit of these methods is the computation of the effect on the whole system. The profit of the FMEA is no more to identify the unitary failures that could occur, but to find multiple failures that could be significant. Finally, we can mention works on the semantic used in FMEA. To solve the ambiguity of coupling natural vocabulary with quoted values, [START_REF] Bowles | Fuzzy logic priorization of failures in a system failure mode, effects and criticality analysis[END_REF] propose to use fuzzy logic rules. This technique is still experimented in recent works [START_REF] Xu | Fuzzy assessment for engine systems[END_REF], [START_REF] Yeh | Fuzzy assessment of FMEA for sewage plant[END_REF] on various kinds of system (engine, sewage plant). Those different works helped us to identify the crucial points for the automation of FMEA creation.

Influential points for Automatic synthesis of FMEA

We have identified two major points for the success of an automatic synthesis of FMEA. These are the model from which the analysis is built on the one hand, and the database of dysfunctional behavior on the other hand. FMEA specification indicates that this analysis is developed on the results of a functional analysis. In fact, the analyst needs to know each function of each component to conduct his FMEA. In order to fill each line of the FMEA, the engineer plays a component life scenario, so he must be familiar with the functioning of the relationships between system components. To express this functional information, many methods and languages are utilizable; the majority of them are technologically dedicated solutions. Currently, the methods utilized for the automatic synthesis of FMEA are functional models enriched by data on the dysfunctional behavior of the components [START_REF] Price | AutoSteve: automated electrical design analysis[END_REF]Taylor 2002, Papadopoulos et al. 2004a). This is quite paradoxical with the first aim of FMEA, which is to underline and detect risks and failures only from the knowledge of the expected functional behavior. For us, a model is exploitable for FMEA, if it allows to isolate the architecture of the system (physical distribution of the functions), as well as the energy and data transmission between components. In fact, in a deductive study it is important to easily recognize the propagations between the system elements. To sum up, the elements that the modeling language, used for FMEA, should be able to model are the following:

• Architecture of the system and its functionalities

• Hierarchy between blocks • Data and flow transmission Those aspects can be modeled with UML or SysML by the use of class diagrams, composite diagrams and deployment diagrams. A data and flow transmission view also exists in sequences diagrams and interaction diagrams, moreover the UML 2.0 and SysML specifications introduce very useful flow port diagrams. Finally, the possibility to classify the objects gives to those languages a great capacity to furnish easily reusable uniform information. It is essential to construct a database containing the return on experience on the failure modes of utilized components. [START_REF] Basetto | Contribution à la qualification et à l'amélioration des moyens de production ~ Application à une usine de recherché et production de semi conducteurs[END_REF] exposes that: "if each risk component possesses its own typology, the automatic generation of risk can be envisaged". For Basetto a "risk" is the term that refers to a FMEA line. A risk is thus composed of an element name, its failure modes, their effects and causes and optionally its severity and occurrence. According to him the automatic generation of FMEA can be performed only if the set of words utilized to qualify each risk element is finite and previously known. In the FMEA process, this kind of database is used in two ways: firstly the database is a source that helps proposing for each element the right and precise failure modes, secondly after the user has reviewed and completed the FMEA the new information must update the database for the specific use of the component in the studied system. In those conditions, FMEA becomes a precious resource for the establishment of a management process for return on experience. Nevertheless, the use of a database causes an unavoidable rigidity in the employed vocabulary. In fact, taxonomy must be fixed, researcher teams as [START_REF] Tumer | Requirement for a failure mode taxonomy for use in conceptual design[END_REF] work on that topic. For instance this team defined taxonomy on failure modes for plastics. The taxonomies aim at describing in precise words the elements that compose FMEA lines. Those elements depend on the studied technology. Each technological domain possesses its own terminology. The risk elements that should have their proper taxonomy are the components, functions, failure modes, effects, causes, detection means and the corrective actions. This exhaustive list can be reduces regarding the goals of the FMEA. A typology for the components is essential for the automatic synthesis, moreover it provides means for the reuse of known components in new systems. The component typology constitutes an entry in a database that indicates each failure modes for the designated element. This simple mechanism is a main step in the automation of FMEA synthesis, which helps to guarantee the exhaustive enumeration of failure modes. Then a typology of failure modes is necessary and will authorizes to reason on effects and characteristics as severity and occurrence. Using typologies for effects and causes makes possible to underline consequence relationships between risks.

For example Basetto analyses the bijections between the typology set of effects and causes and so highlights the "risk core" of his application. The use of typologies for the database exploitation in the case of automatic FMEA synthesis is essential. Therefore, to be efficient we must impose on the designer the respect of a typology for the definition of his model. The best way is to reuse as much as possible his own vocabulary and to let him modify and enrich the database with his own experience.

Using UML/SysML for automatic synthesis of FMEA

We will describe in this section our solution for the automatic synthesis of FMEA. Our goal, in this step, is to render operational the execution of a FMEA. The role of this FMEA is to help us to find the dysfunctional behavior of the studied system with its functional model. We wish to use the model designed by the conception engineer without adapting it to our purpose. We want to make this generation as complete as feasible, but also as fast as possible.

Exploited model and first solution

As explained in the second section, using models in UML/SysML seems to be the best solution in order to define a general approach that is to be integrated in a modern design process. The models in UML/SysML are well suited to be exploited for FMEA generation. Traditionally, FMEAs are built from functional analysis. Our first algorithm only exploited the sequence diagrams of the designer models. The use of sequence diagrams in order to create an FMEA is justified because we observe that it is possible to find the same information about the studied system in both formats. The functional analysis makes it possible to identify all the system functions. These are the functions that are described by each use case represented by the sequence diagrams. An algorithm that we developed, whose instructions are described in the following lines, realizes the treatment that creates the FMEA from sequences diagrams.

Input of the algorithm:

• Set of the Actors noted A • Set of the Objects noted O (A ∩ O = ∅)

• Set of the messages noted M The elements of M are couples (x,y) where x, y∈A∪O, x is the sender of the message and y its receiver.

• C and E are two empty sets (Causes, Effects)

• The set of the failure modes is noted FM FM = {partial function, no function, intermittent function, unintended function} Output of the algorithm:

• Table of the FMEA Operators:

• + is the operator of concatenation on the right

• for m ∈ M, m = (m[1], m[2])

Start of the algorithm:

Creation of a table whose first line is composed of 9 boxes that indicate, the name of the object or actor, the failure mode, the cause(s), the effect(s), the severity, the probability, the risk, the means of detection, the technical solutions.

∀i ∈ A ∪ O and ∀ fm ∈ FM ∀ m ∈ M, if m[2] = i, C = C + m[1] ∀ m ∈ M, if m[1] = i, E = E + m[2] Creating a line = {i, fm, C, E, ∅, ∅, ∅, ∅, ∅}
This algorithm has been tested on diagrams used by [START_REF] Guiochet | Toward a human-centered UML for risk analysis[END_REF]. Results and benefits of its utilization are exposed in [START_REF] Belhadaoui | Outil d'aide a la conception des systèmes mécatroniques sûr de fonctionnement[END_REF]).

The main interest of this version is that it automatically lists all systems components and proposes to evaluate their behavior according to the fourth basic failure modes. Moreover, it directly associates the entity linked with the component so that the effects and causes are easier to identify. In [START_REF] Belhadaoui | Outil d'aide a la conception des systèmes mécatroniques sûr de fonctionnement[END_REF], the authors used this algorithm on a processor UML model. They remark that our solution allowed them to find faster the same information that they found in a previously manually built FMEA. They add that they saved time, by using this algorithm (implemented in a prototype), in the FMEA creation. Moreover, they indicate that it permitted them to identify new risks forgotten in the previous study, thanks to the links between components and the failure modes proposed by the software tool. Nevertheless, this first solution has a significant drawback. In fact, too many lines are produced and the identified risks need to be clarified by the user. Consequently, we decided to enhance this algorithm, thanks to a connection with a component database. The database proposes for each component its proper failure modes. Those modes are taken from documents on the return on experience of the components. The created FMEA became more precise and concise. The connection to the database intervenes for the enumeration of the failure modes. The algorithm identifies the type of the studied component and then it searches the right failure modes for the component in the database.

Classification and database constitution for

automatic FMEA synthesis As presented in section 4.2.2 the database of functional behavior is crucial because it involves the return on experience for the risk identification. This way, we insure the coherence among various risks studies and we automatically obtain more precise results. The database that we use contains the failure modes of the component that we exploit. Therefore, the new algorithm indicates for each risk the right failure modes as they are described in the database.

Nevertheless, if a component not indicated in the database is met, the algorithm will continue to propose the basic failure modes as in the first version. Later, by integrating the failure modes corrected by the analyzers, the database can be enhanced. Figure 2 illustrates the use of a database for FMEA creation. We have constructed our database using the concept of class depicted in UML and extended in SysML with the Block Definition Diagrams (BDD). This enables us to work at various level of detail in the systems description. In fact, types of components can be depicted with generalization relationships. If SysML is used, the database is constructed with BDDs, an example his given on the bottom part of Figure 3. The database is organized around the components types. Generalization relationships exist between them, for each type we indicate their failure modes as attributes. The names of the failure modes are indicated so that the algorithm will be able to note them in the FMEA table. This technique helps us to save a lot of time in the FMEA synthesis. We are able to create a major part of the FMEA in a precise way and we also guarantee that we exhaustively study the components. Figures 3 and4 show a typical use of this algorithm on simple sequence diagrams. The part of FMEA that is automatically created is given. We can read in this table the precise failure modes of the components as well as suggestions about the behavior of the failure (components involved in causes and effects).

The component database can be completed by a failure modes database. This second database allows us to conduct the next step of the process presented in section 3. In fact, this database describes the failure mode types defined in the component database. We associate diagrams expressing their behavior with the failure mode types. Those diagrams could be GSPN models, AltaRica files or Statecharts diagrams. This will be a first step in an automatic creation of the dysfunctional model. Moreover those diagrams can help to find the effects of the failure modes and thus to build the FMEA. We are currently developing a software tool in order to fully integrate the first step of our approach. This tool is designed to help designers in FMEA synthesis. The UML or SysML files written in XML, thanks to the XMI formalism of the OMG, are loaded. Then the software uses a parser in order to interpret the data and execute the algorithm for the creation of the FMEA. This software is also designed to manage the database described before, it authorizes the user to fill and utilize it for the FMEA synthesis. A second parser will analyze the complete FMEA in order to pass the more precise information, on the failure modes, to the component database.

CONCLUSION

In this article we discussed the appropriateness of using UML/SysML for reliability studies. We briefly described our approach that aims at making easier reliability studies during design process. We pointed out the essential issues for automatic synthesis of FMEA as a method for risk and failure identification. Then, we presented our first solution for this synthesis. We presented a more efficient version of the preceding algorithm and focused on databases construction for this purpose. In the future, we will develop and integrate in our tool, a second parser in order to create Statecharts and GSPN from the results of the FMEA and the UML/SysML models. Moreover, the novelties of SysML specifications open new opportunities for reliability studies. For instance, we currently develop a third version of our algorithm exploiting the new SysML diagrams. We hope to realize the complete reliability study, using SysML and existing analysis tools. We wish to link the failure rates computations to their declaration in the component database. To perform that, it is possible to associate a parametric diagram for each failure mode of the components. This diagram models the equation for the failure rate calculus, linking environmental parameters and the component features. Those equations can be found in the normative documents dedicated to the studied technology.

Figure 1 .

 1 Figure 1. An approach from functional model to reliability indicators

Figure 2 .

 2 Figure 2. Use of a classified database for FMEA synthesis

Figure

  Figure 4. Deducted FMEA

ACKNOWLEDGEMENTS

We specially want to thank all our partners involved in the CAPTHOM project. This work was realized with the financial help of the French Industry Ministry and local collectivities, within the framework of the CAPTHOM project of the Competitiveness Pole S 2 E 2 , www.s2e2.fr.


Pierre David

Vincent Idasiak

Frédéric Kratz

ETUDE POUR UNE MEILLEURE INTEGRATION DES DONNEES DE CONCEPTION DANS LES ANALYSES DE FIABILITE STUDY FOR A BETTER INTEGRATION OF DESIGN DATA IN RELIABILITY ANALYSIS

De nombreux travaux ont montré, que la communication entre les experts de chaque domaine est l'un des points clef du développement des nouveaux systèmes complexes. Pour relever ce défi dans l'industrie du logiciel, l'OMG (Object Management Group) a développé UML (Unified Modelling Language). Depuis plusieurs années, de nombreux chercheurs travaillent sur l'adaptation de UML à l'ingénierie système. Ces efforts ont conduit depuis peu à la création de SysML, un nouveau langage pour la spécification, l'analyse la conception et la validation de systèmes complexes multi-technologiques. Dans cet article, nous présentons comment ces langages peuvent être intégrés pour combiner conception et analyse de sûreté de fonctionnement (SdF), dans le but de maîtriser les impératifs de SdF tout au long du processus de création. Pour cela, nous présentons une méthode d'analyse des critères de SdF s'appuyant sur les procédures classiques de conception, ceci dans le but de ne pas venir perturber le travail des concepteurs. Notre objectif est d'une part de faciliter la communication entre les concepteurs et les analystes SdF, et d'autre part d'accélérer et simplifier l'analyse SdF. Nous nous baserons sur l'emploi d'AMDEC pour la déduction des comportements dysfonctionnels. Nous présenterons notre solution pour la synthèse automatique de tableau AMDEC à partir de modèle UML/SysML décrivant uniquement le comportement fonctionnel du système. Nous insisterons en particulier sur l'apport de l'utilisation d'une base de données structurée pour la gestion du retour d'expérience. Le but de cet article est donc de décrire les premières étapes d'une nouvelle approche pour accélérer et simplifier l'analyse SdF de systèmes complexes. Cette approche s'appuie sur les langages classiquement utilisés en conception, elle propose d'automatiser au maximum les différentes étapes de création et d'analyse de modèles.

Summary

It is commonly admitted that one of the crux, during the design process of new complex systems, is the efficient communication between experts of different domains. The OMG developed UML to tackle this problem in software design. For several years, many researchers have been working on adapting and reusing UML for whole type of systems. These efforts led to the creation of SysML, a new modeling language for specifying, analyzing, designing and verifying complex multi-disciplinary systems. In this paper, we present how those modeling languages can be integrated to combine reliability study with the design process in order to compose a conception process driven by dependability priorities. We have set up a method to conduct reliability studies without perturbing the classic procedures of designers. Our objectives were on the one hand to facilitate communication between functional and dysfunctional analyzers and to simplify the execution of reliability studies on the other hand. In this article, we raise the utility of FMEA for a non-intrusive modeling of dysfunctional aspects. We thus give our solution for an automatic synthesis of FMEA from UML/SysML models, which only describe the nominal behavior. We insist on the keystone of this automatic synthesis, namely the use and management of a database constructed from the information of the return on experience. The purpose of this article is thus to describe the first steps of a new approach to enhance the realization of dependability studies by automating steps and using easily understandable models.

Introduction

La complexité des nouveaux systèmes ne cesse de grandir, il devient évident que la complexité de la phase de développement est liée au nombre de technologies différentes utilisées dans le système. Par exemple, la nécessité d'intégrer des composants logiciels a soulevé de nombreux problèmes auxquels se sont intéressés de nombreuses équipes de recherche. L'origine de ces problèmes d'intégration est bien souvent la difficulté de communiquer entre experts de domaines différents. Les vocabulaires employés par les spécialistes ne sont pas homogènes, ce qui conduit à des erreurs de compréhension et d'interprétation pouvant se révéler source d'erreurs. Le problème est le même lorsqu'il s'agit de considérer la réalisation de modèles. Il n'est pas toujours aisé de synchroniser des modèles spécifiques à chaque technologie employée. De même, les modèles employés en SdF pour qualifier et quantifier le comportement dysfonctionnel des systèmes sont trop souvent difficiles à comprendre et à construire par les ingénieurs de conception. C'est pourquoi les études SdF et les démarches de conception sont souvent perçues comme deux tâches bien distinctes du processus de développement. Ceci réduit fortement l'intérêt des analyses SdF, qui sont alors cantonnées à un rôle de validation plus qu'à un rôle d'aiguillage dans le design. En résumé, nous pouvons dire que les concepteurs et analystes sont confrontés à deux problèmes majeurs que sont, la communication inter-discipline et l'intégration multitechnologique. Le défi pour une étude efficace de SdF est donc de pouvoir combiner les modèles utilisés en conception et les méthodes d'analyse spécifiques au domaine de la SdF. Dans cet article, nous présentons la démarche et les outils développés dans le but de relier le plus rapidement possible les choix de conception et leurs impacts sur la SdF globale du système. Cette démarche a pour ambition de rendre à l'analyse SdF un rôle moteur dans le processus de développement. Dans la suite de ce papier, nous soulignerons l'intérêt de l'utilisation d'UML et SysML pour le design de système complexe. Nous présenterons ensuite l'utilisation de ces langages dans le cadre d'analyse SdF. Puis, nous introduirons notre méthode utilisant les diagrammes UML/SysML, avant de décrire plus en détail la première étape. Cette dernière permet de déduire le caractère dysfonctionnel d'un système à partir de son comportement fonctionnel, par le biais de la génération automatisée d'AMDEC. Nous présenterons un exemple d'utilisation de cette méthode sur un système de contrôle d'une cuve.

L'analyse SdF de système à partir de modèles UML et SysML

Des langages pour la conception de systèmes multi-technologiques

Comme nous l'avons mentionné en introduction, la bonne communication entre les acteurs d'un projet est un point essentiel dans le développement des systèmes complexes. Cette problématique est très présente dans le domaine de l'ingénierie logicielle, où le client final a souvent de grosses difficultés pour appréhender le vocabulaire très spécifique et précis du monde de l'informatique. L'expression des besoins dans ce domaine est devenue délicate et source d'importantes erreurs. Pour tenter de mettre un terme à ces difficultés, la communauté scientifique a mis au point différents langages synthétisés de nos jours en une unique spécification : UML. UML a été spécifié dans le but de modéliser les projets informatiques ou les systèmes incluant du logiciel sous une forme compréhensible par tous. Ce langage a largement atteint ses objectifs et est actuellement très employé dans le domaine du développement logiciel.

16ème Congrès de Maîtrise des Risques et de Sûreté de Fonctionnement -Avignon 6-10 octobre 2008 communication 2B-2 page 2/2 Depuis la spécification 2.0, UML n'est plus réservé à la programmation, grâce à son approche orientée-objet (OO), il devient exploitable pour la description de tous types de systèmes. De nombreuses publications mentionnent les avantages de l'approche OO pour l'ingénierie de systèmes complexes et conseillent donc l'emploi de l'UML 2.0. Néanmoins, en raison de sa sémantique trop orientée logicielle, il n'est encore que peu utilisé pour la conception de systèmes n'incluant pas une part significative de logiciel. Par conséquent une attente forte existe toujours pour un langage permettant la description de système où le caractère pluridisciplinaire est prédominant. C'est pourquoi l'OMG a créé SysML [START_REF] Omg | OMG systems modeling language (OMG SysML) V1.0. 1er septembre[END_REF] pour spécifier, analyser, concevoir et valider les systèmes complexes. SysML a été construit depuis avril 2003 comme une extension d'UML adaptée au vocabulaire de l'ingénierie système et apportant de nouveaux moyens pour la modélisation et la spécification. Dans [START_REF] Willard | UML for systems engineering[END_REF], l'auteur souligne l'héritage provenant d'UML 2.0 et introduit les nouvelles possibilités de SysML en matière d'accessibilité et d'adaptabilité à des domaines variés. Dans [START_REF] Hause | The SysML modeling language. 15th European systems engineering conference[END_REF], le lecteur pourra trouver une bonne introduction à SysML et à ses nouveaux diagrammes que sont les diagrammes de spécifications et les diagrammes paramétriques. SysML permet de modéliser aussi bien l'architecture du système que son comportement, il réutilise les diagrammes de classe et d'objet d'UML, tout en adaptant la sémantique en utilisant la dénomination de « bloc » pour tout type d'entité (abstraite ou instanciée). Les nouveaux diagrammes ajoutent de nouvelles possibilités comme la captation des exigences ou l'ouverture à une structuration proche des EFFBD (Extended Functional Flow Block Diagram). En outre les diagrammes paramétriques permettent de recenser et structurer les équations reliant les paramètres physiques du système. Dans [START_REF] Peak | Simulation-based design using SysML Part 1: a parametric primer & Simulation-based design using SysML Part 2: celebrating diversity by example[END_REF], les auteurs décrivent les origines de ces diagrammes et leurs liens avec les COB (Composable OBject), ils démontrent alors comment SysML pourra être utilisé pour nourrir des moteurs de simulation. En particulier, ils présentent une application à l'outil d'analyse et de résolution d'équation XaiTools (X-Analysis Integration Toolkit du Georgia Institute of Technology). UML et SysML sont exploitables pour la conception de système. L'approche OO utilisée ainsi que la modélisation hiérarchique et les possibilités de composition semblent être idéales pour traiter des problèmes pluri-technologiques. De plus, la notation graphique de ces langages permet d'accélérer la compréhension des modèles et permet de les rendre rapidement accessible à des néophytes. Enfin le dernier avantage que nous pouvons mentionner pour ces langages est la présence sur le marché de nombreux outils logiciels intégrant ces spécifications. En particulier, bien que SysML soit un langage finalisé récemment, de nombreux outils UML l'implémentent déjà.

UML et SysML pour l'analyse de la SdF

Devant l'intérêt croissant des ingénieurs système pour UML, les analystes de la SdF ont à leur tour cherché à exploiter ce langage. Ces recherches ont mené aux résultats suivants dont l'adaptation à SysML est un de nos axes de réflexion. L'intégration d'exigences de SdF ou l'analyse des critères SdF des systèmes à partir de modèles UML posent de nombreux problèmes de construction et de modélisation d'informations, [START_REF] Leangsukun | Reliability modeling using UML[END_REF] décrit la problématique de la modélisation de la SdF dans le domaine informatique. Les auteurs font la remarque que les programmeurs ne maîtrisent pas les techniques d'estimation de la SdF. Par conséquent, ils ont imaginé une méthode pour réduire le fossé entre les méthodes des programmeurs et celle conçues pour l'analyse. Ils proposent de définir un nouvel ensemble de stéréotypes UML, permettant de décrire le comportement dysfonctionnel du système. Ce comportement est ajouté au modèle fonctionnel du système de sorte que le modèle résultant présente conjointement les deux facettes du système. Pour exploiter ce modèle construit manuellement, les auteurs proposent un outils utilisant le langage XML pour extraire automatiquement les paramètres nécessaires afin de lancer une analyse du système avec l'outil SHARPE (Symbolic Hierarchical Automated Reliability and Performance Evaluator développé par Duke University). Ceci leur permet par la suite d'obtenir et d'analyser de façon classique des arbres de défaillances et des modèles utilisant les chaînes de Markov. Pour illustrer leur propos, leur méthode est testée sur une architecture client/serveur de type 2/3. Dans [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF], Zarras et Issarny avaient déjà fait utilisation de stéréotypes pour la saisie formatée de données dysfonctionnelles. De plus, ils ont utilisé le langage OCL (Object Constraint Language) pour saisir les spécifications fonctionnelles du système. Ces deux travaux ( [START_REF] Leangsukun | Reliability modeling using UML[END_REF], [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF]) montrent qu'UML peut être utilisé afin de considérer les aspects dysfonctionnels et les exigences de SdF. Une spécification et une étude en UML peuvent donc servir de point de départ pour l'analyse SdF d'un système. On voit également que les résultats de cette analyse pourront être répercutés et exprimés dans le même modèle que celui utilisé par le concepteur initial. Cependant, les deux méthodes présentées dans ces publications sont dédiées chacune à un outil d'analyse particulier. De plus, elles font chacune appel à un ensemble de stéréotypes UML qui leur est propre. Ceci rend ces solutions très peu généralisables et exploitables telles quelles par le reste de la communauté. Enfin, on peut noter que la construction du modèle dysfonctionnel est réalisée de façon empirique par l'utilisateur et ne découle absolument pas de l'analyse du premier modèle UML. Dans [START_REF] Zarras | Model-driven dependability analysis of web services[END_REF], Zarras emploie une approche légèrement différente. Le modèle dysfonctionnel est construit de la même façon cependant son exploitation est différente. Il ne s'agit plus de simplement mettre en forme les données pour un outil spécifique, mais de générer automatiquement des modèles de SdF, tels que des arbres de défaillances et des chaînes de Markov. Néanmoins, les applications considérées restent uniquement tournées vers des systèmes informatiques et supposent que l'utilisateur est capable de décrire lui-même l'ensemble du comportement dysfonctionnel du système. A l'inverse, d'autres travaux exploitent les modèles UML pour déduire ce comportement. Dans [START_REF] Guiochet | Toward a human-centered UML for risk analysis[END_REF], l'approche est fondamentalement différente. L'analyse d'un robot de télé-échographie y est présentée. Dans ce cas, le modèle n'est pas construit pour représenter les défaillances du système mais pour les déduire grâce à l'emploi d'une méthode d'analyse des risques. Pour cela, les auteurs ont défini un ensemble de modèles d'erreurs pouvant affecter les messages rencontrés dans les diagrammes de séquences UML (présent sous la même forme en SysML). La méthode proposée se compose de deux phases, la première est de modéliser la tâche ou la mission que l'on souhaite analyser. Il est à noter que les interventions humaines peuvent être prises en compte. La deuxième étape consiste à utiliser les modèles d'erreur dans une analyse de type AMDEC pour ainsi déduire les risques encourus. Ces multiples approches prouvent que UML est adapté pour l'expression ou la déduction d'informations sur le comportement dysfonctionnel des systèmes. Néanmoins l'utilisation massive de stéréotypes rend ces travaux peu réutilisables, car dirigés par des besoins spécifiques et souvent particuliers aux cas d'étude ou à des habitudes personnelles. En effet, les principes de construction du modèle et les informations modélisées sont conditionnés par l'analyse que souhaite faire l'utilisateur. De plus, pour être exploitables les modèles utilisés sont souvent régis par des règles strictes et difficiles à se réapproprier. Pour se montrer plus universel, on doit chercher à raisonner à partir de modèles directement issus de la modélisation de l'analyse fonctionnelle. Dans de nombreux cas, l'ajout direct de la partie dysfonctionnelle au modèle peut rendre ce dernier plus difficile à appréhender et améliorer. Dans tous ces travaux précédents, on remarque que malheureusement les modèles UML sont construits spécialement pour la réalisation d'analyses SdF. Il s'agit dans ces travaux non pas de réutiliser les modèles des concepteurs, mais de se servir du même langage de modélisation. La simple utilisation d'UML ne résout donc pas le problème de l'intégration des analyses SdF au processus de conception. L'utilisation de SysML permet de réduire certains des inconvénients rencontrés dans les travaux précédents par le biais, entre autres, de l'utilisation des nouveaux diagrammes. Par exemple, les diagrammes de spécification permettent d'exprimer naturellement les exigences et de les allouer aux différents composants sans utiliser des règles OCL comme en [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF]. De plus la modélisation des aspects de fiabilité est un objectif déclaré de SysML. Les diagrammes paramétriques peuvent par exemple correspondre à des calculs de taux de défaillances pour un composant considéré. En combinant ces diagrammes avec un solveur, comme décrit dans [START_REF] Peak | Simulation-based design using SysML Part 1: a parametric primer & Simulation-based design using SysML Part 2: celebrating diversity by example[END_REF], il deviendra possible de déduire des indicateurs SdF comme un taux de défaillance global du système. Dans la section suivante, nous allons décrire notre solution pour la réalisation d'une analyse SdF s'interfacant au mieux avec le processus de conception.

Intégrer l'analyse de la Sûreté de Fonctionnement au processus de conception

Comme nous venons de le voir, les travaux précédents concernant l'utilisation d'UML pour réaliser l'analyse de la SdF au plus près des préoccupations des concepteurs, sont certes perfectibles mais démontrent un fort potentiel pour l'utilisation d'UML ou SysML en SdF. UML, et à n'en pas douter dans un futur proche SysML, seront les langages de modélisation bénéficiant de la plus large utilisation dans le domaine du développement de systèmes complexes. Le but de nos travaux n'est pas de trouver comment modéliser les défaillances en UML et SysML, mais de trouver la façon la plus générale possible pour exploiter ces modèles, afin d'obtenir de nouvelles informations sur la fiabilité du systèmes. Au final, on souhaite obtenir le plus rapidement possible des critères caractérisant la SdF du système, permettant de prendre une décision au niveau de la conception. Un des désavantages majeurs des analyses de SdF est qu'elles compliquent et ralentissent le processus de conception. C'est pourquoi notre ambition est de créer un logiciel capable de fournir au designer un maximum d'informations sur la fiabilité du système sans qu'il soit un expert de SdF. Nous proposons pour cela de suivre une méthode déductive et itérative en trois étapes :

• A partir du modèle fonctionnel rédigé par le concepteur, la première étape consiste à l'établissement de l'AMDEC assistée par ordinateur. Cette AMDEC est réalisée sur la base de l'analyse des modèles UML ou SysML, en s'appuyant plus particulièrement sur les diagrammes de séquences. A l'inverse de [START_REF] Leangsukun | Reliability modeling using UML[END_REF], [START_REF] Zarras | A UML-based framework for assessing the reliability of software systems[END_REF] et [START_REF] Zarras | Model-driven dependability analysis of web services[END_REF], nous ne supposons pas connaître le comportement dysfonctionnel des composants. Nous nous plaçons donc dans le cas où l'analyse SdF du système doit être réalisée entièrement. On suppose que l'utilisateur possède au mieux une base de données constituée à partir du retour d'expérience sur la vie de tout ou partie des composants employés. Le rôle de cette étape est donc de recenser les défaillances pouvant toucher le système. Ce point de l'étude est donc critique pour le reste du déroulement de l'analyse SdF, car il fournira les éléments de base du raisonnement à l'échelle du système. Dans la section 4, nous présentons comment accélérer la réalisation de l'AMDEC et rendre cette analyse exploitable pour accélérer et intégrer l'étude de la SdF. L'obtention de scénarios de défaillance ainsi que le calcul d'indicateurs de fiabilité nécessite l'utilisation de modèles et langages formels (RDPSG, AltaRica, Figaro, BDMP). La construction de ces derniers nécessite une expertise. Nous envisageons donc de réaliser des outils d'aide à la création de ces modèles s'interfaçant avec les outils de traitement actuels, a l'instar de l'outil OPALE permettant de générer le modèle de fiabilité et de disponibilité de réseaux électriques [START_REF] Bouissou | Automated Dependability Analysis of Complex Systems with the KB3 Workbench: the Experience of EDF R&D[END_REF]. Dans l'exemple de la Figure 1, nous proposons de construire un modèle en automate de mode [START_REF] Rauzy | Mode Automata and their compilation into Fault tree[END_REF]

Synthèse automatique d'AMDEC à partie de modèles fonctionnels en UML/SysML

L'AMDEC est une méthode standard pour l'analyse des risques et la détection de défaillances potentielles, utilisable très tôt dans le processus de développement [START_REF] Tumer | Requirement for a failure mode taxonomy for use in conceptual design[END_REF]. C'est une méthode inductive et qualitative bien connue, qui propose de détailler le système composant par composant. Pour chacun d'entre eux, les analystes recherchent leurs modes de défaillances, les effets de ces derniers ainsi que leurs causes. Ensuite dans le but de repérer les points faibles de la structure, on affecte une cotation en terme de probabilité d'apparition et de gravité à chacun des risques identifiés. Dans cette partie nous allons présenter les travaux existants pour la gestion des AMDEC. Ensuite, nous fournirons notre solution exploitant les diagrammes UML/SysML ainsi qu'une base de données regroupant le retour d'expérience. Nous montrerons, à travers ces deux sections, en quelle mesure notre solution est novatrice. ter et comprendre. En effet, l'établissement d'une AMDEC doit se faire en présence des experts de chaque domaine ou partie du système ou processus étudié. L'étude a pour résultat un long tableau sous forme papier, qu'il est bien souvent difficile d'appréhender eu égard à l'importance du nombre de lignes crées dans une étude complète. Enfin, ces différentes contraintes ont pour effet de retarder les AMDEC de sorte qu'elles se trouvent réalisées bien trop tard dans le processus de conception, annihilant ainsi une des principales missions de l'AMDEC : identifier au plus tôt dans le cycle de développement les risques et défaillances probables du système. Une dernière critique relevée sur l'AMDEC est l'impossibilité de mettre en évidence les effets de défaillances multiples. Il a été démontré à de nombreuses reprises que les pannes combinées ont bien souvent un comportement bien différent de la simple addition des effets des défaillances particulières. Toutes ces difficultés entrent en contradiction avec les bénéfices attendus des AMDEC. Cette méthode est née d'attentes très précises en matière d'analyse et de conception. Il a été vérifié qu'elle permet une recherche exhaustive des risques encourus par le système. Elle permet alors de détecter très tôt dans la conception les points sensibles sur lesquels focaliser toutes les attentions. Son système de cotations fait ressortir des priorités entre les risques, ce qui permettra aux concepteurs de justifier la non-correction de défaillances jugées mineures par leur faible dangerosité ou par leur faible probabilité d'apparition. Le traitement systématique des risques liés au système peut alors être envisagé, ceci représente une étape importante vers une conception de systèmes sûrs de fonctionnement et non dangereux pour l'utilisateur final. Le principal atout de l'AMDEC est alors de pouvoir déduire très tôt le comportement dysfonctionnel du système à partir de sa description fonctionnelle. La seule étape nécessaire qui précède l'AMDEC étant une simple analyse fonctionnelle. L'AMDEC est aussi très appréciée pour la constitution de base de données concernant l'ensemble des composants rencontrés au cours des études. Le recensement systématique des modes de défaillance et de leurs cotations permet de constituer une base importante pour utiliser le retour d'expérience dans les nouvelles créations. Le format de présentation est très facile à réorganiser en structure de données accélérant les travaux futurs. Pour toutes ces raisons les travaux concernant les AMDEC restent très nombreux. Le but de ces travaux est de trouver les moyens de combattre les entraves à l'établissement efficace d'AMDEC. Les apports de ce type d'analyse sont en effet suffisamment importants pour justifier l'emploi de nouvelles techniques pour accélérer et rendre plus robuste la réalisation d'AMDEC. Pour cela les chercheurs disposent de deux leviers pour rendre optimum ce travail. On peut agir sur l'aspect organisationnel et sur l'ajout d'un support logiciel dans la conduite des analyses. Bassetto [START_REF] Basetto | Contribution à la qualification et à l'amélioration des moyens de production ~ Application à une usine de recherché et production de semi-conducteurs[END_REF] fort d'une expérience menée à grande échelle fournit quelques conseils d'organisation pour impliquer les ingénieurs responsables des AMDEC et améliorer leur perception sur l'efficacité de la méthode:

• Définir l'objet et les limites de l'analyse Génération de modèle à partir de l'AMDEC [START_REF] Papadopoulos | A method and tool support for model-based semi-automated FMEA of engineering designs[END_REF]. La génération automatique, partielle ou complète, est donc l'objet de multiples travaux. Certains se focalisent sur l'exploitation d'une Base de Données et la pérennisation des résultats, quand d'autres mettent l'accent sur la génération automatique d'information par des simulations de modèles. Dans [START_REF] Price | Automated multiple FMEA. Reliability engineering and system safety[END_REF], les auteurs présentent l'outil AutoSteve d'aide à la conception de systèmes électroniques complexes à destination de l'automobile. L'outil réalise principalement une création automatisée d'AMDEC. Les auteurs décrivent une méthode de génération d'AMDEC de premier niveau (mode de défaillance simple), puis une méthode pour la recherche des défaillances multiples dont le souci est de contenir l'explosion combinatoire par des moyens « d'élagage » de l'arbre des scenarii de défaillance. Ainsi une méthode et des règles de sélection des risques significatifs sont utilisées. La génération d'AMDEC simple est réalisée dans AutoSteve par simulation qualitative d'un modèle de la carte électronique, réunissant la partie fonctionnelle et la partie dysfonctionnelle de chaque composant. La simulation peut donc être déroulée sur le modèle sans connaître précisément chaque composant mais en se cantonnant à la connaissance de sa fonction. Dans [START_REF] Papadopoulos | A method and tool support for model-based semi-automated FMEA of engineering designs[END_REF], les auteurs développent une approche cherchant à rester généraliste et applicable à tout type de technologie. Le modèle fonctionnel du système est saisi sous Matlab Simulink, puis enrichi par une série d'arbre de défaillances créés automatiquement à partir de la saisie du caractère dysfonctionnelle des composants. L'AMDEC est ensuite réalisée par l'étude des arbres de défaillances. Cette méthode permet à partir de la connaissance des défaillances particulières de chacun des composants de déduire l'effet des défaillances à l'échelle du système et de considérer les défaillances simultanées. Pour ces deux précédents travaux, le pré-requis à la création automatisée de L'AMDEC est la connaissance et la modélisation des défaillances particulières de chaque composant. L'apport réel de telles méthodes dans la mise en place de l'AMDEC est donc le calcul des effets des défaillances à l'échelle globale du système. L'intérêt d'une telle AMDEC n'est alors plus la découverte et le recensement des défaillances individuelles, mais leur sélection au regard de leurs conséquences ainsi que la recherche de défaillances multiples significatives. Enfin pour clore cet état de l'art on peut mentionner les travaux cherchant à réduire l'ambiguïté des cotations et du vocabulaire employé dans les AMDEC. [START_REF] Bowles | Fuzzy logic priorization of failures in a system failure mode, effects and criticality analysis[END_REF] propose un emploi de la logique floue permettant de transcrire de façon plus explicite et en langage naturel les cotations des risques. La méthode employée cherche, au moyen de règles d'inférences, à être plus précise sur la qualification de risques ayant un indicateur RPN (Risk Priority Number) similaire mais un vecteur de risques différents. Dans ce travail les cotations des paramètres de fréquence, gravité et détectabilité sont notés de façon classique, l'emploi de la logique floue permet en sortie de caractériser le risque dans le langage naturel. La méthode a été utilisée sur de nombreux problèmes, comme explicité dans [START_REF] Yeh | Fuzzy assessment of FMEA for sewage plant[END_REF] qui applique la méthode à un moteur diesel. Une variante est également disponible, qui permet de s'affranchir des cotations chiffrées et de procéder dès le début en langage naturel.

les points sensibles pour l'automatisation de la création d'AMDEC

L'étude proposée au paragraphe précédent nous a permis d'identifier les points cruciaux de la génération automatique d'AMDEC. Nous en avons dégagé deux principaux. Ce sont d'une part le modèle à partir duquel est réalisée l'analyse et d'autre part la base de retour d'expérience concernant les comportements dysfonctionnels. En premier lieu l'AMDEC doit se « nourrir » d'une bonne analyse fonctionnelle du système. En effet il est indispensable de connaître parfaitement chaque fonction ainsi que l'ensemble des composants qui les réalisent. Le mode de fonctionnement de chacun d'entre eux doit être identifié et déclaré pour permettre la réalisation de l'AMDEC. Il faut connaître le mieux possible les relations entre chacun d'entre eux afin d'être capable de tirer les conclusions nécessaires pour la connaissance des effets de défaillance. Pour capturer ce comportement fonctionnel un très large éventail de méthodes, souvent spécialisées par technologie, existe. Actuellement les méthodes utilisées pour la gestion automatique d'AMDEC s'appuient sur des modèles fonctionnels enrichis par des informations sur le caractère dysfonctionnel des composants [START_REF] Papadopoulos | Automating the failure modes end effects analysis of safety critical systems[END_REF], [START_REF] Price | Automated multiple FMEA. Reliability engineering and system safety[END_REF]. Cet état de fait nous semble dans un sens paradoxal avec le but premier des AMDECs, qui est d'isoler et de Enfin la possibilité de classifier les objets donne à ce langage une grande capacité pour fournir une information facilement réutilisable et dont le contenu sera uniforme. Ce dernier ouvre une perspective vers la classification et l'enregistrement des composants dans des structures de base de données particulièrement adaptées à la conduite et à la pérennisation des AMDEC. L'emploi d'une Base de Données (BdD) est le second point clef pour une AMDEC. Pour [START_REF] Basetto | Contribution à la qualification et à l'amélioration des moyens de production ~ Application à une usine de recherché et production de semi-conducteurs[END_REF] la constitution d'une BdD est indispensable pour espérer créer automatiquement une AMDEC : « si chaque composante des risques possède ses typologies, la génération automatique de risques peut être envisagée ». La constitution de la BdD intervient en amont et en aval de l'AMDEC. La condition sine qua non pour l'automatisation d'une AMDEC est la connaissance pour chaque composant étudié de ses modes de défaillance, de son comportement fonctionnel et dysfonctionnel. Une fois l'AMDEC d'un système réalisée et enrichie par ses utilisateurs, la BdD d'origine peut être enrichie à son tour à partir de la nouvelle expérience obtenue de l'AMDEC. La constitution et l'exploitation d'une BdD dans le cadre d'une AMDEC nécessite la mise en place d'un vocabulaire fixé, spécifié et diffusé. Ce point délicat revient à fixer une typologie dans la création des AM-DEC. Cet aspect a été ciblé par de nombreux auteurs comme [START_REF] Basetto | Contribution à la qualification et à l'amélioration des moyens de production ~ Application à une usine de recherché et production de semi-conducteurs[END_REF] et a fait l'objet de développement particuliers comme [START_REF] Tumer | Requirement for a failure mode taxonomy for use in conceptual design[END_REF]. Les typologies ont pour but de décrire dans un vocabulaire spécifié les différents éléments présents dans les AMDEC. Ces éléments sont dépendants du type de technologie étudiée, et chaque « grand domaine » technologique doit pouvoir se doter de ses typologies propres. Les éléments devant bénéficier d'une typologie sont a priori les composants, les fonctions, les modes de défaillances, les effets, les causes, les moyens de détection et les actions correctives. La difficulté, pour être capable d'interpréter le modèle du concepteur, est de pourvoir faire concorder le vocabulaire du concepteur et la base de typologie. Il est donc préférable d'établir cette typologie en fonction des habitudes des développeurs, ainsi que de leur offrir la possibilité de faire évoluer et de compléter la BdD qui sera utilisée pour l'analyse SdF.

Utiliser UML/SysML pour la synthèse automatique d'AMDEC

Nous présentons dans cette section notre solution pour la création automatisée d'AMDEC. Cette solution s'attache à respecter nos remarques exposées précédemment sur le type de modèle analysable et l'apport d'une BdD bien formée. Notre but est donc de rendre opérationnelle l'AMDEC, avec pour ambition de se servir de cette méthode pour initier une démarche globale d'analyse de la SdF. L'utilisation d'une AMDEC automatisée est dans notre cas novatrice car l'automatisation porte sur la déduction des défaillances élémentaires. Ceci permet de réaliser une utilisation également nouvelle des diagrammes UML et SysML où il ne s'agit plus de simplement saisir un comportement dysfonctionnel, mais de pouvoir le déduire du modèle originel.

Modèle exploité et première solution réalisée

Comme décrit dans la seconde section, l'utilisation d'UML et SysML semble être la meilleure approche pour définir une méthode s'interfacant au mieux avec les problématiques de conception. De plus, ces langages possèdent les caractéristiques requises pour être analysés par une AMDEC, que nous avons énoncées dans le paragraphe 4.2.1. La première solution de constitution automatique d'AMDEC que nous avons réalisée exploite principalement les diagrammes de séquences, que l'on retrouve de façon identique dans les deux spécifications de l'OMG. Traditionnellement les AMDEC sont construites à partir des informations issues des analyses fonctionnelles. Dans une analyse fonctionnelle on isole différents éléments, on recherche notamment les différentes phases de vie du système. Celles-ci se retrouvent dans les diagrammes de séquences, car ces derniers décrivent les cas d'utilisation dans toutes les phases de vie. On recherche également les éléments extérieurs et leurs relations avec le système. Ces éléments extérieurs seront identifiés dans les diagrammes de séquences via les « acteurs ». Enfin l'analyse fonctionnelle permet d'identifier toutes les fonctions du système, or ce sont ces fonctions qui sont décrites par chaque cas d'utilisation, que représentent les diagrammes de séquences. Dans la première version de l'algorithme de création d'AMDEC, on ne fait pas encore appel à la BdD des comportements dysfonctionnels. Cet algorithme permet de garantir l'exhaustivité de la recherche de composants et de défaillances. Le résultat de l'algorithme est un tableau AMDEC dans lequel figurent tous les systèmes à étudier et tous les modes de défaillances à envisager pour eux. Ces modes de défaillances sont les quatre modes de défaillance classiques, à savoir : la fonction dégradée, l'absence de fonction, la fonction intempestive et la perte de fonction. De plus, on suggère pour chaque risque (couple composant/mode de défaillance) de ce tableau AMDEC, l'ensemble des composants ou éléments de l'environnement pouvant être cause ou subir les effets de chaque défaillance. Cet algorithme est présenté dans les lignes qui suivent : Entrées de l'algorithme :

• Ensemble des Acteurs nommé A • Ensemble des Objets nommé O. Remarque : A ∩ O = ∅ •
Ensemble des Messages nommé M. Les éléments de M sont des couples (x,y) où x, y ∈ A ∪ O, x est l'émetteur du message et y le récepteur.

• C et E deux ensembles vides (ils recevront respectivement les entités pouvant être cause ou subir les effets de défaillances) • L'ensemble des Modes de défaillance nommé MD. MD = {fonction dégradée, pas de fonction, fonction intempestive, perte de fonction} Sorties de l'algorithme :

• Tableau représentant l'AMDEC Opérateurs :

• + est ici l'opérateur de concaténation à droite • pour m ∈ M, m= ( m [START_REF] Omg | OMG systems modeling language (OMG SysML) V1.0. 1er septembre[END_REF] , m [START_REF] Willard | UML for systems engineering[END_REF] ). Début de l'algorithme : Création d'un tableau dont la première ligne comprend 9 cases indiquant, nom de l'objet ou de l'acteur, mode de défaillance, entités cause, entités affectées, gravité, occurrence, risque, moyens de détection possibles, solutions possibles.

∀ i ∈ A ∪ O et ∀ md ∈ MD ∀ m ∈ M, si m[2] = i, C = C + m[1] ∀ m ∈ M, si m[1] = i, E = E + m[2]
16ème Congrès de Maîtrise des Risques et de Sûreté de Fonctionnement -Avignon 6-10 octobre 2008 communication 2B-2 page 6/6

créer une ligne = {i, md, C, E, ∅, ∅, ∅, ∅, ∅}.

Cette solution a été testée sur des diagrammes issus de [START_REF] Peak | Simulation-based design using SysML Part 1: a parametric primer & Simulation-based design using SysML Part 2: celebrating diversity by example[END_REF]. Des résultats et un retour d'expérience sur son utilisation pour l'étude d'un microprocesseur sont également exposés dans [START_REF] Belhadaoui | Outil d'aide a la conception des systèmes mécatroniques sûrs de fonctionnement[END_REF]. Dans cet article les auteurs précisent que l'emploi de ce premier algorithme leur a permis de retrouver toutes les informations qui figuraient dans une première AMDEC faite entièrement manuellement. De plus, outre le gain de temps observé lors de la création de l'AMDEC, les suggestions apportées par la partie créée automatiquement leur a permis d'identifier des risques qui n'avaient pas été perçus lors de la première analyse. Malgré les avantages cités précédemment, cette version souffre du problème de l'explosion combinatoire du nombre de lignes du tableau fournit en sortie. De plus, les solutions proposées restent très généralistes dans l'étude du système. C'est pourquoi, nous avons décidé d'apporter une modification en réalisant une connexion de l'algorithme à une BdD. Ce travail nous permet d'obtenir une AMDEC à la fois plus précise et concise. La connexion avec la BdD intervient à l'étape de recensement des modes de défaillances envisagés pour le composant. En réalisant une reconnaissance de la typologie des types des composants, on peut automatiquement rechercher dans la base de données les modes de défaillances particuliers applicables aux composants étudiés. La partie suivante expose l'utilisation de la classification d'éléments UML et SysML pour la réalisation de la BdD.

  Déduction du comportement dysfonctionnel par analyse du modèle du concepteur • Construction du modèle dysfonctionnel • Analyse qualitative et quantitative du modèle obtenu. Chacune de ces étapes nécessite des méthodes ou modèles différents. Notre rôle est donc d'optimiser les liens qui existent entre ces différentes activités et modèles. C'est pourquoi, nous développons actuellement des outils pour conduire automatiquement des analyses SdF à partir de modèles créés par les concepteurs en UML ou SysML. Le but de chaque étape est d'apporter de nouvelles connaissances sur le comportement du système ou de préparer automatiquement des modèles pour les outils d'analyses existant. La figure 1 représente un exemple possible d'enchaînement des étapes de la méthode.

Figure 1 .

 1 Figure 1. Du modèle fonctionnel aux indicateurs de SdF

  à partir des informations recueillies dans l'AMDEC. Nous envisageons l'utilisation de ce formalisme pour sa structure organisée autour d'états gérant les flux du système, avec laquelle il est facile de représenter le comportement dysfonctionnel que va prendre un composant. Pour chaque composant identifié dans l'AMDEC il est possible d'exprimer ses états fonctionnels et dysfonctionnels ainsi que le traitement des flux reçus et émis (flux d'énergie, de commandes, de contrôle) dans ces états donnés. Le modèle obtenu permet de mettre en évidence la propagation des flux et donc potentiellement des erreurs portées par ces derniers. Ce modèle a ensuite l'avantage d'être aisément transposable vers des modèles bénéficiant de plate-formes outillées tels que les modèles en AltaRica et les RDPSG. En effet, dans ces deux formalismes on peut retrouver ou adopter une représentation état/flux mettant en avant la transmission des informations et de l'énergie à travers le système. Cette partie de la méthode est encore à développer. La dernière étape de la démarche consiste simplement à utiliser les outils existants pour réaliser l'analyse des modèles obtenus. On peut citer pour l'emploi d'AltaRica le logiciel OCAS module de Cecilia Workshop, pour les RDPSG, Jagrif équipé de Moca RP et pour Figaro le logiciel KB3. Il est possible alors d'obtenir des indicateurs SdF tels qu'un taux de défaillance global ou un temps moyen entre défaillances. Il est également possible d'obtenir des arbres de défaillances donnant les scénarios de défaillance et permettant également le calcul de taux de défaillance.

4. 1

 1 Etat de l'art sur la gestion automatisée des AMDEC L'AMDEC est une méthode d'analyse qui bénéficie de nos jours d'un important retour sur utilisation. Les nombreuses années de pratique de cette méthode ont permis à de très nombreux chercheurs et utilisateurs d'identifier les entraves à sa mise en oeuvre efficace. De nombreuses contraintes organisationnelles et opérationnelles éloignent bien souvent les ingénieurs des bénéfices qu'ils souhaitaient tirer de l'étude. L'AMDEC est en effet perçue par la majorité de ses utilisateurs comme une analyse longue à mettre en oeuvre, peu flexible, fastidieuse et souvent très propice aux erreurs. Pour de très nombreuses personnes la réalisation d'AMDEC relève uniquement d'un impératif administratif et contractuel visant à satisfaire la hiérarchie ou le client. Les industriels expriment également leurs difficultés à rendre l'AMDEC opérationnelle, c'est à dire à lier les résultats de l'analyse au déclenchement d'actions correctives et de reprise de la conception. L'AMDEC perd ainsi son pouvoir d'aiguillage dans le processus de conception. La lourdeur de la méthode semble avoir plusieurs origines, ce sont d'une part les difficultés à réunir régulièrement les personnes compétentes pour la réalisation et d'autre par le fort volume d'information à produire, présen-16ème Congrès de Maîtrise des Risques et de Sûreté de Fonctionnement -Avignon 6-10 octobre 2008 communication 2B-2 page 4/4

  détecter les risques et comportements dysfonctionnels, avec comme unique connaissance le comportement fonctionnel du système. Ces langages qu'ils 16ème Congrès de Maîtrise des Risques et de Sûreté de Fonctionnement -Avignon 6-10 octobre 2008 communication 2B-2 page 5/5 soient naturels ou techniques ont en commun la représentation des composants et leur influence les uns sur les autres jusqu'à l'obtention d'une fonction finale. Ainsi un modèle est utilisable selon nous pour la création d'AMDEC s'il permet d'isoler l'architecture du système (agencement entre composants et sous systèmes), ainsi que les flux d'énergie et d'informations entre les composants. Il est en effet utile dans le but de réaliser une étude déductive, cherchant par définition à déterminer un état final en fonction d'une situation donnée, d'utiliser une représentation permettant d'isoler facilement la propagation des flux trahissant la réalisation des fonctions. Pour nous, les caractéristiques minimales du langage de modélisation fonctionnel doivent donc être les suivantes : • représentation architecturale • représentation hiérarchique • représentation comportementale. Ces aspects nous pouvons les retrouver dans le langage UML/SysML, dont les diagrammes permettent une représentation claire des architectures et composition des systèmes par les diagrammes d'objet et de déploiement. UML/SysML met à disposition une vue des flux transmis au travers du système en identifiant via les messages des diagrammes de séquences toutes les interactions existantes entre les objets.

4. 3 . 2

 32 Organisation et exploitation d'une base de données des comportements dysfonctionnels pour la synthèse d'AMDECComme il a été indiqué en 4.2 l'utilisation d'une BdD des comportements dysfonctionnels est cruciale, car elle permet d'impliquer le retour d'expérience dans l'identification des risques. On assure ainsi une cohérence entre les différentes études et on obtient automatiquement des résultats beaucoup plus précis. La BdD contient les modes de défaillance connus pour les composants que nous utilisons. L'algorithme indique donc les défaillances connues dans la base, mais propose néanmoins les modes classiques si un composant n'est pas connu. Une fois l'AMDEC reprise par un opérateur, on pourra réintégrer dans la BdD les modes de défaillance identifiés manuellement. De même il est important de maintenir à jour la base en la modifiant si de nouveaux modes de défaillance sont identifiés en reprenant les AMDEC passées. Nous avons conçu notre base de données en nous appuyant sur le concept de classes présent en UML et extensible à SysML par les diagrammes de définition de blocs. Ce concept nous permet de travailler à de très nombreux niveaux de détail dans la définition du système. En effet, il est possible de représenter les composants avec des relations de hiérarchie au sens généralisation. Cette hiérarchie peut également être définie entre les modes de défaillance, du plus large (modes de défaillance des composants électriques) au plus précis (modes de défaillance d'un condensateur céramique de marque donnée). La figure 2 illustre l'exploitation de la base de donnée pour la création d'AMDEC.

Figure 2 .

 2 Figure 2. Utilisation de la BdD pour la création d'AMDECLa base de données est construite par l'intermédiaire de diagrammes de définition de blocs (bdd : Block Definition Diagram). Elle est structurée autour des composants physiques. C'est à dire que les relations hiérarchiques concernent les composants eux-mêmes, on crée ainsi une arborescence de la définition la plus générale (ex : composant électronique) vers plus de spécialisation (ex : résistance). Pour chaque élément de cet arbre, on fixe dans leurs attributs les modes de défaillance auxquels ils sont sujets. Leur nom peut ainsi être récupéré pour construire la colonne modes de défaillance de l'AMDEC. Cette technique nous permet de gagner beaucoup de temps dans l'établissement des AMDEC. On peut ainsi créer une majeure partie de l'AMDEC de façon précise tout en assurant l'exhaustivité dans la prise en compte des composants. Les figures 3,4 et 5 présentent un exemple type d'utilisation de cet algorithme sur un système anti-débordement (SAD) de cuve. L'AMDEC résultante est automatiquement partiellement remplie, on y retrouve les modes de défaillance précis de chaque composant ainsi que des suggestions sur le déroulement de la défaillance (causes, effets). Le système que nous considérons est décrit sur le bdd de la figure3. Il est principalement constitué d'un système de contrôle du volume de la cuve. Ce système est le sujet de l'étude réalisée. Il est constitué de 2 capteurs de niveau, d'une alarme, de 2 électrovannes, 2 vannes manuelles et d'un système d'alimentation électrique. Le comportement du système de contrôle a été décrit au travers de différents diagrammes de séquences. Ces diagrammes nous permettent d'utiliser notre technique pour la génération automatique d'AMDEC partielle. La figure4présente un de ces diagrammes de séquences. Le scénario décrit tous les mécanismes mis en place pour éviter le débordement de la cuve. En cas d'accident tout ou partie de ce scénario se déroule jusqu'à un retour en état sûr de l'installation. Nous avons ensuite utilisé les algorithmes précédemment décrit, ainsi qu'une BdD décrivant les caractères dysfonctionnels connus pour des composants classiques tels que les vannes manuelles et les électrovannes. Nous avons ainsi créé automatiquement une partie importante de l'AMDEC du système de contrôle. La figure5présente un extrait de ce que nous générons de façon systématique. Il s'agit de la partie concernant l'étude de l'électrovanne va. Cette étude nous a permis de mettre en évidence l'efficacité de la méthode développée. En effet nous avons constaté que nous retrouvions les même avantages qu'avec la première version de l'algorithme et que nous fournissions des informations beaucoup plus riches sur le système. L'utilisation de SysML pour la modélisation de ce système nous permet également de mettre en évidence certaines voies d'amélioration de notre méthode. En effet nous nous apercevons que l'utilisation d'informations complémentaires présentes dans les modèles SysML, va nous permettre d'aller encore plus loin dans la mise en évidence des points faibles et risques liés au système. En SysML les IBD (Internal Block Diagram) décrivent la structure interne des composants en termes de connections entre leurs propriétés ou entre les ports de leurs sous-composants. Ces diagrammes vont nous permettre d'analyser plus précisément les causes et effets des Modes de Défaillance. En effet si nous considérons l'IBD du système de contrôle de la figure6, nous pouvons compléter l'AMDEC de la figure5en ajoutant dans la liste des composants causes de défaillances l'alimentation électrique ae qui fournit le courant à va. L'utilisation des IBD nous semble indispensable pour poursuivre cette démarche de création d'AMDEC. En effet il apparaît qu'il n'est pas suffisant de se cantonner à la description comportementale inter composant du système pour mettre en évidence toutes les facettes du comportement dysfonctionnel. L'étude de la structure et plus particulièrement des points d'échanges de flux, d'énergie et de données est primordiale pour évaluer dans leur globalité les risques qui pèsent sur le système. Les IBD vous donc nous permettre de franchir ce pas dans l'analyse des systèmes. En effet l'étude des entités liées par les flow ports ainsi que la définition du flux passant par ces ports va nous permettre de relever de nouveaux éléments comme les problèmes d'alimentation énergétique ou le passage de fluides. Ces données très importantes ne sont pas représentées au sein des diagrammes de séquences, plus à même de représenter la partie commande des systèmes. La spécification de SysML offre la possibilité au concepteur de préciser la nature du flux circulant par les ports des composants.

Figure 3 .

 3 Figure 3. Block Definition Diagram du SAD

Figure 4 .Figure 5 . 8 figure 6 .

 4586 Figure 4. Diagramme de séquence du fonctionnement du système de contrôle

•

  Constituer une équipe réunissant spécialistes et utilisateurs du système analyser • Formation des participants à la méthode • Régularité des rencontres •Obtenir l'adhésion du management et des équipes opérationnelles en faisant valoir leur intérêt dans la méthode. De plus, l'intégration de l'AMDEC ne peut se faire sans un support logiciel adapté. Dans ce sens de nombreux chercheurs se sont penchés sur l'aide que pouvait apporter l'outil informatique à la création d'AMDEC. L'utilisation de logiciel peut être variée dans le cas de l'AMDEC :

• Maintien de la base de données [12] • Aide à la saisie du tableau • Synthèse automatique de parties du tableau [13], [14] • Réorganisation et mise en évidence des éléments importants [15] • Aide à l'utilisation et à la création de typologies [11], [12] •

16ème Congrès de Maîtrise des Risques et de Sûreté de Fonctionnement -Avignon 6-10 octobre 2008 communication 2B-2 page 3/3

Remerciements

Nous tenons à remercier les partenaires du projet Capthom. Ce travail a été réalisé avec le soutien financier de la Région Centre et du Ministère de l'Industrie dans le cadre du projet Capthom du pole S 2 E 2 , www.s2e2.fr.