Technique d’analyse du risque HAZOP
La méthode HAZOP, pour HAZard OPerability, a été développée par la société Imperial Chemical Industries (ICI) au début des années 1970. Elle a depuis été adaptée dans différents secteurs d’activité. Considérant de manière systématique les dérives des paramètres d’une installation en vue d’en identifier les causes et les conséquences, cette méthode est utilisée pour l’examen de systèmes thermo-hydrauliques pour lesquels des paramètres comme le débit, la température, la pression, le niveau, la concentration sont particulièrement importants pour la sécurité de l’installation. Elle a fait l’objet d’une norme IEC61882 (2001) et est largement utilisée aujourd’hui. Son succès tient à sa simplicité et à la possibilité de réaliser des HAZOP très tôt dans le processus de développement. Elle a également comme avantage d’être adaptable au formalisme utilisé pour décrire un système.
HAZOP ne considère pas des modes de défaillances comme l’AMDEC mais les dérives potentielles (ou déviations) des principaux paramètres liés à l’exploitation de l’installation. Pour chaque partie constitutive du système examiné, la génération (conceptuelle) des déviations est effectuée de manière systématique par la conjonction :
de mots-guides comme par exemple PAS DE ; PLUS DE ; MOINS DE ; TROP DE , des paramètres associés au système étudié comme par exemple dans le cas d’un procédé industriel : la température, la pression, le débit, etc. mais également le temps ou des opérations à effectuer.
Argumentaire de sécurité
Suite à de nombreux accidents industriels parmi lesquels l’incendie nucléaire à Wind-scale en 1957, l’explosion chimique à Flixborough en 1974, l’explosion suivie par un incendie de la plateforme pétrolière Piper Alpha en 1988 ont poussé le gouvernement britannique à obliger les futurs exploitants à présenter des rapports démontrant la sécurité de l’installation et les opérations qui y sont pratiquées. Cette procédure est l’un des premiers exemples d’un dossier de sécurité. Cependant, il n’existait pas de consigne claire et précise pour analyser ou construire un tel dossier de sécurité. Ce manque de clarté a été la motivation de nombreuses recherches portant sur la construction d’un argumentaire de sécurité que l’on peut aussi bien appliquer à une installation ou à un système. On peut notamment citer les travaux menés dans le cadre de la thèse de Kelly (1998). Le concept a vite prouvé son intérêt aux yeux du gouvernement britannique et son Ministère de la Défense a rendu obligatoire en 2004 dans la norme DefStan 00-56 (2004) la présence d’un document nommé Safety case ou « Dossier de sécurité » (aussi appelé « Cas de sécurité ») pour toute acquisition d’un système de caractère critique. Ce standard définit le Dossier de Sécurité comme (traduction libre) «un document structuré comprenant des éléments de preuve qui présente un argument convaincant, compréhensible et valide prouvant que le système est sûr pour une utilisation prévue dans un environnement prédéfini» .
La notion d’argumentaire de sécurité a été introduite pour guider l’élaboration de ce dossier et s’est appuyé sur les travaux de Toulmin (1958), qui a défini les 6 éléments d’un argument solide et réaliste : La revendication (claim) : qui correspond à l’affirmation de ce que l’on estime vrai. Les données (data ou ground) : qui constituent les éléments de preuve qui fondent la revendication. Les garanties (warrant) : qui explicitent les principes du raisonnement qui fait le lien entre les données et la revendication.
Les fondements (backing) : qui constituent la structure profonde du raisonnement et de l’argumentaire. Les restrictions (rebuttal) : qui signalent les exceptions éventuelles. Les modalités (qualifier) : qui précisent les conditions particulières à respecter pour que la revendication soit vraie.
Langage de modélisation unifié UML
UML (en anglais Unified Modeling Language ou Langage de Modélisation Unifié) est un langage de modélisation graphique. Il est apparu dans le monde du génie logiciel, dans le cadre de la « conception orientée objet ». Couramment utilisé dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine informatique. Sur le site de l’OMG (OMG, Consulté le 13 mars 2010), UML2 propose treize types de diagrammes . UML n’étant pas une méthode, le choix de diagrammes à utiliser est laissé libre aux utilisateurs. De même, on peut se contenter de modéliser partiellement un système, par exemple certaines parties critiques. Les 13 diagrammes UML sont dépendants hiérarchiquement et se complètent, de façon à permettre la modélisation d’un projet tout au long de son cycle de vie. Ils peuvent être rassemblés selon deux catégories : les diagrammes structurels et les diagrammes comportementaux. Il existe six diagrammes structurels : Le diagramme de classes représente les classes intervenant dans le système. Le diagramme d’objets sert à représenter les instances de classes (objets) utilisées dans le système.
Le diagramme de composants il permet de montrer les composants du système d’un point de vue physique, tels qu’ils sont mis en œuvre (fichiers, bibliothèques, bases de données…). Le diagramme de déploiement sert à représenter les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage…) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent entre eux.
Le diagramme de paquetages un paquetage étant un conteneur logique permettant de regrouper et d’organiser les éléments dans le modèle UML, le diagramme de paquetages sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles de définitions. Le diagramme de structures composites permet de décrire sous forme de boîte blanche les relations entre composants d’une classe.
Étude de la sensibilité de la confiance
Une étude de sensibilité a été réalisée sur le nœud G1 (« Le robot MIRAS est au moins aussi sûr qu’un déambulateur classique »). Pour chaque nœud est affiché en premier l’incertitude puis la confiance. Par exemple, la confiance de G1 est de 73,12%. Tous les nœuds n’ont pas été agrandi par souci de visibilité. Dans ce réseau de confiance, nous retrouvons l’interconnexion des éléments servant à supporter différents nœuds à la fois :
Le nœud G9 supporte à la fois les nœuds G1-2 et G4-1 de la confiance dans l’argumentaire (seules les 10 nœuds feuilles les plus influents sont représentés).
Les éléments de preuve Sn31 (« Test et avis des patients/Conception du robot » ) et Sn32 («Application de la norme Rollators ISO 11999-2») supportent simultanément le nœud G10 (« Le robot n’induit pas la chute naturelle de façon plus élevé » ) et le nœud G3 (« Le robot n’a pas de mouvement susceptible de stresser le patient » ).
Le nœud G8 (« Les risques d’avoir une posture incorrecte (HN1b), de chuter (HN4) et d’avoir des problèmes physiologiques (HN5) sans alarme sont traités par un système de détection qui déclenche l’alarme et l’arrêt du robot) ») supporte à la fois G11 (« Le risque de ne pas passer en mode sûr » ) et G1-2 (« Les risques induits par l’utilisation d’un déambulateur classique sont réduits ou constants » ).
L’élément de preuve Sn45 (« Tests démontrant que l’arrêt temporaire n’induit pas de dangers » ) supporte à la fois G8-6 (« La détection d’un problème entraîne toujours le déclenchement de l’alarme et l’arrêt temporaire du robot ») et G2-1-2 (« La commande d’arrêt est obligatoire suite à une détection d’obstacle ».
Table des matières
Introduction générale
1 Maîtrise de la confiance en robotique de service
1.1 Introduction
1.2 Gestion du risque
1.3 Technique d’analyse du risque HAZOP
1.4 Analyse quantitative : les réseaux bayésiens
1.5 Analyse quantitative : fonction de croyance
1.6 Argumentaire de sécurité
1.7 Vue générale des contributions de la thèse
2 Analyse du risque basée modèle
2.1 Introduction
2.2 Utilisation des modèles dans l’analyse du risque
2.3 Langage de modélisation unifié UML
2.3.1 Diagramme des cas d’utilisation
2.3.2 Diagramme de séquence
2.3.3 Diagramme d’états-transitions
2.4 Méthode d’analyse du risque HAZOP-UML
2.4.1 Introduction
2.4.2 Mots-guide appliqués au diagramme des cas d’utilisation
2.4.3 Mots-guide appliqués au diagramme de séquence
2.4.4 Mots-guide appliqués au diagramme d’états-transitions
2.4.5 Documents produits par HAZOP-UML
2.5 Conclusion
3 Confiance dans un argumentaire de sécurité
3.1 Introduction
3.2 Approches existantes pour l’évaluation de la confiance dans un argumentaire
3.2.1 Approches qualitatives
3.2.2 Approche quantitative : probabilité Baconienne
3.2.3 Approche quantitative : réseaux Bayésiens
3.2.4 Approche quantitative : théorie de Dempster-Shafer
3.3 Vers une nouvelle approche d’évaluation de la confiance d’un argumentaire
3.3.1 Approche générale
3.3.2 Mesure de confiance
3.3.3 Types d’argument
3.3.4 Argumentation simple
3.3.5 Argumentation alternative
3.3.6 Argumentation complémentaire
3.3.7 Argumentation mixte
3.3.8 Étude de sensibilité
3.4 Conclusion
4 Application à un robot d’aide à la déambulation
4.1 Présentation générale du projet MIRAS
4.2 Vue générale du travail réalisé
4.3 Les fonctionnalités du robot d’aide à la déambulation
4.4 Analyse et évaluation des risques
4.4.1 Application d’HAZOP-UML
4.4.2 Validation de l’approche HAZOP-UML
4.4.3 Critères de risque
4.4.4 Estimation et évaluation du risque pour la version évaluation clinique
4.4.5 Estimation et évaluation du risque pour la version finale
4.5 Argumentaire de sécurité du robot
4.6 La confiance dans l’argumentaire de sécurité
4.6.1 Construction du réseau de confiance
4.6.2 Choix de l’outil AgenaRisk
4.6.3 Étude de la sensibilité de la confiance
4.7 Conclusion
Synthèse, contributions majeures et perspectives
A Modèle GSN de MIRAS
Bibliographie
