Intégration de la sûreté de fonctionnement dans les processus d'ingénierie système

(1)

THÈSE

En vue de l'obtention du

DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE

Délivré par l’Université Toulouse III – Paul Sabatier Discipline ou spécialité : Systèmes Industriels

Présentée et soutenue par Romaric GUILLERM Le 15 juin 2011

Titre :

Intégration de la Sûreté de Fonctionnement

dans les Processus d’Ingénierie Système

JURY

M. Antoine RAUZY, Chargé de Recherches à l’Ecole Polytechnique de Paris (Président) M. Jean-Pierre BOUREY, Professeur à l’Ecole Centrale de Lille (Rapporteur)

M. Frédéric KRATZ, Professeur à l’ENSI de Bourges (Rapporteur) M. Jean-Claude PASCAL, Professeur à l’UPS de Toulouse (Examinateur) M. Hamid DEMMOU, Maître de Conférences à l’UPS de Toulouse (Directeur)

M. Nabil SADOU, Professeur-assistant à Supélec de Rennes (Co-directeur)

Ecole doctorale : Systèmes Unité de recherche : LAAS-CNRS

(2)

(3)

Remerciements

I

Remerciements

Le travail présenté dans ce mémoire a été réalisé au Laboratoire d’Analyse et d’Architecture des Systèmes (L.A.A.S.) du C.N.R.S. de Toulouse, au sein du groupe de recherche Ingénierie Système et Intégration (I.S.I.).

Mes remerciements vont en premier lieu à Monsieur Raja CHATILA, directeur du LAAS, pour m’avoir accueilli dans ce laboratoire pendant ces années de travail.

Je remercie également Monsieur Hamid DEMMOU, Maître de Conférence HDR à l’Université Paul Sabatier de Toulouse, de m’avoir accueilli au sein de son groupe de recherche I.S.I. et d’avoir encadré mon travail en m’apportant nombres de recommandations.

Ce travail a également été dirigé par Monsieur Nabil SADOU, Professeur-assistant à l’Ecole Supélec de Rennes, à qui j’exprime ma gratitude pour ses conseils, son soutien et sa confiance.

Je tiens à remercier Monsieur Antoine RAUZY, Chargé de Recherches au Laboratoire d’informatique de l’Ecole Polytechnique de Paris, de m’avoir fait l’honneur de présider mon jury de soutenance.

Je suis très reconnaissant envers Monsieur Jean-Pierre BOUREY, Professeur à l’Ecole Centrale de Lille, et Monsieur Frédéric KRATZ, Professeur à l’Ecole Nationale Supérieure d’Ingénieurs de Bourges, d’avoir accepté d’étudier mon travail et d’en être les rapporteurs ainsi que pour l’intérêt et l’attention qu’ils ont accordés à cette étude.

J’exprime toute ma gratitude à Monsieur Antoine RAUZY et à Monsieur Jean-Claude PASCAL, Professeur à l’Université Paul Sabatier de Toulouse, d’avoir accepté d’examiner ce travail.

Je voudrais également exprimer une profonde gratitude à Monsieur Abd-El-Kader SAHRAOUI, Professeur à l’Université de Toulouse Le Mirail, pour les nombreuses discutions que nous avons pu avoir et qui m’ont permis d’avancer dans mon travail, ainsi que pour son amitié.

Je remercie enfin l’ensemble des personnels du laboratoire LAAS, et plus particulièrement l’ensemble des membres (ou anciens membres) du groupe I.S.I., pour leur accueil. Je ne saurais oublier non plus mes collègues doctorants ou stagiaires qui m’ont tenu compagnie et avec qui j’ai 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,

(4)

II

Frédérique 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-père, mes sœurs 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 fidélité dans leur engagement à mes côtés, notamment dans les moments les plus difficiles.

Le 1 juillet 2011, à Toulouse Romaric GUILLERM

(5)

Dédicaces

III

Je dédie ce travail de thèse, aboutissement de mes études, à ma Mère, sans qui rien n’aurait était possible.

Je le dédie également à une personne qui m’est très chère, à laquelle je souhaite une même prochaine réussite.

(6)

(7)

Table des Matières

V

Table des Matières

Introduction Générale ... 1

Chapitre 1 : Ingénierie des systèmes complexes et sûreté de

fonctionnement ... 5

1. Introduction ... 5

2. Systèmes complexes ... 5

2.1. Définition d’un système ... 5

2.2. Complexité ... 6

2.3. Propriétés émergentes ... 7

3. Ingénierie Système ... 7

3.1. Historique et définition ... 8

3.2. Cycle de vie et cycle de développement ... 9

3.3. Approche générale de conception des systèmes ... 10

3.4. Ingénierie des exigences ... 13

3.4.1. Définition d’une exigence ... 14

3.4.2. Rôle et intérêt de l’ingénierie des exigences ... 14

3.4.3. Expression des exigences ... 15

3.4.4. Traçabilité ... 15

3.4.5. Changement d’exigences ... 15

3.4.6. Quelques outils d’ingénierie des exigences ... 16

3.5. Gestion des risques ... 17

3.5.1. Définition d’un risque ... 17

3.5.2. Pourquoi s’intéresser aux risques ? ... 18

3.5.3. Etapes de la gestion des risques ... 19

3.5.4. Stratégies de la gestion des risques ... 20

3.5.5. Outils de la gestion des risques ... 21

3.5.6. Synthèse ... 22

(8)

VI

4.1. Historique ... 23

4.2. Concepts et définitions ... 24

4.3. Quelques méthodes de sûreté de fonctionnement ... 26

4.4. Enjeu de la sûreté de fonctionnement ... 29

5. Sûreté de fonctionnement des systèmes complexes ... 30

5.1. Exemples d’échecs ... 30

5.1.1. Navette spatiale Challenger ... 30

5.1.2. Ariane 5 ... 30

5.1.3. Mars Polar Lander ... 31

5.1.4. Plate-forme pétrolière BP ... 31

5.2. Origines des problèmes de sûreté de fonctionnement ... 32

5.3. Nécessité d’une approche globale ... 34

6. Conclusion ... 35

Chapitre 2 : Démarche processus proposée ... 37

1. Introduction ... 37

2. Etat de l’art pour une conception de systèmes sûrs ... 37

2.1. Normes de Sûreté ... 37

2.1.1. CEI-61508 et ses dérivées ... 37

2.1.2. ARP-4754 ... 38 2.1.3. ARP-4761 ... 40 2.2. Quelques projets ... 40 2.2.1. SQUALE ... 40 2.2.2. ESACS ... 41 2.2.3. ISAAC ... 42 2.2.4. ASSERT ... 43

2.3. Autres travaux de recherche ... 43

2.3.1. Modèle de développement à sûreté de fonctionnement explicite ... 43

2.3.2. Méthodologie d’IS basée sur les modèles et guidées par la SdF ... 45

2.4. Synthèse ... 47

3. Processus et normes d’Ingénierie Système ... 49

3.1. Vision processus ... 50

3.2. Normes d’Ingénierie Système (IEEE-1220, EIA-632, ISO-15288) ... 51

3.3. Paradigme processus-méthodes-outils ... 53

(9)

Table des Matières

VII

3.4.1. Historique et généralité ... 53

3.4.2. Interaction entre les différents processus ... 54

3.4.3. Les 33 sous-processus de l’EIA-632 ... 55

3.4.4. Structure d’un système selon l’EIA-632 ... 56

3.4.5. Vision des exigences de l’EIA-632 ... 57

4. Approche globale proposée ... 59

4.1. Principe d’intégration de la SdF ... 59

4.2. Les processus de conception système ... 60

4.2.1. Le processus de définition des exigences ... 60

4.2.2. Le processus de définition de la solution ... 62

4.3. Les processus d’évaluation technique ... 64

4.3.1. Le processus d’analyse des systèmes ... 65

4.3.2. Le processus de validation des exigences ... 65

4.3.3. Le processus de vérification du système ... 66

5. Conclusion ... 66

Chapitre 3 : Méthodologie de déclinaison d’exigences de sûreté

de fonctionnement ... 67

1. Introduction ... 67

2. Déclinaison d’exigences de sûreté de fonctionnement ... 67

2.1. Pourquoi cette déclinaison ? ... 67

2.2. Déclinaison vis-à-vis des processus d’ingénierie système ... 68

3. Travaux sur la déclinaison d’exigences de sûreté de fonctionnement ... 69

3.1. Travaux de Peter Lindsay, John McDermid et David Tombs ... 69

3.2. Travaux de Tim Kelly et al. ... 71

4. Présentation de la méthodologie ... 72

4.1. Aperçu de la méthodologie ... 73 4.2. Méthodes utilisées ... 73 4.2.1. AMDEC ... 74 4.2.2. Arbre de défaillances ... 75 4.3. Méthodologie de déclinaison ... 78

4.3.1. Etape 1 : Analyse des défaillances du système ... 78

4.3.2. Etape 2 : Analyses des causes des défaillances... 79

4.3.3. Etape 3 : Analyses des défaillances des sous-systèmes ... 80

(10)

VIII

5. Formalisation UML ... 80

5.1. Formalisation de l’AMDEC ... 81

5.2. Formalisation de l’Arbre de Défaillances... 81

5.3. Formalisation de la méthodologie complète ... 82

6. Cas d’étude ... 83

6.1. Présentation de l’exemple ... 83

6.2. Application de la méthodologie ... 83

6.2.2. Etape 2 : Analyses des causes des défaillances ... 84

6.2.4. Etape 4 : Synthèse ... 85

6.3. Utilisation de la formalisation UML... 86

7. Bilan de la méthodologie et complément ... 87

8. Conclusion ... 88

Chapitre 4 : Vers une méthodologie ISBM ... 89

1. Introduction ... 89

2. Modèle d’information et ISBM ... 89

2.1. Ingénierie Système Basée sur les Modèles (ISBM) ... 89

2.2. Définition d’un modèle d’information ... 92

2.3. Intérêt d’un modèle d’information ... 92

2.3.1. Appuyer la gestion des exigences ... 92

2.3.2. Partager les connaissances ... 93

2.3.3. Supporter la conception ... 94

2.3.4. Synthèse ... 95

2.4. Travaux relatifs aux modèles d’information ... 96

2.4.1. MeMVaTEx ... 96

2.4.2. Modèle de données de l’AFIS ... 96

2.4.3. Modèle de MAP Système ... 98

2.4.4. DoDAF et MoDAF ... 99

2.4.5. Snow Card Volere ... 100

2.4.6. Travaux du CRAN ... 101

2.4.7. Travaux du LAAS-CNRS ... 102

2.4.8. Synthèse ... 102

(11)

Table des Matières

IX

3. Modèle proposé ... 103

3.1. Le langage choisi : SysML ... 104

3.1.1. Historique ... 104

3.1.2. Présentation ... 105

3.1.3. Stéréotype et block ... 106

3.1.4. Traçabilité avec SysML ... 107

3.1.5. Justification du choix de SysML ... 109

3.2. Extension proposée de SysML ... 109

3.2.1. Exigences enrichies ... 110

3.2.2. Nouveaux stéréotypes d’exigences ... 111

3.2.3. Stéréotype « risk » ... 112

3.3. Présentation du modèle d’information ... 114

4. Compléments au modèle ... 115

4.1. Utilisation d’OCL ... 115

4.2. Analyses et résultats issus du modèle de données ... 116

4.2.1. Matrices de traçabilité ... 116

4.2.2. Etats des exigences ... 116

5. Conclusion ... 117

Chapitre 5 : Exemple illustratif de l’avion S18 ... 119

1. Introduction ... 119

2. Présentation de l’exemple ... 119

2.1. Le système « avion S18 » ... 119

2.1.1. Les fonctions ... 119

2.1.2. Les sous-systèmes ... 120

2.2. Le système « freins des roues » ... 121

2.3. Le système « calculateur BSCU » ... 123

3. Application de la méthodologie de déclinaison d’exigences de Sûreté de

Fonctionnement ... 124

3.1. Niveau « avion S18 » ... 124

(12)

X

3.1.4. Etape 4 : Synthèse ... 129

3.2. Niveau « freins des roues » ... 129

3.2.4. Etape 4 : Synthèse ... 131

3.3. Niveau « calculateur BSCU » ... 132

3.3.4. Etape 4 : Synthèse ... 135

4. Modélisation SysML ... 137

4.1. Préparation du projet sous Tau-G2 ... 137

4.1.1. Extension de SysML ... 138

4.1.2. Organisation en packages ... 138

4.2. Niveau « avion S18 » ... 140

4.2.1. Package de la solution de conception ... 140

4.2.2. Package des exigences ... 141

4.2.3. Package de V&V : les cas de tests ... 145

4.3. Niveau « freins des roues » ... 145

4.3.1. Package de la solution de conception ... 146

4.3.2. Package des exigences ... 148

4.3.3. Package de V&V : les cas de tests ... 151

4.4. Niveau « calculateur BSCU » ... 152

5. Synthèse de l’étude de cas ... 152

6. Conclusion ... 153

Conclusion Générale ... 155

Bibliographie ... 159

Annexe A : Mots-clés associés au modèle de développement à

SdF explicite ... 171

(13)

Table des Matières

XI

1.1. Processus de création ... 171

1.2. Processus de prévention de fautes ... 171

1.3. Processus de tolérance aux fautes ... 172

1.4. Processus d’élimination des fautes ... 172

1.5. Processus de prévision des fautes ... 172

2. Conception ... 173

3. Réalisation ... 175

4. Intégration ... 175

Annexe B : Modélisation SysML du niveau « calculateur BSCU »

... 177

1. Package de la solution de conception ... 177

1.1. Fonctions du système ... 177

1.2. Structure du système ... 178

2. Package des exigences ... 178

2.1. Diagramme des exigences haut-niveau ... 178

2.2. Diagramme de déclinaison des exigences ... 179

2.3. Diagramme de satisfaction des exigences ... 181

2.4. Diagramme de vérification des exigences ... 182

(14)

(15)

Table des Figures

XIII

Table des Figures

Figure I.1 : Cycle de développement en V d’un système ... 10

Figure I.2 : Cycle de vie d'un produit ... 10

Figure I.3 : Vue globale de la conception d'un système ... 11

Figure I.4 : Démarche générale de conception... 12

Figure I.5 : L'Ingénierie Système fédératrice de domaines ... 12

Figure I.6 : Typologie des modèles en IS (AFIS) ... 13

Figure I.7 : Outils de gestion d’exigences (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 Sûreté de Fonctionnement ... 24

Figure I.12 : Relation faute-erreur-défaillance ... 26

Figure I.13 : Sûreté de fonctionnement et aspects contributeurs ... 34

Figure II.1 : Norme CEI-61508 et ses dérivées ... 38

Figure II.2 : Les processus de l’ARP-4754 ... 39

Figure II.3 : Proposition du projet ESACS ... 42

Figure II.4 : Modèle de développement à SdF explicite ... 44

Figure II.5 : Processus génériques de base relatifs à la SdF ... 48

Figure II.6 : Processus d'Ingénierie Système ... 50

Figure II.7 : Exemple de modélisation en processus ... 51

Figure II.8 : Couverture des normes IEEE-1220, EIA-632 et ISO-15288 ... 52

Figure II.9 : Approche Processus-Méthodes-Outils ... 53

Figure II.10 : Les processus de l'EIA-632 (traduction française) ... 54

Figure II.11 : Les 33 sous-processus de l'EIA-632 ... 55

Figure II.12 : Un bloc de construction (traduction française) ... 56

Figure II.13 : Exemple de décomposition d'un système avec l'EIA-632 ... 57

Figure II.14 : Relations entre exigences ... 57

Figure II.15 : Rôle des exigences spécifiées ... 58

Figure II.16 : Processus de conception système... 60

Figure II.17 : Processus de définition des exigences ... 60

Figure II.18 : Processus de définition de la solution ... 63

Figure II.19 : Processus d’évaluation technique ... 64

Figure III.1 : Evolution parallèle des processus de Définition des Exigences et de Définition de l’architecture ... 69

Figure III.2 : Evolution parallèle des processus de Définition des Exigences et de Définition de l’architecture ... 71

(16)

XIV

Figure III.4 : Exemple de structure d’un tableau d’AMDEC ... 74

Figure III.5 : Exemple de modes de défaillances génériques extrait de l’CEI-60812 ... 75

Figure III.6 : Diagramme d’Ishikawa avec les 5 M ... 75

Figure III.7 : Exemple d’Arbre de Défaillances ... 76

Figure III.8 : Les portes logiques ... 77

Figure III.9 : Les représentations des événements ... 77

Figure III.10 : Les symboles de transfert de sous-arbres ... 78

Figure III.11 : Formules pour le calcul des probabilités des fonctions OU et ET ... 78

Figure III.12 : Exemple d’arbre de défaillances ... 79

Figure III.13 : Formalisation de l’AMDEC en UML ... 81

Figure III.14 : Formalisation de l’arbre de défaillance en UML ... 82

Figure III.15 : Formalisation UML des concepts de la méthode AMDEC+AdD ... 82

Figure III.16 : Système ascenseur ... 83

Figure III.17 : AMDEC système « ascenseur » - fonction « transporter les usagers » ... 84

Figure III.18 : Arbre de défaillance de la cause système « chute de la cabine » ... 84

Figure III.19 : AMDEC « sous-système de contrôle du mouvement » ... 85

Figure III.20 : Synthèse de la déclinaison des exigences du système « ascenseur » ... 85

Figure III.21 : Diagramme d’objets de la formalisation UML pour l’exemple du système « ascenseur » ... 86

Figure IV.1 : Transition entre l’IS centrée sur les documents et l’IS centrée sur les modèles ... 90

Figure IV.2 : ISBM tout au long du cycle de développement ... 91

Figure IV.3 : Modèle du système au centre de l’I.S. ... 91

Figure IV.4 : Relation entre les exigences dans l’EIA-632 ... 93

Figure IV.5 : Le modèle d’information : un niveau d’interconnexion ... 94

Figure IV.6 : Répartition des domaines au cours de la modélisation ... 95

Figure IV.7 : Exigence MeMVaTEx ... 96

Figure IV.8 : Vue d’ingénierie de définition d’architecture système (AFIS) ... 97

Figure IV.9 : Extrait fiche n°3 AFIS : un modèle de données pour la description d’exigences ... 97

Figure IV.10 : Vue générale des processus IS - MAP Système ... 98

Figure IV.11 : Méta-modèle générique de l’Ingénierie Système de MAP Système ... 99

Figure IV.12 : Vue conceptuelle principale du Core Architecture Data Model 2.0 ... 100

Figure IV.13 : SnowCard Volere ... 101

Figure IV.14 : Modèle du système à faire de D. EVROT ... 102

Figure IV.15 : Séparation des concepts manipulés ... 103

Figure IV.16 : Historique de SysML ... 105

Figure IV.17 : Construction de SysML à partir d’UML 2 ... 105

Figure IV.18 : Les diagrammes de SysML ... 106

Figure IV.19 : Liens de traçabilité entre exigences et exigences ... 107

Figure IV.20 : Liens de traçabilité entre exigence et autres éléments de modèle ... 108

Figure IV.21 : Liens de traçabilité entre exigence et autres éléments de modèle ... 109

Figure IV.22 : Exigences SysML enrichies ... 111

Figure IV.23 : Champ maturité d’une exigence ... 111

Figure IV.24 : Nouveaux stéréotypes pour les exigences ... 112

(17)

Table des Figures

XV

Figure IV.26 : Le bloc « risk » ... 113

Figure IV.27 : Nouveau bloc « risk » lié aux exigences de sûreté de fonctionnement ... 114

Figure IV.28 : Modèle d’information SysML proposé ... 114

Figure IV.29 : Exemple de matrice de traçabilité pour la vérification des exigences ... 116

Figure V.1 : Sous-systèmes impliqués dans le freinage ... 120

Figure V.2 : Système de freins des roues ... 122

Figure V.3 : Système BSCU ... 124

Figure V.4 : AMDEC système « Avion S18 » pour la fonction de décélération au sol ... 126

Figure V.5 : Arbre de défaillance de la « perte non-annoncée de la capacité de décélération » ... 127

Figure V.6 : Arbre de défaillance de la « décélération involontaire après V1 » ... 127

Figure V.7 : AMDEC du sous-système « freins des roues » ... 128

Figure V.8 : Arbre de défaillance de la « perte non-annoncée de tous les freins des roues » ... 130

Figure V.9 : AMDEC du sous-système « calculateur BSCU » ... 131

Figure V.10 : Arbre de défaillance de « une défaillance du BSCU provoque la perte de la commande de freinage » (1/2) ... 132

Figure V.11 : Arbre de défaillance de « une défaillance du BSCU provoque la perte de la commande de freinage » (2/2) ... 133

Figure V.12 : Arbre de défaillance de « le BSCU commande le freinage en l’absence de données d’entrée et provoque un freinage involontaire » (1/3) ... 133

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 système ... 140

Figure V.19 : Avion S18 – Structure du système ... 141

Figure V.20 : Avion S18 – Diagramme des exigences haut-niveau ... 142

Figure V.21 : Avion S18 – Diagramme de déclinaison des exigences ... 143

Figure V.22 : Avion S18 – Diagramme de satisfaction des exigences ... 144

Figure V.23 : Avion S18 – Diagramme de vérification des exigences ... 145

Figure V.24 : Avion S18 – Cas de tests ... 145

Figure V.25 : Freins des roues – Fonctions du système ... 146

Figure V.26 : Freins des roues – Structure du système ... 147

Figure V.27 : Freins des roues – Structure du système (2) ... 147

Figure V.28 : Freins des roues – Diagramme des exigences haut-niveau ... 149

Figure V.29 : Freins des roues – Diagramme de déclinaison des exigences ... 150

Figure V.30 : Freins des roues – Diagramme de satisfaction des exigences... 151

Figure V.31 : Freins des roues – Diagramme de vérification des exigences ... 151

Figure V.32 : Freins des roues – Cas de tests ... 152

Figure V.33 : Synthèse d’une partie des déclinaisons ... 153

Figure B.1 : Calculateur BSCU – Fonctions du système ... 177

(18)

XVI

Figure B.3 : Calculateur BSCU – Diagramme des exigences haut-niveau ... 178 Figure B.4 : Calculateur BSCU – Diagramme de déclinaison des exigences (partie 1/2) ... 179 Figure B.5 : Calculateur BSCU – Diagramme de déclinaison des exigences (partie 2/2) ... 180 Figure B.6 : Calculateur BSCU – Diagramme de satisfaction des exigences ... 181 Figure B.7 : Calculateur BSCU – Diagramme de vérification des exigences ... 182 Figure B.8 : Calculateur BSCU – Cas de tests ... 183

(19)

Introduction Générale

1

Introduction Générale

L’intégration de diverses technologies, notamment celles de l’informatique et l’électronique, fait que les systèmes conçus de nos jours sont de plus en plus complexes. Ils ont des comportements plus élaborés et plus difficiles à prévoir, ont un nombre de constituants en interaction plus important et/ou réalisent des fonctions de plus haut niveau. Parallèlement à cette complexification des systèmes, la compétitivité du marché mondial impose aux développeurs de systèmes des contraintes de coût et de délais de plus en plus strictes. La même course s’opère concernant la qualité des systèmes, notamment lorsque ceux-ci mettent en jeu un risque de vies humaines ou un risque financier important. Ainsi, les développeurs sont contraints d’adopter une approche de conception rigoureuse pour répondre aux exigences du système souhaité et satisfaire les diverses contraintes (coût, délais, qualité, sûreté de fonctionnement,…). Pour prendre en compte ces contraintes, un cadre a été défini. Il s'agit de l'Ingénierie Système (IS) qui est une démarche méthodologique pour maîtriser la conception des systèmes et des produits complexes. Cette démarche est définie à travers différentes normes visant à guider la conception de système. La sûreté de fonctionnement, qui prend une place de plus en plus importante dans la conception des systèmes, doit être intégrée dans les processus d’ingénierie système. En effet, les propriétés de sûreté sont des propriétés émergentes. Elles résultent d’interdépendances qui existent dans le système et dans l’interaction de ce dernier avec son environnement. L’analyse de la sûreté de fonctionnement nécessite donc une démarche globale.

Le travail présenté dans ce mémoire a pour objectif la proposition d’une approche globale pour la prise en compte de la sûreté de fonctionnement. Il s’appuie sur la norme EIA-632, qui est largement employée, en particulier dans les domaines aéronautique et militaire. Il consiste à améliorer les processus d’ingénierie système décrits par l’EIA-632, afin d’intégrer une prise en compte globale et explicite de la sûreté de fonctionnement. En effet, jusqu’à présent la sûreté de fonctionnement était obtenue par la réutilisation de modèles génériques après avoir étudié et développé chaque fonction indépendamment. Il n’y avait donc pas de prise en compte spécifique des risques liés à l’intégration de plusieurs technologies. L’intégration de la sûreté de fonctionnement dans les processus de l’IS 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 l’IS est celui de l’ingénierie des exigences. Pour cette raison, nous proposons de nous intéresser aux exigences de sûreté de fonctionnement au niveau global et le plus tôt possible dans la phase de développement, pour ensuite les décliner aux niveaux inférieurs, ceci en s’appuyant sur les processus de la norme EIA-632

(20)

2

que nous étoffons. Nous proposons également une méthode originale de déclinaison d'exigences de sûreté de fonctionnement à base d'arbres de défaillances et d'AMDEC.

Pour une meilleure gestion de la complexité des systèmes, la tendance actuelle est d’utiliser des approches se basant sur l’Ingénierie Système Basée sur les Modèles (ISBM), qui propose de s’appuyer fortement sur les modèles, ceci pour toutes les étapes du cycle de développement. Ainsi, une autre facette du travail présenté propose un modèle d'information basé sur SysML pour appuyer notre approche.

Survol de la thèse

Ainsi, trois axes principaux se dégagent des travaux présentés dans ce mémoire de thèse. Ceux-ci concernent :

1. Une démarche d’Ingénierie Système intégrant la sûreté de fonctionnement, qui explicite au niveau processus d’ingénierie système comment prendre en compte les aspects « sûreté de fonctionnement » pour la conception.

2. Une méthodologie de déclinaison d’exigences de sûreté de fonctionnement, qui aide à la définition et la déclinaison d’exigences de sûreté niveau système en exigences de sûreté allouées aux sous-systèmes (à différents niveaux).

3. Un modèle d’information en SysML, qui permet de collecter toutes les informations produites lors de la conception, d’appuyer et de guider cette conception. La démarche d’Ingénierie Système intégrant la sûreté de fonctionnement

La démarche d’ingénierie système intégrant la sûreté de fonctionnement explique les activités à accomplir à chaque étape du travail de conception (définition des exigences, de la solution logique, de la solution physiques, etc.) pour concevoir un système sûr de fonctionnement. Le niveau de vision adopté ici est celui du processus. Nous ne considérons pas les méthodes, encore moins les outils. Cette vision processus n’impose pas de cycle de conception particulier (par exemples : cycle en V ou cycle en spirale). Néanmoins, les « allers-retours » entre définition des exigences et définition de la solution (logique et physique) semblent inévitables, d’autant plus que nous traitons des systèmes complexes. En fait, des choix de conception, des conflits entre exigences, voire même des difficultés techniques à satisfaire certaines exigences, ceci lors de la définition de la solution, amènent à définir de nouvelles exigences (ou modifier d’anciennes) et à les « réinjecter » dans la spécification. C’est particulièrement le cas pour un certain nombre d’exigences concernant les propriétés de sûreté de fonctionnement, qui ne peuvent être identifiées, définies et/ou déclinées complètement qu’une fois une architecture fonctionnelle décidée, ou bien un choix d’architecture physique fait.

La méthodologie de déclinaison d’exigences de sûreté de fonctionnement :

Notre démarche de conception sûre, qui s’attache donc à traiter les aspects de sûreté de fonctionnement d’un système, implique entre autres une traçabilité rigoureuse. Tout élément de la conception doit justifier sa présence par l’existence d’exigences lui correspondant. Cela signifie que la source de la conception est fondée sur l’ensemble des exigences dans notre démarche. Ainsi, rendre le système sûr de fonctionnement consiste

(21)

Introduction Générale

3

entre autres à être capable de définir les exigences de sûreté de fonctionnement, de les traiter, de les décliner, et de les allouer. La méthodologie de déclinaison d’exigences de sûreté de fonctionnement que nous proposons permet d’aider à cette définition d’exigences de sûreté, tout d’abord au niveau du système. Puis, elle permet la déclinaison nécessaire de ces exigences de sûreté au niveau plus bas : celui des sous-systèmes. La méthodologie combine à la fois des AMDEC niveau système, des Arbres de Défaillances (AdD), et des AMDEC niveau sous-systèmes. L’AMDEC niveau système nécessite la solution logique du système pour pouvoir être réalisée. Elle est à l’origine d’actions correctives qui conduiront à des exigences de Sûreté de Fonctionnement (SdF) de niveau système. Ces actions correctives s’attachent à réduire soit la probabilité d’apparition du mode de défaillance, soit la gravité des effets du mode de défaillance. Concernant les actions correctives qui s’intéressent à la probabilité, l’utilisation d’un AdD, une fois la solution physique disponible, et d’AMDEC sous-système permettent de décliner les exigences niveau système en exigences niveau sous-systèmes. Pour les actions correctives qui s’occupent de la gravité, le niveau de spécification est aussi le niveau système. L’utilisation d’arbres d’événements (Event Tree) peut faciliter l’identification ou la compréhension de ces actions correctives. Le modèle d’information en SysML

Nous souhaitons également appuyer la conception, avec sa génération de données d’ingénierie (exigences, solutions logique et physique), par un modèle d’information. Celui-ci permet de regrouper toutes les données de la conception au sein d’une base commune à tous les participants (ingénieurs système, ingénieurs de sûreté de fonctionnement, …). Bien entendu, doivent être inclus les différentes exigences, les fonctions identifiées, ainsi que les composants choisis, mais également un ensemble de liens entre ces éléments afin de rendre cohérent le modèle et d’expliquer l’utilité des diverses informations. Il s’agit là encore de l’aspect de traçabilité, très important pour une conception cohérente et sûre. Le langage bien adapté que nous avons choisi pour réaliser ce modèle est SysML (une extension d’UML à l’ingénierie système). Il permet de définir aussi bien les exigences, les fonctions et les composants, que les différents liens de traçabilité évoqués plus haut. L’intérêt d’un tel modèle d’information qui regroupe au sein d’un même modèle les aspects de spécification (les exigences) et de solution de conception (fonctions, composants et architectures associées) est qu’il permet une prise en compte rapide et efficace des évolutions des deux aspects en parallèle, définition des exigences et définition de la solution. La présence de ces deux aspects (exigences et solution) au sein du même modèle ne contrarie pas pour autant les recommandations des autorités de sûreté qui sont de ne pas mêler les exigences à la modélisation de la solution. En effet, SysML permet de clairement distinguer et séparer les deux aspects. Egalement pris en compte dans notre modèle, les « cas de tests » du langage SysML sont utilisés et liés aux exigences qu’ils vérifient. Devant être prévus dès l’étape de définition des exigences, ils permettent d’intégrer les aspects de vérification et validation dans le modèle.

Plan du manuscrit

Suite à cette introduction générale, le premier chapitre présente le cadre de travail qui est celui de l’ingénierie système. Il présente entre autres la gestion des exigences, la gestion des risques, ainsi que le domaine de la sûreté de fonctionnement. Ce chapitre finit par la

(22)

4

présentation de notre problématique, sur la base d’un constat fait sur les origines des problèmes de sûreté de fonctionnement des systèmes complexes.

Le deuxième chapitre du mémoire expose la démarche d’ingénierie système à base de processus qui prend en compte la sûreté de fonctionnement. Ce chapitre propose un état de l’art sur le sujet et présente les visions processus et normes d’ingénierie système. La norme EIA-632, sur laquelle nous nous appuyons, est présentée avant l’exposition de notre démarche processus proposée.

Le troisième chapitre concerne la méthodologie de déclinaison d’exigences de sûreté de fonctionnement. Le bien-fondé de cette méthodologie est justifié et celle-ci est également resituée dans les processus d’ingénierie système. Un état de l’art sur la déclinaison d’exigences de sûreté est développé, une formalisation UML est proposée et un cas d’étude simple illustre son application.

Le quatrième chapitre souhaite orienter la démarche de prise en compte de la sûreté de fonctionnement vers une démarche d’Ingénierie Système Basée sur les Modèles (ISBM). Le modèle d’information développé dans le cadre de ces travaux de thèse et basé sur le langage SysML sera exposé.

Le cinquième et dernier chapitre du mémoire présente un exemple issu du monde aéronautique qui sert d’illustration aux propositions des chapitres précédents. Il s’agit d’un avion de ligne fictif, sur lequel nous appliquons la méthodologie de déclinaison d’exigences de sûreté à différents niveaux et pour lequel nous fournissons une modélisation SysML utilisant notre modèle d’information.

Pour finir, une conclusion générale fait le bilan des contributions apportées, ceci par rapport à la problématique identifiée. Il s’agit également de présenter les perspectives des travaux afin de les améliorer et de les poursuivre.

(23)

Chapitre 1 Ingénierie des systèmes complexes et sûreté de fonctionnement

5

I. Chapitre 1 : Ingénierie des systèmes

complexes et sûreté de

fonctionnement

1. Introduction

Ce premier chapitre du mémoire introduit le cadre de travail : l’ingénierie système. Il correspond au domaine de recherche du groupe ISI (Ingénierie Système et Intégration) du LAAS-CNRS au sein duquel cette thèse a été réalisée. Spécifiquement, nous traitons des systèmes complexes, dont nous donnons notre propre définition. Nous discernons quelles sont les principales caractéristiques de ces systèmes, et expliquons en quoi cette complexité influe sur les activités de développement.

Un aspect important de la conception système sur lequel se focalise le travail de thèse est la sûreté de fonctionnement [Laprie, 2004]. Nous présentons cette notion et décrivons comment elle intervient dans l’ingénierie des systèmes complexes.

Ainsi, dans ce chapitre, après la définition de ce qu’est un système complexe et après avoir exposé ses principales caractéristiques, nous abordons la discipline de l’ingénierie système. Les notions de cycles de vie, cycles de développement et approche de conception sont ensuite exposées.

Parmi les différents processus de l’ingénierie système, nous faisons un focus sur la gestion des exigences et la gestion des risques, qui importent énormément pour notre problématique. Puis nous présentons la sûreté de fonctionnement, avec ses concepts, quelques-unes de ses méthodes et son enjeu. Pour finir, nous exposons un constat sur les origines des problèmes de sûreté de fonctionnement des systèmes complexes, appuyé par quelques exemples de systèmes qui ont défaillis. La problématique de notre travail qui s’appuie sur ce constat est présentée à la fin de ce premier chapitre.

2. Systèmes complexes

2.1. Définition d’un système

Depuis toujours, l’homme invente et conçoit des instruments, des matériels, des équipements, … pour améliorer ou faciliter sa vie. Ces fabrications ont un intérêt direct ou indirect pour l’homme en apportant un service. La motivation de toutes ces constructions vient des fonctions apportées par le système, qui se manifestent par des interactions entre le système lui-même et l’environnement. Concernant les premières réalisations de l’homme,

(24)

6

celles-ci étaient relativement simples. Ainsi, la « structure » interne de la conception était très facilement compréhensible. Mais malgré leur simplicité, ces éléments constituaient déjà les premiers « systèmes ». Puis, ils ont sans cesse évolué en devenant de plus en plus élaborés et compliqués, surtout depuis le début de l’ère industrielle. Cependant, quelque soit le système, une caractéristique demeure. En effet, ils font tous l’objet d’association d’éléments (constituants, composants, …) en interaction dans le but de faire émerger de nouvelles fonctionnalités qui permettent de rendre un ou plusieurs services attendus.

Ainsi, nous donnons dès à présent une définition d’un système, extraite du livre « Ingénierie et Intégration des systèmes » de Jean-Pierre MEINADIER [Meinadier, 1998], qui est la suivante :

Définition : Un système est un ensemble composite de personnels, de matériels et de

logiciels organisés pour que leur interfonctionnement permette, dans un environnement donné, de remplir les missions pour lesquelles il a été conçu.

Nous constatons alors que par une généralisation, l’homme peut lui-même faire partie d’un système, à la manière d’un « constituant ».

L’AFIS (Association Française d’Ingénierie Système) [AFIS] a également sa propre définition du système, dans laquelle l’intérêt des interactions est clairement exprimé :

Définition : Un système est décrit comme un ensemble d’éléments en interaction

entre eux et avec l’environnement, intégré pour rendre à son environnement les services correspondants à sa finalité. Un système présente donc des propriétés nouvelles résultant des interactions entre ses constituants : si l’on intègre des éléments pour faire un système, c’est bien pour bénéficier des effets de synergie résultant de leurs interactions.

Une autre définition d’un système donnée par l’INCOSE (International Council on

Systems Engineering) est la suivante :

Un système est un ensemble d’éléments interdépendants qui interagissent entre eux de façon organisée et forment un ensemble unique [INCOSE 2004].

Finalement, nous pouvons conclure que les interactions constituent l’essence même des systèmes. Grâce à elles, de nouvelles propriétés apparaissent, dépassant celles propres aux simples constituants.

2.2. Complexité

Alors que bon nombre d’ouvrages fournissent une définition claire du mot « système », il n’en va pas de même pour l’expression « système complexe », qui s’impose pourtant largement aujourd’hui [Magee & al., 2004].

En revenant à l’origine de l’adjectif « complexe », il apparait que ce mot nous provient du latin cum plexus, qui signifie qu’il y a beaucoup d’intrications, que « tout est lié ». Le lien avec les interactions et leur nombre est alors acquis. Mais est-ce nécessaire et/ou suffisant pour former un système complexe ?

(25)

7 En se référant au dictionnaire, nous trouvons :

Complexe, adjectif

Sens 1 : Qui comprend plusieurs éléments ayant de nombreux rapports entre eux. Synonyme : emmêlé. Anglais : complex.

Sens 2 : Difficile à appréhender, à analyser et en saisir le sens. Synonyme : difficile. Anglais : complex, complicated.

Le sens 1 de la définition ci-dessous reprend l’idée d’une interaction importante entre les constituants du système, mais ajoute à cela le fait que ces éléments sont un certain nombre. Le sens 2 fait supposer que le fonctionnement du système n’est pas compréhensible immédiatement, il est difficile à suivre et à étudier. S’ajoute donc une difficulté de compréhension et d’analyse.

Nous avons alors tenté de donner notre propre définition d’un « système complexe », en tenant compte de ce qui précède mais aussi d’autres écrits que nous avons pu rencontrer pendant nos recherches.

Système Complexe : Système capable de fournir des fonctions de haut niveau, dont le

comportement global est difficile à prévoir et dont la structure présente un graphe d’interaction non-trivial, souvent pourvu de boucles de rétroactions, et associant la plupart du temps plusieurs technologies de par l’implication de nombre de constituants.

La complexité de ces systèmes a forcé les concepteurs à adopter et à s’adapter à une méthode de développement bien plus organisée et rigoureuse [Bar-Yam, 2005]. La section 3 présente cette nouvelle façon d’aborder la conception, nécessaire pour maîtriser cette complexité grandissante : l’Ingénierie Système.

2.3. Propriétés émergentes

Un concept important qui a fait son apparition avec les systèmes complexes est celui de « propriétés émergentes » [Leveson, 2004], [Black & al., 2009]. Elles désignent les caractéristiques du système qui apparaissent du fait de la mise en interaction des constituants. En effet, ces propriétés émergentes ne peuvent pas être attribuées à des composants seuls. Elles sont basées sur le fait que l’ensemble fait plus que la somme de ses parties.

L’émergence est un domaine de recherche à part entière, que nous n’explorons pas ici. Seulement, comme annoncé en introduction, nous allons nous intéresser aux propriétés de sûreté de fonctionnement des systèmes complexes qui sont fortement liées à un caractère émergent.

3. Ingénierie Système

Après avoir revu les concepts de système et système complexe, nous nous intéressons à la conception de ces systèmes. Plus particulièrement, nous exposons le domaine qu’est l’Ingénierie Système, à travers son historique, sa définition et quelques concepts comme le cycle de vie d’un système ou le cycle de développement. Nous terminons la section par deux

(26)

8

aspects inclus dans l’ingénierie système sur lequel l’essentiel du travail va s’appuyer : l’ingénierie des exigences et la gestion des risques.

3.1. Historique et définition

L’Ingénierie Système a fait son apparition aux Etats-Unis dans les années 50 pendant les courses à l’espace et au développement de missiles équipés de tête nucléaire. Pour ces derniers, considérés comme une nécessité absolue pour la sécurité du pays, les services militaires et leurs sous-traitants civils subissaient une pression énorme pour développer, tester et mettre en service ces missiles nucléaires le plus rapidement possible, de même que pour mettre en orbite des satellites d’espionnage. Ils se sont donc attachés à trouver des outils et des techniques pour améliorer la performance du système, et surtout celle de la gestion du développement (en termes de performance technique, d’échéance calendaire ou encore de contrôle du coût). A partir de ce moment, le management de l’ingénierie a alors beaucoup évolué, en standardisant l’utilisation de spécifications, de documents d’interfaces, de revues de conception ou encore de gestion de configuration formelle. Les progrès du monde informatique ont, également, énormément contribué à l’expansion de l’Ingénierie Système, facilitant les travaux de gestion et d’enregistrement de documents et de configurations. Les outils informatiques ont aussi permis un net progrès grâce à la possibilité d’effectuer toutes sortes de simulation.

En France, il existe depuis 1999 une association regroupant des entreprises concernées par l’Ingénierie Système : l’Association Française d’Ingénierie Système [AFIS]. On y trouve entre autre des entreprises comme Airbus, Alcatel Space, Thales, Giat Industrie, Renault, PSA Peugeot Citroën, France Télécom, EDF, RATP, etc. Il existe aussi une association internationale d’Ingénierie Système, implantée aux Etats-Unis : l’International Council on Systems Engineering (INCOSE). L’AFIS est d’ailleurs affiliée à l’INCOSE en tant que « chapitre français de l’INCOSE ».

L’Ingénierie Système est donc le domaine qui va aider le concepteur et lui permettre de mener son développement de la meilleure manière possible. Cette nouvelle science est finalement le résultat d’un retour d’expérience de la part de grandes entreprises industrielles impliquées dans le développement de systèmes technologiques complexes. En fait, deux raisons principales sont à l’origine de cette science. La première provient d’échecs industriels et commerciaux, car ils ont grandement motivé l’introduction d’une méthode d’aide, d’assistance ou de gestion afin de les éviter. Ils vont d’ailleurs continuellement être analysés pour améliorer l’Ingénierie Système. La seconde vient du constat qu’une grande part des activités à mener pour les développements est un invariant vis-à-vis des projets et des secteurs d’application. Les problèmes à affronter sont en effet souvent de même nature :

 des besoins insuffisamment exprimés,

 des spécifications imprécises ou incomplètes,

 des solutions non justifiées ou non validées,

 une formation des utilisateurs insuffisante,

 des ressources et compétences mal planifiées,

(27)

9

Après ce rapide historique de l’avènement de l’Ingénierie Système, voyons la définition qu’en donne l’AFIS :

L’Ingénierie Système (ou ingénierie de systèmes) est une démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties prenantes.

Pour résumé, l’Ingénierie Système est donc une approche méthodologique qui a été développée et est en amélioration continue pour permettre au concepteur de système complexe d’aboutir à une solution équilibrée dans les meilleurs coûts et délais et répondant au mieux aux besoins des différentes entités concernées par l’utilisation du système (les clients, les agents de maintenance, d’autres systèmes,…).

3.2. Cycle de vie et cycle de développement

Lorsque l’on traite de l’Ingénierie Système, il est incontournable de considérer le cycle de développement du produit et son cycle de vie.

Le cycle de développement le plus connu, apparu d’abord 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 démarche de raffinements successifs qui répond à la phase de conception, partant du général (l’expression des besoins souvent à travers un Cahier des Charges Fonctionnel (CdCF)) pour déboucher sur le particulier. La branche ascendante, quant à elle, détaille les phases d’intégration et de validation du système.

La Figure I.1 ne donne qu’un exemple de cycle de développement en V, car le nombre d’étapes et les noms des phases changent souvent d’un ouvrage à l’autre. Mais le principe reste toujours le même. On constate ici qu’une première phase de spécification démarre avec le CdCF en donnée d’entrée, produit le référentiel des exigences, encore appelé spécification technique des besoins, et prévoit d’ores et déjà le plan de validation du système qui sera utilisé en phase finale. Ensuite, l’étape de conception démarre pour aboutir au dossier de conception, composé d’une spécification de l’architecture du système et des spécifications techniques des besoins des constituants, et du plan et tests d’intégration. Peut alors commencer le développement des différents constituants qui vont composer le système final. Cette étape de développement peut d’ailleurs être vue comme la juxtaposition de multiples sous-cycles en V qui peuvent se dérouler en parallèle, à hauteur d’un cycle par constituants à concevoir. Si le constituant n’est pas réalisable par un seul métier (ou génie), le sous-cycle associé reprend celui du système. Pour finir, se succèdent les étapes d’intégration du système, pendant lesquelles les constituants sont assemblés entre eux en suivant le plan d’intégration préalablement établi, et de validation du système, pour vérifier que le système répond bien aux besoins initiaux (le CdCF) et en utilisant le plan de validation.

(28)

10

Figure I.1 : Cycle de développement en V d’un système

Le piège de ce cycle en V est la linéarité apparente d’une succession séquentielle des opérations. Car il n’en est rien. En pratique, il y a de nombreuses rétroactions des phases aval vers les phases amont, suite à des découvertes tardives d’erreurs obligeant à remettre en question des phases préalablement validées ou suite à une demande de modification d’exigences ou une évolution du marché par exemple. C’est pourquoi d’autres cycles de développement existent, avec notamment le modèle incrémental, le modèle à versions successives ou encore le modèle en spirale [Boehm, 1986].

Mais le champ d’action de l’Ingénierie Système ne se limite pas à la seule étape du développement du produit. En effet, elle agit sur tout le cycle de vie du système, 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 générale de conception des systèmes

L’Ingénierie Système fournit donc une démarche méthodologique qui suit le produit tout au long de sa vie, depuis ses premières conceptualisations, jusqu’à son retrait définitif du service, en passant par les phases de développement et d’exploitation. Le paragraphe qui suit explique de manière générale comment et sous quelles contraintes est conçu un système.

(29)

11

Tout d’abord, un nombre important d’acteurs peut être impliqué dans la réalisation du produit. Cela induit déjà un premier besoin en termes d’organisation pour gérer au mieux les communications entre tous ces acteurs. On trouve évidemment le développeur en charge de la conception (aussi appelé concepteur ou maître d’œuvre) et le ou les clients (ou utilisateurs). Mais bien souvent, on a également affaire à un maître d’ouvrage (pour le compte duquel est réalisé le système), à des sous-traitants ou des fournisseurs. Tous ces acteurs, mis à part le développeur lui-même, vont constituer ce que l’on appelle des parties prenantes du système (voir Figure I.3).

Figure I.3 : Vue globale de la conception d'un système

Le concepteur est donc en premier lieu informé des besoins des utilisateurs, que ce soit par l’intermédiaire d’un maître d’ouvrage ou non. A cet ensemble, il doit adjoindre également ceux des autres parties prenantes. Tous ces besoins vont alors être étudiés et analysés, puis progressivement transformés en une spécification faite d’exigences fonctionnelles et non-fonctionnelles qui ne sont rien d’autre que des énoncés plus ou moins formels des besoins de l’ensemble des parties prenantes.

Peut alors démarrer la phase d’étude fonctionnelle du système en commençant par une analyse externe, pour ensuite procéder à une analyse interne qui consiste à décomposer les fonctions en sous-fonctions et débouche sur l’architecture fonctionnelle du système.

Puis, la conception du système proprement dit commence par l’approche organique, qui consiste à découper le système en autant de sous-systèmes que nécessaire et à faire des choix d’organes matériels ou de modules logiciels. On obtient alors l’architecture organique du système, qui peut être vue comme une solution logique (voir Figure I.4).

Pour finir, il reste l’approche physique qui consiste à faire des choix d’organes physique pour répondre à l’architecture organique préalablement établie. Il s’agit ici de produire ce que l’on nomme : architecture physique du système. L’ensemble composé de l’architecture organique et l’architecture physique réunies forme ce que l’on appelle la synthèse de la solution.

(30)

12

Figure I.4 : Démarche générale de conception

Lors du développement d’un système complexe, de nombreux domaines doivent travailler ensemble, coopérer et collaborer en vue d’obtenir une solution satisfaisante (voir Figure I.5). Nous distinguons 4 domaines principaux : le domaine du besoin, le domaine des génies, celui des spécialités et celui de la logistique. Typiquement, le domaine du besoin inclus le maître d’ouvrage et les multiples points de vue fournis par les manageurs, les opérateurs ou encore les utilisateurs. Le domaine des génies est certainement celui qui nous vient le plus rapidement à l’esprit lorsque nous pensons à la construction d’un système technique complexe, car il rassemble les différentes compétences : mécanique, thermique, électrique, logiciel, télécommunications, etc. Celui des spécialités dites transverses s’occupent de toutes les compétences interdisciplinaires, tel que la sûreté de fonctionnement, la sécurité ou encore l’ergonomie. Le dernier domaine à ne pas oublier est celui de la logistique. Il est absolument nécessaire si l’on souhaite respecter des délais ou encore une bonne qualité de service. Il traite notamment des aspects d’approvisionnement, de production, d’exploitation, de maintien en condition opérationnel ou de retrait du service.

(31)

13

L’Ingénierie Système a alors pour rôle de faire cohabiter toutes ces disciplines en les intégrant au sein d’un même ensemble de processus. La tâche n’est pas évidente, surtout lorsqu’il s’agit de faire communiquer tous les acteurs. Pour cela, il semble nécessaire de s’appuyer sur un langage commun. Le moyen le plus sûr et qui permet le moins d’ambigüité et de divergence de compréhension reste sans aucun doute l’utilisation et le partage de modèles [Estefan, 2008]. Le concept de modèle reste en fait indissolublement lié à celui de système, du fait de la complexité du système, de son hétérogénéité et de sa pluridisciplinarité, car l’esprit humain n’appréhende la complexité qu’en la modélisant. En effet, comprendre ou concevoir ne revient qu’à créer des modèles mentaux et agir ou réaliser n’est rien d’autre que de se conformer aux modèles que l’on a construits. On peut citer 3 types de modèles [Verries, 2010] que l’AFIS classifie en fonction du rôle qu’ils jouent dans la conduite des activités d’ingénierie système (voir Figure I.6) :

 les modèles cognitifs : pour l’analyse et l’exploration du problème ou du besoin à l’origine du système et pour la validation des concepts opérationnels.

 les modèles normatifs :

o de type prescriptif : pour la définition des exigences, la formalisation du besoin.

o de type constructifs : pour la définition des solutions apportées ou envisagées au niveau de la conception architecturale du système.

 les modèles prédictifs : pour prévoir, estimer et valider le comportement du système vis-à-vis de ses exigences, à l’aide de modèles formels ou de modèles analytiques selon les techniques utilisées.

Figure I.6 : Typologie des modèles en IS (AFIS)

3.4. Ingénierie des exigences

Un point de l’Ingénierie Système sur lequel se concentre une partie de notre travail concerne l’ingénierie des exigences. C’est une part de l’ingénierie système très importante, qui est en charge de s’occuper de toutes les activités liées aux exigences telles que leur définition, leur traçabilité, leur modification, leur gestion en terme de maturité, etc. Nous verrons plus tard en quoi elle est importante pour notre problématique concernant la conception de systèmes sûrs de fonctionnement.

(32)

14

La section qui vient s’attache donc à présenter les principaux concepts et intérêts de cette ingénierie des exigences et commence, en premier lieu, par la définition d’une exigence.

3.4.1. Définition d’une exigence

Une exigence correspond à une expression de besoin bien formulée émanant du client ou de toutes autres parties prenantes en lien avec le système à développer. Elle transmet un besoin en fonctionnalité (exigence fonctionnelle) ou en qualité (exigence non-fonctionnelle) que doit satisfaire le produit qui est en train d’être conçu. Concernant les exigences non-fonctionnelles, celles-ci peuvent représenter :

 des contraintes globales de qualité de service,

 des aptitudes du système (fiabilité, opérabilité, convivialité, …),

 des contraintes opérationnelles (conformité à des normes d’utilisation),

 des contraintes de conception (réutilisation d’existant).

L’intérêt principal de transcrire les besoins en exigences réside dans la non-ambiguïté qui doit en découler à travers leurs formulations. De plus, cela apporte un bon support de communication entre les différentes parties prenantes du projet qui doivent collaborer.

3.4.2. Rôle et intérêt de l’ingénierie des exigences

Gérer les exigences [Buren & al., 1998] dans un projet est une activité fondamentale à son bon déroulement. En effet, un nombre important de documents peut être produit lors de la conception d’un système. Sans l’ingénierie des exigences, il serait quasiment impossible de garantir la cohérence et la qualité nécessaire au succès du projet. Effectivement, des études statistiques ont montré que les exigences interviennent pour environ 40% des succès ou échecs d’un projet, d’où leur importance vis-à-vis de notre préoccupation.

Ainsi, l’ingénierie des exigences permet de [Sommerville & al., 1997] :

 collecter les exigences,

 faciliter leur expression,

 détecter les incohérences entres elles,

 les valider,

 gérer leur priorité (les hiérarchiser),

 gérer les changements d’exigences,

 gérer la qualité,

 faire le lien avec le reste du projet et/ou avec le contexte,

 et encore assurer leur traçabilité.

L’ingénierie des exigences doit aussi veiller à ce que chaque exigence soit correctement déclinée, allouée, suivie, satisfaite, vérifiable, vérifiée et justifiée.

Nous saisissons bien l’importance de l’ingénierie des exigences dans un projet, pour sa réussite, et donc pour garantir que le système conçu répondra bien aux besoins et fonctionnera comme prévu. Tout écart vis-à-vis du respect des exigences pourra être à l’origine d’un fonctionnement non-souhaité, d’où le lien avec notre problématique. En

(33)

15

particulier, nous avons constaté l’importance des exigences liées aux interfaces, qui sont encore trop souvent la cause de problèmes de conception, et donc de retards et de surcoûts.

Ci-après, nous allons faire un focus sur trois aspects majeurs de l’ingénierie des exigences : l’expression des exigences, la traçabilité et le changement d’exigences.

3.4.3. Expression des exigences

Une bonne expression des exigences constitue un point clé de la réussite d’un projet. Toute ambiguïté ou tout oubli à ce niveau sera source de complication ultérieure, pouvant bien entendu s’en suivre de retard, de surcoût, de pénalité, etc. Il faut veiller à ce que les interprétations que peuvent se faire les différentes parties prenantes soient les mêmes. Pour cela, il convient d’utiliser des termes simples et d’éviter ceux ambigus ou vagues. Il est aussi recommandé de joindre schémas ou modèles normalisés qui peuvent éclairer l’exigence dès que cela est possible. (Nous rappelons ici l’adage bien connu : « un bon schéma vaut mieux qu’un long discours ».)

Outre la formulation même du « besoin » exprimé à travers l’exigence, à celle-ci peut également être associée d’autres attributs comme : le type (primaire ou dérivée), le niveau de conformité (obligatoire, conseil ou information), la priorité, la portée (exigence sur le système lui-même ou le programme) ou encore l’état (vérifiée, validée, …). Toutes ces informations ont leurs importances et doivent être tenues à jour.

3.4.4. Traçabilité

La traçabilité des exigences [Ramesh & al., 2001] est sans doute le concept le plus important dans l’ingénierie des exigences. Elle permet de connaitre facilement l’origine des exigences, ainsi que tous les liens entre les exigences elles-mêmes ou entre les exigences et le reste du projet ou le contexte (besoins utilisateur, réalisation, tests, …).

Dans la littérature [Ramesh, 1998], la traçabilité est citée comme facteur de qualité d’une bonne conception. Tout d’abord dans le but de décrire les connexions entre les différents niveaux d’exigences, elle présente un ensemble d’avantages qui permettent :

 de montrer plus facilement que la conception satisfait les exigences et d’aider à identifier rapidement quelles exigences ne sont pas satisfaites par la solution (autrement dit : de vérifier/valider la solution proposée),

 de ne perdre aucune justification vis-à-vis de choix de conception,

 de faciliter et maîtriser l’évolution du système dans le futur,

 de comprendre l’impact d’un changement d’exigence et de faciliter la prise en compte de l’évolution.

3.4.5. Changement d’exigences

Le changement d’exigences fait partie intégrante de l’ingénierie des exigences. Il est alors nécessaire de garantir une traçabilité, comme nous venons de l’expliquer ci-dessus. Mal suivi, le changement d’exigences a souvent été source de graves problèmes de conception. Ceux-ci entraînent des retards et des surcoûts néfastes à la survie de

(34)

16

l’entreprise, voire même des dysfonctionnements important du système portant atteintes à la sécurité de biens et/ou de personnes.

Une bonne ingénierie des exigences, avec une traçabilité complète où toutes les informations nécessaires sont présentes, doit permettre d’analyser et de prendre en compte l’impact de changements d’exigences. Changements qui deviennent d’ailleurs de plus en plus inévitables, d’une part, dû à la complexité des systèmes qui impose de faire des hypothèses initiales à revoir et ajuster plus tard dans le développement, d’autre part, dû à l’arrivée de nouvelles technologies ou plus simplement à cause de la rapidité de l’évolution du marché actuel.

Un autre aspect important qui complique encore la tâche d’ingénierie des exigences provient du fait que plusieurs parties prenantes et les différents acteurs de la conception interviennent pour définir et traiter les exigences. Derrière cette idée, il y a la notion d’un travail collaboratif, et donc d’une gestion collaborative des exigences. Ceci fait l’objet de nombreux travaux et constitue un domaine de recherche à part entière. Pour plus d’information, le lecteur peut par exemple se référer à [Konate, 2009] ou [Coulin, 2007].

3.4.6. Quelques outils d’ingénierie des exigences

Pour finir cette partie sur l’ingénierie des exigences, nous donnons quelques exemples d’outils d’ingénierie des exigences utilisés dans le monde industriel.

Le plus connu est incontestablement l’application DOORS d’IBM. C’est en effet le leader de ce marché, utilisé par les plus grandes entreprises dans tous les domaines (avionique, spatial, médical, défense, …). DOORS permet une structuration des exigences, en associant autant de champs que désiré à la définition des exigences. Il permet aussi de gérer des liens de traçabilité entre les exigences, dont la sémantique est à définir par l’utilisateur. En résumé, DOORS fournit un environnement complet et collaboratif de gestion des exigences.

Mais il existe en fait de très nombreux autres outils qui permettent de faire de la gestion des exigences, ayant chacun leurs avantages ou leurs inconvénients, en étant plus adapté à certains domaines qu’à d’autres. L’INCOSE propose d’ailleurs une liste (non-exhaustive) de ces outils, reprise en Figure I.7 (cf. http://www.incose.org/ProductsPubs/ products/rmsurvey.aspx).

OUTIL NOM DU VENDEUR

Accept Requirements (Accept 360) Accept Software

Acclaro DFSS Version 5 Axiomatic Design Solutions, Inc. Aligned Elements Version 1.5 (AE 1.5) Aligned AG

Avenqo PEP Version 1.2 Avenqo

Blueprint Requirements Center 2010 Blueprint Software Systems, Inc. Cameo Requirements+ Version 4.0 No Magic Inc.

CASE Spec Version 8.15 Goda Software Cognition Cockpit (Cockpit) Version 5.1 Cognition Corporation Contour by Jama Software (Contour) Version 2.9 Jama Software CORE Version 5.1.5 Vitech Corporation Cradle Version 5.7 3SL, Inc.

Dimensions RM (DimRM) Version 10.1.4 Serena Software Enterprise Architect Version 7.1 Sparx Systems