Institut National Polytechnique de Lorraine

Ecole doctorale IAEM Lorraine Dpartement de Formation Doctorale en Automatique

THSEprsente et soutenue publiquement le 13 Janvier 2011 pour lobtention du

Doctorat de lInstitut National Polytechnique de Lorrainespcialit Automatique, Traitement du signal et Gnie Informatique

tel-00601086, version 1 - 16 Jun 2011

Conception sre des systmes mcatroniques intelligents pour des applications critiquesPar HICHAM BELHADAOUIComposition du jury Prsident : Rapporteurs : Examinateurs : Pr. Jos RAGOT (CRAN, INPL) HDR Dr. Zineb SIMEU-ABAZI (G-SCOP, INPG) Pr. Frdric KRATZ (PRISME, ENSI de Bourges) Pr. Luc HEBRARD (InESS, UdS) Pr. Jean-Franois AUBRY (CRAN, INPL), Directeur de thse Dr. Olaf MALASSE (A3SI, Arts et Mtiers ParisTech, Metz) , co-Directeur HDR Dr. Nicolas HERAUD (SPE, Universit de Corse) Jean-Claude BOEHM (CETIM) Dr. Karim HAMIDI (IRSN)Centre de Recherche en Automatique de Nancy UMR 7039 - Nancy Universit - CNRS 2, Avenue de la Fort de Haye 54516 Vanduvre-ls-Nancy Tel. +33 (0) 83 59 59 59 - Fax +33 (0) 3 83 59 56 44

Invits :

Remerciements

RemerciementsCes travaux ont t effectus au sein de lquipe A3SI (dirige par Mr Olaf MALASSE) du centre Arts et Mtiers ParisTech de Metz qui a cofinance ce travail, et lquipe Architecture des Systmes de lENSEM de Casablanca. Cette thse a t dirige par le Professeur Jean-Franois AUBRY, mon codirecteur de thse franais, qui je tiens exprimer ma reconnaissance et mes profonds remerciements pour son encadrement, pour sa disponibilit pendant nos runions lINPL, ou dans les diverses runions avec les membres du projet de la fondation CETIM. Durant la priode de ma thse, jai assist toutes les runions effectues au sein de lquipe SACSS (Systmes Automatiss Contraints par la Sret de Fonctionnement et la Scurit) dirige par le Professeur Aubry, et qui fait partie du groupe thmatique SURFDIAG (Sret de Fonctionnement et Diagnostic des systmes) du Centre de Recherche en Automatique de Nancy (CRAN). Merci monsieur le professeur pour vos efforts et lintrt que vous avez apport mon travail.

tel-00601086, version 1 - 16 Jun 2011

Je tiens tmoigner toute ma gratitude et ma sincre reconnaissance Mr Olaf MALASSE Directeur de centre de comptence A3SI, de mavoir offert lopportunit dun PFE et loccasion de poursuivre par une thse, ainsi que pour lencadrement direct de ce travail. Merci de votre patience, et de votre implication matrielle et morale. Je tiens galement exprimer mes remerciements Mr Grgory BUCHHEIT, ingnieur de recherche au centre A3SI, pour sa coopration et sa participation ce travail. Je remercie le Professeur Jos RAGOT, Professeur denseignement suprieur (CRAN, INPL), pour l'honneur qu'il me fait en prsidant ce Jury de thse. Je tiens remercier galement : Madame Dr.HDR Zineb SIMEU-ABAZI, Monsieur Pr. Frederic KRATZ, Monsieur Pr. Luc HEBRARD, Monsieur Dr. HDR Nicolas HERAUD, Monsieur Dr. Karim HAMIDI-GEORGES, Monsieur Dr. Nicolae BRINZEI, Pour l'honneur qu'ils me font en participant mon Jury de thse, et particulirement Madame Zineb Simeu-Abazi Matre de Confrences Habilit du G-SCOP de lINP de Grenoble, Frdric Kratz Professeur l'ENSI de Bourge qui ont accept d'tre rapporteurs de mes travaux. Merci tous les membres du consortium CETIM pour leur disponibilit, leur bonne humeur et leur ambiance scientifique trs riche pendant les runions. Je veux remercier l'ensemble des

Remerciements permanents pour leurs critiques et conseils, et l'ensemble des doctorants : Mehdi JELLOULI et Benot DUBOIS pour l'ambiance conviviale qu'ils y mettent. Je remercie la Fondation CETIM, Fondation de France pour son soutien ce projet, et par consquent ma formation. Je remercie Monsieur Jean Claude BOEHM le reprsentant de la Fondation CETIM qui nous a accompagns durant toute cette exprience. Il me reste remercier toutes les personnes que jai rencontres durant cette aventure et avec qui jai travaill durant ces trois annes. Enfin, je ddie ce paragraphe tous ceux qui mont aid et support dans cette preuve. Je pense mes amis et ma famille grce qui jai pu en arriver jusque l.

tel-00601086, version 1 - 16 Jun 2011

tous les tres chers dont le soutien ma t indispensable.

Rsum

RsumLa criticit des systmes complexes programmables ncessite de garantir un niveau de fiabilit et de scurit convenable. Des tudes de sret de fonctionnement doivent tre menes tout au long du cycle de dveloppement du systme. Ces tudes permettent une meilleure matrise des risques et de la fiabilit. Les points faibles sont mis en vidence et permettent aux concepteurs de spcifier des stratgies de reconfiguration avant la phase de prototype rel et les tests rels. Les tudes de sret de fonctionnement doivent tre menes au plus tt dans la phase de conception, afin de rduire les cots et le nombre de prototypes ncessaires la validation du systme. Le travail prsent dans ce mmoire de thse a pour objectif de dfinir une mthodologie de conception des systmes complexes programmables ddis une application mcatronique [Belhadaoui et al., 2008-a], intgrant ds les premires phases du cycle de dveloppement [At-Kadi et al., 2000], les aspects sret de fonctionnement. Lapport dune telle mthodologie doit permettre de faire face un certain nombre de contraintes propres au domaine des capteurs intelligents (les exigences de cahier des charges, le respect des normes lgislatives en vigueur). La mthodologie dveloppe doit permettre de : Modliser et simuler les comportements fonctionnels et dysfonctionnels des systmes Estimer la fiabilit par modlisation Raliser des mesures de sensibilit afin de connatre la contribution de chaque composant la fiabilit du systme Capitaliser la connaissance sur le systme au cours des diffrentes phases dvaluation (prvisionnelle, exprimentale et oprationnelle) pour affiner les estimations de fiabilit Ce Travail introduit le concept dinformation en sret de fonctionnement. Nous interprtons la dfaillance de celle-ci comme tant le rsultat de linitiation et de la propagation dinformations errones travers larchitecture dun capteur intelligent ddi une application mcatronique. Cette propagation sest accompagne de contraintes (partage de ressources matrielles et informationnelles, modes dgrads dinformation) qui tendent influencer fortement la crdibilit de cette information. Nous dbutons sur un tat de lart pour montrer lintrt de lapproche flux informationnel sur un cas dtude complexe. Ceci est li la prsence dune partie programmable (interaction matriel-logiciel) et videment du systme hybride (signaux mixtes analogique-numrique). Cette nouvelle approche distingue, les phnomnes dapparition et de disparition derreurs (matrielles, logicielles et environnementales), ainsi que les squences de propagation aboutissant un mode de dysfonctionnement du systme. Grce cette distinction nous expliquons les concepts mal traits par les mthodes conventionnelles, tels que la dfaillance simultane, la dfaillance de cause commune et abordons dune manire raliste les problmatiques des interactions matriel-logiciel et celle des signaux mixtes. Les squences de propagation derreurs gnres permettent laide dun modle markovien non homogne, de quantifier dune manire analytique les paramtres de la sret de fonctionnement du systme (fiabilit, disponibilit, scurit) et de positionner le capteur dans un mode de fonctionnement parmi les six que nous avons dfinis suivant les spcifications du cahier des charges.

tel-00601086, version 1 - 16 Jun 2011

Abstract

AbstractThe complexity of critical programmable systems requests the guarantee of high level of reliability and safety. The dependability studies should be conducted throughout the development cycle of the system. These studies provide better risk management and reliability. The weak points are highlighted, and enable designers to specify reconfiguration strategies before the prototype stage and real testing. The dependability studies must be conducted as soon as possible in the design phase, in order to reduce costs and the number of prototypes necessary to validate the system. The work presented in this thesis aims to define a design methodology of complex systems dedicated to a mechatronic programmable application [Belhadaoui et al., 2008-a], integrating as soon as possible dependability aspects in the development cycle [At-Kadi et al., 2000]. The provision of such a methodology must resist face a number of constraints specific to the intelligent sensors field (requirements specifications, compliance with standards legislation). The methodology developed enable to:

tel-00601086, version 1 - 16 Jun 2011

Modeling and simulate the functional and dysfunctional behavior of systems. Estimate the reliability by modelling. Achieve measures sensitivity to deduce the contribution of each component in the reliability of the system. Capitalize the system knowledge during different phases of evaluation (planning, experimental and operational) to refine estimations of reliability. This work introduces the concept of information dependability. It interprets the information failure, as a result of the initiation and propagation of failure information through the architecture. This spread has been accompanied by constraints (sharing hardware resource and information, degraded modes of information), which tend to influence the credibility of this information. We begin on a state of the art to show the interest of the information flow approach in a complex case study. This interest is linked to the presence of programmable part (hardware-software interaction), and obviously to the hybrid character of the system (mixed-signal analog and digital). This new approach distinguishes, the phenomena of appearance and disappearance of errors (hardware, software and environmental), as well as the sequences of propagation resulting to the system failures. With this distinction we explain the concepts badly treated by conventional methods, such as the simultaneous failure, the common cause failure and in a realistic manner convincing the issues of hardware-software interactions, and the mixed signals. The generated errors propagation sequences allows, with using a non-homogeneous Markov model, to quantify an analytical dependability parameters of the system (reliability, availability, security) and to position the sensor in an operating mode among six that have been defined according to the standards specifications.

Table des matires

Table des matiresChapitre 0 : Introduction gnrale ............................................................. .......1 Chapitre 1: Sret de fonctionnement et ingnierie systme1.1 Introduction ................................................................................................................ .............. ..8 1.2. Processus de conception ............................................................................................ .............. 10 1.2.1. Structure dun systme selon lEIA-632 .................................................... .............. 12 1.2.2. Prise en compte de la sret de fonctionnement........................................ .............. 13 1.2.2.1 Notions de base ........................................................................................... .............. 14 1.3. Mthode dvaluation des logiciels et des architectures matrielles ..................... .............. 15 1.3.1 Gnralits sur le processus de conception ................................................. .............. 15 1.3.2. Modlisation et valuation ........................................................................... .............. 17 1.3.3. Mthode de sret du logiciel ...................................................................... .............. 17 1.3.4. Mthode en sret des architectures matrielles ....................................... .............. 21 1.3.5 Sret de fonctionnement des systmes de commande programmable ... .............. 23 1.3.5.1. Validation de la conception dune architecture sre de Fonctionnement ................................................................................ .............. 24 1.3.5.1.1. Vrification formelle ............................................................ .............. 26 1.3.5.1.2. Analyse quantitative de la FMDS dune architecture sre ............. 28 1.3.5.1.3. Intgration des approches ................................................... .............. 29 1.4 Conclusion ................................................................................................................... .............. 30

tel-00601086, version 1 - 16 Jun 2011

Chapitre 2 : Problmatique lie la sret de fonctionnement dun sous-systme mcatronique2.1 Introduction ................................................................................................................ .............. 33 2.2 Systmes microprocesseurs .................................................................................... .............. 36 2.2.1 Une omniprsence mal matrise ....................................................................... .............. 36 2.2.2 Composants intelligents(SMART components)................................................ .............. 38 2.2.3 Typologie derreurs et mcanismes de protection ............................................ .............. 39 2.3 Place de lvaluation dans le processus de conception ............................................ .............. 42 2.4 Evaluation conjointe logiciel/matriel ...................................................................... .............. 43

Table des matires 2.5 Approche flux informationnel ................................................................................... .............. 44 2.5.1 Le modle flux informationnel ........................................................................... .............. 45 2.5.2 Diagramme de Flux Informationnel .................................................................. .............. 45 2.5.3 Automates dtats finis........................................................................................ .............. 46 Rgles de DEC-blocs ...................................................................................... .............. 48 2.5.4 Gnration des listes globales ............................................................................. .............. 49 2.5.5 Evaluation quantitative....................................................................................... .............. 49 2.6 Capteur intelligent - Description du prototype ..51 2.6.1 Partie sensible du capteur ..52 2.6.2 Unit de traitement analogique pour le conditionnement du signal ..52 2.6.3 Unit de traitement numrique... ..53 2.7 Conclusion ................................................................................................................... ..58

tel-00601086, version 1 - 16 Jun 2011

Chapitre 3 : Application de lapproche flux informationnelle lvaluation dun processeur3.1. Introduction ............................................................................................................... .............. 60 3.2. Analyse fiabiliste dun microsystme numrique ................................................... .............. 61 3.2.1 Etude dune instruction simple .................................................................... .............. 62 a - Exemple de linstruction DUP ................................................................. .............. 62 b- Exemple de linstruction STORE ............................................................................ 63 3.2.2 Modle de haut niveau de lapproche flux informationnel appliqu sur linstruction DUP........................................................................................... .............. 64 3.2.3 Gnration des squences Exemple de linstruction DUP ................... .............. 65 a- Exemple de liste de fonctionnement nominale ........................................ .............. 66 b- Exemple dune liste de la combinaison de dfaillance ........................................... 66 c- Mot dune liste sans moyen de contrle Checker .............................. .............. 67 d- Mot dune liste avec moyen de contrle Checker ............................. .............. 67 3.2.4 Gnration des squences Exemple de linstruction STORE .............. .............. 67 a- Exemple de liste de fonctionnement nominale ........................................ .............. 68 b- Exemple dune liste de la combinaison de dfaillance ............................ .............. 68 3.3. Descriptive dvaluation quantitative du jeu dinstructions ................................. .............. 69 3.3.1 Exemple de deux instructions DUP et STORE ........................................... .............. 70 3.4. valuation dune application pour le mcanisme de recouvrement de fautes .... .............. 74 3.4.1 Modlisation des fonctions de sauvegarde .................................................. .............. 75 3.4.2 Modlisation des fonctions de restauration ................................................ .............. 76 3.5 Modlisation dune application logicielle Programme de Tri ........................... .............. 79 3.5.1 Programme sans prise en compte de tolrance........................................... .............. 79 3.5.2 Programme avec prise en compte de stratgie de tolrance...................... .............. 81 3.6 Conclusion ................................................................................................................... .............. 84

Table des matires

Chapitre 4 : Evaluation fiabiliste de larchitecture dun capteur mcatronique4.1 Introduction ................................................................................................................ .............. 89 4.2 Etude fiabiliste de larchitecture dun capteur........................................................ .............. 89 4.2.1 Influences des fautes et critre de performance ......................................... .............. 90 4.2.2 Modes de dfaillance de la partie analogique du capteur.......................... .............. 90 4.2.3 Dfaillance par dpassement ........................................................................ .............. 91 4.2.4 Dfaillance par temps de rponse ................................................................ .............. 92 4.2.5 Dfaillance de prcision ................................................................................ .............. 92 4.3 Etude prliminaire et analyse des modes de dfaillance ......................................... .............. 92 4.3.1 Dtermination des contraintes ..................................................................... .............. 92 4.3.2 Dtermination des taux de dfaillance ........................................................ .............. 93 4.3.2.1 Dtermination des taux de dfaillance ou fiabilit des composants.............. 93 4.3.2.2 Calcul des taux de dfaillance ou de la fiabilit des blocs et de systme ...... 93 4.3.3 Gnralits ..................................................................................................... .............. 94 4.3.4 Sources dinformations disponibles ............................................................. .............. 94 4.3.4.1 Ajustement des taux de dfaillance................................................... .............. 94 4.3.4.2 Exemple de donnes de base extraites du MIL-HDBK-217 ........... .............. 96 4.4. Modlisation selon lapproche flux informationnel ............................................... .............. 96 4.4.1 Sources de dfaillance ................................................................................... .............. 96 4.4.2 Modlisation dune instruction simple ........................................................ .............. 98 4.4.3 Cas dtude : Programme de Tri ................................................................. .............. 103 4.5 Exploitation des rsultats pour lamlioration de la fiabilit ................................. .............. 105 4.5.1 Redondance et vote majoritaire ................................................................... .............. 105 4.6 Conclusion ................................................................................................................... .............. 106

tel-00601086, version 1 - 16 Jun 2011

Conclusions gnrales et perspectives ........................................................ ............ 108 Rfrences bibliographiques ....................................................................... ............ 116

Acronymes ..................................................................................................130Annexe A ....................................................................................................... ............ 142 Annexe B........................................................................................................ ............ 146 Annexe C ....................................................................................................... ............ 151 Annexe D ....................................................................................................... ............ 155

Liste des figures

Table des matires

Chapitre 0Figure 0.1 Elments de comparaison entre lavionique et lautomobile (source P. Koopmann Carnegie Mellon)................................................................................................................ .............. 2 Figure 0.2 Interaction du systme et son environnement ................................................... .............. 3 Figure 0.3 Synergie des technologies pour construire les systmes mcatroniques .......... .............. 4 Figure 0.4 Moyens dintgration de la sret de fonctionnement [Lap 05]. ...................... .............. 5

Chapitre 1Figure 1.1 Intgration des processus de dveloppement matriel et logiciel (USA) ........ .............. 10

tel-00601086, version 1 - 16 Jun 2011

Figure 1.2 Processus de dveloppement dune architecture programmable ..................... .............. 11 Figure 1.3 Evolution des principales normes de lIS [Verri10] ......................................... .............. 12 Figure 1.4 Cycle de dveloppement dapplications Matriel/logiciel................................ .............. 16 Figure 1.5 Mthodes qualitatives et quantitatives de la sret de fonctionnement ............ .............. 22 Figure 1.6 Interactions entre conception et validation des architectures ........................... .............. 30

Chapitre 2Figure 2.1 Architecture gnrale dun systme mcatronique ........................................... .............. 33 Figure 2.2 Processus de reconfiguration dynamique des systmes mcatroniques ........... .............. 34 Figure 2.3 Chane dacquisition sans lment numrisation du signal .............................. .............. 34 Figure 2.4 Chane dacquisition dun capteur muni dun lment intelligent (processeur) .............. 35 Figure 2.5 Infrastructure de technologie dinformation ..................................................... .............. 36 Figure 2.6 Distribution de la mmoire en fonction de la taille du logiciel ........................ .............. 37 Figure 2.7 Vision global dun lment de mesure intelligent.. ............. 42 Figure 2.8 Diffrentes couches dune architecture informatique ....................................... .............. 39 Figure 2.9 Positionnement de lvaluation fiabiliste dans le cycle de conception..42 Figure 2.10 Positionnement modles / traces ..................................................................... .............. 43 Figure 2.11 Positionnement de lvaluation fiabiliste dans le cycle de conception logiciel/matriel ......................................................................................... .............. 44 Figure 2.12 Processus dvaluation .................................................................................... .............. 45 Figure 2.13 Diagramme de flux informationnel pour un arrt durgence .......................... .............. 46

Table des matires Figure 2.14 Modle dun automate dune entit fonctionnelle ........................................ .............. 48 Figure 2.15 Architecture globale de capteur intelligent [mkhida 08] ..51 Figure 2.16 Evolution technologique de llment sensible dun capteur ......................... .............. 52 Figure 2.17 Schma lectronique de la partie analogique du capteur ................................ .............. 53 Figure 2.18 Architecture de processeur pile .................................................................... .............. 55 Figure 2.19 Organigramme dexcution de programme de Tri.......................................... .............. 56 Figure 2.20 Impact du nombre de recouvrement sur le temps dexcution...57 Figure 2.21-a- Surcot protection logicielle scnario 2 ....57 Figure 2.21-b- Surcot protection logicielle scnario 4 ....57

tel-00601086, version 1 - 16 Jun 2011

Chapitre 3Figure 3.1 Chemin de donnes de linstruction DUP........................................................................ 63 Figure 3.2.a. Modle RTL de linstruction STORE -1er front dhorloge ......................................... 63 Figure 3.2.b. Modle RTL de linstruction STORE 2me front dhorloge .................................... 64 Figure 3.3. Modle informationnel de linstruction DUP sans et avec Checker ............................... 64 Figure 3.4 Modle de bas niveau de linstruction DUP .................................................................... 66 Figure 3.5 Modle de bas niveau de linstruction DUP en prsence dun Checker .......................... 67 Figure 3.6 Modle de haut niveau de STORE................................................................................... 68 Figure 3.7 Modle de bas niveau de linstruction STORE................................................................ 68 Figure 3.8 Arbre de mode dfaillance 2 (recherche de disponibilit) ............................................... 71 Figure 3.9 Interface de cration des vnements de base.................................................................. 71 Figure 3.10 Calcul de probabilit dun vnement en cas de deux composants en parallle72 Figure 3.11 : Calcul de probabilit dun vnement en cas de deux composants en srie.72 Figure 3.12 : Interface du logiciel Aralia en choisissant la loi de Weibull72 Figure 3.13 Vue Globale dune application logicielle ...................................................................... 75 Figure 3.14 Organigramme de calcul des probabilits de dfaillance des zones 2 et 3 .................... 77 Figure 3.15 Modle de boucle de programme pour la sauvegarde de DSP selon les trois niveaux ................................................................................................................................. 78 Figure 3.16 Organigramme de lalgorithme du programme de tri de dix variables avec lajout de tolrance aux fautes ........................................................................................................................... 82

Table des matires Figure 3.17 Arbre de dfaillance de programme de Tri en prsence de recouvrement .................... 83 Figure 3.18 Probabilit dtre dans un mode de dfaillance avec et sans prsence de tolrance...... 84

Chapitre 4Figure 4.1: Schma lectronique de la partie analogique du capteur ................................. .............. 97 Figure 4.2: Modle de haut niveau de larchitecture du capteur dans le cas dune instruction ADD.. 99 Figure 4.3: Modle de haut niveau en absence de la partie analogique ............................. .............. 99 Figure 4.4: Modle de bas niveau correspond une instruction assembleur ..................... .............. 101 Figure 4.5: Reprsentation graphique des rsultats du tableau 4.4 .................................... .............. 102 Figure 4.6: Modle hirarchique dune application logiciel .............................................. .............. 103

tel-00601086, version 1 - 16 Jun 2011

Conclusion et annexesFigure C.G.1 Dmarche de la mthode globale propose .................................................. .............. 115 Figure A.C.1 Modle de haut niveau de deux composants ................................................ .............. 155 Figure A.C.2 Modle de bas niveau de la figure A.C.1 ..................................................... .............. 155 Figure A.C.3 Dmarche de lvaluation fiabiliste selon lapproche flux informationnel .. .............. 156 Figure A.C.4 Arbre de cause correspondant la liste Lcorrect ............................................ .............. 157 Figure A.C.5 Arbre de dfaillance correspondant la liste Lincorrect .................................. .............. 157 Figure A.D.1 Taxonomie de la sret de fonctionnement[AVI 04] ..................................... .............. 160 Figure A.D.2 Exemple dun rseau de Petri ....................................................................... .............. 164 Figure A.D.3 Modlisation des tats normaux et de panne dun composant ..................... .............. 168

Liste des tableaux

Table des matires

Chapitre 3Tableau 3.1. Rsultat sans dispositif de dtection .............................................................. .............. 73 Tableau 3.2 Rsultat avec dispositif de dtection et de recouvrement ............................... .............. 73 Tableau 3.3 Probabilits des instructions simples .............................................................. .............. 74 Tableau 3.4 Rsultats des instructions propres aux fonctions de tolrance ....................... .............. 79 Tableau 3.5 Valeurs de probabilits du programme de Tri sans prise en compte de fonctions de recouvrement ............................................................................. .............. 81 Tableau 3.6 Valeurs de probabilits relatives au programme de Tri avec prise en compte de fonctions de recouvrement ....................................................... .............. 83 Tableau 3.7 Rsultats de comparaison de programme de Tri dans le cas de tolrance et sans tolrance ......................................................................... .............. 83

tel-00601086, version 1 - 16 Jun 2011

Chapitre 4Tableau 4.1 : Taux de dfaillance des composants standards ............................................ .............. 94 Tableau 4.2 : Coefficients de correction selon lenvironnement de travail........................ .............. 95 Tableau 4.3 : Mcanismes et leurs modes de dfaillance analogique ................................ .............. 98 Tableau 4.4 : Rsultats relatifs une instruction ADD ...................................................... .............. 102 Tableau 4.5 : Effet de lajout de la partie analogique sur ltude de la fiabilit du capteur.............. 104

AnnexesTableau A.A.1 AMDEC de la partie de traitement analogique ......................................... .............. 146 Tableau A.A.2 AMDEC de la partie logique programmable ............................................. .............. 148 Tableau A.B.1 Bases de donnes de la fiabilit lectronique ............................................ .............. 149 Tableau A.B.2 Rsultats FIDES pour des composants lectroniques ................................ .............. 152

Introduction gnrale

Chapitre 0 : Introduction gnrale

tel-00601086, version 1 - 16 Jun 2011

-1-

Introduction gnrale Le mirage de lre du tout numrique entrane notre socit vers plus dinconscience et dinsouciance envers les systmes intelligents qui sont magnifis des fins mercantiles. La gnralisation du Plug and Play (ajout facilit et transparent de fonctionnalits aux systmes) impacte invitablement la gestion et le traitement des fonctions prcdemment installes: nouvelles interactions ; nouveaux partages des temps La complexit des systmes devient transparente en apparence avec la miniaturisation et linformatisation. Elle existe toujours, mais nest plus aisment apprhendable et visible par lhomme (cela rsulte aussi des outils de CFAO qui permettent de concevoir et de raliser sans parfaite matrise les systmes). Dans une socit mercantile, le Bug est banalis (1 Bug 1 Reset, ou on jette : cest bon pour le commerce !). Le systme industriel a, quant lui, une dure de vie de 4 50 ans !! Et si un Reset est possible sur un systme isol, il existe ici un risque dengagement de la scurit pouvant concerner plusieurs milliers de personnes (plusieurs millions dans le cas du Nuclaire). Lingnierie des systmes complexes, avec ses outils de conception et dveloppement, fait partie des marchs applicatifs reconnus forte valeur ajoute (System@tic, ITEA). Ces systmes (6 Md $ en 2007) embarqus et distribus, haute exigence en sret de fonctionnement, font massivement recours des architectures (circuits et systmes) lectronique programmable, o le logiciel est devenu important. Une demande toujours croissante en performances, des contraintes conomiques plus tendues, une croissance exponentielle de la taille des circuits/systmes et du code grant ces circuits ont pour consquence de rendre la conception, la ralisation et la mise au point de ces systmes de plus en plus dlicate (que penser alors des conditions dun rtrofit ?). Mme les plus grandes socits ne sont plus mme de circonscrire la dure de la phase pr-commerciale et plus grave encore, de commercialiser un circuit/systme exempt derreurs. La vrification fonctionnelle des systmes combinant la fois matriel et logiciel ne seffectue actuellement qu la fin du processus de conception. Cette phase se rvle excessivement coteuse et pnalisante au sein du processus dintgration produit/systme. Les bureaux dingnierie ont tendance dvelopper en premier lieu un modle abstrait du systme, pour ensuite en tester les fonctionnalits, la fiabilit et les performances que des composants bass sur un tel modle seraient mme doffrir. Lenjeu conomique est dimportance [Bergeron et al., 2010], la validation peut reprsenter jusqu 70% de leffort de conception, 80% des lignes de code dun projet, et il existe plus dingnieurs de vrification que de concepteurs.Automobiles (USA) Units dployes Heures oprationnelles / an Cot par vhicule Mortalit / an Accidents / an Mortalit / million dheures Qualification des oprateurs Niveau de redondance 100 000 000 30 000 millions 20 000 $ 42 000 21 millions 0,71 Faible Uniquement sur les freins Avions commerciaux (USA) 10 000 55 millions 65 millions $ 350 170 6,4 leve Tout systme critique

tel-00601086, version 1 - 16 Jun 2011

Figure 0.1 : Elments de comparaison entre lavionique et lautomobile (source P. Koopmann Carnegie Mellon)

-2-

Introduction gnrale Lingnierie de la sret ne peut se satisfaire da priori, aussi crdibles et partags soientils ! Le risque associ aux transports de masse reste trs suprieur celui du transport individuel (Figure 0.1). Les prcautions et investissements ddis la sret et la scurit dans la conception et lexploitation des aronefs sont parfaitement justifis au regard de la mortalit compare au nombre dheures de fonctionnement. La massification des transports, en ltat actuel des techniques et organisations industrielles, reprsente un risque important mal apprhend par les gestionnaires et la technocratie. Les ingnieries de llectronique numrique et du logiciel occupent donc une place prpondrante dans le processus de conception et de vrification des systmes informatiss. Les niveaux dintgration des composants lectroniques, de complexit et de taille du code embarqu croissent continuellement et cette croissance saccompagne dune plus grande sensibilit aux perturbations (les environnements naturel et technologique devenant eux aussi plus agressifs) et aux autres attaques (exigence forte quant la capacit des systmes communiquer). Un systme est un ensemble complexe de fonctions, soumis des alas (dclenchement derreurs systmatiques, bit flips, dfaillances matrielles), devant rendre un service dfini, quelque soient son tat interne, ltat de son environnement et le niveau de stress appliqu (Figure 0.2).Situationcriticit de la raction

tel-00601086, version 1 - 16 Jun 2011

conceptionRobustesse, err. rsiduelles

Systme SEDmode de fonctionnement

impacts environnementCEM, accidents, pollutions

environnementnormal-dgrad-extrme stress exognes

sretFMDS, risque, perf. conomiques

profil de missionstress oprationnel

interface

tat internevariables dynamiques

interface qualit de serviceperformances dynamiques

org. oprationnellemaintenance

autres entresinteractions autres syst.

SD Systme de dfense

interactions autres systmespropagation de fautes

stress intrinsques

Fautessystmatiques-alatoires

prvention-protection-sauvegarde

Figure 0.2: Interaction du systme et son environnement. Tous les systmes mcatroniques (Figure 0.3) sont complexes. Le nombre des combinaisons possibles des tats des parties pose un problme dexplosion combinatoire qui conduit des nombres gigantesques dtats possibles. Cette complexit est un dfi pour la sret de fonctionnement. Pour laugmenter on a souvent recours la redondance, dploiement d'une multitude de versions diffrentes d'un mme schma ou motif (pattern) qui participe ellemme laugmentation de la complexit. On parle de redondance fonctionnelle (exemple : la reprise en mode dgrad ou de secours dune fonction) ou de redondance structurelle qui dsigne des structures diffrentes pour excuter une mme fonction (comme le double circuit

-3-

Introduction gnrale de freinage d'une voiture automobile ou plusieurs ateliers diffrents ou usines diffrentes pour fabriquer une mme pice ou un mme engin).

Figure 0.3 : Synergie des technologies pour construire les systmes mcatroniques.

tel-00601086, version 1 - 16 Jun 2011

La structure fonctionnelle des systmes (ensemble logiciel et matriel) est de facto devenue complexe et variable. Prvenir et liminer les fautes font partie des attendus des processus de dveloppement et de vrification. Les fautes issues derreurs rsiduelles la conception, ou ralisation des composants lectroniques, ou du logiciel, sont certes localisables, identifiables et reproductibles, mais difficilement dtectables ! Les causes potentielles de dfaillance se rvlent multiples : matrielles, logicielles, environnements de dveloppementLa non cohrence, les combinaisons derreurs potentiellement latentes et dormantes dpendant de ltat du systme et la complexit des applications rendent lanalyse difficile. Les types de dfaillance [Aiguo L. et Bingrong H., 2007] peuvent galement se combiner : dfaillance dexcution (non progression, boucle infinie, plantage), fonctionnelle (mauvais traitement), oprationnelle (dlai de traitement non respect, indisponibilit). Le traitement (dtection et recouvrement) des erreurs apporte, au prix dune augmentation des niveaux de complication et de complexit du systme, la garantie dune meilleure probabilit de comportement satisfaisant du systme. Lintgration de mcanismes (matriels et logiciels) de tolrance aux fautes intrinsques par conception, par la commande ou par diagnostic et reconfiguration, modifient sensiblement larchitecture matrielle et logicielle (firmware, application) et impactent la dynamique et la FMDS (fiabilit, maintenabilit, disponibilit et scurit) des systmes. Les aspects fonctionnels et dysfonctionnels doivent tre pris en considration pour lvaluation des performances (en terme fiabiliste et de qualit de service) dun systme. De nombreux rfrentiels encadrent le dveloppement des systmes contraints par des impratifs de sret et de scurit, tel la norme gnrique CEI 61508 [CEI 61058] dcrivant le processus de dveloppement des systmes E/E/EP ddis aux applications relatives la scurit des systmes industriels. La sret de fonctionnement dun systme peut-tre dfinie comme laptitude d'une entit assumer une ou plusieurs fonctions requises dans des conditions donnes [CEI 50191], dont la variation sur occurrence dvnement(s) peut induire une dfaillance du systme. Les dpendances (relles ou potentielles, dans leur acception explicite ou implicite) entre parties dun systme, induisent des interactions entre elles, rendant difficile la compltude des spcifications du systme. Cette complexit, intrinsque lingnierie systmes, la confronte de fait aux problmatiques des interactions multi-physiques et inter-disciplinaires. La

-4-

Introduction gnrale mcatronique, combinaison synergique et systmique de mcanique des solides et des fluides, d'lectronique, et d'informatique temps relprocde de cette complexit (Figure 0.3) Les moyens de garantie de la Sret de Fonctionnement (Dependability) (Figure 0.4) sont gnralement assimils llimination, la prvention et la tolrance aux fautes [Lap 04]. Ltude de ses proprits mle analyse de la Fiabilit (Reliability), de la Maintenabilit (Maintenability), de la Disponibilit (Availability), de la Scurit innocuit (Safety), de la Confidentialit (Security) et de lIntgrit (Intgrity) de linformation. Des attributs secondaires ont galement t dfinis : la Robustesse (persistance dun comportement correct en prsence de fautes), la Rsilience (capacit dadaptation), lAuthenticit, la Survivabilit

tel-00601086, version 1 - 16 Jun 2011

Figure 0.4 : Moyens dintgration de la sret de fonctionnement [Lyonnet P., 2006]. Lvaluation des performances fiabilistes (FMDS) des systmes embarqus complexes ncessite le dveloppement de nouvelles approches. Dans les systmes intgrant du logiciel, la structure fiabiliste des fonctions dpend du logiciel. La recherche des squences dvnements menant la dfaillance du systme doit donc associer logiciel et matriel. La mthode doit contribuer lanalyse qualitative et quantitative de la sret des systmes et microsystmes. Ce rapport de thse est structur pour aborder en dtail chacun de ces volets : Les dfinitions indispensables la comprhension des concepts de base de la sret de fonctionnement sont abordes au dbut du chapitre I. Les mthodes et les outils ncessaires pour entreprendre les analyses prvisionnelles de sret de fonctionnement pour des systmes en cours de conception sont classs selon la mention qualitative et quantitative dans le chapitre I.

-5-

Introduction gnrale Lintgration de la sret de fonctionnement en ingnierie systme et notamment dans la conception des composants dautomatismes intelligents [Seung J.R. et Kosuke I., 2003], [Wen Y.K. 2001] est prsente dans le chapitre II. Nous proposons une architecture de capteur intelligent pour une application mcatronique. Nous dtaillons dans le mme chapitre les problmatiques lies la sret de fonctionnement des capteurs intelligents. Lanalyse fiabiliste pour la conception des systmes intelligents signaux mixtes, et la gnralisation de la mthode du flux informationnel [Hami et al.,2005] dans la partie logique programme du capteur sont des points traits dans le chapitre III. Ltude globale de larchitecture dun capteur intelligent, illustre par une valuation fiabiliste de lexcution dune application logicielle, embarque sur une architecture de processeur pile, est ralise en dtail dans le chapitre IV. La robustesse de ce type de capteur est troitement lie aux techniques de tolrance aux fautes utilises. Nous consacrons la dernire partie du chapitre IV ltude de limpact de ces techniques sur les performances.

tel-00601086, version 1 - 16 Jun 2011

-6-

Chapitre1 : Sret de fonctionnement et ingnierie systmes

Chapitre 1 :Sret de fonctionnement et ingnierie systme

tel-00601086, version 1 - 16 Jun 2011

-7-

Chapitre1 : Sret de fonctionnement et ingnierie systmes

1.1 IntroductionLes systmes numriques de contrle/commande ont conquis quasiment tous les domaines dapplications [Barana et al., 2004] [Khobare et al., 1998], quelque soit leur niveau de criticit. Parmi les caractristiques partages par ces systmes nous citons leur complexit intrinsque croissante (intelligence distribue, redondances, fonctionnalits hirarchises...) et leur interaction avec lenvironnement (contraintes temps rel, applications critiques). Cette complexit croissante rend obsolte les mthodes de conception et dvaluation actuelles. Il est illusoire de matriser compltement la conception et la pratique des systmes complexes. Les mthodes de conceptions ne permettent quune approche partielle et parcellaire des problmes : simplifications des contraintes mal matrises, modles inadquats, compltude du prototypage, outils de conception et technologies limits Il nexiste pas de solution entirement satisfaisante pour la rsolution de ces problmes. Cest la raison pour laquelle nous recherchons amliorer et valider sa conception. Lenjeu actuel est de dfinir un systme, intgrant des interactions internes (matriel/logiciel, fonctionnelles, dysfonctionnelles) et externes (environnements).

tel-00601086, version 1 - 16 Jun 2011

Lors de la conception dun systme, les concepteurs doivent respecter des exigences (les dlais, les cots, la sret de fonctionnement, les performances) exprimes par diffrentes parties : concepteur (chercheurs et ingnieurs), matre duvre (intgrateurs), matres douvrages, exploitants Dans le domaine des systmes programmables, de nombreuses mthodes et outils ont t dvelopps pour faire face la complication et la complexit croissante. Une mthodologie systmique savre ncessaire pour garantir que le systme conue respecte les exigences du cahier des charges. Une recherche bibliographique montre que les principaux dfauts de conception sont dus : des besoins mal spcifis, incomplets ou errons ou des exigences (cahier des charges) mal formules, lvolution des besoins ou des exigences dans le temps, la non accumulation de savoir-faire et le manque de retour dexprience, lvolution technologique, la dfinition errone dinterfaces, la pression de la concurrence, lextension dexigences fonctionnelles. Gnralement, dans la conception des systmes complexes, chaque fonction pouvait tre tudie et dveloppe indpendamment des autres et limplication de la sret de fonctionnement se rsumait la rutilisation de modles gnriques bass sur le retour dexprience. Cette approche conventionnelle ne permet pas la prise en compte des risques lis linteraction entre ces fonctions matriel/logiciel. Il est donc important de formuler les exigences de sret de fonctionnement non seulement localement (pour chaque sous systme), mais globalement (pour le systme entier). Cela revient formuler ces exigences au niveau du systme complet et, ensuite, les dcliner des niveaux plus bas (jusquaux simples composants). Le cycle en V est traditionnellement utilis dans la description du cycle de dveloppement dun systme embarqu. Le cycle est compos de deux branches. La branche descendante, qui -8-

Chapitre1 : Sret de fonctionnement et ingnierie systmes correspond une dmarche de raffinements successifs, dcrit les phases de conception allant de labstrait, qui dmarre avec lexpression des besoins, au particulier. La branche ascendante dtaille les phases dintgration et de validation correspondant chaque phase de conception. La conception dun systme suivant le cycle en V gnre un retarder du au choix de la technologie de ralisation. Dans cette optique, les efforts sont concentrs que sur la spcification et non sur les interactions au moment de lintgration, ce qui entrane le non matrise du comportement rel du systme intgr. Les systmes actuels sont de plus en plus complexes car ils intgrent des fonctionnalits supplmentaires, des technologies varies et doivent tre oprationnels sur des priodes longues. Ces systmes demandent aussi de longues priodes de dveloppement pendant lesquelles les besoins et les technologies voluent. Rsultat les cots et les dlais deviennent rdhibitoires compte tenu dun environnement o la comptitivit mondiale est de rigueur. Pour prendre en considration ces conditions, une discipline a t dfinie, il s'agit de l'Ingnierie Systme (IS).

tel-00601086, version 1 - 16 Jun 2011

La particularit de lIS est de considrer la fois les aspects techniques et les aspects logistiques (financiers, stockage, transport). LIS a t traditionnellement une discipline applique aux systmes physiques ; depuis une dizaine dannes, lIS sapplique dans la conception des systmes complexes. Les domaines concerns sont la tlcommunication, les systmes dinformation, les systmes de transport, les services financiers et autres applications allant du domaine mdical au gnie des procds. Lingnierie systme, science transdisciplinaire par obligation [Angeli A.M., 1996], a t dfinie ds les annes soixante dans le standard Mil-Std-499. Elle doit intgrer des spcialistes de disciplines diffrentes dans un projet commun. Une grande partie des secteurs de lingnierie est concerne (lectronique, automatique, informatique, mcanique). Ces domaines sont concerns par cette discipline agrgative qu'est l'ingnierie systme, et qui a engendr de nouvelles appellations, comme la mcatronique (1) Elle propose un processus structur de la conception dun systme. Elle a pour objectif de formaliser et d'apprhender la conception des systmes complexes. Les premiers organismes s'y intresser ont donc t les grandes institutions de la dfense amricaine (NASA, USAF), afin de cadrer le dveloppement de leurs programmes au travers d'approches industrielles plus rationnelles. Ils ont donn une dfinition assez ambitieuse lingnierie systme : Systems engineering is a robust approach to the design, creation, and operation of systems. In simple terms, the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets (or met) the goals.

Mcatronique : nologisme form en 1969 par un ingnieur de Yasukawa, ce terme dsigne une dmarche qui regroupe les savoir-faire mcanique, lectronique et informatique pour concevoir des produits plus performants, plus compacts et moins onreux.

(1)

-9-

Chapitre1 : Sret de fonctionnement et ingnierie systmes Si lingnierie des systmes matriels et celle des logiciels ont volu en toute indpendance, les normes et directives rcentes mettent l'accent sur la ncessit d'intgrer ces deux processus [Al-Dhaher A. H. G., 2001] (figure 1.1).

tel-00601086, version 1 - 16 Jun 2011

Figure 1.1 : Intgration des processus de dveloppement matriel et logiciel (USA) Lacclration des dveloppements technologiques, ces dernires annes, sest traduit par laugmentation du nombre des composants lmentaires dans les systmes. Un systme complexe est un systme compos d'un grand nombre d'entits en interaction locale et simultane. Il n'existe pas de dfinition formelle de ce qu'est un systme complexe, mis part un seul consensus qui stablit autour de certaines proprits comme la complexit des interactions, boucles de rtroaction, et intgration de sous-systmes. Un systme complexe est un systme structur. Sa structure subit une variation selon lapplication [Goldenfeld et al., 2006], dans laquelle le nombre de composants indpendants en interaction est grand. Il existe de multiples voies par lesquelles le systme peut voluer [Whitesides et al., 2007], elles sont trs sensibles aux conditions initiales ou aux petites perturbations. Lingnierie systme intgre le dveloppement et l'organisation des systmes complexes.

1.2. Processus de conceptionLes systmes complexes requirent une grande rigueur, lors de leur conception, dans les choix des architectures et lintgration de leurs composants. Do la ncessit dactivits dingnierie complmentaires telles l'ingnierie du contrle/commande, de la conception d'interface (extensibilit des systmes), lingnierie de la performance, le gnie logiciel (SysML, CMMI, mthodes orientes objet, ingnierie des exigences, langage formels), lingnierie de la fiabilit (s'applique tous les aspects du systme, lment essentiel de l'ingnierie de la scurit, s'appuie trs largement sur les statistiques, la thorie des probabilits), lingnierie de la scurit (identification, minimisation des risques essentiels - 10 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes la scurit), lingnierie de la sret (domaine interdisciplinaire qui intgre lingnierie du contrle/commande, de la fiabilit, de la scurit et des systmes), lingnierie de la maintenance (maintien oprationnel des fonctions).

tel-00601086, version 1 - 16 Jun 2011

Figure 1.2 : Processus de dveloppement dune architecture programmable Le processus de dveloppement au sens de la MIL-STD-499A (Figure 1.2) est constitu de : Transformation dun besoin oprationnel en termes de performances, la configuration dun systme est le fruit d'un processus itratif allant de sa dfinition aux essais et son valuation, via les phases de synthse, danalyse et de conception. Intgration des paramtres techniques permettant dassurer la compatibilit physique, fonctionnelle, et informatique optimisante.

- 11 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Intgration de la fiabilit, la maintenance, la scurit, et tout facteur influenant les cots de possession financier et techniques du systme. Lors de la conception dun systme complexe incluant de nouvelles technologies, afin de mener dans les meilleures conditions le projet, les concepteurs utilisent des normes qui les aident accomplir leur mission durant le dveloppement. Parmi ces normes, on peut citer la norme EIA-632 [STA-EIA], ISO 15288 et IEEE 1220.

tel-00601086, version 1 - 16 Jun 2011

Figure 1.3 : Evolution des principales normes de lIS [Verri10].

1.2.1. Structure dun systme selon lEIA-632La norme EIA-632 est lune des normes les plus utilises dans le domaine de lIngnierie Systme [Sadou et al., 2005]. Une telle norme a t dploye principalement dans des industries de laronautique, de production et militaires. Cette norme complte les processus techniques de dfinition du systme en couvrant la ralisation des produits jusqu leur mise en service (mise en utilisation). De plus, elle inclut les processus contractuels dacquisition et de fourniture. Un processus est un ensemble dactivits interactives [AFIS] coordonnes pour transformer progressivement des lments d'entre en produits. Un processus normalis dcrit les types dactivits raliser et de rsultats attendus de ces activits. Ces processus doivent rpondre un certain nombre d'exigences selon des normes [EIA 1999]. La norme EIA-632 dfinit 13 processus de dveloppement : 3 processus de Management Technique 2 processus d'Acquisition et de Fourniture 2 processus de Conception 2 processus de Ralisation 4 processus d'Evaluation Technique

Ces processus sont utiliss chaque niveau de hirarchisation des produits finaux, pour chaque module, pour les spcifier, les modliser et, bien sr, pour les dvelopper.

- 12 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Selon les informations recueillies sur lchec de projets industriels [Sahraoui A.E.K.,2006], gnralement la cause de lchec du projet est la ngligence des produits qui contribuent la conception du systme en question. En effet, la plupart des partenaires se focalisent uniquement sur le dveloppement des produits finaux (End products). La norme EIA-632, introduit le concept de produit capacitant (enabling product). Il sagit des tapes qui permettent dobtenir un produit final et peuvent tre utiliss par plusieurs produits finaux. Le dveloppement du systme selon la norme industrielle (EIA-632) consiste dcomposer le systme entre produits finaux et tapes suivre et dexplorer un ensemble de processus qui sera appliqu pour le dveloppement des produits finaux. L'infrastructure pour le dveloppement se base sur les problmes de la logistique, qui sont considrs comme des produits capacitants dans le cadre de lEIA-632. Ces produits capacitants seront utiliss pour excuter lensemble des processus associs au dveloppement, la production, au dploiement, et la formation des oprateurs afin dutiliser les produits finaux.

tel-00601086, version 1 - 16 Jun 2011

Gnralement il y a sept types de produits capacitants (tapes suivre) contribuant la production dun produit final : la phase de dveloppement, la production, le test, le dploiement, la formation des oprateurs pour savoir utiliser le produit, le support du produit, et la retraite du produit (recyclage). Le dveloppement dun systme (produit dsir) est dcompos en une hirarchie de soussystmes dfinis en tant que modules. Le dveloppement dun module de niveau infrieur est lanc ds que le module de niveau suprieur est compltement spcifi. A partir de l, le module est considr comme un produit qui a des caractristiques et des exigences identifies et fait l'objet d'un dveloppement de mme type que le systme dsir. La dcomposition se poursuit jusqu lidentification de trois catgories de produits finaux : Produits finaux sur tagre, Produits finaux pouvant tre implments directement, Produits finaux pouvant tre fournis par un sous-traitant.

1.2.2. Prise en compte de la sret de fonctionnement (SdF)Dans plusieurs cas dtude les attributs de la SdF sont pris en compte une chelle composant/quipement, ou plus gnralement pour chaque sous-systme homogne (mcanique, lectronique...) dune manire ascendante. Beaucoup dautres pistes sont ouvertes dans la dmarche systmatique de type descendante. Dans lapproche systme [Sadou et al., 2005], la prise en compte de la sret de fonctionnement doit tre faite toutes les tapes de conception. Si on considre, une exigence de fiabilit dfinie globalement sur le systme, sa formalisation et son analyse devront permettre de sassurer que les solutions techniques choisies au fur et mesure de lavancement de la conception et de la ralisation permettent de prendre en compte correctement cette exigence au niveau des sous systmes et de leur intgration. Le processus de vrification et de validation doit apporter les techniques et les solutions pour garantir le degr de fiabilit spcifie. Les diffrentes mthodes et outils de lanalyse de la sret de fonctionnement sont ainsi dterminants dans le choix des solutions techniques envisager. La - 13 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes conception dun systme en prsence dune exigence de fiabilit donne, ncessite ltude des dfaillances possibles ; cest une tude sur les scnarios redouts qui permet dorienter la recherche des solutions techniques (reconfiguration, redondance, rduction des taux de dfaillances), autrement dit cest le respect de lexigence en sret tout au long de la dmarche Ingnierie Systme. 1.2.2.1 Notions de base Les notions de sret de fonctionnement des systmes (ensemble de matriel et de logiciel) se basent sur la dfinition suivante la Sret de Fonctionnement dun Systme (SdF) est la proprit qui permet ses utilisateurs de placer une confiance justifie dans le service quil leur dlivre [Laprie J.C.,1995]. Nous pouvons tirer un ensemble de dfinition de ses attributs dans le sens large: Etre en mesure de raliser instantanment une fonction, cest la Disponibilit. Capable dassurer la fonction trop longue temps, cest la Fiabilit. Non-occurrence de consquences catastrophiques, cest la Scurit-innocuit. Non-occurrence de divulgations non-autorises de linformation, cest la Confidentialit . Non-occurrence daltrations inappropries du systme, cest lintgrit . Aptitude aux oprations et aux volutions, cest la Maintenabilit. Dans la terminologie de la sret de fonctionnement, nous distinguons entre faute, erreur et dfaillance [Laprie J.C.,2004], gnralement selon la succession suivante : Faute Erreur dfaillance Faute est une cause adjuge ou suppose dune erreur. Erreur est la partie de ltat du systme qui est susceptible dentraner une dfaillance. Dfaillance survient lorsque le service offert par le systme ne correspond pas la fonction qui lui en est demande. Dans la pratique, les fautes et leurs sources sont naturellement diverses. Nous pouvons les partager selon plusieurs points de vue : Cause phnomnologique (fautes physiques ou fautes dues lhomme). Nature (fautes accidentelles, fautes intentionnelles avec ou sans volont de nuire). Phase de cration ou doccurrence (fautes de dveloppement, fautes oprationnelles). Situation par rapport lenvironnement du systme (fautes internes, fautes externes). Persistance (fautes permanentes, fautes temporaires). La distinction entre diffrentes classes de fautes permet de penser des contres mesures appropries. Nous pouvons citer quatre catgories dvaluation pour la sret de fonctionnement : Prvention aux fautes : comment empcher l'occurrence ou l'introduction de fautes, cest le choix et la mise en uvre dun ensemble de processus visant matriser la conception, la ralisation et la validation du systme, et assurer le bon fonctionnement du systme durant sa vie oprationnelle.

tel-00601086, version 1 - 16 Jun 2011

- 14 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Tolrance aux fautes : comment fournir un service et remplir la fonction du systme mme en cas de faute. Elle vise quiper le systme de certains mcanismes de traitement derreurs (supprimer les erreurs avant leur propagation) ainsi que le traitement de fautes (viter quune faute ne soit active de nouveau). Elimination des fautes : comment rduire la prsence (nombre, svrit) des fautes. Prvision des fautes : comment estimer la prsence, la cration et les consquences des fautes. La prvision des fautes est conduite en effectuant des valuations du comportement du systme par rapport loccurrence des fautes et leur activation. Les mthodes de tolrance aux fautes, sont implantes tant au niveau matriel, que logiciel, sont destines rendre le systme robuste aux fautes provoques par lenvironnement (radiations, lectromagntisme, dfauts lectriques, perturbation mcanique, vibration). Ces mthodes font partie intgrante de limplmentation, leur fonctionnement est parfois test par lutilisation de techniques formelles. Les mthodes dinjection de fautes sont trs utilises pour la simulation des mcanismes de tolrance qui apportent un durcissement de lapplication. Elles se traduisent en pratique par lajout dinstructions, de vrification, de signature aux diffrents blocs du code. Ces techniques permettent de dtecter les flux de commande errons. Lors dune dtection de faute, selon les mthodes, lexcution du programme est alors arrte, ou dirige vers une routine de correction qui lui permet de reprendre le flux dexcution escompt. Lobjectif de notre travail tant la prvision des fautes, nous distinguerons deux types de prvision : Evaluations ordinales qui consistent identifier, classer et ordonner les dfaillances, et envisager les mthodes et techniques pour viter ces dfaillances (une tude prliminaire de dfaillance). Evaluations probabilistes, sont destines valuer en termes de probabilits le degr de satisfaction de certains attributs de la sret de fonctionnement. Nous classons notre mthode dvaluation quantitative nomme approche flux informationnel [Hami et al.,2005] dans ce deuxime type dvaluation. Les systmes multi-composants tolrants aux fautes et hautement fiables sont trs prsents dans les technologies modernes. Il est important dtre en capacit de dterminer des mesures telles que la fiabilit, le temps moyen datteinte dun tat de dfaillance ou la disponibilit pour ces systmes. Pour cela nous construisons un modle stochastique permettant lanalyse (gnralement par une chane de Markov temps continu). Cependant, lespace dtats savre trop grand de tel sorte quen pratique nous ne pouvons pas esprer de calculer directement les mesures [Chen et al.,2008].

tel-00601086, version 1 - 16 Jun 2011

1.3. Mthode dvaluation des logiciels1.3.1 Gnralits sur le processus de conceptionLes systmes automatiss complexes requirent des mthodes de modlisation et de quantification de mtriques fiabilistes (Fiabilit, Maintenabilit, Disponibilit, Scurit), ou de performance (notamment temps rel), pour leur conception, leur analyse et leur validation. Le dveloppement de ces systmes complexes (matriel/logiciel) robustes repose sur un cycle - 15 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes tabli au cours duquel les concepteurs ont leur disposition de nombreux environnements de dveloppement [Harel et al., 2002], [Sutherland et al., 2003], [Yalamanchili S., 2001], et de vrification [Dabny et al., 2008], [Kopf T., 1999], [Berar B et al., 2001]. Malgr lexistence de tels environnements, la conception matriel/logiciel est actuellement la frontire dune crise importante [Zhan J. et G. Xiong 2006], [ITRS 2004]. Cette crise est directement lie la taille et la complexit des systmes, ce qui a des consquences sur la phase de vrification. Les techniques formelles se heurtent la barrire des explosions combinatoires, tandis que les procdures de simulation ncessitent des temps de calcul trop grands [Wu Y-F.2007], [Kropf T. 1999]. Une partie de la communaut scientifique semble saccorder sur le fait que la solution rside en partie dans llvation du niveau dabstraction des modles, base sur des mthodes de modlisation et vrification agissant des niveaux dabstraction plus levs [Monstand et al., 2006], [ITRS 2004]. Le cycle de dveloppement est une approche descendante qui consiste en un amalgame des mthodes de conception matrielles et logicielles [Gorse et al., 2004].

tel-00601086, version 1 - 16 Jun 2011

Figure 1.4 : Cycle de dveloppement dapplications Matriel/logiciel. Le cycle commence avec les ides prliminaires relatives au systme dvelopper, partir desquelles sont crits les documents nonant la description du systme et les exigences requises par rapport ses fonctionnalits. Les documents, aussi appels documents informels consistent en la description, en langue naturelle, du systme et de ses fonctionnalits. Ces descriptions sont la plupart du temps accompagnes de figures, tableaux [Belhadaoui et al., 2007-a], automates, algorithmes reprsentatifs, et parfois mme, de dtails particuliers concernant limplmentation. Ce sont ces documents qui servent de point de dpart de la phase de modlisation transactionnelle et fonctionnelle [Donlin A. 2004]. Durant cette phase est dlivr un premier modle haut niveau du systme. Les divers composants du modle sont ensuite affects une implmentation matrielle ou logicielle en fonction des - 16 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes contraintes de modularit ou contraintes temporelle. Le reste du cycle consiste en deux branches parallles au cours desquelles les implmentations matrielles et logicielles sont raffines et vrifies par simulation, ou par des techniques formelles [Givargis T. et Vahid F., 2002].

1.3.2. Modlisation et valuationLa modlisation consiste en une reprsentation abstraite dun systme rel, dans le but de lanalyser mathmatiquement. Le processus de modlisation doit tre bas sur des hypothses motives par deux considrations contradictoires [Mercier et al., 2006] : Simplicit : il faut veiller liminer les dtails sans intrt (expression volontairement vague, car tout dtail a son importance). La simplification permet dutiliser des mthodes danalyse beaucoup plus simples et plus rapides. Adquation des rsultats avec le systme rel : les rsultats obtenus avec le modle doivent tre trs proches des valeurs relles.

tel-00601086, version 1 - 16 Jun 2011

Lobjectif est dobtenir un compromis entre ces deux notions. Les modles mathmatiques utiliss sont des modles vnements discrets, des processus stochastiques, et bien souvent des chanes de Markov en raison de leurs bonnes proprits (exploitables). Afin de diminuer la complexit des modles manipuls, il est souhaitable de commencer par une description de plus haut niveau du systme, partir de laquelle un modle mathmatique peut tre algorithmiquement construit. Le modle mathmatique obtenu, se pose la question de son valuation. Les mesures qui nous intressent sont typiquement la fiabilit du systme, sa disponibilit, le temps de rponse, et la capacit au recouvrement dans le cadre de lvaluation des performances. Dans le cas idal, lvaluation peut tre ralise analytiquement, cest dire rsolue exactement [Belhadaoui et al., 2008-a]. Cependant ceci ne peut tre obtenu que dans le cas de modles relativement simples, avec des contraintes fortes (Markov...). De plus, il est important de noter que mme quand ces hypothses sont respectes, lvaluation nest pas toujours possible. La technique ncessitant le moins dhypothses est la simulation (technique dvaluation utilisant des nombres alatoires, souvent dfinie alors par simulation Monte Carlo).

1.3.3. Mthode de sret du logicielNous visons dans ce travail quantifier la fiabilit dune architecture matrielle excutant un logiciel dune manire analytique tout en vitant toute sorte de simulation lente. Il est ncessaire de poser la question quest-ce que la fiabilit des logiciels ? Comme repose cette question est dans le sens large, La fiabilit du logiciel est dfinie comme tant : La probabilit dun logiciel accomplir lensemble des fonctions spcifies dans son document de rfrence, dans un environnement donn et pour un temps de fonctionnement donn . Cest une dfinition de fiabiliste, qui peut tre value par des modles mathmatiques. Cette dfinition est plus restrictive que la dfinition de la fiabilit du logiciel donne dans la norme ISO/IEC 9126 comme laptitude du logiciel maintenir un niveau de performance requis lorsquil est utilis dans les conditions spcifies . Cette dfinition soulve dans le monde informatique principalement deux difficults selon [Valle F.et Vernos D., 2000].

- 17 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Un logiciel ne peut fonctionner quavec un support matriel muni de ses interfaces ad-hoc. Cette constatation a dclench le besoin de matriser la conception dun systme compos de logiciel et de matriel. En terme de fiabilit, nous examinons les diffrences qui existent entre un produit matriel et un produit logiciel donn par rapport : La dure dutilisation : Pour le matriel, la vie utile dcrot avec le temps si nous ne le rparons pas ; La fiabilit logicielle crot avec le temps si nous arrivons corriger les dfauts de conception ou si nous arrivons corriger le matriel sur lequel sexcute le logiciel. Lorigine de la dfaillance : Pour le matriel comme pour un logiciel, les causes de dfaillances prennent naissance pendant leur conception et leur production, Pour le matriel comme pour un logiciel, lobsolescence peut tre la consquence des effets des dfaillances (non rpares), de ceux de la mode ou bien du progrs technologique.

tel-00601086, version 1 - 16 Jun 2011

Si le logiciel nest pas soumis aux contraintes physico-chimiques, le phnomne de vieillissement ne se traduit pas par un changement de ses performances intrinsques, mais par un changement de son environnement. Il sagit en loccurrence de la contrainte dure de vie du logiciel. Il apparat que lapplication de la courbe en baignoire du matriel au cas du logiciel est non raliste, la courbe en baignoire ne sapplique pas strictement au logiciel. Cependant, le cycle de dveloppement du logiciel peut tre compar avec le cycle de vie du matriel. Ainsi, pendant les phases du cycle de dveloppement, le taux de dfaillance logiciel peut tre prsent par la courbe en baignoire (sans partie vieillissement, vue que le logiciel ne veiller pas). Rappelons que cette forme est due la priode de jeunesse, suivie de la priode o le taux de dfaillance est constant, et la priode de fin de vie. Si nous considrons les diffrentes modifications apportes au logiciel pendant lexploitation, nous constatons des courbes en baignoires qui se succdent. Il est ncessaire de prouver que ces dites baignoires sont bien leffet de phnomnes intrinsques la phase de dveloppement du logiciel. La premire phase commence avec les tests et est considre comme la phase de correction. Les erreurs de programmation ou les oprations non conformes aux spcifications sont identifies et corriges [MIL-HDBK-338B 1998] ; La deuxime phase reprsente la priode de vie utile du logiciel dans laquelle le taux de dfaillance est constant. La distribution utilise lors de cette phase est la loi exponentielle [MIL-HDBK-338B 1998] ; La dernire phase commence juste aprs la fin de la vie utile. La plupart des erreurs observes pendant cette priode rsultent de lincapacit du logiciel satisfaire des nouveaux besoins sans modification des spcifications initiales. Nous pouvons considrer ce phnomne comme l"usure" du logiciel. Les "dfauts" observs pendant cette priode peuvent servir comme base pour un nouveau logiciel. En plus, il y a le phnomne de vieillissement du logiciel, comme notamment les problmes lis aux systmes dexploitation [MIL-HDBK-338B 1998].

- 18 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Les risques induits par une dfaillance peuvent tre prdits, prvus, valus. Un nombre de mthodes prdictives dvaluation, ont t tudies. Avant de dtailler les principes de ces mthodes, il est ncessaire dentreprendre une rflexion et de lister les lments sur lesquels vont sappuyer ces diffrentes mthodes. Au cours de la conception et la ralisation dun produit logiciel, certaines tches sont automatises, dautres font appel lintervention humaine. Les tudes de fiabilit dun systme doivent tenir compte des diffrents lments qui sont en interaction avec lui. La fiabilit du systme est la rsultante de la fiabilit du matriel, du logiciel, des interfaces matriel-logiciel, de la fiabilit humaine, des interfaces homme-matriel-logiciel. Des modles de croissance de la fiabilit logicielle [Rook 1990], [Mihalache et al., 2005]ont t dvelopps. Ces modles restent peu utiliss dans les applications industrielles [Everett et al., 1998], ils ne permettent pas davoir une ide claire sur le niveau de risque dutilisation dun tel logiciel ce qui est le but principal de la quantification de la fiabilit. La fiabilit dun systme, est lie son aptitude assurer une mission dans des conditions denvironnement donnes et pendant une dure donne. En dautres termes, la fiabilit caractrise la confiance que lutilisateur peut placer dans le service rendu par ce systme.

tel-00601086, version 1 - 16 Jun 2011

Lapparition dune dfaillance systme est le fruit dun processus de propagations, combinaisons et interactions de fautes, selon Yasuura H. Si le code programme (ensemble dobjet et de routine), apparat parfaitement dterministe, le processus dapparition dune dfaillance, gnralement rcursif vis--vis de larchitecture hirarchique du systme, peut tre vu comme probabiliste en combinant aux fautes dites de premier type (de spcification par incompltude ou mauvaise comprhension, de conception, de ralisation), des fautes de deuxime type (activation dune erreur lors de sa rvlation au cours de lexcution du programme). Il existe une autre constatation dans le domaine du logiciel qui consiste dire quil suffit de corriger tous les erreurs du code pour liminer toute possibilit de dfaillance du logiciel associ et rendre le taux de dfaillance nul. Cest une confusion entre la fiabilit et le comptage des erreurs. Les concepteurs font souvent appel des mtriques qui se basent notamment sur le comptage des erreurs dans le code, ils ne sintressent pas aux sources de ces erreurs. Cette confusion fait partie de la problmatique de quantification de la fiabilit du logiciel. La quantification de fiabilit du logiciel, ncessite de remonter lorigine du besoin de lutilisateur. En effet le logiciel nest pas une vision abstraite mais il est matrialis par un systme dans lequel le code binaire sexcute afin dachever lobjet dune mission de service. Selon les besoins et spcifications du cahier des charges, la fiabilit sexprime par exemple en termes de MTTF (Mean Time To Failure), de taux de dfaillance, de la probabilit de pouvoir excuter la mission avec succs. Le systme est constitu du logiciel et dune architecture matrielle, chacun pouvant tre lorigine dune dfaillance. Cependant, pour pouvoir valuer la fiabilit globale de ce systme, il est naturel de prendre en compte la part de chacun de ses composants. Il sensuit assez clairement quil est indispensable de trouver une approche globale de modlisation de tout le systme. La dmarche SdF dans la phase de conception commence par une analyse prliminaire de risques du systme, afin didentifier les fonctions et les composants risque [Bel 07-a]. Cette

- 19 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes analyse permettra de prendre en compte les ncessits disoler les parties risques dans le choix de larchitecture. La dmarche repose essentiellement sur une analyse prvisionnelle des risques. Le but de lanalyse prvisionnelle des risques est didentifier les parties critiques du systme complexe et les actions pour rduire les risques associs. Lanalyse de risques peut tre ralise au moyen dune analyse inductive ou dune analyse dductive. Lanalyse inductive correspond une approche montante, o lon identifie toutes les combinaisons dvnements lmentaires possibles qui entranent la ralisation dun vnement unique indsirable. La dmarche de lanalyse dductive est inverse, puisque nous partons de lvnement indsirable et nous recherchons par une approche descendante toutes les causes possibles. Ces analyses qui sappuient sur la description du systme sont dites techniques danalyse statique [Darricau et al., 1999]. Des techniques danalyse dynamique sont galement utilises en complment. Ces analyses se droulent en parallle et en liaison troite avec les activits danalyse/spcification et de conception, de manire continue et itrative. Lanalyse statique ncessite de disposer en entre : des vnements redouts pour le systme ;

tel-00601086, version 1 - 16 Jun 2011

dune description du systme (au niveau de spcifications, puis au niveau de larchitecture, afin de comprendre les interactions entre les diffrents sous-systmes). Ces analyses mettent en vidence les scnarios susceptibles de conduire la dfaillance. A partir de ces scnarios, des actions de rduction des risques sont ensuite identifies, telles que : Spcification des modes de fonctionnement dgrad pour supprimer ou diminuer la gravit des consquences du dysfonctionnement considr. La spcification de ces modes de fonctionnement dgrad doit tre cohrente avec les exigences de tolrance aux fautes ; Etudes complmentaires spcifiques visant dmontrer limprobabilit du risque (modlisation, simulation) ; Identification dessais de validation spcifiques visant dmontrer que le scnario ne va pas se produire ; Contraintes sur larchitecture du matriel et du logiciel ; Contraintes sur la testabilit et lobservabilit en opration ; Implantation de mcanismes de dtection et de traitement de dfauts ; Choix de conception minimisant les risques (choix darchitecture, de structures de donnes, ...) ; Identification de tests permettant de dmontrer lefficacit des mcanismes implments. Lanalyse dynamique du comportement dun systme ainsi que sa modlisation dynamique permettent de vrifier des proprits supplmentaires de cohrence, de compltude, ... Elle permet aussi de tester les modes dgrads du systme et lefficacit des techniques de tolrance aux fautes. Les analyses dynamiques ou de performances permettent de mettre en vidence des problmes de : Dfinition incorrecte ou incomplte des modes de fonctionnement ou des transitions entre modes et donc des spcifications ;

- 20 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Dimensionnement et de partage de ressources ; Synchronisation des traitements et des entres/sorties ; Ordonnancement des tches ; Protocole de communication. Ce type de modlisation est surtout utile pour aider ou valider le choix entre plusieurs dveloppements possibles. Les techniques de modlisation pour la quantification de la fiabilit sont qualifies de prvisionnelles ou dexprimentales pour le matriel ou le logiciel : Techniques prvisionnelles : se situent en amont dans le cycle de vie. Lobjectif de ces techniques est de valider la conception du systme par rapport aux spcifications FMDS (fiabilit, maintenabilit, disponibilit et scurit) de sret de fonctionnement. Dans le cas du logiciel, il nexiste actuellement pas de technique suffisamment mature pour valuer la fiabilit prvisionnelle. Ce qui voque un vaste domaine de recherche.

tel-00601086, version 1 - 16 Jun 2011

Techniques exprimentales : consistent valuer le niveau de fiabilit atteint par le systme partir des essais raliss sur ce systme dans sa phase dexcution. Ces techniques se situent en aval dans les phases du cycle de vie. Elles ont pour objectif principal de vrifier lobtention du niveau de fiabilit requis en analysant les faits techniques observs. Les mthodes et modles dvaluation de logiciels commencent tre reconnus et permettent de mener bien des tudes de fiabilit exprimentale. Par extrapolation du comportement dj observ du logiciel, les modles de fiabilit du logiciel apportent des lments quantifis de la qualit de service tout en reposant sur des tests [Vall .F et Vernos .D, 2002]. La norme ISO/CEI 61508 [CEI 61508] qui fait rfrence dans le domaine dans le domaine de la scurit fonctionnelle, donne des taux de dfaillance quantifis aux niveaux dintgrit des systmes, avec prise en compte du logiciel. Cela invite les industriels et les concepteurs particulirement justifier ce niveau de dfaillance accept, laide dvaluation par modlisation ou laide dessais de qualification employant les techniques actuelles.

1.3.4. Mthode en sret des architectures matriellesLa notion de sret de fonctionnement dans le sens large selon [Villemeur A., 1997] est la science des dfaillances. Elle inclut leur identification dune manire exhaustive, leur valuation probabiliste, leur prvision par des observations et proposition des mthodes, leur mesure statistique ainsi que leur matrise par rduction, prvision et tolrance. La sret de fonctionnement dans le sens strict est laptitude dune entit assumer une ou plusieurs fonctions requises dans des conditions donnes. Ltude de la sret de fonctionnement dans les deux sens est lun des meilleurs moyens pour assurer la qualit de service. Une dfaillance dans le domaine de la sret de fonctionnement est un vnement qui indique la cession de laptitude dune entit accomplir une fonction requise. Lentit signifie

- 21 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes tout lment, composant, sous systme, unit fonctionnelle, quipement ou systme que lon peut considrer individuellement. Elle peut tre constitue par du matriel ou de logiciel. Une classification dans la terminologie des architectures des systmes peut tre : Pice Composant Sous-systme Systme lmentaire Systme Les dfaillances peuvent tre classes selon plusieurs critres, en fonction de leur importance, de la rapidit de leur apparition, de linstant de leur occurrence, de leurs causes et de leurs effets [CEI 50 191] [Villemeur A., 1997] [Laprie J.C.,1995], ces critres sont donns par :

Rapidit de manifestation : dfaillance progressive : de lvolution dans le temps (on peut la prvoir). dfaillance soudaine : non prvisible. Importance : dfaillance partielle : signifie la disparition de quelques fonctions du systme. dfaillance complte : disparition totale de toutes les fonctions du systme. dfaillance pertinente : elle a une consquence directe sur les calculs. dfaillance non pertinente : nentrane pas dinterprtation du calculs. Rapidit et importance : dfaillance catalectique : soudaine et complte. dfaillance par dgradation : progressive et partielle Date dapparition : dfaillance de la jeunesse : taux dapparition baisse. dfaillance par vieillissement : taux dapparition augmente. Par leurs effets : dfaillance mineurs : dommage ngligeable au systme, pas de risque humain. dfaillance significative : dommages significatives au systme, risque humain. Evaluation de la sret

tel-00601086, version 1 - 16 Jun 2011

Mthodes Qualitatives HAZOP PHA FMEA FTA

Mthodes Quantitatives ETA Markov

Figure 1.5 : Exemples de mthodes qualitatives et quantitatives de la sret de fonctionnement.

- 22 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Les mthodes danalyse de la sret de fonctionnement des architectures matrielles sont nombreuses. Parmi les mthodes souvent utilises dans ce domaine, nous distinguons des mthodes qualitatives et quantitatives pour lvaluation de la sret de fonctionnement (en premier lieu nous nous intressons ltude qualitative). Nous pouvons les classer selon la figure 1.5. Les mthodes qualitatives souvent utilises pour les systmes simples sont le PHA, HAZOP. Elles permettent un examen relativement rapide des situations dangereuses sur larchitecture du systme, leur simplicit se termine par la rencontre des systmes complexes. Nous trouvons les mthodes AAD (Analyse par Arbre de Dfaillances) et AMDEC (Analyse des modes de dfaillance de leurs criticit) qui consistent dterminer lenchanement des vnements pouvant conduire ou non un accident partir dun vnement initiateur, dans ces mthodes il faut dfinir avec discernement lvnement initiateur ce qui rend lourde leur mise en uvre surtout pour des systmes complexes. La mthode qualitative traite, dans ce travail, est la mthode AMDEC. Cette mthode est prcde par deux tapes fondamentales. Aprs la dfinition des spcifications standards du cahier des charges et les spcifications des paramtres FMDS (fiabilit, Maintenabilit, Disponibilit et Scurit). Nous ralisons une tude danalyse fonctionnelle qui consiste dfinir avec prcision les limites matrielles du systme, les diffrentes fonctions et oprations ralises par ce systme et les diverses configurations dexploitation. Cette tude se situe en amont, elle prsente ltude danalyse prliminaire de risque qui a pour but court terme dtablir une liste exhaustive des incidents ou accidents pouvant avoir des consquences sur la scurit de personnel et du matriel [Villemeur A., 1997] et long terme didentifier les dangers de chaque composant du systme, les modes de dfaillance les plus rencontrs, leurs causes possibles, et dvaluer leurs effets sur le reste de larchitecture du systme par calcul de leurs gravits.

tel-00601086, version 1 - 16 Jun 2011

1.3.5. Sret de fonctionnement des systmes de commande programmableLe contexte de notre travail est la conception dune architecture sre et structure de haut niveau (au sens de fiabilit et de robustesse) dun capteur. Ce capteur est spcifique aux systmes mcatronique en interaction avec un environnement physique ayant sa dynamique propre. Ces systmes se caractrisent par leur hybridit (continu/discret), leur complexit (diversit des aspects prendre en compte), et la criticit de leur sret. Ils se retrouvent dans des contextes applicatifs divers, et leur modlisation doit prendre en compte ce caractre mixte. Dans le domaine du contrle de procds physiques le problme est de trouver le compromis entre la rgulation et les lois de commande. Les systmes mcatroniques sont en extension et se sont dvelopps avec une cadence trs leve dans ces dernires dcennies. Lintelligence de ces lments est lie lexistence dun lment de calcul interne (processeur), qui requiert lusage de techniques particulires pour assurer leur programmation, dune part du fait de leur complexit, et dautre part la criticit de leur sret. En particulier, un modle global est ncessaire pour fournir un support des outils danalyse qui offrent une assistance la validation.

- 23 -

Chapitre1 : Sret de fonctionnement et ingnierie systmes Les motivations se prsentent la fois dans la conception et le dveloppement des systmes multi-formalismes et dans la prise en compte des exigences spcifiques en sret de fonctionnement de ces systmes complexes. Systmes complexes : Un systme dont la conception ncessite des techniques et des comptences diverses pour leur valuation, leur mise en uvre, et la dfinition de leurs missions, en termes de modes de fonctionnement, et de confrontation et commutation entre ces modes. Ceci suggre une structuration, distinguant diffrents niveaux dintervention. Systmes scurit critique : Un systme dont la consquence de son dysfonctionnement met souvent en danger les personnes (transportes dans le cas dun avion ou dun train par exemple), ou les biens (coteux, intervention difficile). Ceci induit un besoin dassistance la conception ou lopration de ces systmes par des mthodes de modlisation, danalyse, de validation et de mise en uvre correcte avec le support doutils efficaces. Devant lincapacit des mthodes classiques dvaluation de la sret de fonctionnement vis-vis des systmes complexes, lapproche flux informationnel [Hami et al.,2005] donne une ouverture et une piste pour rpondre ce besoin, elle fournit un ensemble de scnarios de dysfonctionnement, fond sur un modle dynamique des automates dtats finis, qui sert lanalyse de cohrence des spcifications et leur vrification. Lintgration de tels outils, peut tre une mthodologie de conception. Dans la suite de ce travail, nous allons montrer lextension de lapproche flux informationnel pour construire un modle global qui prend en compte la mixit continu/discret du systme de cas dtude (capteur intelligant). Il permet de structurer la spcification de faon dcoupler ces aspects (continu/discret). Il repose sur un modle dynamique qui offre des outils dassistance la spcification, lanalyse et la mise en uvre du prototype f