2011tou30161 2 PDF

THSE
En vue de l'obtention du
DOCTORAT DE LUNIVERSIT DE TOULOUSE

Dlivr par lUniversit Toulouse III Paul Sabatier Discipline ou spcialit : Systmes Industriels
Prsente et soutenue par Romaric GUILLERM Le 15 juin 2011 Titre :
Intgration de la Sret de Fonctionnement dans les Processus dIngnierie Systme
JURY M. Antoine RAUZY, Charg de Recherches lEcole Polytechnique de Paris (Prsident) M. Jean-Pierre BOUREY, Professeur lEcole Centrale de Lille (Rapporteur) M. Frdric KRATZ, Professeur lENSI de Bourges (Rapporteur) M. Jean-Claude PASCAL, Professeur lUPS de Toulouse (Examinateur) M. Hamid DEMMOU, Matre de Confrences lUPS de Toulouse (Directeur) M. Nabil SADOU, Professeur-assistant Suplec de Rennes (Co-directeur)
Ecole doctorale : Systmes Unit de recherche : LAAS-CNRS Directeur(s) de Thse : M. Hamid DEMMOU et M. Nabil SADOU
Remerciements
Remerciements
Le travail prsent dans ce mmoire a t ralis au Laboratoire dAnalyse et dArchitecture des Systmes (L.A.A.S.) du C.N.R.S. de Toulouse, au sein du groupe de recherche Ingnierie Systme et Intgration (I.S.I.). Mes remerciements vont en premier lieu Monsieur Raja CHATILA, directeur du LAAS, pour mavoir accueilli dans ce laboratoire pendant ces annes de travail. Je remercie galement Monsieur Hamid DEMMOU, Matre de Confrence HDR lUniversit Paul Sabatier de Toulouse, de mavoir accueilli au sein de son groupe de recherche I.S.I. et davoir encadr mon travail en mapportant nombres de recommandations. Ce travail a galement t dirig par Monsieur Nabil SADOU, Professeur-assistant lEcole Suplec de Rennes, qui jexprime ma gratitude pour ses conseils, son soutien et sa confiance. Je tiens remercier Monsieur Antoine RAUZY, Charg de Recherches au Laboratoire dinformatique de lEcole Polytechnique de Paris, de mavoir fait lhonneur de prsider mon jury de soutenance. Je suis trs reconnaissant envers Monsieur Jean-Pierre BOUREY, Professeur lEcole Centrale de Lille, et Monsieur Frdric KRATZ, Professeur lEcole Nationale Suprieure dIngnieurs de Bourges, davoir accept dtudier mon travail et den tre les rapporteurs ainsi que pour lintrt et lattention quils ont accords cette tude. Jexprime toute ma gratitude Monsieur Antoine RAUZY et Monsieur Jean-Claude PASCAL, Professeur lUniversit Paul Sabatier de Toulouse, davoir accept dexaminer ce travail. Je voudrais galement exprimer une profonde gratitude Monsieur Abd-El-Kader SAHRAOUI, Professeur lUniversit de Toulouse Le Mirail, pour les nombreuses discutions que nous avons pu avoir et qui mont permis davancer dans mon travail, ainsi que pour son amiti. Je remercie enfin lensemble des personnels du laboratoire LAAS, et plus particulirement lensemble des membres (ou anciens membres) du groupe I.S.I., pour leur accueil. Je ne saurais oublier non plus mes collgues doctorants ou stagiaires qui mont tenu compagnie et avec qui jai pass de bon moment : Jean VERRIES, Jacqueline KONATE, Mourad MESSAADIA, Vincent ALBERT, Carlos GOMEZ, Vikas SHUKLA, Amar CHAALANE, Hassen GHARBI, Oumar KONE, Fallou GUEYE, Bernat GACIAS, I
Remerciements Frdrique BANIEL, Maria Alejandra AYALA PEREZ, Touria BEN RAHHOU, Samia OURARI, Mariem TROJET, Boadu Mensah SARPONG, Kata KIATMANAROJ et Panwadee TANGPATTANAKUL. Le dernier mot s'adresse mes parents, mon beau-pre, mes surs et toute ma famille, mes amis et mes proches (que je ne pourrai malheureusement pas tous citer car il me manquerait de la place et je crains d'en oublier, je m'en excuse) pour leurs soutiens permanents tous les niveaux et pour leur fidlit dans leur engagement mes cts, notamment dans les moments les plus difficiles.
Le 1 juillet 2011, Toulouse Romaric GUILLERM
II
Ddicaces
Je ddie ce travail de thse, aboutissement de mes tudes, ma Mre, sans qui rien naurait tait possible.
Je le ddie galement une personne qui mest trs chre, laquelle je souhaite une mme prochaine russite.
III
IV
Table des Matires
Table des Matires

Introduction Gnrale .......................................................................... 1 Chapitre 1 : Ingnierie des systmes complexes et sret de fonctionnement ...................................................................................... 5
1. Introduction .......................................................................................................... 5 2. Systmes complexes ............................................................................................. 5
2.1. 2.2. 2.3. Dfinition dun systme ...........................................................................................5 Complexit ...............................................................................................................6 Proprits mergentes .............................................................................................7
3. Ingnierie Systme .............................................................................................. 7

3.1. 3.2. 3.3. 3.4. Historique et dfinition ...........................................................................................8 Cycle de vie et cycle de dveloppement ...................................................................9 Approche gnrale de conception des systmes ....................................................10 Ingnierie des exigences ........................................................................................13 Dfinition dune exigence ...............................................................................14 Rle et intrt de lingnierie des exigences ..................................................14 Expression des exigences................................................................................15 Traabilit .......................................................................................................15 Changement dexigences ................................................................................15 Quelques outils dingnierie des exigences ....................................................16 Dfinition dun risque .....................................................................................17 Pourquoi sintresser aux risques ? ................................................................18 Etapes de la gestion des risques.....................................................................19 Stratgies de la gestion des risques ...............................................................20 Outils de la gestion des risques ......................................................................21 Synthse..........................................................................................................22
3.4.1. 3.4.2. 3.4.3. 3.4.4. 3.4.5. 3.4.6. 3.5. 3.5.1. 3.5.2. 3.5.3. 3.5.4. 3.5.5. 3.5.6.
Gestion des risques ................................................................................................17
4. Sret de fonctionnement .................................................................................. 23

V
Table des Matires 4.1. 4.2. 4.3. 4.4. Historique .............................................................................................................. 23 Concepts et dfinitions .......................................................................................... 24 Quelques mthodes de sret de fonctionnement ................................................ 26 Enjeu de la sret de fonctionnement .................................................................. 29
5. Sret de fonctionnement des systmes complexes ......................................... 30

5.1. Exemples dchecs ................................................................................................. 30 Navette spatiale Challenger .......................................................................... 30 Ariane 5 .......................................................................................................... 30 Mars Polar Lander ......................................................................................... 31 Plate-forme ptrolire BP .............................................................................. 31 5.1.1. 5.1.2. 5.1.3. 5.1.4. 5.2. 5.3.
Origines des problmes de sret de fonctionnement .......................................... 32 Ncessit dune approche globale.......................................................................... 34
6. Conclusion .......................................................................................................... 35
Chapitre 2 : Dmarche processus propose ................................... 37

1. Introduction ....................................................................................................... 37 2. Etat de lart pour une conception de systmes srs ......................................... 37
2.1. Normes de Sret .................................................................................................. 37 CEI-61508 et ses drives .............................................................................. 37 ARP-4754 ........................................................................................................ 38 ARP-4761 ........................................................................................................ 40 SQUALE ......................................................................................................... 40 ESACS ............................................................................................................ 41 ISAAC ............................................................................................................. 42 ASSERT .......................................................................................................... 43 Modle de dveloppement sret de fonctionnement explicite .................. 43 Mthodologie dIS base sur les modles et guides par la SdF ................... 45 2.1.1. 2.1.2. 2.1.3. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.3. 2.3.1. 2.3.2. 2.4.
Quelques projets .................................................................................................... 40
Autres travaux de recherche ................................................................................. 43
Synthse ................................................................................................................ 47
3. Processus et normes dIngnierie Systme ....................................................... 49

3.1. 3.2. 3.3. 3.4. Vision processus .................................................................................................... 50 Normes dIngnierie Systme (IEEE-1220, EIA-632, ISO-15288) ....................... 51 Paradigme processus-mthodes-outils .................................................................. 53 EIA-632 .................................................................................................................. 53 VI
Table des Matires 3.4.1. 3.4.2. 3.4.3. 3.4.4. 3.4.5. Historique et gnralit ..................................................................................53 Interaction entre les diffrents processus ......................................................54 Les 33 sous-processus de lEIA-632 ................................................................55 Structure dun systme selon lEIA-632 .........................................................56 Vision des exigences de lEIA-632 ..................................................................57
4. Approche globale propose ................................................................................. 59

4.1. 4.2. Principe dintgration de la SdF ............................................................................59 Les processus de conception systme ....................................................................60 Le processus de dfinition des exigences .......................................................60 Le processus de dfinition de la solution .......................................................62 Le processus danalyse des systmes .............................................................65 Le processus de validation des exigences.......................................................65 Le processus de vrification du systme ........................................................66
4.2.1. 4.2.2. 4.3. 4.3.1. 4.3.2. 4.3.3.
Les processus dvaluation technique ...................................................................64
5. Conclusion .......................................................................................................... 66
Chapitre 3 : Mthodologie de dclinaison dexigences de sret de fonctionnement .............................................................................. 67

1. Introduction ........................................................................................................ 67 2. Dclinaison dexigences de sret de fonctionnement ...................................... 67
2.1. 2.2. Pourquoi cette dclinaison ? ..................................................................................67 Dclinaison vis--vis des processus dingnierie systme .....................................68
3. Travaux sur la dclinaison dexigences de sret de fonctionnement ............. 69

3.1. 3.2. Travaux de Peter Lindsay, John McDermid et David Tombs ..............................69 Travaux de Tim Kelly et al. ...................................................................................71
4. Prsentation de la mthodologie ....................................................................... 72

4.1. 4.2. Aperu de la mthodologie.....................................................................................73 Mthodes utilises .................................................................................................73 AMDEC ...........................................................................................................74 Arbre de dfaillances ......................................................................................75 Etape 1 : Analyse des dfaillances du systme ..............................................78 Etape 2 : Analyses des causes des dfaillances..............................................79 Etape 3 : Analyses des dfaillances des sous-systmes .................................80 Etape 4 : Synthse ..........................................................................................80 VII
4.2.1. 4.2.2. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4.
Mthodologie de dclinaison ..................................................................................78
Table des Matires
5. Formalisation UML ........................................................................................... 80

5.1. 5.2. 5.3. Formalisation de lAMDEC ................................................................................... 81 Formalisation de lArbre de Dfaillances.............................................................. 81 Formalisation de la mthodologie complte ......................................................... 82
6. Cas dtude ......................................................................................................... 83

6.1. 6.2. Prsentation de lexemple ..................................................................................... 83 Application de la mthodologie ............................................................................. 83 Etape 1 : Analyse des dfaillances du systme.............................................. 83 Etape 2 : Analyses des causes des dfaillances ............................................. 84 Etape 3 : Analyses des dfaillances des sous-systmes ................................. 84 Etape 4 : Synthse .......................................................................................... 85
6.2.1. 6.2.2. 6.2.3. 6.2.4. 6.3.
Utilisation de la formalisation UML..................................................................... 86
7. Bilan de la mthodologie et complment .......................................................... 87 8. Conclusion .......................................................................................................... 88
Chapitre 4 : Vers une mthodologie ISBM ..................................... 89

1. Introduction ....................................................................................................... 89 2. Modle dinformation et ISBM .......................................................................... 89
2.1. 2.2. 2.3. Ingnierie Systme Base sur les Modles (ISBM) .............................................. 89 Dfinition dun modle dinformation ................................................................... 92 Intrt dun modle dinformation ........................................................................ 92 Appuyer la gestion des exigences................................................................... 92 Partager les connaissances ............................................................................ 93 Supporter la conception ................................................................................. 94 Synthse ......................................................................................................... 95 MeMVaTEx .................................................................................................... 96 Modle de donnes de lAFIS ......................................................................... 96 Modle de MAP Systme ................................................................................ 98 DoDAF et MoDAF .......................................................................................... 99 Snow Card Volere ......................................................................................... 100 Travaux du CRAN ........................................................................................ 101 Travaux du LAAS-CNRS ............................................................................. 102 Synthse ....................................................................................................... 102
2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.4.4. 2.4.5. 2.4.6. 2.4.7. 2.4.8. 2.5.
Travaux relatifs aux modles dinformation ......................................................... 96
Triptyque exigences-solutions-V&V, principe de bonne conception .................. 103 VIII
Table des Matires
3. Modle propos ................................................................................................. 103

3.1. Le langage choisi : SysML ................................................................................... 104 Historique ..................................................................................................... 104 Prsentation.................................................................................................. 105 Strotype et block ....................................................................................... 106 Traabilit avec SysML ................................................................................ 107 Justification du choix de SysML .................................................................. 109 Exigences enrichies ...................................................................................... 110 Nouveaux strotypes dexigences ............................................................... 111 Strotype risk ......................................................................................... 112 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.3.
Extension propose de SysML ............................................................................. 109
Prsentation du modle dinformation ................................................................ 114
4. Complments au modle .................................................................................. 115

4.1. 4.2. Utilisation dOCL ................................................................................................. 115 Analyses et rsultats issus du modle de donnes ............................................. 116 Matrices de traabilit .................................................................................. 116 Etats des exigences ....................................................................................... 116
4.2.1. 4.2.2.
5. Conclusion ........................................................................................................ 117
Chapitre 5 : Exemple illustratif de lavion S18 ............................ 119

1. Introduction ...................................................................................................... 119 2. Prsentation de lexemple ................................................................................ 119
2.1. Le systme avion S18 ..................................................................................... 119 Les fonctions ................................................................................................. 119 Les sous-systmes ......................................................................................... 120 Les fonctions ................................................................................................. 121 Les sous-systmes ......................................................................................... 122 Les fonctions ................................................................................................. 123 Les sous-systmes ......................................................................................... 123 2.1.1. 2.1.2. 2.2. 2.2.1. 2.2.2. 2.3. 2.3.1. 2.3.2.
Le systme freins des roues ............................................................................ 121
Le systme calculateur BSCU ........................................................................ 123
3. Application de la mthodologie de dclinaison dexigences de Sret de Fonctionnement ...................................................................................................... 124

3.1. Niveau avion S18 ............................................................................................ 124 Etape 1 : Analyse des dfaillances du systme ............................................ 125 IX 3.1.1.
Table des Matires 3.1.2. 3.1.3. 3.1.4. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.3. 3.3.1. 3.3.2. 3.3.3. 3.3.4. Etape 2 : Analyses des causes des dfaillances ........................................... 125 Etape 3 : Analyses des dfaillances des sous-systmes ............................... 127 Etape 4 : Synthse ........................................................................................ 129 Etape 1 : Analyse des dfaillances du systme............................................ 129 Etape 2 : Analyses des causes des dfaillances ........................................... 130 Etape 3 : Analyses des dfaillances des sous-systmes ............................... 130 Etape 4 : Synthse ........................................................................................ 131 Etape 1 : Analyse des dfaillances du systme............................................ 132 Etape 2 : Analyses des causes des dfaillances ........................................... 132 Etape 3 : Analyses des dfaillances des sous-systmes ............................... 135 Etape 4 : Synthse ........................................................................................ 135
Niveau freins des roues .................................................................................. 129
Niveau calculateur BSCU .............................................................................. 132
4. Modlisation SysML ........................................................................................ 137

4.1. Prparation du projet sous Tau-G2 .................................................................... 137 Extension de SysML..................................................................................... 138 Organisation en packages ............................................................................ 138 Package de la solution de conception ........................................................... 140 Package des exigences .................................................................................. 141 Package de V&V : les cas de tests ................................................................ 145 Package de la solution de conception ........................................................... 146 Package des exigences .................................................................................. 148 Package de V&V : les cas de tests ................................................................ 151 4.1.1. 4.1.2. 4.2. 4.2.1. 4.2.2. 4.2.3. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.4.
Niveau avion S18 ............................................................................................ 140
Niveau freins des roues .................................................................................. 145
Niveau calculateur BSCU .............................................................................. 152
5. Synthse de ltude de cas ............................................................................... 152 6. Conclusion ........................................................................................................ 153
Conclusion Gnrale ........................................................................ 155 Bibliographie ..................................................................................... 159 Annexe A : Mots-cls associs au modle de dveloppement SdF explicite....................................................................................... 171
1. Expression des exigences ................................................................................ 171
X
Table des Matires 1.1. 1.2. 1.3. 1.4. 1.5. Processus de cration........................................................................................... 171 Processus de prvention de fautes ...................................................................... 171 Processus de tolrance aux fautes ....................................................................... 172 Processus dlimination des fautes ...................................................................... 172 Processus de prvision des fautes ....................................................................... 172
2. Conception ........................................................................................................ 173

2.1. 2.2. 2.3. 2.4. 2.5. Processus de cration........................................................................................... 173 Processus de prvention de fautes ...................................................................... 173 Processus de tolrance aux fautes ....................................................................... 173 Processus dlimination des fautes ...................................................................... 174 Processus de prvision des fautes ....................................................................... 174
3. Ralisation ........................................................................................................ 175

4. Intgration........................................................................................................ 175
Annexe B : Modlisation SysML du niveau calculateur BSCU ............................................................................................................... 177

1. Package de la solution de conception .............................................................. 177
1.1. 1.2. Fonctions du systme .......................................................................................... 177 Structure du systme........................................................................................... 178
2. Package des exigences ..................................................................................... 178

2.1. 2.2. 2.3. 2.4. Diagramme des exigences haut-niveau............................................................... 178 Diagramme de dclinaison des exigences ........................................................... 179 Diagramme de satisfaction des exigences ........................................................... 181 Diagramme de vrification des exigences ........................................................... 182
3. Package de V&V : les cas de tests ................................................................... 182

XI
Table des Matires
XII
Table des Figures
Table des Figures

Figure I.1 : Cycle de dveloppement en V dun systme ........................................................10 Figure I.2 : Cycle de vie d'un produit ......................................................................................10 Figure I.3 : Vue globale de la conception d'un systme ..........................................................11 Figure I.4 : Dmarche gnrale de conception........................................................................12 Figure I.5 : L'Ingnierie Systme fdratrice de domaines ....................................................12 Figure I.6 : Typologie des modles en IS (AFIS) ....................................................................13 Figure I.7 : Outils de gestion dexigences (INCOSE) ..............................................................17 Figure I.8 : Criticit des risques .............................................................................................18 Figure I.9 : 2 familles de risques.............................................................................................18 Figure I.10 : Arbre de la gestion des risques ..........................................................................22 Figure I.11 : Arbre de la Sret de Fonctionnement ..............................................................24 Figure I.12 : Relation faute-erreur-dfaillance.......................................................................26 Figure I.13 : Sret de fonctionnement et aspects contributeurs ..........................................34 Figure II.1 : Norme CEI-61508 et ses drives ......................................................................38 Figure II.2 : Les processus de lARP-4754 ..............................................................................39 Figure II.3 : Proposition du projet ESACS .............................................................................42 Figure II.4 : Modle de dveloppement SdF explicite .........................................................44 Figure II.5 : Processus gnriques de base relatifs la SdF..................................................48 Figure II.6 : Processus d'Ingnierie Systme .........................................................................50 Figure II.7 : Exemple de modlisation en processus ..............................................................51 Figure II.8 : Couverture des normes IEEE-1220, EIA-632 et ISO-15288 ..............................52 Figure II.9 : Approche Processus-Mthodes-Outils ................................................................53 Figure II.10 : Les processus de l'EIA-632 (traduction franaise) ...........................................54 Figure II.11 : Les 33 sous-processus de l'EIA-632 ..................................................................55 Figure II.12 : Un bloc de construction (traduction franaise) ................................................56 Figure II.13 : Exemple de dcomposition d'un systme avec l'EIA-632 .................................57 Figure II.14 : Relations entre exigences .................................................................................57 Figure II.15 : Rle des exigences spcifies ............................................................................58 Figure II.16 : Processus de conception systme......................................................................60 Figure II.17 : Processus de dfinition des exigences ..............................................................60 Figure II.18 : Processus de dfinition de la solution ..............................................................63 Figure II.19 : Processus dvaluation technique .....................................................................64 Figure III.1 : Evolution parallle des processus de Dfinition des Exigences et de Dfinition de larchitecture .......................................................................................................................69 Figure III.2 : Evolution parallle des processus de Dfinition des Exigences et de Dfinition de larchitecture .......................................................................................................................71 Figure III.3 : Vue gnrale de la mthode combinant AMDEC et Arbres de Dfaillances ...73 XIII
Table des Figures Figure III.4 : Exemple de structure dun tableau dAMDEC ................................................. 74 Figure III.5 : Exemple de modes de dfaillances gnriques extrait de lCEI-60812 ............ 75 Figure III.6 : Diagramme dIshikawa avec les 5 M ................................................................ 75 Figure III.7 : Exemple dArbre de Dfaillances ...................................................................... 76 Figure III.8 : Les portes logiques ............................................................................................ 77 Figure III.9 : Les reprsentations des vnements ................................................................ 77 Figure III.10 : Les symboles de transfert de sous-arbres ...................................................... 78 Figure III.11 : Formules pour le calcul des probabilits des fonctions OU et ET ................. 78 Figure III.12 : Exemple darbre de dfaillances ..................................................................... 79 Figure III.13 : Formalisation de lAMDEC en UML .............................................................. 81 Figure III.14 : Formalisation de larbre de dfaillance en UML ............................................ 82 Figure III.15 : Formalisation UML des concepts de la mthode AMDEC+AdD ................... 82 Figure III.16 : Systme ascenseur .......................................................................................... 83 Figure III.17 : AMDEC systme ascenseur - fonction transporter les usagers ........... 84 Figure III.18 : Arbre de dfaillance de la cause systme chute de la cabine .................... 84 Figure III.19 : AMDEC sous-systme de contrle du mouvement .................................... 85 Figure III.20 : Synthse de la dclinaison des exigences du systme ascenseur ............. 85 Figure III.21 : Diagramme dobjets de la formalisation UML pour lexemple du systme ascenseur ............................................................................................................................ 86 Figure IV.1 : Transition entre lIS centre sur les documents et lIS centre sur les modles ................................................................................................................................................. 90 Figure IV.2 : ISBM tout au long du cycle de dveloppement ................................................. 91 Figure IV.3 : Modle du systme au centre de lI.S. ............................................................... 91 Figure IV.4 : Relation entre les exigences dans lEIA-632 ..................................................... 93 Figure IV.5 : Le modle dinformation : un niveau dinterconnexion .................................... 94 Figure IV.6 : Rpartition des domaines au cours de la modlisation .................................... 95 Figure IV.7 : Exigence MeMVaTEx ........................................................................................ 96 Figure IV.8 : Vue dingnierie de dfinition darchitecture systme (AFIS) ......................... 97 Figure IV.9 : Extrait fiche n3 AFIS : un modle de donnes pour la description dexigences ................................................................................................................................................. 97 Figure IV.10 : Vue gnrale des processus IS - MAP Systme .............................................. 98 Figure IV.11 : Mta-modle gnrique de lIngnierie Systme de MAP Systme ............... 99 Figure IV.12 : Vue conceptuelle principale du Core Architecture Data Model 2.0 ............. 100 Figure IV.13 : SnowCard Volere ........................................................................................... 101 Figure IV.14 : Modle du systme faire de D. EVROT ..................................................... 102 Figure IV.15 : Sparation des concepts manipuls .............................................................. 103 Figure IV.16 : Historique de SysML ..................................................................................... 105 Figure IV.17 : Construction de SysML partir dUML 2 .................................................... 105 Figure IV.18 : Les diagrammes de SysML ........................................................................... 106 Figure IV.19 : Liens de traabilit entre exigences et exigences ......................................... 107 Figure IV.20 : Liens de traabilit entre exigence et autres lments de modle ............... 108 Figure IV.21 : Liens de traabilit entre exigence et autres lments de modle ............... 109 Figure IV.22 : Exigences SysML enrichies ........................................................................... 111 Figure IV.23 : Champ maturit dune exigence ................................................................... 111 Figure IV.24 : Nouveaux strotypes pour les exigences ..................................................... 112 Figure IV.25 : Matrice de criticit ........................................................................................ 113 XIV
Table des Figures Figure IV.26 : Le bloc risk ................................................................................................ 113 Figure IV.27 : Nouveau bloc risk li aux exigences de sret de fonctionnement .......... 114 Figure IV.28 : Modle dinformation SysML propos ........................................................... 114 Figure IV.29 : Exemple de matrice de traabilit pour la vrification des exigences .......... 116 Figure V.1 : Sous-systmes impliqus dans le freinage ....................................................... 120 Figure V.2 : Systme de freins des roues .............................................................................. 122 Figure V.3 : Systme BSCU .................................................................................................. 124 Figure V.4 : AMDEC systme Avion S18 pour la fonction de dclration au sol .......... 126 Figure V.5 : Arbre de dfaillance de la perte non-annonce de la capacit de dclration ............................................................................................................................................... 127 Figure V.6 : Arbre de dfaillance de la dclration involontaire aprs V1 ................... 127 Figure V.7 : AMDEC du sous-systme freins des roues .................................................. 128 Figure V.8 : Arbre de dfaillance de la perte non-annonce de tous les freins des roues ............................................................................................................................................... 130 Figure V.9 : AMDEC du sous-systme calculateur BSCU .............................................. 131 Figure V.10 : Arbre de dfaillance de une dfaillance du BSCU provoque la perte de la commande de freinage (1/2) ................................................................................................ 132 Figure V.11 : Arbre de dfaillance de une dfaillance du BSCU provoque la perte de la commande de freinage (2/2) ................................................................................................ 133 Figure V.12 : Arbre de dfaillance de le BSCU commande le freinage en labsence de donnes dentre et provoque un freinage involontaire (1/3) ............................................. 133 Figure V.13 : Arbre de dfaillance de le BSCU commande le freinage en labsence de donnes dentre et provoque un freinage involontaire (2/3) ............................................. 134 Figure V.14 : Arbre de dfaillance de le BSCU commande le freinage en labsence de donnes dentre et provoque un freinage involontaire (3/3) ............................................. 134 Figure V.15 : Extension de SysML ....................................................................................... 138 Figure V.16 : Building blocks ................................................................................................ 139 Figure V.17 : Organisation en packages ............................................................................... 139 Figure V.18 : Avion S18 Fonctions du systme ................................................................. 140 Figure V.19 : Avion S18 Structure du systme ................................................................. 141 Figure V.20 : Avion S18 Diagramme des exigences haut-niveau ..................................... 142 Figure V.21 : Avion S18 Diagramme de dclinaison des exigences .................................. 143 Figure V.22 : Avion S18 Diagramme de satisfaction des exigences .................................. 144 Figure V.23 : Avion S18 Diagramme de vrification des exigences .................................. 145 Figure V.24 : Avion S18 Cas de tests ................................................................................. 145 Figure V.25 : Freins des roues Fonctions du systme ....................................................... 146 Figure V.26 : Freins des roues Structure du systme ....................................................... 147 Figure V.27 : Freins des roues Structure du systme (2) .................................................. 147 Figure V.28 : Freins des roues Diagramme des exigences haut-niveau ........................... 149 Figure V.29 : Freins des roues Diagramme de dclinaison des exigences ........................ 150 Figure V.30 : Freins des roues Diagramme de satisfaction des exigences........................ 151 Figure V.31 : Freins des roues Diagramme de vrification des exigences ........................ 151 Figure V.32 : Freins des roues Cas de tests....................................................................... 152 Figure V.33 : Synthse dune partie des dclinaisons .......................................................... 153 Figure B.1 : Calculateur BSCU Fonctions du systme ..................................................... 177 Figure B.2 : Calculateur BSCU Structure du systme...................................................... 178 XV
Table des Figures Figure B.3 : Calculateur BSCU Diagramme des exigences haut-niveau ......................... 178 Figure B.4 : Calculateur BSCU Diagramme de dclinaison des exigences (partie 1/2) ... 179 Figure B.5 : Calculateur BSCU Diagramme de dclinaison des exigences (partie 2/2) ... 180 Figure B.6 : Calculateur BSCU Diagramme de satisfaction des exigences...................... 181 Figure B.7 : Calculateur BSCU Diagramme de vrification des exigences ...................... 182 Figure B.8 : Calculateur BSCU Cas de tests..................................................................... 183
XVI
Introduction Gnrale
Introduction Gnrale
Lintgration de diverses technologies, notamment celles de linformatique et llectronique, fait que les systmes conus de nos jours sont de plus en plus complexes. Ils ont des comportements plus labors et plus difficiles prvoir, ont un nombre de constituants en interaction plus important et/ou ralisent des fonctions de plus haut niveau. Paralllement cette complexification des systmes, la comptitivit du march mondial impose aux dveloppeurs de systmes des contraintes de cot et de dlais de plus en plus strictes. La mme course sopre concernant la qualit des systmes, notamment lorsque ceux-ci mettent en jeu un risque de vies humaines ou un risque financier important. Ainsi, les dveloppeurs sont contraints dadopter une approche de conception rigoureuse pour rpondre aux exigences du systme souhait et satisfaire les diverses contraintes (cot, dlais, qualit, sret de fonctionnement,). Pour prendre en compte ces contraintes, un cadre a t dfini. Il s'agit de l'Ingnierie Systme (IS) qui est une dmarche mthodologique pour matriser la conception des systmes et des produits complexes. Cette dmarche est dfinie travers diffrentes normes visant guider la conception de systme. La sret de fonctionnement, qui prend une place de plus en plus importante dans la conception des systmes, doit tre intgre dans les processus dingnierie systme. En effet, les proprits de sret sont des proprits mergentes. Elles rsultent dinterdpendances qui existent dans le systme et dans linteraction de ce dernier avec son environnement. Lanalyse de la sret de fonctionnement ncessite donc une dmarche globale. Le travail prsent dans ce mmoire a pour objectif la proposition dune approche globale pour la prise en compte de la sret de fonctionnement. Il sappuie sur la norme EIA-632, qui est largement employe, en particulier dans les domaines aronautique et militaire. Il consiste amliorer les processus dingnierie systme dcrits par lEIA-632, afin dintgrer une prise en compte globale et explicite de la sret de fonctionnement. En effet, jusqu prsent la sret de fonctionnement tait obtenue par la rutilisation de modles gnriques aprs avoir tudi et dvelopp chaque fonction indpendamment. Il ny avait donc pas de prise en compte spcifique des risques lis lintgration de plusieurs technologies. Lintgration de la sret de fonctionnement dans les processus de lIS offre un cadre structurant pour mener les analyses dans un contexte plus large que celui traditionnellement rencontr dans le milieu fiabiliste. Un des processus les plus critiques de lIS est celui de lingnierie des exigences. Pour cette raison, nous proposons de nous intresser aux exigences de sret de fonctionnement au niveau global et le plus tt possible dans la phase de dveloppement, pour ensuite les dcliner aux niveaux infrieurs, ceci en sappuyant sur les processus de la norme EIA-632 1
Introduction Gnrale que nous toffons. Nous proposons galement une mthode originale de dclinaison d'exigences de sret de fonctionnement base d'arbres de dfaillances et d'AMDEC. Pour une meilleure gestion de la complexit des systmes, la tendance actuelle est dutiliser des approches se basant sur lIngnierie Systme Base sur les Modles (ISBM), qui propose de sappuyer fortement sur les modles, ceci pour toutes les tapes du cycle de dveloppement. Ainsi, une autre facette du travail prsent propose un modle d'information bas sur SysML pour appuyer notre approche.
Survol de la thse
Ainsi, trois axes principaux se dgagent des travaux prsents dans ce mmoire de thse. Ceux-ci concernent : 1. Une dmarche dIngnierie Systme intgrant la sret de fonctionnement, qui explicite au niveau processus dingnierie systme comment prendre en compte les aspects sret de fonctionnement pour la conception. 2. Une mthodologie de dclinaison dexigences de sret de fonctionnement, qui aide la dfinition et la dclinaison dexigences de sret niveau systme en exigences de sret alloues aux sous-systmes ( diffrents niveaux). 3. Un modle dinformation en SysML, qui permet de collecter toutes les informations produites lors de la conception, dappuyer et de guider cette conception. La dmarche dIngnierie Systme intgrant la sret de fonctionnement La dmarche dingnierie systme intgrant la sret de fonctionnement explique les activits accomplir chaque tape du travail de conception (dfinition des exigences, de la solution logique, de la solution physiques, etc.) pour concevoir un systme sr de fonctionnement. Le niveau de vision adopt ici est celui du processus. Nous ne considrons pas les mthodes, encore moins les outils. Cette vision processus nimpose pas de cycle de conception particulier (par exemples : cycle en V ou cycle en spirale). Nanmoins, les allers-retours entre dfinition des exigences et dfinition de la solution (logique et physique) semblent invitables, dautant plus que nous traitons des systmes complexes. En fait, des choix de conception, des conflits entre exigences, voire mme des difficults techniques satisfaire certaines exigences, ceci lors de la dfinition de la solution, amnent dfinir de nouvelles exigences (ou modifier danciennes) et les rinjecter dans la spcification. Cest particulirement le cas pour un certain nombre dexigences concernant les proprits de sret de fonctionnement, qui ne peuvent tre identifies, dfinies et/ou dclines compltement quune fois une architecture fonctionnelle dcide, ou bien un choix darchitecture physique fait. La mthodologie de dclinaison dexigences de sret de fonctionnement : Notre dmarche de conception sre, qui sattache donc traiter les aspects de sret de fonctionnement dun systme, implique entre autres une traabilit rigoureuse. Tout lment de la conception doit justifier sa prsence par lexistence dexigences lui correspondant. Cela signifie que la source de la conception est fonde sur lensemble des exigences dans notre dmarche. Ainsi, rendre le systme sr de fonctionnement consiste 2
Introduction Gnrale entre autres tre capable de dfinir les exigences de sret de fonctionnement, de les traiter, de les dcliner, et de les allouer. La mthodologie de dclinaison dexigences de sret de fonctionnement que nous proposons permet daider cette dfinition dexigences de sret, tout dabord au niveau du systme. Puis, elle permet la dclinaison ncessaire de ces exigences de sret au niveau plus bas : celui des sous-systmes. La mthodologie combine la fois des AMDEC niveau systme, des Arbres de Dfaillances (AdD), et des AMDEC niveau sous-systmes. LAMDEC niveau systme ncessite la solution logique du systme pour pouvoir tre ralise. Elle est lorigine dactions correctives qui conduiront des exigences de Sret de Fonctionnement (SdF) de niveau systme. Ces actions correctives sattachent rduire soit la probabilit dapparition du mode de dfaillance, soit la gravit des effets du mode de dfaillance. Concernant les actions correctives qui sintressent la probabilit, lutilisation dun AdD, une fois la solution physique disponible, et dAMDEC sous-systme permettent de dcliner les exigences niveau systme en exigences niveau sous-systmes. Pour les actions correctives qui soccupent de la gravit, le niveau de spcification est aussi le niveau systme. Lutilisation darbres dvnements (Event Tree) peut faciliter lidentification ou la comprhension de ces actions correctives. Le modle dinformation en SysML Nous souhaitons galement appuyer la conception, avec sa gnration de donnes dingnierie (exigences, solutions logique et physique), par un modle dinformation. Celuici permet de regrouper toutes les donnes de la conception au sein dune base commune tous les participants (ingnieurs systme, ingnieurs de sret de fonctionnement, ). Bien entendu, doivent tre inclus les diffrentes exigences, les fonctions identifies, ainsi que les composants choisis, mais galement un ensemble de liens entre ces lments afin de rendre cohrent le modle et dexpliquer lutilit des diverses informations. Il sagit l encore de laspect de traabilit, trs important pour une conception cohrente et sre. Le langage bien adapt que nous avons choisi pour raliser ce modle est SysML (une extension dUML lingnierie systme). Il permet de dfinir aussi bien les exigences, les fonctions et les composants, que les diffrents liens de traabilit voqus plus haut. Lintrt dun tel modle dinformation qui regroupe au sein dun mme modle les aspects de spcification (les exigences) et de solution de conception (fonctions, composants et architectures associes) est quil permet une prise en compte rapide et efficace des volutions des deux aspects en parallle, dfinition des exigences et dfinition de la solution. La prsence de ces deux aspects (exigences et solution) au sein du mme modle ne contrarie pas pour autant les recommandations des autorits de sret qui sont de ne pas mler les exigences la modlisation de la solution. En effet, SysML permet de clairement distinguer et sparer les deux aspects. Egalement pris en compte dans notre modle, les cas de tests du langage SysML sont utiliss et lis aux exigences quils vrifient. Devant tre prvus ds ltape de dfinition des exigences, ils permettent dintgrer les aspects de vrification et validation dans le modle.
Plan du manuscrit
Suite cette introduction gnrale, le premier chapitre prsente le cadre de travail qui est celui de lingnierie systme. Il prsente entre autres la gestion des exigences, la gestion des risques, ainsi que le domaine de la sret de fonctionnement. Ce chapitre finit par la 3
Introduction Gnrale prsentation de notre problmatique, sur la base dun constat fait sur les origines des problmes de sret de fonctionnement des systmes complexes. Le deuxime chapitre du mmoire expose la dmarche dingnierie systme base de processus qui prend en compte la sret de fonctionnement. Ce chapitre propose un tat de lart sur le sujet et prsente les visions processus et normes dingnierie systme. La norme EIA-632, sur laquelle nous nous appuyons, est prsente avant lexposition de notre dmarche processus propose. Le troisime chapitre concerne la mthodologie de dclinaison dexigences de sret de fonctionnement. Le bien-fond de cette mthodologie est justifi et celle-ci est galement resitue dans les processus dingnierie systme. Un tat de lart sur la dclinaison dexigences de sret est dvelopp, une formalisation UML est propose et un cas dtude simple illustre son application. Le quatrime chapitre souhaite orienter la dmarche de prise en compte de la sret de fonctionnement vers une dmarche dIngnierie Systme Base sur les Modles (ISBM). Le modle dinformation dvelopp dans le cadre de ces travaux de thse et bas sur le langage SysML sera expos. Le cinquime et dernier chapitre du mmoire prsente un exemple issu du monde aronautique qui sert dillustration aux propositions des chapitres prcdents. Il sagit dun avion de ligne fictif, sur lequel nous appliquons la mthodologie de dclinaison dexigences de sret diffrents niveaux et pour lequel nous fournissons une modlisation SysML utilisant notre modle dinformation. Pour finir, une conclusion gnrale fait le bilan des contributions apportes, ceci par rapport la problmatique identifie. Il sagit galement de prsenter les perspectives des travaux afin de les amliorer et de les poursuivre.
Chapitre 1
Ingnierie des systmes complexes et sret de fonctionnement
I.
Chapitre 1 : Ingnierie des systmes complexes et sret de fonctionnement

1. Introduction
Ce premier chapitre du mmoire introduit le cadre de travail : lingnierie systme. Il correspond au domaine de recherche du groupe ISI (Ingnierie Systme et Intgration) du LAAS-CNRS au sein duquel cette thse a t ralise. Spcifiquement, nous traitons des systmes complexes, dont nous donnons notre propre dfinition. Nous discernons quelles sont les principales caractristiques de ces systmes, et expliquons en quoi cette complexit influe sur les activits de dveloppement. Un aspect important de la conception systme sur lequel se focalise le travail de thse est la sret de fonctionnement [Laprie, 2004]. Nous prsentons cette notion et dcrivons comment elle intervient dans lingnierie des systmes complexes. Ainsi, dans ce chapitre, aprs la dfinition de ce quest un systme complexe et aprs avoir expos ses principales caractristiques, nous abordons la discipline de lingnierie systme. Les notions de cycles de vie, cycles de dveloppement et approche de conception sont ensuite exposes. Parmi les diffrents processus de lingnierie systme, nous faisons un focus s ur la gestion des exigences et la gestion des risques, qui importent normment pour notre problmatique. Puis nous prsentons la sret de fonctionnement, avec ses concepts, quelques-unes de ses mthodes et son enjeu. Pour finir, nous exposons un constat sur les origines des problmes de sret de fonctionnement des systmes complexes, appuy par quelques exemples de systmes qui ont dfaillis. La problmatique de notre travail qui sappuie sur ce constat est prsente la fin de ce premier chapitre.
2. Systmes complexes
2.1. Dfinition dun systme
Depuis toujours, lhomme invente et conoit des instruments, des matriels, des quipements, pour amliorer ou faciliter sa vie. Ces fabrications ont un intrt direct ou indirect pour lhomme en apportant un service. La motivation de toutes ces constructions vient des fonctions apportes par le systme, qui se manifestent par des interactions entre le systme lui-mme et lenvironnement. Concernant les premires ralisations de lhomme, 5
Chapitre 1
celles-ci taient relativement simples. Ainsi, la structure interne de la conception tait trs facilement comprhensible. Mais malgr leur simplicit, ces lments constituaient dj les premiers systmes . Puis, ils ont sans cesse volu en devenant de plus en plus labors et compliqus, surtout depuis le dbut de lre industrielle. Cependant, quelque soit le systme, une caractristique demeure. En effet, ils font tous lobjet dassociation dlments (constituants, composants, ) en interaction dans le but de faire merger de nouvelles fonctionnalits qui permettent de rendre un ou plusieurs services attendus. Ainsi, nous donnons ds prsent une dfinition dun systme, extraite du livre Ingnierie et Intgration des systmes de Jean-Pierre MEINADIER [Meinadier, 1998], qui est la suivante : Dfinition : Un systme est un ensemble composite de personnels, de matriels et de logiciels organiss pour que leur interfonctionnement permette, dans un environnement donn, de remplir les missions pour lesquelles il a t conu. Nous constatons alors que par une gnralisation, lhomme peut lui-mme faire partie dun systme, la manire dun constituant . LAFIS (Association Franaise dIngnierie Systme) [AFIS] a galement sa propre dfinition du systme, dans laquelle lintrt des interactions est clairement exprim : Dfinition : Un systme est dcrit comme un ensemble dlments en interaction entre eux et avec lenvironnement, intgr pour rendre son environnement les services correspondants sa finalit. Un systme prsente donc des proprits nouvelles rsultant des interactions entre ses constituants : si lon intgre des lments pour faire un systme, cest bien pour bnficier des effets de synergie rsultant de leurs interactions. Une autre dfinition dun systme donne par lINCOSE (International Council on Systems Engineering) est la suivante : Un systme est un ensemble dlments interdpendants qui interagissent entre eux de faon organise et forment un ensemble unique [INCOSE 2004]. Finalement, nous pouvons conclure que les interactions constituent lessence mme des systmes. Grce elles, de nouvelles proprits apparaissent, dpassant celles propres aux simples constituants.
2.2. Complexit
Alors que bon nombre douvrages fournissent une dfinition claire du mot systme , il nen va pas de mme pour lexpression systme complexe , qui simpose pourtant largement aujourdhui [Magee & al., 2004]. En revenant lorigine de ladjectif complexe , il apparait que ce mot nous provient du latin cum plexus, qui signifie quil y a beaucoup dintrications, que tout est li . Le lien avec les interactions et leur nombre est alors acquis. Mais est-ce ncessaire et/ou suffisant pour former un systme complexe ?
Chapitre 1
En se rfrant au dictionnaire, nous trouvons : Complexe, adjectif Sens 1 : Qui comprend plusieurs lments ayant de nombreux rapports entre eux. Synonyme : emml. Anglais : complex. Sens 2 : Difficile apprhender, analyser et en saisir le sens. Synonyme : difficile. Anglais : complex, complicated. Le sens 1 de la dfinition ci-dessous reprend lide dune interaction importante entre les constituants du systme, mais ajoute cela le fait que ces lments sont un certain nombre. Le sens 2 fait supposer que le fonctionnement du systme nest pas comprhensible immdiatement, il est difficile suivre et tudier. Sajoute donc une difficult de comprhension et danalyse. Nous avons alors tent de donner notre propre dfinition dun systme complexe , en tenant compte de ce qui prcde mais aussi dautres crits que nous avons pu rencontrer pendant nos recherches. Systme Complexe : Systme capable de fournir des fonctions de haut niveau, dont le comportement global est difficile prvoir et dont la structure prsente un graphe dinteraction non-trivial, souvent pourvu de boucles de rtroactions, et associant la plupart du temps plusieurs technologies de par limplication de nombre de constituants. La complexit de ces systmes a forc les concepteurs adopter et sadapter une mthode de dveloppement bien plus organise et rigoureuse [Bar-Yam, 2005]. La section 3 prsente cette nouvelle faon daborder la conception, ncessaire pour matriser cette complexit grandissante : lIngnierie Systme.
2.3. Proprits mergentes

Un concept important qui a fait son apparition avec les systmes complexes est celui de proprits mergentes [Leveson, 2004], [Black & al., 2009]. Elles dsignent les caractristiques du systme qui apparaissent du fait de la mise en interaction des constituants. En effet, ces proprits mergentes ne peuvent pas tre attribues des composants seuls. Elles sont bases sur le fait que lensemble fait plus que la somme de ses parties. Lmergence est un domaine de recherche part entire, que nous nexplorons pas ici. Seulement, comme annonc en introduction, nous allons nous intresser aux proprits de sret de fonctionnement des systmes complexes qui sont fortement lies un caractre mergent.
3. Ingnierie Systme
Aprs avoir revu les concepts de systme et systme complexe, nous nous intressons la conception de ces systmes. Plus particulirement, nous exposons le domaine quest lIngnierie Systme, travers son historique, sa dfinition et quelques concepts comme le cycle de vie dun systme ou le cycle de dveloppement. Nous terminons la section par deux 7
Chapitre 1
aspects inclus dans lingnierie systme sur lequel lessentiel du travail va sappuyer : lingnierie des exigences et la gestion des risques.
3.1. Historique et dfinition

LIngnierie Systme a fait son apparition aux Etats-Unis dans les annes 50 pendant les courses lespace et au dveloppement de missiles quips de tte nuclaire. Pour ces derniers, considrs comme une ncessit absolue pour la scurit du pays, les services militaires et leurs sous-traitants civils subissaient une pression norme pour dvelopper, tester et mettre en service ces missiles nuclaires le plus rapidement possible, de mme que pour mettre en orbite des satellites despionnage. Ils se sont donc attachs trouver des outils et des techniques pour amliorer la performance du systme, et surtout celle de la gestion du dveloppement (en termes de performance technique, dchance calendaire ou encore de contrle du cot). A partir de ce moment, le management de lingnierie a alors beaucoup volu, en standardisant lutilisation de spcifications, de documents dinterfaces, de revues de conception ou encore de gestion de configuration formelle. Les progrs du monde informatique ont, galement, normment contribu lexpansion de lIngnierie Systme, facilitant les travaux de gestion et denregistrement de documents et de configurations. Les outils informatiques ont aussi permis un net progrs grce la possibilit deffectuer toutes sortes de simulation. En France, il existe depuis 1999 une association regroupant des entreprises concernes par lIngnierie Systme : lAssociation Franaise dIngnierie Systme [AFIS]. On y trouve entre autre des entreprises comme Airbus, Alcatel Space, Thales, Giat Industrie, Renault, PSA Peugeot Citron, France Tlcom, EDF, RATP, etc. Il existe aussi une association internationale dIngnierie Systme, implante aux Etats-Unis : lInternational Council on Systems Engineering (INCOSE). LAFIS est dailleurs affilie lINCOSE en tant que chapitre franais de lINCOSE . LIngnierie Systme est donc le domaine qui va aider le concepteur et lui permettre de mener son dveloppement de la meilleure manire possible. Cette nouvelle science est finalement le rsultat dun retour dexprience de la part de grandes entreprises industrielles impliques dans le dveloppement de systmes technologiques complexes. En fait, deux raisons principales sont lorigine de cette science. La premire provient dchecs industriels et commerciaux, car ils ont grandement motiv lintroduction dune mthode daide, dassistance ou de gestion afin de les viter. Ils vont dailleurs continuellement tre analyss pour amliorer lIngnierie Systme. La seconde vient du constat quune grande part des activits mener pour les dveloppements est un invariant vis--vis des projets et des secteurs dapplication. Les problmes affronter sont en effet souvent de mme nature : des besoins insuffisamment exprims, des spcifications imprcises ou incompltes, des solutions non justifies ou non valides, une formation des utilisateurs insuffisante, des ressources et comptences mal planifies, etc.
Chapitre 1
Aprs ce rapide historique de lavnement de lIngnierie Systme, voyons la dfinition quen donne lAFIS : LIngnierie Systme (ou ingnierie de systmes) est une dmarche mthodologique gnrale qui englobe lensemble des activits adquates pour concevoir, faire voluer et vrifier un systme apportant une solution conomique et performante aux besoins dun client tout en satisfaisant lensemble des parties prenantes. Pour rsum, lIngnierie Systme est donc une approche mthodologique qui a t dveloppe et est en amlioration continue pour permettre au concepteur de systme complexe daboutir une solution quilibre dans les meilleurs cots et dlais et rpondant au mieux aux besoins des diffrentes entits concernes par lutilisation du systme (les clients, les agents de maintenance, dautres systmes,).
3.2. Cycle de vie et cycle de dveloppement

Lorsque lon traite de lIngnierie Systme, il est incontournable de considrer le cycle de dveloppement du produit et son cycle de vie. Le cycle de dveloppement le plus connu, apparu dabord dans le domaine informatique, est incontestablement le cycle en V [Forsberg & al., 1991a]. Celui-ci est compos de 2 branches. La branche descendante correspond une dmarche de raffinements successifs qui rpond la phase de conception, partant du gnral (lexpression des besoins souvent travers un Cahier des Charges Fonctionnel (CdCF)) pour dboucher sur le particulier. La branche ascendante, quant elle, dtaille les phases dintgration et de validation du systme. La Figure I.1 ne donne quun exemple de cycle de dveloppement en V, car le nombre dtapes et les noms des phases changent souvent dun ouvrage lautre. Mais le principe reste toujours le mme. On constate ici quune premire phase de spcification dmarre avec le CdCF en donne dentre, produit le rfrentiel des exigences, encore appel spcification technique des besoins, et prvoit dores et dj le plan de validation du systme qui sera utilis en phase finale. Ensuite, ltape de conception dmarre pour aboutir au dossier de conception, compos dune spcification de larchitecture du systme et des spcifications techniques des besoins des constituants, et du plan et tests dintgration. Peut alors commencer le dveloppement des diffrents constituants qui vont composer le systme final. Cette tape de dveloppement peut dailleurs tre vue comme la juxtaposition de multiples sous-cycles en V qui peuvent se drouler en parallle, hauteur dun cycle par constituants concevoir. Si le constituant nest pas ralisable par un seul mtier (ou gnie), le sous-cycle associ reprend celui du systme. Pour finir, se succdent les tapes dintgration du systme, pendant lesquelles les constituants sont assembls entre eux en suivant le plan dintgration pralablement tabli, et de validation du systme, pour vrifier que le systme rpond bien aux besoins initiaux (le CdCF) et en utilisant le plan de validation.
Chapitre 1
Figure I.1 : Cycle de dveloppement en V dun systme
Le pige de ce cycle en V est la linarit apparente dune succession squentielle des oprations. Car il nen est rien. En pratique, il y a de nombreuses rtroactions des phases aval vers les phases amont, suite des dcouvertes tardives derreurs obligeant remettre en question des phases pralablement valides ou suite une demande de modification dexigences ou une volution du march par exemple. Cest pourquoi dautres cycles de dveloppement existent, avec notamment le modle incrmental, le modle versions successives ou encore le modle en spirale [Boehm, 1986]. Mais le champ daction de lIngnierie Systme ne se limite pas la seule tape du dveloppement du produit. En effet, elle agit sur tout le cycle de vie du systme, depuis la phase de conceptualisation jusqu celle de retrait de service, comme le montre la Figure I.2.
Figure I.2 : Cycle de vie d'un produit
3.3. Approche gnrale de conception des systmes

LIngnierie Systme fournit donc une dmarche mthodologique qui suit le produit tout au long de sa vie, depuis ses premires conceptualisations, jusqu son retrait dfinitif du service, en passant par les phases de dveloppement et dexploitation. Le paragraphe qui suit explique de manire gnrale comment et sous quelles contraintes est conu un systme. 10
Chapitre 1
Tout dabord, un nombre important dacteurs peut tre impliqu dans la ralisation du produit. Cela induit dj un premier besoin en termes dorganisation pour grer au mieux les communications entre tous ces acteurs. On trouve videmment le dveloppeur en charge de la conception (aussi appel concepteur ou matre duvre) et le ou les clients (ou utilisateurs). Mais bien souvent, on a galement affaire un matre douvrage (pour le compte duquel est ralis le systme), des sous-traitants ou des fournisseurs. Tous ces acteurs, mis part le dveloppeur lui-mme, vont constituer ce que lon appelle des parties prenantes du systme (voir Figure I.3).
Figure I.3 : Vue globale de la conception d'un systme
Le concepteur est donc en premier lieu inform des besoins des utilisateurs, que ce soit par lintermdiaire dun matre douvrage ou non. A cet ensemble, il doit adjoindre galement ceux des autres parties prenantes. Tous ces besoins vont alors tre tudis et analyss, puis progressivement transforms en une spcification faite dexigences fonctionnelles et non-fonctionnelles qui ne sont rien dautre que des noncs plus ou moins formels des besoins de lensemble des parties prenantes. Peut alors dmarrer la phase dtude fonctionnelle du systme en commenant par une analyse externe, pour ensuite procder une analyse interne qui consiste dcomposer les fonctions en sous-fonctions et dbouche sur larchitecture fonctionnelle du systme. Puis, la conception du systme proprement dit commence par lapproche organique, qui consiste dcouper le systme en autant de sous-systmes que ncessaire et faire des choix dorganes matriels ou de modules logiciels. On obtient alors larchitecture organique du systme, qui peut tre vue comme une solution logique (voir Figure I.4). Pour finir, il reste lapproche physique qui consiste faire des choix dorganes physique pour rpondre larchitecture organique pralablement tablie. Il sagit ici de produire ce que lon nomme : architecture physique du systme. Lensemble compos de larchitecture organique et larchitecture physique runies forme ce que lon appelle la synthse de la solution.
11
Chapitre 1
Figure I.4 : Dmarche gnrale de conception
Lors du dveloppement dun systme complexe, de nombreux domaines doivent travailler ensemble, cooprer et collaborer en vue dobtenir une solution satisfaisante (voir Figure I.5). Nous distinguons 4 domaines principaux : le domaine du besoin, le domaine des gnies, celui des spcialits et celui de la logistique. Typiquement, le domaine du besoin inclus le matre douvrage et les multiples points de vue fournis par les manageurs, les oprateurs ou encore les utilisateurs. Le domaine des gnies est certainement celui qui nous vient le plus rapidement lesprit lorsque nous pensons la construction dun systme technique complexe, car il rassemble les diffrentes comptences : mcanique, thermique, lectrique, logiciel, tlcommunications, etc. Celui des spcialits dites transverses soccupent de toutes les comptences interdisciplinaires, tel que la sret de fonctionnement, la scurit ou encore lergonomie. Le dernier domaine ne pas oublier est celui de la logistique. Il est absolument ncessaire si lon souhaite respecter des dlais ou encore une bonne qualit de service. Il traite notamment des aspects dapprovisionnement, de production, dexploitation, de maintien en condition oprationnel ou de retrait du service.
Figure I.5 : L'Ingnierie Systme fdratrice de domaines
12
Chapitre 1
LIngnierie Systme a alors pour rle de faire cohabiter toutes ces disciplines en les intgrant au sein dun mme ensemble de processus. La tche nest pas vidente, surtout lorsquil sagit de faire communiquer tous les acteurs. Pour cela, il semble ncessaire de sappuyer sur un langage commun. Le moyen le plus sr et qui permet le moins dambigit et de divergence de comprhension reste sans aucun doute lutilisation et le partage de modles [Estefan, 2008]. Le concept de modle reste en fait indissolublement li celui de systme, du fait de la complexit du systme, de son htrognit et de sa pluridisciplinarit, car lesprit humain napprhende la complexit quen la modlisant. En effet, comprendre ou concevoir ne revient qu crer des modles mentaux et agir ou raliser nest rien dautre que de se conformer aux modles que lon a construits. On peut citer 3 types de modles [Verries, 2010] que lAFIS classifie en fonction du rle quils jouent dans la conduite des activits dingnierie systme (voir Figure I.6) : les modles cognitifs : pour lanalyse et lexploration du problme ou du besoin lorigine du systme et pour la validation des concepts oprationnels. les modles normatifs : o de type prescriptif : pour la dfinition des exigences, la formalisation du besoin. o de type constructifs : pour la dfinition des solutions apportes ou envisages au niveau de la conception architecturale du systme. les modles prdictifs : pour prvoir, estimer et valider le comportement du systme vis--vis de ses exigences, laide de modles formels ou de modles analytiques selon les techniques utilises.
Figure I.6 : Typologie des modles en IS (AFIS)
3.4. Ingnierie des exigences

Un point de lIngnierie Systme sur lequel se concentre une partie de notre travail concerne lingnierie des exigences. Cest une part de lingnierie systme trs importante, qui est en charge de soccuper de toutes les activits lies aux exigences telles que leur dfinition, leur traabilit, leur modification, leur gestion en terme de maturit, etc. Nous verrons plus tard en quoi elle est importante pour notre problmatique concernant la conception de systmes srs de fonctionnement. 13
Chapitre 1
La section qui vient sattache donc prsenter les principaux concepts et intrts de cette ingnierie des exigences et commence, en premier lieu, par la dfinition dune exigence.
3.4.1. Dfinition dune exigence

Une exigence correspond une expression de besoin bien formule manant du client ou de toutes autres parties prenantes en lien avec le systme dvelopper. Elle transmet un besoin en fonctionnalit (exigence fonctionnelle) ou en qualit (exigence non-fonctionnelle) que doit satisfaire le produit qui est en train dtre conu. Concernant les exigences nonfonctionnelles, celles-ci peuvent reprsenter : des contraintes globales de qualit de service, des aptitudes du systme (fiabilit, oprabilit, convivialit, ), des contraintes oprationnelles (conformit des normes dutilisation), des contraintes de conception (rutilisation dexistant).
Lintrt principal de transcrire les besoins en exigences rside dans la non-ambigut qui doit en dcouler travers leurs formulations. De plus, cela apporte un bon support de communication entre les diffrentes parties prenantes du projet qui doivent collaborer.
3.4.2. Rle et intrt de lingnierie des exigences

Grer les exigences [Buren & al., 1998] dans un projet est une activit fondamentale son bon droulement. En effet, un nombre important de documents peut tre produit lors de la conception dun systme. Sans lingnierie des exigences, il serait quasiment impossible de garantir la cohrence et la qualit ncessaire au succs du projet. Effectivement, des tudes statistiques ont montr que les exigences interviennent pour environ 40% des succs ou checs dun projet, do leur importance vis--vis de notre proccupation. Ainsi, lingnierie des exigences permet de [Sommerville & al., 1997] : collecter les exigences, faciliter leur expression, dtecter les incohrences entres elles, les valider, grer leur priorit (les hirarchiser), grer les changements dexigences, grer la qualit, faire le lien avec le reste du projet et/ou avec le contexte, et encore assurer leur traabilit.
Lingnierie des exigences doit aussi veiller ce que chaque exigence soit correctement dcline, alloue, suivie, satisfaite, vrifiable, vrifie et justifie. Nous saisissons bien limportance de lingnierie des exigences dans un projet, pour sa russite, et donc pour garantir que le systme conu rpondra bien aux besoins et fonctionnera comme prvu. Tout cart vis--vis du respect des exigences pourra tre lorigine dun fonctionnement non-souhait, do le lien avec notre problmatique. En 14
Chapitre 1
particulier, nous avons constat limportance des exigences lies aux interfaces, qui sont encore trop souvent la cause de problmes de conception, et donc de retards et de surcots. Ci-aprs, nous allons faire un focus sur trois aspects majeurs de lingnierie des exigences : lexpression des exigences, la traabilit et le changement dexigences.
3.4.3. Expression des exigences

Une bonne expression des exigences constitue un point cl de la russite dun projet. Toute ambigut ou tout oubli ce niveau sera source de complication ultrieure, pouvant bien entendu sen suivre de retard, de surcot, de pnalit, etc. Il faut veiller ce que les interprtations que peuvent se faire les diffrentes parties prenantes soient les mmes. Pour cela, il convient dutiliser des termes simples et dviter ceux ambigus ou vagues. Il est aussi recommand de joindre schmas ou modles normaliss qui peuvent clairer lexigence ds que cela est possible. (Nous rappelons ici ladage bien connu : un bon schma vaut mieux quun long discours .) Outre la formulation mme du besoin exprim travers lexigence, celle-ci peut galement tre associe dautres attributs comme : le type (primaire ou drive), le niveau de conformit (obligatoire, conseil ou information), la priorit, la porte (exigence sur le systme lui-mme ou le programme) ou encore ltat (vrifie, valide, ). Toutes ces informations ont leurs importances et doivent tre tenues jour.
3.4.4. Traabilit
La traabilit des exigences [Ramesh & al., 2001] est sans doute le concept le plus important dans lingnierie des exigences. Elle permet de connaitre facilement lorigine des exigences, ainsi que tous les liens entre les exigences elles-mmes ou entre les exigences et le reste du projet ou le contexte (besoins utilisateur, ralisation, tests, ). Dans la littrature [Ramesh, 1998], la traabilit est cite comme facteur de qualit dune bonne conception. Tout dabord dans le but de dcrire les connexions entre les diffrents niveaux dexigences, elle prsente un ensemble davantages qui permettent : de montrer plus facilement que la conception satisfait les exigences et daider identifier rapidement quelles exigences ne sont pas satisfaites par la solution (autrement dit : de vrifier/valider la solution propose), de ne perdre aucune justification vis--vis de choix de conception, de faciliter et matriser lvolution du systme dans le futur, de comprendre limpact dun changement dexigence et de faciliter la prise en compte de lvolution.
3.4.5. Changement dexigences

Le changement dexigences fait partie intgrante de lingnierie des exigences. Il est alors ncessaire de garantir une traabilit, comme nous venons de lexpliquer ci-dessus. Mal suivi, le changement dexigences a souvent t source de graves problmes de conception. Ceux-ci entranent des retards et des surcots nfastes la survie de
15
Chapitre 1
lentreprise, voire mme des dysfonctionnements important du systme portant atteintes la scurit de biens et/ou de personnes. Une bonne ingnierie des exigences, avec une traabilit complte o toutes les informations ncessaires sont prsentes, doit permettre danalyser et de prendre en compte limpact de changements dexigences. Changements qui deviennent dailleurs de plus en plus invitables, dune part, d la complexit des systmes qui impose de faire des hypothses initiales revoir et ajuster plus tard dans le dveloppement, dautre part, d larrive de nouvelles technologies ou plus simplement cause de la rapidit de lvolution du march actuel. Un autre aspect important qui complique encore la tche dingnierie des exigences provient du fait que plusieurs parties prenantes et les diffrents acteurs de la conception interviennent pour dfinir et traiter les exigences. Derrire cette ide, il y a la notion dun travail collaboratif, et donc dune gestion collaborative des exigences. Ceci fait lobjet de nombreux travaux et constitue un domaine de recherche part entire. Pour plus dinformation, le lecteur peut par exemple se rfrer [Konate, 2009] ou [Coulin, 2007].
3.4.6. Quelques outils dingnierie des exigences

Pour finir cette partie sur lingnierie des exigences, nous donnons quelques exemples doutils dingnierie des exigences utiliss dans le monde industriel. Le plus connu est incontestablement lapplication DOORS dIBM. Cest en effet le leader de ce march, utilis par les plus grandes entreprises dans tous les domaines (avionique, spatial, mdical, dfense, ). DOORS permet une structuration des exigences, en associant autant de champs que dsir la dfinition des exigences. Il permet aussi de grer des liens de traabilit entre les exigences, dont la smantique est dfinir par lutilisateur. En rsum, DOORS fournit un environnement complet et collaboratif de gestion des exigences. Mais il existe en fait de trs nombreux autres outils qui permettent de faire de la gestion des exigences, ayant chacun leurs avantages ou leurs inconvnients, en tant plus adapt certains domaines qu dautres. LINCOSE propose dailleurs une liste (nonexhaustive) de ces outils, reprise en Figure I.7 (cf. http://www.incose.org/ProductsPubs/ products/rmsurvey.aspx).
OUTIL Accept Requirements (Accept 360) Acclaro DFSS Version 5 Aligned Elements Version 1.5 (AE 1.5) Avenqo PEP Version 1.2 Blueprint Requirements Center 2010 Cameo Requirements+ Version 4.0 CASE Spec Version 8.15 Cognition Cockpit (Cockpit) Version 5.1 Contour by Jama Software (Contour) Version 2.9 CORE Version 5.1.5 Cradle Version 5.7 Dimensions RM (DimRM) Version 10.1.4 Enterprise Architect Version 7.1 NOM DU VENDEUR Accept Software Axiomatic Design Solutions, Inc. Aligned AG Avenqo Blueprint Software Systems, Inc. No Magic Inc. Goda Software Cognition Corporation Jama Software Vitech Corporation 3SL, Inc. Serena Software Sparx Systems
16
Chapitre 1

Future Tech Systems, Inc. IBM IBM eDev Technologies Visure Solutions Kovair Software, Inc. No Magic Inc. MKS Inc. Viewset Corporation Polarion Software Andromeda s.r.l. e-LM.com Limited SparxSystems Japan Co., Ltd RequirementOne Inc. Geensoft Accord Software and Systems Pvt. Ltd. QAVantage Siemens TraceCloud 4SQ Solutions LLC workspace.com
Envision VIP Version 9 IBM Rational DOORS Version 9.2 IBM Rational RequisitePro Version 7.1 inteGREAT Version 4.7 IRQA Version 4 Kovair Global Lifecycle (Kovair) Version 5.5 MagicDraw and SysML Plugin Version 16.5 MKS Integrity 2009 PACE Version 3 Polarion Requirements Version 2 Project & Test Engineering System (PTESY) Version 5.4 Psoda Version 5.02.1 RaQuest Version 3.0 ReqMan Version 2.0 Reqtify Version 2010-1A Requirements Manager (ReMa) RTIME Version 5 Teamcenter Requirements (Tc RM) Version 8 TraceCloud What To Do Next (WTDN) workspace.com Requirements Management
Figure I.7 : Outils de gestion dexigences (INCOSE)
3.5. Gestion des risques

La gestion des risques est une activit importante pour le bon droulement du projet de conception. Cest une activit dingnierie systme que nous nous devons de prsenter, vu notre problmatique de conception sre de fonctionnement, qui impose une gestion des risques. Ainsi, dans cette section, nous donnons tout dabord la dfinition dun risque et nous justifions lintrt de ltude des risques. Puis nous prsentons les tapes, les stratgies et les outils de la gestion des risques.
3.5.1. Dfinition dun risque

Un risque correspond une perte ou une dgradation potentielle, identifie et souvent quantifiable. Cest un danger ventuel plus ou moins prvisible qui peut affecter lissue du projet. Il est ncessairement li une situation ou une activit et est associ la probabilit de loccurrence dun vnement ou dune srie dvnements. Il peut tre caractris par une grandeur deux dimensions : sa criticit. La Figure I.8 illustre cette caractristique avec : en abscisse : la svrit (ou gravit) des effets et des consquences du risque considr, en ordonne : la probabilit doccurrence du risque.
17
Chapitre 1
Figure I.8 : Criticit des risques
Sur cette Figure I.8, on peut dores et dj identifier la stratgie de rduction du risque qui consiste rduire sa probabilit doccurrence (prvention) et/ou diminuer sa svrit (protection) pour rendre le risque acceptable. En fait, la premire dfinition scientifique du risque a t donne en 1738 par Daniel Bernoulli dans Specimen theoriae novae de mensura sortis [Bernoulli, 1738] : le risque est lesprance mathmatique dune fonction de probabilit dvnements . Plus simplement, il sagit de la valeur moyenne des consquences des vnements pondrs par leurs probabilits. Dans cette dfinition, nous retrouvons bel et bien la notion de probabilit et celle de svrit par lintermdiaire de la valeur reprsentative des consquences des vnements. Mais dautres lments sont associer aux risques comme : les consquences elles-mmes, la stratgie de gestion du risque, loutil employ pour appliquer la stratgie, et bien entendu le ou les facteurs de lapparition du risque.
3.5.2. Pourquoi sintresser aux risques ?

La prise en compte des risques est essentielle pour une bonne conduite de projet. En effet, ils peuvent tre responsables de lchec du projet ou, tout du moins, dune augmentation non ngligeable du cot ou du dlai de dveloppement. Sintresser aux risques permettrait donc dviter ce genre de problmes. Cela permettrait de diminuer le nombre et le cot des accidents, dempcher les accidents handicapants ou mortels, ou plus simplement dviter linsatisfaction du client.
Figure I.9 : 2 familles de risques
Dun point de vue global, on peut identifier deux grandes familles de risques : Les risques prsents lors de lexploitation du systme et directement lis au systme et son fonctionnement. Typiquement, il sagit des risques que la sret de 18
Chapitre 1
fonctionnement va traiter. Par exemple, on retrouve ceux relatifs une dfaillance dun sous-systme ou dun composant, ou encore ceux en rapport avec la protection des personnes utilisant le systme. Les risques lis au projet ou au dveloppement lui-mme. Ils ninterviennent pas directement dans la sret de fonctionnement du systme. En revanche, ils peuvent tre lorigine de risques du premier type. Comme exemple, nous pouvons citer le risque d au retard dun fournisseur ou bien celui caus par la rencontre dune difficult technique plus importante que prvue dans la phase de dveloppement. Ce qui dans les deux cas pourra se traduire par un retard de lachvement de la conception, accompagn ventuellement dune pression plus importante sur les chargs de dveloppement qui peut tre un facteur daugmentation du nombre de fautes de conception (do le lien avec les risques lis au systme et la sret de fonctionnement).
Finalement, nous comprenons bien pourquoi la gestion des risques est une activit importante pour la russite des projets. Vis--vis de notre problmatique, lintrt est vident concernant le premier type de risques (ceux lis au systme), mais ltude des autres risques semble galement d propos la vue de leurs possibles influences. Dans les paragraphes suivants, nous allons tudier plus en dtail cette gestion des risques, en prsentant notamment ses tapes, les stratgies possibles de traitement des risques et les outils appuyant certaines de ces stratgies.
3.5.3. Etapes de la gestion des risques

Comme nous venons de le voir, la gestion des risques est fondamentale, puisque cest elle qui permet de prvoir la survenue du problme, de lincident, de laccident, et de mettre en uvre les actions pour le prendre en compte. Elle se dcompose en grandes tapes, encore appeles phases de la gestion des risques. Identification des risques Dans cette premire tape, il sagit de procder linventaire des risques. Tous les risques doivent tre rpertoris, que ceux-ci soient de type financier, organisationnel, technique ou encore humain. Les sources dinformation possibles pour raliser cette identification des risques peuvent tre des consultations, des archives ou encore des mmoires de projets. Evaluation et classement des risques Aprs la phase didentification des risques, ces derniers doivent tre valus en tenant compte des consquences possibles. Cest cette tape quil est question dvaluer la probabilit du risque et sa svrit, pour en dduire sa criticit. Aprs lvaluation de tous les risques, un classement peut tre tabli en fonction de la criticit associe chaque risque. Il permettra de donnes des priorits aux risques tudier dans ltape suivante. Traitement ou acceptation des risques A cette tape, il sagit de traiter ou daccepter les risques qui ont t identifis et valus lors des phases prcdentes. Typiquement, les risques ayant une forte criticit vont sans 19
Chapitre 1
doute tre traits, tandis que certains risques ayant une criticit faible pourront tre simplement accepts, sans aucune modification. Le paramtre de jugement le plus important qui permettra de choisir entre le traitement ou lacception dun risque correspond trs souvent la diffrence entre le cot des dgts si le risque survient et le cot du traitement du risque. En fait, dans cette phase de traitement ou acceptation, diffrentes stratgies de gestion des risques peuvent tre employes, stratgies qui elles-mmes disposent doutils pour leurs mises en uvre. Nous dtaillons ces stratgies et ces outils dans les paragraphes suivants. Analyse des consquences et suivi En dernire tape, il convient de refaire une analyse en vue de rexaminer les lments impacts par les traitements de risque, principalement pour vrifier si de nouveaux risques ne sont pas apparus. Il sagit galement de commencer un suivi des risques, et plus particulirement un suivi de lvolution de leurs criticits au cours du projet.
3.5.4. Stratgies de la gestion des risques

Comme nous lavons annonc ci-dessus, il existe diverses stratgies pour traiter les risques. Par ordre croissant de cot, on distingue en effet quatre manires de grer les risques : Lvitement Cette stratgie consiste ne pas faire lactivit qui prsente le risque considr. Elle est certes la moins chre et la moins risque du point de vue des dcideurs, mais elle constitue un rel frein au dveloppement de lentreprise. Sans compter que la plupart du temps, elle ne fait que reporter le risque sur dautres entreprises ou le remettre plus tard. Lacceptation La deuxime stratgie de gestion des risques correspond tout simplement lacceptation du risque tel quil est. Ce choix sera fait principalement pour des risques faible criticit, c'est--dire dont la probabilit doccurrence est faible et/ou les consquences du risques sont limites. Malgr tout, cette approche ne permettra jamais de protger le personnel ou les outils de production dans le cas o le risque se produirait. Pour cela, il est ncessaire quune volont de rduction de risque se manifeste. La rduction du risque La dmarche la plus classique de la gestion des risques correspond cette troisime stratgie : la rduction du risque. Lobjectif est de rduire la criticit du risque, ceci en abaissant sa probabilit doccurrence et/ou sa svrit. Le transfert Lorsque lentreprise ne souhaite pas grer un risque (sans quil soit question de laccepter ou non), elle a la possibilit, dans certain cas, de transfrer le risque incrimin. A titre financier, le transfert de risque seffectue lorsque lentreprise contracte une assurance 20
Chapitre 1
ou toute autre forme de couverture de risque financier ou garantie financire. A titre oprationnel et conomique, il a lieu lorsque lentreprise sous-traite lactivit prsentant le risque sous une forme ou une autre (sous-traitance directe, en cascade, cotraitance, externalisation ou outsourcing). Dans ce cas, un sous-traitant srieux et qualifi pourra faire payer trs cher sa prestation ou au contraire dmontrer quil gre mieux le risque pour un prix quivalent voire infrieur. En revanche, le recours un sous-traitant non qualifi ou ddaigneux du risque fera courir un risque encore plus grand.
3.5.5. Outils de la gestion des risques

Pour tre effectivement accomplies, certaines stratgies nonces ci-dessus disposent doutils de la gestion des risques. Il sagit principalement des stratgies de rduction du risque et de transfert, dont nous donnons ici quatre exemples doutils : La prvention La prvention consiste diminuer la probabilit doccurrence du risque en diminuant ou supprimant certains des facteurs du risque. Cet outil correspond une stratgie de rduction du risque et il constitue dailleurs la meilleure manire de grer les risques associs ses propres ressources. Les actions correctives Les actions correctives cherchent diminuer les effets du risque lorsque celui-ci survient. Par exemple, un harnais de scurit sur un chafaudage na aucune influence sur le risque de chute lui-mme, mais diminue fortement les effets de la chute (blessures, fractures, traumatismes,). Lorsquil est impossible dagir sur les facteurs du risque (et donc la probabilit doccurrence), les actions correctives constituent un outil efficace de minimisation dimpact en modifiant les consquences. La diversification Un outil intressant dans certain cas pour la diminution du risque est la diversification. Il sagit de diviser le risque en plusieurs risques plus ou moins indpendant pour ainsi rduire les consquences globales du risque initial. Par exemple, si un retard dans la livraison dun composant par un fournisseur prsente un risque important pour lentreprise, la solution de diversification consiste passer commande non plus auprs dun unique fournisseur, mais auprs de plusieurs fournisseurs. Le palliatif Le dernier outil prsent ici est celui du palliatif, qui permet de conduire des stratgies de transfert. Il consiste profiter de loccurrence du risque , en utilisant son profit lvnement, sans pour autant modifier la probabilit ou les consquences du risque. Un exemple typique de cet outil est celui de lassurance qui couvre le risque en proposant un ddommagement, mais nempche en aucun cas laccident.
21
Chapitre 1
3.5.6. Synthse
Pour rsumer, la gestion des risques est une activit importante pour une bonne russite dun projet de conception. Sans elle, atteindre le but du projet dans les conditions de cots et dlais souhaits devient peu probable. La Figure I.10 reprend les diffrentes notions importantes la gestion des risques sous la forme dun arbre, rappelant les diffrentes phases de la gestion des risques, les principales stratgies possibles de traitement des risques et les outils appuyant ces stratgies.
Figure I.10 : Arbre de la gestion des risques
Ltendue de la gestion des risques permet aussi bien de soccuper des risques en rapport avec le droulement de la conception que ceux prsents lors de lutilisation du systme. Ce sont dailleurs ces derniers risques, lis au systme, qui pourront devenir des donnes dentre pour des tudes de sret de fonctionnement du systme. Les attributs des risques sont galement reprsents sur la Figure I.10. Parmi les entraves de la gestion des risques figurent aussi les dangers et les accidents, o : Un danger dfinit une proprit intrinsque une substance, un systme technique, une disposition (lvation dune charge), , un organisme, etc., de nature entraner un dommage sur un lment vulnrable. Un accident est un vnement alatoire, fortuit, qui entrane des dommages vis-vis des personnes, des biens ou de lenvironnement ou qui entrane un engagement de responsabilit.
Ainsi, un risque fait le lien entre un danger et un accident dans le sens o il correspond la possibilit de survenance dun accident rsultant dune exposition aux effets dun phnomne dangereux. Par analogie avec les entraves de la trilogie de la sret de fonctionnement (fautes, erreurs et dfaillances), la chane dapparition est ici la suivante : danger risque accident.
22
Chapitre 1
Dans la partie suivante, nous abordons un domaine de lingnierie qui est la sret de fonctionnement, sattachant ltude des risques associs au systme concevoir.
4. Sret de fonctionnement
4.1. Historique
Les problmes de Sret de Fonctionnement [Lannoy, 2008] existent depuis trs longtemps, ds quun systme a pu dfaillir ou tomber en panne. Mais au dpart, aucune tude spcifique de Sret de Fonctionnement ntait applique. Cest dans les annes 1930 que la premire collecte dinformations statistiques sur des moteurs et des accidents dappareils a t conduite dans le secteur du transport arien. Entre 1939 et 1942, on a vu apparatre les tous premiers objectifs quantifis donns par le capitaine A.F. Pugsley de la 7me brigade dinfanterie canadienne. Il valua des taux de dfaillances hauteur de 10-5/h pour les avions et 10-7/h pour leurs structures. Puis dans les annes 1940, des techniques de fiabilit commencrent se dvelopper, avec notamment la conception des V1 en Allemagne ou encore celle des moteurs de traction des locomotives aux Etats-Unis. Dans les annes 1950, le concept de maintenance [Jardine, 1987] fait son apparition. On assiste galement aux toutes premires tudes sur la fiabilit humaine pour les nouvelles centrales nuclaires. A la mme poque, des travaux de recueil de donnes de fiabilit lectronique sont entams. A partir de 1960, les industries aronautiques et spatiales firent des analyses relatives aux dfaillances de composants. Le dpartement de la dfense amricain (DoD) promulgua les premires vraies exigences de Sret de Fonctionnement suite des accidents sur missiles. En 1961, les laboratoires Bell utilisent le nouveau concept darbre des causes sur le projet du missile Minuteman [Watson, 1961]. Cette technique va directement tre reprise par Boeing. En France, la mthode des combinaisons de pannes est utilise sur le projet Concorde, puis sur Airbus. En 1962, lAcadmie des Sciences accueille le mot fiabilit dans sa terminologie. A partir de 1970, les premiers travaux sur la fiabilit des logiciels [Ledoux & al., 2007] commencent et de nombreuses tudes sont menes dans le domaine du nuclaire. Nous pouvons citer, par exemple, le rapport amricain Rasmussen [Rasmussen, 1975] sur les risques nuclaires des centrales de Surry 1 et Peach Bottom 2. En 1979, la catastrophe nuclaire de Three Miles Island [Rogovin, 1979] motive encore plus le dveloppement doutils de Sret de Fonctionnement. Puis, progressivement, les techniques de Sret de Fonctionnement vont largement se diffuser et stendre de plus en plus de domaines : la chimie, le ferroviaire, lautomobile, le traitement et lpuration de leau, et lensemble des grands secteurs industriels. Aujourdhui, des rglementations et des certifications imposent lutilisation doutils ddis la sret de fonctionnement (cf. chapitre 2 pour des exemples de normes de sret). 23
Chapitre 1
Elles induisent aussi une certaine ide de la couverture du risque. En effet, on prfre dornavant parler de tort ou de responsabilit dans les procs qui font suite des accidents, la place de la notion de risque. Pourtant, le risque existe toujours. Paralllement, la comptitivit croissante force les entreprises adopter la productivit la meilleure possible, et donc rduisent au maximum les arrts de production et maximisent la disponibilit de leurs quipements. Pour conclure ce rapide historique de la sret de fonctionnement, nous pouvons dire quaujourdhui la scurit des biens et des personnes na jamais t aussi importante, phnomne accru par la pression mdiatique et cologique autour des accidents majeurs.
4.2. Concepts et dfinitions

La Sret de Fonctionnement est, comme nous lavons aperu dans le paragraphe qui traite de lintgration de domaines par lingnierie systme, une spcialit dite transverse. Elle concerne tous les domaines techniques, tous les gnies. Elle a pour finalit le maintien du bon fonctionnement d'un systme, d'un produit ou d'un de ses constituants, dans le temps, tout au long de son cycle de vie. La sret de fonctionnement est perue travers diffrents attributs : la fiabilit, la maintenabilit, la disponibilit, ou encore la scurit. Son tude est devenue fondamentale pour les systmes critiques, o un dysfonctionnement peut engendrer un risque humain ou financier important. Elle sapplique galement aux systmes dinformation, o l encore un dysfonctionnement peut causer un risque financier consquent, mais galement un risque social. J.C. Laprie [Laprie & al., 1995] a dfini la sret de fonctionnement dun systme comme tant la proprit qui permet ses utilisateurs de placer une confiance justifie dans le service quil leur dlivre , o un utilisateur est un autre systme (humain ou physique) qui interagit avec le systme considr et o le service dlivr est le comportement du systme tel que peru par ses utilisateurs. Un bon moyen pour prsenter la sret de fonctionnement est de sappuyer sur larbre de la sret de fonctionnement [Avizienis & al., 2001], [Avizienis & al., 2004], prsent en Figure I.11.
Figure I.11 : Arbre de la Sret de Fonctionnement
24
Chapitre 1
Ainsi, la sret de fonctionnement possde diffrents aspects : ses attributs, sur lesquels un concepteur mettra plus ou moins laccent suivant le type dutilisation du systme : le fait dtre prt lutilisation conduit la disponibilit, la continuit du service conduit la fiabilit, la non-occurrence de consquences catastrophiques pour lenvironnement conduit la scurit-innocuit, la non-occurrence de divulgations non-autorises de linformation conduit la confidentialit, la non-occurrence daltrations inappropries de linformation conduit lintgrit, laptitude aux rparations et aux volutions conduit la maintenabilit.
La Sret de Fonctionnement vise principalement rduire le plus possible le nombre de dfaillances dun systme. Autrement dit, elle fait en sorte que le systme dlivre au maximum les services normalement prvus, sans quils dvient de leurs objectifs respectifs. Or, il est possible que des erreurs viennent perturber le bon fonctionnement du systme et fassent dfaillir le systme. On dfinit dailleurs une erreur comme la partie de ltat du systme susceptible dentraner une dfaillance. Ces erreurs proviennent de ce que lon appelle des fautes, lorsque ces dernires ont t actives. Ces fautes peuvent tre de nature trs diverses : suivant la phase de conception : fautes de dveloppement ou fautes oprationnelles, suivant la frontire du systme : fautes internes ou fautes externes, suivant leur localisation : fautes matrielles ou fautes logicielles, suivant leur cause phnomnologique : fautes naturelles ou fautes dues lhomme, suivant les intentions en jeu : fautes non malveillantes ou fautes malveillantes, suivant les capacits en jeu : fautes accidentelles, fautes dlibres ou fautes dincomptence, suivant leur persistance : fautes permanentes ou fautes temporaires (voire furtives).
La sret de fonctionnement met disposition diffrents moyens pour limiter la prsence de fautes, et donc viter loccurrence de dfaillances : la prvention des fautes : qui sattache empcher loccurrence ou lintroduction de fautes, la tolrance aux fautes : qui fait en sorte que le systme dlivre toujours un service acceptable, mme en prsence de fautes, llimination des fautes : qui veut rduire la prsence (nombre, svrit) des fautes, la prvision des fautes : qui cherche estimer la prsence, la cration et les consquences des fautes.
Pour rsumer, les attributs de la sret de fonctionnement disponibilit, fiabilit, scurit-innocuit, confidentialit, intgrit et maintenabilit correspondent aux proprits du systme lies la sret de fonctionnement. Ils permettent dapprcier la 25
Chapitre 1
qualit du systme vis--vis des services dlivrs. Les entraves la sret de fonctionnement fautes, erreurs et dfaillances (cf. Figure I.12) sont les circonstances indsirables causes ou rsultats de la non-sret de fonctionnement du systme. Pour combattre ces entraves et atteindre les niveaux souhaits des attributs, les moyens de la sret de fonctionnement vont tre sollicits : la prvention des fautes, la tolrance aux fautes, llimination des fautes et la prvision des fautes.
Figure I.12 : Relation faute-erreur-dfaillance
Bien souvent, la sret de fonctionnement fait dornavant lobjet dune validation par un organisme extrieur et indpendant de la structure qui a dvelopp le systme, surtout lorsque des vies humaines sont en jeu. Dans certains secteurs dactivit (comme dans laronautique par exemple), il est question de certification, qui est un contrle de qualit bas sur des normes. LAFNOR dfini dailleurs la certification comme la reconnaissance, par un organisme indpendant du fabricant ou du prestataire de service, de la conformit d'un produit, service, organisation ou personnel des exigences fixes dans un rfrentiel.
4.3. Quelques mthodes de sret de fonctionnement

Les principales mthodes de sret de fonctionnement consistent en des analyses des dfaillances du systme, de ses sous-systmes et de ses composants pour dterminer leurs causes et estimer leurs consquences sur le service rendu par le systme. Ces analyses peuvent tre qualitatives ou quantitatives, et elles se conforment lune des deux approches suivantes : Lapproche inductive : qui correspond un raisonnement du particulier vers le gnral, o lon recherche les effets dune dfaillance sur le systme ou son environnement. Lapproche dductive : qui correspond un raisonnement du gnral vers le particulier, o lon recherche les causes possibles dune dfaillance.
Nous prsentons ci-dessous quelques mthodes classiques de la sret de fonctionnement. Lobjectif nest pas dtre exhaustif. Pour une revue complte des diffrentes mthodes de sret de fonctionnement, le lecteur est invit consulter [Villemeur, 1988], [Aldemir & al., 2006] ou encore [M2OS, 2010]. Blocs Diagrammes de Fiabilit (BDF) : mthode graphique servant visualiser les sous-ensembles dun systme pour en faire apparatre la faon dont ils contribuent aux diffrentes fonctions du systme. Elle montre notamment les redondances, les lments qui contribuent une mme fonction et les lments de secours ncessaires. Elle sert de base des analyses de fiabilit, de scurit, de maintenabilit et de disponibilit. Allocation de fiabilit : pour dcliner les objectifs de fiabilit spcifis au niveau dun produit complexe (par exemple le systme) en objectifs applicables diffrents niveaux de larborescence technique ou fonctionnelle du produit.
26
Chapitre 1
Evaluation prvisionnelle de fiabilit : pour valuer et affiner, avec un degr de prcision croissant avec lavancement du projet, la fiabilit du produit laide de techniques et de donnes voluant avec les progrs de la conception et lacquisition de rsultats dessais. Elle constitue une base importante pour lorientation des choix de conception. FIDES : Pour estimer la fiabilit des composants, cartes lectroniques ou sousensembles sur tagres (COTS : Component Of The Shelf). Estimations de fiabilit partir dessais ou de retour dexprience : pour dterminer les paramtres de lois de fiabilit partir de donnes traites de retour dexprience ou dessais. Fiabilit prvisionnelle en mcanique : pour estimer la fiabilit des composants mcaniques en prenant en compte les modes de dfaillance particuliers (rupture, dformation, grippage, bruyance) lis la fatigue, lusure et au vieillissement. Fiabilit en mcanique la mthode contrainte-rsistance : pour valuer la fiabilit dune pice mcanique soumise des contraintes. Mthode danalyse de la SdF du logiciel : par les normes, par les spcifications, par les moyens ou par lanalyse. Il sagit de construire la sret de fonctionnement (fiabilit, scurit), analyser et valuer loccurrence de bogues dun logiciel et si possible le plus tt dans le dveloppement dun nouveau logiciel. Analyse prliminaire de risques (APR) (Preliminary hazard analysis (PHA)) : pour identifier les points du systme qui peuvent tre critiques pour la scurit, valuer les risques correspondants, les scnarios associs et dfinir les critres de conception appliquer [Desroches & al., 2009], [Mortureux, 2002]. Analyse des Modes de Dfaillance et de leurs Effets (AMDE) (Failure Modes and Effects Analysis (FMEA)) et Analyse des Modes de Dfaillance, de leurs Effets et de leur Criticit (AMDEC) (Failure Modes, Effects and Criticity Analysis (FMECA)) : mthodes danalyse inductive et rigoureuse ayant pour buts didentifier les dfaillances dont les consquences peuvent affecter le fonctionnement dun systme, et pour lAMDEC de les hirarchiser selon leur niveau de criticit afin de les matriser [Faucher, 2004], [Faucher, 2009], [Landy, 2007]. Mthode de l'Espace des Etats: pour valuer les principales caractristiques de fiabilit et de disponibilit dun systme rparable. Analyse par arbre de dfaillances (AdD) (Fault Tree Analysis (FTA)) : permet une analyse dductive des causes techniques ou oprationnelles pouvant provoquer des situations contraires un objectif spcifi, en particulier, de scurit (situation redoute) ou de disponibilit (vnement indsirable) [Lee & al., 1985], [Vesely & al., 1987]. Analyse par arbre dvnements (AAE) (Event Tree Analysis (ETA)) : permet didentifier et dvaluer les consquences possibles dun vnement initiateur selon les circonstances ou dysfonctionnements avec lesquels il se combine.
27
Chapitre 1
Analyse par arbre de causes : pour runir dans une reprsentation synthtique et logique tous les lments ayant contribu un incident avr. Arbres de Maintenance et dAptitude la Maintenance : fournit le moyen de dfinir, doptimiser et dactualiser la politique de maintenance des outils de production. Hazard and Operational Study (HAZOP) : pour examiner en dtail les composants dun systme et dterminer ce qui se produirait si ce composant devait fonctionner en dehors de son mode normal dutilisation. Analyse des Risques, PoInts Critiques pour leur Matrise (ARPIC-M) (Hazard Analysis Critical Control Point (HACCP)) : est un moyen de garantir la salubrit des aliments. Il repose sur la prvision et la prvention des dangers biologiques, chimiques et physiques. La simulation de Monte Carlo : La simulation de Monte Carlo [Batut, 1986], [Dubi, 2000] est une technique utilise pour estimer la probabilit de rsultats en rptant un grand nombre de fois une exprience laide de la simulation et en utilisant des nombres alatoires. Cest une mthode qui a pour but dimiter un systme rel. Analyse de zone : pour mettre en vidence les problmes rsultant des interactions physiques entre lments voisins ou de flux perturbateurs gnrs par des sources externes. Maintenance Base sur la Fiabilit (MBF) (Reliability Centered Maintenance (RCM)) : pour optimiser la maintenance tout en matrisant la scurit, la disponibilit et la dure de vie dun quipement. Intgration Conception et Soutien (ICS) : pour aider la dcision et la slection dune solution prfrentielle pour la conception dun matriel durable et rparable, compte tenu de critres de cot, de disponibilit et defficacit. Plans dexpriences : pour permettre aux concepteurs de matriser les paramtres de conception, laide dun nombre minimal dessais. Le rglage de ces paramtres permet doptimiser les performances du produit ou des procds et/ou de rduire leur sensibilit aux diffrentes sources de variabilit. Essais acclrs de dure de vie : pour prdire, de manire conomique et sur un laps de temps rduit, lvolution dans le temps dune (ou plusieurs) performance(s) fonctionnelle(s) ainsi que la dure de vie dune entit matrielle utilise dans ses conditions normales demploi, partir dessais raliss sous des valeurs de contraintes suprieures aux niveaux spcifis en utilisation normale. Essais aggravs : pour explorer les marges de fonctionnement dun produit en dveloppement et dceler au plus tt, pour pouvoir les corriger, les dfauts inhrents la conception (produit et procds) qui rduisent ces marges des valeurs juges insuffisantes.
28
Chapitre 1
Epreuves de dverminage : pour faire apparatre les dfauts de jeunesse dun produit afin de les corriger avant livraison. Elles consistent soumettre les exemplaires dun matriel en sortie de production des cycles de contraintes adaptes (lectriques, mcaniques, thermiques...) visant prcipiter les dfauts latents en dfauts patents (observables). Logique de traitement des incidents et actions correctives (LTI-AC) (Failure report and corrective Action System (FRACAS)) : pour fournir toutes les informations requises pour identifier les causes de dysfonctionnements dun produit manifestes au cours de son dveloppement ou de son utilisation en vue dapporter, en temps et en heures, les actions correctives appropries. Cot de Cycle de Vie (CCV), Cot global de possession (CGP) (Lyfe Cycle Cost (LCC)) : vise loptimisation prvisionnelle et la matrise du cot global de possession dun produit, dune machine ou dune installation. Cest une donne conomique destine faciliter les choix stratgiques de conception et de dveloppement du produit ainsi que le contrle de sa gestion. Cette analyse permet dorienter les tudes de sret de fonctionnement, les tudes de maintenance et de soutien logistique intgr. Louvrage [Villemeur, 1988] dresse un tat de lart complet des mthodes de sret de fonctionnement. Des techniques plus rcentes dvaluation de la sret de fonctionnement des systmes dynamiques peuvent tre consultes dans [Khalfaoui, 2003], [Sadou, 2007] et [Aldemir & al., 2006].
4.4. Enjeu de la sret de fonctionnement

Plus une erreur de conception est dcouverte tardivement, plus le risque technique induit peut tre lourd et entraner des surcots et des retards considrables pour le projet. Lapparition du risque peut notamment conduire la mise en cause de la scurit des personnes et des biens, la dgradation de lenvironnement, la perte de fonctions ou tout simplement la dgradation de limage de marque. Lenjeu de la sret de fonctionnement est donc didentifier les risques au plus tt dans la phase de dveloppement du produit. Comme nous lavons dj vu, la sret de fonctionnement est une activit dingnierie systme. Elle peut tre qualitative ou quantitative. La part qualitative correspond loptimisation des tudes et elle reprsente environ 70% de lactivit totale. Les 30% restants reprsentent la partie quantitative consacre la matrise des risques avant fabrication partir des architectures dj labores. Cest donc une phase doptimisation des architectures des systmes et de leur mise en uvre de faon maximiser, moindre cot, leur robustesse aux alas. En rsum, lanalyse de la sret de fonctionnement est une action de rduction des risques et donc du cot lachvement. Elle sexerce essentiellement pendant les premires phases des projets, jusqu la mise en production.
29
Chapitre 1
5. Sret de fonctionnement des systmes complexes

La sret de fonctionnement des systmes complexes ne va pas de soi et ncessite une prise en compte particulire. Dans ce paragraphe, nous citons quelques exemples de catastrophes ou dchecs de systmes qui nont pas fonctionn correctement. Puis nous rsumons les origines des problmes de sret de ces systmes complexes, pour dboucher sur le constat quune approche de prise en compte globale de la sret est ncessaire.
5.1. Exemples dchecs

5.1.1. Navette spatiale Challenger
Le 28 janvier 1986, la navette spatiale amricaine Challenger de la NASA se dsintgra environ 70 secondes aprs son dcollage. Lorigine du problme qui conduisit la catastrophe venait dun joint dtanchit du propulseur dappoint poudre droit, adjacent au rservoir externe de la navette, qui ntait pas conu pour les conditions climatiques du jour du lancement. Plusieurs ingnieurs avaient pourtant exprim leur proccupation quant leffet de la temprature sur la rsistance des joints toriques en caoutchouc qui permettaient de sceller les joints du propulseur poudre. En effet, sil faisait plus froid que 11,7C, il ny avait plus aucune garantie dtanchit. Cette considration tait importante, car les joints toriques taient reprs comme des composants dun niveau critique 1 . Cest--dire que sils ne fonctionnaient pas de manire optimale, cela dtruirait la navette et son quipage. Ce risque, pourtant connu des dirigeants de la NASA depuis 1977, a t nglig pour ce dcollage, car jug non suffisamment tabli au regard des enjeux politiques de ce vol en particulier (une enseignante choisie aprs une slection sur lensemble du pays faisait partie de lquipage). Ainsi, alors que la temprature tait de -13C avant le dcollage, lautorisation de mise feu a tout de mme t accorde. Le joint dfailli. Une fuite de gaz brlant provoqua un dpart de flamme qui endommagea le rservoir principal rempli dhydrogne, la structure du rservoir cdant sous leffet de la chaleur. Le dme infrieur du rservoir dhydrogne se spara et heurta la partie suprieure du rservoir doxygne. Au mme moment, le propulseur dappoint poudre pivota et percuta la structure inter-rservoir. Sen suivi la dsintgration complte du rservoir, puis de la navette qui subit un facteur de charge denviron 20g, bien suprieur ses tolrances.
5.1.2. Ariane 5
Le 4 juin 1996 a eu lieu le vol inaugural du lanceur Ariane 5 de la socit Arianespace. Mais 40 secondes aprs le dcollage, le lanceur dvie de sa trajectoire et explose. En fait, lerreur qui a conduit la catastrophe provient de la rutilisation dun composant logiciel dAriane 4 pour Ariane 5 : le programme de contrle de la vitesse horizontale de la fuse. Mais comme la trajectoire dAriane 5 est diffrente de celle dAriane 4, une des variables du programme qui avait un domaine de variation fix a dpass sa plage de valeurs avec Ariane 5. Ce qui a entrain une succession derreurs qui a conduit la destruction du 30
Chapitre 1
lanceur. Cette erreur aura cot 500 millions de dollars uniquement en matriel, sans parler des retards engendrs et des consquences sur limage de marque dArianespace.
5.1.3. Mars Polar Lander

Mars Polar Lander tait une sonde spatiale destine lobservation et lanalyse du sol martien. Elle faisait partie du programme Mars Surveyor de la NASA. La sonde fut perdue lors de son entre dans latmosphre martienne le 3 dcembre 1999. Elle tait quipe de pieds pour latterrissage, sur lesquels taient disposs des capteurs. Lis un calculateur, ceux-ci permettaient de dtecter limpact avec le sol afin de couper les moteurs. Mais lors du dploiement des pieds de la sonde, les vibrations engendres et perus par les capteurs furent mal interprtes par le logiciel de bord, qui considra que la soude tait arrive sur le sol martien. Les moteurs destins freiner la descente de la sonde furent coups prmaturment, alors quelle tait encore une quarantaine de mettre du sol. Mars Polar Lander impacta alors la surface une vitesse de 22 mtres par seconde et fut dtruite.
5.1.4. Plate-forme ptrolire BP

Une plateforme ptrolire de British Petroleum (BP), appele Deepwater Horizon, a explos le 20 avril 2010. Cette catastrophe a caus une mare noire de trs grande ampleur dans le Golfe du Mexique, ainsi que 11 dcs, 17 blesss et le naufrage de la plateforme. Concernant les raisons de cet accident, les spcialistes de BP pensent quune dizaine de causes majeures sont entres en jeu. Le premier problme concerne un anneau en ciment qui devait empcher les infiltrations indsirables dhydrocarbures dans le tubage du puits. Selon la BP, le paraptrolier Halliburton charg de la confection de cet anneau aurait coul un ciment nonconforme aux caractristiques du puits Macondo. Ainsi, le coulis na pas rempli son rle dobstacle et de lhuile et du gaz ont pu remonter vers la plateforme. Ensuite, peut-tre sous leffet dun relchement dazote, le verrou suivant (appel Shoe Track) na pas fonctionn non plus. Les raisons de ce dysfonctionnement ne sont toujours pas expliques la date o ces lignes sont crites. Paralllement, dans la matine du 20 avril, des techniciens ralisent des tests de pression afin de confirmer lintgrit du puits. Aprs lanalyse des donnes, BP estime quau moment o ces tests sont raliss, cette intgrit du puits nest absolument pas dmontre, ce qui aurait d suffire pour interrompre les oprations. Mais cela na pas t le cas, car les rsultats des tests ont t dclars positifs et, bord, les techniciens de BP ont approuvs. Faute toute aussi grave, les techniciens et ingnieurs de Transocean et Sperry nont pas vu, sur leurs appareils de mesure, que le flexible reliant le puits la plateforme tait envahi dhydrocarbures. Or, le guide de contrle des puits de Transocean stipule que ce flexible doit faire lobjet dune surveillance de tous les instants.
31
Chapitre 1
Suite cette accumulation de fautes et derreurs, les ractions correctives tardives nont pu empcher la catastrophe. Pour tenter de faire retomber la pression des hydrocarbures, les techniciens avaient orient le flux dhuile et de gaz vers un dgazeur situ sur la plateforme. Le souci est que ce dispositif qui spare le liquide du gaz nest pas conu pour traiter dimportants volumes. En effet, le gaz schappe dans latmosphre, un trop important nuage dhydrocarbure se forme alors au-dessus de Deepwater Horizon. La plateforme nayant pas t conue pour une telle situation, les installations lectriques ont provoqu les explosions. En dehors des pertes humaines importantes causes par ces dflagrations, les explosions dconnectent aussi les cbles lectriques qui relient la plateforme un dispositif de fermeture du puits. Les hydrocarbures continuent donc dalimenter lincendie qui ravage la plateforme. Tous les espoirs restants rsident alors dans le systme de fermeture automatique qui doit sactiver de lui-mme en cas dincident srieux. Hlas, aucun des deux systmes de commande na fonctionn : le premier cause de sa batterie plat et le second en raison dune valve dfectueuse. Fautes de conceptions, non-respect des rgles de scurit, maintenance approximative, la liste des fautes commises par les oprateurs de Deepwater Horizon a, semble-t-il, t bien longue. Selon BP, ce furent les pratiques de ses prestataires qui constituaient les causes principales...
5.2. Origines des problmes de sret de fonctionnement

Dans les accidents du paragraphe prcdent, il savre que les composants ntaient pas dfaillants en termes de non-satisfaction des exigences pour lesquelles ils ont t conus. Les composants ont fonctionn exactement comme cela tait prvu. Les problmes proviennent des effets imprvus ou mal compris des comportements des composants sur le systme dans son ensemble. Ces erreurs sont des erreurs dans la conception du systme plutt que dans la conception des composants (y compris lanalyse de la sret de ces composants). Notamment, il sagit derreurs dans lattribution et la traabilit des fon ctions globales du systme au niveau des composants individuels. En fait, laugmentation de la taille et de la complexit des systmes actuels rend les processus de conception de plus en plus difficiles. Les changements apports aux systmes au fil des annes font apparatre des limites des approches et techniques relatives la sret. Ils concernent : Des volutions technologiques rapides, Des changements dans la nature des accidents, De nouveaux types de dangers, Une augmentation de la complexit et de lhtrognit, Une relation plus complexe entre lhumain et lautomatisation, Un changement de la vision des organismes de rgulation et des simples utilisateurs sur la sret.
32
Chapitre 1
Ces changements reprsentent un challenge pour tous les acteurs acadmiques et/ou industriels pour la dfinition de nouveaux processus, mthodes et outils danalyse et dvaluation de la sret. Rasmussen [Rasmussen, 1997] a par exemple montr que la majorit des accidents sont souvent causs non pas par la composition de dfaillances indpendantes mais reflte plutt dune migration systmatique du comportement organisationnel vers les limites dun comportement sr. Ceci est principalement d aux pressions sur les cots et sur lefficacit exige dans un environnement de plus en plus comptitif. Somme toute, les faiblesses des processus actuels danalyse et dvaluation de la sret peuvent tre rsumes par les points suivants (liste non exhaustive) : Lanalyse de la sret comporte un certain degr intrinsque dincertitude. Ainsi, il existe un degr de subjectivit dans lidentification des problmatiques de sret. Diffrents groupes ont besoin de travailler avec diffrentes vues du systme (vue dingnieur systme et vue dingnieur de sret par exemple). Gnralement cest un atout, mais cela peut tre une barrire quand les vues sont incohrentes. Mauvaise dfinition des exigences de sret et de leur formalisation. Absence de traabilit des exigences de sret. Les mthodes existantes (traditionnelles) sont insuffisantes vu la complexit des systmes actuels. La description textuelle des modes de dfaillance est souvent ambige. Absence de langage commun entre les diffrents mtiers concerns par le systme. Besoins mal spcifis ou exigences mal formules. Evolution des besoins/exigences dans le temps et mauvaise gestion du changement. Modification spontane, parfois faite avec de bonnes intentions. Non accumulation de savoir-faire et manque de retour dexprience. Pari technologique trop important. Dfinition errone dinterface. Forte pression de la concurrence. Extension dexigences fonctionnelles.
Nous constatons que les problmes de sret de fonctionnement des systmes ne proviennent pas ncessairement dune mauvaise analyse ou mauvaise estimation des attributs de sret (fiabilit, maintenabilit, disponibilit, scurit, confidentialit, intgrit), mais de nombre dautres aspects lis aux projets et la dmarche de conception. Comme exemple nous pouvons citer : la gestion des donnes, les mcanismes de traabilit, la gestion de configuration, la gestion des risques, la dfinition dinterface, la formulation dexigence, etc. Ainsi, la sret de fonctionnement passe certes par lensemble de ces attributs, mais est galement sous linfluence dun certain nombre daspects contributeurs . Ces lments participent indirectement la sret de fonctionnement du systme, et cest dailleurs en grande partie eux que le travail prsent dans ce mmoire sadresse. La Figure I.13 cidessous prsente une vue conceptuelle de la sret de fonctionnement, de ses attributs, ainsi que de quelques-uns des aspects contributeurs, ceci en adoptant une reprsentation 33
Chapitre 1
sinspirant du building-block dune norme dIngnierie Systme, lEIA-632, que nous verrons plus loin (Systme = Systme produit + produits contributeurs).
Figure I.13 : Sret de fonctionnement et aspects contributeurs
5.3. Ncessit dune approche globale

En analysant les faiblesses rpertories dans le paragraphe prcdent, nous constatons que certains points sont dus labsence dune approche globale dvaluation de la sret. En effet, les proprits de sret sont des proprits mergentes qui rsultent dinterdpendances existant dans le systme et dans linteraction avec son environnement. Il est absolument ncessaire que ces proprits soient tudies globalement au niveau du systme complet si lon souhaite quelles soient respectes. De surcroit, ces proprits importantes du systme doivent tre considres ds le dbut de la conception. En effet, elles ne peuvent pas tre introduites ou seulement mesures a posteriori, et doivent tre traites le plus tt possible pour limiter leurs impacts sur les dlais et les cots de conception. Une solution pour prendre en compte efficacement les proprits de sret est donc la proposition dune approche globale pour lanalyse et la gestion de ces dernires. Lingnierie systme qui est un cadre mthodologique pour la conception des systmes complexes constitue un cadre cohrent et complet pour cette fin. Ce cadre est donc considr dans notre travail et une approche de prise en compte de manire efficace de la sret est dveloppe. Nous avons vu plus haut que lun des processus de lingnierie systme est lingnierie des exigences [Sommerville, 2006]. Lingnierie des exigences est souvent considre dans la littrature comme le processus le plus critique dans le dveloppement dun systme complexe [Juristo & al., 2002], [Komi-Sirvio & al., 2003]. Elle peut tre divise en deux groupes principaux d'activits [Parviainen & al., 2004] : Le dveloppement des exigences : cette activit inclut les processus dlicitation [Goguen & al., 1993], de documentation, danalyse et de validation des exigences. La gestion des exigences : cette activit inclut les processus de gestion de la maintenance, de gestion des changements et de gestion de la traabilit des exigences [Gotel & al., 1994], [Sahraoui, 2005].
34
Chapitre 1
Cest aussi sur cet aspect dingnierie des exigences que notre travail sappuie fortement. Il faut effectivement accorder une attention particulire la dfinition et au dveloppement des exigences de sret, mais aussi leur gestion.
6. Conclusion
Suite la dfinition des systmes complexes et de la notion de proprit mergente, lingnierie systme a t prsente dans ce premier chapitre, en dtaillant lingnierie des exigences et la gestion des risques. Nous avons poursuivi par la prsentation du domaine de la sret de fonctionnement, qui fait partie de nos domaines dintrt. Pour finir le chapitre, nous nous sommes penchs sur la sret de fonctionnement des systmes complexes. Cette dernire section a permis dexprimer la problmatique gnrale du travail de thse en se basant sur lorigine des problmes de sret de fonctionnement des systmes complexes. Nous avons alors conclu quil tait ncessaire de dfinir une approche globale pour la prise en compte de la sret de fonctionnement en lintgrant dans les processus dingnierie systme. Le chapitre suivant sera consacr la prsentation de cette approche.
35
Chapitre 1
36
Chapitre 2
Dmarche processus propose
II.
Chapitre 2 : Dmarche processus propose

1. Introduction
Le premier chapitre nous a permis didentifier la ncessit dune approche globale pour la prise en compte de la sret de fonctionnement pour lingnierie des systmes complexes. Ce deuxime chapitre est ddi la proposition dune dmarche globale de prise en compte de la sret de fonctionnement rpondant cette problmatique. Pour cela, nous faisons dans un premier temps un tat de lart sur le sujet, incluant tant des normes de sret et des projets, que des travaux de recherche acadmiques. Nous rsumons et synthtisons dans cette section les diffrents travaux, dont la plupart utilise une vision processus, puis en faisons un bilan. Ensuite, nous posons la base de notre travail en introduisant la vision processus des activits dingnierie systme et les normes dingnierie systme. En particulier, nous dtaillons la norme EIA-632 que nous utilisons. Enfin, nous terminons le chapitre par la prsentation de notre dmarche processus pour prendre en compte la sret de fonctionnement.
2. Etat de lart pour une conception de systmes srs

Pour commencer, cette section propose un tat de lart relatif la problmatique dune conception de systmes complexes srs de fonctionnement. Tout dabord nous voquerons quelques normes de sret, puis nous citerons les grands projets en rapport avec le travail et finirons par deux exemples de travaux de recherche dans le domaine.
2.1. Normes de Sret

2.1.1. CEI-61508 et ses drives
La norme CEI-61508 [CEI-61508, 2010] est une norme gnrique de sret de fonctionnement du CEI (International Electrotechnical Commission). Elle est utilise comme rfrentiel par tous les grands secteurs industriels. Elle traite de la scurit fonctionnelle des systmes lectriques/lectroniques et lectroniques programmables (E/E/PE). En fait, cette norme a rvolutionn le monde de la sret de fonctionnement, car elle a su amener des nouveauts dans la faon dintgrer et de raliser les activits de sret de fonctionnement dans le cycle de dveloppement dun systme E/E/PE. Entre autres, la norme a permis de dfinir des niveaux dintgrit pour des systmes E/E/PE qui prennent 37
Chapitre 2
en compte aussi bien les aspects quantitatifs que qualitatifs dans la gestion du risque. La norme intgre les activits de scurit en les adaptant en fonction des niveaux dintgrit de la scurit souhaits (connus sous le nom de SIL : Safety Integrated Level). Par son aspect gnrique, la norme CEI 61508 reste brve sur la description des outils, mthodes et les techniques mettre en uvre. Mais depuis sa cration, plusieurs drivs de cette norme ont vu le jour dans le but de la rendre applicable pour les diffrents secteurs concerns (voir Figure II.1).
Figure II.1 : Norme CEI-61508 et ses drives
Ces normes drives sont les suivantes : La norme CEI 61511, cre en 2003, est adapte pour les procds industriels. La norme CEI 61513, cre en 2001, est adapte pour le secteur du nuclaire. La norme CEI 62061, cre en 2005, est adapte pour la scurit des machines. Les normes EN 50126/EN 50128/EN 50129, cres respectivement pour les dernires versions, en 1999/2001/2003, sont adaptes pour le secteur du ferroviaire. La norme ISO 26262, qui devrait tre publie en tant que standard en 2011, sera adapte pour le secteur de lautomobile.
2.1.2. ARP-4754
La norme de sret [ARP-4754, 1996], dont lintitul est Certification Considerations for Highly-Integrated or Complex Aircraft Systems et dont une nouvelle version est sortie en dcembre 2010, est un standard de la Society of Automotive Engineers (SAE). Elle traite de processus de dveloppement de systmes aronautiques en se focalisant sur les aspects de sret. Elle sintresse galement des aspects concernant la certification. La norme fait rfrence dautres standards bien connus, comme le [DO-178B, 1992] Software Considerations in Airborne Systems and Equipment Certification pour le dveloppement de logiciel dans le domaine aronautique, ou encore le [DO-254, 2000] Design Assurance Guidance for Airborne Electronic Hardware Considerations in Airborne Systems and Equipment Certification pour le dveloppement de matriel. La Figure II.2 montre les activits et leurs organisations prconises par la norme ARP4754, qui fait intervenir des : FHA : Functional Hazard Assessment, PSSA : Preliminary System Safety Assessment, CCA : Common Cause Analysis, SSA : System Safety Assessment.
38
Chapitre 2
Cet ensemble dactivits dbute par une analyse prliminaire des risques au niveau du systme, qui a pour objectif didentifier les risques potentiels qui pourraient porter atteinte au systme. Eventuellement, ces risques peuvent tre pondrs par une criticit (fonction de la probabilit dapparition et de la gravit), puis classs suivant cette criticit. Sur cette base de risques, les objectifs, les exigences ou encore la politique de SdF sont identifis et dfinis. Ils doivent tre intgrs directement pour la conception du systme. Puis des analyses de risques approfondies sont effectues partir de la conception dj tablie. Elles sont ventuellement compltes par des analyses de causes communes.
Figure II.2 : Les processus de lARP-4754
Enfin, un ensemble dactivits concerne lvaluation de la sret de fonctionnement du systme, o il sagit de trouver des indications qui montrent que le systme satisfait bien les exigences de sret de fonctionnement. Une fois la ralisation termine ou en partie acheve, des activits de tests et dessais relatifs la sret de fonctionnement sont galement raliss, ceci pour valider le respect effectif des contraintes et exigences de sret de fonctionnement. Pour beaucoup de techniques dingnierie pour la sret, lARP-4754 fait aussi rfrence un autre standard de la SAE : lARP-4761 prsent dans la section suivante. 39
Chapitre 2
2.1.3. ARP-4761
LARP-6761 [ARP-4761, 1996] Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment est un standard de la SAE. Il est destin tre utilis conjointement avec lARP-4754 pour dmontrer la conformit du systme en court de conception avec des articles de certification, tel que le 14 CFR 25.1309 concernant la FAA (Federal Aviation Administration) ou encore le CS25.1309 concernant lEASA (European Aviation Safety Agency). Dans ses 30 premires pages, le standard dfinit un ensemble organis de processus couvrant lvaluation de la sret, avec principalement la description de mthodes danalyse courantes pour cette valuation de la sret, dont : FHA : Functional Hazard Assessment, FTA : Fault Tree Analysis, FMEA : Failure Mode and Effects Analysis, FMES : Failure Modes and Effects Summary, CCA : Common Cause Analysis, ZSA : Zonal Safety Analysis, PRA : Particular Risks Analysis, CMA : Common Mode Analysis.
Les 140 pages suivantes de ce standard dtaillent plus en profondeur les diffrentes techniques, avec leur modlisation et explique comment elles doivent tre appliques. Les 160 dernires pages prsentent un exemple fictif et lapplication de ces techniques sur ce cas dtude. Cet exemple sera dailleurs repris en partie dans le chapitre 5 pour illustrer notre travail.
2.2. Quelques projets

2.2.1. SQUALE
Le projet SQUALE (Security, Safety and Quality Evaluation for Dependable Systems) [Deswarte & al., 1999], [Deswarte, 1998] est un projet europen dont les principaux participants taient le CR2A-DI, Admiral, IABG, le LAAS-CNRS et Matra Transport International. Cest un projet ACTS (Advanced Communications Technologies and Services) qui dbuta en mars 1996 et sacheva vers la fin 1998. Le rapport final du projet est consultable dans [SQUALE, 1999b]. Le but de ce projet tait dlaborer et de fournir un cadre pour lvaluation de la sret de fonctionnement des systmes technologie dinformation (IT System). Des critres dvaluation de la sret de fonctionnement ont t dfinis. Ils ont un caractre gnrique, dans le sens o ils peuvent sappliquer tous les secteurs dactivits. Lintrt de ses critres par rapport dautres critres comme ceux fourni par TCSEC (Trusted Computer System Evaluation Criteria), ITSEC (Information Technology Security Evaluation Criteria) [TCSEC, 1985], [Deswarte & al., 1998] ou encore dautres normes propres lavionique, le ferroviaire, le nuclaire, etc. provient du fait quils couvrent la fois les aspects de scuritinnocuit et de scurit-confidentialit, ainsi que tous les autres attributs de la sret de 40
Chapitre 2
fonctionnement (fiabilit, disponibilit, maintenabilit,). Pour laborer les critres proposs par SQUALE, les participants au projet se sont dailleurs en partie appuys sur les Critres Communs [Common Criteria, 1998]. (Note : il existe maintenant des versions plus rcentes des Critres Communs.) Ainsi, les diffrents collaborateurs du projet ont dfini et propos un panel dactivits raliser dans des conditions donnes, selon les diffrents attributs de sret de fonctionnement et leurs niveaux de confiance souhaits (dclins en niveaux de dtail, de rigueur et dindpendance). Fondamentalement, SQUALE dfinit des activits mettre en uvre pour valider la sret de fonctionnement dun systme, paramtrables en fonction des niveaux de confiance voulus. Le document alors tabli par le projet SQUALE [SQUALE, 1999a] se veut tre applicable pour la validation ou la certification de systmes qui sont critiques au niveau de la sret ou de la scurit, ou qui ont un niveau requis lev de disponibilit, de fiabilit ou de maintenabilit. De plus, il couvre toutes les phases du cycle de vie des systmes.
2.2.2. ESACS
ESACS (Enhanced Safety Assessment For Complex Systems) [ESACS], [Bozzano & al., 2003] est un projet europen RTD en rponse lappel de Growth 2000 traitant de nouvelles perspectives en aronautique . Le projet dmarra en fvrier 2001 et sacheva en dcembre 2003. Les objectifs du projet taient : de dfinir une mthodologie pour amliorer la ralisation des analyses de sret au cours du dveloppement de systmes complexes, dtablir un environnement partag bas sur les outils supportant la mthodologie, de valider la mthodologie travers son application sur un cas dtude.
Lenvironnement entre la conception et la sret est compos doutils pour gnrer des parties danalyses de sret en utilisant les informations extraites directement du modle du systme et dune base incluant toutes les informations de sret lies au systme. Le constat de base fait lors des dbuts du projet ESACS rejoint des points identiques aux ntres concernant les faiblesses des processus de sret de fonctionnement. Plus de dtails sont disponibles dans [ESACS, 2001]. Les dfaillances et leurs effets proviennent souvent du simple jugement des ingnieurs et sont vrifis par des tests. Or ces jugements deviennent de plus en plus difficiles cause de la complexification des systmes. Principalement, le nombre dtats possibles des systmes augmentent considrablement du fait de lintgration de calculateurs toujours plus sophistiqus et de laugmentation des interactions entre les diffrents systmes avion (note : on parle de systme avion en aronautique pour dsigner les premiers soussystmes de lavion) qui implique un risque dinteraction entre des dfaillances. Lautre point concerne la manire dont les informations sont gres et changes par les ingnieurs. En fait, actuellement les informations entre les ingnieurs systme et les ingnieurs de sret sont changes sous forme papier. Ainsi, linformation concernant le 41
Chapitre 2
comportement du systme est transmise par texte ou par modle et elle doit tre en premier lieu interprte par lanalyste de sret. Dans un second temps seulement, des AMDEC ou des arbres de dfaillances (par exemple) sont raliss, tant supports par dautres outils. Ce type de traitement de linformation est source derreurs et implique la duplication des efforts de modlisation (pour la conception, puis pour la sret) et aussi retarde lidentification des problmes.
Figure II.3 : Proposition du projet ESACS
Le projet ESACS a rpondu ces faiblesses actuelles en expliquant que les analyses dvaluation de la sret doivent tre conduites partir de quelques moyens automatiques directement appliqus sur le modle fonctionnel du systme (voir Figure II.3). Cela signifie que les modles utiliss pour la conception du systme doivent tre enrichis avec les informations ou exigences de sret de fonctionnement. Egalement, il sagit dutil iser des mthodes de simulation ou des mthodes formelles (model-checking) pour aider aux analyses de sret. Finalement, les principales recommandations issues du projet sont : identifier et dvelopper un modle commun du systme la fois pour la conception et pour la sret, dvelopper une faon dexprimer les exigences de sret plus prcise et plus rigoureuse, et dans le mme cadre que celui pour la conception du systme, Enrichir les modles du systme pour inclure les comportements dfaillants, Fournir le moyen dutiliser le modle du systme enrichi pour la gnration danalyse des modes de dfaillance et de leurs effets, ainsi que pour la gnration darbres de dfaillance, Fournir une classification des modes de dfaillance.
2.2.3. ISAAC
Le projet europen ISAAC (Improvement of Safety Activities on Aeronautical Complex systems) [ISAAC], [Akerlund & al., 2006] est une continuit au projet ESACS qui avait russi montrer le bnfice engendr par lutilisation de mthodes formelles pour lvaluation de la sret des avions. Ce projet se droula de 2003 2006. Lobjectif tait daller encore plus loin dans lamlioration et lintgration des activits de sret des 42
Chapitre 2
systmes complexes aronautiques. Les bnfices potentiels vont dune meilleure confiance en la sret des systmes un accroissement de la comptitivit des industries europennes. Entre autre, il sagissait dtendre les techniques formelles pour prendre en compte les erreurs humaines, les analyses de causes communes, les analyses de mission et la testabilit. Il tait aussi question damliorer les notations dESACS pour reprsenter les exigences de sret. Un troisime volet soccupait de laspect dintgration, travers des recommandations gnrales et de librairies et interfaces partag. Cest en fait un des concepts cls qui permet damliorer lefficacit des processus industriels, qui le plus souvent reposent sur des outils diffrents.
2.2.4. ASSERT
Le projet ASSERT (Automated proof-based System and Software Engineering for RealTime systems) [Conquet, 2008] [Conquet & al., 2005] est un projet coordonn par lAgence Spatiale Europen (European Space Agency ESA), plus prcisment par la division des systmes logiciels. Il a runi prs de 28 partenaires, dont des industries spatiales et des laboratoires de recherche, ainsi que des entreprises de dveloppement de logiciels et doutils. Il commena le 1er septembre 2004 et se termina le 31 dcembre 2007. Ce projet avait comme objectif de changer la manire de procder lingnierie des systmes et des logiciels. Notamment, une nouvelle approche est propose, plus fiable car base sur la modlisation, la prservation de proprits systme et la transformation de modle vers le code final. Un processus est dfini, accompagn dun ensemble doutils, et des projets concrets ont permis de valider lapproche. Parmi les nombreux langages utiliss dans les processus dASSERT, on trouve notamment AADL, UML ou encore Altarica. Sur un cas dtude dun budget total de 50 M, avec une partie avionique reprsentant 30 M dont la part logicielle est de 4 M, il a t estim un gain de 1,8 M sur ces 4 M en suivant lapproche propose par le projet ASSERT.
2.3. Autres travaux de recherche

2.3.1. Modle de dveloppement sret de fonctionnement explicite
Dans [Laprie & al., 1995], un modle de dveloppement de systme est propos. Il est caractris de modle de dveloppement Sret de Fonctionnement explicite. En effet, les moyens de la SdF sont directement identifiables travers les processus proposs. La vision processus est adopte pour la description de ce nouveau modle, qui voulait regrouper au sein de processus fondamentaux les activits ncessaires la construction dun systme et celles relatives la sret de fonctionnement. Le processus principal est alors celui dit de cration du systme, qui inclut les sous-processus dexpression des exigences, de conception, de ralisation et dintgration. Autour de ce processus de base vont se greffer les processus spcifiques la SdF que sont les processus dlimination des fautes, de prvision des fautes, de tolrance aux fautes et de prvention de fautes. A cela
43
Chapitre 2
sajoute encore tous les autres processus classiques dassurance qualit, de certification, etc. (voir la Figure II.4).
Figure II.4 : Modle de dveloppement SdF explicite
Le processus de cration fait donc apparatre quatre activits de base : lexpression des exigences, la conception, la ralisation et lintgration. Lexpression des exigences correspond aux activits de spcifications fonctionnelles, o il est question de dfinir les fonctions et les services que le systme devra rendre. Une description de lenvironnement dutilisation doit galement tre faite et toutes les contraintes lies au dveloppement, la validation ou encore lexploitation doivent tre identifies. Cet ensemble dactivits doit aboutir une spcification (formelle ou informelle) du systme concevoir. La conception correspond aux activits qui permettent de dfinir larchitecture du systme, activits souvent itres jusqu la dfinition de composants lmentaires. La ralisation consiste en la ralisation des composants ou ladaptation des composants qui sont rutiliss. Enfin, lintgration correspond lassemblage des composants pour fabriquer le systme et lintgration du systme ainsi construit dans son environnement dutilisation. Le processus de prvention de fautes va dfinir et coordonner les activits de cration du systme avec les autres processus, ceci travers trois activits principales : dfinition des formalismes et des langages, organisation du projet (allocation des tches aux quipes et gestion des ressources), et planification et valuation des risques lis au dveloppement. Le processus de tolrance aux fautes comporte trois classes dactivits : la dfinition des classes de fautes pour lesquelles le systme devra se prmunir et la description du comportement du systme en prsence de ces fautes, le partitionnement du systme en zone de confinement derreur et dindpendance de fautes, et la dfinition dalgorithmes et de mcanismes de traitement des erreurs et des fautes. Le processus dlimination des fautes est en fait le processus qui va se charger de toutes les vrifications ou les tests ncessaires au dveloppement, la cohrence de la 44
Chapitre 2
progression de la conception ou la conformit de ce qui est produit. Il pourra tre lorigine de demande de modification de la conception, si ncessaire. Le processus de prvision des fautes est compos des activits qui permettent dexprimer les objectifs de sret de fonctionnement du systme, dallouer ces objectifs aux diffrents constituants du systme et dvaluer la sret de fonctionnement. Toutes ces activits sont en forte interaction, que ce soit entre les processus de sret de fonctionnement et le processus de cration, ou entre les processus de sret de fonctionnement eux-mmes. Ceci provient du fait que les exigences de sret de fonctionnement et llaboration de mcanismes de tolrance aux fautes ncessitent une analyse globale. Cela rejoint le constat que nous avions fait de la ncessit dune prise en compte au niveau global des exigences de sret de fonctionnement du systme. Les dtails des processus de sret de fonctionnement et du processus de cration ont t proposs dans [Laprie & al., 1995] sous la forme dun ensemble de mots-cls, ceci pour chaque tape du processus de cration (expression des exigences, conception, ralisation et intgration). Ils sont repris en annexe A de ce mmoire. Critique du modle Le modle ainsi propos offre un cadre gnral pour le dveloppement de systmes srs de fonctionnement, ceci en regroupant et faisant apparatre clairement les activits relatives la prvention de fautes, la tolrance aux fautes, llimination des fautes et la prvision des fautes. Les points importants exprims travers les diffrentes listes de mots-cls constituent une base trs complte et intressante pour lingnierie du systme. Nanmoins, lapproche reste vraiment oriente systmes informatiques . De plus, il a t question lors de la construction de ce modle de distinguer et regrouper en blocks les activits en fonction de leur appartenance soit la prvention de fautes, soit llimination de fautes, soit la prvision des fautes ou encore la tolrance aux fautes. Mais vouloir absolument faire cette sparation rend le modle, et surtout une instanciation de ce modle, bien difficile saisir. Vouloir absolument distinguer et regrouper les activits pour faire apparatre en quatre blocs les moyens de la sret de fonctionnement casse la logique de conception. Les concepteurs auront plus de difficult comprendre les flux entre activits et leurs enchanements travers ce modle qui semble devenir trop artificiel. Les activits ntant donc pas regroupes en fonction de leurs interactions, il est normal daboutir des schmas dinteraction avec une intrication importante de flches reprsentant les interactions en question.
2.3.2. Mthodologie dIS base sur les modles et guides par la SdF
Une mthodologie dingnierie systme a t dveloppe en collaboration entre le MIT (Massachusetts Institute of Technology) et le JPL (Jet Propulsion Laboratory). Prsente dans [Leveson & al., 2007], cette mthodologie se base sur lutilisation de modles et est guide par les aspects de sret de fonctionnement. Le travail ralis se base sur le constat que, notamment dans le domaine spatial, de srieux problmes ou des pertes de missions rsultent de laugmentation de la complexit 45
Chapitre 2
des systmes, conjugue avec lutilisation de nouvelles technologies, dont linformatique et le logiciel (voir [Leveson, 2003]). Ainsi, pour contrer cette complexit, de nouvelles mthodologies sont ncessaires afin de concevoir la sret dans les systmes spatiaux depuis le dbut du processus de conception, en utilisant des techniques bases sur des modles pour trouver tt les fautes de conception (cest--dire lorsque les cots de modification sont encore faibles). Lide de la mthodologie est de placer lanalyse des risques dans le processus de conception nominal, au lieu dtre considre comme une activit spare. La mthode intgre aussi plusieurs aspects dvelopps par le MIT et/ou le JPL. Cot MIT, nous retrouvons le STAMP (pour Systems-Theoretic Accident Model and Processes - [Leveson & al., 2003] et [Leveson & al., 2005]), la STPA (pour STAMP-Based Hazard Analysis [Leveson & al., 2005]) et lIntent Specification (un cadre de spcification dingnierie systme structur et bas sur des contraintes). Lapport du JPL vient par son approche dingnierie systme bas sur des modles, avec des analyses dtats. Pour revenir sur lIntent specification, elle correspond une nouvelle forme de spcification amliore car conue pour : Faciliter la traabilit, Appuyer la vrification des diffrentes proprits du systme (dont la fiabilit), Rduire les cots dune modification et dune r-analyse du systme.
La mthodologie est compose dtapes qui sont les suivantes : Etape 1 : Identifier les objectifs de la mission, les exigences et les contraintes, Etape 2 : Dfinir les accidents systme ou les pertes inacceptables, Etape 3 : Dfinir les risques haut-niveau, Etape 4 : Dfinir les contraintes de sret haut-niveau, Etape 5 : Identifier les contraintes denvironnement et dutilisateur, Etape 6 : Procder la dcomposition fonctionnelle haut-niveau, Etape 7 : Concevoir la structure du systme de contrle haut-niveau, Etape 8 : Procder lanalyse prliminaire des risques, Etape 9 : Dfinir les spcifications des lments du systme, o Etape 9.1 : Dfinir les objectifs, les hypothses, les exigences et les contraintes, o Etape 9.2 : Dvelopper les modles du systme sous contrle, o Etape 9.3 : Dfinir et concevoir le comportement oprationnel du systme de contrle, o Etape 9.4 : Dvelopper des modles formels du systme de contrle, o Etape 9.5 : Continuer procder la STPA, o Etape 9.6 : Raffiner itrativement la conception du systme, Etape 10 : Procder aux tests de validation, Etape 11 : Gnrer la conception et le code logiciel.
46
Chapitre 2
2.4. Synthse
Ainsi, nous venons de parcourir un tat de lart pour la conception de systmes complexes srs de fonctionnement. Les normes de sret aident normment comprendre quels sont les objectifs et les activits pour obtenir un systme srs. Par exemple, lARP4754 fournit une trs bonne vision des activits de sret de fonctionnement. Mais en soit, ces normes ne dfinissent pas une approche globale et unifie avec les activits de conception nominales, cest--dire quelles ne sont pas intgres compltement aux processus dingnierie systme. Les quelques projets que nous avons cit noffrent pas non plus une relle approche globale dingnierie systme. Ils se focalisent plus sur les mthodes et les outils utiliser. Quant aux deux travaux de recherche prsents (Laprie et Leveson), le modle de dveloppement sret de fonctionnement explicite est trs orient pour le domaine logiciel et propose, selon nous, une trop grande sparation entre les activits classiques de conception et les aspects de sret de fonctionnement. Concernant la mthodologie dIS base sur les modles et guides par la SdF, lide de placer lanalyse des risques dans le processus de conception nominal correspond tout fait notre objectif. Mais lapproche propose est trs spcifique et pas suffisamment gnrique. Il est en effet question dutiliser le STAMP, la STPA ou encore lIntent Specification (cf. paragraphe 2.3.2), sans une relle sparation entre les processus et les mthodes. Constat Finalement, le constat que nous faisons est que toutes les normes de sret de fonctionnement existantes se basent plus ou moins sur un mme ensemble fondamental dactivits mettre en uvre. Un exemple a t vu en Figure II.2, qui montre les activits et leurs organisations prconises par la norme ARP-4754 [ARP-4754, 1996]. Cet ensemble dactivits, synthtis Figure II.5, dbute par une analyse prliminaire des risques au niveau du systme. Elle a pour objectif didentifier les risques potentiels qui pourraient porter atteinte au systme. Eventuellement, ces risques peuvent tre pondrs par une criticit (fonction de la probabilit dapparition et de la gravit), puis classs suivant cette criticit. Sur cette base de risques, les objectifs, les exigences ou encore la politique de SdF sont identifis et dfinis. Ils doivent tre intgrs directement pour la conception du systme. Puis des analyses de risques approfondies sont effectues partir de la conception dj tablie. Elles sont ventuellement compltes par des analyses de causes communes. Enfin, un ensemble dactivits concerne lvaluation de la sret de fonctionnement du systme, o il sagit de trouver des indications qui montrent que le systme satisfait bien les exigences de sret de fonctionnement. Une fois la ralisation termine ou en partie acheve, des activits de tests et dessais relatifs la sret de fonctionnement sont galement raliss, ceci pour valider le respect effectif des contraintes et exigences de sret de fonctionnement. 47
Chapitre 2
Figure II.5 : Processus gnriques de base relatifs la SdF
Selon les secteurs, les systmes ou les criticits des risques traiter, les activits devront tre ralises avec des niveaux de rigueur, de dtail ou encore dindpendance (dautres facteurs tant possibles) bien dtermins. En fonction de ces niveaux, les activits seront en quelque sorte paramtres et devront par exemple faire appel tantt des mthodes informelles, tantt des mthodes formelles. Ainsi, il est utile de dfinir des niveaux de confiance et de les associer chaque caractristique dun systme ou sous-systme. Ces niveaux dfiniront alors ceux des activits mettre en uvre. Comme exemples de documents spcifiques la SdF dfinissant des niveaux, nous retrouvons les critres communs [Common Criteria, 1998], le rapport du projet SQUALE [SQUALE, 1999a] ou encore la norme CEI-61508 [CEI-61508, 2010] (avec les SIL). Notre proposition Comme ltablit le constat la base de notre problmatique, la sret de fonctionnement doit tre prise en compte ds le dbut de la conception du systme, afin dviter des dpassements non-souhaits des cots et des dlais du projet de conception. Lingnierie systme est un cadre de travail appropri pour la conception de systmes complexes. Dans notre travail, nous montrons comment la sret de fonctionnement peut tre explicitement gre dans ce cadre. Une approche dingnierie systme pour la sret de fonctionnement se base sur lhypothse que les proprits de SdF ne peuvent tre traites entirement quen prenant en compte toutes les variables et tous les aspects (du social au technique) [Kotovsky & al., 1985]. Cette base pour lingnierie systme a t tablie partir du principe quun systme est plus que la simple somme de ses constituants. La gestion de la sret de fonctionnement doit alors suivre toutes les tapes de lingnierie systme, depuis la dfinition des exigences jusqu la vrification et la validation du systme, et mme son retrait de service. Si nous considrons, par exemple, une exigence de fiabilit dfinie pour le systme complet, sa 48
Chapitre 2
formalisation et son analyse doit permettre dassurer que les solutions techniques slectionnes lors de la progression de la conception rpondent bien cette exigence de fiabilit au niveau des sous-systmes et aprs leur intgration. En fait, les activits relatives la sret de fonctionnement peuvent tre classes selon trois catgories principales. Les activits de prvision des dysfonctionnements [Sadou & Demmou, 2009] regroupent un ensemble danalyses de sret de fonctionnement, telle que la recherche de scnarios [Guillerm & al., 2009a], [Guillerm & al., 2010a] conduisant aux dfaillances ou lanalyse des consquences de dfaillances. Ces activits sont raliser en parallle la conception du systme. Les activits de tolrance aux fautes et aux pannes [Arlat & al., 1999] sintressent la mise en place de mcanismes tels que les redondances pour recouvrir certaines pannes, ou encore prennent en compte les erreurs possibles des oprateurs. Elles font partie intgrante des activits de conception du systme. La dernire famille dactivits est celle des dmonstrations dobtention de la sret [Sheard, 2006]. Elle regroupe lensemble des activits de vrification et validation (V&V), de tests et dessais relatifs la sret de fonctionnement du systme [Cohn, 1989], [Beizer, 1990]. Ces activits sont ralises une fois certaines tapes de conception acheves (pour la V&V) ou la fin dtapes cls de la ralisation (pour les tests et les essais).
Nous proposons ainsi une nouvelle approche laide de processus qui doivent tre dfinis indpendamment des mthodes et des outils, qui sont par ailleurs lintrt principal dautres projets (ESACS [ESACS, 2001], ISAAC [Akerlund & al., 2006] et MISSA1 par exemple). Mais avant dexposer notre propre dmarche processus, nous nous devons de dfinir les processus et normes dingnierie systme.
3. Processus et normes dIngnierie Systme

Deux principales approches de conception ont fait lobjet de nombreux travaux et ont t dfinies. Le cycle en V et ses variantes [Forsberg & al., 1991b] , [Forsberg & al., 1995], [Boehm & al., 1994], [Boehm, 1988], et lapproche processus. Le cycle en V a dj t aperu au premier chapitre. Quant lapproche processus, elle est base sur le fait que quelque soit la stratgie utilise pour le dveloppement dun systme, les activits restent les mmes [Evrot, 2008]. Les processus techniques reprsentant ces diffrentes activits dingnierie systme sont groups en deux catgories principales : les processus de dfinition du systme et les processus de vrification et de validation du systme. Ils sont dfinis par des normes dingnierie systme ([IEEE-1220, 2005], [EIA-632, 1999], [ISO-15288, 2008]).
More Integrated Systems Safety Assessment (http://www.missa-fp7.eu/)
49
Chapitre 2
Lapproche processus est adopte dans notre travail car elle est plus flexible que lapproche de dveloppent en V. En effet, la vision processus ne contraint pas la squence des activits de dveloppement, contrairement aux approches bases sur des cycles [Meinadier, 2002]. Cette diffrence est la motivation pour le choix de lapproche processus, dautant plus quil sagit de systmes complexes.
3.1. Vision processus

Une manire de transcrire lIngnierie Systme passe donc par la dfinition de processus dIngnierie Systme. Ces processus informent des tches ou des activits raliser par des acteurs du projet (quipes de conception, de management,) pour raliser la mission souhaite. Ils possdent des donnes dentre et de sortie et sont activs ds que des entres respectent certaines contraintes prtablies, si tant est que les ressources ncessaires sont disponibles (voir la schmatisation dun processus ci-aprs).
Figure II.6 : Processus d'Ingnierie Systme
LAFIS fournit une dfinition du processus qui est : Processus : Un processus est un ensemble dactivits interactives coordonnes pour transformer progressivement des lments dentre en produits. En fait, diffrents niveaux de dfinition des processus existent [AFIS, 2005a] : Le processus normalis : il est dfini dans des normes (cf. le paragraphe suivant), a souvent un caractre gnrique et de recommandation, et prsente des types dactivits raliser et de rsultats attendus. Ce genre de processus provient souvent dun consensus entre des experts dentreprises les plus avances. Le processus dfini ou institutionnalis dans un organisme : il rsulte de lajustement dun processus normalis aux besoins de lorganisme, en fonction des pratiques et des mthodes choisies par lorganisme pour raliser les activits. Dailleurs, la conception et lamlioration des processus institutionnaliss relve de lingnierie des processus. Le processus ajust un projet : il provient dune adaptation dun processus institutionnalis aux justes besoins du projet, en prenant en compte les contraintes et les ressources du projet en question. 50
Chapitre 2
Comme nous lavons vu dans le premier chapitre, un modle transmet de manire plus efficace et plus sre une information quune explication textuelle qui peut comporter des ambiguts. Ainsi, les processus sont eux aussi modliss, par exemple en utilisant la notation graphique de la Business Process Modeling Notation (BPMN), anciennement propose par les membres de la Business Process Modeling Initiative (BPMI) et dsormais sous la coupe de lOMG.
Figure II.7 : Exemple de modlisation en processus
Un autre exemple de notation possible pour la modlisation de processus est donn par le mta-modle SPEM (Software & Systems Process Engineering Meta-Model) de lOMG (Object Management Group) [SPEM, 2008]. Effectivement, ce mta-modle peut tre utilis par toutes les activits de modlisation de mthodes et de processus, ceci en utilisant des notations dUML [UML, 2010]. Dans ses travaux [Rochet, 2007], Samuel Rochet a par exemple modlis les processus dune norme dIS qui est lEIA-632 (cf. section suivante) laide du langage SPEM.
3.2. Normes dIngnierie Systme (IEEE-1220, EIA-632, ISO15288)

Les normes dingnierie systme sont dfinies en termes de processus (normaliss). Ces processus permettent de transmettre facilement, rapidement et sans ambigut les enchanements et les imbrications dactivits mettre en uvre. Ces normes sont donc des standardisations de processus pour lIngnierie Systme. Tantt elles sont destines un domaine bien prcis, tantt elles ont un caractre beaucoup plus gnrique et peuvent sappliquer dans des organismes de natures trs varies. Tantt elles ne couvrent quune partie du cycle de vie du produit (par exemple la phase de dveloppement uniquement), tantt leurs portes stendent la totalit du cycle de vie (cest--dire de la conceptualisation au retrait de service). Lintrt de concevoir, puis dutiliser une norme, vient du fait quelle nat dune capitalisation dexprience et de savoir-faire de grandes entreprises, en tous cas pour celles qui concernent lingnierie systme. Elle reprend donc les bonnes pratiques dIngnierie couramment constates, mais se base aussi sur des checs industriels pour samliorer et apporter de nouvelles activits censes viter ces checs. Une norme procure donc les meilleurs pratiques possibles connues pour une bonne conduite et une bonne gestion dun programme (ou projet) industriel. 51
Chapitre 2
Actuellement, on dnote 3 grandes normes dIngnierie Systme qui sont : lIEEE-1220 [IEEE-1220, 2005], lEIA-632 [EIA-632,1999] et lISO-15288 [ISO-15288, 2008]. Elles dfinissent donc les types dactivits raliser et les rsultats produits. Elles recouvrent des champs diffrents, de manire dautant plus approfondie que leur champ est plus limit, et ainsi se compltent.
Figure II.8 : Couverture des normes IEEE-1220, EIA-632 et ISO-15288
Les dfinitions donnes par lAFIS pour les normes IEEE-1220 et ISO-15288 sont : Norme IEEE 1220 : Issue du standard militaire MIL STD 499B, cette norme de l'IEEE, dont la version initiale date de 1994, se focalise sur les processus techniques dingnierie systme allant de lanalyse des exigences jusqu la dfinition physique du systme. Les trois processus danalyse des exigences, danalyse fonctionnelle et allocation et de synthse, finement dtaills, comprennent chacun leur sousprocessus de vrification ou de validation. Le processus danalyse systme a pour but danalyser dans un cadre pluridisciplinaire les problmes (conflits dexigences ou solutions alternatives) issus des processus principaux afin de prparer les dcisions. Le processus de matrise de lIS (control) concerne tout particulirement la gestion technique de lingnierie systme et la matrise de linformation tant du systme que du projet. Norme ISO 15288 : Inspire sur le plan et la forme par la norme ISO/CEI 12207 AFNOR Z 67- 150 (Typologie des processus du cycle de vie du logiciel), cette norme de l'ISO, datant de 2003 et revue en 2008, tend les processus techniques tout le cycle de vie du systme (elle couvre ainsi les processus dexploitation, de maintien en condition oprationnelle et de retrait de service). La norme sapplique lingnierie des systmes contributeurs qui ont leur propre cycle de vie (systmes de fabrication, de dploiement, de soutien logistique, de retrait de service) : que lon songe par exemple lingnierie des systmes de dmantlement et de traitements des dchets dune installation nuclaire. Elle complte les processus sappliquant aux projets par des processus, dits dentreprise, qui ont pour objectif de dvelopper le potentiel de 52
Chapitre 2
lorganisme dIS en manageant les domaines communs au profit des projets dIS. Les processus de cette norme (version 2003) sont rappels en appendice au glossaire de base AFIS. La norme que nous avons choisie dutiliser dans nos travaux et qui sera dtaille plus loin est lEIA-632, ceci pour plusieurs raisons. Tout dabord, elle offre un bon compromis de couverture du cycle de vie par rapport lIEEE-1220 qui est trop spcifique aux toutes premires phases du projet et par rapport lISO-15288 qui englobe la gestion de lentreprise que nous nabordons pas dans le travail prsent dans ce mmoire. Ensuite, lEIA-632 savre tre une norme trs populaire et efficace, particulirement utilise dans les domaines aronautiques et militaires. Le dernier point intressant qui ressort au travers de cette norme est la dfinition et la prise en compte de produits contributeurs . Nous cernerons ce quils reprsentent dans la section consacre la norme EIA-632.
3.3. Paradigme processus-mthodes-outils

Les normes dingnierie systme proposent donc un ensemble de processus raliser, comme nous venons de le voir. Elles offrent un guide mthodologique fait de tches, mais en ne sintressant principalement quaux rsultats obtenir en fonction des entres. Cest-dire quun processus ne dcrit pas la manire de raliser le travail correspondant. En fait, une mthode est bien souvent ncessaire pour remplir laction demande par un processus. Elle sert implmenter le processus en question et ne doit pas tre choisie pour sa flexibilit ou sa popularit, mais uniquement parce quelle reflte la smantique du processus. Les mthodes peuvent bien entendu tre slectionnes parmi celles existantes, ou ventuellement tre dveloppes spcifiquement. Pour faciliter lapplication dune mthode, des outils sont utiliss. Il est possible que plusieurs outils existent pour rpondre une mthode, de mme que plusieurs mthodes peuvent satisfaire un processus. Ainsi, dans cette approche rsume par la Figure II.9, un processus est implment par une mthode qui peut tre applique en utilisant un outil. Nous pouvons noter quil est impossible dutiliser un outil implmentant un processus sans avoir pralablement identifi la mthode approprie.
Figure II.9 : Approche Processus-Mthodes-Outils
3.4. EIA-632
Dans cette section, nous prsentons la norme choisie pour appuyer notre travail : il sagit de lEIA-632.
3.4.1. Historique et gnralit

En juin 1994, un groupe de travail compos dindustriels, de membres de lINCOSE et du Department of Defense (DoD) amricain sest runi et a commenc de dvelopper un 53
Chapitre 2
standard pour lingnierie des systmes. Ce travail a t ralis par le comit G-47 dIngnierie Systme de lElectronic Industries Alliance (EIA). Il en a t dgag une bauche de la norme EIA-632, qui deviendra un standard destin tre utilis par des entreprises commerciales, mais aussi par des agences gouvernementales et leurs soustraitants. En avril 1995, un groupe plus formel de travail, tabli sous le projet PN-3537 et compos de reprsentants de lEIA et de lINCOSE, a produit une premire version finale du standard. La version de la norme avec laquelle nous avons travaill date elle de 1998 (et a t approuv le 7 janvier 1999). Ainsi, la norme EIA-632 dfinie une approche dingnierie ou de ringnierie des systmes, incorporant les bonnes pratiques constates dans la seconde partie du XXme sicle. Elle propose au dveloppeur systme un ensemble cohrent de processus organiss en 5 groupes : Les processus dacquisition et de fourniture, Les processus de management technique, Les processus de conception systme, Les processus de ralisation du produit, Les processus dvaluation technique.
Figure II.10 : Les processus de l'EIA-632 (traduction franaise)
3.4.2. Interaction entre les diffrents processus

De manire synthtique, la Figure II.10 prsente les interactions entre les diffrents groupes de processus, qui sont les suivantes : 54
Chapitre 2
1) Une demande dacquisition survient et est traite par le processus de Fourniture (car il sagit de fournir lobjet de la demande au client) par ltablissement dun contrat, 2) Les exigences de lacqureur (provenant du contrat) sont transmisses aux processus de Conception Systme en charge de llaboration de la solution logique, puis physique, ainsi que de plusieurs ensembles dexigences techniques spcifies, dont chacun est associ un sous-systme, 3) Le processus dAcquisition soccupe dacheter (si disponible sur le march) ou de faire fabriquer les sous-systmes rpondant aux diffrents ensembles dexigences spcifies, 4) Une fois les sous-systmes reus, la ralisation du produit final peut commencer (processus dImplmentation), base sur la solution de conception pralablement tablie et choisie, 5) Pour finir, le systme final est transmis lutilisateur (processus de Transfert pour Utilisation), juste aprs avoir subi des tests et la validation finale. En parallle, tous les processus prcdents sont grs, cadencs et contrls par les processus de Management Technique. Les processus dEvaluation Technique permettent quant eux deffectuer des analyses systme (par exemple des analyses de risques), des validations dexigences ou des vrifications systme, ceci durant le dveloppement et si ncessaire.
3.4.3. Les 33 sous-processus de lEIA-632

Les 5 groupes de processus de lEIA-632 organisent en fait 13 processus dingnierie systme, qui eux mme se dcomposent en 33 sous-processus en tout. Le dveloppeur doit alors dcider lesquels de ces 33 sous-processus utiliser. La Figure II.11 fournit lensemble de ces sous-processus.
Figure II.11 : Les 33 sous-processus de l'EIA-632
55
Chapitre 2
Remarque : Le terme sous-processus que nous employons ici remplace celui de requirement dfinis dans la norme EIA-632. En effet, nous avons dcid de ne pas traduire requirement par exigence , mais plutt par sous-processus afin dviter toutes confusions vis--vis des exigences proprement dites du systme (cest--dire les exigences dacqureur ou des autres parties prenantes, les exigences techniques spcifies, les exigences techniques drives, etc.).
3.4.4. Structure dun systme selon lEIA-632

Pour pallier le fait que la ngligence des produits qui contribuent avoir le systme dsir est une cause dchecs de projets industriels [Messaadia, 2008], lEIA-632 adopte une dcomposition originale et trs intressante du systme dont la brique de base est le bloc de construction (traduction de building block ). Le systme complet est dcompos en un (voire plusieurs) produit final auquel est associ un ensemble de produits contributeurs (traduction choisie pour enabling products ). Ces produits contributeurs [Martin, 2001] reprsentent tous les lments ou les systmes annexes ncessaires au dveloppement, la production, au test, au dploiement et au support du produit final, ainsi qu la formation des oprateurs et des agents de maintenance et au retrait du service des systmes qui ne sont plus utilisables. Ils devront tre disponibles au moment opportun, en tant soit achets, soit fabriqus.
Figure II.12 : Un bloc de construction (traduction franaise)
Le systme final est quant lui dcompos en une hirarchie de sous-systmes dfinis en tant que modules. Le dveloppement des modules de niveau infrieur est lanc ds que le module de niveau suprieur est compltement spcifi. Chaque module est alors considr comme un produit qui a des caractristiques et des exigences identifies et fait lobjet dun dveloppement de mme nature que le systme global. La dcomposition se poursuit jusqu lidentification dune des trois catgories de produits finals : Produits finals sur tagre, Produits finals pouvant tre implments directement, Produits finals pouvant tre fournis par un sous-traitant. 56
Chapitre 2
Figure II.13 : Exemple de dcomposition d'un systme avec l'EIA-632
Suite la prsentation de ses processus et de sa vision dun systme, nous abordons un point de lEIA-632 substantiel pour notre travail qui est la gestion des exigences. En effet, nous avons voqu dans la problmatique limportance dune gestion efficace des exigences pour une conception sre de fonctionnement (cf. chapitre 1).
3.4.5. Vision des exigences de lEIA-632

Dans le texte de la norme EIA-632, il est question de plusieurs catgories dexigences (revoir le chapitre 1 paragraphe 3.4.1. pour la dfinition dune exigence). En effet, il apparait des exigences dacqureur, des exigences des autres parties prenantes, des exigences techniques du systme, des exigences techniques drives ou encore des exigences spcifies. Plusieurs types de solution sont galement cits : la solution logique, la solution physique et la solution de conception. La gestion des exigences, dont un schma caractre non-normatif est prsent en annexe de la norme (annexe G) et est repris en Figure II.14, permet de bien comprendre larticulation entre toutes ces exigences et solutions.
Figure II.14 : Relations entre exigences
57
Chapitre 2
Sur ce schma, relatif la construction dun building block, les exigences dacqureur et celles des autres parties prenantes conduisent aux exigences techniques du systme. Cette transformation dexigences est ralise par le processus de dfinition des exigenc es et le but est daboutir une spcification en exigences dites techniques du systme qui doit tre non ambige, complte, consistante, ralisable, vrifiable et ncessaire et suffisante pour concevoir le systme. Ensuite, une partie des exigences techniques du systme permet daboutir des reprsentations de la solution logique. Des exigences techniques drives peuvent alors merger, suite un affinement dexigences techniques ou des choix de solution logique qui imposent des contraintes pour la suite du dveloppement. Puis la solution physique est tudie de faon convenir la solution logique et intgrer les exigences techniques du systme qui nont pas encore t alloues. L aussi, des exigences techniques drives peuvent surgir et sajouter aux prcdentes. Elles devront tre directement satisfaites par les reprsentations de la solution physique. Enfin, une solution de conception merge des reprsentations de la solution physique et elle conduit plusieurs ensembles dexigences spcifies. Chaque ensemble dexigences spcifies va donner les exigences dacqureur assignes pour le dveloppement des blocs de construction du niveau infrieur (celui des soussystmes) comme le montre la Figure II.15 ci-dessous.
Figure II.15 : Rle des exigences spcifies
Cette gestion des exigences intgre un aspect de traabilit, qui est effectivement cit plusieurs endroits dans la norme. La traabilit est dailleurs un garant fondamental au bon droulement de la conception et est un facteur dterminant du point de vue de la 58
Chapitre 2
qualit et de la sret de fonctionnement du systme, comme nous lavons constat dans lanalyse faite la fin du premier chapitre concernant les faiblesses des activits dingnierie systme. Un exemple dapplication de la norme EIA-632 pour la conception systme peut tre consult dans [Esteban et al., 2009].
4. Approche globale propose

4.1. Principe dintgration de la SdF
Lintgration de la sret de fonctionnement doit concerner tous les processus dingnierie systme. Il sagit de pouvoir implanter dans lapproche gnrale de conception dun systme (dfini par les processus de lEIA-632 dans notre cas) le schma de traitement de la sret de fonctionnement identifi dans la synthse de la section prcdente. Dans un premier travail [Guillerm & al., 2009b], [Guillerm & al., 2010b], laccent est mis principalement sur les processus de conception systme et les processus dvaluation technique. Les exigences de sret de fonctionnement doivent tre prises en compte dans le processus de dfinition des exigences, qui permet la formulation, la dfinition, la formalisation et lanalyse de ces exigences. Puis, un modle de traabilit [Gotel & al., 1994] doit tre tabli pour assurer la prise en compte des exigences travers le cycle de dveloppement du systme. Ces exigences de sret de fonctionnement influencent les exigences dacqureur, les exigences des autres parties prenantes, les exigences techniques du systme, les reprsentations de la solution logique et les reprsentations de la solution physique. Les processus dvaluation technique dfinissent 12 types de sous-processus allant de la validation de la dclaration des exigences jusqu la vrification de disponibilit des produits contributeurs. Les tches associes chaque sous-processus peuvent tre consultes dans [EIA-632, 1999]. Les sous-processus considrs sont : validation de dclaration des exigences, validation des exigences de lacqureur, validation des exigences des autres parties prenantes, validation des exigences techniques drives, validation des reprsentations de la solution logique et vrification de la solution de conception.
Limplmentation de lapproche consiste identifier et indiquer de quelle manire la sret de fonctionnement doit tre considre par chaque sous-processus de lEIA-632. Autrement dit, les sous-processus du standard EIA-632 sont traduits ou raffins en termes de sret de fonctionnement.
59
Chapitre 2
4.2. Les processus de conception systme

Les processus de conception systme sont utiliss pour convertir les exigences de toutes les parties prenantes (acqureur et autres parties prenantes) en un ensemble de spcifications, plan ou modles. Cet ensemble forme la solution de conception qui doit tre ralisable et doit satisfaire et apporter une rponse toutes les exigences. Pour se faire, deux processus sont impliqus : le processus de dfinition des exigences et le processus de dfinition de la solution. Les relations entre ces processus sont visibles sur la Figure II.16.
Figure II.16 : Processus de conception systme
4.2.1. Le processus de dfinition des exigences

Le rle du processus de dfinition des exigences est de transformer les exigences des parties prenantes en un ensemble dexigences techniques du systme. Trois sous -processus sont associs ce processus, ils traitent respectivement des exigences de lacqu reur, des exigences des autres parties prenantes et des exigences techniques du systme (voir Figure II.17). Le processus de dfinition des exigences est r-accompli si ncessaire. Les exigences de sret de fonctionnement doivent tre prises en compte dans ce processus. Cela permet la formulation, la dfinition, la formalisation et lanalyse de ces exigences. Puis, un modle de traabilit doit tre construit pour assurer la considration de ces exigences travers le cycle de dveloppement du systme.
Figure II.17 : Processus de dfinition des exigences
4.2.1.1.
E.14 : Exigences dacqureur
Concernant les exigences dacqureur, le dveloppeur doit dfinir un ensemble valid dexigences dacqureur pour le systme, ou une partie du systme. Pour cela, il doit : 60
Chapitre 2
1. Identifier, collecter et hirarchiser les exigences pour le systme, incluant galement toutes exigences concernant le dveloppement, la production, le test, le dploiement/linstallation, lentrainement, lutilisation, le support/la maintenance, et le retrait de service. 2. Assurer que les exigences rpondent aux besoins et attentes de lacqureur, en faisant appel au sous-processus E.26 de validation des exigences dacqureur. Si la distinction entre exigence fonctionnelle ou non-fonctionnelle na pas t possible au niveau du processus dlicitation des exigences, le concepteur doit la faire afin de catgoriser les exigences. Dans le cadre de la sret de fonctionnement, les exigences dacqureur correspondent gnralement des contraintes sur le systme. Il est donc ncessaire didentifier toutes les contraintes imposes par lacqureur, qui concerneront principalement la scurit et la disponibilit (la fiabilit et la maintenabilit viennent dans un second temps). Une organisation hirarchique doit tre effectue, en associant des poids aux exigences de sret de fonctionnement suivant leurs criticits. Par exemple, pour un avion de ligne, lorganisation hirarchique consiste associer une exigence de fiabilit du systme du train datterrissage une priorit plus lev qu une exigence de fiabilit du systme de climatisation.
4.2.1.2.
E.15 : Exigences des autres parties prenantes
Concernant le deuxime sous-processus, le dveloppeur doit dfinir un ensemble valid dexigences des autres parties prenantes pour le systme ou une partie du systme. Lapproche reste la mme que celle des exigences dacqureur en termes didentification, de collecte, de validation, etc. Pour des exigences de sret provenant dautres parties prenantes, elles peuvent, entre autres, provenir du respect dune certification ou de contraintes de qualit. Dailleurs, quelques standards guident le concepteur pour dfinir les exigences de sret de fonctionnement. Les systmes critiques dans le secteur arospatial civil sont par exemple dvelopps en suivant les recommandations prsentes dans [ARP-4754, 1996] et [ARP4761, 1996]. Ces standards fournissent des conseils pour la dtermination des exigences, incluant la capture des exigences, les types des exigences et les exigences drives. Mise part la source des exigences qui est diffrente, la mme approche que pour les exigences dacqureur est applique pour les exigences des autres parties prenantes.
4.2.1.3.
E.16 : Exigences techniques du systme
Au niveau du sous-processus traitant des exigences techniques, le dveloppeur doit dfinir un ensemble valid dexigences techniques du systme partir des ensembles dexigences dacqureur et dexigences des autres parties prenantes. Le rsultat associ laccomplissement de ce sous-processus doit correspondre un ensemble dexigences techniques qui sont non-ambiges, compltes, consistantes, faisables, vrifiables, et ncessaires et suffisantes pour la conception du systme. 61
Chapitre 2
Dans le cadre de la sret de fonctionnement, les exigences techniques du systme traduisent des performances systme. Cela consiste dfinir des attributs de sret de fonctionnement tel que des MTTF2 (temps moyen de fonctionnement avant panne), des MTBF3 (temps moyen entre pannes), des MTTR4 (temps moyen avant rparation), des taux de dfaillances, ou encore des niveaux de confiance (SIL, ITSEC, TCSEC, SQUALE, ). Parmi toutes les exigences formules par lacqureur ou les autres parties prenantes, certaines dentre elles sont des exigences de sret de fonctionnement. Elles seront une des sources dexigences techniques de sret de fonctionnement. Les tudes des vnements critiques dfinissent galement des exigences de sret, dans le sens o leurs prises en comptes doivent conduire une conception du systme capable de les viter. En fait, des appels au processus danalyse des systmes sont faire pour procder des analyses (prliminaires) de risques, afin de dfinir, entre autres, les objectifs, la politique, les fonctions et les exigences de sret de fonctionnement. Il peut alors en dcouler des exigences de sret afin de rduire la probabilit des risques identifis (par exemple laide dexigences de fiabilit) ou afin de rduire la consquence des effets des risques (par exemple en ajoutant des barrires ou des mesures de protection). Les rsultats danalyses de risques constituent alors la seconde source dexigences de sret de fonctionnement. Par ailleurs, il est recommand de dfinir des attributs pour les exigences dans le but de faciliter leur gestion, par exemple en exprimant les exigences avec un langage comme SysML [SysML, 2008]. De plus, SysML permettra de lier les exigences la solution de conception.
4.2.2. Le processus de dfinition de la solution

Le processus de dfinition de la solution est en charge de llaboration des spcifications, reprsentations, plans et modles correspondant la solution de conception, ceci partir de lensemble des exigences techniques du systme. La solution de conception ainsi dfinie doit en fait satisfaire : 1. Lensemble des exigences techniques du systme qui proviennent du processus de dfinition des exigences, 2. Ainsi que lensemble des exigences techniques drives qui sont licites lors du processus mme de dfinition de la solution. Ce processus de dfinition de la solution dispose de trois sous-processus gnrant les reprsentations de la solution logique, les reprsentations de la solution physique et les exigences spcifies (voir Figure II.18).
2 3
Mean Time To Failure Mean Time Between Failures 4 Mean Time To Repair
62
Chapitre 2
Figure II.18 : Processus de dfinition de la solution
4.2.2.1.
E.17 : Reprsentations de la solution logique
Le dveloppeur doit dfinir un ou plusieurs ensembles de reprsentations de la solution logique qui sont conformes avec les exigences techniques du systme. Pour cela, il doit en particulier : 1. Faire des analyses de traabilit, 2. Identifier et dfinir les interfaces, les tats et les modes, les temps de rponse, et les flux de donnes et de contrle, 3. Analyser les comportements, 4. Analyser les modes de dfaillances et dfinir les effets des dfaillances. Notre recommandation est dutiliser des modles semi-formels ou formels (UML, SysML, rseaux de Petri, machine tats finis) pour les reprsentations de la solution logique. Lutilisation de modles formels facilite les vrifications et les analyses de par leur automatisation possible. Dans ce processus, les techniques danalyse de la sret de fonctionnement sont utilises pour le choix de la meilleure solution logique.
4.2.2.2.
E.18 : Reprsentations de la solution physique
Le dveloppeur doit dfinir un ensemble de reprsentations de la solution physique, qui satisfait les reprsentations de la solution logique, les exigences techniques drives et les exigences techniques du systme. Les reprsentations de la solution physique sont donc drives des reprsentations de la solution logique et doivent respecter toutes les exigences, en particulier les exigences de sret de fonctionnement. Les mmes genres danalyses de sret que pour la solution logique doivent tre appliqus pour la solution physique. Les recommandations proposes pour la solution logique restent valables. Cependant, quand on approche de la solution physique, la smantique de SysML semble ne pas tre compltement suffisante. Il est alors possible dutiliser des langages darchitecture comme AADL [Aer, 2004], VHDL-AMS [Verries and al, 2008], [Vhd, 1999], SystemC-AMS, etc.
4.2.2.3.
E.19 : Exigences spcifies
Pour ce dernier sous-processus de conception systme, le dveloppeur doit spcifier les exigences pour la solution de conception finale. Lobjectif est de caractriser entirement la solution de conception. Le concepteur doit sassurer que la solution de conception est cohrente avec ses exigences sources, des analyses de sret de fonctionnement permettant la validation de ces exigences (concernant la sret). Les exigences spcifies (incluant les exigences fonctionnelles et de
63
Chapitre 2
performances, les caractristiques physiques et les exigences de test) permettent alors une description complte du systme final ainsi que de tous ses sous-systmes. Au fur et mesure que les sous-processus de conception E.17 et E.18 progressent, le systme se voit de plus en plus dtaill. Les risques sont alors affins, et de nouveaux risques peuvent mme apparatre. Des solutions de rduction de certains risques peuvent tre lorigine de nouveau problme de sret. Ainsi, de nouvelles actions de rductions de risques doivent tre conduites et les exigences de sret doivent tre affines une nouvelle fois. Le processus volue ainsi jusqu ce que tous les risques identifis soient traits et attnus suffisamment pour les rendre acceptables (voir lorganisation des processus de conception systme Figure II.16). En fait, pendant la conception, il est ncessaire deffectuer des activits de tolrance aux fautes et aux pannes qui vont permettre ltablissement de mcanismes de redondances, de reconfigurations ou de tolrance aux fautes. Il est galement indispensable de procder des analyses de prvisions des dysfonctionnements (telles quune recherche de scnarios conduisant aux dfaillances ou une analyse des consquences des dfaillances) qui doivent se faire en parallle la conception. A travers toutes les tapes du dveloppement, de nombreux lments de modle de diffrents niveaux dabstraction sont crs, ce qui ncessite un rel suivi pour garantir la cohrence et lintgrit de la conception. La traabilit y contribue fortement, en liant les divers ensembles dexigences (techniques, techniques drives, ou encore spcifies), des solutions logique et physique. L encore, lutilisation du langage SysML peut apporter une aide.
4.3. Les processus dvaluation technique

Les processus dvaluation technique sont destins tre invoqus par les processus de conception systme. Ils forment un groupe de quatre processus, avec : le processus danalyse des systmes, le processus de validation des exigences, le processus de vrification du systme et le processus de validation des produits finals.
Figure II.19 : Processus dvaluation technique
64
Chapitre 2
4.3.1. Le processus danalyse des systmes

Le processus danalyse des systmes est utilis pour : 1. Fournir une base rigoureuse pour prendre les dcisions techniques, rsoudre les conflits dexigences, et valuer les alternatives de solutions physiques, 2. Dterminer les progrs vis--vis de la satisfaction des exigences techniques et techniques drives, 3. Supporter la gestion des risques, 4. Assurer que les dcisions sont prises seulement aprs avoir valu les cots, les dlais, les performances, et les effets des risques sur lingnierie ou la ringnierie du systme.
4.3.1.1.
E.24 : Analyse des risques
Un des sous processus appartenant au processus danalyse systme est celui danalyse des risques. Dans ce sous-processus, le dveloppeur doit procder des analyses de risques sur le systme pour prvoir une stratgie de gestion des risques, supporter cette gestion des risques et supporter les prises de dcisions qui en dcoulent. Plusieurs techniques peuvent tre employes pour analyser les risques, par exemple : les arbres de dfaillances [Lee & al., 1985] ou lAnalyse des Modes de Dfaillance, de leur Effet et de leur Criticit (AMDEC) [Buzzatto, 1999]. Cette tape est trs importante concernant la sret de fonctionnement, car elle dtermine les risques du systme qui est la base de rflexions qui apporteront de nouvelles exigences pour la sret du systme. Le sous-processus danalyse des risques peut donc gnrer des exigences de sret autres que celles dfinies par lacqureur ou les autres parties prenantes. Ces nouvelles exigences doivent alors tre prises en compte dans la conception du systme.
4.3.2. Le processus de validation des exigences

La validation des exigences est une tape critique pour la russite du dveloppement et de limplmentation du systme. Les exigences sont valides quand il est certain quelles dcrivent les exigences et objectifs dentre de telle sorte que le systme rsultant puisse les satisfaire. En fait, ce processus doit permettre de sassurer que les exigences sont ncessaires et suffisantes pour la cration de la solution de conception approprie. Durant ce processus, une attention particulire est porte sur lanalyse de la traabilit, qui permet la vrification de tous les liens entre les exigences dacqureur, les exigences des autres parties prenantes, les exigences techniques et techniques drives, et les reprsentations des solutions logique et physique. Comme les autres exigences, les exigences de sret doivent tre valides. La validation doit permettre la conception de systmes srs de fonctionnement. Pour faciliter cette tape, des solutions semi-formelles, telles quUML [Booch & al., 2005] ou SysML [SysML, 2008], peuvent tre utilises pour une bonne formulation des exigences. En effet, la diversit des personnes concernes par le projet de conception systme qui peuvent avoir des connaissances limites concernant la structure du futur systme, rend les projets 65
Chapitre 2
dingnierie des exigences trs difficile lchelle de lentreprise. Cest pourquoi UML et SysML, travers la diversit de leurs diagrammes, peuvent tre vraiment utiles en offrant un langage commun et en prsentant un ensemble de vues intgres dans un mme modle gnral.
4.3.3. Le processus de vrification du systme

Le processus de vrification du systme est utilis pour sassurer que : 1. 2. 3. 4. la solution de conception systme gnre est cohrente avec sa source dexigences, les produits finals remplissent leurs exigences spcifies, le dveloppement ou lobtention des produits contributeurs progressent, les produits contributeurs requis seront prts et disponibles lorsquils devront ltre.
En particulier, il faut vrifier la conformit de la solution de conception vis--vis des exigences, dont les exigences de sret de fonctionnement. La vrification formelle et la simulation [Zeigler & al., 2000] sont des mthodes couramment utilises pour faire de la vrification systme. Dautres mthodes telles que le test, le prototypage virtuel, la vrification de modle peuvent tre employes.
5. Conclusion
Ainsi, dans ce deuxime chapitre, nous avons pass en revue les diffrents travaux lis notre problmatique dintgration de la sret de fonctionnement dans les processus dingnierie systme dans la premire partie. Le constat est que la majorit de ces travaux se situent dans le domaine informatique, dune part, et sintressent plus laspect mthodes et outils, dautre part. A partir de l, dans la deuxime partie, nous avons prsent une approche globale de prise en compte de la sret de fonctionnement. Celle-ci sappuie sur les processus dfinis dans la norme EIA-632 et dfinit les activits spcifiques mettre en uvre et qui concernent la sret de fonctionnement. Parmi les diffrents processus de lingnierie systme, un processus spcifique est reconnu comme tant critique. Il sagit du processus dingnierie des exigences, en particulier celles lies la sret. Le chapitre suivant propose une approche de dclinaison des exigences de sret diffrents niveaux dun systme complexe.
66
Chapitre 3
Mthodologie de dclinaison dexigences de sret de fonctionnement
III.
Chapitre 3 : Mthodologie de dclinaison dexigences de sret de fonctionnement

1. Introduction
Aprs la prsentation du deuxime chapitre sur lapproche globale de prise en compte de la sret de fonctionnement par des processus dingnierie systme, ce troisime chapitre propose une mthodologie spcifique pour la dclinaison des exigences de sret de fonctionnement. Nous verrons que cette mthodologie sintgre parfaitement dans lapproche gnrale du prcdent chapitre. Lobjectif de cette mthodologie est daider la dfinition dexigences de sret de fonctionnement au niveau systme , mais surtout de dcliner ces exigences en dautres exigences de sret de fonctionnement associes aux diffrents sous-systmes. Ainsi, la satisfaction des exigences aux niveaux des sous-systmes permettra la satisfaction des exigences systmes. Lintrt de la mthodologie rside galement dans la traabilit gnre entre les diffrentes exigences de sret de fonctionnement, diffrents niveaux (systme et sous-systmes). Nous verrons limportance de cette dclinaison et de cette traabilit induite pour la gestion des exigences. Ainsi, ce chapitre dbute par la justification dune telle mthodologie de dclinaison et par resituer sa place dans les processus dingnierie systme. Puis, suit un bref tat de lart avant de prsenter notre mthodologie. Nous donnons ensuite une formalisation base dUML de cette dernire. Puis, un cas dtude simple permet dillustrer la mthodologie. Pour finir le chapitre, nous dressons un bilan de cette nouvelle mthodologie en offrant quelques complments.
2. Dclinaison dexigences de sret de fonctionnement

Avant de prsenter la mthodologie de dclinaison dexigences de sret de fonctionnement, il convient de justifier le besoin dune telle mthode, ainsi que de situer cette dclinaison parmi lensemble des processus dingnierie systme.
2.1. Pourquoi cette dclinaison ?

Dans la problmatique, nous avons vu que la complexification des systmes impose une volution des tudes des proprits de sret, afin dassurer et de permettre les niveaux de confiance ncessaires. Pour une considration effective de la sret de fonctionnement par 67
Chapitre 3
le processus de conception, il est impratif de considrer cette sret travers des tudes globales dans les processus dingnierie systme. Une fois que les proprits de sret ont t identifies globalement (cest --dire licites), celles-ci doivent tre dclines localement pour tre effectivement ralises par le systme. Les proprits locales associes aux sous-systmes ou aux composants doivent tre tablies afin dassurer les proprits globales, ce qui implique un travail de traabilit et des activits dingnierie des exigences.
2.2. Dclinaison vis--vis des processus dingnierie systme

Nous avons vu au chapitre 1 limportance de lingnierie des exigences dans lingnierie systme. Lingnierie des exigences est considre comme un processus crucial dans la conception des systmes complexes. Concernant les exigences de sret de fonctionnement, celle-ci peuvent tre classifies comme des exigences non-fonctionnelles et sont lies aux proprits mergentes du systme. Dfinies au niveau du systme, elles ne peuvent pas tre attribues un seul constituant du systme. Bien entendu, ces exigences non-fonctionnelles sont fondamentales pour le succs dun projet de conception. Deux principales activits sont dfinies dans lingnierie des exigences. La premire concerne le dveloppement des exigences, incluant les processus dlicitation, de documentation, danalyse et de validation des exigences. La seconde sintresse au management des exigences, incluant le management de la maintenance, la gestion des changements et la traabilit des exigences. La mthodologie de dclinaison propose permet de prendre en compte les exigences de sret de fonctionnement en facilitant la gestion de leur traabilit. En fait, elle concerne les deux processus principaux de la gestion des exigences : la fois les activits de dveloppement et celles de management. Dune part, la mthode aide lidentification (cest--dire llicitation) des exigences de sret de fonctionnement au niveau systme. Puis, laide de diffrentes analyses, elle permet de dcliner les exigences globales de sret de fonctionnement en exigences locales, licites leur tour. Dautre part, la traabilit engendre par la dclinaison rpond parfaitement un besoin des activits de management des exigences. Positionnement par rapport lEIA-632 Pour bien situer la position de la mthodologie de dclinaison des exigences de sret de fonctionnement, la Figure III.1 reprend les principaux processus de lEIA-632 qui entrent en jeu.
68
Chapitre 3
Figure III.1 : Evolution parallle des processus de Dfinition des Exigences et de Dfinition de larchitecture
Nous avons vu dans la dmarche mthodologique propose la fin du chapitre 2, quil existe diffrentes sources dexigences de sret de fonctionnement. Celles si peuvent provenir : 1. directement de lacqureur ou dune partie prenante (autre que norme ou certification), 2. de norme respecter ou de certification satisfaire, 3. ou encore danalyse de sret de fonctionnement. Dans la mthodologie, des analyses de sret (E.24) sont appeles par les processus de dfinition de la solution (E.17 et E.18) pour identifier les exigences de sret, ce qui correspond la troisime source dexigences cite plus haut. Ces exigences sont reprises par les processus de dfinition des exigences techniques du systme (E.16) o elles seront bien dfinies et formalises. Cest aussi cette tape que la dclinaison doit tre visible laide de la traabilit qui est gre par le processus E.16. Toutes les nouvelles exigences sont ensuite transmises aux processus de dfinition de la solution pour tre intgres la conception.
3. Travaux sur la dclinaison dexigences de sret de fonctionnement

Dans la littrature, il existe quelques travaux qui traitent de dclinaison dexigences de sret de fonctionnement. Principalement, des travaux ont t raliss dans les universits de York (Grande-Bretagne) et de Queensland (Australie).
3.1. Travaux de Peter Lindsay, John McDermid et David Tombs

Les travaux de Peter Lindsay, John McDermid et David Tombs, des universits de York et de Queensland, [Lindsay & al., 1999], [Lindsay & al., 2000] et [Lindsay & al., 2002], sont plutt orients vers les systmes logiciels. Ils partent du constat quune grande varit de 69
Chapitre 3
techniques danalyse de sret de fonctionnement existe, mais que individuellement, ces techniques sont limites pour faire face aux systmes complexes, ou pour driver et prioriser les exigences de sret des composants. Ils ont aussi constat une confusion ou une ambigit entre les techniques utiliser pour valuer les risques et celles plutt destines assigner des objectifs de sret. En fait, chaque composant individuel dun systme complexe a son propre comportement de dfaillance, et les dfaillances de ces composants mnent aux dfaillances du systme de faon plus ou moins prvisible. Un systme complexe typique possde alors de multiples modes de dfaillance. Dans leurs travaux, ils ont donc dvelopp un processus pour driver les exigences de sret de fonctionnement pour tous les composants du systme. Ils ont notamment identifi deux aspects concernant la sret des composants : Un aspect fonctionnel, relatif ce que le composant est suppos faire ou ne pas faire, Un aspect quantitatif, relatif au degr avec lequel le systme peut tolrer la dfaillance dune fonction et continuer fonctionner avec un risque acceptable.
Ainsi, pour traiter ces deux aspects, ils proposent un processus qui permet de classer les accidents potentiels et les risques systmes, de montrer comment les dfaillances systmes conduisent aux risques, danalyser les dfaillances systmes, et didentifier les combinaisons de fautes de composants qui peuvent les causer. En utilisant un modle derreur quantifi et bas sur les taux de dfaillances tolrs des diffrentes classes daccidents, et en exploitant les taux de dfaillance des composants connus, ils drivent des exigences quantifies sur les composants restants. Leur processus intgre des techniques existantes danalyse de sret de fonctionnement pour une valuation complte et quantifie des risques du systme. Il value la robustesse du systme par rapport aux dfaillances des composants et drive des exigences de sret de fonctionnement pour les composants. En rsum, les tapes principales du processus sont les suivantes : 1. Construction dun modle de conception du systme, qui dfinit le cadre du systme et les fonctions de ses composants. 2. Identification et classification des risques du systme. Une analyse de dfaillance du type Functional Failure Analysis est suggre. 3. Identification des fonctions de sret systme et des mesures de protection travers la considration de squences daccidents. Lutilisation darbre dvnements (Event Tree) est suggre. 4. Construction dun modle dtaill de causes et effets, pour enregistrer comment les fautes se propagent dans le systme du niveau composant au niveau systme, et pour identifier les causes communes possibles. Lutilisation darbre de dfaillance (Fault Tree) est suggre. 5. Allocation dun budget dexigences de sret, en utilisant les modles des tapes prcdentes pour justifier les objectifs quantitatifs. Cest dans cette dernire tape que se concrtise la dclinaison des exigences de sret. De manire trs succincte, les tapes traitent respectivement les questions suivantes : 70
Chapitre 3 1. 2. 3. 4. 5.
Comment fonctionne le systme ? Quest ce qui peut arriver de mal ? Comment ce mal peut arriver ? Pourquoi ce mal peut arriver ? Quelle est la probabilit pour que ce mal arrive ?
Plus de dtails sur ce processus sont disponible dans le rapport [Lindsay & al., 1999]. Pour appuyer la proposition de ce processus, des exemples sont proposs : celui dune presse industrielle dans [Lindsay & al., 2000] et [Lindsay & al., 1999], ou celui dun missile dans [Lindsay & al., 2002].
3.2. Travaux de Tim Kelly et al.

A luniversit de York, les travaux sur la drivation dexigences de sret de fonctionnement ont continu. En particulier, dans [Wu & al., 2006] il est propos un processus semblable celui vu dans le paragraphe prcdent, ainsi quune approche base de Use Case Maps. Lobjet de la proposition concerne aussi la gnration dexigences de sret de fonctionnement, et ce le plus tt possible dans la phase de conception. La problmatique du travail se base sur un constat inclus dans celui que nous avions synthtis la fin du chapitre 1, qui est que des exigences inadaptes ou mal-comprises sont la cause majeur de problme de sret de fonctionnement. Elle sappuie aussi sur le fait que des tudes ont montr lnorme intrt en termes de cot rgler les erreurs dexigences tt dans le processus de dveloppement. Le processus propos sinspire en fait du modle Twin Peaks vu dans lintroduction gnrale, qui explicite clairement lvolution parallle et de manire volutive des processus de dfinition des exigences et de dfinition des architectures (voir Figure III.2). Le principe de base de ce modle est quun choix dexigences peut dterminer un espace darchitectures, et quun choix darchitectures candidates peut son tour contraindre les concepteurs des exigences particulires.
Figure III.2 : Evolution parallle des processus de Dfinition des Exigences et de Dfinition de larchitecture
Ainsi, de manire condense, le processus peut se rsumer de la manire suivante : Les risques sont identifis par des analyses de risques faites partir des descriptions disponibles de larchitecture du systme et de son environnement oprationnel. Les risques identifis sont valus en termes de probabilit et de svrit. Des dcisions de conception architecturelle sont ensuite faites pour choisir les actions ou stratgies appropries de rduction des risques, et des exigences de sret sont dfinies en rponse ces choix de mcanismes de rduction de risques. Pendant que le processus de conception progresse et 71
Chapitre 3
que des dtails supplmentaires sur le systme sont obtenus, des risques vont tre redfinis et de nouveaux risques peuvent merger. Les choix de mcanismes dattnuation de risques peuvent eux-mmes tre lorigine de nouveaux problmes de sret. Ainsi, de nouvelles actions de rduction des risques doivent tre identifies et les exigences de sret doivent tre affines. Le processus volue jusqu ce que tous les risques soient suffisamment attnus. Un exemple de systme de vhicule guid automatiquement est galement trait dans [Wu & al., 2006], afin dillustrer le processus. Dans des travaux prcdents, T. Kelly, avec Karen Allenby, stait galement pench sur la possibilit dutiliser les diagrammes de cas dutilisation UML et des scnarios associs au cas dutilisation pour conduire les analyses de risques. Plus de dtails sur cette proposition sont disponible dans [Allenby & al., 2001]. Notamment, cette publication prsente un exemple relatif au contrle des reverses (ou inverseurs de pousse) dun avion de ligne. Il illustre bien le fait que de nouvelles exigences de sret de fonctionnement sont cres suite une analyse de risques, ceci pour diffrentes conditions de dfaillance. Ces exigences de sret sont alors soit des contraintes de performance (comme un taux de dfaillance ou un temps de rponse), soit des exigences fonctionnelles additionnelles. Finalement, on saperoit que le processus de drivation dexigences de sret de fonctionnement reste le mme, quelques soit les techniques utilises. Cest exactement ce qui est expliqu dans [Alexander & al., 2009], o les trois phases fondamentales des processus de drivation dexigences de sret ont t identifies : 1. Identification des risques, 2. Analyse des risques, 3. Drivation des exigences de sret de fonctionnement. Il existe de nombreuses mthodes diffrentes, qui, en les combinant astucieusement, permettent la ralisation de chacune de ces tapes, et donc laccomplissement du processus de drivation. La mme publication, [Alexander & al., 2009], cite un certain nombre de ces mthodes. Les diffrents travaux que nous venons de prsenter ne sintressent pas explicitement la gestion de la traabilit lors de la gnration des exigences diffrents niveaux. A notre connaissance, ce sont les seuls travaux traitant de la problmatique de dclinaison des exigences de sret diffrents niveaux du systme.
4. Prsentation de la mthodologie
Dans cette section, nous allons prsenter la mthodologie de dclinaison dexigences de sret de fonctionnement propose [Guillerm & al., 2011]. Nous prsentons aussi les deux mthodes de sret de fonctionnement utilises : lAMDEC et lanalyse par arbres de dfaillances.
72
Chapitre 3
4.1. Aperu de la mthodologie

Lobjectif de la mthodologie est de pouvoir lier les exigences de sret de fonctionnement dfinies au niveau du systme avec celles dfinies au niveau des soussystmes. Ces liens correspondent alors la dclinaison des exigences. La mthodologie se dcompose en 4 tapes, organises et dfinies de la manire suivante : Etape 1 : analyse des dfaillances au niveau du systme complet qui peuvent conduire une situation catastrophique ou, tout du moins, un vnement nonsouhait. Etape 2 : analyses des causes de ces dfaillances en sappuyant sur larchitecture du systme. Il sagit de trouver les origines des dfaillances systme au niveau des soussystmes. Etape 3 : analyses des dfaillances au niveau des sous-systmes. Etape 4 : synthtiser la dclinaison des exigences de sret de fonctionnement laide des informations des prcdentes tapes.
La Figure III.3 rsume le procd de la mthode en montrant la squence des diffrentes tapes et en spcifiant les informations dentres/sorties.
Figure III.3 : Vue gnrale de la mthode combinant AMDEC et Arbres de Dfaillances
4.2. Mthodes utilises

Pour appliquer cette mthodologie, nous avons choisi dutiliser des mthodes existantes pour les tapes 1 3. Il sagit de mthodes de sret de fonctionnement bien connues et trs utilises que sont : lAnalyse des Modes de Dfaillance, de leurs Effets et de leurs Criticits (AMDEC) et lanalyse par Arbre de Dfaillances (AdD). LAMDEC a t slectionne car elle est bien adapte ltape 1 et ltape 3. Lanalyse par AdD est, quant elle, un bon
73
Chapitre 3
choix pour raliser ltape 2. Il est noter que dautres mthodes peuvent tre utilises, du moment quelles remplissent lobjectif de ltape raliser.
4.2.1. AMDEC
LAMDEC (Analyse des Modes de Dfaillance, de leurs Effets et de leurs Criticits) [Buzzatto, 1999], [Faucher, 2004], [Landy, 2007], [Faucher, 2009] est une analyse inductive de recherche des effets des pannes des composants sur les sous-systmes et le systme. Cest un procd systmatique pour identifier les modes potentiels de dfaillances avant quelles ne surviennent, avec lintention de les liminer ou de minimiser les risques associs. Historiquement, lAMDEC fut dveloppe dans le secteur aronautique par larme amricaine en 1949. Elle fut utilise pour la premire fois dans les annes 60 pour des analyses de scurit des avions et elle prit son essor en Europe au cours des annes 70 dans les secteurs automobile, chimique et nuclaire. Initialement, la mthode tait appele AMDE (Analyse des Modes de Dfaillance et de leurs Effets). Aujourdhui, elle a ajout lestimation de la criticit des risques, do son nom : AMDEC. Finalement, cette mthode spcifique la sret de fonctionnement des systmes permet de prioriser les interventions afin de rduire les risques les plus grands, mais aussi de formaliser la documentation. Elle aide prvoir pour ne pas tre oblig de revoir . Elle peut tre utilise pour un objet, un procd de fabrication ou encore un processus de production. On parle alors respectivement dAMDEC Produit, dAMDEC Processus ou dAMDEC Moyen. Classiquement, les rsultats dune AMDEC sont consigns dans un tableau semblable celui de la Figure III.4.
Systme
1
Fonction
2
Mode de dfaillance
3
Cause
4
Effet
5
Criticit/ Classification
6
Actions Correctives
7
Figure III.4 : Exemple de structure dun tableau dAMDEC
Ralise sur un systme donn (colonne n1), lAMDEC rpertorie pour chaque fonction du systme (colonne n2) tous les modes de dfaillance (colonne n3). Puis il sagit didentifier les causes possibles de ces modes de dfaillance (colonne n4), sachant que plusieurs causes diffrentes peuvent tre lorigine dun mme mode de dfaillance. Ensuite, les effets des modes de dfaillances doivent tre identifis (colonne n5). Aprs, une classification de chaque couple {cause + effet} de tous les modes de dfaillance doit tre effectue (colonne n6). Souvent, il sagit de choisir une criticit parmi les 5 classes : catastrophique, hasardeux, majeur, mineur ou sans importance. A ce stade, lanalyse proprement dite est en principe finie. Mais une ultime tape est ajoute. Il sagit, pour finir, de dfinir les actions correctives mettre en uvre pour rendre les risques acceptables (colonne n7).
74
Chapitre 3
Identifier les modes de dfaillance : Pour aider lidentification des modes de dfaillance, une liste de modes gnriques peut tre utilise. Par exemple la norme CEI-60812 [CEI-60812, 2006] propose dans son tableau II la liste des modes gnriques de la Figure III.5.
Figure III.5 : Exemple de modes de dfaillances gnriques extrait de lCEI-60812
Identifier les causes : Il existe aussi des mthodes pouvant aider lidentification des causes possibles dun mode de dfaillances. Une possibilit est de se servir du diagramme dIshikawa avec ces 5 M : Main duvre, Matriels, Milieu, Matires, Mthodes (voir Figure III.6).
Figure III.6 : Diagramme dIshikawa avec les 5 M
4.2.2. Arbre de dfaillances

Lanalyse par arbre de dfaillance [Lee & al., 1985], [Chatelet, 2000], [Sinnamon & al., 1996], [Vesely, 1987] est une mthode de type dductif, qui a t mise au point au dbut des 75
Chapitre 3
annes 1960 par la compagnie amricaine Bell Tlphone. Elle fut ensuite exprimente pour lvaluation de la scurit des systmes de tir de missiles, puis reprise dans de nombreux domaines tels que laronautique, le nuclaire, lindustrie chimique, etc. Lanalyse par arbre de dfaillance est largement rpandue dans les tudes de sret de fonctionnement car elle caractrise de faon trs claire les liens de dpendance, du point de vue du dysfonctionnement, entre les diffrents constituants dun systme. Cette technique est capable de grer des combinaisons complexes de dfaillances. Elle est donc bien adapte ltude des dfaillances multiples, mme si elle ne sintresse pas limpact que peut avoir lordre dans lequel les vnements sont considrs. La mthode de larbre de dfaillances part dun vnement indsirable et cherche en connatre les causes possibles. Lobjectif de la mthode est de dterminer les diverses combinaisons possibles dvnements qui entrainent la ralisation dun vnement indsirable donn. Le rsultat est form dune reprsentation graphique des combinaisons au moyen dune structure arborescente, comme celle montre en Figure III.7. Un arbre de dfaillances fourni alors une vue synthtique qui reprsente des interactions entre les composants dun systme du point de vue de la sret de fonctionnement.
Figure III.7 : Exemple dArbre de Dfaillances
La tte de larbre de dfaillance (qui, par analogie, correspond la racine) reprsente la plupart du temps un vnement unique mettant srieusement en question la scurit du systme tudi. Afin de faciliter lanalyse, cet vnement indsirable ( top event) doit tre prcisment dfini. Larbre de dfaillance lui-mme est alors form de niveaux successifs dvnements tels que chaque vnement est gnr partir des vnements du niveau infrieur par lintermdiaire de divers oprateurs (ou portes) logiques. Ce processus dductif est poursuivi jusqu ce que lon obtienne des vnements dits vnements de base : les feuilles de larbre. Prsentation de la symbolique utilise : Les portes logiques utilises sont essentiellement les portes ET et OU (voir Figure III.8). Dautres types de fonction logique existent, mais leur utilisation reste encore anecdotique.
76
Chapitre 3 Symbole
Mthodologie de dclinaison dexigences de sret de fonctionnement Nom porte ET Signification Lvnement de sortie (S) de la porte ET est gnr si tous les vnements dentre (E1, E2, En) sont raliss simultanment. Lvnement de sortie (S) de la porte OU est gnr si au moins un des vnements dentre (E1, E2, En) est ralis (OU INCLUSIF).
porte OU
Figure III.8 : Les portes logiques
Concernant la reprsentation des vnements, il existe en fait toute une srie de reprsentations possibles, qui ont chacune leur propre signification. Le tableau de la Figure III.9 en rpertorie un certain nombre.
Symbole
Nom Rectangle
Signification Evnement (intermdiaire) rsultant de la combinaison dautres vnements par lintermdiaire dune porte logique Evnement qui ne peut tre considr comme lmentaire mais dont les causes ne seront pas dveloppes (temps, moyens limits, etc.) Evnement dont les causes ne sont pas encore dveloppes mais le seront ultrieurement (analyse en cours) Evnement lmentaire qui ne ncessite pas dtre dvelopp plus avant. Evnement de base qui se produit normalement pendant le fonctionnement du systme. Evnement conditionnel ; utilis avec certaines portes logiques.
Losange
Double losange
Cercle
Maison
Ovale
Figure III.9 : Les reprsentations des vnements
Le dernier type de symbole prsent ici est celui qui permet la connexion entre des sousarbres. Il est bien utile dans le cas de redondance dans un arbre ou pour scinder un arbre trop complexe en arbres plus petits dans le but de faciliter sa lecture. Deux symboles de ce type sont donns en Figure III.10.
77
Chapitre 3 Symbole
Mthodologie de dclinaison dexigences de sret de fonctionnement Nom Signification La partie de larbre qui devait se trouver lemplacement de ce symbole est dplace la suite du symbole Une partie semblable, mais non identique celle qui devrait se trouver lemplacement de ce symbole est donne la suite du symbole
Triangle
Triangle invers
Figure III.10 : Les symboles de transfert de sous-arbres
Analyse quantitative : Larbre de dfaillance offre une aide non-ngligeable des analyses quantitatives de sret de fonctionnement, en termes de fiabilit. En effet, il est possible de pondrer les vnements de larbre par des probabilits, afin dobtenir par exemple la probabilit de lvnement indsirable principal en fonction des probabilits des vnements de base. Pour le calcul des probabilits, il sagit dutiliser les formules associes aux portes logiques (cf. Figure III.11).
Figure III.11 : Formules pour le calcul des probabilits des fonctions OU et ET
4.3. Mthodologie de dclinaison

La mthode sorganise en quatre tapes, supposant que le systme complexe est compos de plusieurs sous-systmes. A partir de la dfinition du systme, de ses fonctions, de son architecture, de ses sous-systmes et de leurs fonctions respectives, la mthode combine des analyses AMDEC et des arbres de dfaillances pour dfinir les exigences de sret de fonctionnement systme et les informations sur la dclinaison de ces exigences globales en exigences locales associes aux sous-systmes.
4.3.1. Etape 1 : Analyse des dfaillances du systme

Dans cette premire tape de la mthode, il sagit de conduire une AMDEC au niveau systme. Pour chaque fonction du systme, il sagit didentifier les modes de dfaillances, leurs causes et leurs effets sur le systme (ventuellement en fonction de la phase, ltat ou le mode du systme). Puis il faut classifier ces effets et proposer les actions correctives ncessaires appropries.
78
Chapitre 3
Une fois cette premire tape acheve, lAMDEC niveau systme aura donc permis didentifier, dune part, un ensemble de causes systme, ainsi que les criticits lies aux effets de ces causes. Dautre part, en fonction de ces criticits, des actions correctives relatives ces causes systme ont t dfinies. Ces actions correctives sont alors sources dexigences de sret de fonctionnement intgrer dans la conception et que le systme doit satisfaire pour garantir un niveau de sret de fonctionnement suffisant. Notamment, elles peuvent se traduire en exigences de sret de fonctionnement au travers dobjectifs respecter en termes de frquence acceptable (il sagit dans ce cas dune action corrective qui porte sur les causes). On note que des actions correctives peuvent aussi agir sur les effets dun mode de dfaillance, afin de rduire la gravit.
4.3.2. Etape 2 : Analyses des causes des dfaillances

A partir des causes systme identifies dans la premire tape, la seconde phase consiste construire les arbres de dfaillances qui vont lier les causes systmes des modes de dfaillances des sous-systmes. Ainsi, le top-event (c'est--dire la racine) de chaque arbre est une cause systme. Le but est alors de dterminer les causes au niveau sous-systme du top-event, en utilisant les oprateurs logiques tel que ET et OU, et sachant que les feuilles des arbres doivent correspondre des modes de dfaillances de soussystmes. A ce stade, la distinction entre un mode de dfaillance et une cause est bien visible. Un mode de dfaillance correspond leffet par lequel une dfaillance est reue ou observe depuis un point de vue externe. Une cause reprsente quant elle un vnement qui conduit un (ou plusieurs) mode de dfaillance selon un point de vue interne. Cest pourquoi ici, lorsque lon considre le systme et sa composition en sous -systmes, on essaye de lier les modes de dfaillance des sous-systmes (point de vue externe sur les sous-systmes), pour arriver, en passant ventuellement par des vnements intermdiaires, des causes systme (point de vue interne sur le systme). Ces dernires (les causes systme) tant lies aux modes de dfaillance systme travers lAMDEC systme. Ainsi, ces arbres (dont un exemple gnrique est visible Figure III.12) permettent de lier une cause systme un ensemble de modes de dfaillance de sous-systmes.
Figure III.12 : Exemple darbre de dfaillances
79
Chapitre 3
Ultrieurement, il sagit dassocier des probabilits aux lments des arbres daprs les donnes de fiabilit disponibles et en respectant les objectifs de fiabilit que peuvent imposer les actions correctives de lAMDEC niveau systme. Les donnes dentre pour le calcul des autres probabilits peuvent donc tre une combinaison entre des objectifs de fiabilit (niveau systme) et des donnes ou hypothses concernant les sous-systmes (cest-dire provenant des feuilles de larbre). Lessentiel est de rester cohrent dans la pondration de larbre, notamment en respectant les formules basiques de calcul des probabilits vis--vis des fonctions logiques (revoir Figure III.11). On utilise le terme de budget de fiabilit [Lindsay & al., 2000] pour dsigner la marge de fiabilit disponible restant attribuer aux sous-systmes dont on na aucune donne a priori.
4.3.3. Etape 3 : Analyses des dfaillances des sous-systmes

La troisime tape de la mthode consiste en la ralisation de plusieurs AMDEC, appliques au niveau sous-systme. Les modes de dfaillances des sous-systmes utiliss ltape 2 rapparaissent travers ces AMDEC (par principe des analyses AMDEC). En fait, pour une cause systme donne, il est ncessaire de raliser une AMDEC pour chaque soussystme dont au moins un mode de dfaillance intervient dans larbre de dfaillances de la cause systme en question. Une fois que cette phase est termine, linformation utile pour notre mthode provient des relations entre les modes de dfaillances des sous-systmes et les actions correctives du niveau sous-systme.
4.3.4. Etape 4 : Synthse

La quatrime et dernire tape de la mthode est la synthse qui fournit la dclinaison des exigences de sret de fonctionnement niveau systme en exigences niveau soussystme. Dans les tapes prcdentes, des liens de 3 types diffrents ont t crs : Entre les causes systme et les actions correctives systme, Entre les causes systme et les modes de dfaillances sous-systme, Entre les modes de dfaillances sous-systme et les actions correctives sous-systme.
Ces diffrents liens permettent de relier les actions correctives systme aux actions correctives sous-systme. En traduisant les actions correctives par des exigences de sret de fonctionnement, nous obtenons des relations entre des exigences de sret de fonctionnement niveau systme et des exigences de sret de fonctionnement niveau soussystme.
5. Formalisation UML
Nous allons, dans la section qui suit, proposer une formalisation possible de la mthodologie laide dUML. Cela revient dfinir un modle conceptuel liant les diffrents concepts utiliss, tels que les modes de dfaillances, les effets, les causes, les actions correctives, etc. 80
Chapitre 3
Lintrt de cette formalisation est double. Tout dabord, elle permet de bien poser et montrer la relation entre les diffrentes notions, ce qui permet de clarifier la comprhension de la mthode. Le deuxime intrt serait pour une implmentation ventuelle de la mthode dans un outil informatique. Le modle faciliterait alors limplmentation de loutil, notamment concernant la base de donnes manipuler. Nous allons donc prsenter le modle conceptuel ralis pour la mthode. Mais pour arriver au modle complet, il a t ncessaire de formaliser lAMDEC et les arbres de dfaillances.
5.1. Formalisation de lAMDEC

La formalisation UML de lAMDEC que nous avons ralise est visible Figure III.13. Brivement, on retrouve le fait quune cause implique un (ou plusieurs) mode de dfaillance, qui lui-mme peut provoquer un effet.
Figure III.13 : Formalisation de lAMDEC en UML
Explication du modle conceptuel : Un systme se dcompose en sous-systmes, qui eux-mmes peuvent tre considrs comme des systmes. Chaque systme offre un ensemble de fonctions. Une fonction possde des modes de dfaillance. Des causes impliquent ces modes de dfaillance. Les modes de dfaillance provoquent des effets. Une cause possde une frquence et un effet possde une gravit. La combinaison de la frquence dune cause avec la gravit dun effet impliqu est source dune criticit. Selon les cas, une criticit ncessite des actions correctives, qui vont agir sur la frquence et/ou la gravit.
5.2. Formalisation de lArbre de Dfaillances

La formalisation de larbre de dfaillance en UML est donne par la Figure III.14. Elle fait intervenir des vnements. Ceux-ci peuvent tre des causes ou des modes de dfaillance, mais pas uniquement puisque des vnements intermdiaires entre les 81
Chapitre 3
causes dun systme et les modes de dfaillance des sous-systmes peuvent tre dfinis. Lautre concept qui apparat est celui de porte logique , qui peut tre de type ET, OU, voire dautres types (OU EXCLUSIF, OU PRIORITAIRE, ET PRIORITAIRE,).
Figure III.14 : Formalisation de larbre de dfaillance en UML
Un vnement peut donc tre racine (c'est--dire en sortie) pour une porte logique et/ou feuille (c'est--dire en entre) pour une autre porte logique. Les termes racine et feuille sont utiliss ici pour rappeler que lon construit un arbre.
5.3. Formalisation de la mthodologie complte

Pour la formalisation de la mthodologie complte, il sagit dintgrer les deux diagrammes prcdents dans un seul schma. A cela, il faut ajouter le fait que les actions correctives sont sources dexigences de sret de fonctionnement. Ces exigences sont prendre en compte pour la conception du systme, elles sont donc alloues au systme. Au final, le diagramme de la Figure III.15 formalise tous les concepts de la mthode dans un diagramme de classes UML.
Figure III.15 : Formalisation UML des concepts de la mthode AMDEC+AdD
82
Chapitre 3
6. Cas dtude
Afin dillustrer la mthodologie de dclinaison dexigences de sret de fonctionnement expose dans ce chapitre, nous lappliquons un cas dtude simple. Nous ne dclinerons quune seule exigence de sret systme pour cet exemple. Un exemple plus complet sera prsent dans le chapitre 5.
6.1. Prsentation de lexemple

Le systme tudi est celui dun ascenseur, constitu dune cabine mobile suspendue un cble dans une cage. Un sous-systme de contrle du mouvement (incluant un treuil actionn par un moteur lectrique) permet de mouvoir le cble rattach un contrepoids lautre extrmit. La cabine comporte une porte automatique qui actionne aussi louverture de portes palires. Un ensemble de pupitres de commande, dont un est situ lintrieur de la cabine et les autres se trouvent prs des portes palires, permet de grer les demandes de mouvements de lascenseur. Un sous-systme de ventilation garantie la qualit de lair dans la cabine. Pour finir, quelques dispositifs de scurit sont prsents : un capteur de prsence dans la zone de fermeture de la porte automatique, un interphone prsent dans la cabine et des freins durgence sur le toit de la cabine.
Figure III.16 : Systme ascenseur
6.2. Application de la mthodologie

Nous allons maintenant appliquer la mthodologie de dclinaison dexigences de sret de fonctionnement ce systme ascenseur .

La premire tape consiste procder une AMDEC au niveau du systme ascenseur . Dans la prsentation de cet exemple, nous ne montrons que le mode de 83
Chapitre 3
dfaillance descente non-matrise de la fonction transporter les usagers de lascenseur. La Figure III.17 prsente alors le tableau AMDEC reprsentatif de cette tude.
Figure III.17 : AMDEC systme ascenseur - fonction transporter les usagers
Daprs ce tableau, nous pouvons identifier une exigence de sret au niveau systme : La descente non-matrise lie la chute de la cabine doit avoir une frquence < 10-9/h . Cette exigence est lie la cause systme : chute de la cabine , qui va tre tudie dans la deuxime tape de la mthode.

Pour la deuxime tape, nous devons analyser toutes les causes systme identifies lors de la premire tape. Dans la prsentation de cet exemple, nous ne considrons que la cause systme chute de la cabine visible dans le tableau AMDEC de la Figure III.17. Nous construisons alors un arbre de dfaillance partant de cette cause systme et faisant intervenir les modes de dfaillances des sous-systmes, donn en Figure III.18.
Figure III.18 : Arbre de dfaillance de la cause systme chute de la cabine
Ainsi, daprs la figure, la chute de la cabine fait intervenir la dfaillance du soussystme de contrle du mouvement (commande de descente non-souhaite), la dfaillance du cble (rupture) et la dfaillance des freins durgence (non-fonctionnement).

La troisime tape de la mthodologie de dclinaison des exigences de sret veut que nous procdions des AMDEC pour tous les sous-systmes qui interviennent dans les arbres de dfaillances de la seconde tape. Les sous-systmes qui interviennent dans larbre de la Figure III.18 sont : le soussystme de contrle du mouvement, le cble et les freins durgence. La Figure III.19 donne 84
Chapitre 3
les rsultats de lAMDEC pour le sous-systme de contrle du mouvement. Cest lunique tableau AMDEC sous-systme que nous prsentons dans ce mmoire.
Figure III.19 : AMDEC sous-systme de contrle du mouvement
Daprs ce tableau, nous pouvons identifier une exigence de sret au niveau du soussystme de contrle du mouvement : La commande de descente non-souhaite lie au mode de commande bloqu dans ltat de descente doit avoir une frquence < 10-7/h . Cette exigence est lie au mode de dfaillance du sous-systme de contrle du mouvement : commande de descente non-souhaite . Des AMDEC pour le cble et les freins durgence permettraient didentifier respectivement les exigences : La rupture du cble doit avoir une frquence < 10-7/h , pour le cble. Le non-fonctionnement des freins durgence doit avoir une frquence < 5.10-3/h , pour les freins durgence.

Dans la quatrime tape, la synthse permet de montrer la dclinaison des exigences de sret au niveau systme en exigences de sret sous-systme. Nous donnons ici lexemple de dclinaison qui correspond larbre de dfaillance de la Figure III.18 et qui est synthtis en Figure III.20.
Figure III.20 : Synthse de la dclinaison des exigences du systme ascenseur
L'exigence de sret systme La descente non-matrise lie la chute de la cabine doit avoir une frquence < 10-9/h est dcline au niveau sous-systmes en : Pour le sous-systme de contrle du mouvement : o La commande de descente non-souhait li au mode de commande bloqu dans ltat de descente doit avoir une frquence < 10-7/h Pour le cble : o La rupture du cble doit avoir une frquence < 10-7/h 85
Chapitre 3
Pour les freins durgence : o Le non-fonctionnement des freins durgence doit avoir une frquence < 5.10-3/h
6.3. Utilisation de la formalisation UML

La formalisation UML, prsente au paragraphe 5.3, permet de poser les concepts manipuls dans la mthodologie de dclinaison, tout en prsentant les relations entre ces concepts. Nous donnons en Figure III.21, sur la base de lexemple du systme ascenseur , un diagramme des objets qui instancient les classes du diagramme de la formalisation. Comme lors de ltape 3 de lapplication de la mthodologie de dclinaison dexigences (prsente au paragraphe 6.2.3), nous nous sommes limits un seul sous-systme : celui du contrle du mouvement.
Figure III.21 : Diagramme dobjets de la formalisation UML pour lexemple du systme ascenseur
86
Chapitre 3
Partant du systme S1, lascenseur, nous avons tudi la fonction F1 : transporter les usagers . Nous nous sommes intresss un mode de dfaillance de cette fonction : le mode MdD1 de descente non-matrise . Lidentification de son effet E1, crash de la cabine entrainant une mort possible de ces usagers , permet de dfinir une gravit G1, catastrophique. Lidentification dune cause C1, chute de la cabine , nest associe aucune frquence connue. Ainsi, une action corrective AC1 qui agit sur la frquence est dfinie : faire en sorte que la frquence soit < 10-9/h . Cette action corrective est source de lexigence de sret Exigence1 : la descente non-matrise lie la chute de la cabine doit avoir une frquence < 10-9/h , qui doit tre satisfaite par le systme S1, lascenseur. La cause C1 est lie une porte logique ET qui combine le mode de dfaillance MdD4, non-fonctionnement des freins durgence , avec lvnement Ev1, descente de la cabine non-contrle . Cet vnement Ev1 est lui-mme li une autre porte logique OU qui combine les modes de dfaillance MdD3, rupture du cble , et MdD2, commande de descente non-souhaite . Ce dernier mode de dfaillance MdD2 est li une fonction F2, monter/descendre la cabine , du systme S2 de contrle du mouvement , sous-systme du systme S1. Lanalyse de ce mode de dfaillance MdD2 a permis didentifier une cause C2, mode de commande bloqu dans ltat de descente , et son effet E2 : hors de contrle, la cabine descend de manire non-matrise, entrainant son crash possible . La cause C2 nest associe aucune frquence connue, quant leffet E2, sa gravit G2, hasardeux, est dtermine. Sur cette base, une action corrective AC2 qui agit sur la frquence est dtermine : faire en sorte que la frquence soit < 10-7/h . Cette action corrective est source de lexigence de sret Exigence2 : la commande de descente non-souhaite lie au mode de commande bloqu dans ltat de descente doit avoir une frquence < 10-7/h , qui doit tre satisfaite par le systme S2, sous-systme de contrle du mouvement.
7. Bilan de la mthodologie et complment

La mthodologie propose, dans son tat actuelle (Combinaison dAMDEC et dAdD), aide donc la dfinition dexigences de sret de fonctionnement niveau systme, puis permet la dcomposition et lallocation de ces exigences sur les sous-systmes. Mais cette dcomposition et allocation dexigences ne concernent en fait que les exigences qui agissent sur la frquence, ceci travers les liens causes-effets des arbres de dfaillances. Il sagit de soccuper aussi des exigences qui traitent de la gravit des effets. Le problme est le suivant : on considre quun mode de dfaillance dune fonction systme apparat, que peut-on faire pour en rduire les effets ? La rponse vient en ajoutant des mesures de protection ou des fonctions de scurit qui vont empcher la dfaillance daboutir un accident ou tout du moins rduire la gravit de laccident. Les nouvelles mesures/fonctions sont dfinies travers des actions correctives traductibles en exigences de sret de fonctionnement, qui sapparentent des exigences fonctionnelles. Ainsi, les risques associs aux modes de dfaillance sont traits par ces exigences de sret que lon adjoint aux exigences qui dfinissent les mesures de protection dj prsentes. Toutes ces exigences sont au dpart dfinies au niveau systme, et vont tre 87
Chapitre 3
traites de la mme manire que la partie fonctionnelle du systme. Il ny a donc pas dautres mthodes spcifiques pour la dclinaison de ces exigences sur des sous-systmes. Cette dclinaison va se faire classiquement avec les processus standard de lingnierie systme. En revanche, pour aider lidentification des mesures protectives, une mthode possible consiste utiliser des arbres dvnements (event trees) [Villemeur, 1988]. Elle complte lAMDEC et montre de faon synthtique quelles mesures de protection permettent de contrer les effets dun mode de dfaillance. Sen suit alors la dfinition dactions correctives, et donc dexigences de sret de fonctionnement, qui agissent sur la gravit des modes de dfaillances. Dans une dmarche de conception de systmes complexes, SysML semble tre un langage de modlisation de plus en plus utilis. A ce propos, la mthodologie que nous venons de prsenter peut sappuyer sur les travaux de [David & al., 2010] qui sintressent la fiabilit des systmes complexes en utilisant SysML, en particulier pour la prparation de lAMDEC. Ces travaux offrent la possibilit dextraire des diagrammes SysML fonctionnels les informations ncessaires aux tudes de risques.
8. Conclusion
Dans le cas des systmes complexes, un systme est gnralement dfini comme la composition des sous-systmes qui interagissent de manire non intuitive pour satisfaire un certain nombre de fonctions et rpondre un ensemble dexigences. Dans ce chapitre, il a t question de dfinition dexigences de sret et de la gestion de ces dernires diffrents niveaux du systme. Nous avons alors prsent une mthodologie de dclinaison qui permet dobtenir une traabilit et une dclinaison rigoureuse entre les exigences de sret dfinies au niveau systme et celles dfinies au niveau sous-systmes , ceci en plus daider cette dfinition dexigences. Elle est base sur des mthodes courantes de sret que sont lAMDEC et lanalyse par arbre de dfaillance. Cette mthodologie constitue un vritable atout vis--vis dune conception sre, en renforant la prise en compte de la sret dans le processus de conception. Elle apporte une rponse aux problmes de conception vus dans la problmatique lis la dfinition des exigences de sret, leur gestion et leur traabilit. Le chapitre suivant continue dans ce sens, en fournissant un appui la conception au travers dun modle dinformation contenant des donnes dingnierie et des donnes de traabilit.
88
Chapitre 4
Vers une mthodologie ISDM
IV.
Chapitre 4 : Vers une mthodologie ISBM

1. Introduction
Afin damliorer la gestion des exigences de sret et rpondre des faiblesses concernant la conception de systmes complexes srs, nous proposons dans ce quatrime chapitre dappuyer notre dmarche par un modle dinformation. Ceci revient orienter la dmarche vers une mthodologie dIngnierie Systme Base sur les Modles (ISBM). Le contenu du chapitre commence alors par une section sur lISBM, la dfinition et lintrt dun modle dinformation ainsi quun tat de lart du domaine. Suit la principale section du chapitre qui prsente notre modle base du langage SysML. Le choix de ce langage est justifi et les diffrentes extensions sont prsentes. Pour terminer, une section propose des complments aux modles sous forme danalyses possibles mettre en uvre.
2. Modle dinformation et ISBM

Dans cette premire section, nous prsentons le concept dIngnierie Systme Base sur les Modles (ISBM) et lapport que peut avoir cette dernire dans la conception de systmes complexes. Nous discutons ensuite de modle dinformation qui permet doutiller cette ISBM. Aprs avoir dfini le modle dinformation, nous expliquons son intrt et son apport vis--vis des activits de gestion des exigences, mais aussi pour communiquer entre les diffrentes quipes impliques dans la conception. Suit un tat de lart relatif aux modles dinformation, exposant les travaux les plus significatifs du domaine. Puis, nous prsentons un principe de bonne conception qui est fortement conseill par les autorits de sret. Les recommandations de ces autorits sont prises en compte dans la dfinition de notre modle dinformation qui est prsent dans ce chapitre.
2.1. Ingnierie Systme Base sur les Modles (ISBM)

LIngnierie Systme Base sur les Modles (ISBM), en anglais Model Based System Engineering, propose de sappuyer fortement sur les modles, ceci pour toutes les tapes du cycle de dveloppement (partant des spcifications et allant jusquaux tests dintgration) [Estefan, 2008]. Le suivi dune mthodologie dISBM permet de guider la conception avec lutilisation de tels modles pour telles tapes du cycle de conception.
89
Chapitre 4
LINCOSE prsente lISBM comme lapplication formelle des techniques de modlisation pour raliser les activits de spcification systme, de conception, danalyse, de vrification et de validation, en partant de la phase de conceptualisation, tout au long du dveloppement, et sur lensemble des phases du cycle de vie [INCOSE, 2007]. Avec lISBM, il est question de remplacer les approches de conception essentiellement base sur des documents par des approches compltes dingnierie systme bases sur des modles (voir Figure IV.1).
Figure IV.1 : Transition entre lIS centre sur les documents et lIS centre sur les modles
En fait, les promesses du dveloppement bas sur la modlisation sont nombreuses [Friedenthal & al., 2008] : Formaliser la pratique de lingnierie systme travers lutilisation de modle. Intgrer diffrents domaines de modlisation du systme. Amliorer la communication : o faciliter la comprhension du systme tous les participants, o constituer des documents de rfrence pour les fournisseurs et sous-traitants. Amliorer la qualit des produits : o dtecter les erreurs plus tt, o assurer que toutes les exigences sont satisfaites, o apporter de la rigueur et de la prcision. Matriser les cots de dveloppement et les plannings : o prendre en compte les changements durant la dure de vie du projet, o permettre une gestion fine et efficace des ressources, o acclrer les dveloppements et la mise sur le march des produits. Grer et matriser la complexit.
En rsum, lISBM veut faire progresser lIngnierie Systme dans de nombreux domaines tels que la communication, la prcision des analyses, lintgration des rsultats , la rutilisation des connaissances produites mais surtout la maitrise de la complexit. Nous avons rduit de 20% 50% selon les projets, nos cots de dveloppement ds la premire anne dutilisation de Rhapsody associ notre outil de gestion des exigences Doors dclarer un dirigeant dune compagnie de tlcommunication (Leader Telecom). Comme le montre la Figure IV.2, lISBM implique que tous les participants un projet de conception (Clients, sous-traitants, concepteurs) travaillent sur des modles, ceci pour toutes les tapes du cycle de dveloppement le permettant (de Material Solution 90
Chapitre 4
Analysis Operations & Support , voir Figure IV.2). En fait, les modles sont prsents tous les niveaux : aussi bien pour les conceptions dtailles des diffrents mtiers (mcanique, lectrique, logiciel), que pour les analyses des diffrentes spcialits transverses (telle que la sret de fonctionnement), mais aussi et surtout au niveau du systme. Pour ce dernier niveau, on parle de modle systme, qui est le point central de la conception du systme. En effet, ce modle se trouve la jonction et fait le lien entre les exigences des parties prenantes, les analyses du systme, la conception dtaille et les aspects de documentation (voir Figure IV.3 extrait de [David, 2009]).
Figure IV.2 : ISBM tout au long du cycle de dveloppement
Figure IV.3 : Modle du systme au centre de lI.S.
91
Chapitre 4
Cest donc pour se rapprocher dune IS base sur les modles que nous proposons dans ce chapitre un modle dinformation qui rassemble lensemble des donnes dingnierie au sein dun modle commun. Ce modle, qui permettra de remplacer de nombreux documents, se situe parfaitement au niveau du modle du systme de la Figure IV.3.
2.2. Dfinition dun modle dinformation

Nous proposons la dfinition suivante pour la notion de modle dinformation, plus connu dans le pass sous le nom de modle de donnes : Dfinition : Un modle dinformation correspond une base de donnes dans laquelle sont stockes toutes les connaissances produites par lactivit lie ce modle, ceci avec une smantique prcise et des relations logiques dfinies entre ces connaissances. Dans notre cas, nous utilisons ce concept de modle dinformation dans la conception systme. Les connaissances produites peuvent alors correspondre toutes sortes de donnes dingnierie. Pour nen citer que quelques-unes, nous pouvons retrouver les exigences, les composants logiques, les composants physiques, les interfaces, les fonctions, etc. Des exemples de relations entre ces donnes, que nous dtaillerons plus loin, peuvent tre une relation dallocation entre une fonction et un composant, ou encore une re lation de satisfaction entre une exigence et une fonction. De plus, chacune des donnes peut avoir une structure particulire constitue de diffrents champs prdfinis de type dtermin. Par exemple, pour une exigence il est possible de la structurer en dfinissant des champs partie prenante , description et justification de type chane de caractres, ou encore un champ priorit qui prendrait des valeurs entires dans lintervalle [0, 5] par exemple.
2.3. Intrt dun modle dinformation

2.3.1. Appuyer la gestion des exigences
Dans le premier chapitre de cette thse, nous avons vu limportance des activits de gestion des exigences pour le bon droulement dun projet [Juristo & al., 2002], vu le nombre important de documents qui sont produits lors de la conception dun systme. Sans cette gestion des exigences, il serait extrmement difficile de garantir la cohrence et la qualit ncessaire au succs du projet de conception dun systme complexe. Appuyer la gestion des exigences par un modle dinformation apporte un soutien considrable au droulement du projet. En effet, le modle peut contenir toutes les donnes dingnierie systme, dont notamment toutes sortes dexigences. Il facilite lexpression des donnes en leur donnant une structure particulire et permet des liens logiques entre ces donnes (ou par les donnes elles-mmes) pour justifier leur existence. Mais encore, un modle dinformation participe la collecte des donnes, facilite leur partage, permet de dtecter au plus tt les incohrences, permet de grer la validation des donnes et aide la gestion de changement dans les donnes (par exemple un changement dexigence). Il permet aussi, travers des indicateurs dans la structure des donnes, dvaluer la progression du projet, par exemple en suivant lvolution des tats de maturit des 92
Chapitre 4
exigences qui doivent tre dfinies, dclines, alloues, satisfaites, vrifies ou encore justifies. En fait, lavantage principal utiliser un modle dinformation pour la gestion des exigences provient de la gestion rigoureuse de la traabilit possible grce un tel modle. Il permet de formaliser cette traabilit qui peut dailleurs tre ralise de bout en bout, partant des besoins initiaux et allant jusquaux lments les plus fins et dtaills de la conception, sans oublier les procdures ou cas de tests. Concernant le modle dinformation propos plus tard dans ce chapitre, celui-ci va sappuyer en partie sur la vision des exigences dans la norme EIA-632 dj prsente dans le chapitre 2, paragraphe 3.4.5 (voir Figure IV.4). Les exigences techniques, provenant des exigences des parties prenantes, conduisent aux reprsentations des solutions logique et physique, qui elles-mmes sont sources de nouvelles exigences appeles exigences techniques drives. Puis la solution de conception rpondant lensemble des exigences techniques est fige par des exigences spcifies.
Figure IV.4 : Relation entre les exigences dans lEIA-632
2.3.2. Partager les connaissances

Un modle dinformation est la base des connaissances systme du projet de conception, permettant le partage des donnes entre tous les domaines de comptence (mcanique, hydraulique, thermique, lectrique, ). Il permet entre autres le partage des connaissances entre ingnieurs de conception et ingnieurs de sret. En effet, la conception de systme donne lieu une accumulation de documentations qui doivent toutes tre croises et mises jour pour maintenir la cohrence et respecter les spcifications du systme. Un modle dinformation est un moyen de regrouper dans un modle commun tous les corps de mtiers, les spcifications, les contraintes et les paramtres de l'ensemble 93
Chapitre 4
du systme. Il est donc destin modliser le niveau systme , en exhibant ses interactions avec lenvironnement ainsi que les connexions entre les diffrents sous systmes. En fait, les avantages apports par un modle dinformation sont nombreux, dont notamment : Un partage des spcifications d'un systme complexe entre tous les corps de mtiers. Lidentification des risques et la cration d'une base d'analyse commune tous les participants d'un projet. Facilite la gestion de projets complexes, l'volutivit et la maintenabilit des systmes complexes. Documente et capitalise le savoir de tous les corps de mtiers dans un projet.
Le modle dinformation doit tre vu comme un moyen de mise en commun des connaissances, incluant les trois volets : exigences, solution de conception et V&V (Vrification et Validation). Il est considrer comme un vritable niveau dinterconnexion entre les diffrents mtiers, comme le reprsente la Figure IV.5.
Figure IV.5 : Le modle dinformation : un niveau dinterconnexion
2.3.3. Supporter la conception

Les deux points prcdents participent dj au fait quun modle dinformation fournit un vrai support la conception du systme. Mais plus encore, le fait mme de modliser les connaissances laide du modle permet la transformation plus ou moins progressive des besoins en la dfinition du systme concevoir. Durant cette transformation, un passage graduel se fait depuis des concepts abstraits vers une dfinition rigoureuse du systme. Il convient de distinguer deux domaines distincts dans la modlisation : lespace du problme et lespace des solutions possibles. Vraisemblablement, au dbut du projet lespace de reprsentation du problme est plus important que celui de reprsentation des solutions possibles. Au fur et mesure de lavancement de la conception, lensemble de reprsentation des solutions possibles senrichit peu peu, pour aboutir la dfinition rigoureuse du systme. En parallle, lensemble de reprsentation du problme senrichit afin de mieux dfinir les attentes du systme (besoins/exigences) jusqu se stabiliser. (cf. Figure IV.6)
94
Chapitre 4
Figure IV.6 : Rpartition des domaines au cours de la modlisation
Dailleurs, la transition entre le domaine du problme et celui de la solution est un point trs dlicat de lingnierie systme. Elle doit sexprimer par des allocations dexigences, de proprits ou de contraintes sur des lments de solution possible. Ces allocations engendrent des liens de traabilit qui sont cruciaux pour les tapes de vrification et validation du systme. En consquence, lutilisation dun modle dinformation permet aussi de rduire le foss entre le domaine du problme et celui de la solution, ceci laide de liens de traabilit.
2.3.4. Synthse
Pour rsumer, une manire de rendre efficace la gestion des exigences est de sappuyer sur un modle dinformation qui serait la base et le cur de connaissance du projet de conception, et sur lequel on va sappuyer pour : guider la conception, dfinir tt et bien les exigences, grer rigoureusement la traabilit des exigences, grer les modifications/changements dexigences, raliser les analyses dimpacts, valuer lavancement du projet, comprendre le systme, ceci sur la base dun langage commun comprhensible par tous et dun modle partag, passer progressivement du domaine du problme celui de la solution, rutilisation des modles existants pour supporter lvolution technologique,
En fait, vis--vis de notre problmatique de conception de systmes srs, il faut garder lesprit que tout ce qui contribue un systme de dveloppement meilleur (ou systme pour faire) il peut sagir du projet, de son organisation et de son droulement constitue un facteur positif pour llaboration du bon systme dvelopper (ou systme faire). Ici, lutilisation dun modle dinformation est clairement un facteur positif pour une bonne conception.
95
Chapitre 4
2.4. Travaux relatifs aux modles dinformation

2.4.1. MeMVaTEx
Le projet MeMVaTEx [Albinet & al., 2007] [Albinet & al., 2008], signifiant Mthode de Modlisation pour la Validation et la Traabilit des Exigences, regroupe un ensemble de partenaires acadmiques (CEA, INRIA/UNSA, CNRS, UTC/HEUDIASYC) et de partenaires industriels (Siemens VDO, Embelec). Dans le domaine des systmes temps rel embarqus, lobjectif du projet tait de dfinir une mthodologie pour la modlisation des systmes en prenant en compte lexpression des exigences et leur traabilit tout au long du processus de conception. Finalement plutt destine au monde logiciel, la mthodologie se base sur le langage EAST-ADL et sur deux profils UML 2.0 : le profil MARTE pour le temps rel et le profil SysML pour la modlisation des exigences. MeMVaTEx propose galement quelques extensions ces langages. Par exemple, la dfinition dun nouveau strotype pour les exigences par un mcanisme dhritage permet dassocier de nouveaux attributs pour les exigences (voir Figure IV.7). Dans ce projet, il tait aussi question de modliser les trois aspects : exigences, solution et V&V, de manire spare mais au sein dun mme formalisme [Albinet & al., 2008].
Figure IV.7 : Exigence MeMVaTEx
2.4.2. Modle de donnes de lAFIS

LAFIS (Association Franaise dIngnierie Systme) propose son propre modle de donnes (ou modle dinformation) pour la conception systme en ingnierie s ystme. Il prsente de nombreux aspects, notamment en se plaant dans plusieurs vues diffrentes : La vue des concepts gnraux, La vue affaire, La vue dingnierie : dfinition darchitecture (voir Figure IV.8), La vue dingnierie : exigences, La vue dingnierie : gestion de configuration, La vue dingnierie IVV. 96
Chapitre 4
Figure IV.8 : Vue dingnierie de dfinition darchitecture systme (AFIS)
Ce modle est prsent dans un document de lAFIS du groupe de travail MO (Mthodes et Outils) [AFIS, 2005b]. En complment, il existe des fiches qui dtaillent de manire plus fine la description des donnes dingnierie. Par exemple, la fiche n3 du groupe de travail IE (Ingnierie des Exigences), intitule un modle de donnes pour la description dexigences , dcrit les proprits caractristiques des exigences. Elle fournit aussi un ensemble de liens entre les exigences et dautres objets de lingnierie systme (justification, source, condition, risque, compromis, produit, vrification) (voir Figure IV.9).
Figure IV.9 : Extrait fiche n3 AFIS : un modle de donnes pour la description dexigences
97
Chapitre 4
2.4.3. Modle de MAP Systme

[MAP Systme] est une socit indpendante de conseil en Ingnierie Systme, fonde par Alain Faisandier et Thrse Renard. Ses consultants ont une longue exprience professionnelle qui leur permet davoir de solides connaissances et un recul important dans le dveloppement, la mthodologie, le management, lassurance qualit, la matrise douvrage et la matrise duvre des systmes complexes civils et militaires des secteurs des tlcommunications, du spatial, du nuclaire, de laronautique, de lautomobile, du biomdical et de linformatique. Ils se sont galement intresss la question de conception de systmes srs de fonctionnement, mais en sappuyant sur les processus dingnierie systme de la norme ISO-15288 (voir Figure IV.10). Ils se sont appuys en partie sur le guide de la sret de fonctionnement de Jean-Claude Laprie, avec les processus de dveloppement sret de fonctionnement explicite et la liste des points cls identifis du guide. Pour appuyer la dmarche, ils ont aussi dfini un modle de donnes (voir Figure IV.11) [Faisandier, 2008], qui distingue 3 volets : le domaine du problme (besoins, exigences, ), le domaine fonctionnel et le domaine organique. Ils ajoutent ensuite un quatrime volet qui est celui de la sret de fonctionnement, incluant notamment les notions de risque et de danger .
Figure IV.10 : Vue gnrale des processus IS - MAP Systme
En plus de la vision processus et du modle de donnes, MAP Systme a dvelopp un outil, qui sappuie sur le modle de donnes. Il intgre tous les aspects, des exigences aux constituants, en passant par les fonctions. Loutil propose aussi un certain nombre de pattern de sret de fonctionnement, qui sont disponibles dans une librairie et utilisables par le concepteur. Par exemple, il existe le pattern de la redondance double
98
Chapitre 4
active, ou encore celui de la redondance double passive. Bien entendu, le concepteur a la possibilit de construire son propre pattern.
Figure IV.11 : Mta-modle gnrique de lIngnierie Systme de MAP Systme
2.4.4. DoDAF et MoDAF

Le DoDAF (Department of Defense Architecture Framework) a t conu par le dpartement de la dfense amricaine. Il a pour objectif dassister la conception, le dveloppement et lacquisition de systmes ou systmes de systmes structurs hirarchiquement. En fait, le DoDAF fournit un cadre darchitecture destin au dveloppement dune architecture de systmes ou dune architecture dentreprise. Ce cadre darchitecture comporte deux couches : celle des donnes, pour les lments entits, relations et attributs, celle de prsentation, pour les vues et les produits.
Le rfrentiel est dfini par le Core Architecture Data Model 2.0 (CADM, essentiellement un schma de base de donnes commun) (voir Figure IV.12) et le systme de rfrentiel de larchitecture du DoD (DARS). Les vues permettent de visualiser larchitecture de donnes en organisant les donnes logiquement dans une perspective spcifique. Quant aux produits, ils sont un moyen de visualiser larchitecture de donnes par des graphiques, des tables ou des textes. Somme toute, un des intrts principaux de DoDAF est de rendre possible lchange dinformation entres les diffrents groupes collaboratifs dutilisateurs pour atteindre leurs 99
Chapitre 4
objectifs partags. Il sagit donc dapporter un vocabulaire commun aux diffrentes quipes afin de faciliter les changes dinformations.
Figure IV.12 : Vue conceptuelle principale du Core Architecture Data Model 2.0
Le MoDAF (Ministry of Defense Architecture Framework) est, quant lui, bas sur le DoDAF, mais ralis par le ministre de la dfense du Royaume-Uni. Il contient en fait dautres vues, spcifique aux besoins du MoD.
2.4.5. Snow Card Volere

Volere est une marque dpose appartenant Atlantic Systems Guild. Cette organisation est un centre de connaissance, de conseil et dorganismes de formation rpartis entre Londres, Aachen et New York. Son objectif est de rester lavant -garde du dveloppement et de lingnierie des systmes. Volere est en fait le nom donn un ensemble de ressources dexigences, qui couvrent des cours, des modles, des livres ou encore des processus. Pour notre travail, nous avons retenu de cet ensemble la proposition de reprsentation dune exigence, appele SnowCard Volere ou Atomic Requirement [Volere], visible en Figure IV.13. Lexigence Volere est alors compose de : Un identifiant unique, Un type, qui peut tre choisi laide du Template Volere [Roberston, 2010] qui propose la classification suivante : o Exigences fonctionnelles o Exigences non-fonctionnelles : dapparence, 100
Chapitre 4
de convivialit et dergonomie, de performance, oprationnelles et denvironnement, de maintenabilit et de support, de scurit, culturelles et politiques, lgales ou juridiques. La description de lexigence, La justification de lexigence, Linitiateur de lexigence, qui correspond une des parties prenantes, Un critre de satisfaction qui fournit une aide pour savoir si la solution remplit lexigence, Le degr de satisfaction de la partie prenante dans le cas o lexigence est implmente (de 1 pour indiffrent 5 pour trs satisfait), Le degr dinsatisfaction de la partie prenante dans le cas o lexigence nest pas implmente (de 1 pour importe peu 5 pour trs mcontent), La priorit qui indique limportance relative de lexigence, Les conflits qui informent des exigences qui ne peuvent pas tre implmentes si celle-ci lest, Une liste des documents lappui qui illustrent et expliquent davantage lexigence, Un historique.
Figure IV.13 : SnowCard Volere
2.4.6. Travaux du CRAN

Dominique EVROT [Evrot, 2008] propose un modle dinformation succinct, repris en Figure IV.14, partir dune vision inspire du modle de donnes de lAFIS [AFIS, 2005b]. 101
Chapitre 4
Celui-ci sinscrit dans le cadre du processus de dfinition du systme, o il est ncessaire dtablir des relations entre les exigences, les fonctions et/ou les composants du systme.
Figure IV.14 : Modle du systme faire de D. EVROT
Ce modle de traabilit liant les exigences aux composants du systme permet de raliser des analyses dimpacts dans le cas dvolutions dexigences. On est capable dvaluer les consquences de la modification dune exigence sur la scurit du systme partir du rseau tiss entre exigences, fonctions et composants.
2.4.7. Travaux du LAAS-CNRS

Dans le cadre de sa mthodologie de conception systme propose dans ses travaux de thse, Jean VERRIES [Verries & al., 2008] [Verries, 2010] a dvelopp un modle dinformation trs dtaill. Il fait bien la distinction entre la dfinition des donnes dingnierie, regroupes en diffrents ensembles, la dfinition des liens existants entre ces donnes, et la prsence de points de vue qui forment les modles de conception et danalyse.
2.4.8. Synthse
Nous constatons que de nombreux travaux se sont intresss la question dun modle dinformation. Plutt dfini pour le logiciel, MeMVaTEx nintgre pas de concept spcifique la sret de fonctionnement. Cependant, il propose de bonnes extensions pour les exigences et utilise le langage SysML. Le modle de lAFIS quant lui sintresse beaucoup au concept de vue. Il intgre de nombreux concepts, dont une partie sera exploite pour notre travail. Il en va de mme avec le modle propos par MAP Systme. Concernant les projets DoDAF et MoDAF, ils mettent en relation des concepts plus que des donnes dingnierie, mais lide de partage dinformation entre les diffrentes quipes est bien prsente. Dans les travaux de Volere, les champs dfinis par la snowcard et la classification en type des exigences pourront tre exploits. D. Evrot propose un premier modle dinformation trs succinct, dfini en UML et celle de J. Verries propose un modle dtaill concernant les exigences.
102
Chapitre 4
Notre proposition vient complter ces travaux, en dfinissant un modle centr sur les donnes dingnierie, redfinissant des exigences, intgrant des aspects de sret de fonctionnement et utilisant le langage SysML.
2.5. Triptyque exigences-solutions-V&V, principe de bonne conception

Au sujet de notre modle dinformation, dont lutilit a t justifie ci-dessus, nous souhaitons quil respecte un principe de bonne conception provenant des autorits de sret (voir [Albinet & al., 2008]). En effet, celles-ci imposent une sparation des concepts manipuls lors de la conception du systme. Les exigences, la solution de conception et les donnes concernant la V&V doivent tre dveloppes indpendamment. On fait dailleurs rfrence au triptyque exigences-solutions-V&V. Il faut donc pouvoir distinguer trs clairement ces diffrents concepts. Cette distinction peut tre retrouve dans des normes, par exemple dans la norme ISO-26262 [ISO-26262, 2008], adaptation prochaine de lCEI61508 [CEI-61508, 2010] au domaine de lautomobile. Afin dillustrer ce discours, la Figure IV.15 prsente ce qui ne doit pas tre fait ( gauche) et ce quil convient de faire ( droite).
v.s.
Figure IV.15 : Sparation des concepts manipuls
Or, le premier cas (celui de gauche) prsente tout de mme un avantage non-prsent dans le second. Il permet dattacher directement les exigences aux lments de solutions, par exemple en restant dans le mme formalisme. Lavantage du second cas, quant lui, est clair. Il permet une gestion efficace de chaque concept, appuye par des outils spcifiques. Ceci tant, le problme de cette approche est que les exigences sont gres de faon externe au processus de modlisation de la solution. Il ne facilite donc pas la comprhension et la revue des exigences par rapport aux quipes de dveloppement de la solution. Nous verrons que notre approche va, tout en respectant la sparation des concepts prvue par les autorits de sret, sinspirer des deux cas prcdents pour intgrer les deux avantages.
3. Modle propos
Dans cette section, nous prsentons tout dabord le langage SysML (System Modeling Language). Ensuite, nous dtaillons quelques points particuliers de ce langage, notamment concernant les relations lies aux exigences. Puis nous justifions le choix de SysML pour le modle dinformation que nous proposons [Guillerm & al., 2010c] et nous exposons nos extensions du langage. La prsentation de notre modle dinformation clt la section. 103
Chapitre 4
3.1. Le langage choisi : SysML

SysML [Bock, 2006] est l'ingnierie des systmes complexes et/ou htrognes ce qu'UML est l'informatique. Il doit permettre des acteurs de corps de mtiers diffrents de collaborer autour d'un modle commun pour dfinir un systme. La conception de systme donne souvent lieu une accumulation de documentations qui doivent toutes tre croises et mises jour pour maintenir la cohrence et respecter les spcifications du systme. SysML est un moyen de regrouper dans un modle commun tous les corps de mtiers, les spcifications, les contraintes, et les paramtres de l'ensemble du systme. SysML n'aborde plus la conception avec la notion de classes mais avec la notion de blocs qui deviendront des parties mcaniques, lectroniques, informatiques ou autres. SysML (System Modeling Language) est donc : Un langage de modlisation visuel pour lIngnierie Systme. Compatible avec UML pour lIngnierie Logicielle. Ce qui est parfaitement logique, puisque SysML est un DSL (Domain Specific Language) dUML pour le Systme , cest--dire une adaptation dUML. Un support la spcification, lanalyse, le design, la vrification et la validation dun large panel de systmes et de systmes de systmes . Ces systmes pouvant inclure du matriel, du logiciel, de linformation, des processus, du personnel et des services.
3.1.1. Historique
Voici un bref historique des mthodes, techniques ou langages de conception qui ont permis darriver jusqu SysML, en passant videmment par le langage UML (cf. Figure IV.16) : Dans les annes 1970, les premires mthodes d'analyse pour la conception systme apparaissent. Les annes 1980 annonce l'approche systmique, avec la modlisation des donnes et modlisation des traitements : Merise [Redouin, 1989], Axial, IE... Entre 1990 et 1995, il y a une vritable mergence d'une multitude de mthodes oriente-objets : Booch [Booch, 1993], Classe-Relation, Fusion, HOOD, OMT [Rumbaugh & al., 1990], OOA, OOD, OOM, OOSE [Jacobson, 1992] ... Lanne 1995 marquera les premiers consensus, tels quOMT (James Rumbaugh), OOD (Grady Booch) ou OOSE (Ivar Jacobson). Les annes 1995 1997 voit les premiers pas pour lunification et la normalisation des mthodes avec la naissance d'UML.
Ainsi, UML (Unified Modeling Language) [Booch & al., 2005] est n de la fusion des 3 mthodes qui ont le plus influenc la modlisation oriente objets au milieu des annes 90 : OMT (Object Modeling Technique). Mthode d'analyse et de conception oriente objets. Vues statiques, dynamiques et fonctionnelles d'un systme. OOD (Object Oriented Design). Vues logiques et physiques du systme.
104
Chapitre 4
OOSE (Object Oriented Software Engineering). Couvre tout le cycle de dveloppement. Une des plus anciennes mthodes objet focalise sur le modle statique.
Fin 1997, UML devient un standard OMG (Object Management Group). L'OMG est un organisme but non lucratif, cr en 1989 l'initiative de grandes socits (HP, Sun, Unisys, American Airlines, Philips...). Son rle est de promouvoir des standards qui garantissent l'interoprabilit entre applications orientes objet, dveloppes sur des rseaux htrognes. Puis UML samliore et senrichit progressivement pour atteindre la version UML 2.0 en 2004. Finalement, suite aux premires prmisses dun langage spcifique lingnierie systme ds 2001, cest en 2005 quune premire version de SysML voit le jour. Aujourdhui, la version actuelle du langage est SysML 1.2.
Figure IV.16 : Historique de SysML
3.1.2. Prsentation
SysML est une adaptation dUML 2 pour lingnierie systme. Plus prcisment, SysML rutilise une partie dUML, appele UML4SysML (interprter UML for SysML ), laquelle est ajoute une extension (voir Figure IV.17).
Figure IV.17 : Construction de SysML partir dUML 2
105
Chapitre 4
Pour dfinir SysML [Bock, 2005], 6 diagrammes ont t retirs des 13 diagrammes dUML. Il sagit des diagrammes de composants, dobjets, de dploiement, de vue densemble des interactions et de temps, qui sont trop orients pour le monde logiciel ou qui napporteraient rien de significatif lingnierie systme. Par ailleurs, 2 diagrammes ont t renomms : le diagramme de classes est remplac par le diagramme de dfinition de blocks et le diagramme de structure composite devient le diagramme de blocks internes. La notion de classe, sur laquelle on pouvait sappuyer pour crer des instances (cest--dire des objets), na pas t reprise pour le domaine de lingnierie systme, o celle-ci est substitue par la notion de block. Ainsi, un systme ou un composant sont dfinis par des blocks en SysML. Le diagramme dactivit a subi quelques modifications et le diagramme paramtrique a t ajout pour dfinir les relations entre les grandeurs physiques du systme. Le dernier point, certainement linnovation majeure de SysML, est le diagramme des exigences qui voit le jour. Il permet dintroduire les exigences systmes dans le modle, avec un certain nombre de liens de traabilit rendu possible entre des exigences ellesmmes ou entre des exigences et dautres lments de modlisation. La Figure IV.18 rsume ce paragraphe traitant de lensemble des diagrammes offerts par SysML.
Figure IV.18 : Les diagrammes de SysML
Finalement, travers un environnement unique intgrant les exigences et permettant la modlisation de la conception, SysML supporte diffrentes vues qui sont : les exigences, avec le diagramme des exigences, le comportement, avec les diagrammes des cas dutilisation, de squence, dactivits et de machine tats, la structure, avec les diagrammes de dfinition de blocks et de blocks internes, les contraintes, avec le diagramme paramtrique.
3.1.3. Strotype et block

Cette section prsente deux notions importantes de SysML, essentielles la prsentation de nos travaux.
106
Chapitre 4
Dans SysML, on voit apparaitre la notion de strotype. Les strotypes sont dfinis par des extensions de mta-classes qui permettent de dfinir de nouveaux lments de modlisation. En effet, la dfinition dun nouveau strotype fait partie de la mta modlisation : cest--dire de la modlisation de moyens de modlisation. Un strotype peut tre associ de nouvelles proprits (attributs) ou de nouvelles contraintes. Il permet en fait une extension smantique du langage. Nous verrons plus loin des exemples de strotypes dfinis dans SysML ou dfini par nous-mmes. La notion de classe disparait dans une modlisation SysML. Cet lment de base de la modlisation UML est remplac par la notion de block . Le block est ainsi llment qui va permettre de dcrire les architectures des systmes (composants, sous-systmes, systme). (En fait, dans le mta-modle SysML (profil de UML2.0), block est dfini comme un strotype.)
3.1.4. Traabilit avec SysML

Nous avons vu maintes reprises limportance de la traabilit lors de la conception dun systme complexe. Dans ce paragraphe, il sagit justement de prsenter les aspects de traabilit offerts par le langage SysML.
3.1.4.1.
Relations entre exigences
SysML permet 3 types de liens entre les exigences. Ceux-ci sont la composition, la drivation et la copie. La Figure IV.19 reprsente ces diffrents liens sur des exemples gnriques.
Figure IV.19 : Liens de traabilit entre exigences et exigences
Le lien de composition indique quune exigence est dcompose en plusieurs autres exigences. Avec ce type de lien, si les exigences filles sont satisfaites, alors lexigence mre lest aussi. Le lien de drivation (strotyp par deriveReqt) exprime une dpendance entre deux exigences.
107
Chapitre 4
Le lien de copie (strotyp par copy) reprsente la simple copie dune exigence. Cela permet de crer une exigence en lecture seule .
3.1.4.2.
Relations entre exigences et autres lments de modle
SysML dfinit galement des connexions entre les exigences et dautres lments de modle. Daprs le concept de traabilit utilis pour la conception de systmes, il est effectivement tout fait d-propos de proposer ce type de liens qui contribue rendre lensemble du modle SysML cohrent. Ces liens de connexion entre les exigences et dautres lments de modle sont au nombre de 3 (voir Figure IV.20).
Figure IV.20 : Liens de traabilit entre exigence et autres lments de modle
Le lien de satisfaction (strotyp par satisfy) signifie que llment du modle satisfait lexigence. Le lien de vrification (strotyp par verify) est utilis pour lier un TestCase une exigence. Ce lien signifie que lexigence peut tre vrifie par le TestCase en question, qui explique la mthode ou la procdure permettant la vrification (traduction franaise : cas de tests). Le lien de raffinement (strotyp par refine) permet dexpliquer plus en dtails une exigence, plus que le simple champ de description textuelle. Par exemple, un diagramme de machine tats peut expliciter plus clairement et synthtiquement lide du paragraphe textuel de lexigence.
3.1.4.3.
Relation dallocation Activits/Blocks
Le dernier type de lien que nous prsentons ici est celui dallocation (strotyp par allocate). Son usage le plus courant correspond lallocation dune fonction sur un composant, autrement dit : lallocation dune activit sur un block. Cette allocation peut se reprsenter sous de nombreuses formes dans les diagrammes SysML. Elle peut par exemple apparatre travers les attributs allocatedFrom et allocatedTo des blocks, ou plus simplement en utilisant un lien dassociation tagu du strotype allocate. Mais la faon le plus couramment utilise reste lutilisation des partitions dans les diagrammes dactivits (aussi appeles : swimlanes), comme le montre la Figure IV.21. Cela permet dallouer les 108
Chapitre 4
fonctions reprsentatives des activits prsentes dans la partition (ActionName dans la Figure IV.21) au block associ cette partition (ElementName dans la Figure IV.21).
Figure IV.21 : Liens de traabilit entre exigence et autres lments de modle
3.1.5. Justification du choix de SysML

Aprs avoir prsent trs rapidement le langage SysML (la spcification faisant plus de 250 pages), nous justifions le choix de ce langage pour notre problmatique. Parmi les avantages que peut offrir SysML pour la conception systme, nous pouvons citer : Tout dabord, SysML est un excellent candidat au besoin dun langage commun bien dfini et comprhensible par tous les acteurs impliqus dans la conception, de disciplines ou de spcialits diffrentes. SysML permet la modlisation dune large gamme de systmes, incluant tant du matriel, que du logiciel, de linformation, des processus, du personnel ou des quipements. Il permet davoir un modle complet du systme, couvrant lensemble des tapes, partant des exigences jusqu la solution physique (aspects structurel et comportemental), ce qui est rendu possible par la varit des diagrammes de SysML. SysML permet une expression soigne des exigences, incluant toutes les informations ncessaires, structure avec diffrents attributs. Il offre la possibilit davoir une traabilit rigoureuse. Entre autres, celle-ci facilite les analyses dimpacts, par exemple dans le cadre dun changement dexigence. Avec SysML, il est possible de dcrire les allocations des exigences sur les diffrents lments du modle. En plus de cela, il est possible dintgrer et dassocier des cas de tests directement la modlisation. Le dernier point important est le fait que SysML est un langage extensible. Nous proposons dailleurs une extension du langage, prsent dans la section ci-aprs.
3.2. Extension propose de SysML

Les diffrentes relations prsentes dans les paragraphes prcdents (composition, derivation, copy, satisfy, verify, refine et allocate) sont essentielles pour la dfinition de notre modle dinformation et galement pour satisfaire la gestion des exigences de lEIA632. Cependant, nous souhaitons ajouter au langage quelques autres lments. Nous dfinissons de nouvelles exigences, qui contiennent plus dinformation que les exigences de base de SysML. Ces informations sont utiles pour une meilleure conception, en 109
Chapitre 4
fournissant plus de dtails et en rendant possible un meilleur suivi du travail. A cela nous ajoutons aussi un nouveau lien, ainsi que de nouveau type dexigences (plus prcisment, il sagit de strotype). Nous dfinissons entre autres un sous-type dexigence technique du systme qui sont des exigences de sret de fonctionnement. De plus, nous ajoutons un nouveau type de block SysML : il sagit dun block risk qui reprsente les risques qui menacent le systme.
3.2.1. Exigences enrichies

Le concept dexigence est fondamental en conception systme. Cest galement un des intrts et une des nouveauts quapporte SysML, de considrer les exigences et les lier des lments du modle. Lobjectif est de rapprocher et lier les besoins des parties prenantes la solution de conception, pour guider le dveloppement, aider la vrification et la validation, ou encore faciliter le suivi des changements dexigences ou les volutions. SysML dfinit une exigence comme le montre llment requirement gauche dans la Figure IV.22, avec 3 attributs : Heading : le nom de lexigence, qui correspond au nom donn llment requirement. Text : sa description sous forme textuelle. Id : son identifiant.
Nous enrichissons cette dfinition en prconisant de nouveaux attributs, dont une partie est inspire du profil RPM (Requirement Profil for MeMVaTEx), des recommandations de lAFIS ou de la Snow Card Volere. Ces attributs, visibles droite dans la Figure IV.22, sont les suivants : Catgorie : indique si lexigence est fonctionnelle, de fiabilit, de performance, de scurit, de cot, de disponibilit, de maintenabilit, de sret, (Une liste possible est donne par Volere [Roberston, 2010]). Justification : justifie lexistence de lexigence. Source : enregistre la provenance de lexigence (acqureur, partie prenante, conception, lois, rglementation, base technologique, standards, spcifications, capacits et tendances des produits concurrents, interfaces avec dautres systmes ou plateformes, analyse de risques, ). Cible : indique la cible concerne par lexigence qui peut tre le systme ou des produits contributeurs (produits de dveloppement, de production, de test, de dploiement/installation, dentrainement, dopration, de support/maintenance ou de retrait de service). Maturit (origine, dfinie, valide, vrifie) : renseigne sur la vie de lexigence qui passe travers diffrents stades. Criticit (faibleforte) : caractrise limportance de lexigence en termes de risque. Flexibilit (faibleforte) : caractrise une certaine tolrance envers la satisfaction de lexigence. Priorit (faibleforte) : ordonne les exigences pour leur prise en compte dans la conception. 110
Chapitre 4
Figure IV.22 : Exigences SysML enrichies
Concernant le champ maturit qui renseigne sur la vie de lexigence, la Figure IV.23 illustre les diffrents stades en les dtaillant. En fait, lexigence doit atteindre ltat valide pour pouvoir tre allou un lment de modle. Quant ltat vrifie , il est obtenu aprs avoir suivi le TestCase associ lexigence, qui procde une vrification sur le modle ou le systme ralis.
Figure IV.23 : Champ maturit dune exigence
3.2.2. Nouveaux strotypes dexigences

Les strotypes permettent dtendre la smantique des lments de modlisation : il sagit du mcanisme dextension du mta-modle dUML (base de SysML). Ils permettent de dfinir de nouveaux types de block, en plus du noyau prdfini par UML (ou SysML par extension). Comme exemples de strotypes, nous avons dj vu <<requirement>> ou <<testcase>>. Pour catgoriser les exigences en respectant la classification de la norme EIA-632, nous avons dfini de nouveaux strotypes pour les exigences, comme le montre la Figure IV.24.
111
Chapitre 4
Figure IV.24 : Nouveaux strotypes pour les exigences
Ainsi, pour mieux distinguer les exigences entre-elles, il sera possible de crer des exigences de diffrents strotypes : <<acquirerReqt>> pour les exigences dacqureurs, <<otherStakeholderReqt>> pour les exigences des autres parties prenantes, <<systemTechnicalReqt>> pour les exigences techniques du systme, <<safetyReqt>> pour les exigences techniques du systme de sret fonctionnement, <<specifiedReqt>> pour les exigences spcifies.
de
Sur la mme Figure IV.24, apparait aussi la dfinition dun nouveau lien de traabilit : le lien specify . Il permet de lier les exigences spcifies et la solution de conception. Pour rappel, les exigences spcifies, telles que dfinies dans lEIA-632, servent dcrire et dtailler la solution de conception finale. Note : sur la Figure IV.24, les lments de SysML sont les rectangles contour pais. Le reste correspond lextension du langage que nous proposons.
3.2.3. Strotype risk

Les analyses de risques sont, comme nous lavons dj vu, la base de la conception de systme sr de fonctionnement. Cest souvent le point de dpart de rflexions concernant la fiabilit du systme ou la scurit du systme et de ses utilisateurs. Les risques, suite leurs analyses par le processus de traitement des risques, peuvent tre la source dexigences de sret de fonctionnement, voire de modification dexigences dj existantes. Les nouvelles exigences ainsi dfinies vont agir sur le risque en essayant soit de rduire limpact de loccurrence du risque (sa gravit), soit de rduire la frquence doccurrence du risque, ou les deux. Le but final tant de rendre le risque acceptable selon sa criticit, qui est une combinaison de sa gravit et de sa frquence (voir Figure IV.25).
112
Chapitre 4
Figure IV.25 : Matrice de criticit
De par lexistence de cette relation entre les risques et les exigences de sret et de par limportance que cela reprsente au niveau de la traabilit et de la comprhension du modle, nous introduisons un nouveau strotype de bloc risk , visible en Figure IV.26. Les attributs que nous dfinissons pour ce bloc risk sont les suivants : ID : identifiant, Statment : description du risque, Assumptions : ventuelles hypothses faites pour la dfinition de ce risque, Severity : svrit (ou gravit) du risque (sans gravit, mineur, majeur, hasardeux, catastrophique).
Figure IV.26 : Le bloc risk
Ce bloc apporte en fait une justification la prsence des exigences, tout en aidant la gestion des risques. Les analyses dimpacts tirent aussi un bnfice de cette traabilit entre risques et exigences. Il est possible, par exemple, davoir directement accs aux risques remis en cause par la modification dune exigence. La Figure IV.27 prsente la dfinition du bloc risk comme extension de SysML. Sur cette mme figure apparat la dfinition dun nouveau lien de traabilit treat , qui permet de lier les exigences de sret de fonctionnement aux risques.
113
Chapitre 4
Figure IV.27 : Nouveau bloc risk li aux exigences de sret de fonctionnement
Note : dans la Figure IV.27, de mme que pour la Figure IV.24, les lments de SysML sont les rectangles contour pais. Le reste correspond lextension du langage que nous proposons.
3.3. Prsentation du modle dinformation

Aprs avoir tendu le langage SysML, nous pouvons dfinir notre propre modle dinformation [Guillerm & al., 2010d], donn en Figure IV.28.
Figure IV.28 : Modle dinformation SysML propos
Ce modle peut tre vu comme un mta-modle pour la conception des systmes complexes srs de fonctionnement. Utilisable pour la conception dun building block, il 114
Chapitre 4
sinspire en partie dlments de la norme EIA-632, notamment en faisant apparatre clairement la distinction entre les diffrentes classes dexigences (acqureur, autres parties prenantes, technique du systme, et spcifie). A partir dexigences dacqureur (AcquirerReqt) et dexigences dautres parties prenantes (OtherStakeholderReqt), des exigences techniques du systme (SystemTechnicalReqt) sont dfinies. Ces exigences sont lies des cas de tests (TestCase) qui prvoient dores et dj leur vrification. Parmi ces exigences, certaines sont des exigences de sret de fonctionnement (SafetyReqt). Celles-ci sont lies galement aux risques (Risk) quelles traitent. Puis les architectures logique (LogicalArchitecture) et physique (PhysicalArchitecture) sont dfinies. Elles permettent de structurer respectivement lensemble des fonctions (Function) et des composants (Component) du systme. Tous ces lments satisfont lensemble des exigences techniques du systme. Dans le modle, nous avons souhait mettre en vidence la notion dinterface (Interface). En effet, comme nous lavons vu dans le 1er chapitre, cette notion est importante. Linterface est ici dfinie comme un composant particulier, qui est lui-mme li dautres composants. Pour finir, les exigences spcifies dcrivent la solution de conception finale. Elles sont elles-aussi lies des cas de tests pour les vrifier.
4. Complments au modle
Pour accompagner le modle dinformation, un certain nombre de complments peuvent tre ajouts et utiliss. Entre autre, nous avons pens la possibilit dutiliser un langage formel pour lexpression de certaines exigences (lorsque cela est possible) comme OCL. Il est galement intressant de montrer la possibilit de retirer un certain nombre dinformation du modle utile au management du projet. Par exemple, il est possible (si les outils de modlisation implmentent correctement ces fonctionnalits) dobtenir toutes sortes de matrices de traabilit, ou encore un inventaire des tats des exigences.
4.1. Utilisation dOCL

OCL (Object Constraint Language) a t dfini pour formaliser des contraintes et tre utilis par UML. Il faisait partie intgrante de la norme UML depuis la version 1.3. Mais aujourdhui, dans le cadre dUML 2.0, les spcifications dOCL figurent dans un document spar, dcrivant en dtails la syntaxe formelle du langage. OCL peut tre utilis dans de nombreux diagrammes dUML afin de spcifier des contraintes sur ltat dun objet ou dun ensemble dobjets. Il pourrait parfaitement tre utilis pour formaliser certaines des exigences (celles qui peuvent tre crites avec ce langage). La suite logique cette formalisation serait la vrification automatique de ces exigences sur le modle du systme.
115
Chapitre 4
4.2. Analyses et rsultats issus du modle de donnes

4.2.1. Matrices de traabilit
Nous avons mainte fois rpt limportance de la traabilit lors de la conception dun systme complexe. Si les outils le permettent, il serait possible avec lutilisation de notre modle dinformation de rcuprer toutes sortes de matrices de traabilit. Celles -ci pourraient directement tre utilises comme lments de synthse pour la traabilit qui permettraient de voir lavanc de la conception. Elles pourraient galement servir et aider les analyses dimpacts suite un changement (exigences, composants, fonctions). Par exemple, loutil Tau G2 dIBM (appartenant auparavant Telelogic) propose, avec le plugin pour SysML, la gnration de matrices de traabilit, appele matrices de dpendance. Ces matrices affichent les lments source et cible de dpendances (c'est--dire de lien de traabilit). Il est possible dobtenir une matrice qui prend en compte tous les liens (all), les liens dallocations (allocate), les liens de drivation (derive), les liens de satisfaction (satisfy) ou encore les liens de vrification (verify). Les lments sources sont alors lists verticalement et les lments cibles lists horizontalement. (Il est aussi possible de demander la transpose de la matrice (reversed), dans ce cas les sources sont affiches horizontalement et les cibles verticalement.) Comme le montre la Figure IV.29, un ensemble dexigences (REQ1 UC 1.1, REQ1 UC 1.2, etc.) est trac vers un ensemble de cas de tests (1.1.1, 1.1.2, etc.) pour leur vrification.
Figure IV.29 : Exemple de matrice de traabilit pour la vrification des exigences
4.2.2. Etats des exigences

Dautres informations importantes peuvent tre dduites du modle dinformation et servir la gestion du projet de conception en fournissant des indications quant ltat davancement de la conception. Il sagit des tats des exigences, contenus dans les champs maturit de nos extensions de lexigence SysML. Il serait intressant, toujours au 116
Chapitre 4
travers doutils, dobtenir le pourcentage dexigences ltat origine , dfinie , valide ou vrifie .
5. Conclusion
Nous venons de prsenter dans ce quatrime chapitre un modle dinformation qui vient appuyer la dmarche processus dingnierie systme dfinie dans le deuxime chapitre. Il permet de se rapprocher dune mthodologie dingnierie systme base sur les modles. Son rle est de rendre plus efficace la gestion des exigences et de fournir une base commune entre tous les participants la conception. Ce modle dinformation est bas sur le langage SysML et respecte les concepts de la norme EIA-632. Pour ce faire, nous avons dfini des extensions de SysML, galement prsentes dans ce chapitre, en particulier pour prendre en compte des exigences de sret de fonctionnement ou encore le concept de risque dans le modle. Le chapitre suivant prsentera un exemple dutilisation de ce modle issu du domaine aronautique.
117
Chapitre 4
118
Chapitre 5
Exemple illustratif de lavion S18
V.
Chapitre 5 : Exemple illustratif de lavion S18

1. Introduction
Afin dillustrer les travaux prsents dans ce mmoire, nous prsentons un cas dtude dans ce cinquime et dernier chapitre. Il sagit dun avion de ligne dont les informations ont t extraites de lexemple trait par la norme ARP-4761 : lavion fictif S18. Ce cas dtude permet dillustrer lutilit de la mthodologie de dclinaison dexigences de sret de fonctionnement sur un systme suffisamment complexe. Lutilisation de notre modle dinformation SysML, ralis laide de loutil Tau G2 dIBM, sera elle aussi prsente. Cet exemple sera trait de manire structure en suivant une dcomposition hirarchique en couche. Pour ce faire, nous nous baserons sur la notion de building block recommande par la norme EIA-632, norme sur laquelle repose notre approche dintgration de la sret de fonctionnement dans les processus dingnierie systme prsente au chapitre 2. Ainsi, ce chapitre est compos de trois grandes sections. La premire section dcrit lexemple de manire dtaille, en prsentant les fonctions et les sous-systmes, ceci pour trois systmes de niveaux diffrents. La deuxime section sattache appliquer la mthodologie de dclinaison dexigences de sret de fonctionnement aux diffrents niveaux hirarchiques. Quant la troisime section, celle-ci propose la modlisation SysML de cet exemple utilisant notre modle dinformation.
2. Prsentation de lexemple
Lexemple illustratif choisi et trait est celui de lavion fictif S18 issu de la norme ARP 4761. Le niveau systme complet est alors dcrit dans un premier temps, avec les diffrentes fonctions et la dcomposition en sous-systmes.
2.1. Le systme avion S18

Lavion S18 est un quadriracteur servant au transport de passagers. Il peut transporter de 300 500 passagers sur 5000 miles nautiques mach 0.86. Le temps de vol moyen de cet appareil est de 5 heures.
2.1.1. Les fonctions

Les diffrentes fonctions ralises par ce systme sont : contrler la pousse pour commander la force exerce par les moteurs, 119
Chapitre 5
contrler le plan de vol pour commander les diffrentes gouvernes de lappareil, permettant ainsi dagir sur lorientation spatiale de lavion (roulis, lacet, tangage), dterminer lorientation pour avoir un retour sur lorientation spatial relative de lappareil concernant les angles roulis, lacet et tangage, dterminer la position et la direction pour avoir un retour sur lorientation spatial absolue de lappareil par rapport au sol, contrler lavion au sol pour commander lappareil au sol, avec comme sousfonctions : o dterminer la transition air/sol o dclrer lavion au sol o contrler la direction de lavion au sol o contrler lenvironnement cabine pour grer lenvironnement de la cabine des passagers (temprature, air, lumire),
Une tude et une modlisation complte ncessiteraient un trop grand nombre de dtails pour tre inclus dans ce mmoire de thse, cest pourquoi nous nous limitons cette liste non-exhaustive qui nous permet de modliser une partie du systme en guise dexemple. Par la suite, nous nous intressons plus en dtail la sous-fonction dclrer lavion au sol .
2.1.2. Les sous-systmes

Le systme avion se dcompose en plusieurs sous-systmes. Cest la mise en relation et linteraction de ces sous-systmes qui permet de raliser les fonctions listes plus haut. Une liste, encore une fois non-exhaustive, des sous-systmes est : La structure Le systme de pousse Le systme des gouvernes Le systme des arofreins Le systme des inverseurs de pousse Le systme des freins des roues
Figure V.1 : Sous-systmes impliqus dans le freinage
120
Chapitre 5
Note : On note ici lutilisation du mot systme , et non sous-systme . Ceci est justifi par le fait quun sous-systme est lui-mme un systme, mais aussi par le langage employ par les industriels de construction aronautique qui emploient plutt le mot systme avion pour lavion complet et le mot systme pour ce niveau ( sous-systme ou quipement est utilis pour le niveau suivant). Dans la suite de notre tude, nous nous intressons en particulier la fonction de dclration de lavion au sol. Les sous-systmes qui interviennent pour cette fonction de dclration sont les inverseurs de pousse , les arofreins et les freins des roues . Les inverseurs de pousse sont associs aux racteurs et peuvent inverser la direction de la pousse. Ils ne peuvent tre utiliss quau-del dune certaine vitesse (autrement les racteurs rinjectent du gaz chaud et se dtriorent). Les arofreins sont des surfaces mobiles sur les ailes qui servent rduire la portance et augmenter la trane. En consquence, ils ralentissent la vitesse de l'avion, en l'empchant de redcoller et en transfrant davantage de poids sur les roues. Ils sont efficaces seulement au-dessus d'une certaine vitesse. Enfin, les freins des roues sont utiliss toutes les vitesses et sont situs sur les trains d'atterrissages principaux (pas sur le train avant). Ils peuvent tre utiliss de faon dissymtrique, pour lutter contre un vent de travers ou pour effectuer des virages serrs. Sachant que nous souhaitons parcourir plusieurs niveaux de dcomposition hirarchique, nous continuons la prsentation de lexemple en dtaillant le sous-systme de freins des roues. Viendra ensuite celle dun calculateur prsent dans ce sous-systme de freins des roues : le calculateur BSCU.
2.2. Le systme freins des roues

Le systme freins des roues permet de ralentir la rotation des roues de lavion afin de rduire la vitesse de lappareil. Dautres systmes permettent de diminuer la vitesse de lavion, comme les reverses ou les arofreins, mais ceux-ci nont quun rle secondaire compar lefficacit des freins des roues. Pour lexemple, nous ne traitons en dtails que ce systme de freins des roues.

Le premier rle du systme de freins des roues est de dclrer lavion au sol sans faire draper les pneus. Le systme de freins des roues accomplit cette fonction automatiquement latterrissage ou manuellement quand le pilote lactive. En plus de dclrer lavion, le systme de freins des roues est utilis pour : contrler la direction au sol avec un freinage diffrentiel (pour les virages serrs), stopper la rotation des roues lors de la rtraction des trains, empcher lavion de bouger quand il est parqu, informer du freinage et de ltat du systme.
121
Chapitre 5

Le systme freins des roues ninclut pas uniquement les freins multi-disques en carbone, mais bien dautres sous-systmes ncessaire leurs contrles et leur fonctionnement. Deux ensembles indpendants (Figure V.2) de pistons hydrauliques permettent dactionner ces freins en carbone. Le premier ensemble est opr partir dune ressource hydraulique VERTE et est utilis par le mode de freinage NORMAL. Un mode ALTERNATIF est en veille et est slectionn automatiquement lorsque le systme NORMAL dfaille. Ce mode est opr indpendamment partir dune ressource hydraulique BLEUE (appartenant au deuxime ensemble) et est soutenu par un accumulateur qui est galement utilis pour activer le frein de parking. Laccumulateur approvisionne le systme ALTERNATIF dans le mode de freinage dURGENCE lorsque la ressource BLEUE est perdue et que le mode NORMAL nest pas disponible. La commutation entre ces modes est automatique, dpendant des conditions de dfaillances, mais elle peut aussi tre slectionne manuellement. Un calculateur, appel calculateur BSCU pour Braking System Control Unit, permet dlaborer les ordres de commandes de freinage en fonction du mode slectionn (automatique ou manuel) et/ou des ordres des pilotes provenant des pdales. Aliment par une ressource lectrique, ce calculateur envoi aussi des informations un systme dannonciation de freinage. Ce systme est charg de renseigner les pilotes sur ltat gnral de tout le systme de freinage. Ce calculateur permet de fournir les commandes de freinage la chaine NORMALE, tandis que concernant la chaine ALTERNATIVE, celle-ci est commande directement par une liaison mcanique lie aux pdales.
Figure V.2 : Systme de freins des roues
122
Chapitre 5
Ainsi, les sous-systmes considrs dans notre tude sont les suivants (cf. Figure V.2) : Le calculateur BSCU, La ressource lectrique, Le systme dannonciation, Les composants hydrauliques du mode NORMAL, Les composants hydrauliques du mode ALTERNATIF, Laccumulateur (mode dURGENCE et frein de parking), La ressource hydraulique VERTE, La ressource hydraulique BLEUE.
2.3. Le systme calculateur BSCU

Nous venons de voir le systme de freins des roues de lavion S18. Ce systme contient un calculateur : le BSCU, que nous dtaillons pour le troisime et dernier niveau de notre tude. Cet lment correspond en fait la partie intelligente du systme de freins des roues, ce que nous allons retrouver dans le dtail de ses fonctions.

Le rle du calculateur BSCU, Braking System Control Unit, est, comme son nom le laisse deviner, dlaborer et de fournir des commandes pour le freinage. En fait, ses activits peuvent tre dfinies par deux fonctions principales qui sont : Gnrer la commande de freinage partir de linformation des pdales, en assurant lanti-drapage des roues, Slectionner, grce son moniteur gnral, le mode de freinage alternatif si le BSCU est dfaillant (ne peut plus gnrer la commande de freinage).

Pour des raisons de sret (que nous verrons plus loin), larchitecture du BSCU est compose de 2 units de calcul en parallle : le BSCU1 et le BSCU2. Chaque unit de calcul comporte : Une ressource lectrique, pour lalimentation des sous-systmes en nergie lectrique, Un CPU, pour le calcul des fonctions de commande raliser, Un moniteur de puissance, pour la surveillance de la disponibilit de la ressource de puissance, Un moniteur systme, pour le contrle du fonctionnement de lunit de calcul.
En plus de ces deux units de calcul, le BSCU inclut galement un moniteur gnral et un commutateur. Le moniteur gnral contrle ltat de fonctionnement des deux units de calcul (BSCU1 et BSCU2) et permet de fournir les rsultats des oprations du BSCU1 ou ceux du BSCU2 en sortie du BSCU laide du commutateur. Il permet galement de signaler linvalidit gnrale du BSCU lorsque celui-ci est dfaillant. De manire plus dtaille, le fonctionnement en fonction des dfaillances est le suivant : 123
Chapitre 5
En opration normal, le BSCU1 fournit les commandes de freinage et dantidrapage aux freins des roues. Si le moniteur systme du BSCU1 reporte une dfaillance, alors le BSCU2, si valide, fournit la commande. Si les BSCU1 et BSCU2 sont dfaillants, alors le moniteur gnral reporte ltat invalide. Dans ce cas, le circuit normal du systme de freins des roues ne peut plus tre utilis.
La Figure V.3 synthtise sur un schma lensemble des relations entre les diffrents composants du systme BSCU.
Figure V.3 : Systme BSCU
3. Application de la mthodologie de dclinaison dexigences de Sret de Fonctionnement

Suite la prsentation de lexemple, nous allons maintenant appliquer la mthodologie de dclinaison dexigences de sret de fonctionnement dfinie dans le chapitre 3. Pour bien illustrer lintrt de la mthodologie, nous allons lappliquer sur trois niveaux : celui de lavion S18 (en ne sintressant qu la fonction de dclration au sol), celui du systme freins des roues et celui de lquipement calculateur BSCU .
3.1. Niveau avion S18

Pour le cas dtude, nous nous intressons la fonction de dclration au sol de lavion S18. Les phases considres sont les phases datterrissage, de dcollage dans le cas dinterruption avant la vitesse V1 (lavion commence son dcollage, lquipage dcouvre une anomalie avant la limite de vitesse V1, il dcide alors dinterrompre le dcollage : freinage durgence de lavion) et la circulation sur les voies de roulage (mode taxi). Nous rappelons que les sous-systmes qui interviennent pour la fonction de dclration sont les inverseurs de pousse , les arofreins et les freins des roues (revoir Figure V.1). Nous allons appliquer la mthode sur les aspects dclration au sol du systme avion, pour identifier les exigences de sret et dterminer leur dclinaison au niveau des sous-systmes.
124
Chapitre 5

Donne par la Figure V.4, l'application de lAMDEC au niveau du systme Avion S18 pour la fonction de dclration fait apparatre les modes de dfaillance suivants : perte de la capacit de dclration , dclration involontaire aprs V1 , perte partielle de la capacit de dclration , perte de la capacit de dclration automatique , dclration asymtrique .
Il faut noter que le tableau AMDEC de la Figure V.4 nest pas exhaustif. Dautres modes de dfaillance peuvent tre dfinis. Dans ce tableau, nous avons examin les diffrentes phases d'utilisation du systme car les contraintes changent en fonction de ces phases. Cependant, la frquence napparait pas, car elle n'est pas disponible au dbut de l'tude. Ainsi, les actions correctives agissent sur les causes et permettent de dfinir les frquences associes qui conduisent une criticit acceptable (criticit = frquence x gravit) pour une gravit donne, qui elle est connue. Pour donner un exemple, nous pouvons identifier une exigence de sret au niveau systme avion S18 : la perte non-annonce de la capacit de dclration doit avoir une frquence < 5.10-9/flt . Cette exigence est lie la cause systme : perte non-annonce de la capacit de dclration , qui va dailleurs tre tudie dans la deuxime tape de la mthode. Remarque : concernant les donnes quantitatives visibles dans les arbres qui vont suivre, une distinction dunit sera faire entre celle des objectifs : par heure de vol (/fh), et celle des probabilits : par vol (/flt). Sachant que lon considre une dure moyenne des vols de 5h, il y aura quivalence entre, par exemple, un objectif de 10-9/fh et une probabilit de 5.10-9/flt.

L'arbre de dfaillances de la Figure V.5 sintresse la cause systme : perte nonannonce de la capacit de dclration . Il est construit progressivement dans le but d'obtenir des feuilles qui reprsentent les modes de dfaillance des sous-systmes. Ainsi, daprs la figure, la perte non-annonce de la capacit de dclration fait intervenir : la perte non-annonce des inverseurs de pousse, la perte non-annonce de tous les freins sur piste contamine (par de leau, de la neige, de la glace) et la perte non-annonce de tous les freins. Dans son arbre de dfaillance, nous constatons que la cause systme perte nonannonce de la capacit de dclration fait intervenir une autre cause systme : perte non-annonce des freins des roues . Il est effectivement possible qu'un arbre implique une cause associe un autre mode de dfaillance du systme. Mais cela implique que, pour les calculs de probabilit, nous devons respecter l'objectif de la cause, mais aussi ceux des autres causes survenant dans l'arbre.
125
Chapitre 5
Figure V.4 : AMDEC systme Avion S18 pour la fonction de dclration au sol
126
Chapitre 5
Figure V.5 : Arbre de dfaillance de la perte non-annonce de la capacit de dclration
Remarque : larbre de la Figure V.5 ne fait pas intervenir la dfaillance des arofreins, car lefficacit de ces derniers est bien plus faible que celle des freins ou des inverseurs de pousse (surtout faible vitesse). Ils ne sont donc pas pris en compte dans la capacit de dclration. En revanche, ils sont considrer pour des dclrations involontaires. Larbre de dfaillance de la Figure V.6 sintresse la cause systme : dclration involontaire aprs V1 .
Figure V.6 : Arbre de dfaillance de la dclration involontaire aprs V1
Daprs cet arbre, la dclration involontaire aprs V1 fait intervenir linversion de pousse, le dploiement des arofreins et le freinage des roues, toutes ces actions de manire involontaire et aprs la vitesse V1.

Pour cet exemple, nous ne prsentons, dans la Figure V.7, que lAMDEC du soussystme freins des roues , avec l'tude de la fonction freiner les roues sur le sol sans drapage . Dans cette tude, nous retrouvons quelques modes de dfaillance du soussystme freins des roues prsents dans les arbres de dfaillance des Figure V.5 et Figure V.6, comme : perte totale du freinage des roues freinage des roues involontaire aprs V1 127
Chapitre 5
Figure V.7 : AMDEC du sous-systme freins des roues
128
Chapitre 5
Un exemple dexigence de sret identifie au niveau de ce sous-systme de freins des roues est : la perte non-annonce de tous les freins doit avoir une frquence < 5.10-7/flt , lie au mode de dfaillance perte totale du freinage des roues .

La synthse permet de montrer la dclinaison des exigences de sret au niveau systme en exigences de sret sous-systme. Nous donnons ici deux exemples de dclinaison qui correspondent respectivement aux deux arbres de dfaillance crs (voir Figure V.5 et Figure V.6). L'exigence de sret systme la perte non-annonce de la capacit de dclration doit avoir une frquence <5.10-9/flt est dcline au niveau sous-systmes en : Pour les freins des roues : o la perte non-annonce de tous les freins sur une piste contamine doit avoir une frquence < 5.10-7/flt o la perte non-annonce de tous les freins doit avoir une frquence < 5.10-7/flt Pour les inverseurs de pousse : o la perte non-annonce des inverseurs de pousse doit avoir une frquence < 5.10-3/flt
Lexigence de sret systme la dclration involontaire aprs V1 doit avoir une frquence < 5.10-9/flt est dcline au niveau sous-systmes en : Pour les freins des roues : o le freinage involontaire des roues aprs V1 doit avoir une frquence < 5.10-9/flt Pour les inverseurs de pousse : o linversion involontaire de la pousse aprs V1 doit avoir une frquence < 5.10-9/flt Pour les arofreins : o le dploiement involontaire des arofreins aprs V1 doit avoir une frquence < 5.10-9/flt
3.2. Niveau freins des roues

Nous poursuivons ltude de cet exemple par lapplication de la mthodologie de dclinaison dexigences de sret de fonctionnement au niveau suivant : celui du systme freins des roues .

Lanalyse des dfaillances au niveau du systme freins des roues a dj t ralise dans ltape 3 du niveau prcdent. Pour cette tape, il suffit donc de reprendre lAMDEC ralise en Figure V.7 au paragraphe 3.1.3. Les modes de dfaillances identifis sont les suivants (liste non-exhaustive) :
129
Chapitre 5 Perte totale du freinage des roues , Perte symtrique partielle du freinage des roues , Perte asymtrique du freinage des roues , Freinage involontaire des roues .
Un exemple dexigence de sret identifie laide de cette AMDEC est : la perte nonannonce de tous les freins doit avoir une frquence < 5.10-7/flt , lie la cause systme perte non-annonce de tous les freins des roues .

Larbre de dfaillance de la Figure V.8 sintresse la cause systme : perte nonannonce de tous les freins des roues .
Figure V.8 : Arbre de dfaillance de la perte non-annonce de tous les freins des roues
Cette cause fait intervenir des pertes (dfaillance) au niveau de la ressource et des composants hydrauliques de la chaine normale, du calculateur BSCU, ainsi quau niveau des systmes de freins alternatif et durgence et du systme dannonciation. Mais daprs la figure, nous constatons que nous ntudions pas plus en dtails la dfaillance du systme de freins alternatif. Egalement, nous ne considrons pas de contrainte de fiabilit pour les dfaillances du systme de freins durgence et du systme dannonciation.

Pour cet exemple, nous ne prsentons, dans la Figure V.9, que lAMDEC sous-systme du calculateur BSCU , avec l'tude de la fonction fournir la commande de freinage . 130
Chapitre 5
Dans cette AMDEC, nous reconnaissons le mode de dfaillance perte de la commande de freinage du BSCU prsent dans larbre de dfaillance de la Figure V.8.
Figure V.9 : AMDEC du sous-systme calculateur BSCU
Ce mode de dfaillance est dailleurs li une exigence de sret que nous identifions : la perte du calculateur BSCU entrainant la perte de la commande de freinage doit avoir une frquence < 3,3.10-5/flt .

Suite lapplication de la mthodologie de dclinaison dexigences de sret de fonctionnement au niveau du systme de freins des roues, nous pouvons alors identifier une dclinaison. Elle concerne la perte non-annonce de tous les freins. Lexigence de sret systme la perte non-annonce de tous les freins doit avoir une frquence < 5.10-7/flt est dcline au niveau sous-systmes en : Pour le systme dannonciation : o Il n'y a pas de contrainte concernant la fiabilit du systme d'annonciation Pour le systme de freinage alternatif : o La perte du systme de freinage alternatif doit avoir une frquence < 5.10-3/flt Pour le systme de freinage durgence : o Il n'y a pas de contrainte concernant la fiabilit du systme de freinage d'urgence Pour la ressource hydraulique normale : o La perte de la ressource hydraulique du mode normal doit avoir une frquence < 3,3.10-5/flt Pour les composants hydrauliques normaux : o La perte des composants hydraulique du systme de freinage du mode normal doit avoir une frquence < 3,3.10-5/flt Pour la ressource lectrique : o La perte de la ressource lectrique doit avoir une frquence < 10-7/flt Pour le calculateur BSCU : o La perte du calculateur BSCU entrainant la perte de la commande de freinage doit avoir une frquence < 3,3.10-5/flt
131
Chapitre 5
3.3. Niveau calculateur BSCU

Nous poursuivons ltude de cet exemple par lapplication de la mthodologie de dclinaison dexigences de sret de fonctionnement au niveau suivant : celui du systme calculateur BSCU .

Lanalyse des dfaillances au niveau du systme calculateur BSCU a dj t ralise dans ltape 3 du niveau prcdent. Pour cette tape, il suffit donc de reprendre lAMDEC ralise en Figure V.9 au paragraphe 3.2.3. Les modes de dfaillances identifis sont les suivants : Perte de la commande de freinage, Dclanchement intempestif de la commande de freinage.
Un exemple dexigence de sret identifie laide de cette AMDEC est : la perte du calculateur BSCU entrainant la perte de la commande de freinage doit avoir une frquence < 3,3.10-5/flt , lie la cause systme une dfaillance du BSCU provoque la perte de la commande de freinage .

Larbre de dfaillance prsent dans les Figure V.10 et Figure V.11 sintresse la cause systme : une dfaillance du BSCU provoque la perte de la commande de freinage .
Figure V.10 : Arbre de dfaillance de une dfaillance du BSCU provoque la perte de la commande de freinage (1/2)
132
Chapitre 5
Figure V.11 : Arbre de dfaillance de une dfaillance du BSCU provoque la perte de la commande de freinage (2/2)
La cause systme une dfaillance du BSCU provoque la perte de la commande de freinage provient donc : dune dfaillance du moniteur gnral, de la perte des deux units de calcul, ou alors dune dfaillance du commutateur lie ou non une dfaillance dune unit de calcul (suivant la position dans laquelle le commutateur est bloqu). Quant aux dfaillances mmes des units de calcul, celles-ci proviennent soit dune dfaillance lectronique, soit dune panne dalimentation lectrique. Larbre de dfaillance prsent dans les Figure V.12, Figure V.13 et Figure V.14 sintresse la cause systme : le BSCU commande le freinage en labsence de donnes dentre et provoque un freinage involontaire .
Figure V.12 : Arbre de dfaillance de le BSCU commande le freinage en labsence de donnes dentre et provoque un freinage involontaire (1/3)
133
Chapitre 5
134
Chapitre 5
Lors de lanalyse de la cause systme le BSCU commande le freinage en labsence de donnes dentre et provoque un freinage involontaire , nous voyons sur larbre que nous ne considrons que les dfaillances dtectes du BSCU. Nous supposons que la non-existence dune dfaillance unique non-dtecte t prouv (do la probabilit de 0 dans larbre). Cette cause systme provient donc soit dune dfaillance dtecte du BSCU1, soit dune dfaillance dtecte du BSCU2 dans le cas o le BSCU2 est utilis. Cette utilisation du BSCU2 se produit lorsque le BSCU1 est dfaillant ou lorsque le commutateur est bloqu sur la position du BSCU2. Concernant la dfaillance dtecte dune unit de calcul (BSCU1 ou BSCU2), celle-ci se produit lors dune dfaillance de son alimentation lectrique combine avec une dfaillance de son moniteur de puissance, ou bien lors dune dfaillance I/O ou CPU combine avec une dfaillance de son moniteur systme (qui reporte toujours ltat valide).

Nous choisissons de ne pas prsenter dAMDEC relatif aux sous-systmes du calculateur BSCU dans ce mmoire. Le niveau atteint prsente en effet des composants dont les fonctions et leurs modes de dfaillance sont comprhensible aisment. Lintrt de la prsentation de ces AMDEC nest donc pas essentiel.

Suite lapplication de la mthodologie de dclinaison dexigences de sret de fonctionnement au niveau du calculateur BSCU, nous pouvons alors identifier deux dclinaisons. La premire concerne la perte du calculateur BSCU et la deuxime le freinage involontaire. Lexigence de sret systme la perte du calculateur BSCU entrainant la perte de la commande de freinage doit avoir une frquence < 3,3.10-5/flt est dcline au niveau soussystmes en : Pour le moniteur gnral : o L'erreur du systme de surveillance du BSCU entranant un passage en mode alternatif doit avoir une frquence < 1,3.10-5/flt Pour le commutateur : o Le blocage du commutateur sur la position de l'unit de calcul BSCU1 doit avoir une frquence < 1,48.10-2/flt o Le blocage du commutateur dans une position intermdiaire doit avoir une frquence < 5.10-6/flt o Le blocage du commutateur sur la position de l'unit de calcul BSCU2 doit avoir une frquence < 1,48.10-2/flt Pour le CPU du BSCU1 : o La dfaillance lectronique du BSCU1 doit avoir une frquence < 3,5.10-4/flt Pour le CPU du BSCU2 : o La dfaillance lectronique du BSCU2 doit avoir une frquence < 3,5.10-4/flt 135
Chapitre 5
Pour la ressource lectrique du BSCU1 : o La panne d'alimentation lectrique du BSCU1 doit avoir une frquence < 1,5.10-4/flt Pour la ressource lectrique du BSCU2 : o La panne d'alimentation lectrique du BSCU2 doit avoir une frquence < 1,5.10-4/flt
Lexigence de sret systme le freinage involontaire en raison d'une panne du calculateur BSCU doit avoir une frquence < 2,5.10-9/flt est dcline au niveau soussystmes en : Pour le commutateur : o Le blocage du commutateur sur la position de l'unit de calcul BSCU2 doit avoir une frquence < 1,48.10-2/flt Pour le moniteur de puissance du BSCU1 : o Le blocage dans l'tat valide du systme de surveillance de l'alimentation lectrique du BSCU1 doit avoir une frquence < 2.10-2/flt Pour le moniteur de puissance du BSCU2 : o Le blocage dans l'tat valide du systme de surveillance de l'alimentation lectrique du BSCU2 doit avoir une frquence < 2.10-2/flt Pour le moniteur systme du BSCU1 : o Le systme de surveillance de validit du BSCU1 qui est dfaillant dans l'tat valide en raison d'une erreur matrielle doit avoir une frquence < 2.10-2/flt o L'existence d'erreur de conception du moniteur du BSCU1 n'a pas de contrainte concernant la fiabilit Pour le moniteur systme du BSCU2 : o Le systme de surveillance de validit du BSCU2 qui est dfaillant dans l'tat valide en raison d'une erreur matrielle doit avoir une frquence < 2.10-2/flt o L'existence d'erreur de conception du moniteur du BSCU1 n'a pas de contrainte concernant la fiabilit Pour la ressource lectrique du BSCU1 : o La panne d'alimentation lectrique du BSCU1 entranant des donnes errones doit avoir une frquence < 5.10-8/flt Pour la ressource lectrique du BSCU2 : o La panne d'alimentation lectrique du BSCU2 entranant des donnes errones doit avoir une frquence < 5.10-8/flt Pour le CPU du BSCU1 : o La dfaillance matriel du CPU du BSCU1 entranant des donnes errones doit avoir une frquence < 3,13.10-8/flt o L'erreur de conception des fonctions du CPU du BSCU1 entranant des donnes errones n'a pas de contrainte de fiabilit o La dfaillance I/O du BSCU1 entranant des donnes errones doit avoir une frquence < 1,88.10-8/flt Pour le CPU du BSCU2 : 136
Chapitre 5 o o o
Exemple illustratif de lavion S18 La dfaillance matriel du CPU du BSCU2 entranant des donnes errones doit avoir une frquence < 3,13.10-8/flt L'erreur de conception des fonctions du CPU du BSCU2 entranant des donnes errones n'a pas de contrainte de fiabilit La dfaillance I/O du BSCU2 entranant des donnes errones doit avoir une frquence < 1,88.10-8/flt
Remarque : cette deuxime dcomposition refait intervenir une exigence au niveau du commutateur, concernant son blocage sur la position du BSCU2, dj prsente dans la premire dcomposition. Ce genre de configuration est tout fait acceptable, du moment que les exigences ne sont pas incohrentes. Il sagit en fait daccorder les contraintes de sret ou de prendre en compte la contrainte la plus svre. La dtection de lincohrence potentielle et laccord fait entre les exigences se grent lors des phases danalyse et de validation des exigences.
4. Modlisation SysML
La section qui suit prsente la modlisation SysML de lexemple de lavion S18 pour les 3 niveaux de building block tudis prcdemment (avion S18, systme de freinage, calculateur BSCU) en sintressant plus particulirement la fonction de freinage. Nous rappelons que nous souhaitons modliser, en respectant le modle dinformation dfini dans le chapitre 4, afin de partager les donnes dingnierie sur une base commune lors de lingnierie du systme, ceci entre les diffrents participants la conception (particulirement entre les ingnieurs systme et les ingnieurs de sret de fonctionnement pour ce qui concerne notre problmatique). Nous verrons que lessentiel de la modlisation prsent ici sattache la dfinition des exigences et aux liens de traabilit.
4.1. Prparation du projet sous Tau-G2

Loutil que nous avons choisi dutiliser pour modliser en SysML est loutil Tau G2, qui est disponible au LAAS-CNRS. Autrefois dvelopper par la socit Telelogic, Tau G2 appartient maintenant IBM. Lobjectif principal de Tau G2 est doffrir un environnement de modlisation UML, avec des possibilits de simulation et de gnration de codes. Toutefois, le mta-modle de SysML a t implant dans loutil pour permettre galement de modliser en langage SysML. Tout dabord, avant de commencer la modlisation, il sagit de prparer le projet sous TauG2. Plus que la cration mme dun nouveau projet, ce que nous prsentons ici correspond lextension ncessaire de SysML dfinir et lorganisation en packages propose pour notre projet.
137
Chapitre 5
4.1.1. Extension de SysML

Concernant lextension de SysML, nous avons cr un nouveau package appel ExtensionSysML . Celui-ci contient alors tous les nouveaux strotypes ajouter SysML, tels que proposs dans la section 3.2 du chapitre 4. La visualisation de ces strotypes et de leurs relations est rendue visible travers un diagramme prsent en Figure V.15. Dans cette figure, les nouveaux strotypes dexigences apparaissent : acquirerReqt , otherStakeholderReqt , systemTechnicalReqt , specifiedReqt et safetyReqt , ainsi que la dfinition du bloc risk . Les dfinitions des deux nouveaux liens de traabilit sont galement visibles : lien treat , pour une exigence de sret qui traite un risque, et lien specify , pour une exigence spcifie qui spcifie un lment de la solution.
4.1.2. Organisation en packages

Concernant lorganisation du projet, un package est dfini pour chacun des trois niveaux de building block tudi (voir Figure V.16) : AvionS18 , Systme FreinsDesRoues , BSCU .
Pour rappel, la notion de building block provient de la norme EIA-632 que nous utilisons, prsente au chapitre 2.
Figure V.15 : Extension de SysML
138
Chapitre 5
Figure V.16 : Building blocks
Puis, pour chacun de ces niveaux, une structure en trois (autres) packages permet dorganiser la modlisation. Il sagit de suivre le principe de bonne conception prsent au paragraphe 2.5 du chapitre 4, qui stipulait de sparer les concepts dexigences, de solution de conception et de vrification et validation dans la modlisation. Ainsi, les trois packages sont (voir Figure V.17) : Requirements , Design Solution , V&V .
Le package Requirements accde aux deux autres packages : Design Solution et V&V , et importe lextension de SysML contenu dans le package ExtensionSysML pour lutiliser.
Figure V.17 : Organisation en packages
Note : afin de faciliter la comprhension de lexemple, nous prsentons par la suite les packages dans lordre suivant : Design Solution , Requirements et V&V . Ceci se justifie par le fait que le package Requirements fait rfrence beaucoup dlments contenus dans le package Design Solution . Pour autant, cet ordre de prsentation nest absolument pas reprsentatif de la temporalit de cration des lments du modle. 139
Chapitre 5
4.2. Niveau avion S18

Suite la prparation du projet, nous pouvons commencer la modlisation du systme. Nous commenons par le building block avion S18 , en prsentant successivement les diffrents diagrammes prsents dans les diffrents packages annoncs ci-dessus.
4.2.1. Package de la solution de conception

Le premier package prsent est celui de la solution de conception ( Design Solution ). Celui-ci contient deux diagrammes : 1. Un diagramme de cas dutilisation, prsentant les fonctions du systme, 2. Un diagramme de block, pour la structure du systme.
4.2.1.1.
Fonctions du systme
La Figure V.18 prsente les fonctions du systme travers un diagramme de cas dutilisation. En plus de montrer les acteurs du systme dans ce diagramme, ce sont bien entendu les cas dutilisation qui sont reprsentatifs des fonctions. Une structure hirarchique entre ces fonctions est ralise laide de relations include . Par exemple, la fonction dclrer lavion au sol est une sous-fonction de la fonction contrler lavion au sol , qui elle-mme est une sous-fonction de la fonction piloter lavion .
Figure V.18 : Avion S18 Fonctions du systme
140
Chapitre 5
4.2.1.2.
Structure du systme
Une partie de la structure du systme avion S18 est reprsente en Figure V.19 dans un diagramme de blocks. Nous retrouvons le fait que lavion S18 est compos de : Une structure, Un systme de pousse, Un systme de gouvernes, Un systme darofreins, Un systme dinverseurs de pousse, Un systme de freins des roues.
Figure V.19 : Avion S18 Structure du systme
4.2.2. Package des exigences

Le second package prsent est celui des exigences ( Requirements ). Nous avons choisi de crer quatre diagrammes dexigences pour : 1. Les exigences haut-niveau, pour prsenter les exigences au niveau du systme, lavion S18 pour ce premier building block, et lier ces exigences aux risques quelles traitent par la relation treat , 2. La dclinaison des exigences, pour montrer la dclinaison des exigences systme en exigences sous-systme par la relation de composition, 3. La satisfaction des exigences, pour indiquer les lments du systme (systme ou sous-systmes) qui satisfont les exigences par la relation satisfy , 4. La vrification des exigences, pour dsigner les lments de V&V qui vrifient les exigences par la relation verify .
4.2.2.1.
Diagramme des exigences haut-niveau
La Figure V.20 montre les exigences haut-niveau de lavion S18. Seulement deux risques apparaissent : sortie de piste haute vitesse et sortie piste sur cot . Leurs svrits sont comprises entre deux valeurs, ceci est d une simplification de modlisation
141
Chapitre 5
que nous faisons pour ne pas alourdir le modle : par exemple pour ne pas multiplier le nombre de risques en fonction des phases atterrissage/taxi/dcollage annul. Dans ce diagramme, nous retrouvons par exemple lexigence de sret systme la perte non-annonce de la capacit de dclration doit avoir une frquence <5.10-9/flt identifie lors de lAMDEC du systme avion S18 (voir paragraphe 3.1.1). Cette exigence, dont lidentifiant est R2 , permet de traiter le risque Risk_1 : lavion sort de la piste haute vitesse et peut rentrer en contact avec des obstacles .
Figure V.20 : Avion S18 Diagramme des exigences haut-niveau
142
Chapitre 5
4.2.2.2.
Diagramme de dclinaison des exigences
La Figure V.21 montre la dclinaison des exigences haut-niveau (systme avion S18) en exigences sous-systmes. Nous retrouvons ici les deux dclinaisons synthtises au paragraphe 0 concernant les exigences systme perte dclration non-annonce et dclration involontaire aprs V1 , qui se dclinent au niveau des sous-systmes : inverseurs de pousse, frein des roues et arofreins. Note : Concernant les identifiants des exigences (champ Id), nous avons choisis de rutiliser lidentifiant de lexigence mre pour les exigences dclines. Par exemple, si lidentifiant de lexigence mre est R2 , alors la premire exigence dcline aura comme identifiant R2.1 .
Figure V.21 : Avion S18 Diagramme de dclinaison des exigences
4.2.2.3.
Diagramme de satisfaction des exigences
La Figure V.22 montre les affectations des exigences aux lments de la solution de conception, ceci travers le lien satisy de SysML. Ces lments peuvent tre tous des lments du langage SysML autres que des exigences, mais dans notre modlisation, ceuxci correspondent des blocks (reprsentatifs de systmes) ou des usecases (reprsentatifs de fonctions). Concernant les deux dclinaisons dexigences prcdentes, les exigences systme sont trs logiquement lies des lments systme, qui ici correspondent aux fonctions du systme avion S18 (modliser laide de usecase). Quant aux exigences sous-systme, celles-ci sont associes des blocks reprsentant des sous-systmes (freins des roues, inverseurs de pousse, arofreins). 143
Chapitre 5
En bas du diagramme, une srie dexigences a t simplement lie au block avion S18 reprsentant le systme. Pour une modlisation complte, ces exigences devraient galement tre dclines. Mais pour limiter la taille de lexemple, nous ntudions pas en profondeur ces exigences.
Figure V.22 : Avion S18 Diagramme de satisfaction des exigences
4.2.2.4.
Diagramme de vrification des exigences
La Figure V.23 montre les relations de vrification entre les oprations de V&V (qui sont strotyps par TestCase) et les exigences systme. Pour lexemple, seul les deux exigences systme la base des dclinaisons ont t considres dans ce diagramme. Les oprations de V&V correspondent alors des analyses de SdF. Elles sont dfinies dans le package V&V prsent ci-aprs.
144
Chapitre 5
Figure V.23 : Avion S18 Diagramme de vrification des exigences
Ainsi, lexigence nomme perte dclration non-annonce sera vrifie, daprs le diagramme, par une opration nomme analyse SdF perte dclration non-annonce .
4.2.3. Package de V&V : les cas de tests

Le dernier package prsenter est celui de V&V, qui renferme les cas de tests. Celui-ci contient le diagramme de la Figure V.24, qui dfinit les deux oprations de V&V entrevues au paragraphe 4.2.2.4. A ces oprations, nous associons des commentaires dans le diagramme des TestCases afin de les spcifier. Comme nous pouvons le voir sur la Figure V.24, ces commentaires sont les suivants : Pour lopration analyse SdF perte dclration non-annonce : analyser avec larbre de dfaillance de lvnement racine perte dclration non-annonce (cf. Figure V.5), Pour lopration analyse SdF dclration involontaire aprs V1 : analyser avec larbre de dfaillance de lvnement racine dclration involontaire aprs V1 (cf. Figure V.6).
Figure V.24 : Avion S18 Cas de tests
4.3. Niveau freins des roues

Le second building block tudi est celui des freins des roues . Nous prsentons galement les diffrents diagrammes prsents dans les trois packages (solution de conception, exigences, V&V) de ce building block.
145
Chapitre 5
4.3.1. Package de la solution de conception

Le premier package prsent est celui de la solution de conception ( Design Solution ), prsentant les fonctions et la structure du systme.
4.3.1.1.
Fonctions du systme
La Figure V.25 prsente les fonctions du systme freins des roues travers un diagramme de cas dutilisation. Les diffrentes fonctions retrouves ici correspondent : Le freinage de lavion au sol, qui peut tre manuel ou automatique et qui inclut une fonction danti-drapage, Le contrle de la direction au sol avec un freinage diffrentiel, Le maintien immobile de lavion quand celui-ci est parqu, Larrt de la rotation des roues lors de la rtractation des trains aprs un dcollage, La transmission dinformations concernant le freinage et ltat gnral du systme de freinage des roues.
Figure V.25 : Freins des roues Fonctions du systme
4.3.1.2.
Structure du systme
La structure du systme freins des roues est reprsente en Figure V.26 dans un diagramme de blocks. Nous retrouvons le fait que le systme freins des roues est compos de : Une ressource lectrique, Un calculateur BSCU Un systme dannonciation, Une chaine normale, incluant : une ressource et des composants hydrauliques, 146
Chapitre 5
Une chaine alternative, incluant : une ressource et des composants hydrauliques, ainsi quun accumulateur.
Figure V.26 : Freins des roues Structure du systme
La Figure V.27 propose un diagramme de structure composite pour le systme de freins des roues, dans lequel les relations entre les diffrents composants sont visibles.
Figure V.27 : Freins des roues Structure du systme (2)
147
Chapitre 5
4.3.2. Package des exigences

Le second package prsent est celui des exigences ( Requirements ).
4.3.2.1.
Diagramme des exigences haut-niveau
La Figure V.28 montre les exigences haut-niveau du systme de freins des roues. Dans ce diagramme, les risques traits par les exigences de sret haut-niveau apparaissent aussi. Ceux-ci sont : Sortie piste haute vitesse : L'avion sort de la piste haute vitesse et peut rentrer en contact avec des obstacles. Haute temprature : La temprature sur les roues atteint le point o la dfaillance du pneu/roue se produit. Feu des pneus possible. Sortie piste sur cot : L'avion sort de la piste sur le cot et peut entrer en contact avec des obstacles. Avion stopp sur piste : L'avion est stopp sur la piste. Eclatement pneus : Eclatement potentiel de tous les pneus et perte de l'efficacit du freinage.
Dans ce diagramme, nous retrouvons par exemple lexigence de sret systme la perte non-annonce de tous les freins doit avoir une frquence < 5.10-7/flt identifie lors de lAMDEC du sous-systme freins des roues (voir paragraphe 3.2.1). Cette exigence, dont lidentifiant est R2.1 , permet de traiter le risque Risk_1 : lavion sort de la piste haute vitesse et peut rentrer en contact avec des obstacles .
148
Chapitre 5
Figure V.28 : Freins des roues Diagramme des exigences haut-niveau
149
Chapitre 5
4.3.2.2.
Diagramme de dclinaison des exigences
La Figure V.29 montre la dclinaison des exigences haut-niveau (systme freins des roues) en exigences sous-systmes. Nous retrouvons ici la dclinaison synthtise au paragraphe 3.2.4 concernant lexigence sous-systme perte freins non-annonce .
Figure V.29 : Freins des roues Diagramme de dclinaison des exigences
4.3.2.3.
Diagramme de satisfaction des exigences
La Figure V.30 montre les affectations des exigences aux lments de la solution de conception (block dans notre exemple), ceci travers le lien satisy de SysML. Dans ce diagramme, nous avons choisi de ne reprsenter que les affectations des exigences concernes par la dclinaison prsente au paragraphe prcdent. Ainsi, lexigence haut-niveau est lie au systme freins des roues . Quant aux autres exigences, 150
Chapitre 5
elles sont connectes aux sous-systmes qui les concernent, comme illustr par la Figure V.30.
Figure V.30 : Freins des roues Diagramme de satisfaction des exigences
4.3.2.4.
Diagramme de vrification des exigences
La Figure V.31 montre les relations de vrification entre les oprations de V&V (qui sont strotyps par TestCase) et les exigences systme. Dans cette figure, seule lexigence systme la base de la dclinaison a t considre. Lopration de V&V correspond alors une analyse de SdF. Elle est dfinie dans le package V&V prsent ci-aprs.
Figure V.31 : Freins des roues Diagramme de vrification des exigences
Ainsi, lexigence nomme perte freins non-annonce sera vrifie, daprs le diagramme, par une opration nomme analyse SdF perte freins non-annonce .
4.3.3. Package de V&V : les cas de tests

Le dernier package prsenter est celui de V&V, qui renferme les cas de tests. Celui-ci contient le diagramme de la Figure V.32, qui dfinit lopration de V&V entrevue au paragraphe 4.3.2.4. A cette opration, nous associons un commentaire dans le diagramme 151
Chapitre 5
des TestCases afin de la spcifier. Comme nous pouvons le voir sur la Figure V.32, ce commentaire est le suivant : Pour lopration analyse SdF perte freins non-annonce : analyser avec larbre de dfaillance de lvnement racine perte des freins non-annonce (cf. Figure V.8).
Figure V.32 : Freins des roues Cas de tests
4.4. Niveau calculateur BSCU

Le troisime et dernier building block que nous avons tudi est celui du calculateur BSCU . La mme organisation que pour les deux building blocks prcdents a t faite. Etant donn que le travail ralis est similaire, nous ne prsentons pas ce niveau dans le chapitre. Nanmoins, tous les diagrammes sont fournis en annexe B de ce mmoire.
5. Synthse de ltude de cas

Pour rsumer et faire une courte synthse sur le cas dtude prsent dans ce chapitre 5, nous avons donc russi appliquer successivement, trois fois la mthodologie de dclinaison des exigences de sret de fonctionnement dfinie au chapitre 3, ceci pour trois building blocks successifs : lavion S18, le sous-systme de freins des roues et le calculateur BSCU. Nous avons alors identifi et dfini : Deux exigences de sret au niveau avion S18 , dclines au niveau des soussystmes : freins des roues, inverseurs de pousse et arofreins. Une exigence de sret au niveau freins des roues , dcline au niveau du systme dannonciation, du systme de freinage alternatif (non dcline davantage), du systme de freinage durgence (idem), de la ressource hydraulique normale, des composants hydrauliques normaux, de la ressource lectrique et du calculateur BSCU. Deux exigences de sret au niveau calculateur BSCU , dclines au niveau du moniteur gnral, du commutateur, des CPUs, des ressources lectriques, des moniteurs de puissance et des moniteurs systme.
Nous avons galement modlis lexemple laide du langage SysML augment de notre extension afin de respecter le modle dinformation dfini au chapitre 4. Nous avons ainsi illustr notre proposition pour intgrer des aspects de sret dans SysML, tel que les exigences de sret ou les risques. Un aspect important qui ressort de ce modle dinformation, qui pourra tre utilis autant par les ingnieurs systme que ceux de sret, est la traabilit. Pour donner un exemple, la Figure V.33 synthtise une partie des 152
Chapitre 5
dclinaisons dexigences de sret, dont toutes les informations (traabilit incluse) sont accessibles dans le modle dinformation. Sur cette figure, nous avons replac les identifiants des exigences du modle SysML au niveau des systmes qui les concernent. En considrant le systme gnral avion S18 , les systmes ont t catgoriss en : avion , systmes , quipements ou composants . Daprs la figure, nous pouvons par exemple retrouver le fait que lexigence R2.2.7.5 associe au CPU1 provient de lexigence R2.2.7 du BSCU, qui venait de lexigence R2.2 du systme de freins des roues, qui ellemme tait rsultat de la dclinaison de lexigence R2 associe au systme avion S18.
Figure V.33 : Synthse dune partie des dclinaisons
6. Conclusion
Ce chapitre 5, dernier chapitre du mmoire, a donc permis dillustrer les propositions du chapitre 3, concernant la mthodologie de dclinaison dexigences de sret de fonctionnement, et du chapitre 4, concernant lutilisation dun modle dinformation en SysML, ceci dans le contexte propos au chapitre 2. Nous avons montr la faisabilit de notre mthodologie de dclinaison dexigence de sret sur un exemple complexe, ceci au travers de diffrents niveaux de building blocks. Nous avons bien vu quen combinant des AMDECs et des analyses par arbres de dfaillances, nous avons russi dfinir des exigences de sret et identifier les dclinaisons des exigences de sret associes au systme en exigences de sret associes aux sous-systmes. Comme nous lavons vu en conclusion du chapitre 1, cette traabilit de la sret de fonctionnement est extrmement importante pour une vrification et une validation correcte du systme, ainsi que pour des analyses dimpacts suite un changement dexigences.
153
Chapitre 5
De surcroit, la section sur la modlisation SysML (incluant notre extension au langage) a montr les possibilits de ce langage pour une modlisation respectant notre modle dinformation. La gestion de la traabilit est parfaitement visible et les concepts dexigences, de solution de conception et de V&V sont spars en respectant une organisation claire du projet. La visualisation directement dans le modle des risques et des exigences de sret renforce la modlisation.
154
Conclusion Gnrale
Conclusion Gnrale
Pour ce travail de thse, nous nous sommes intresss la sret de fonctionnement des systmes complexes et sa prise en compte dans la conception de ces systmes. Une analyse des origines des problmes de sret de fonctionnement des systmes complexes a t ralise. De nombreux points sont lorigine de ces problmes, tel que de mauvaises dfinitions ou formulations des exigences, une mauvaise ou absence de traabilit, une absence dun langage commun entre les diffrents corps de mtiers, etc. Il nous a alors paru essentiel de dfinir une approche globale de prise en compte de la sret de fonctionnement au niveau processus dingnierie systme pour apporter des rponses aux faiblesses identifies. Le cadre de processus dingnierie systme parait vident pour traiter de la conception des systmes complexes. Par nature, les proprits de sret de fonctionnement des systmes complexes ncessitent un point de vue gnral sur le systme. Intgrer leur gestion dans un tel cadre est la solution aux problmes de sret. Ainsi, le premier objectif a t de proposer une approche de prise en compte de la sret de fonctionnement dans les processus dingnierie systme. Cette approche a t construite en se basant sur la norme EIA-632 et elle dfinit les activits spcifiques mettre en uvre concernant la sret de fonctionnement. A loccasion, nous avons identifi un p rocessus particulirement critique qui est celui dingnierie des exigences. Notamment une attention toute particulire doit tre prte concernant les exigences de sret. Cette approche structure et impose une formulation claire des exigences (notamment de sret) et recommande leurs formalisations. Elle revendique une traabilit, trs importante pour la conception de systmes complexes, particulirement en cas dvolution des exigences et de gestion de changement. Ensuite, nous nous sommes concentrs sur une mthodologie qui permet daider la dfinition dexigences de sret au niveau du systme, puis leurs dclinaisons au niveau des sous-systmes. Lintrt concernant la traabilit est immdiat concernant ces exigences de sret. Cette mthodologie, construite base dAMDEC et danalyses darbres de dfaillance, amliore ainsi la dfinition des exigences de sret, leur gestion et leur traabilit. Nous avons galement voulu se rapprocher dune approche dIngnierie Systme Base sur les Modles (ISBM). Un modle dinformation a t dfini et prsent afin de rendre plus efficace la gestion des exigences et de fournir une base commune entre tous les participants la conception, notamment entre les diffrents mtiers. Ce modle est bas sur le langage SysML et respecte les concepts dfinis dans la norme EIA-632. Il inclut explicitement des concepts important pour notre problmatique que sont les risques et les exigences de sret. Il permet une trs bonne vision des aspects de traabilit entre les 155
Conclusion Gnrale diffrentes donnes dingnierie, tout en sparant les trois concepts : exigences, solution de conception et V&V. Pour finir, nous avons illustr les diffrentes propositions sur lexemple de lavion fictif S18. Dans le cadre dune conception en suivant lapproche dfinie au deuxime chapitre et les concepts de la norme EIA-632, le cas dtude a permis dappliquer la mthodologie de dclinaison dexigences de sret du troisime chapitre, ceci sur trois niveaux. Lexemple a galement t modlis en SysML en suivant le modle dinformation prsent au quatrime chapitre. Les liens de traabilit taient alors directement visibles, ainsi que les risques et les exigences de sret qui font partie intgrante du modle. Problme dingnierie ou problme de gestion ? Pour faire une synthse des problmes de sret de fonctionnement, deux grandes familles de problmes de sret se distinguent : les problmes dingnierie et les problmes de gestion. Il ne faut pas confondre les deux. Un problme dingnierie ne peut tre rsolu quen soccupant de lingnierie, alors quun problme de gestion quen amliorant la gestion. Typiquement, un souci dans larchitecture du systme est un problme dingnierie, alors quune mauvaise traabilit est un problme de gestion. Dans notre travail, nous nous sommes finalement intresss aux deux fronts en mme temps, avec entre autres : Lapproche processus intgrant la sret de fonctionnement qui donne la fois des recommandations concernant la gestion des donnes dingnierie et lingnierie du systme, La mthodologie de dclinaison dexigence qui concerne plus lingnierie du systme, Le modle dinformation qui se retrouve plus un niveau gestion des donnes dingnierie.
Perspectives
De nombreuses perspectives sont envisageables pour amliorer et continuer le travail ralis au cours de cette thse et prsent dans ce mmoire. Celles-ci se retrouvent au niveau des trois axes de recherches prsents dans le travail : la dmarche processus propose, la mthodologie de dclinaison et le modle dinformation. La dmarche dIngnierie Systme intgrant la sret de fonctionnement Dautres processus de la norme EIA-632 pourrait tre explors et dtaills en termes de sret de fonctionnement, pour amliorer la dmarche processus propose. En effet, nous nous sommes essentiellement concentrs sur les processus de conception systme et sur quelques processus dvaluation technique (analyse des risques, validation des exigences, vrification du systme), car ces processus sont au cur de lingnierie du systme et sont primordiaux. Ce sont effectivement eux qui permettent les dfinitions des exigences et des solutions logique et physique, ainsi que des validations et vrifications de la conception. Mais nous pourrions explorer dautres processus, comme les processus de fourniture et dacquisition, les processus de planification, dvaluation et de pilotage, les processus de 156
Conclusion Gnrale ralisation et de transfert pour lutilisateur. Ltude de ces processus dun point de vue sret de fonctionnement permettrait damliorer encore la dmarche de conception propose et ainsi la sret des systmes conus en suivant cette dmarche. La mthodologie de dclinaison dexigences de sret de fonctionnement : Concernant la mthodologie de dclinaison dexigences de sret de fonctionnement, nous nous sommes concentrs sur la partie cause des modes de dfaillances, ceci en utilisant les arbres de dfaillances. Les actions correctives sattachaient rduire la frquence des causes. Il sagirait, pour complter la mthodologie, de sintresser a la partie effet des modes de dfaillances. Les actions correctives auraient alors comme objectif de rduire la gravite des effets. Une possibilit serait dutiliser des arbres dvnements pour analyser cette partie effet . Une autre continuit possible concernant la mthodologie de dclinaison serait denvisager des exigences manant dactions correctives associes aux modes de dfaillances des sous-systmes qui ninterviennent pas dans les arbres de dfaillances. La question serait de savoir comment considrer ces exigences au niveau du systme. Devraient-elles provenir dune dclinaison ? Sont-elles indicatrices doublis au niveau des analyses des dfaillances systmes ou au niveau des arbres de dfaillances ? Le modle dinformation en SysML Concernant le modle dinformation, nous avons voqu, la fin du quatrime chapitre, lutilisation potentielle du langage OCL pour la formalisation des exigences. Il sagirait donc dintgrer cette possibilit dans le modle dinformation. Egalement, nous avons envisag des analyses dfinir sur le modle dinformation, tel que des gnrations de matrices de traabilit ou encore des valuations dindicateurs ou de mtriques. Les besoins de ces analyses devraient tre identifis et leurs formalisations pourraient tre dfinies. Une extension plus importante du modle dinformation, que nous avons dfinit laide de SysML, serait de le lier un langage plus spcifique pour la solution physique. Un bon candidat pour ce langage pourrait tre AADL.
157
Conclusion Gnrale
158
Bibliographie
Bibliographie
[Aer, 2004] [AFIS] [AFIS, 2005a] [AFIS, 2005b] [Akerlund & al., 2006] SAE Aerospace. SAE AS5506: Architecture Analysis and Design Language (AADL). SAE International, 2004. AFIS, Association Franaise dIngnierie Systme, www.afis.fr. Document de vulgarisation de lIS, 2005, www.afis.fr. AFIS, Modle de donnes AFIS, version 2.0, groupe de travail Mthodes et Outils, 2005. Akerlund O., P. Bieber, E. Boede, M. Bozzano, M. Bretschneider, C. Castel, A. Cavallo, M. Cifaldi, J. Gauthier, A. Griffault, O. Lisagor, A. Ldtke, S. Metge, C. Papadopoulos, T. Peikenkamp, L. Sagaspe, C. Seguin, H. Trivedi, L. Valacca, ISAAC, a framework for integrated safety analysis of functional geometrical and human aspects, ERTS 2006, Toulouse, France, 25-27 january, 2006. Albinet A., J-L. Boulanger, H. Dubois, M-A. Peraldi-Frati, Y. Sorel and Q-D. Van. Model-based methodology for requirements traceability in embedded systems, 3rd ECMDA workshop on traceability, Haifa, Israel, June 2007. Albinet A., S. Begoc, J.-L. Boulanger, O. Casse, I. Dal, H. Dubois, F. Lakhal, D. Louar, M.-A. Peraldi-Frati, Y. Sorel and Q.-D. Van, The MeMVaTEx methodology: from requirements to models in automotive application design, in ERTS08, Toulouse, France, January 2008. Aldemir T., D.W. Miller, M.P. Stovsky, J. Kirschenbaum, P. Bucci, A.W. Fentiman, et L.T. Mangan, Current state of reliability modeling methodologies for digital systems and their acceptance criteria for nuclear power plant assessments. NUREG/CR-6901, U.S. Nuclear Regulatory Commission, Washington, DC, 2006. Alexander R., N. Herbert and T. Kelly, Deriving Safety Requirements for Autonomous Systems, 4th SEAS DTC Technical Conference, July 2009.
[Albinet & al., 2007]
[Albinet & al., 2008]
[Aldemir & al., 2006]
[Alexander & al., 2009]
159
Bibliographie [Allenby & al., 2001] Allenby K. and T. Kelly, Deriving Safety Requirements using Scenarios, 5th IEEE International Symposium on Requirements Engineering (RE'01), IEEE Computer Society Press, 2001. J. Arlat, Y. Crouzet, P. David, J.-L. Dega, Y. Deswarte, J.-C. Laprie, D. Powell, C. Rabjac, H. Schindler, J.-F. Soucailles, Fault Tolerant Computing, dans Encyclopedia of Electrical and Electronics Engineering, (Ed. J. G. Webster), Ch. 7, pp. 285-313, J. Wiley & Sons, 1999. ARP-4754: Certification considerations for highly-integrated or complex aircraft systems, Society of Automotive Engineers (SAE) standard, novembre 1996. ARP-4761: Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment, Society of Automotive Engineers (SAE) standard, dcembre 1996. Avizienis A., J.-C. Laprie, and B. Randell, Fundamental Concepts of Dependability, LAAS-CNRS, Technical Report N01145, Apr. 2001. Avizienis A., J.-C. Laprie, B. Randell, et C. Landwehr, Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, vol. 1, pp. 11-33, 2004. Bar-Yam Y.. About engineering complex systems: Multiscale analysis and evolutionary engineering. Engineering selforganizing systems: methodologies and applications, vol. 3464, pp. 16-3, 2005. Batut. J Fiabilit prvisionnelle du rseau trs haute tension dedf. In 5eme Colloque international de fiabilit et de maintenabilit, Biarritz, France, October 1986. Beizer. B, Software Testing Techniques, Van Nostrand Reinhold, New York, 2nd Edition, 1990. Bernoulli D., Specimen theoriae novae de mensura sortis, Commentarii Academiae Scientiarum Imperialis Petropolitanae 5, p. 175-192, 1738. Black J., P. Koopman, System Safety as an Emergent Property in Composite Systems. IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pp. 369-378, Estoril, Lisbon, June 29-July 2, 2009. 160
[Arlat & al., 1999]
[ARP-4754, 1996]
[ARP-4761, 1996]
[Avizienis & al., 2001]
[Avizienis & al., 2004]
[Bar-Yam, 2005]
[Batut, 1986]
[Beizer, 1990] [Bernoulli, 1738]
[Black & al., 2009]
Bibliographie [Bock, 2005] [Bock, 2006] [Boehm, 1986] [Boehm, 1988] [Boehm & al., 1994] [Booch, 1993] Bock C., Systems engineering in the product lifecycle, Int J Product Development 2(12), 123137, 2005. Bock C., SysML and UML 2 Support for Activity Modeling, Systems Engineering, 9, No. 2, pp. 160-186, 2006. Boehm B., A spiral model of software development and enhancement, ACM SIGSOFT, vol 11, N 4, August 1986. Boehm B., A Spiral Model of Software Development and Enhancement, Computer, pp. 61-72, May 1988. Boehm B., P. Bose, A Collaborative Spiral Software Process Model Based on Theory W, October 11, 1994. Booch G., Object-Oriented Analysis and Design with Applications (2nd Edition), Addison-Wesley Professional, 10 October, 1993. Booch G., J. Rumbaugh et I. Jacobson, The Unified Modeling Language User Guide, 2nd Edition, Addison Wesley, 2005. Bozzano M, Cavallo. A, Cifaldi. M, Valacca. L, Villafiorita. A. Improving Safety Assessment of Complex Systems: An Industrial case study. FM 2003. Pisa, 8-14 September 2003. Buren, JV & Cook, DA 1998, Experiences in the Adoption of Requirements Engineering Technologies, Software Technology Support Center. Buzzatto J.L., Failure mode, effects and criticality analysis (FMECA) use in the Federal Aviation Administration (FAA) reusable launch vehicle (RLV) licensing process. Digital Avionics Systems Conference, 1999. Proceedings 18th. vol.2 10/24-29/1999. Location: St Louis, MO, USA. CEI-60812: Techniques danalyse de la fiabilit du systme procdure danalyse des modes de dfaillance et de leurs effets, International Electrotechnical Commission standard, 2006. CEI-61508: Functional safety of electrical/electronic/ programmable electronic safety-related systems, International Electrotechnical Commission standard, 2010. Chatelet E., Sret de fonctionnement : mthodes et outils de base. Universit de technologie de Troyes edition, 2000. Cohn. A, "The notion of proof in hardware verification", Journal of Automated Reasoning, vol. 5, pp. 127-139, 1989.
[Booch & al., 2005] [Bozzano & al., 2003]
[Buren & al., 1998]
[Buzzatto, 1999]
[CEI-60812, 2006]
[CEI-61508, 2010]
[Chatelet, 2000] [Cohn, 1989]
161
Bibliographie [Common Criteria, 1998] Common Criteria for Information Technology Security Evaluation, Common Criteria Implementation Board, Version 2.0, CCIB-98-026, CCIB-98-027, CCIB-98-027A, CCIB-98-028, May 1998. E. Conquet and P. David, Preparing the System and Software engineering of the 21st century for critical systems with the ASSERT project, in Fifth European Dependable Computing Conference, Supplementary. Volume, (Budapest, Hungary), pp.27-32, 2005. Conquet E., The ASSERT project: a step towards reliable and scientific system and software engineering, ERTS2008, Toulouse, France, January 2008. Coulin C. R.. A Situational Approach and Intelligent Tool for Collaborative Requirements Elicitation. Thse de doctorat, University of technology, Sydney and Universit Paul Sabatier, Toulouse, 2007. David P., Contribution lanalyse de sret de fonctionnement des systmes complexes en phase de conception : application lvaluation des missions dun rseau de capteurs de prsence humaine, Thse doctorat, Universit dOrlans, 2009. David P., Idasiak V., Kratz F., Reliability study of complex physical systems using SysML, Reliability Engineering and System Safety, Vol. 95, p.431-450, 2010. Desroches A., Baudrin D., Dadoun M. Lanalyse prliminaire des risques. Edition Herms Lavoisier, 2009. Deswarte Y. SQUALE: Dependability Assessment Criteria , SQUALE Open Workshop, Toulouse, 24-25 novembre 1998. Deswarte Y., Kaniche M., Corneillie P., Benoit P., SQUALE : critres d'valuation de la sret de fonctionnement , Actes du 11me Colloque National de Fiabilit & Maintenabilit (/-11), Arcachon (France), 29 septembre - 1er octobre 1998, pp. 367376 Deswarte Y., Kaaniche M., Corneillie P., Goodson J., SQUALE Dependability Assessment Criteria, 18th International Conference on Computer Safety, Reliability and Security (SAFECOMP'99), (Toulouse, France), Lecture Notes on Computer Science 1698, Springer-Verlag, pp.27-38, 1999.
[Conquet & al., 2005]
[Conquet, 2008]
[Coulin, 2007]
[David, 2009]
[David & al., 2010]
[Desroches & al., 2009] [Deswarte, 1998] [Deswarte & al., 1998]
[Deswarte & al., 1999]
162
Bibliographie [DO-178B, 1992] DO-178B: Software considerations in airborne systems and equipment certification, RTCA et EUROCAE, 1er dcembre 1992. DO-254: Design assurance guidance for airborne electronic hardware, RTCA et EUROCAE, 19 avril 2000. Dubi A., Monte Carlo Applications in Systems Engineering. John Wiley & Sons, Ltd. England, 2000. EIA-632: Processes for engineering systems, Industries Alliance standard, 7 janvier 1999. Electronic
[DO-254, 2000] [Dubi, 2000] [EIA-632, 1999] [ESACS, 2001]
Requirements for improving the safety process on Complex Systems and definition of the tools integration concepts, WP1, ESACS, 17 mai 2001. Consortium, Enhanced Safety Assessment for Complex Systems (Project Portal), http://www.cert.fr/esacs/. Esteban P., J.-C. Pascal et D. Esteve, Une mthodologie de Conception Produit base sur la norme EIA-632, 8me Congrs International de Gnie Industriel (CIGI 2009), Bagnres de Bigorre (France), 8p, 10-12 Juin 2009. Estefan J.A., Survey of Model-Based Systems Engineering (MBSE) Methodologies. Part B. Survey of Candidate ModelBased Engineering (MBSE) Methodologie. 47p. May, 2007. INCOSE MBSE Focus Group. Evrot D., Contribution la vrification dexigences de scurit : application au domaine de la machine industrielle, Thse de doctorat, Universit Henri Poincar, Nancy I, 2008. Faisandier A., Sensibilisation l'Ingnierie des Systmes, Toulouse, MAP Systme, 2008. Faucher J., Pratique de lAMDEC, Edition DUNOD, Paris 2004. Faucher J., Pratique de lAMDEC (2me dition), Editeur Dunod, 17 juin 2009. Forsberg K., Mooz H., Visualizing project management: models and frameworks for mastering complex systems. Proceeding of the 1991 INCOSE Symposium. Forsberg K., Mooz H., The relationship of system engineering to the project cycle. Proceedings of the 1991 INCOSE Symposium.
[ESACS] [Esteban et al., 2009]
[Estefan, 2008]
[Evrot, 2008]
[Faisandier, 2008] [Faucher, 2004] [Faucher, 2009] [Forsberg & al., 1991a]
[Forsberg & al., 1991b]
163
Bibliographie [Forsberg & al., 1995] Forsberg K., Mooz H., Application of the Vee to Incremental and Evolutionary Development, Proceedings of the Fifth Annual International Symposium of the National Council on Systems Engineering, St. Louis, MO, July 1995. Friedenthal S., A. Moore and R. Steiner, A Practical Guide to SysML: The Systems Modeling Language. The MK/OMG press, Elsevier, 2008. Goguen J. and C. Linde, Techniques for requirements elicitation. In 1st IEEE International Symposium on Requirements Engineering, pages 152-164, San Diego, 4-6th January 1993. Gotel O. C. Z. and C. W. Finkelstein, An analysis of the requirements traceability problem, in International Conference on Requirements Engineering, 1994, pp. 94 101. Guillerm. R, Sadou. N, Demmou H. et Alloula K., Hybrid Approach for Deriving Feared Scenarios in Industrial Systems, SAFE PROCESS 2009 - 7th IFAC Symposium on Fauult Detection Supervision and Safety of Technical Processes, Barcelone (Espagne), 30 Juin - 3 Juillet 2009. Guillerm R., H. Demmou et N. Sadou, System engineering approach for safety management of complex systems, European Simulation and Modelling Conference (ESM'2009), Leicester (Royaume-Unis), 26-28 Octobre 2009. Guillerm. R, Sadou. N, Demmou. H.. ESA Petri net: Dynamic reliability analysis Tool. International Journal of Adaptive and Innovative Systems 1, 3/4 (2010) 201-216. Guillerm R., H. Demmou et N. Sadou, Safety Evaluation of complex system Integration in system engineering process, IEEE International Systems Conference 2010, San Diego (California, USA), 5-8 Avril 2010. Guillerm R., H. Demmou et N. Sadou, Engineering dependability requirements for complex systems - A new information model definition, IEEE International Systems Conference 2010, San Diego (California, USA), 5-8 Avril 2010. Guillerm R., H. Demmou model driven design of engineering approach, Management Conference 2010. et N. Sadou, Information model for complex system based on system Complex Systems Design and (CSDM2010), Paris, 27-29 Octobre
[Friedenthal & al., 2008]
[Goguen & al., 1993]
[Gotel & al., 1994]
[Guillerm & al., 2009a]
[Guillerm & al., 2009b]
[Guillerm & al., 2010a]
[Guillerm & al., 2010b]
[Guillerm & al., 2010c]
[Guillerm & al., 2010d]
164
Bibliographie [Guillerm & al., 2011] Guillerm R., N. Sadou et H. Demmou, Combining FMECA and Fault Trees for declining safety requirements of complex systems, European Safety and Reliability Conference (ESREL), 2011. IEEE-1220: Standard for application and management of the systems engineering process, IEEE standard, 20 mars 2005. Systems engineering handbook. International Council on Systems Engineering (INCOSE) Working Group, 2004. INCOSE, Systems Engineering Vision 2020, INCOSE-TP-2004004-02, version 2.03, septembre 2007. ISAAC Consortium, Improvement of Safety Activities on Aeronautical Complex systems (Project Portal), http://www.cert.fr/isaac/. ISO-15288: Systems and software engineering system life cycle processes, International Organization of Standardization standard, 2008. ISO-26262, Vhicules routiers scurit fonctionnelle, version projet de comit, International Organization of Standardization standard, 2008. Jacobson I., Object Oriented Software Engineering: A Use Case Driven Approach, Addison Wesley, 1 juillet 1992. Jardine. A. Maintenance, replacement and reliability, Pitman, Boston, MA, 1987. Juristo. N, A. M. Moreno, and A. Silva, Is the European Industry Moving Toward Solving Requirements: Engineering Problems?, IEEE Software, vol. 19, no. 6, pp. 7077, 2002. Khalfaoui. S . Mthode de recherche des scnarios redouts pour lvaluation de la sret de fonctionnement des systmes mcatroniques du monde automobile. Thse de Doctorat, No 03574, Institut National Polytechnique, Toulouse, 26 septembre 2003. Komi-Sirvio S. and M. Tihinen, Great Challenges and Opportunities of Distributed Software Development An Industrial Survey. In Proceedings of the Fifteenth International Conference on Software Engineering & Knowledge Engineering (SEKE2003), 2003, pp. 489496.
[IEEE-1220, 2005] [INCOSE, 2004]. [INCOSE, 2007] [ISAAC]
[ISO-15288, 2008]
[ISO-26262, 2008]
[Jacobson, 1992] [Jardine, 1987] [Juristo & al., 2002]
[Khalfaoui, 2003]
[Komi-Sirvio & al., 2003]
165
Bibliographie [Konate, 2009] Konate J., Approche systme pour la conception dune mthodologie pour llicitation collaborative des exigences, Thse de doctorat, Universit de Toulouse, 2009. Kotovsky K., J.R. Hayes et H.A. Simon, Why are some problems hard? Evidence from Tower of Hanoi, Cognitive Psychology, vol. 17, 1985. Landy G., AMDEC : Guide pratique, Edition AFNOR 2007. A. Lannoy, Matrise des risques et sret de fonctionnement : repres historiques et mthodologiques, Collection Sciences du risque et du danger, srie Notes de synthse et de recherche, 128p. janvier 2008. Laprie J.-C., J. Arlat, J.-P. Blanquart, A. Costes, Y. Crouzet, Y. Deswarte, J.-C. Fabre, H. Guillermain, M. Kaniche, K. Kanoun, C. Mazet, D. Powell, C. Rabjac, P. Thvenod, Guide de la sret de fonctionnement, Editions Cpadus, Toulouse, mai 1995, 369 p. Laprie. J-C, Sret de fonctionnement des systmes : concepts de base et terminologie, Revue de llectricit et de llectronique (REE), (11), pp.95-105, novembre 2004. Ledoux J., Gaudoin O., Modlisation alatoire en fiabilit des logiciels. Ed Hermes Science Publications, 2007. Lee W.S, Grosh D.L, Tillman F.A, Lie C.H. "Fault tree analysis, methods, and applications - A review", IEEE Transactions on Reliability, August 1, 1985; ISBN 0018-9529; r-34, page 194203. Leveson N., White Paper on Approaches to Safety Engineering, 23 avril 2003. Leveson N., M. Daouk, N. Dulac et K. Marais, A Systems Theoritic Approach to Safety Engineering, 30 October 2003. Leveson N., Model-based analysis of socio-technical risk. Technical Report ESD-WP-2004-08, MIT, Cambridge, MA, December 2004. Leveson N. et N. Dulac, Safety and Risk-Driven Design in Complex Systems-of-Systems, 1st NASA/AIAA Space Exploration Conference, Orlando (Floride), 30 janvier 1er fvrier 2005. Leveson N., M. S. Herring, B. D. Owens, M. Ingham et K. A. Weiss, Safety-Driven Model-Based System Engineering 166
[Kotovsky & al., 1985]
[Landy, 2007] [Lannoy, 2008]
[Laprie & al., 1995]
[Laprie, 2004]
[Ledoux & al., 2007] [Lee & al., 1985]
[Leveson, 2003] [Leveson & al., 2003] [Leveson, 2004]
[Leveson & al., 2005]
[Leveson & al., 2007]
Bibliographie Methodology Part I: Methodology Description, 16 dcembre 2007. [Lindsay & al., 1999] Lindsay P. A., J. A. McDermid et D. J. Tombs, A Process for Derivation and Quantification of Safety Requirements for Components of Complex Systems, Technical report, No. 99-46, dcembre 1999. Lindsay P. A., J. A. McDermid et D. J. Tombs, Deriving quantified safety requirements in complex systems, Computer safety, reliability and security, SAFECOMP 2000, Rotterdam, Pays-Bas, 24-27 Octobre 2000, vol. 1943, pp. 117-130. Lindsay P. A. et J. A. McDermid, Derivation of safety requirements for an embedded control system, Systems Engineering, Test and Evaluation Conference, Sydney, 29-30 Octobre 2002. Groupe de travail Management, Mthodes, Outils, Standards (M2OS), Fiches mthodes, Institut pour la Matrise des Risques (IMdR), septembre 2010. Magee C. and De Weck O. L., Complex System Classification, Fourteenth Annual International Symposium of the International Council on Systems Engineering (INCOSE), Toulouse, France, June 20-24, 2004. MAP Systme, http://sinergie.mapsysteme.pagesperso-orange.fr Martin. N. J., Chapter 24: Processes for Engineering a System. Citation Information. Digital Avionics Handbook, Second Edition - 2 Volume Set Edited by Cary R . Spitzer CRC Press 2001 Meinadier J.-P., Ingnierie et intgration des systmes, Editions Herms, 1998. Meinadier J.-P., Le mtier dintgration de systmes, Edition Herms-Lavoisier (540p), 2002. Messaadia M., Ingnierie systme et systme de production manufacturire : Intgration de lvolution des exigences dans le PLM, Thse de Doctorat, Universit de Toulouse, avril 2008. Mortureux Y., Analyse prliminaire des risques, Technique de lingnieur, Octobre 2002. Parviainen P., Tihinen M., Lormans M., and Van Solingen R., Requirements Engineering: Dealing with the Complexity of Sociotechnical Systems Development, Requirements 167
[Lindsay & al., 2000]
[Lindsay & al., 2002]
[M2OS, 2010]
[Magee & al., 2004]
[MAP Systme] [Martin, 2001]
[Meinadier, 1998] [Meinadier, 2002] [Messaadia, 2008]
[Mortureux, 2002] [Parviainen & al., 2004]
Bibliographie Engineering for Sociotechnical Systems, J. L. Mate and A. Silva, Eds. IdeaGroup Inc, ch.1, pp.120, 2004. [Ramesh, 1998] Ramesh B., Factors influencing requirements traceability practice, communication of the ACM, vol. 41, issue 12, pp.37-44, New York, USA, 1998. Ramesh B. and Jarke M., Towards reference models for requirements traceability, IEEE Transactions on Software Engineering, vol. 27, issue 1, pp.58-93, 2001. Rasmussen N., Reactor Safety Study An Assessment of Accident Risks in U.S., Commercial Nuclear Power Plants, WASH-1400, October 1975. Rasmussen J., Risk Management in a Dynamic Society: A Modelling Problem, Safety Science, vol. 27, No. 2/3, Elsevier Science Ltd., pp.183-213, 1997. Redouin P., Merise, comprendre et pratiquer, EDITEST, 1989. Robertson J. and S., Volere Requirements Specification Template, edition 15, Atlantic Systems Guild, 2010. Rochet S., Formalisation des processus de lIngnierie Systme : proposition dune mthode dadaptation des processus gnriques diffrents contexte dapplication, Thse de Doctorat, INSA de Toulouse, 26 novembre 2007. Rogovin M., Three Mile Island: a report to the commissioners and to the public, Technical Report, Nuclear Regulatory Commission, Washington, DC (USA), January 1979. Rumbaugh J. R., Blaha M. R., Lorensen W., Eddy F., Premerlani W., Object-Oriented Modeling and Design, PrenticeHall, 1st October, 1990. Sadou N., Aide la conception des systmes embarqus srs de fonctionnement, Thse de Doctorat, Universit de Toulouse, 6 novembre 2007. Sadou N. and Demmou H., Reliability analysis of discrete event dynamic systems with Petri nets, Reliability Engineering & System Safety, pp.1862-1868, november 2009. Sahraoui A.-E.-K., Requirements Traceability Issues: Generic Model, Methodology And Formal Basis, International Journal of Information Technology and Decision Making, vol. 4, no. 1, pp. 5980, 2005.
[Ramesh & al., 2001]
[Rasmussen, 1975]
[Rasmussen, 1997]
[Redouin, 1989] [Roberston, 2010] [Rochet, 2007]
[Rogovin, 1979]
[Rumbaugh & al., 1990]
[Sadou, 2007]
[Sadou & al., 2009]
[Sahraoui, 2005]
168
Bibliographie [Sheard, 2006] Sheard S., Complex Systems Science and its Effects on Systems Engineering, European Systems Engineering Conference, Edinburgh, UK, 18-20 September 2006. Sinnamon M. and Andrews J. D., Fault trees and binary decision diagrams, Proceedings of the Annual Reliability and Maintainability Symposium, pp.215-222, 1996. Sommerville I. and Sawyer P., Requirements Engineering: A Good Practice Guide, 1st edition, John Wiley & Sons, 1997. Sommerville I., Software Engineering (Update) (8th Edition), International Computer Science, Addison-Wesley Longman Publishing Co., Boston, MA, USA, 2006. Software & Systems Process Engineering Meta-Model Specification (SPEM), version 2.0, Object Management Group (OMG), avril 2008. SQUALE (Security, Safety and Quality Evaluation for Dependable Systems): Dependability Assessment Criteria, 4th draft, janvier 1999. SQUALE (Security, Safety and Quality Evaluation for Dependable Systems): End of Project Report, 26 fvrier 1999. Systems Modeling Language (SysML), version 1.1, Object Management Group (OMG), novembre 2008. TCSEC: Department of Defense Trusted Computer System Evaluation Criteria, U.S. Department of Defense, 1985. Unified Modeling Language (UML), Superstructure, version 2.3, Object Management Group (OMG), mai 2010. Verries J., Paludetto M. and Saharaoui A.-E.-K., From design with SysML to VHDL-AMS simulation, Proceeding of ESM08, pp.115-120, Le Havre, Oct. 2008. Verries J., Approche pour la conception de systmes aronautiques innovants en vue doptimiser larchitecture Application au systme portes passagers, Thse de doctorat, Universit de Toulouse, 2010. Vesely W. E. and Roberts N. H., Fault Tree Handbook, U.S. Nuclear Regulatory Commission, Government Printing Office, 1987.
[Sinnamon & al., 1996]
[Sommerville & al., 1997] [Sommerville, 2006]
[SPEM, 2008]
[SQUALE, 1999a]
[SQUALE, 1999b] [SysML, 2008] [TCSEC, 1985] [UML, 2010] [Verries & al., 2008]
[Verries, 2010]
[Vesely & al., 1987]
169
Bibliographie [Vhd, 1999] 1076.1-1999 IEEE Standard VHDL Analog and Mixed-Signal Extensions Language Reference Manual, IEEE Press, ISBN 07381-1640-8. Villemeur A., Sret de Fonctionnement des Industriels, Paris : Edition Eyrolles, 785p, 1988. Volere, Atomic Requirement, www.volere.co.uk. Watson H.A., Launch Control Safety Study, section VII Vol. 1, Bell Labs, Murray Hill, NJ, 1961. Wu W. and Kelly T., Deriving Safety Requirements as Part of System Architecture Definition, 24th International System Safety Conference, System Safety Society, Albuquerque (USA), August 2006. Zeigler B.P, Praehofer H. and Kim T.G., Theory of modelling and simulation, Academic Press, San Diego, California, USA, 2000. Systmes
[Villemeur, 1988] [Volere] [Watson, 1961] [Wu & al., 2006]
[Zeigler & al., 2000]
170
Annexe A
Annexe A : Mots-cls associs au modle de dveloppement SdF explicite

1. Expression des exigences
1.1. Processus de cration
Spcifications fonctionnelles o Dfinitions des fonctions (services attendus en valeur et en temps) o Description et enchanement des phases (systmes phass) o Rpartition prliminaire des tches entre lhomme et le systme Description de lenvironnement dutilisation o Frontires du systme (environnement sociotechnique) o Caractristiques de lenvironnement et profils des utilisateurs o Modes dexploitation Contraintes de dveloppement, de validation et dexploitation o Contraintes physiques (poids, technologie, etc.) o Evolutions prvisibles o Portabilit et interoprabilit souhaites o Rutilisation o Testabilit o Contraintes dexploitation et de maintenance
1.2. Processus de prvention de fautes

Formalismes et langages o Exigences de certification, rglementation, normes et standards o Choix des formalismes, outils et environnements pour le dveloppement Organisation projet o Attribution des tches et organisation des quipes o Gestion de la sous-traitance o Gestion des ressources Planification projet et valuation des risques lis au dveloppement o Identification des risques (contraintes de dveloppement et dexplo itation, volution des technologies) o Moyens pour la rduction des risques o Choix dune stratgie de dveloppement o Planification de chaque tape du projet (objectifs, moyens, cots, dlais) o Dfinition des critres de transition entre les diffrentes tapes
171
Annexe A
o o Planification des revues de projet et des audits Planification de la gestion des configurations
1.3. Processus de tolrance aux fautes

Comportement en prsence de dfaillances o Identification et dosage des attributs de la sret de fonctionnement mis en jeu o Hypothses de dfaillance et modes dgrads possibles Dfinition des dfaillances Modes de dfaillance (domaine, perception, consquences) Dure maximale dinterruption de service admissible Nombre de fautes successives tolrer dans chaque mode
1.4. Processus dlimination des fautes

Prparation du plan de vrification o Dfinition des stratgies de vrification statique (revues, inspection, ) o Dfinition des stratgies de test (critres de test, mthodes de gnration) o Spcification des simulateurs denvironnement ventuels Hypothses pour la vrification Vrification des exigences o Analyse comportementale (vrification de proprits) o Revues et inspection de la spcification o Agrment de la spcification Maquettage Mise en situation doprateurs Revue par experts Conception de scnarios de vrification fonctionnelle
1.5. Processus de prvision des fautes

Expression des objectifs de sret de fonctionnement o Choix des mesures et assignation dobjectifs quantifis Analyse des modes de dfaillance, de leurs effets et de leur criticit o Identification des modes de dfaillance o Classification des dfaillances/svrit o Classes de dfaillance prendre en compte Hypothses pour la prvision o Hypothses pour la modlisation et paramtres o Caractrisation de lenvironnement dutilisatio n et de maintenance Paramtres de lenvironnement (temprature, pression, etc.) Profil oprationnel (frquence dutilisation/fonction) Allocation sret de fonctionnement par fonction o Classement des fonctions par niveau de criticit Prparation du plan de prvision des fautes o Choix des mthodes et outils danalyse et dvaluation ordinale et probabiliste o Dfinition dune procdure de collecte de donnes Collecte et analyse o Produits existants : retour dexprience Donnes de fiabilit Donnes sur lenvironnement de dveloppement et dutilisation
172
Annexe A
o Produits en cours : suivi du produit (nombre de fautes, etc.)
2. Conception
Dfinition de larchitecture o Structure Dcomposition en couches et/ou en composants Rpartition des tches entre lhomme et le systme o Comportement Requtes/rponses entre couches et les interactions entre composants o Donnes Nature et flots des donnes entre composants Choix des technologies o Identification des composants matriels et logiciels Identification des composants rutilisables o Dfinition des adaptations ncessaires Prparation des procdures dexploitation et de maintenance Prparation du plan dintgration o Stratgie dintgration de larchitecture o Plan dintgration du systme dans son environnement

Formalismes et langages o Choix des formalismes, outils et environnements pour le dveloppement o Normes et standards Gestion de projet Planification projet et valuation des risques lis au dveloppement

Comportement en prsence de fautes o Hypothses de fautes (fautes prises en compte et fautes exclues) Nature des fautes (accidentelles, intentionnelles) Cause phnomnologique (physiques, humaines) Frontires du systme (internes, externes) Persistance temporelle (permanentes, temporaires) Modes de dfaillance (domaine, perception, consquences) o Modles derreurs Partitionnement o Niveau(x) de dtail de lapplication de la tolrance Zones dindpendance des fautes Zones de confinement des erreurs o Couches dapplication de la tolrance o Supports de tolrance et rpartition des tches entre lhomme et le systme Choix des techniques de tolrance aux fautes o Diversification fonctionnelle o Programmation dfensive
173
Annexe A
o Techniques de protection Mcanismes de traitement derreurs o Dtection o Diagnostic o Recouvrement Mcanismes de traitement des fautes o Diagnostic o Passivation o Reconfiguration Identification des points durs

Hypothses pour la vrification Vrification de la conception o Analyse comportementale (vrification de proprits) o Revues et inspections de la conception o Prototypage et mise en situation des oprateurs o Vrification de la conception par rapport aux exigences Vrification des mcanismes de tolrance aux fautes o Vrification (formelle) des algorithmes de traitements derreurs et de fautes o Injection de fautes par simulation (modle de fautes) Prparation des tests unitaires et des tests dintgration o Dfinition des stratgies de test (critres de test, mthodes de gnration) o Dfinition des stratgies dinjection de fautes Conception de scnarios de vrification fonctionnelle et structurelle Vrification de lvaluation

Hypothses pour la prvision Analyse des modes de dfaillance, de leurs effets et de leur criticit Allocation de sret de fonctionnement par composant Evaluation prliminaire de la sret de fonctionnement o Mthodes Modles analytiques Simulation o Dimensionnement Redondances (hommes et systme) Couvertures Collecte et analyse o Donnes sur les dfaillances des composants ( partir des bases de donnes existantes) o Suivi et analyse des fautes identifies
174
Annexe A
3. Ralisation
Ralisation des composants o Fabrication des composants matriels o Codage des composants logiciels Adaptation des composants rutiliss Paramtrisation

Formalismes et langages o Choix des formalismes, outils et environnements pour le dveloppement o Normes et standards pour la ralisation Gestion de projet Planification projet et valuation des risques lis au dveloppement

Mise en uvre des mcanismes de tolrance aux fautes

Hypothses pour la vrification Vrification de la ralisation o Vrification de chaque composant vis--vis de sa spcification (test, revues) o Revues et inspection de la ralisation o Tests de charge et de robustesse Vrification de lvaluation

Hypothses pour la prvision Evaluation de la couverture des tests Evaluation de la fiabilit des composants Evaluation prliminaire de la sret de fonctionnement du systme Collecte et analyse o Relevs de dfaillance et de correction des composants o Catgorisation et analyse des fautes, erreurs, dfaillances
4. Intgration
Intgration des composants Intgration du systme dans son environnement
175
Annexe A

Formalismes et langages o Choix des formalismes, outils et langages pour lintgration o Normes et standards pour lintgration Gestion de projet Planification projet et valuation des risques lis au dveloppement

Intgration des composants de tolrance aux fautes avec les autres composants

Hypothses pour la vrification Vrification de lintgration par rapport larchitecture Vrification des mcanismes de tolrance aux fautes Tests dinteroprabilit Vrification du produit par rapport sa spcification Test du systme dans son environnement Tests de qualification Vrification de lvaluation

Hypothses pour la prvision Evaluation de la couverture des tests Evaluation de la tolrance aux fautes Evaluation des mesures de sret de fonctionnement Collecte et analyse o Relevs de dfaillance, derreur et de correction (systme) o Catgorisation et analyse des fautes, erreurs, dfaillances
176
Annexe B
VI.
Annexe B : Modlisation SysML du niveau calculateur BSCU

Le troisime et dernier building block modlis dans le cas dtude de lavion S18, prsent au chapitre 5, est celui du calculateur BSCU . Nous prsentons ici les diffrents diagrammes prsents dans les trois packages (solution de conception, exigences, V&V) de ce building block.
1. Package de la solution de conception

Le premier package prsent est celui de la solution de conception ( Design Solution ), prsentant les fonctions et la structure du systme.
1.1. Fonctions du systme

La Figure B.1 prsente les fonctions du systme calculateur BSCU travers un diagramme de cas dutilisation. Les diffrentes fonctions retrouves ici correspondent : Le rglage du freinage afin dviter le drapage des roues, La slection du mode de freinage (manuel ou automatique), La transmission dinformations concernant le statut du calculateur BSCU, La gnration de commande de freinage en fonction des commandes reues et de ltat du systme.
Figure B.1 : Calculateur BSCU Fonctions du systme
177
Annexe B
1.2. Structure du systme

La structure du systme calculateur BSCU est reprsente en Figure B.2 dans un diagramme de blocks. Nous retrouvons le fait que le systme calculateur BSCU est compos de : Deux ressources lectriques, Deux moniteurs de puissance, Deux CPU, Deux moniteurs systme, Un moniteur gnral, Un commutateur.
Figure B.2 : Calculateur BSCU Structure du systme
2. Package des exigences

Le second package prsent est celui des exigences ( Requirements ).
2.1. Diagramme des exigences haut-niveau

La Figure B.3 montre les exigences haut-niveau du systme calculateur BSCU . Dans ce diagramme, nous retrouvons par exemple lexigence de sret systme la perte du calculateur BSCU entrainant la perte de la commande de freinage doit avoir une frquence < 3,3.10-5/flt identifie lors de lAMDEC du calculateur BSCU (voir paragraphe 3.3.1 du chapitre 5).
Figure B.3 : Calculateur BSCU Diagramme des exigences haut-niveau
178
Annexe B
2.2. Diagramme de dclinaison des exigences

Le diagramme rpartit entre la Figure B.4 et la Figure B.5 montrent les dclinaisons des exigences haut-niveau (systme calculateur BSCU) en exigences sous-systmes. Nous retrouvons les dclinaisons synthtises au paragraphe 3.3.4 du chapitre 5 concernant les exigences sous-systme : panne BSCU provoque perte commande freinage , pour la Figure B.4, panne BSCU provoque freinage involontaire , pour la Figure B.5.
Remarque : dans ce diagramme, nous constatons que lexigence sous-systme R2.2.7.4 appartient aux deux dclinaisons (celle de lexigence R2.2.7 et celle de lexigence R20) Une fois lexigence R2.2.7.4 lie lexigence R2.2.7 pour la premire dclinaison, il tait impossible dutiliser la relation de composition containement (prvue pour les exigences) pour la deuxime dclinaison (celle de lexigence R20). Cela signifie que, tel que SysML est dfini, une exigence sous-systme ne peut pas appartenir deux exigences systmes. Dans TauG2, nous avons opt pour une solution rapide et simple qui est lutilisation du lien de composition classique .
Figure B.4 : Calculateur BSCU Diagramme de dclinaison des exigences (partie 1/2)
179
Annexe B
Figure B.5 : Calculateur BSCU Diagramme de dclinaison des exigences (partie 2/2)
180
Annexe B
2.3. Diagramme de satisfaction des exigences

La Figure B.6 montre les affectations des exigences aux lments de la solution de conception (block dans notre exemple), ceci travers le lien satisy de SysML.
Figure B.6 : Calculateur BSCU Diagramme de satisfaction des exigences
181
Annexe B Dans ce diagramme, nous avons choisi de ne reprsenter que les affectations des exigences concernes par les dclinaisons prsentes au paragraphe prcdent. Ainsi, les exigences haut-niveaux sont lies au systme calculateur BSCU . Quant aux autres exigences, elles sont connectes aux sous-systmes qui les concernent (moniteur gnral, CPU1, CPU2, ressource lectrique 1, ressource lectrique 2, commutateur, etc.).
2.4. Diagramme de vrification des exigences

La Figure B.7 montre les relations de vrification entre les oprations de V&V (qui sont strotyps par TestCase) et les exigences systme. Pour lexemple, seul les deux exigences systme la base des dclinaisons ont t considres dans ce diagramme. Les oprations de V&V correspondent alors des analyses de SdF. Elles sont dfinies dans le package V&V prsent ci-aprs.
Figure B.7 : Calculateur BSCU Diagramme de vrification des exigences
Ainsi, lexigence nomme panne BSCU provoque perte commande freinage sera vrifie, daprs le diagramme, par une opration nomme analyse SdF BSCU provoque perte commande .
3. Package de V&V : les cas de tests

Le dernier package prsenter est celui de V&V, qui renferme les cas de tests. Celui-ci contient le diagramme de la Figure B.8, qui dfinit les deux oprations de V&V entrevues au paragraphe 2.4 de ce chapitre. A ces oprations, nous associons des commentaires dans le diagramme des TestCases afin de les spcifier. Comme nous pouvons le voir sur la Figure B.8, ces commentaires sont les suivants : Pour lopration analyse SdF BSCU provoque perte commande : analyser avec larbre de dfaillance de lvnement racine panne du calculateur BSCU provoque perte de commande de freinage (cf. Figure V.10 et Figure V.11), Pour lopration analyse SdF BSCU provoque freinage involontaire : analyser avec larbre de dfaillance de lvnement racine panne du calculateur BSCU provoque freinage involontaire (cf. Figure V.12, Figure V.13 et Figure V.14).
182
Annexe B
Figure B.8 : Calculateur BSCU Cas de tests
183
Annexe B
184
Abstract
Integration of Dependability in System Engineering Processes
Abstract: The integration of various technologies, including computer and electronics, makes the nowadays designed systems increasingly complex. They have behaviors which are more elaborate and difficult to predict, they have a greater number of components in interaction and/or perform highest level functions. Parallel to this increasing complexity of these systems, the competitive of the global market imposes strong constraints of cost and time to the system developers. Other strong constraints deal with the quality of these systems, especially when they involve human risks or significant financial risks. Thus, developers are forced to adopt a rigorous design approach to meet the desired system requirements and satisfy the various constraints (cost, time, quality, dependability...). Several methodological approaches to guide the system design are defined through system engineering standards. Our work is based on the EIA-632 standard, which is widely used, especially in the aeronautical and military fields. It is to improve the systems engineering process described by the EIA-632, in order to incorporate a global and explicit consideration of dependability. Indeed, till now the dependability was achieved by reusing generic models after having studied and developed independently each function. So there was no specific consideration of the risks associated with the integration of several technologies. For this reason, we propose to concern ourselves with the dependability requirements at the global level and as early as possible in the development phase. Then, these requirements will be decline to lower levels. We based our approach on the processes of the EIA-632 standard that we expand. We also propose an original method for the declination of the dependability requirements based on fault trees and FMEAC, and an information model based on SysML in order to support our approach. An example from the aeronautical field illustrates our proposals.
Keywords: System engineering, Processes, EIA-632, Dependability, FMECA, Fault trees, Requirements, Information model, SysML.
185
186
AUTEUR : Romaric GUILLERM TITRE : Intgration de la Sret de Fonctionnement dans les Processus dIngnierie Systme DIRECTEURS DE THESE : Hamid DEMMOU et Nabil SADOU LIEU ET DATE DE SOUTENANCE : LAAS-CNRS, 15 juin 2011
RESUME
Lintgration de diverses technologies, notamment celles de linformatique et llectronique, fait que les systmes conus de nos jours sont de plus en plus complexes. Ils ont des comportements plus labors et plus difficiles prvoir, ont un nombre de constituants en interaction plus important et/ou ralisent des fonctions de plus haut niveau. Paralllement cette complexification des systmes, la comptitivit du march mondial impose aux dveloppeurs de systmes des contraintes de cot et de dlais de plus en plus strictes. La mme course sopre concernant la qualit des systmes, notamment lorsque ceuxci mettent en jeu un risque en vies humaines ou un risque financier important. Ainsi, les dveloppeurs sont contraints dadopter une approche de conception rigoureuse pour rpondre aux exigences du systme souhait et satisfaire les diverses contraintes (cot, dlais, qualit, sret de fonctionnement,). Plusieurs dmarches mthodologiques visant guider la conception de systme sont dfinies par lintermdiaire de normes dIngnierie Systme. Notre travail sappuie sur la norme EIA-632, qui est largement employe, en particulier dans les domaines aronautique et militaire. Il consiste amliorer les processus dingnierie systme dcrits par lEIA-632, afin dintgrer une prise en compte globale et explicite de la sret de fonctionnement. En effet, jusqu prsent la sret de fonctionnement tait obtenue par la rutilisation de modles gnriques aprs avoir tudi et dvelopp chaque fonction indpendamment. Il ny avait donc pas de prise en compte spcifique des risques lis lintgration de plusieurs technologies. Pour cette raison, nous proposons de nous intresser aux exigences de Sret de Fonctionnement au niveau global et le plus tt possible dans la phase de dveloppement, pour ensuite les dcliner aux niveaux infrieurs, ceci en sappuyant sur les processus de la norme EIA-632 que nous toffons. Nous proposons galement une mthode originale de dclinaison d'exigences de sret de fonctionnement base d'arbres de dfaillances et d'AMDEC, ainsi quun modle d'information bas sur SysML pour appuyer notre approche. Un exemple issu du monde aronautique permet dillustrer nos propositions.
MOTS-CLES
Ingnierie systme, Processus, EIA-632, Sret de fonctionnement, AMDEC, Arbres de dfaillances, Exigences, Modle dinformation, SysML.
DISCIPLINE : Systmes Industriels
LAAS-CNRS
7, avenue du Colonel Roche - 31077 TOULOUSE Cedex 4 France Tl. : +33 (0)5 61 33 32 00 - Fax. : +33 (0)5 61 55 35 77 - Mail : laas-contact@laas.fr - http://www.laas.fr

2011tou30161 2 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2011tou30161 2 PDF

Transféré par

Droits d'auteur :

Formats disponibles

THSE

DOCTORAT DE LUNIVERSIT DE TOULOUSE

Prsente et soutenue par Romaric GUILLERM Le 15 juin 2011 Titre :

Intgration de la Sret de Fonctionnement dans les Processus dIngnierie Systme

Le 1 juillet 2011, Toulouse Romaric GUILLERM

Table des Matires

Table des Matires

3. Ingnierie Systme .............................................................................................. 7

Gestion des risques ................................................................................................17

4. Sret de fonctionnement .................................................................................. 23

5. Sret de fonctionnement des systmes complexes ......................................... 30

Chapitre 2 : Dmarche processus propose ................................... 37

Quelques projets .................................................................................................... 40

Autres travaux de recherche ................................................................................. 43

3. Processus et normes dIngnierie Systme ....................................................... 49

4. Approche globale propose ................................................................................. 59

4.2.1. 4.2.2. 4.3. 4.3.1. 4.3.2. 4.3.3.

Les processus dvaluation technique ...................................................................64

Chapitre 3 : Mthodologie de dclinaison dexigences de sret de fonctionnement .............................................................................. 67

3. Travaux sur la dclinaison dexigences de sret de fonctionnement ............. 69

4. Prsentation de la mthodologie ....................................................................... 72

4.2.1. 4.2.2. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4.

Mthodologie de dclinaison ..................................................................................78

Table des Matires

5. Formalisation UML ........................................................................................... 80

6. Cas dtude ......................................................................................................... 83

6.2.1. 6.2.2. 6.2.3. 6.2.4. 6.3.

Utilisation de la formalisation UML..................................................................... 86

7. Bilan de la mthodologie et complment .......................................................... 87 8. Conclusion .......................................................................................................... 88

Chapitre 4 : Vers une mthodologie ISBM ..................................... 89

Travaux relatifs aux modles dinformation ......................................................... 96

Triptyque exigences-solutions-V&V, principe de bonne conception .................. 103 VIII

Table des Matires

3. Modle propos ................................................................................................. 103

Extension propose de SysML ............................................................................. 109

Prsentation du modle dinformation ................................................................ 114

4. Complments au modle .................................................................................. 115

5. Conclusion ........................................................................................................ 117

Chapitre 5 : Exemple illustratif de lavion S18 ............................ 119

Le systme freins des roues ............................................................................ 121

Le systme calculateur BSCU ........................................................................ 123

3. Application de la mthodologie de dclinaison dexigences de Sret de Fonctionnement ...................................................................................................... 124

Niveau freins des roues .................................................................................. 129

Niveau calculateur BSCU .............................................................................. 132

4. Modlisation SysML ........................................................................................ 137

Niveau avion S18 ............................................................................................ 140

Niveau freins des roues .................................................................................. 145

Niveau calculateur BSCU .............................................................................. 152

5. Synthse de ltude de cas ............................................................................... 152 6. Conclusion ........................................................................................................ 153

2. Conception ........................................................................................................ 173

3. Ralisation ........................................................................................................ 175

Annexe B : Modlisation SysML du niveau calculateur BSCU ............................................................................................................... 177

2. Package des exigences ..................................................................................... 178

3. Package de V&V : les cas de tests ................................................................... 182

Table des Matires

Table des Figures

Table des Figures

Ingnierie des systmes complexes et sret de fonctionnement

Chapitre 1 : Ingnierie des systmes complexes et sret de fonctionnement

Ingnierie des systmes complexes et sret de fonctionnement

Ingnierie des systmes complexes et sret de fonctionnement

2.3. Proprits mergentes

Ingnierie des systmes complexes et sret de fonctionnement