No dordre : 695

THSE
prsente
LI NSTITUT

NATIONAL DES S CIENCES A PPLIQUES DE T OULOUSE pour lobtention du titre de DOCTEUR

de lInstitut National des Sciences Appliques de Toulouse Spcialit : Informatique par

Jrmie GUIOCHET

L ABORATOIRE D TUDE DES S YSTMES I NFORMATIQUES ET AUTOMATIQUES cole Doctorale Systmes Titre de la thse :

M ATRISE DE LA SCURIT DES SYSTMES DE

LA ROBOTIQUE DE SERVICE

A PPROCHE UML BASE SUR UNE

ANALYSE DU RISQUE SYSTME
Soutenue le 9 juillet 2003, devant le jury : Prsident : Rapporteurs : Examinateurs : M. Daniel ESTEVE M. Franck BARBIER Mme Jocelyne TROCCAZ Mme Claude BARON M. Gilles MOTET M. Bertrand TONDU M. Bernard COULETTE Directeur de Recherche CNRS, LAAS Professeur, Universit de Pau Directeur de recherche CNRS, TIMC/IMAG Matre de confrence, INSA Toulouse Professeur, INSA Toulouse Professeur, INSA Toulouse Professeur, Universit Toulouse le Mirail

Membre invit :

 Qui ne risque rien na rien

Dicton populaire

Avant-propos
Le travail prsent dans ce manuscrit rsulte de nombreux changes avec des personnes de diffrents horizons. Sans leur aide, et la richesse de leurs expriences ce travail naurait pu tre ralis. Pour avoir accept de participer et de prsider au jury de thse, je tiens remercier M. Daniel Esteve. Jai particulirement apprci le climat des changes quil a su crer la soutenance ainsi que son recul et son analyse sur lensemble de disciplines prsentes dans ce mmoire. Je remercie M. Franck Barbier et Mme Jocelyne Troccaz pour lintrt quils ont port ma thse en acceptant dtre rapporteurs. Leurs remarques ont permis de donner plus de cohrence de nombreux aspects de ce mmoire. Je remercie plus particulirement Mme Jocelyne Troccaz pour laccueil qui ma t fait au sein de TIMC/IMAG lors de ma collaboration avec Mme Adriana Vilchis sur le projet TER. Je tiens remercier tout particulirement M. Gilles Motet, directeur du LESIA, pour avoir accept dtre membre du jury ainsi que pour son accueil au sein du laboratoire. Jai fortement apprci sa disponibilit, son coute et la richesse des changes que nous avons eus. Je remercie vivement Mme Claude Baron et M. Bertrand Tondu, mes directeurs de recherche, pour mavoir fait conance notamment lors de lexploration de thmes diffrents de la sret de fonctionnement ou de la robotique. Jadresse mes remerciements M. Bernard Coulette pour avoir accept dtre membre de mon jury. Je le remercie plus particulirement ainsi que mes collgues de lUTM pour laccueil quils mont rserv dans leur universit et au sein de GRIMM/ISYCOM. Leur comprhension a permis damnager mes enseignements en tant quATER pour maider nir mon mmoire dans de bonnes conditions. Je remercie galement les collgues du DGEI pour la qualit des changes professionnels ou personnels. Je remercie plus particulirement M. Serge Ippolito pour son dynamisme et ses remarques claires sur les muscles articiels. Je remercie galement M. Pascal Acco pour son aide en automatique et pour la bonne ambiance de bureau. Enn, et malgr les conventions, peut tre ceux quil faudrait mettre en premiers, ceux qui mont soutenu dans la vraie vie et mont fait avancer pendant ces annes : la famille, les amis, et par dessus tout Audrey et Lou.

Table des matires

Introduction gnrale 1 Scurit des systmes de la robotique de service 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Effets non dsirs : les dommages . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Dommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1.1 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1.2 Gravit dun dommage . . . . . . . . . . . . . . . . . . . 1.2.1.3 Occurrence dun dommage . . . . . . . . . . . . . . . . . 1.2.2 Notion de Risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.1 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2.2 Mesure du risque . . . . . . . . . . . . . . . . . . . . . . 1.2.2.3 Risque acceptable . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Causes : les dangers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Notion de danger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Phnomne dangereux et situation dangereuse . . . . . . . . . . . . . 1.3.3 vnement dommageable . . . . . . . . . . . . . . . . . . . . . . . 1.3.4 Incident et accident . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.5 Exemple dutilisation des notions lies au risque . . . . . . . . . . . 1.3.6 Analyse du danger . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Moyens : la gestion du risque . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Vue densemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Facteurs humains et gestion du risque pour des systmes de la robotique mdicale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 Analyse du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3.1 Analyse du risque et processus de dveloppement . . . . . 1.4.3.2 Dnition du systme et de lutilisation prvue . . . . . . . 1.4.3.3 Identication des phnomnes dangereux . . . . . . . . . . 1.4.3.4 Estimation du risque . . . . . . . . . . . . . . . . . . . . . 1.4.4 valuation du risque . . . . . . . . . . . . . . . . . . . . . . . . . . 17 21 21 22 23 23 23 24 25 25 25 26 27 28 28 28 29 29 30 31 31 31 32 34 34 34 35 36 37

TABLE DES MATIRES 1.4.5 Matrise du risque . . . . . . . . . . . . . . . . . . . . . . Techniques utilises pour lanalyse du risque . . . . . . . . . . . . Techniques utilises pour la matrise du risque . . . . . . . . . . . . 1.6.1 Conception matrielle . . . . . . . . . . . . . . . . . . . . 1.6.1.1 Architectures mcaniques et matriaux utiliss . . 1.6.1.2 Scurit autour des actionneurs . . . . . . . . . . 1.6.1.3 Scurit par la redondance des composants . . . . 1.6.1.4 Scurit par la dtection de contacts avec lhumain 1.6.2 Conception logicielle . . . . . . . . . . . . . . . . . . . . . 1.6.2.1 Limitations logicielles des performances du robot 1.6.2.2 Scurit lors de la mise sous tension . . . . . . . 1.6.2.3 Surveillance du systme . . . . . . . . . . . . . . 1.6.2.4 Conception des interfaces humain-machine . . . . Assurance : la certication . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Certication et risque . . . . . . . . . . . . . . . . . . . . . 1.7.2 Classication des dispositifs mdicaux . . . . . . . . . . . 1.7.3 Processus de certication . . . . . . . . . . . . . . . . . . . Conclusion et problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 41 43 44 44 45 47 48 49 49 50 50 51 52 53 53 54 55 57 57 59 59 59 60 61 61 62 63 63 65 66 71 72 72 74 76 77 77 77

1.5 1.6

1.7

1.8 2

Risques lis lutilisation des muscles articiels de McKibben 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Description du muscle articiel . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1.1 Fabrication du muscle . . . . . . . . . . . . . . . . . . 2.2.1.2 Utilisation du muscle . . . . . . . . . . . . . . . . . . 2.2.2 valuations des efforts en statique et dynamique . . . . . . . . . 2.2.2.1 Force statique . . . . . . . . . . . . . . . . . . . . . . 2.2.2.2 Force dynamique . . . . . . . . . . . . . . . . . . . . 2.2.3 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Actionnement dune articulation . . . . . . . . . . . . . . . . . . 2.2.5 Contrle des muscles articiels . . . . . . . . . . . . . . . . . . 2.2.6 Validation sur un bras sept axes anthropomorphe . . . . . . . . . 2.3 Identication des dangers et estimation du risque . . . . . . . . . . . . . 2.3.1 Phnomnes dangereux de type dfaillances . . . . . . . . . . . . 2.3.1.1 Dfaillances de la tresse et de son systme de maintien 2.3.1.2 Dfaillance du tube de caoutchouc . . . . . . . . . . . 2.3.2 Situations dangereuses . . . . . . . . . . . . . . . . . . . . . . . 2.4 Solutions possibles pour la matrise du risque . . . . . . . . . . . . . . . 2.4.1 Moyens de prvention . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Moyens de protection . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES 2.5 Synthse et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 78 81 81 82 82 82 83 83 84 84 84 85 86 87 88 88 89 90 92 93 95 95 96 96 99 99 100 101 102 103 105 106 106 107 108 109

3 La modlisation oriente objet avec UML 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 UML : notation pour le dveloppement orient objet . . . . . . . . . . . . . 3.2.1 Le paradigme objet . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 La complexit des systmes . . . . . . . . . . . . . . . . . 3.2.1.2 La notion dobjet . . . . . . . . . . . . . . . . . . . . . . 3.2.1.3 Les classes dobjet . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Le langage de modlisation UML . . . . . . . . . . . . . . . . . . . 3.2.2.1 Pourquoi modliser ? . . . . . . . . . . . . . . . . . . . . 3.2.2.2 Bref historique de UML . . . . . . . . . . . . . . . . . . . 3.2.2.3 Les diagrammes UML . . . . . . . . . . . . . . . . . . . . 3.2.2.4 Le mtamodle . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Processus de dveloppement et UML . . . . . . . . . . . . . . . . . 3.2.3.1 Pilot par les cas dutilisation . . . . . . . . . . . . . . . . 3.2.3.2 Itratif et incrmental . . . . . . . . . . . . . . . . . . . . 3.2.3.3 Centr sur larchitecture . . . . . . . . . . . . . . . . . . . 3.3 Travaux actuels sur le dveloppement orient objet et la sret de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Prvention des fautes . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Prvision des fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Tolrance aux fautes . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 limination des fautes . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Conclusions sur la sret de fonctionnement et le dveloppement orient objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Intgration dUML pour lanalyse du risque 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Description du systme et de son utilisation . . . . . . . . . . . . . . . 4.2.1 Modlisation du mtier . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Intgration du dispositif technologique dans la tche de service . 4.2.3 Dnition des frontires du systme . . . . . . . . . . . . . . . 4.2.4 Description des tches des acteurs . . . . . . . . . . . . . . . . 4.3 Analyse des dangers et estimation du risque . . . . . . . . . . . . . . . 4.3.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Analyse prliminaire des dangers . . . . . . . . . . . . . . . . 4.3.3 Analyse des modes de dfaillance . . . . . . . . . . . . . . . . 4.3.3.1 Analyse des modes de dfaillance des messages . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

10 4.3.3.2 4.3.3.3

TABLE DES MATIRES Modles derreur des messages . . . . . . . . . . . . . . . Proposition de tableau gnrique de lAMDEC pour une analyse systme . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Application aux diffrents domaines . . . . . . . . . . . . . . . . . . 4.3.4.1 Analyse des modes de dfaillance des messages provenant des acteurs de type dispositif extrieur . . . . . . . . . . . 4.3.4.2 Analyse des modes de dfaillance des messages provenant des acteurs humains . . . . . . . . . . . . . . . . . . . . . 4.3.4.3 Analyse des modes de dfaillance des composants lectroniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4.4 Analyse des modes de dfaillance des composants mcaniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4.5 Analyse des modes de dfaillance du logiciel . . . . . . . . 4.3.5 Analyse des arbres de fautes . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 114 116 117 119 121 125 127 130 132

4.4 5

Application de lanalyse du risque au dveloppement en UML dun robot tlchographe 137 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.2 Prsentation du projet TER . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 5.3 Dnition du systme et de son utilisation . . . . . . . . . . . . . . . . . . . 139 5.3.1 Modlisation du mtier : lexamen chographique . . . . . . . . . . . 139 5.3.2 Systme robotis pour la tl-chographie et allocation des tches . . 143 5.3.3 Dnition des frontires de lanalyse . . . . . . . . . . . . . . . . . 146 5.3.4 Analyse des tches . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 5.3.4.1 Cas dutilisation Raliser tche . . . . . . . . . . . . . . . 148 5.3.4.2 Cas dutilisation Gestion patient . . . . . . . . . . . . . . 153 5.3.4.3 Cas dutilisation Conguration du robot . . . . . . . . . . 153 5.3.5 Diagramme global des cas dutilisation, structure dynamique et statique du Systme de contrle TER . . . . . . . . . . . . . . . . . . . 155 5.4 Identication des dangers et estimation du risque . . . . . . . . . . . . . . . 157 5.4.1 Analyse prliminaire des dangers . . . . . . . . . . . . . . . . . . . 158 5.4.2 Analyse des modes de dfaillance des acteurs . . . . . . . . . . . . . 159 5.4.2.1 Modes de dfaillance du Site matre . . . . . . . . . . . . . 161 5.4.2.2 Modes de dfaillance de lOprateur . . . . . . . . . . . . 165 5.4.3 Analyse des modes de dfaillance des composants matriels . . . . . 167 5.4.4 Analyse des modes de dfaillance des composants lectroniques . . . 167 5.4.5 Analyse des modes de dfaillance du logiciel . . . . . . . . . . . . . 169 5.4.6 Analyse des arbres de fautes . . . . . . . . . . . . . . . . . . . . . . 175 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

TABLE DES MATIRES Synthse, contributions majeures et perspectives A La notation UML A.1 Concepts transversaux . . . . . A.2 Diagramme des cas dutilisation A.3 Diagramme de classes . . . . . . A.4 Diagramme dtats-transitions . A.5 Diagrammes dinteraction . . . A.6 Diagramme de composants . . . A.7 Diagramme de dploiement . . .

11 181 185 185 186 186 188 189 190 190 191 191 192 194 195 199 201

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

B Complments lanalyse des modes de dfaillance du robot TER B.1 Diagramme des cas dutilisation simpli . . . . . . . . . . . . . . . . . . . B.2 Diagramme de squence principal du cas dutilisation Raliser tche . . . . . B.3 Diagramme de squence principal du cas dutilisation Contrler lexcution de la tche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.4 Diagrammes de squence du cas dutilisation Conguration du robot . . . . . Index Bibliographie

Table des gures

1.1 1.2 1.3 1.4 1.5 1.6 1.7 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 Exemple de tableau pour lestimation du risque . . . . . . . . . . . . . . . . Exemple dutilisation de la terminologie . . . . . . . . . . . . . . . . . . . . Activits de la gestion des risques, gure tire de la norme ISO 14971 (2000) Exemple de diagramme des niveaux dacceptabilit du risque et de la zone ALARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Illustration de lacceptabilit du risque en fonction du cot, gure tire de HSE (1999) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple darbre de fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemple de tableau de lAMDEC . . . . . . . . . . . . . . . . . . . . . . . Photo de lextrmit dun muscle articiel . . . . . . . . . . . . . . . . . . . Coupe dune extrmit dun muscle articiel avant le sertissage de la jupe mtallique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Branchements entre muscle articiel et son pr-actionneur . . . . . . . . . . Force statique de plusieurs muscles 5 bars . . . . . . . . . . . . . . . . . . Site exprimental pour les tests dun muscle en dynamique . . . . . . . . . . Rponse en longueur et force dynamique dun muscle un chelon pour une charge de 15 kg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Puissance instantane en rponse chelon pour une charge de 15 kg . . . . . Forces dynamiques de deux muscles pour une masse souleve de 10 kg . . . Principe de lactionnement dune articulation au moyen de deux muscles antagonistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sens de rotation des 7 axes du bras anthropomorphe . . . . . . . . . . . . . . Vue de dos du bras anthropomorphe 7 axes . . . . . . . . . . . . . . . . . . Vue de face du bras anthropomorphe 7 axes . . . . . . . . . . . . . . . . . . Vue de prol du bras anthropomorphe 7 axes . . . . . . . . . . . . . . . . . Manipulation dun verre par le bras anthropomorphe 7 axes . . . . . . . . . . Dbattements des axes 1 3 du bras anthropomorphe 7 axes . . . . . . . . . Dbattements des axes 4 7 du bras anthropomorphe 7 axes . . . . . . . . . Analyse des modes de dfaillance de la tresse et du systme de maintien . . . Analyse du mode de dfaillance du tube de caoutchouc . . . . . . . . . . . . 26 30 32 38 39 42 42 59 60 60 62 63 64 64 65 66 67 68 68 69 70 71 72 73 74

14

TABLE DES FIGURES 2.19 Rponse en longueur une crevaison . . . . . . . . . . . . . . . . . . . . . . 2.20 Rponse en pression une crevaison . . . . . . . . . . . . . . . . . . . . . . 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 Interactions entre les objets . . . . . . . . . . . . . . . . . . . . . . Exemple de deux instances de la classe CapteurPosition . . . . . . . volution des versions du langage UML . . . . . . . . . . . . . . . Objets, classes et mtamodle . . . . . . . . . . . . . . . . . . . . Dveloppement pilot par les cas dutilisation (CU) . . . . . . . . . Le modle darchitecture 4+1 vues, gure tire de Kruchten (1999) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 75 83 84 85 87 88 89

Vue globale de la dmarche prsente dans ce chapitre . . . . . . . . . . . . 100 Modlisation dun geste mdical (a), et dun cas de tl-mdecine robotise (b) 103 Exemple de diagramme des cas dutilisation . . . . . . . . . . . . . . . . . . 104 Exemple de che de cas dutilisation . . . . . . . . . . . . . . . . . . . . . . 104 Exemple de diagramme de squence pour un scnario du cas dutilisation Raliser tche de la gure 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Interactions principales lors de lutilisation dun sous-systme . . . . . . . . 106 Exemple de tableau pouvant servir pour lanalyse prliminaire des dangers . . 108 Package Behavioral Elements, diagramme tir de la spcication 1.4 dUML 110 Mtamodle des lments Interaction et Message dans la spcication 1.4 dUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 lments dune interaction ralise par lenvoi de deux messages . . . . . . . 112 Exemple de tableau de lAMDEC . . . . . . . . . . . . . . . . . . . . . . . 115 Diagramme de squence illustrant des interactions entre un site matre et un systme esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Analyse dun mode de dfaillance du message Controler_mouvements() . . . 118 Diagramme dtats prenant en compte un mode de dfaillance de Contrler_mouvements() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Procdure de mise en route dun systme quelconque . . . . . . . . . . . . . 119 Gestion du risque induit par les erreurs humaines . . . . . . . . . . . . . . . 121 Exemple dutilisation dun diagramme de dploiement en informatique industrielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Diagramme de classes reprsentant les dispositifs extrieurs au logiciel . . . . 122 Diagramme de blocs tir de larticle de Dombre et al. (2001) . . . . . . . . . 125 Diagramme de classes reprsentant les composants mcaniques dune articulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Package reprsentant les lments du Systme de contrle de la gure 4.18 . . 128 Diagramme de classes dun robot manipulateur dune sonde quelconque pour lexamen dun patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Exemple darbre de fautes pour un effort de la sonde trop important sur le patient131

TABLE DES FIGURES

15

4.24 Rsum de la dmarche prsente . . . . . . . . . . . . . . . . . . . . . . . 133 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 5.23 5.24 5.25 5.26 5.27 5.28 5.29 5.30 5.31 5.32 5.33 5.34 Vue gnrale du systme TER . . . . . . . . . . . . . . . . . . . . . . . . . Diagramme de dploiement du systme dchographie . . . . . . . . . . . . Diagramme de classes des acteurs de lexamen chographique . . . . . . . . Diagramme des cas dutilisation de lexamen chographique . . . . . . . . . Diagramme des cas dutilisation dun robot . . . . . . . . . . . . . . . . . . Diagramme des cas dutilisation du site esclave . . . . . . . . . . . . . . . . Diagramme de classes des acteurs . . . . . . . . . . . . . . . . . . . . . . . Packages et acteurs du systme global . . . . . . . . . . . . . . . . . . . . . Diagramme des cas dutilisation du systme de contrle esclave, que lon note par la suite Systme de contrle TER . . . . . . . . . . . . . . . . . . . . . . Vue de leffecteur du robot esclave TER . . . . . . . . . . . . . . . . . . . . Diagramme de squence du scnario principal de Raliser tche . . . . . . . Cas dutilisation en relation avec Raliser tche . . . . . . . . . . . . . . . . Diagramme de squence du contrle de lexcution de la tche par lOprateur Cas dutilisation Contrler lexcution de la tche . . . . . . . . . . . . . . . Diagramme de squence de la conguration du robot . . . . . . . . . . . . . Diagramme des cas dutilisation illustrant la relation include . . . . . . . . Diagramme gnral des cas dutilisation . . . . . . . . . . . . . . . . . . . . Diagramme dtats du Systme de contrle TER . . . . . . . . . . . . . . . . Diagramme de classes du Systme de contrle TER . . . . . . . . . . . . . . Table destimation du risque . . . . . . . . . . . . . . . . . . . . . . . . . . Table danalyse prliminaire des dangers . . . . . . . . . . . . . . . . . . . . Diagramme dtats illustrant limplantation dun arrt durgence . . . . . . . Diagramme de squence principal du cas dutilisation Raliser tche . . . . . Utilisation du package Communication par le Systme de contrle TER . . . . AMDEC du message Contrler_robot mit par le Site matre . . . . . . . . . Diagramme dtats du Systme de contrle TER prenant en compte les modes de dfaillance du message Contrler_robot . . . . . . . . . . . . . . . . . . AMDEC du message Mettre la pression . . . . . . . . . . . . . . . . . . . . Systme dalimentation en air . . . . . . . . . . . . . . . . . . . . . . . . . Principaux composants mcaniques pour lactionnement des anneaux de dplacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AMDEC dun muscle articiel . . . . . . . . . . . . . . . . . . . . . . . . . Commande en boucle ferme avec un rgulateur de type PIDa . . . . . . . . AMDEC dun capteur de position . . . . . . . . . . . . . . . . . . . . . . . AMDEC dun convertisseur Intensit/Pression . . . . . . . . . . . . . . . . . AMDEC du Contrleur TER . . . . . . . . . . . . . . . . . . . . . . . . . . 139 140 140 141 144 145 146 147 147 148 149 150 152 153 154 155 156 156 157 158 160 161 162 162 163 164 166 166 167 168 168 169 170 170

16

TABLE DES FIGURES 5.35 Diagramme de squence des tests lors de linitialisation (cas dutilisation Congurer Robot) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.36 Contenu du package Contrleur TER . . . . . . . . . . . . . . . . . . . . . . 5.37 Diagramme de classes du logiciel . . . . . . . . . . . . . . . . . . . . . . . . 5.38 Diagramme de squence du logiciel du scnario principal de Raliser tche . 5.39 Diagramme de squence du logiciel de lasservissement en position . . . . . 5.40 AMDEC du message recevoirConsigne() . . . . . . . . . . . . . . . . . . . 5.41 AMDEC du message envoyerCommande() . . . . . . . . . . . . . . . . . . . 5.42 Arbre de fautes de llment racine Pression trop importante sur le patient . . 5.43 Arbre de fautes concernant linstallation du systme . . . . . . . . . . . . . . 5.44 Arbre de fautes illustrant lintroduction du sous-systme darrt durgence . . A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12 A.13 Package, dpendance, note et strotype Acteur, cas dutilisation et association . Strotype Acteur . . . . . . . . . . Classe . . . . . . . . . . . . . . . . . . Association . . . . . . . . . . . . . . . Agrgation, composition et cardinalit . Gnralisation et spcialisation . . . . . tats et transitions . . . . . . . . . . . . Embotement dtats . . . . . . . . . . Diagramme de squence . . . . . . . . Diagramme de collaboration . . . . . . Composant . . . . . . . . . . . . . . . Nud et lien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

171 171 172 173 173 174 175 176 176 177 185 186 186 186 186 187 187 188 188 189 189 190 190 191 192 193 193 194 195 196 196 197

B.1 Cas dutilisation du systme de contrle du site esclave de TER . . . . . . . . B.2 Ralisation de la tche dchographie . . . . . . . . . . . . . . . . . . . . . B.3 AMDEC des messages mis par le patient lors de linteraction Ralisation de la tche dchographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.4 AMDEC du message Contrler_robot mis par le site matre . . . . . . . . . B.5 Contrle de lexcution de la tche . . . . . . . . . . . . . . . . . . . . . . . B.6 Conguration de la tche . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.7 AMDEC du message Mettre en position initiale . . . . . . . . . . . . . . . . B.8 Conguration du contrleur . . . . . . . . . . . . . . . . . . . . . . . . . . . B.9 AMEDC du message Mettre la pression . . . . . . . . . . . . . . . . . . . .

Introduction gnrale
Les systmes technologiques sont au cur de nombreuses applications permettant daider lhumain dans des tches dangereuses, trop complexes ou impossibles. Parmi ces applications, certaines peuvent blesser des humains, ou provoquer des dgts sur les biens matriels ou lenvironnement. De tels systmes sont qualis de systmes scurit critique et leur utilisation est conditionne par la conance que lhumain leur accorde. Cette conance est dautant plus importante que lon assiste aujourdhui des transferts de responsabilits de lhumain vers les dispositifs technologiques. Cette problmatique a conduit lmergence dun nouveau domaine, la sret de fonctionnement, dnie par Laprie (1992) comme la proprit dun systme qui permet de placer une conance justie dans le service quil dlivre . Ce concept permet de regrouper plusieurs proprits que sont la scurit-condentialit (security en anglais), la abilit, la disponibilit, et la scurit-innocuit (safety). Dans le cadre de notre tude, concernant lintgrit des biens et des personnes, nous utiliserons le terme de scurit en lieu de scurit-innocuit. Les moyens utiliss pour garantir ces diffrentes proprits consistent principalement en lutilisation de techniques de conception, dveloppes dans des secteurs de pointe comme laronautique, le nuclaire, ou le spatial. Malgr ces moyens, la complexit grandissante des systmes technologiques, induite notamment par lapparition des systmes dits socio-techniques, o lhumain et le dispositif technologique interagissent pour accomplir une tche, rend impossible la garantie dune scurit absolue. Et, si dans sa dnition premire, le terme de scurit revt un caractre absolu, il est aujourdhui utilis pour exprimer une proprit relative. En effet, les concepteurs intgrent le fait quil subsiste pour toute application un risque rsiduel. La scurit est alors dnie par la connaissance et lacceptabilit de ce risque. Les concepteurs dun systme doivent donc tre en mesure de grer ce risque depuis les premires tapes du processus de dveloppement jusqu lutilisation. La notion de risque, pressentie par la communaut des roboticiens qui se sont concentrs sur la notion de scurit (Dhillon, 1991), est nouvelle dans le domaine de la robotique. En effet, depuis lavnement des premiers automates et des manipulateurs simples pour les fonctions dapprovisionnement, jusquau robots manipulateurs polyvalents permettant le pickand-place, la soudure par points, lassemblage simple, et plus tard la peinture et la nition, ces machines se sont cantonnes un milieu industriel protg. Au sein des chanes de fabrication de lindustrie automobile, de llectro-mnager, de llectronique grand public, ou de lensemble des secteurs de la mcanique, ces robots ont toujours t conns un espace

18

Introduction gnrale

de travail interdit lhumain. Lvolution des techniques et notamment de linformatique, a permis dadapter ces robots manipulateurs des applications non manufacturires hors de lusine, dans des environnements non protgs. Cette robotique de service, dveloppe dans de nombreux domaines comme le spatial, le nuclaire ou le sous-marin, a connu dans les annes 90 une dernire volution vers des applications dites amicales , voluant dans un milieu humain. La robotique mdicale est sans doute la plus spectaculaire de ces applications o lexigence principale est la scurit. La complexit de ces applications et le fait de partager lespace de travail avec lhumain, ou dentrer en contact avec lui (voire lintrieur du corps humain), amne classer ces dispositifs dans la catgorie des systmes scurit critique. Ainsi, le concept de risque prsent prcdemment, sapplique aux systmes de la robotique de service voluant dans un milieu humain. Pour traiter les risques, les ingnieurs doivent faire face de nombreuses difcults relevant de multiples domaines dtude dont les facteurs humains, et ont leur disposition de nombreuses techniques matrielles, logicielles, ou organisationnelles (lies au processus de dveloppement). Choisir parmi ces techniques celles qui correspondent le mieux au problme, est complexe. Les concepteurs, guids par leur savoir-faire, effectuent alors des choix souvent noys dans le processus de dveloppement, sans pouvoir les justier vis--vis de la scurit. Le travail que nous avons ralis contribue proposer aux ingnieurs des solutions pour apprhender cette problmatique. Tout dabord, en partant de lvnement redout, le dommage, nous tudions dans le chapitre 1, les concepts formant la base thorique de notre analyse. partir de ltude de cet effet non dsir, nous prsentons le concept qui en drive, le risque, puis ses causes et les moyens de le grer. Dans le domaine de la robotique de service, cette notion de risque est encore nouvelle, et ce chapitre se consacre intgrer les travaux de domaines transversaux. De plus, le cas de la robotique mdicale, domaine de pointe de la robotique de service, est tudie en estimant que cette analyse peut sappliquer aux autres domaines de la robotique de service moins contraignants en terme de scurit. Ce chapitre montre que parmi les techniques de rduction du risque dveloppes en robotique, un axe de recherche important concerne la dcouverte de nouveaux actionneurs moins lourds et moins rigides. Le poids et la compliance naturelle des muscles articiels de McKibben dvelopps depuis une dizaine dannes au sein du LESIA, semblent rpondre ces contraintes. Ainsi, le chapitre 2 analyse le risque li lemploi de ces actionneurs. Lutilisation des muscles articiels ntant quune technique parmi dautre pour rduire les risques, les chapitres suivants prsentent une dmarche globale danalyse du risque sintgrant au processus de dveloppement, et notamment en se basant sur lutilisation du langage de modlisation orient objet UML (Unied Modeling Language). Le chapitre 3 contient une prsentation des principaux concepts de la modlisation oriente objet avec UML utiliss dans cette dmarche, ainsi quun rapide tat de lart sur les tudes concernant les liens entre ce langage et la sret de fonctionnement. Le chapitre 4 est ddi la prsentation de cette dmarche, et sappuie sur les concepts prsents au chapitre 1. Il se limitera nanmoins lune

Introduction gnrale

19

des activits de la gestion du risque, lanalyse du risque. Cette dmarche se base sur la combinaison de techniques de lingnieur an de pouvoir sintgrer rapidement tout processus de dveloppement. Ainsi, des techniques comme lAMDEC (Analyse des Modes de Dfaillance, de leurs Effets et de leur Criticit) et lanalyse des arbres de fautes sont utilises. De plus cette dmarche intgre le concept de facteurs humains, rarement abord par les concepteurs. La dimension cognitive de ce domaine est encore loigne des sciences de lingnieur, et plus particulirement en France ( loppos des pays anglo-saxons). Dans le contexte de la scurit, nous nous limiterons cependant trois de ses composantes fondamentales que sont lanalyse des tches, lallocation des tches, et lanalyse des erreurs humaines. Le chapitre 5 prsente une application de cette dmarche lanalyse du risque dun robot mdical pour la tl-chographie actionn par des muscles articiels. Ce projet, nanc par le ministre de lenseignement, de la recherche et de la technologie, intitul TER pour Tl-chographie Robotise, initi en 1999, a regroup plusieurs laboratoires, hpitaux et industriels franais. Laspect pluridisciplinaire de cette thse ma conduit explorer des disciplines aux limites des sciences de lingnieur. Et, bien que lapplication de cette thse soit oriente vers la robotique de service, de nombreux lments prsents dans ce mmoire peuvent sappliquer dautres systmes informatiques. Il sagit donc avant tout dun travail transversal, o la notion de risque vient sinclure dans la thorie des systmes, et o les spcialistes de la robotique ainsi que du langage UML, pourront trouver une ouverture vers la matrise de la scurit.

Chapitre 1 Scurit des systmes de la robotique de service

1.1 Introduction

La robotique industrielle essentiellement ddie des processus manufacturiers a rcemment utilis la technologie de ses bras robots pour des applications hors de lusine. Cette robotique de service , et plus particulirement sa composante de pointe, la robotique mdicale (Dario et al., 1996), a fortement modi la problmatique de la scurit des systmes robotiques. Alors que les problmes de scurit des robots industriels relevaient essentiellement de dfaillances des systmes de protection (barrires, grillages, etc.), et que loprateur humain ne pntrait lespace de travail que pour des oprations de maintenance ou de programmation, la robotique de service ncessite de prendre en compte la proximit physique et ltroite collaboration entre lhumain et le robot. Limprieuse exigence de matriser la scurit est dautant plus urgente que les fonctionnalits et lautonomie des robots de service ne cessent daugmenter. Ainsi, le robot mdical Robodoc1 , commercialis pour effectuer le remplacement de la tte du fmur au niveau de la hanche (Pransky, 1997; Cain et al., 1993), ralise lissue de la planication de lopration, la dcoupe et la prparation de la cavit fmorale en totale autonomie. Par ailleurs, on assiste aujourdhui lapparition de systmes de tl-mdecine (mdecine distance) permettant la tlopration du robot par le spcialiste se trouvant une grande distance du patient. Il existe aussi des systmes de tlopration sur site, permettant au spcialiste deffectuer des actions plus rapides et plus prcises. Ainsi, dans un systme comme AESOP (Sackier et Wang, 1994), le chirurgien guide avec sa voix les dplacements dun endoscope, an deffectuer une opration minimalement invasive2 . De
ISS Inc, USA, http ://www.robodoc.com Cette technique opratoire minimise laccs anatomique par le biais de petites incisions pour insrer un endoscope et des instruments chirurgicaux
2 1

22

Scurit des systmes de la robotique de service

faon plus gnrale, plusieurs projets de recherche, sur le modle de larthroscopie3 , visent rduire les oprations de chirurgie en miniaturisant les outils et en faisant appel un guidage par endoscope. Des robots miniatures (ou micro-robots) pourraient rpondre cette demande, et permettre alors des oprations jusquici impossibles, car trop dangereuses, comme de complexes oprations du cur ou du cerveau. Dans ce contexte, les utilisateurs (patients et mdecins), mais galement les personnes se trouvant dans leur environnement ou les autorits acceptant leur mise sur le march, peuvent sinterroger juste titre sur la conance qui peut tre accorde de tels systmes. La scurit, un des facteurs de cette conance, a longtemps t considre comme une proprit rsultant de lutilisation dun ensemble de techniques sans quil y ait de lien entre elles. Il existe nanmoins aujourdhui une science de la scurit, parfois appele science du danger, science du risque, ou plus rcemment cyndinique4 . Bien que ces concepts soient tudis depuis plusieurs annes dans dimportants secteurs comme laronautique ou le nuclaire, la spcicit de la robotique mdicale ncessite une remise en question de ces concepts. Ce chapitre fonde ses analyses sur la notion dvnement non dsir quest le dommage (section 1.2). partir de cette notion, et de lensemble des normes qui lui sont ddies, les parties suivantes traitent des causes des dommages (section 1.3), des moyens que lon peut mettre en uvre pour les traiter (section 1.4) et des techniques appropries ces moyens (section 1.5 et section 1.6). Nous abordons ensuite la notion dassurance que lon peut obtenir concernant la scurit de ces systmes grce la certication (section 1.7). Aprs un premier travail de synthse sur la scurit des robots (Guiochet, 2001), nous avons par la suite privilgi le domaine de la robotique mdicale (Guiochet et al., 2003a). Nous pouvons en effet penser que nos analyses sapplique largement aux autres domaines de la robotique de service moins contraignants en terme de scurit.

1.2

Effets non dsirs : les dommages

An danalyser la notion de scurit inhrente aux robots mdicaux, il nous a paru fondamental de revenir aux notions de base, et de comprendre le mcanisme dapparition dun accident. Pour tout systme, les effets non dsirs sont dnis par la notion de dommage.
Examen dune cavit articulaire au moyen dune camra appele endoscope permettant par la suite deffectuer des oprations sans ouvrir comme en chirurgie 4 http ://www.cindynics.org
3

1.2 Effets non dsirs : les dommages

23

1.2.1 Dommage
1.2.1.1 Dnition

La notion de dommage est particulirement stable, car il est possible de retrouver la mme dnition dans le domaine mdical (ISO 14971, 2000), en robotique (Prasad, 1988) et au sein des normes gnriques (IEC 60300-3-9, 1995). La dnition gnrique du ISO/CEI Guide 51 (1999) est utilise dans le domaine mdical o le dommage est dni comme : Dommage Blessure physique ou une atteinte la sant des personnes, ou dgt caus aux biens ou lenvironnement

Il est intressant de comparer cette dnition avec celle de la scurit frquemment utilise en robotique industrielle, dnie comme la prvention de dgts sur lhumain, le robot et les lments avec lesquels le robot interagit (Dhillon, 1991). On retrouve deux composantes de la notion de dommage : les personnes qui peuvent tre les patients, les spcialistes ou les assistants, identis ici comme les humains, les biens, correspondants aux dispositifs mdicaux utiliss (le robot lui-mme, les outils, les appareils de mesures, etc.) , Cependant, dans la dnition adopte dans le domaine mdical, on trouve une composante supplmentaire qui est lenvironnement. En dehors des biens et des personnes, il est en effet possible didentier les dommages sur lenvironnement en terme de destruction, pollution, etc. Ceci est particulirement important pour les nouvelles applications de robotique de service dont la tche peut inuer sur ltat de lenvironnement. Le dommage peut ensuite tre quali par sa nature (brlure, crasement, coupure, etc.) et mesur par sa gravit et sa probabilit doccurrence. 1.2.1.2 Gravit dun dommage

Pour des systmes robotiques mdicaux, la notion de gravit est identique de nombreux autres domaines technologiques. Elle value la nuisance des dommages. Cependant, les normes relatives aux dispositifs mdicaux ne prescrivent aucune chelle de graduation de ces nuisances, et laissent ainsi le choix aux fabricants ( loppos dautres domaines o les niveaux sont prdnis). La liste ci-dessous donne un exemple de mtrique sur la gravit des dommages sur les seuls humains : Catastrophique : dcs dune ou plusieurs personnes Majeur : blessures ou maladies graves, inrmit permanente Mineur : blessures ou maladies mineures, ncessitant un traitement mdical Minime : lgres blessures relevant des premiers soins (ne ncessitant pas un traitement mdical) Ngligeable : incident nexigeant aucun traitement mdical

24

Scurit des systmes de la robotique de service

Notons que dans cette chelle de mesure, le dcs dune ou de plusieurs personnes est class comme catastrophique alors que dans dautres domaines technologiques le niveau catastrophique est rserv loccurrence du dcs de plusieurs personnes. Cest le cas par exemple pour les dommages dorigine naturelle (sismes, etc.). Pour les dispositifs mdicaux, il est vident que lenjeu est la sant dun patient, et que son dcs est donc catastrophique. La notion de gravit en fonction du nombre de morts est par consquent un concept inexistant en mdecine. Il existe malgr tout un exemple de dispositif mdical ayant provoqu un ensemble de dcs (six), le Therac-25, utilis aux tats-Unis, qui a provoqu un ensemble deffets secondaires cause dune trop forte exposition de rayons X. Ce cas est prsent plus en dtail dans la section 1.4.3.3. Le terme de svrit est parfois utilis pour exprimer la gravit. Cela provient en partie de la comparaison avec le terme anglais severity, mais son utilisation, critique daprs le Nouveau Petit Robert (1995), ne fait quajouter une dnition supplmentaire au domaine du risque dj lourd en synonymes. 1.2.1.3 Occurrence dun dommage

En plus de la gravit, un dommage est quali par sa frquence doccurrence. Dans la norme mdicale ISO 14971 (2000), la probabilit dun dommage est exprime en terme doccurrence dun dommage. Mme si cette mesure nest ici que qualitative (frquent, occasionnel, etc.), le terme de probabilit est conserv. Cette norme voque le fait qu une bonne description qualitative est prfrable une inexactitude quantitative . Ce point de vue que lon retrouve dans beaucoup douvrages aujourdhui, a un aspect novateur par rapport aux prescriptions qui ont t faites lors des dbuts des tudes de sret de fonctionnement. Il provient en particulier de la difcult destimer les probabilits obtenues selon trois approches : utilisation de donnes historiques utilisation de techniques danalyse ou de simulations utilisation de jugements dexperts En robotique mdicale, il nexiste pas notre connaissance de donnes historiques exploitables. Labsence de telles informations pour ces systmes pourrait tre pallie en se rfrant des donnes sur des dommages lis aux contrleurs de robots industriels, des dommages causs par lutilisation de logiciels dans le milieu mdical, des dommages induits par lutilisation de dispositifs mdicaux autres que des robots, etc. La liste ci-dessous fournit un exemple de niveaux de probabilit doccurrence, utilisables pour une estimation qualitative, on donne malgr tout une frquence indicative par anne indique entre parenthses : Frquente (>1) Probable (1 101 ) Occasionnelle (101 102 ) Rare (102 104 )

1.2 Effets non dsirs : les dommages

25

Improbable (104 106 ) Invraisemblable (<106 ) Dans cette classication, Frquente indique une frquence doccurrence du dommage plusieurs fois par an, et Invraisemblable correspond une occurrence tous les 1 000 000 ans. Cependant, selon chaque application, cette classication peut tre modie, certaines utilisant des mesures des frquences comprises entre une occurrence journalire et une toute les 5 ans. Comme prcdemment signal, et contrairement dautres domaines prsentant des risques de dommages, il nexiste pas dans le domaine mdical de norme spciant des mtriques sur les frquences doccurrence : le choix est laiss aux concepteurs. Pour les systmes technologiques complexes comme ceux de laronautique, la limite infrieure est une probabilit de lordre de 109 occurrence par an correspondant la probabilit dapparition dune catastrophe naturelle. Lchelle de valeur que lon a donne ci-dessus nest quun exemple dillustration pour bien exprimer ce quest une probabilit doccurrence. Il est nanmoins vident que lors de lutilisation dun robot mdical, cette estimation sera fortement dpendante du nombre dintervention au cours dune anne, et que le nombre doccurrence annuelle de dommage nest pas signicatif. La plupart de normes sur le sujet vite ce problme en laissant aux concepteurs le choix de la dnition, et donc du calcul, des niveaux de probabilit.

1.2.2 Notion de Risque

1.2.2.1 Dnition

An de rendre compte de linteraction entre la gravit et loccurrence dun dommage, la notion de risque a t introduite. La dnition de la norme mdicale ISO 14971 (2000) est identique celle du ISO/CEI Guide 51 (1999) : Risque Combinaison de la probabilit dun dommage et de sa gravit

La notion de risque connat des uctuations dans sa dnition et est parfois prsente comme la probabilit du danger (par opposition avec la probabilit doccurrence du dommage) combine avec la gravit du dommage. Cest notamment le cas dans les versions prcdentes des normes mdicales sur le risque (EN 1441, 1997; Pr ISO 14971, 1999). Dans le domaine mdical, cest la notion de probabilit du dommage qui est aujourdhui utilise. On dnit plus gnralement pour un risque la probabilit dun dommage en exprimant, par exemple, la probabilit quil y ait un dcs ou des complications ou des effets secondaires, sans prciser quels vnements ont provoqu ce dommage. La dtermination des circonstances de lapparition du dommage est illustr par les notions lies au danger exposes ultrieurement (cf. 1.3). 1.2.2.2 Mesure du risque

An de quantier le niveau du risque, il est possible pour chaque couple (probabilit, gravit) de dnir un niveau. Certains couples peuvent tre alors compars, et choisis de mme

26
Frquence doccurrence

Scurit des systmes de la robotique de service

Gravit du dommage Frquence indicative 4 1 2 3 (par anne) Catastrophique Majeure Mineure Minime

5 Ngligeable I I L T T T

Frquente Probable Occasionnelle Rare Improbable Invraisemblable

>1 1-10
-1 -2 -4 -1 -2

H H H H I I

H H H I I L

H H I I L T

H I I L T T

10 -10 10 -10 10 -10 <10

-6

-3 -6

F IG . 1.1 Exemple de tableau pour lestimation du risque

niveau. Sur la base des classications de gravit et probabilit doccurrence prsentes en sections 1.2.1.2 et 1.2.1.3, le tableau de la gure 1.1 estime le risque suivant quatre niveaux, H (risque fort), I (risque intermdiaire), L (risque faible), et T (risque insigniant). La probabilit est exprime en frquence doccurrence, plus facilement mesurable dans une dmarche qualitative. 1.2.2.3 Risque acceptable

La notion de risque est essentielle pour caractriser la conance attribue un systme. En effet, si on admet souvent comme potentiels des dommages svres, seule leur faible probabilit doccurrence nous les font accepter. Par exemple, nous continuons prendre lavion malgr les accidents possibles du fait que la probabilit dun crasement conduisant aux dcs des passagers est extrmement faible. Nous tablissons gnralement cet arbitrage en fonction des risques que nous encourront par ailleurs, comme ceux induits par des phnomnes naturels : tremblements de terre, avalanches, inondations, etc. On dnit ainsi la notion de risque acceptable drive du ISO/CEI Guide 51 (1999), comme un risque accept dans un contexte donn bas sur des valeurs courantes de notre socit. Notons que lacceptabilit concerne le risque et non la gravit du dommage ou sa probabilit doccurrence considres sparment. Cette dnition souligne galement le fait que lacceptabilit dpend de valeurs courantes de notre socit souvent fondes sur des donnes associes des phnomnes naturels. Ainsi on accepte de prendre le risque de mourir en prenant lavion si la probabilit de ce dcs par cette cause est identique voire infrieure la probabilit de dcs induit par un sisme ou une crise cardiaque (pour un corps sain). La dnition prcise par ailleurs que lacceptabilit est fonction du contexte. Ce contexte peut tout dabord caractriser ltat dun savoir sur des pratiques ou sur une technologie de mise en uvre. Ainsi le risque accept par les passagers des premiers aronefs tait-il bien suprieur celui actuellement tolr par les passagers des avions de ligne.

1.2 Effets non dsirs : les dommages

27

Le contexte exprime galement lapport escompt malgr le risque pris. Ainsi, une opration chirurgicale ou la prise dun mdicament rcemment mis au point a une probabilit non ngligeable de conduire des dommages graves. Leurs risques sont accepts du fait de la gurison espre ou des dommages inluctables causs par une volution naturelle de la maladie. Dans sa dnition idale, un risque associ un robot mdical serait acceptable si le pronostic des patients samliorait (ceci est vrai pour tout dispositif mdical). Au vu de la complexit de lvaluation du risque associ aux applications robotiques mdicales, il est difcile dappliquer cette simple rgle. Nous reviendrons sur cette notion dans la partie 1.4.4 o nous prsenterons les moyens qui existent actuellement pour spcier un risque acceptable.

1.2.3 Scurit
Le concept de scurit est devenu un des enjeux les plus importants pour de nombreux domaines technologiques. Il est parfois utilis pour exprimer labsence daccident ou de perte. De la mme manire, dans le domaine de la robotique industrielle, la scurit est dnie comme la prvention de dgts sur lhumain, le robot et les lments avec lesquels le robot interagit (Dhillon, 1991). Ces dnitions donnent une dimension absolue la scurit. Or le domaine mdical prouve bien quil ny a quune scurit relative ; il existe toujours un risque rsiduel. Par exemple, sur un nombre donn doprations chirurgicales, il est tabli quil existe un certain nombre de rejets, dinfections, ou dautres complications allant parfois jusquau dcs du patient. Au regard des bienfaits pour la majorit des patients, la socit permet de prendre ce risque. Dans ce contexte, le terme scurit est employ dans le domaine mdical pour exprimer un niveau de scurit atteint en rduisant le risque un niveau acceptable. Cest la dnition du ISO/CEI Guide 51 (1999) que nous adopterons pour la suite de notre tude : Scurit Absence de risque inacceptable

Le risque acceptable est, par consquent, le rsultat dun quilibre entre lidal de la scurit absolue, les exigences auxquelles doit rpondre le systme concern, et des facteurs comme le bnce pour les patients, le cot effectif, les rgles et les conventions de la socit concerne. La scurit, dans cette optique, est donc un concept li une connaissance du niveau de risque accept. Ainsi, pour beaucoup doprations chirurgicales, la gravit et la probabilit des dommages possibles (donc le risque) sont des informations que le praticien donne au patient. Ce dernier fait alors conance ou non au niveau de scurit de lintervention mdicale. Il est important de noter que mme si certaines tudes de abilit et de scurit se recoupent, ces deux notions sont bien distinctes au sens o lune sintresse la continuit du service dlivr et lautre la notion de dommage. Il est tout fait possible denvisager une solution trs able mais avec un niveau de scurit trs bas, et vice versa. Par exemple, un

28

Scurit des systmes de la robotique de service

systme dchographie dont la mise sous tension ne provoque aucun effet est peu able mais trs sr.

1.3

Causes : les dangers

1.3.1 Notion de danger

An de prvenir les dommages, la notion de danger est introduite en tant que concept en amont. Le danger a t dni de diffrentes manires. Dans MORT (Management Oversight and Risk Tree prsent par Johnson (1980)), il est principalement caractris par un transfert dnergie. De manire similaire, en robotique industrielle, le danger se rapporte une accumulation dnergie aboutissant un accident (Kumamoto et al., 1986). Le danger a aussi t dni comme une proprit inhrente dun objet, dune substance ou dun sous-systme qui a la capacit de provoquer un dommage. Dans le domaine mdical, il est vident que les dangers ne se rduisent pas un transfert dnergie ou une proprit inhrente. On peut citer comme exemple le rejet dun organe transplant, le dveloppement dun effet secondaire ou le fonctionnement irrgulier (voire larrt) dun pacemaker. Dans le cadre dun systme automatis comme un robot mdical, il est important de prendre en compte ltat dans lequel le systme se trouve et les conditions denvironnement pour dnir un danger. Ces considrations se rapprochent de la dnition donne pour les systmes informatiques par Leveson (1995), o le danger (hazard) est dni par un tat ou un ensemble de conditions dun systme (ou dun objet), qui, coupls avec dautres conditions de lenvironnement du systme (ou de lobjet) mneront invitablement un accident . Les normes IEC 60300-3-9 (1995) et EN 1441 (1997) dnissent le danger comme source potentielle de dommage . Cette dnition se diffrencie de celle de Leveson en posant une condition de potentialit sur laboutissement un dommage. La notion de source est dans ce cadre ambigu et peut tre interprte de diffrentes manires. Il est en effet parfois difcile de faire la diffrence entre le danger, sa cause ou ses effets. Par exemple de telles normes fournissent des listes de dangers communs aux dispositifs mdicaux pour aider le concepteur les identier, et lon peut retrouver dans ces listes la fois des effets et des causes. Cest en cela que le terme source reste large et peut dsigner une dfaillance, une faute ou une erreur dans la terminologie de Laprie et al. (1995). Le concept de source ne souligne pas non plus le fait que cest une combinaison de circonstances qui peuvent aboutir un dommage.

1.3.2 Phnomne dangereux et situation dangereuse

Les disparits entre les dnitions prcdentes ont t rduites avec la publication de la dernire version de la norme sur la gestion du risque pour les dispositifs mdicaux (ISO 14971,

1.3 Causes : les dangers

29

2000)5 . Le terme de phnomne dangereux a t substitu au terme de danger et la notion de situation dangereuse a t introduite. Phnomne dangereux Source potentielle de dommage

On regroupe sous cette appellation lensemble des sources et des facteurs pouvant contribuer la cration dun dommage. Ainsi, un bord coupant est un phnomne dangereux, mais cela ne provoquera pas obligatoirement un dommage. En revanche, en introduisant la notion de situation dangereuse, les normes utilises ici rejoignent la dnition de danger (hazard en anglais) nonce en thorie des systmes informatiques (Leveson, 1995). Situation dangereuse Situation dans laquelle des personnes, des biens ou lenvironnement sont exposs un ou plusieurs phnomnes dangereux

1.3.3 vnement dommageable

Le terme dvnement dommageable est dni dans le ISO/CEI Guide 51 (1999) comme lvnement dclencheur qui fait passer de la situation au dommage. Ce concept nest pas repris dans les normes ddies aux dispositifs mdicaux. En revanche, pour une application robotique il peut tre intressant dutiliser ce concept. Il permet en effet de spcier lvnement qui fait passer le systme socio-technique (systme incluant les humains et la technologie) dune situation dangereuse un dommage spcique. En robotique mdicale, de tels vnements sont principalement des interactions entre loutil du robot et une partie du corps du patient (coupure, arrachement, tirement, brlure, etc.) dont rsulte un dommage (saignements, destruction de liaisons, destruction de fonctionnalits, perforation, etc.).

1.3.4 Incident et accident

Les analyses de scurit utilisent deux notions importantes, pourtant absentes de la norme mdicale ISO 14971 (2000), mais qui apparaissent dans la majorit de la littrature sur le domaine. On dnit alors la notion daccident en sinspirant de la dnition propose par Leveson (1995) : Accident vnement non dsir et doccurrence non prvue rsultant en un niveau de dommage spci

Cette notion repose sur celle de lvnement dommageable. Dans le cas dun accident, lvnement dommageable produit un dommage de gravit non nulle ou non ngligeable. loppos, un vnement dommageable produisant un dommage de gravit nulle ou ngligeable (en gnral d des circonstances extraordinaires, on peut alors parler de chance) produira ce que lon dnit par un incident.
5

Cette norme vient remplacer la EN 1441 (1997)

30

Scurit des systmes de la robotique de service

Bord tranchant Patient

Phnomne dangereux Situation dangereuse

Coupure
Evnement dommageable

Plaie ouverte
Dommage

F IG . 1.2 Exemple dutilisation de la terminologie Incident vnement qui ne conduit pas des pertes, mais qui a le potentiel de crer des dommages en dautres circonstances

Ainsi un mouvement intempestif dun bras de robot qui ne touche pas dhumain (ni de biens) alors que ceux-ci se trouvaient dans son espace de travail, est un incident sil ny a aucun dommage. Cest le cas si un robot frle avec une grande vitesse la tte dun humain. Mme si ces dnitions restent proches de leur utilisation dans le langage courant, elles peuvent parfois crer la confusion avec dautres termes comme le danger. Dans le domaine mdical les normes ne font pas rfrence ces notions alors que dans le domaine des systmes scurit critique (nuclaire, avionique, etc.) elles sont couramment utilises.

1.3.5 Exemple dutilisation des notions lies au risque

Les exemples de la robotique industrielle considrent principalement les ux dnergie comme phnomnes dangereux. En prenant lexemple dune coupure (vnement dommageable), on peut donner une illustration diffrente des concepts lis au danger. La gure 1.2 illustre le fait quune situation dangereuse conduira un dommage sil existe un vnement dangereux (ou dommageable). Lannexe D de la norme ISO 14971 (2000) fournit un ensemble dexemples de phnomnes dangereux possibles et des facteurs qui y contribuent . La classication prsente ne met pas en valeur les diffrents concepts que nous venons dintroduire, et il est possible de trouver un mme niveau de classication des causes de dfaillances, des dfaillances, des types gnriques de sources de dommages, des proprits inhrentes des substances, etc. Le propos de cette norme nest donc pas de donner une vue claire de la terminologie utilise grce des exemples, mais de fournir une liste permettant ventuellement aux concepteurs de trouver des phnomnes dangereux ou des facteurs qui y contribuent, qui nauraient pas t identis. On y trouve des termes gnriques comme par exemple des attributs de lnergie tels que llectricit, la chaleur, la force mcanique, le rayonnement et dans le mme temps des causes de ces transferts nergtiques comme les pices mobiles, les mouvements intempestifs, les masses suspendues, etc. (ISO 14971, 2000, p.22). partir de cette liste, il est tout de mme possible de dresser pour les dispositifs mdicaux une liste de phnomnes dangereux lis un sous-systme : proprits inhrentes dangereuses (un bord tranchant, un gaz toxique)

1.4 Moyens : la gestion du risque

31

tats dangereux du sous-systme (en mouvement, masse suspendue) dfaillances dangereuses incluant les erreurs humaines autres

1.3.6 Analyse du danger

Le terme de danger peut tre utilis en tant que notion gnrale regroupant trois concepts fondamentaux : le phnomne dangereux, la situation dangereuse, et lvnement dommageable. Ltude dun accident peut alors tre mene comme une tude globale faisant appel ces trois vnements, parfois qualie danalyse du danger, sachant que son but est de fournir une base pour lanalyse du risque. Le premier point concerne lanalyse de lvnement dommageable puisquil est le dernier vnement apparaissant avant laccident ou lincident. Lidentication est directe et peut sappuyer sur les donnes historiques, le jugement dexperts ou des techniques danalyse. Il est alors possible dtudier le risque associ cet vnement. Lanalyse des situations dangereuses est plus dlicate, et peut se faire par une connaissance plus avance des sous-systmes. Il est aussi possible de calculer la gravit du dommage associ et la probabilit doccurrence de cette situation. On obtient ainsi le risque de la situation dangereuse. Enn, pour chaque phnomne dangereux, il est aussi possible de calculer le risque, toujours en considrant le dommage induit. Le risque dun dommage est ensuite calcul en combinant les diffrents rsultats des analyses lies ce dommage. Par exemple, en considrant le cas catastrophique du dcs dun patient, il est possible didentier plusieurs vnements dommageables, situations dangereuses et phnomnes dangereux induisant ce dommage. Pour un niveau de gravit du dommage donn, la probabilit doccurrence du dommage est ensuite estime en fonction des diffrentes probabilits doccurrence de ces trois lments. An de guider ltude de ces lments un processus de gestion du risque est prsent dans la partie suivante.

1.4

Moyens : la gestion du risque

1.4.1 Vue densemble

La gure 1.3 donne une reprsentation schmatique des principales tapes du processus de gestion des risques. Ce processus correspond celui prsent dans la norme ISO 14971 (2000) tir du ISO/CEI Guide 51 (1999). Ce schma, ddi aux dispositifs mdicaux se retrouve en partie dans des normes gnriques comme la IEC 60300-3-9 (1995). Il est aujourdhui accept dutiliser cette approche dans de nombreux domaines technologiques. Une tape supplmentaire est parfois prsente, concernant la gestion des informations post-production (informations concernant les risques, guides dutilisation, etc.). Avant de dtailler chaque tape de ce

32

Scurit des systmes de la robotique de service

Analyse du risque
- Identification de lemploi prvu, dfinition du systme - Identification des phnomnes dangereux - Estimation du risque

valuation du risque
Dcisions dacceptabilit du risque

Matrise du risque
- Analyse des options - Mise en oeuvre - valuation du risque rsiduel - Acceptation globale du risque

F IG . 1.3 Activits de la gestion des risques, gure tire de la norme ISO 14971 (2000) processus dans les sections 1.4.3, 1.4.4 et 1.4.5, nous abordons la question essentielle des facteurs humains au sein de la gestion du risque.

1.4.2 Facteurs humains et gestion du risque pour des systmes de la robotique mdicale
La prsence dhumains dans lenvironnement des systmes de la robotique de service et en particulier de la robotique mdicale, en fait des systmes dits socio-techniques. La scurit de tels systmes ne dpend pas uniquement de la dfaillance de ses composants. De plus, lhumain ne peut tre rduit un simple composant ayant un taux de dfaillance. Il peut, par exemple, stopper le systme en cas de dfaillance et nir une opration chirurgicale de manire classique. Son rle dans lutilisation du systme est une composante particulire quil convient danalyser. Ainsi, aujourdhui, la scurit est gnralement obtenue par une analyse des facteurs de risque principalement dus aux dfaillances, mais aussi par une analyse des facteurs humains. Dans le milieu industriel, les facteurs humains sont pris en compte au sein du processus de dveloppement. Mais bien que ce domaine cristallise de nombreuses recherches, il est encore difcile de trouver dans les processus de dveloppement des robots mdicaux, des lments y faisant rfrence. La diffrence de langage entre ingnieurs et spcialistes du domaine cognitif est sans doute une des raisons de ce problme. On peut noter, par exemple, labandon dun projet de norme, la CEI 300-3-8, mentionne dans la IEC 60300-3-9 (1995), qui devait traiter de lapprciation de la abilit humaine. Dans le domaine de la robotique beaucoup dtudes portent sur des aspects trs techniques lis aux interactions entre humains et robots du point de vue des ordres envoys au robot. Par exemple, diffrents modes de tlopration comme le retour deffort ou la commande par

1.4 Moyens : la gestion du risque

33

la voix sont tudis. Dans le domaine mdical, les facteurs humains concernaient principalement ltude de lerreur humaine (Felciano, 1995), sujet largement abord par les sciences cognitives (Reason, 1990). Dans le contexte de la robotique mdicale, nous nous intresserons essentiellement aux facteurs humains qui concernent lutilisation dun systme de robotique mdicale. Nous naborderons pas les facteurs humains concernant la fabrication du systme, ni ceux dvolus exclusivement au domaine mdical comme lerreur de diagnostic. Plusieurs approches existent pour exprimer les interactions entre lanalyse de la scurit (correspondant la gestion du risque) et lanalyse des facteurs humains. Laprie et al. (1995, p65-66) classent les moyens pour la sret de fonctionnement des systmes socio-techniques suivant quatre activits. La scurit, en tant quattribut de la sret de fonctionnement, est ainsi augmente par ces moyens. Les aspects de la scurit lis aux facteurs humains utilisent ici la notion derreur humaine pour la classication de ces activits : La prvention des erreurs humaines a trait principalement la recherche dune rpartition des tches entre humains et technologie qui permette de coner aux humains des fonctions et des tches homognes et cohrentes. La prvision des erreurs humaines concerne les mthodes pour estimer la prsence, la cration et les consquences des erreurs humaines. Llimination des causes derreurs humaines concerne la rduction des causes derreurs en mettant lhumain en situation relle ou en simulation. La tolrance aux erreurs humaines concerne lintroduction de mcanismes permettant au systme socio-technique de continuer sa fonction en dpit des erreurs. Cette classication permet, grce la terminologie utilise, de donner une vision claire des moyens disponibles concernant les facteurs humains. Mais elle nindique aucun enchanement dtapes et aucune interaction avec lanalyse des risques. Daouk et Leveson (2001) exposent les tapes de la fabrication dun systme en mettant en parallle les tapes et les interactions entre trois domaines : le processus de dveloppement, lanalyse de la scurit et lanalyse des facteurs humains. Leurs travaux font apparatre des redondances ou des activits communes lanalyse de la scurit et lanalyse des facteurs humains mais conservent la sparation entre ces deux domaines. De plus, il est intressant de noter que dans un ouvrage de rfrence sur la scurit des systmes comme celui de Leveson (1995), la notion de facteurs humains nest pas utilise, et que seule lerreur humaine est aborde. Dans un rapport de la Food and Drug Administration (2000), les facteurs humains concernent lidentication et la matrise des dangers relatifs lutilisation des dispositifs mdicaux, et sont ce titre intgrs dans la gestion du risque. Nous reprenons cette proposition, an de lappliquer la robotique mdicale, au sein des tapes de la gestion du risque. Cette dmarche se retrouve dans un rapport de la HSE (2001b), o il est propos dinclure les facteurs humains la norme IEC 61508 (2001) ddie aux dispositifs lectriques, lectroniques et programmables relatifs la scurit. Ce rapport reprend tape par tape le cycle de vie de la scurit vu par cette norme et propose linclusion dactivits propres aux facteurs humains.

34

Scurit des systmes de la robotique de service

1.4.3 Analyse du risque

Premire tape de la gestion du risque, lanalyse du risque constitue le cur du processus. Dans la terminologie des normes prcdentes (EN 1441, 1997), lanalyse du risque tait mme parfois considre comme le processus entier. 1.4.3.1 Analyse du risque et processus de dveloppement

Aprs une synthse des aspects normatifs dans les domaines ferroviaire et aronautique, Papadopoulos et McDermid (1998) proposent dutiliser un processus dvaluation de la scurit (Safety Assessement Process) qui prend comme premier point dentre une analyse des risques. Ce processus est parallle au processus de dveloppement avec lequel des informations sont continuellement changes. Il est vident quune analyse de la scurit dpend du dveloppement du systme mais impose aussi certaines modications (conception, utilisation, etc.). Leveson (1995) attribue ainsi deux nalits majeures une analyse du risque : la participation au processus de dveloppement et la production dinformations en vue de la certication. Le cadre lgal actuel renverse cette situation, puisque ce sont les rgles de la certication qui imposent la prsence dune analyse du risque dans le processus de dveloppement. Cela implique notamment que ce processus comme tout processus actuel de dveloppement soit itratif, continu et incrmental et nintervienne donc pas seulement en dbut de fabrication ou des tapes xes du dveloppement. 1.4.3.2 Dnition du systme et de lutilisation prvue

Le premier point de lanalyse du risque concerne la description de lemploi prvu du dispositif. Cette tape a pour but de fournir une base pour lidentication des phnomnes dangereux. Dun point de vue gnrique il est conseill dans cette tape de fournir les lments suivants : une description gnrale, une dnition des frontires du systme, et une description de ses interfaces, une dnition de lenvironnement, une description des ux dnergie, de matires et dinformations aux travers des limites, une dnition des fonctions couvertes par lanalyse du risque. La norme ISO 14971 (2000) fait aussi apparatre des lments faisant rfrence aux facteurs humains (sans les nommer) pour cette activit. Il est par exemple conseill de dcrire lenvironnement dutilisation du dispositif, de dnir qui se charge de linstallation du dispositif, et si le patient peut contrler le dispositif mdical ou inuer sur son utilisation . Dans ces considrations on met en valeur, dune part, limportance de la description de lutilisation en prenant en compte les interactions avec les humains, et dautre part, la ncessit deffectuer une allocation des tches entre les diffrents humains et le dispositif. Cette distribution de la charge de travail se fait en fonction des performances humaines. Cette norme aborde ce der-

1.4 Moyens : la gestion du risque

35

nier point en voquant limportance des facteurs tels que lutilisateur prvu, ses capacits physiques et mentales, ses comptences et sa formation . Lanalyse de la tche et lallocation de la charge de travail sont des activits que lon trouve dans la littrature sur les facteurs humains, mais qui napparaissent pas explicitement dans les normes ddies au risque. Dans le cas des robots mdicaux il convient de se poser la question fondamentale : quelles tches ou parties de tches le robot et lhumain sont-ils les plus -mme de raliser ? Alors que pour les robots industriels la tche sexcutait entirement soit par lhumain soit par le robot, le problme se pose diffremment en robotique mdicale. En effet, pour une mme tche, le spcialiste et le robot peuvent collaborer de diffrentes faons ; le lecteur pourra se rfrer au classement des robots mdicaux en fonction du type dinteraction avec le spcialiste, prsent par Troccaz (1999) et Cinquin (1993). Pour le dveloppement de ces nouvelles applications, laspect danalyse de la tche avec prise en compte du comportement humain est devenu une tape complexe. Les codes du domaine mdical et la complexit des tches telle quune opration chirurgicale rendent ce travail dlicat. Aujourdhui cest un travail qui ne peut se faire que par une collaboration troite entre ingnieurs et spcialistes du domaine mdical. 1.4.3.3 Identication des phnomnes dangereux

Ltape didentication des phnomnes dangereux connus et prvisibles est base sur la dnition du systme. De nombreuses activits peuvent tre utiles lidentication des dangers dans des systmes technologiques comme les robots mdicaux telles que (liste non exhaustive) : la consultation des bases de donnes sur les expriences, les rapports sur les accidents et les incidents, lutilisation de listes comme celle de la norme ISO 14971 (2000), lexamen des sources et des transferts dnergie, lestimation des matires dangereuses (substances, rayons, systmes de pression, etc.), la consultation des analyses de risque dautres dispositifs, les sessions de brainstorming, consultations dexperts, lexamen des interactions entre le patient, le robot et le spcialiste, lutilisation de techniques danalyse. Les techniques utilises pour lidentication permettent soit de partir de phnomnes dangereux, et den dduire des situations et des vnements dommageables (on parle alors de techniques forward), soit de partir des dommages et des vnements dommageables et de retrouver les situations puis les phnomnes dangereux (analyses backward). Parmi les points essentiels de cette activit, il convient de noter limportance de lerreur humaine en tant que phnomne dangereux, ayant des causes, des effets, et des interactions avec dautres dfaillances, et quil est possible de dtecter et de rduire. Il est aujourdhui devenu vident que ce thme est un des enjeux majeurs de la gestion du risque. Des exemples comme lavionique o lerreur humaine est responsable de 70% des accidents, ou comme

36

Scurit des systmes de la robotique de service

laccident de Chernobyl, dmontrent la ncessit dintgrer cette problmatique. Au sein de ce domaine dtude un aspect important concerne les problmes dutilisation des interfaces homme-machine. Un des cas classiques illustrant cet aspect dans le domaine mdical, est celui du Therac-25, analys par Leveson (1995, Annexe A). De 1985 1987, cette machine de traitement de tumeurs par laser, contrle par ordinateur, a provoqu des dommages sur 6 personnes allant parfois jusquau dcs. Certains des accidents ont t provoqus par des squences non prvues de manipulation par les utilisateurs. Ces derniers nont forc ou dsactiv aucune fonctionnalit, et les modications pour bloquer les erreurs ont t introduites par la suite. Ltude de lerreur humaine est un domaine la frontire des sciences cognitives (Reason, 1990; Leplat, 1985), et difcilement intgre par les concepteurs. Comme expos en 1.4.3.3, la complexit de cette discipline a souvent men lutilisation de checklist et de rgles de conception. Cependant comme le soulignent Wright et al. (1994) ces moyens ne sont pas sufsants pour de nombreux systmes et plus particulirement pour les systmes innovants. Face cette problmatique, les ingnieurs ont donc dvelopp des heuristiques et des techniques comme THERP (Technique for Human Error Rate Prediction, dveloppe par Swain au Sandia National Laboratories) permettant daider les concepteurs adapter la tche lhumain. 1.4.3.4 Estimation du risque

Cette tape correspond au calcul du risque. La norme ISO 14971 (2000) indique que le risque pour chaque phnomne dangereux doit tre calcul. Or par dnition (cf. partie 1.2.2), le risque est calcul sur la base du dommage, et non par les phnomnes dangereux qui sont son origine. Lestimation ne peut donc se faire directement, et le calcul est effectu en combinant les estimations pour chaque phnomne et chaque situation. Cest sans doute une des raisons qui explique pourquoi les normes prcdentes proposaient une dnition du risque en fonction du danger et non du dommage comme aujourdhui. Lestimation consiste donc identier la gravit des dommages et la probabilit des phnomnes dangereux conduisant ce dommage. Le risque global est ensuite calcul partir de toutes ces donnes. Pour cette estimation, il est possible dutiliser des normes publies sur lapplication mdicale considre, des donnes techniques scientiques, des donnes de terrain partir de robots mdicaux dj en service (donnes encore trs rares), dessais et dvidences cliniques, lopinion des experts, ou des systmes extrieurs dvaluation de la qualit. La principale difcult provient du calcul de la probabilit dun dommage. Toute tude dbute par une estimation qualitative et lorsque cela est possible, elle est complte par une tude quantitative. Dans les systmes complexes comme les robots mdicaux (mlangeant des aspects mcaniques, lectroniques, informatiques et humains), il est naturel de se poser la question de la faisabilit et de la valeur dune estimation quantitative. Dans dautres domaines, tel que lavionique, certains rsultats ont t critiqus soit pour la complexit de leurs calculs,

1.4 Moyens : la gestion du risque

37

soit du fait de rsultats peu exploitables (des probabilits infrieures 10 7) ou encore du manque de conance que lon attachait ces rsultats. La majeure partie de lanalyse du risque couvre laspect dfaillance des composants du systme. Ces dfaillances, en tant que phnomnes dangereux, peuvent mener des situations dangereuses dont on tudie la probabilit et la gravit du dommage induit. Un aspect fondamental dans cette tape est la diffrence entre les analyses couvrant le systme (matriels et logiciels tant pris comme des composants) et les analyses propres au logiciel. Il est en effet impossible dobtenir des donnes quantitatives ou qualitatives sur des probabilits de dfaillance des composants logiciels qui soient utilisables pour un autre projet. Cet aspect qui nest pas abord au niveau des normes mdicales, est pourtant dj largement abord dans des domaines comme laronautique. La mthode conseille pour pallier cette mconnaissance, est de donner au sous-systme logiciel un niveau dintgrit (ou SIL, Software Integrity Level) correspondant un niveau de criticit des fonctions que le sous-systme doit raliser. Ainsi, daprs la norme logicielle aronautique DO178B/ED-12 Revision B (1992), un logiciel dont un comportement anormal contribuerait la dfaillance dune fonction du systme, et qui conduirait une dfaillance catastrophique pour lavion, est de niveau A le plus lev (pour un effet nul, le niveau E est attribu). Il ne sagit pas de laffectation dun niveau de risque, car ce niveau ne peut tre rduit, mais dun niveau qui impliquera que le fabricant applique des mthodes de dveloppement plus ou moins contraignantes. Ainsi, plutt que danalyser le logiciel lui mme en tant que produit, cette norme propose de contraindre la production de ce logiciel. Cette philosophie, propre au logiciel, se retrouve dans de nombreux domaines, et notamment dans une norme gnrique sur les dispositifs lectriques programmables, la IEC 61508 (2001). Ainsi, pour le logiciel, les tapes suivantes ne peuvent sappliquer directement, sauf si lon considre le logiciel comme un composant au mme titre quun composant lectronique.

1.4.4 valuation du risque

Lactivit dvaluation du risque concerne les prises de dcisions dacceptabilit du risque voque prcdemment (cf. 1.2.2.3). Une premire tape de lvaluation consiste isoler les dangers dont le risque estim nest pas sufsamment faible. Le tableau de la gure 1.1 permet de choisir dans un premier temps les risques que lon accepte en raison de leur faible niveau. Par exemple, il est possible de dcider que seuls les dangers induisant un risque de niveau T ou L ne ncessiteront pas de rduction. En ltat actuel des choses, la dtermination dun niveau de risque acceptable est ralise en utilisant les niveaux de risque acceptable de dispositifs mdicaux dj en service et ceux dactes mdicaux raliss sans lintervention dun robot. La deuxime tape consiste en ltude des risques de niveau trop lev, mais dont la rduction nest pas ralisable. Dans cette situation, il convient de rduire le risque au niveau aussi faible que raisonnablement praticable. Ce concept, intitul ALARP (As Low As Reasonably Practicable), exprime la ncessit de rduire au maximum le risque dans la limite des

38

Scurit des systmes de la robotique de service

Probabilit doccurrence

Zone intolrable Zone ALARP

Protection

Zone largement acceptable

Prvention

Gravit du dommage

F IG . 1.4 Exemple de diagramme des niveaux dacceptabilit du risque et de la zone ALARP moyens techniques et conomiques disponibles (cf. gure 1.4). La rduction du risque peut tre ralise en utilisant deux techniques illustres sur cette gure. Tout dabord, la probabilit doccurrence du dommage peut tre rduite, ce qui est not comme la prvention. Puis, la gravit du dommage peut tre rduite grce des techniques de protection. Une fois le risque ramen en zone ALARP, la problmatique risque/bnce se pose. La gure 1.5 illustre ce principe pour la zone dite tolrable qui nest quune vision diffrente de la zone ALARP de la gure 1.4. Cette balance entre risques et bnces, est sans doute la notion la plus controverse du processus de gestion des risques, puisquelle se base sur des concepts lis aux valeurs de la socit concerne. En effet, comme cela a t prsent en partie 1.2.2.3, le risque est accept dans un contexte donn, bas sur des valeurs courantes de notre socit. Ce qui nest pas explicite dans ces normes, est quun risque est acceptable dune part parce quil se situe dans une limite comparable avec dautres systmes, mais surtout parce que la socit est prte laccepter au regard des bnces quelle peut en tirer. Ainsi, mme aprs avoir dtermin quun risque ntait pas acceptable, et quil est impossible de le rduire pour des raisons techniques ou conomiques, il est toujours possible de dcider que lon prendra le risque en raison du contexte. Le niveau du risque acceptable est alors modi (et non le niveau du risque lui-mme). Pour exprimer le fait quun risque non acceptable au dpart, puisse tre pris par la suite, la notion de risque tolrable est parfois utilise. Dans la gure 1.5, on retrouve cette notion de tolrance lorsquune dcision doit tre prise. Ce principe est plus largement abord dans un rapport de la HSE (2001a). Lexemple de lhpatite B illustre parfaitement la problmatique de la balance entre risques et bnces. En effet, suite une campagne de vaccination contre lhpatite B en France (vaccin ayant fait lobjet dun processus de gestion des risques), plusieurs patients se sont retourns contre des fabricants de ce vaccin pour des cas deffets secondaires (et en 2002, contre ltat franais). Lensemble des patients affects par ses effets a donc dnonc le niveau de risque

1.4 Moyens : la gestion du risque

39

Rgion inacceptable

Le risque ne peut tre justifi sauf dans des circonstances extraordinaires

Rgion tolrable Les risques sont pris seulement si lon en retire un bnfice

Tolrable seulement si la rduction des risques est impossible ou si les cots seraient disproportionns par rapport lamlioration
Plus le risque augmente et plus les cots pour le rduire augmentent. Ce concept de proportion est illustr par le triangle

Le risque doit rester ce niveau

Rgion gnralement acceptable

Risque ngligeable

F IG . 1.5 Illustration de lacceptabilit du risque en fonction du cot, gure tire de HSE (1999) du vaccin en le jugeant inacceptable. Ltat, reprsent par lAgence Franaise de Scurit Sanitaire des Produits de Sant (lAFSSAPS), a alors dcid en septembre 1998, dinterrompre la campagne de vaccination collective en milieu scolaire et de complter lvaluation du risque en initiant des tudes et de rvaluer rgulirement les donnes disponibles (Communiqu de presse du 6 mars 2000, Ministre de lemploi et de la solidarit, Secrtariat dtat la Sant et lAction Sociale6 ). Dans le domaine des dispositifs mdicaux - dont font partie les robots mdicaux - la problmatique intgre dautres lments. Ces robots qui assistent aujourdhui les spcialistes ralisent des tches qui existaient auparavant. Ainsi lacceptabilit du risque peut se mesurer en comparant lacte mdical utilisant le robot, avec lacte sans le robot. Une tude sur plusieurs annes prsente par Bargar et al. (1998), compare avec des mtriques du domaine mdical les rsultats des oprations du remplacement de la hanche par Robodoc avec ceux dune quipe donne. Les performances du robot sont ainsi values et les risques encourus sont valids par la mesure des dommages sur les patients (en loccurrence identiques). De plus, les ingnieurs qui ont dvelopp le premier systme de Robodoc, ont choisi de prendre le risque dadapter un robot industriel pour lapplication mdicale. En effet, la rigidit, la vitesse et lespace de travail du robot industriel adapt, constituaient des sources potentielles de dommage, et induisaient ainsi un risque. Une autre comparaison entre un robot chirurgical et une quipe mdicale classique est prsente par Reichenspurner et al. (2000). De la mme manire, les performances sont values et les dommages sont exposs en terme de temps de rcupration, de complications post-opratoires, et de mortalit (nulle dans les deux cas sur plusieurs centaines doprations). Pour les futures applications robotiques qui permettront deffectuer
6

Document disponible sur http ://www.sante.gouv.fr/htm/pointsur/vaccins/31_000306.htm

40

Scurit des systmes de la robotique de service

des tches jusqualors impossibles, la problmatique de lacceptabilit sera plus complexe. En effet, labsence de comparaison avec des oprations uniquement ralises par lhumain, empche de xer les rgles de risque acceptable. Le processus sera alors le mme que pour des nouvelles oprations chirurgicales ; cest le corps mdical et la socit qui prendront la dcision de faire les essais cliniques et daccepter un risque non nul.

1.4.5 Matrise du risque

La matrise du risque concerne les tapes au cours desquelles sont slectionns les moyens pour rduire les risques. Du point de vue de la scurit, il est courant de ne parler que de rduction du risque. Selon la dnition du risque (cf. 1.2.2), il est possible soit de rduire la gravit du dommage, on parle alors de mcanismes de protection, soit de rduire la probabilit doccurrence du dommage, ce qui correspond aux actions de prvention. Ce concept est illustr sur la gure 1.4. Cette tape interagit avec le processus de dveloppement et les moyens choisis ne doivent pas dgrader les spcications du systme. Un exemple classique est le temps dexcution dun logiciel qui peut considrablement augmenter par lintroduction de procdures ddies la scurit et donc conduire au dbordement des chances temporelles critiques pour un systme temps rel. Un des enjeux de la matrise du risque est donc de garantir un respect des fonctions du systme tout en proposant des mesures pour la rduction du risque. La matrise du risque concerne principalement les activits suivantes : Modication des interfaces : les interfaces humains-machines sont modies an de matriser le risque. Elles concernent les interfaces humain-ordinateurs, les botiers de commande des robots mais aussi certaines parties du robot lui-mme qui interagissent avec le patient ou les spcialistes. Il existe de nombreux travaux ddis exclusivement ce domaine qui relve de diffrentes disciplines, et lattitude gnrale des ingnieurs de dveloppement consiste suivre des guides sous forme de rgles de conception. La partie 1.6.2.4 aborde cette problmatique en se restreignant aux robots mdicaux. Modication de lutilisation : lallocation des tches est modie ainsi que les procdures dutilisation, les formations ou la rdaction des diffrents guides accompagnant le dispositif. Modication de la conception : certaines solutions pour rduire le risque ncessitent de modier la conception mme du dispositif. On peut dores et dj citer les techniques de tolrance aux fautes fournissant des mcanismes de protection, ou les guides de dveloppement bass sur le principe de prvention des risques de dfaillance induites par des fautes de conception (Geffroy et Motet, 2002). Une synthse de lensemble de ces moyens techniques pour la robotique mdicale est prsente dans la partie 1.6. Dans les sections suivantes sont prsentes des techniques pour mettre en uvre lanalyse et la matrise du risque. Nous ne prsenterons pas de techniques dvaluation du risque car il est trs difcile de trouver dans la littrature et plus particulirement dans le domaine mdical

1.5 Techniques utilises pour lanalyse du risque

41

des travaux sur ce sujet. Lensemble des concepts dvaluation du risque sont fortement lis aux valeurs de la socit, et en font un domaine o les techniques nont pas encore leur place.

1.5

Techniques utilises pour lanalyse du risque

Les moyens prsents en section 1.4, fournissent une approche globale pour apprhender la gestion du risque. La mise en uvre de ces moyens peut se faire par lutilisation de techniques spciques chacune des activits de la gestion du risque. Ainsi, pour lanalyse du risque, il est souvent fait mention de mthodes analytiques qui permettent au concepteur de comprendre comment les phnomnes dangereux, les situations dangereuses et les vnements dommageables peuvent mener des accidents, et destimer les probabilits an dannuler ou de rduire les effets. Comme nous lavons vu prcdemment, lanalyse du risque concerne trois points : dnition du domaine dapplication, identication du phnomne dangereux (et/ou de la situation dangereuse) et estimation du risque. Ces trois volets correspondent en gnral trois activits que lon excute de manire itrative. Il nexiste pas de technique couvrant globalement la totalit de ces aspects et, la plupart du temps, plusieurs techniques sont utilises pour chacun deux. Le but de la multiplication de ces techniques est aussi datteindre un certain niveau dexhaustivit danalyse (qui tout comme la scurit est relatif !). Les techniques les plus utilises en robotique industrielle sont prsentes par Dhillon et Anude (1993). Parmi ces techniques, Dhillon et Fashandi (1997) retiennent que lAMDEC7 (Analyse des Modes de Dfaillance et de leurs Effets et de leur Criticit) et lanalyse des arbres de fautes8 semblent tre les plus appropries pour les systmes robotiques. Bien que les exemples dutilisation de ces mthodes (Khodabandehloo, 1996; Walker et Cavallero, 1996) soient orients vers des robots industriels, elles sont largement applicables aux robots mdicaux (Guiochet et al., 2001; Guiochet et Vilchis, 2002; Urbain et Guiochet, 2001). Ces deux techniques souvent utilises conjointement, sont aussi prconises pour lanalyse du risque dans le domaine mdical (ISO 14971, 2000). Ces mthodes sont particulirement adaptes aux dispositifs mdicaux car il est possible dinclure certains aspects lis aux facteurs humains comme lerreur humaine, et aussi de mlanger les diffrents domaines que sont la mcanique, llectronique, et linformatique, prsents dans un systme robotique. La gure 1.7 illustre lutilisation dun tableau pour lAMDEC en ne prenant en compte quun des modes de dfaillance pour le processeur du contrleur de robot tl-chographe TER (Vilchis et al., 2001a). Il existe en effet dautres modes de dfaillance de ce composant comme la coupure (toutes les sorties nulles) qui peut tre due une chute de tension, ou encore le cas o les sorties deviennent alatoires du fait dun dpassement de mmoire ou dun pointeur fou du programme. Le mode de dfaillance analys sur cet exemple est un
7 8

Ou FMECA, Failure Mode, Effects and Critically Analysis Ou FTA, Fault Tree Analysis

42

Scurit des systmes de la robotique de service

Pression exerce par la sonde sur la patiente trop importante

OU
Commande fausse Dfaillance processeur du contrleur
A1

Multiplicateur Bloqu

Mauvais branchement tuyaux dair

Dfaillance convertisseurs I/P

Dfaillance carte sorties

OU

Cables Coincs

Modle du patient erron

B1

Modle gomtrique inverse erron

B3

Information axe/force fausse

Consigne fausse
B4

Modle du robot erron

Lgende
Erreur de lecture consigne

Erreur loi de commande

B5

vnement de base ne ncessitant aucun dveloppement supplmentaire vnement rsultant dune combinaison dvnements Renvoi vers un autre arbre de faures Porte logique OU

B2

OU

Modle du patient erron

B1

OU

Erreur de lecture consigne

Erreur du spcialiste

Erreur de transmission

F IG . 1.6 Exemple darbre de fautes

Svrit

Processeur Fig du contrleur de robot

Interblocage du programme ou du systme dexploitation

A. Envoie commande constante B. Mouvement bloqu en un point

A. Systme externe type watchdog H B. Rinitialisation et Alerte utilisateur

F IG . 1.7 Exemple de tableau de lAMDEC

Risque

Composant

Cause

Occurrence

Modes de dfaillance

A. Effet local B. Effet sur le systme

Evaluation du risque

A. Moyens de dtection possibles B. Solutions

1.6 Techniques utilises pour la matrise du risque

43

processeur bloqu dans un tat quelconque et ne donnant plus signe dactivit ; on utilise alors le terme de g. La cause principale identie est linterblocage entre tches, ou une mauvaise gestion des ressources du systme dexploitation. On exprime galement les effets, ainsi quune estimation du risque suivant les niveaux prsents dans le tableau de la gure 1.1. La solution envisage pour matriser ce risque est lutilisation dun systme de protection du type watchdog ou chien de garde prsent ultrieurement. La gure 1.6 reprsente un arbre de fautes pour lvnement racine Pression exerce trop importante dans le cadre dun robot pour lchographie. Certaines particularits du systme, comme lutilisation de nouveaux actionneurs, les muscles articiels (Tondu et Lopez, 2000) fonctionnant avec de lair comprim, introduisent des vnements dommageables lis lutilisation dair (mauvais branchements des tuyaux dair, dfaillance des convertisseurs Intensit / Pression, etc.). Pour chaque technique danalyse du risque, les solutions proposes pour rduire les risques, prsentes par exemple dans la dernire colonne du tableau de lAMDEC, seront par la suite slectionnes sil savre ncessaire et ralisable de les implanter. Ceci correspond ltape dvaluation du risque. Parmi ces solutions se trouvent un grand nombre de moyens techniques, dont nous proposons une synthse dans la section suivante.

1.6

Techniques utilises pour la matrise du risque

Les nouvelles applications de la robotique ont souvent t ralises partir de robots industriels, notamment pour les robots mdicaux comme le robot chographe Hippocrate (Degoulange et al., 1998) ou le robot chirurgical Robodoc (Cain et al., 1993). Dans ce contexte les solutions techniques permettant daugmenter la scurit des robots ont t conserves voire amliores. Les spcicits des tches de la robotique mdicale ont cependant amen les concepteurs des solutions propres chaque application (robotique de rhabilitation, robotique chirurgicale, etc.). Sur la base de ce constat, Davies (1993) prsente des solutions technologiques et des principes sur lesquels peuvent se baser les concepteurs de tels systmes. De la mme manire, cette partie prsente les principales solutions matrielles et logicielles qui peuvent tre utilises lors de ltape de matrise du risque au sein du processus de gestion du risque. Ces solutions sont issues des exigences non fonctionnelles du systme et de lanalyse du risque. Elles dcoulent donc dun processus danalyse et ne peuvent tre directement implantes comme garanties de scurit. Par exemple, an de rduire le risque de choc entre un robot et un humain, Ikuta et Ishii (2003) introduisent un indice de danger calcul par le rapport entre la force possible produite par le robot et la force maximale que tolre un humain. En se basant sur lidentication et la quantication de ce danger, ils propose alors des solutions de conception et de contrle permettant de rduire ce danger quivalentes celle prsente ici. Les solutions technologiques prsentes dans cette section sont donc des patrons (ou patterns en anglais) de scurit, puisquils reprsentent des solutions connues des problmes

44

Scurit des systmes de la robotique de service

particuliers dans un contexte9 . Nous proposons de les utiliser une fois que les risques ont t estims et valus. Les autres moyens pour la matrise du risque comme la maintenance, les modications de conception, les procdures dutilisation, la formation ou la documentation, ne sont pas voqus car il est difcile den effectuer une synthse et encore plus un catalogue.

1.6.1 Conception matrielle

1.6.1.1 Architectures mcaniques et matriaux utiliss

Larchitecture du robot dpend des exigences fonctionnelles mais aussi de certaines exigences de scurit spciques au milieu o le robot volue. La notion de scurit intrinsque est parfois utilise lorsque la structure mme du robot possde la particularit de ne pas prsenter de phnomnes dangereux (pas de bords tranchants, la vitesse des mouvements ainsi que lamplitude sont limits, etc.). Ainsi, loppos dHIPPOCRATE, un bras manipulateur pour lchographie (Degoulange et al., 1998), le projet TER (Vilchis et al., 2001a,b) propose une structure dite parallle restreignant lamplitude, la force et la vitesse des mouvements. Cette structure permet notamment en cas de coupure dalimentation en air, de nexercer plus aucune pression sur la patiente (la notion darrt durgence est expose plus en dtail dans la partie 1.6.1.2). Il est vident que cest en majorit lanalyse de la tche (incluant lanalyse du geste mdico-chirurgical pour les robots mdicaux) qui guide les choix darchitecture, et dans beaucoup de cas cest une architecture srie comme les bras manipulateurs, qui a t choisie. Parmi les raisons de ces choix on peut citer le fait que beaucoup de robots mdicaux ont t des robots industriels adapts et modis, et aussi le fait quil est plus difcile de commander des structures parallles. Il est possible dimaginer que les applications de demain seront libres de ces contraintes, et que certains robots gagneront changer darchitecture. Les robots mdicaux sont construits aujourdhui pour intervenir sur de trs petits espaces de travail, et des choix spciques au niveau de larchitecture contribuent respecter cette contrainte. Ainsi, pour une tche trs spcialise, il est conseill de rduire le nombre darticulations. Le robot neuro-chirurgical Minerva (Glauser et al., 1993) possde seulement trois articulations (une translation et deux rotations). A loppos un robot multitche, travaillant dans un milieu hostile, possdera un plus grand nombre de degrs de libert, ventuellement redondants. En complment de cette restriction, certains robots sont quips de butes mcaniques trs contraignantes (la rotation de Minerva est limite 30 degrs). De plus, certains robots sont entours de matriaux viscolastiques comme celui de Morita et Sugano (1997b). La gravit du choc est alors diminue par labsorption de lnergie cintique ; le systme enregistre le niveau du choc et adapte alors sa raction.
Cette dnition de patron nest pas universelle, et le lecteur pourra se reporter au rapport de Manhes (1998) pour une synthse sur ce sujet.
9

1.6 Techniques utilises pour la matrise du risque

45

1.6.1.2

Scurit autour des actionneurs

Prcision des mouvements articulaires Il est important de noter que la prcision du mouvement articulaire est un critre de performance tabli dans les exigences fonctionnelles, et quil nest pris en compte dans une analyse de la scurit que si la dgradation de cette performance consititue un phnomne dangereux pour lutilisateur. Dans une analyse des risques, cest principalement cette dfaillance qui est traite. Il existe aujourdhui un ensemble dactionneurs (principalement des moteurs lectriques AC, DC, et pas pas), qui ont des modes et des taux de dfaillances connus et gnralement fournis par les fabricants. La solution la plus commune ces dfaillances est un programme de maintenance prventive. Cette dernire est dnie comme lensemble des actions priodiques qui interviennent avant loccurrence des dfaillances. Elle correspond aux procdures de dtections, inspections, entretiens, calibrages, tests et ajustages (Worthington et Burns, 1988). En robotique mdicale, le choix des concepteurs sest principalement port sur les moteurs pas pas, plus prcis que les autres moteurs. En dehors des modes de dfaillances des actionneurs, un des phnomnes qui dgrade la prcision au niveau de larticulation est le backlash (Klafter et al., 1989) (contre-mouvement d au jeu des articulations sur un changement de sens). Ce mode est rduit par le principe de transmission harmonique10 (roues en forme dellipses). Dans le cadre du robot neuro-chirurgical Minerva, lquipe de recherche a mis au point une solution drive de ce principe (Glauser et al., 1993). Arrt durgence Les mcanismes darrt durgence prsents sur les robots industriels sont utiliss sous la mme forme pour la robotique mdicale. Ils constituent des dispositifs de protection permettant de matrise lnergie du systme. Le principe dinterrupteur homme-mort ou DMS11 , o les mouvements du robot ne sont autoriss que si loprateur maintient un contact, est implant sur des robots mdicaux comme Acrobot (robot chirurgical orthopdique prsent par Davies et al. (1997)) sous forme de gchette. Il peut aussi tre sous forme de pdale comme sur le robot chographe Hippocrate (Degoulange et al., 1998). Comme pour les robots industriels, lappellation arrt durgence nest valide que si le circuit est dit g (INRS, 1998), ce qui veut dire entirement matriel, sans aucun traitement informatique. Ces systmes sont gnralement doubls par des boutons poussoirs directement relis aux sources dnergie. Une fois larrt durgence activ, diffrents systmes de blocage des articulations peuvent tre intgrs. Wadegaonkar, Sunnapwar, et Modak (1996) utilisent des systmes de freins dbrayables lectromagntiques que lon trouve sur des robots industriels commercialiss, comme le Mitsubishi MoveMaster (bras manipulateur 6 axes), coupls des moteurs lectriques. Il existe aussi des systmes de freins utiliss par Ng et Tan (1996), qui senclenchent
10 11

ou harmonic drive, produit dune division de Quincy Technologies, Inc., USA. Dead Man Switch

46

Scurit des systmes de la robotique de service

lors des coupures dnergie. Le robot Wendy (Morita, Iwata, et Sugano, 1999) possde un systme fonctionnant sans logiciel qui permet denclencher des freins lectromagntiques si le bras dpasse une vitesse limite. Delnondedieu (1997) prsente le mcanisme de plusieurs systmes, notamment le concept de Transmission Continment Variable utilis par Cobot12 , et le systme de roue libre utilis par le robot Padyc (Troccaz et Delnondedieu, 1996). Ce systme est mis en uvre par un ensemble de billes qui se coincent dans des cavits, bloquant alors seulement dans un sens la rotation dune bague extrieure. Prvu la base pour une restriction de lespace de travail du robot (le geste chirurgical est alors contraint), il est possible de lutiliser pour un blocage en cas darrt durgence. Il ne convient cependant pas toujours dutiliser des systmes de blocage des articulations. En effet en cas de panne, larrt peut ne pas tre systmatique, il pourrait mme savrer dangereux dans certaines circonstances. Certains sites robotiss utilisent ainsi des systmes hydrauliques secondaires pour des robots manipulant des charges trs lourdes. En cas de dfaillance cette installation prend le relais et redescend doucement le bras charg sur la plateforme robotique. Cette utilisation reste tout de mme rare et concerne le milieu industriel. Dans le cas des robots mdicaux, cest une problmatique complexe qui dpend entirement de lapplication. Le choix du type darrt durgence est guid par les tats dans lesquels on peut placer le systme. Le cas le plus classique est celui o toute nergie est retire lors de lenclenchement de larrt durgence. Pour un robot chirurgical, une des solution est de le ger (par exemple avec des freins lectromagntiques) dans sa position et de permettre au spcialiste de venir le retirer (en ayant un mode dbray par exemple) et de terminer lopration sans le robot. Cest lhumain qui doit intervenir pour cette situation extrme, il ne doit donc pas exister de mouvements de recul du robot suite un traitement informatique. Il existe certaines applications o le robot se place dans un tat dit de pause suite une dfaillance dtecte par le logiciel. Cet tat ne peut tre compar un arrt durgence et il est trs important de faire la distinction. Dans le cas du robot tl-chographe TER, deux choix de conception ont permis dadopter un arrt durgence sans blocage ou frein. La sonde, maintenue par quatre cbles, repose sur le ventre de la patiente, et ces cbles sont actionns par des muscles articiels de McKibben (Tondu et Lopez, 2000) qui se rtractent lorsque la pression dair augmente. Ils permettent ainsi de dplacer lanneau o se trouve la sonde. Le fait de couper toute alimentation dair, dtend les quatre muscles, et la pression sur le ventre de la patiente devient nulle. Dans ce cas particulier larrt durgence est trs simple, et place directement le systme dans un tat sr. Les corrlations qui existent entre les choix darchitecture, le choix des actionneurs et la scurit, sont trs importantes et encore ltude du fait de la difcult de trouver de nouveaux actionneurs et de nouvelles architectures. Cest un thme quil conviendrait dintroduire au niveau de la scurit.
12

http ://othello.mech.nwu.edu/ peshkin/cobot/index.html

1.6 Techniques utilises pour la matrise du risque

47

Compliance passive Les robots industriels sont en gnral lourds, puissants et programms pour effectuer une tche sans obstacle. Ces caractristiques conduisent identier lnergie cintique comme tant un de principaux phnomnes dangereux. Ce phnomne est inacceptable dans le cadre de la robotique de service qui exige uidit, lgret et souplesse. Cette dernire caractristique, proche de lhumain, est un des enjeux les plus importants en robotique de service. Le contrle dun mouvement sous de fortes contraintes (comme un contact permanent avec lhomme) a amen les fabricants dvelopper des contrleurs de robot combinant un contrle en position et en force. La compliance active13 est ce type de contrle par lutilisation dalgorithmes implants dans le contrleur, alors que la stratgie de la compliance passive, celle qui nous intresse ici, est dnie par lutilisation de structures matrielles montes sur le poignet du robot (Wu, 1988). Il est cependant possible dtendre cette dnition lensemble des articulations dun robot. De tels mcanismes apportent une souplesse au poignet ou dautres articulations du robot. Lutilisation de poignets compliants permet de se rapprocher de la souplesse de lhomme et marque une premire tape en ce sens. Le MIA (Mechanical Impedance Adjuster) prsent dans larticle de Morita et Sugano (1997a), se compose principalement dun ajusteur dimpdance (an de rgler la souplesse) et dun entranement darticulation (pour transmettre le mouvement). La compliance consiste rgler un ressort directement joint laxe de larticulation. La compliance passive peut se faire aujourdhui sans structure matrielle monte sur le poignet. En effet, il est possible dobtenir une compliance naturelle de lactionneur. Les muscles articiels dcrits par Tondu et Lopez (2000) offrent une compliance trs comparable aux articulations humaines. Ils contribuent ainsi la scurit intrinsque du robot. Ce sont des actionneurs pneumatiques qui se rtractent lorsque la pression augmente. Ils ont t utiliss pour le dveloppement du robot tl-chographe TER (Vilchis et al., 2001a) mais aussi dans le cadre de bras manipulateurs comme le robot ISAC14 pour la rhabilitation des personnes ges ou handicapes. 1.6.1.3 Scurit par la redondance des composants

La redondance structurelle consiste multiplier les composants matriels du robot comme les actionneurs, les capteurs, les cartes contrleur, etc. Les donnes produites par ces composants peuvent ensuite tre compares et certains composants carts en raison dune dfaillance dtecte. Cette technique de protection, utilise dans les systmes scurit critique comme lavionique est aujourdhui employe en robotique (Rodrigues, 1993; Baerveldt, 1992a). Par exemple, le robot chirurgical Robodoc possde pour chaque articulation deux codeurs incrmentaux (donnes de position), et les donnes sont compares tout instant par
Compliance est un anglicisme que lon trouve parfois traduit par complaisance, ou plus simplement par souplesse 14 Intelligent Soft Arm Control, http ://shogun.vuse.vanderbilt.edu/CIS/IRL/Projects/isaac.html
13

48

Scurit des systmes de la robotique de service

deux processeurs (Cain et al., 1993). La redondance structurelle est la base une technique pour augmenter la abilit : on prolonge la fonction du systme mme si un des composants est dfaillant. Mais dans le cas o la dfaillance du composant est critique en terme de scurit, la redondance devient alors une technique de scurit. Il existe un autre type de redondance, la redondance fonctionnelle, qui permet deffectuer une mme fonction mais avec une conception diffrente. Ainsi, il est possible de retrouver une donne de vitesse avec des capteurs de vitesse mais aussi depuis des donnes de position et dacclration du mouvement. La redondance peut aussi seffectuer un niveau beaucoup plus lev comme lensemble dun contrleur de robot. Laible et al. (2001) prsentent une application dun patron de scurit, lutilisation dun double canal15 , un robot chirurgical. Linformation depuis lutilisateur transite par deux canaux symtriques mais de conception diffrente. Le terme de canal exprime le fait que les donnes passent par un ensemble de composants o elles sont traites. Ainsi les valeurs de la position du robot sont compares tout au long du calcul (en utilisant une mmoire partage entre les deux canaux), avant dtre envoyes aux moteurs. Tout comme la redondance structurelle, cette technique est en gnral limite par les cots, lespace, la consommation dnergie et la complexit du systme. 1.6.1.4 Scurit par la dtection de contacts avec lhumain

Le principal risque pour la robotique industrielle est la prsence de lhumain dans la zone de travail. LINRS (1998) prsente lensemble des moyens de dtection possible de lhumain dans la zone de travail, proximit et au contact. Ces technologies (cellules photolectriques, champs magntiques, planchers, dtecteurs volumtriques, antennes, peaux sensibles , etc.) peuvent tre utilises pour la robotique de service an de modier le comportement du robot. Mais pour beaucoup dapplications de robotique de service, la tche seffectue en collaboration avec lhumain dans la zone de travail. En dehors des dangers lis au domaine mdical (nature biologique, lis lenvironnement, etc.) et de ceux qui ne prsentent pas de dtection possible, on peut identier le danger principal qui est un dplacement du robot provoquant un dommage humain. La source est donc dorigine physique et il faut, pour dtecter ce danger, des capteurs de force sufsamment prcis. Au niveau de la structure mme du robot il est possible dutiliser des matriaux couvrant le robot et permettant de mesurer la force de contact ou la pression exerce en tout point (Yamada et al., 1996). Les capteurs deffort permettent aussi de dtecter une pression trop importante sur le patient et de modier ltat du robot. Ainsi, en cas de dpassement dune force maximale mesure sur leffecteur, le robot chographe Hippocrate (Degoulange et al., 1998), se dbraye et le spcialiste peut dplacer manuellement le bras pour le mettre dans une position non dangereuse. De nombreux systmes robotiques utilisent aujourdhui le retour deffort en tant que variable de rtroaction en associant leffecteur ou aux articulations des capteurs de force. Bien que le retour deffort soit une technique tudie depuis plusieurs annes, elle est encore peu prsente en robotique mdicale, du fait notam15

Dual channel pattern prsent par Douglass (1998)

1.6 Techniques utilises pour la matrise du risque

49

ment que le calcul de cette commande qualie dhybride est complexe et que les donnes des capteurs de force sont difciles interprter en termes de dommages sur lhomme. Dans le cas dun robot chirurgical, il est trs difcile lors dune opration de mesurer lensemble des efforts sur loutil chirurgical. Les solutions que nous venons de prsenter cherchent mettre en place des moyens de rduction des risques de dommages induits par la force ou lnergie cintique. Rappelons que nous avons galement propos des moyens de rduction de ces dommages bass sur la souplesse (compliance) des actionneurs. Pour ces raisons, la gnration de mouvements compliants sans recours un calcul de force apparat comme une solution davenir pour un geste mdical plus sr. Par ailleurs, notons que limagerie mdicale, utilise jusqualors des ns de diagnostic, de localisation et en suivi postopratoire est aujourdhui entirement intgre et utilise lors de lopration avec un robot mdical (Smith-Guerin, 2000, p20-25).

1.6.2 Conception logicielle

Les contrleurs de robots ont aujourdhui atteint la complexit de nombreux systmes informatiss. Pour les directives europennes exposes dans la section 1.7, le logiciel est considr comme un des lments du dispositif mdical, et doit tre trait de la mme manire que les autres composants. Il ny a pas encore de norme ddie au logiciel mdical qui serait analogue la DO178B/ED-12 Revision B (1992) pour le logiciel avionique. La seule recommandation que lon peut extraire des directives est de suivre un systme qualit de type ISO 9000-3 (1997), appliqu au logiciel mdical (Cosgriff, 1994). Ces recommandations concernent surtout la manire dont le logiciel doit tre conu. Dans cette partie nous ne traiterons pas cet aspect, nous tudierons les solutions technologiques logicielles permettant la rduction du risque. Ainsi nous ne nous intresserons pas au vaste domaine des techniques de sret de fonctionnement appliques au logiciel. De plus, en se contraignant au domaine de la robotique de service, il existe tout de mme de nombreuses solutions sans cesse en volution. En consquence, cette section prsente des pointeurs vers les lments de recherche majeurs permettant de rduire certains risques. 1.6.2.1 Limitations logicielles des performances du robot

Le principe de limitation logicielle de performances est utilis dans la robotique industrielle. Par exemple, lorsquun oprateur doit effectuer une tche de maintenance ou programmer une nouvelle tche robotique, la vitesse des mouvements peut tre limite 20 cm/s. Cette valeur que lon peut retrouver dans plusieurs tudes et dans certaines normes robotiques industrielles (comme par exemple la norme amricaine ANSI/RIA R15.06-1999) ne convient pas toutes les applications de la robotique de service. Sa valeur a t xe en fonction du temps de rponse de lhumain face une dfaillance. Pour des applications de robotique mdicale cette valeur doit tre adapte en fonction de lapplication et elle se situe videmment

50

Scurit des systmes de la robotique de service

bien en dessous de 20cm/s. Dans le cadre de la tlopration, le robot suit les mouvements du spcialiste et doit pouvoir bloquer les mouvements trop rapides ou en dehors de la zone de travail. Pour ces applications, le robot ne peut aller plus vite que le spcialiste car il suit les mouvements de loprateur, mais pour les robots autonomes comme Robodoc, il est possible deffectuer un geste plus rapide. Il nexiste aujourdhui encore aucune information ou aucune norme relative la vitesse de dplacement dun robot mdical. Il semble pour linstant difcile de dnir une vitesse commune des oprations aussi diffrentes quune chirurgie invasise ou un examen chographique. 1.6.2.2 Scurit lors de la mise sous tension

La scurit attache aux tapes de mise sous tension et darrt des systmes robotiques est bien matrise pour les robots industriels. Dans le cas des robots mdicaux il est important de spcier ltape de prparation du patient lors de la mise en route. Dune part, la squence de mise en route doit intgrer le placement du patient tout en garantissant la scurit de celui-ci. Et dautre part la prparation du patient peut avoir des effets sur la scurit lors de lopration. La conception du contrleur doit prendre en compte cette donne ds les spcications. Les tapes essentielles des vrications la mise en route dun robot mdical concernent les tests de la mmoire et du processeur par le BIOS, les tests du checksum du code excutable et des chiers utiliss, les tests interactifs des capteurs et des actionneurs, et les tests des circuits darrt (Laible et al., 2001). Dans le cadre du robot TER, la mise sous tension est effectue en premier avec tous les tests relatifs aux composants lectroniques. Une fois ces tests valids par lutilisateur, la pression dalimentation en air des actionneurs est commande. Dune manire gnrale, si le systme peut tre divis en blocs comportant des alimentations spares (et dorigines diffrentes comme llectricit et lair), la mise sous alimentation doit se faire de manire squentielle. 1.6.2.3 Surveillance du systme

Les mcanismes de surveillance doivent en gnral (Leveson, 1995) : dtecter les problmes de trs bas niveau pouvant induire des situations dangereuses, tre indpendants des dispositifs quils surveillent, augmenter le moins possible la complexit du systme, demander une maintenance simple. Largement rpandue aujourdhui, lutilisation de chiens de garde (watchdog) traite les modes de dfaillance comme celui de lexemple du processeur g (cf. section 1.5). Ce systme peut tre matriel ou logiciel. Il est en effet possible de concevoir une carte lectronique qui rinitialise le systme si ce dernier ne donne plus signe dactivit au bout dun certain temps. De manire analogue, il est possible de trouver le mme concept pour le logiciel. En effet, il existe aujourdhui des composants logiciels disponibles sur les plates-formes temps rel

1.6 Techniques utilises pour la matrise du risque

51

(comme VxWorks16 ), qui permettent de lancer une tche de plus haut niveau si le programme semble tre bloqu ou dpasse le temps imparti. Dans les deux cas, matriel ou logiciel, on vite un mode de dfaillance du contrleur de robot et, en choisissant la solution matrielle, on saffranchit des problmes lis au processeur. Cest un patron de scurit que lon peut retrouver dans de nombreux systmes et que Douglass (1999) modlise avec la notation oriente objet UML (Booch et al., 1999). En plus de cette surveillance dactivit, certains robots sont quips de modules de surveillance qui comparent et analysent toutes les entres/sorties et les tats du systme. Robodoc possde ainsi deux cartes contrleurs : une carte principale pour les aspects fonctionnels, une carte ddie la scurit qui compare les diffrentes donnes, analyse les messages, etc. Dune manire similaire, Baerveldt (1992b) expose un systme avec une carte principale, des cartes contrleurs pour chaque articulation, et une carte scurit divise elle-mme en deux modules : un module de contrle de la carte principale, et un module de contrle des cartes contrleurs des articulations. Les informations sont donc analyses et compares par diffrents modules. En cas de dtection de dfaillance, le processeur doit appliquer une politique de scurit qui peut tre le recouvrement dinformation (on effectue un retour en arrire sur les donnes sauvegardes), ou mme la rinitialisation du systme. Un patron de scurit regroupant lutilisation dun chien de garde et dun systme de surveillance de lexcution est prsent par Douglass (1999), sous lappellation Safety Executive Pattern. Dune ralisation plus simple, les contrleurs peuvent comparer et analyser les donnes provenant des capteurs (comme par exemple avec le principe de redondance analytique prsent par Visinsky et al. (1994)), et les ltrer avec diffrents algorithmes numriques (un des plus clbres tant le ltre de Kalman). Le systme garantit ainsi une cohrence de ses entres. 1.6.2.4 Conception des interfaces humain-machine

Bien que cette sous-partie soit place dans la section Conception logicielle, la conception des interfaces humain-machine ne peut tre rduite des moyens logiciels. En effet, depuis ltude de la forme et la couleur dun bouton darrt durgence jusqu la conception dune interface graphique, les tudes couvrent des systmes matriels et logiciels. Cependant, dans le cadre de la robotique de service et plus particulirement de la robotique mdicale, de nombreuses tudes sur les interfaces concernent des systmes informatiss. Les tudes effectues dans ce domaine ne peuvent se rsumer un paragraphe, et lon ne pourrait noncer ici lensemble des solutions techniques adoptes par les systmes robotiques. Cest un sujet qui relve de diffrentes disciplines, et qui se trouve au croisement de lanalyse des facteurs humains, des sciences cognitives et de la thorie des systmes ; le terme gnie cognitif parfois utilis, permet de regrouper cette multi-comptence. Ainsi, cette sous-section
16

Produit de Wind River Systems, Inc., http ://www.windriver.com

52

Scurit des systmes de la robotique de service

prsente quelques points importants des problmatiques et des travaux raliss autour des interfaces. Une sous branche importante de ce domaine est ltude des interactions humain-ordinateur. Dans le cadre de la robotique mdicale, les interfaces fournissent au spcialiste des informations sur ltat du systme mais surtout les donnes essentielles relatives la tche (par exemple une image pour une opration chirurgicale ou pour une chographie). En cela, la qualit des informations sur ltat du systme dlivres loprateur est une garantie de la bonne excution de la tche, et ainsi de la scurit. Le spcialiste utilisant un robot mdical conserve sa responsabilit de mdecin mais devient responsable du contrle de la tche, comme lest un oprateur pour un robot industriel. Plusieurs problmes se posent alors, et notamment lanalyse des erreurs humaines lies aux interfaces, les choix des messages dalerte, les informations afches, etc. Laspect cognitif de ces tudes tant complexe et loign des sciences de lingnieur, le choix est souvent fait de suivre des directives sous forme de listes de rgles de conception (Leveson, 1995, p.485-488), encore appeles bonnes pratiques . Cependant comme le soulignent Wright et al. (1994), ces moyens sont insufsants pour de nombreux systmes et plus particulirement pour les systmes innovants. Ils ne donnent pas la solution exacte au problme li lapplication mais une faon dorienter la solution, et ce titre ils ne garantissent pas la scurit du systme. Les interfaces suivent donc, comme pour tout composant du systme, un cycle de vie itratif avec notamment une tape danalyse du risque li aux facteurs humains. Laspect propre la robotique mdicale provient de leffecteur du robot qui entre en contact avec le patient, et du systme permettant au spcialiste de donner des consignes au systme robotique. Les tudes relatives ces deux aspects concernent principalement les fonctionnalits du systme. Par exemple un systme de vision en trois dimensions comme le robot da Vinci17 pour le spcialiste et un retour deffort de leffecteur sur le patient sont des fonctionnalits avances, mais ne concernent pas directement la scurit. Il est vident quun systme difcile piloter pour un spcialiste savrera dangereux pour le patient, mais nous considrons que cela fait partie des exigences du systme que le concepteur doit suivre. Les recherches trs techniques dans ce domaine ne sont pas directement relies des exigences de scurit, cest lors de lanalyse du risque que le concepteur peut dcider sil a besoin ou non de certaines fonctionnalits au regard de leur apport pour la scurit.

1.7

Assurance : la certication

La certication a pour but de fournir un client une garantie quun produit est conforme sa spcication. Dans notre cas, les spcications de scurit sont au centre du problme.
17

Intuitive Surgical Inc., USA, http ://www.intuitivesurgical.com

1.7 Assurance : la certication

53

1.7.1 Certication et risque

Bien quune analyse du risque ne puisse sufre un processus de certication, elle constitue nanmoins le cur des principales exigences actuelles en terme de certication. An dharmoniser et dassurer un haut niveau de scurit, trois directives europennes, 90/385/CEE (1990), 93/42/CEE (1993), et 98/79/CE (1998), couvrent lensemble des quipements mdicaux. Ces directives dnissent un dispositif rglementaire pour la certication (marquage CE obligatoire) et expriment les exigences essentielles de scurit. Il existe un niveau plus technique, un ensemble de normes ddies aux dispositifs mdicaux qui concernent des aspects plus applicatifs, et la manire de mettre en uvre les exigences des directives. Il est cependant important de noter que ds ces premires directives de trs haut niveau conceptuel, laccent est mis sur lanalyse du risque. La directive 93/42/CEE (1993) lexprime ainsi dans la premire des exigences essentielles : Les dispositifs mdicaux doivent tre conus et fabriqus de telle manire que leur utilisation ne compromette pas ltat clinique et la scurit des patients ni la scurit et la sant des utilisateurs,[...], tant entendu que les risques ventuels lis leur utilisation constituent des risques acceptables au regard du bienfait apport au client . Comme pour la dnition de la scurit, il ressort de cette directive une valeur relative de la prise de risque faisant rfrence la notion dacceptabilit. Ainsi, limportance des tapes danalyse et dvaluation du risque apparat clairement pour tout dispositif mdical. De plus, lors dun processus de certication, un organisme noti procdant lexamen de conception (le G-MED en France) doit pouvoir accder aux donnes et aux rsultats de lanalyse du risque.

1.7.2 Classication des dispositifs mdicaux

Le processus de certication fait appel plusieurs tapes entirement dpendantes de la classe laquelle appartient le dispositif. La classication se fait en fonction du type dinteraction avec le patient. On peut rsumer ces classes (93/42/CEE, 1993) : classe I : dispositifs non invasifs, classe IIa : dispositifs actifs changeant de lnergie, classe IIb : dispositifs actifs changeant de lnergie potentiellement dangereuse, classe III : dispositifs implantables ou dispositifs invasifs long terme. La plupart des robots mdicaux appartiennent la catgorie IIa et IIb. La classe III concerne les dispositifs en rapport avec le cur ou le systme nerveux, qui pour la plupart sont implants dans le corps humain (comme les pacemaker). Les robots chirurgicaux comme Robodoc appartiennent la classe IIb ainsi que les robots non invasifs mais utilisant une nergie ionisante (un robot chographe par exemple). Cette classication exprime un niveau dinteraction avec le patient sans prciser explicitement le niveau de risque correspondant. La notion de

54

Scurit des systmes de la robotique de service

dfaillance nest pas aborde dans cette classication. Il est intressant de noter que dans un domaine comme lavionique, la norme logicielle DO178B/ED-12 Revision B (1992) fait rfrence leffet de la dfaillance dun lment pour la classication (catastrophique, dangereux, majeur, mineur, aucun effet). Cette rfrence fait dfaut dans les systmes mdicaux o tout est centr sur lhumain et la proximit du dispositif, sans attribuer directement un niveau de risque chaque classe. En effet, une dfaillance dun dispositif de la classe III peut avoir un effet moins grave quune dfaillance dun dispositif de la classe IIb. Les notions de dfaillance et deffet ne sont abordes que dans les normes sur la gestion du risque. La diffrence dapproche entre lavionique et le mdical tient au fait que ce dernier domaine aborde depuis peu la notion de systme, et de ce fait ne possde encore que des normes de haut niveau. En devenant plus techniques, les normes du domaine mdical devraient permettre dexprimer les raisons dune telle classication. En avionique, o ces notions sont abordes depuis longtemps, les normes se concentrent sur les composants du systme, et suivent une approche beaucoup plus technique. Ainsi, le logiciel, comme composant, a une norme ddie tout comme la technologie lectronique. On peut noter que dans le mdical, bien que la complexit des logiciels augmente, il ny a toujours pas de norme ddie au logiciel.

1.7.3 Processus de certication

Dans le cadre dune tude de la scurit, et en vue de la certication, il est obligatoire de classer le dispositif comme prsent dans la section prcdente. En fonction de la classe du dispositif, la procdure de preuve de conformit devient plus contraignante. En effet, pour un dispositif de classe I, seule une auto dclaration du fabricant est ncessaire. Pour des dispositifs comme les robots mdicaux (classe IIa et IIb), il est exig un examen complet de conception. Cela consiste fournir lorganisme de certication, une trace (un dossier) contenant lensemble des informations sur le processus qualit qui a t appliqu (en gnral de type ISO 9000), les informations sur la gestion des risques, et les informations sur la conception mme du dispositif. Cette procdure, qui met laccent sur le processus de fabrication plutt que sur le produit lui mme, est commune de nombreux domaines. Ce qui apparat nanmoins dans le domaine mdical cest une absence de normes ou de guides relatifs la production du dossier de certication. Dans le domaine des transports, on retrouve cette notion dans la rdaction des safety cases, qui ne trouvent pas leur quivalent dans le mdical. Il existe tout de mme des normes pour guider le fabricant dans lapplication du processus qualit, comme par exemple la norme NF EN 46003 (1999) qui exprime les particularit de lutilisation de lISO 9003 la fabrication dun dispositif mdical. On retrouve alors des lments comme le dossier de gestion des risques et dautres dossiers relatifs au processus. Les relations entre lutilisation de ces normes et la rdaction du document pour la certication, restent nanmoins oues et peu explicites.

1.8 Conclusion et problmatique

55

1.8

Conclusion et problmatique

Les technologies ont aujourdhui atteint un tel niveau de dveloppement quil est dsormais possible de transfrer au robot un ensemble de responsabilits et de fonctions jusqualors rserves exclusivement aux spcialistes humains. Le domaine de la robotique de service et plus particulirement de la robotique mdicale est un exemple de cette volution. Dans ce cadre, se pose la problmatique de la conance accorde ces systmes technologiques, et notamment celui de la scurit. An de dcomposer la notion de scurit, ce chapitre a repris les notions de base comme le dommage, le risque, et le danger et a cherch faire le lien entre les normes internationales et la recherche en robotique mdicale. Nous avons montr comment il tait possible aujourdhui darriver un ensemble de termes stables, non ambigus et galement applicables dautres domaines technologiques. Certaines relations non explicites dans les normes induisent encore quelques imprcisions notamment pour ce qui est des moyens dapprhender la scurit. Nous avons choisi de dcomposer la gestion du risque en trois tapes, lanalyse du risque, lvaluation du risque et la matrise du risque. Au sein du processus de gestion du risque subsistent deux points essentiels en cours de dveloppement. Tout dabord linclusion des facteurs humains dans les diffrentes activits nest pas explicite, et nous avons montr comment il tait possible de prendre en compte ce concept plusieurs niveaux du processus de gestion des risques. Le second point concerne lestimation du risque pour le logiciel. Il est en effet impossible destimer la probabilit doccurrence de dfaillance dun logiciel, et cela est en partie trait par lintroduction des SIL (Software Integrity Level) au sein de diffrentes normes. Cette dmarche est actuellement absente des normes ddies aux dispositifs mdicaux ou aux robots de service. An de mettre en application les activits de la gestion du risque, des techniques sont utilises mais ne couvrent que certains aspects du processus. Ainsi, lanalyse du risque est en partie traite par lutilisation de techniques comme lAMDEC ou les arbres de fautes. Ces techniques largement utilises dans dautres domaines sont aujourdhui applicables des dispositifs comme les robots de service. Les principales techniques pour la rduction du risque, ont ensuite t prsentes, en se concentrant sur deux aspects : les moyens matriels et logiciels. La sparation entre matriel et logiciel a permis de structurer cette partie, mais il est vident quun grand nombre de patrons de scurit ncessitent lutilisation combine de ces deux technologies. Beaucoup de techniques utilises dans la robotique industrielle, mais aussi dans lavionique ou le nuclaire, sont utilisables pour la robotique mdicale. Les particularits des applications mdicales ncessitent tout de mme des investigations qui nexistaient pas jusquici, en particulier sur de nouvelles architectures, de nouveaux actionneurs, et sur lintgration de la mesure des efforts appliqus sur le patient. Ces thmes de recherche ont une incidence directe sur la scurit, qui est la contrainte principale pour le dveloppement de nouvelles applications de robots mdicaux. Dans ce cadre de recherche, le chapitre 2 prsente

56

Scurit des systmes de la robotique de service

une analyse dun actionneur atypique, le muscle articiel, et value les risques et les bnces induits par lutilisation de cet actionneur. An de valider quune conception a bien intgr les diffrents concepts relatif la scurit, la socit propose un systme dassurance par le biais de la certication. Dans le cas des dispositifs mdicaux, cest un ensemble de directives qui dnit le cadre lgal de la certication. La section 1.7 a montr comment cette rglementation intgre les aspects lis au risque, prsents dans les sections prcdentes. Comme pour des dmarches qualit de type ISO9000, nous avons montr comment la certication des dispositifs mdicaux dont font partie les robots mdicaux, se basent plus sur la manire dont le systme est conu que sur lvaluation du systme lui-mme. Lobservation des informations de la conception ne peut se faire que si la documentation a t correctement ralise, et permet notamment la traabilit des choix de conception. La traabilit dnie dune manire gnrique dans la norme ISO 8402 comme laptitude retrouver lhistorique, lutilisation ou la localisation dun produit ou dun processus de dlivrance dun service au moyen didentications enregistres , peut sappliquer un dveloppement dun dispositif technologique comme un robot de service. partir de ces diffrentes conclusions, le travail prsent dans cette thse contribue apporter une rponse certains des besoins voqus ci-dessus. Ainsi, la dmarche propose tentera de fournir une solution aux diffrentes exigences prsentes ci-dessous : utiliser une terminologie stable et non ambigu pour la scurit (ce qui est fait dans ce chapitre) ; permettre une approche systme multi-domaine ; intgrer les facteurs humains relatifs la scurit, cest dire proposer une dmarche centre humain ; intgrer lanalyse du risque du logiciel ; et favoriser la traabilit des choix de conception pour rpondre aux exigences de la certication. Outre ces diffrentes problmatiques, un effort doit tre fait pour utiliser des techniques connues des ingnieurs, ou facilement comprhensibles. Le chapitre 4 prsente cette dmarche, et valide son utilisation par un cas concret dans le chapitre 5.

Chapitre 2 Risques lis lutilisation des muscles articiels de McKibben

2.1 Introduction

Les robots industriels effectuent aujourdhui des tches complexes, rapides et extrmement prcises. Ces robots ont inond les industries de llectronique et de lautomobile, et lon assiste lexplosion du nombre de ces dispositifs au sein des pays industrialiss. titre dexemple, le Japon comptait en 1999 plus de 400 000 robots industriels, soit un robot pour quatre ouvriers (Karlsson, 1999). Les actionneurs utiliss pour ces robots sont tudis depuis de nombreuses annes et satisfont pleinement les exigences du domaine industriel. Cependant, comme nous lavons montr au premier chapitre, lavnement dune robotique de service ct de la robotique industrielle, soulve des problmes qui nexistaient pas ou avaient t vits jusquici. En particulier, le fait de travailler au contact dun environnement non matris, comme un environnement humain, ne permet plus deffectuer des tches la manire des tches industrielles. Lexigence de la scurit rend ce problme encore plus complexe. Une approche utilise aujourdhui, consiste concevoir des systmes comportant de nombreux capteurs extroceptifs, et notamment des capteurs de force, et de contrler les mouvements du robot par des commandes hybrides, comme par exemple une commande position/force. Beaucoup dapplications de la robotique de service utilisent des actionneurs classiques de la robotique industrielle tels que (Hannaford et Winters, 1990) : les moteurs courant continu, les moteurs induction courant alternatif, les moteurs pas pas, les actionneurs hydrauliques cylindriques, et les actionneurs pneumatiques cylindriques. La plupart des actionneurs utiliss dans des domaines de pointe comme la robotique mdicale sont des moteurs pas pas en raison de leur prcision et de leur faible couple. Cependant, les contrleurs permettant de raliser des tches de service, et ncessitant de nombreux capteurs

58

Risques lis lutilisation des muscles articiels de McKibben

extroceptifs, sont complexes, difciles mettre en uvre, et encore sujets de nombreuses tudes thoriques. De plus, le poids, la taille, et la rigidit des actionneurs induisent des phnomnes dangereux pour des applications en contact avec lhomme. Une alternative ces problmes est lutilisation dactionneurs petits, lgers et avant tout compliants. Les muscles articiels de McKibben, invents dans les annes 50 par le physicien Joseph L. McKibben (Schulte, 1961), sont tudis au sein du LESIA depuis plusieurs annes (Tondu et Lopez, 2000), et semblent rpondre ces exigences. Depuis leur invention jusqu leur industrialisation1 , les muscles ont t sujets de nombreuses modications (E.P.W., 1984; Inoue, 1988; Immega, 1986; Greenhill, 1993) et utiliss dans plusieurs projets de recherche de robotique de service (Brigeston Corporation, 1987; Brigeston Corporation and Taicubo Engeneering, 1993; Noritsu et al., 1996; Pack et al., 1997). Cependant ces muscles sont encore ltat dvaluation, et aucun robot commercialis ne les utilise. Alors que toutes les premires tudes concernaient la validation de la commande des muscles et la faisabilit dapplications robotiques comportant des muscles, des travaux actuels sont initis sur lvaluation de certaines performances comme la fatigue et lusure des muscles (Klute et Hannaford, 1998). Ceci prouve que les muscles sont aujourdhui envisags par la communaut scientique pour des applications hors laboratoire. Dans le cadre dapplications sres (au sens de la scurit), nous proposons deffectuer ici une analyse du risque li lutilisation des muscles articiels. Il ne sagit pas de faire une analyse des performances, comme par exemple les prcisions atteintes, car nous nous limiterons au domaine de la scurit. Ainsi, titre dexemple, une dgradation de la prcision dun actionneur peut tre considre comme un phnomne dangereux et donc sujet une analyse, alors que la proprit inhrente dun actionneur tre moins prcis quun autre par sa construction mme ne nous intressera pas ici. En dautres termes, il ne sagit pas de dmontrer ici que les muscles articiels sont utilisables pour certaines applications et pas pour dautres, car cela relve dune analyse des besoins fonctionnels, qui doit tre faite par tout concepteur dsirant utiliser un actionneur. Ce que nous prsentons ici est une analyse des risques induits par lemploi des muscles articiels, qui peut tre utilise en complment des documents dcrivant le fonctionnement du muscle. Pour cela, ce chapitre suit les tapes de lanalyse du risque et la matrise du risque. Lvaluation du risque ne sera pas aborde en tant que section car elle repose sur des concepts fortement lis lapplication robotique. Comme nous souhaitons aborder le muscle dans une approche gnrique, nous naborderons pas cette activit. Tout dabord lanalyse du risque consiste dnir le systme (le muscle articiel) et ses caractristiques principales, puis dcrire son utilisation. Une utilisation des muscles est prsente sur un bras anthropomorphe sept axes dvelopp au LESIA. La seconde tape de lanalyse du risque concerne lidentication des situations et des phnomnes dangereux, en estiPar exemple le constructeur Allemand FESTO, www.festo.com, propose une gamme dactionneurs du type muscles articiels
1

2.2 Description du muscle articiel

Jupe mtallique

59
Tresse

Embout mtallique Arrive dair

F IG . 2.1 Photo de lextrmit dun muscle articiel mant les risques associs. Une troisime section dtaille les moyens possibles de matrise des risques lis au muscle articiel. Enn, une dernire partie conclut en effectuant une comparaison des bnces en terme de scurit par rapport aux autres actionneurs.

2.2

Description du muscle articiel

Cette section dcrit les principales caractristiques du muscle articiel en terme de conception et de performances. Laccent est mis sur les donnes concernant les nergies changes, et fournit les derniers rsultats sur les muscles fabriqus au LESIA. Pour certains dtails de la conception, du principe de fonctionnement, ou des modles mathmatiques du muscle, le lecteur pourra se reporter larticle de Tondu et Lopez (2000). Nous donnons ici une synthse de certains de ces lments.

2.2.1 Description gnrale

2.2.1.1 Fabrication du muscle

Les muscles articiels fabriqus actuellement au laboratoire consistent en un tube de caoutchouc, entour dune tresse faite de bres dun textile trs rsistant, et de deux bouts de tube mtallique (jupe mtallique) permettant de sertir les extrmits. Une photo de lextrmit correspondante est prsente sur la gure 2.1, et la vue schmatique correspondante est donne gure 2.2. loppos dun pneu qui contient une chambre air dans un volume xe mais dont la pression interne augmente, la tresse permet au tube de caoutchouc de moduler son gonement et donc sa forme. Le tressage suivant un rseau pantographe exible permet de convertir les forces exerces sur la circonfrence en une force mcanique de contraction axiale. Ainsi, lorsque la pression dans le tube de caoutchouc augmente, le muscle se rtracte. Ce principe a men lidentication de diffrents paramtres : 0 est langle de tresse, qui correspond langle dune bre de la tresse par rapport laxe du muscle, en considrant le muscle au repos (non gon). De ce paramtre dpend la conversion de lnergie de pression de circonfrence en force axiale.

60

Risques lis lutilisation des muscles articiels de McKibben

Jupe mtallique Tuyau de Tresse caoutchouc Joint torique Embout mtallique

Arrive dair

F IG . 2.2 Coupe dune extrmit dun muscle articiel avant le sertissage de la jupe mtallique
Embout

Force mcanique

Tresse

Jupe mtallique mtallique

Btit

Pr-actionneur : convertisseur Intensit-Pression

Commande en intensit

F IG . 2.3 Branchements entre muscle articiel et son pr-actionneur l0 dnie comme la longueur active initiale du muscle. La partie active est celle qui se rtracte lors de la mise sous pression, elle correspond donc la longueur de la tresse entre les deux anneaux de mtal. r0 correspond au rayon du tube de caoutchouc, sachant quil doit tre identique au rayon de la tresse pour de meilleures performances. De plus l tant la longueur considre un instant t, on dnit le taux de contraction par = (l0 l)/l0 . Les trois paramtres prsents ci-dessus, ont une inuence directe sur les performances des muscles, la section suivante prsente quelques rsultats sur les forces dynamique et statique. Pour les applications de robotique de service, on pourrait ajouter les paramtres que sont le volume maximal doccupation dun muscle, ainsi que son poids. Nous verrons ultrieurement que ces caractristiques sont trs diffrentes des celles des autres actionneurs. 2.2.1.2 Utilisation du muscle

Dans son utilisation la plus courante, le muscle est command par un pr-actionneur qui permet de convertir une tension ou une intensit, en pression comme prsent sur la gure 2.3. Il est important de souligner toute limportance de ce pr-actionneur, notamment pour lestimation des puissances instantanes du muscle donnes ci-aprs. En effet les performances

2.2 Description du muscle articiel

61

du pr-actionneur inuent directement sur les performances du muscle, comme par exemple le temps de rponse, et donc la vitesse de dplacement. Nous utilisons au sein du LESIA des convertisseurs intensit/pression de la socit Samson2 . Ces practionneurs prennent en entre une intensit comprise entre 4 mA et 20 mA, et rgulent la sortie en pression entre 0 et 5 bars. Sanchez (2000) propose dans sa thse une modlisation complte de ce pr-actionneur permettant didentier la totalit de la boucle de rtroaction.

2.2.2 valuations des efforts en statique et dynamique

2.2.2.1 Force statique

Le lecteur peut se rfrer larticle de Tondu et Lopez (2000) pour une expression des modles mathmatiques des forces statiques et dynamiques du muscle. Les auteurs exposent diffrentes conclusions ayant trait la force statique : la force statique est globalement proportionnelle laire de la section dun muscle ( r2 ), 0 la force statique est globalement indpendante de la longueur initiale l0 , la force statique est globalement proportionnelle la pression de commande P , la force maximale est inversement proportionnelle langle de tresse 0 , la force statique est proportionnelle au taux de contraction avec un facteur proportionnel la pression de commande P . De la mme manire on prsente une synthse des conclusions relatives la force dynamique : la contraction du muscle est naturellement diminue par une friction cintique nonlinaire inhrente la tresse, la rponse varie entre 0,1 et 1 seconde selon le volume du muscle. Dune manire gnrale, la gamme des efforts exercs par les muscles que nous utilisons au laboratoire, peut monter jusqu 400 daN3 . Un graphique reprsentant les forces statiques que les muscles peuvent dployer est fourni sur la gure 2.4. Ce graphique donne pour chaque muscle, la force quil dploie pression maximale (5 bars), et pour des longueurs de muscles xes grce un tire-fort. Le choix de notation de ces muscles correspond lutilisation que lon en fait au laboratoire pour le bras anthropomorphe sept axes o six types de muscle ont t utiliss. Les caractristiques pour chacun des muscles sont : Muscle type 1 : l0 = 230mm, 0 = 17, 1 , r0 = 12 mm, poids=236 g ; Muscle type 2 : l0 = 196mm, 0 = 17, 1 , r0 = 12mm, poids=223 g ; Muscle type 3 : l0 = 190mm, 0 = 19, 8 , r0 = 12mm, poids=220 g ; Muscle type 4 : l0 = 193mm, 0 = 18, 9 , r0 = 8, 5mm, poids=86 g ; Muscle type 5 : l0 = 141mm, 0 = 20, 1 , r0 = 8, 5mm, poids=81 g ; Muscle type 6 : l0 = 118mm, 0 = 23 , r0 = 7 mm, poids=46 g.
2 3

http ://www.samson.de Une force de un dcanewton (daN) quivaut approximativement une masse de un kilogramme

62

Risques lis lutilisation des muscles articiels de McKibben

1 2 3 4 5 6

F IG . 2.4 Force statique de plusieurs muscles 5 bars Pour des rayons de tube plus importants on peut imaginer que les efforts puissent atteindre des valeurs entre 400-500 daN. Ceci nous amne conclure que ces actionneurs sont extrmement puissants par rapport leur poids et leur volume doccupation, notamment par rapport aux moteurs. 2.2.2.2 Force dynamique

Le protocole dexprimentation utilis depuis plusieurs annes au laboratoire (Tondu et Lopez, 1997) consiste en une charge souleve par un muscle grce une poulie. Le site exprimental que nous avons amlior est prsent sur la gure 2.5. La force dploye en dynamique par ces actionneurs est reprsente sur la gure 2.6, pour une masse de 15 kg, et un muscle de type 6. La masse soulever est lorigine pose sur un socle, et la force est donc nulle au dpart. Lenvoi dun chelon de 5 bars permet alors deffectuer une mesure de la force dynamique maximale. partir de ces mesures, on dduit la vitesse de dplacement, puis la puissance dnie par le produit entre la force dynamique et la vitesse de dplacement. Cette puissance identie en dynamique est reprsente sur la gure 2.7 o lchelle est modie pour la lisibilit de la courbe. La valeur relle de la puissance maximum pour cette exprimentation est de 700 daN.cm/s, soit de 70 Watts. On obtient alors un rapport puissance sur masse de 0.3. Cependant malgr la valeur leve de ce rapport, il convient de noter que ces tests ont t effectus en dynamique sur une impulsion de pression, et que les rapports des moteurs pas

2.2 Description du muscle articiel

Codeur incrmental

63

Arrive dair

Capteur de force dynamique

Capteur de pression 15Kg

F IG . 2.5 Site exprimental pour les tests dun muscle en dynamique pas par exemple, qui sont de lordre de 0.1 (Hannaford et Winters, 1990), ont t calculs vitesse constante de dplacement. Ce test est videmment trs difcile effectuer pour les muscles articiels, dont le dbattement est limit ( loppos dun moteur qui peut tourner vitesse constante indniment). De plus, les forces dynamiques atteintes par les plus petits muscles (ceux du type 5) sont du mme ordre de grandeur que celles des plus gros muscles (type 1 et 2). La gure 2.8 montre les forces dynamiques dun muscle de type 1 et dun muscle de type 6, pour une charge souleve de 10 kg. Il est important de noter que la force dynamique, proportionnelle la charge souleve, reste trs leve, mme pour les plus petits muscles que lon utilise dans notre laboratoire.

2.2.3 Compliance
Le terme de compliance, utilise dans ce chapitre fait rfrence la compliance passive prsente dans la section 1.6.1.2. Cette proprit, parfois appele complaisance, est calcule comme linverse de la raideur. Elle donne une mesure sur la souplesse naturelle du muscle. Cette caractristique constitue lintrt principal de ces actionneurs. Elle est une consquence directe du composant de type ressort du muscle articiel. Il nexiste en effet aucun autre actionneur capable de donner cette souplesse naturelle, que ce soit parmi les moteurs lectrique ou les autres actionneurs pneumatiques.

2.2.4 Actionnement dune articulation

Dans beaucoup dapplications robotiques, le muscle est utilis dans un montage comportant deux muscles antagonistes permettant deffectuer une rotation dun axe suivant le principe prsent sur la gure 2.9. Les diffrents modles mathmatiques de lactionnement sont pr-

64

Risques lis lutilisation des muscles articiels de McKibben

Force dynamique (daN) Pression lue (bar) Consigne en pression (Bar) Longueur (cm) 20

15

10

0 0 2 4 6 Temps (secondes) 8 10 12

F IG . 2.6 Rponse en longueur et force dynamique dun muscle un chelon pour une charge de 15 kg

(ramene lchelle) (bars)

F IG . 2.7 Puissance instantane en rponse chelon pour une charge de 15 kg

2.2 Description du muscle articiel

65

16

14

Contraction du gros muscle (cm) Contraction du petit muscle (cm) Force dynamique du petit muscle (daN) Force dynamique du gros muscle (daN)

12

10

0 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8

Temps (secondes)

F IG . 2.8 Forces dynamiques de deux muscles pour une masse souleve de 10 kg sents dans larticle de Tondu et Lopez (2000). Cependant, lapparition des robots parallles, et notamment pour des tches de service, a rendu possibles dautres types dactionnement. Le muscle peut par exemple tre utilis dans sa longueur comme pour le robot tl-chographe TER prsent au chapitre 5.

2.2.5 Contrle des muscles articiels

Les travaux de recherche sur la commande des robots manipulateurs actionns par des muscles articiels de McKibben mens au laboratoire, ont dmontr que plusieurs techniques dasservissement apportent des performances de prcision satisfaisantes pour des applications de service. Les travaux de Boitier (1999) et de Carroll et al. (1997) dmontrent que la commande PID4 avec terme danticipation5 et la commande Structure Variable sont utilisables pour un robot SCARA6 deux DDL (Degrs De Libert). Dautres commandes comme la commande oue (Vial, 1997), la commande plate (Sanchez, 2000), ou la commande par rseaux de neurones (Eskiizmirliler et al., 2002), ont aussi apport des rsultats satisfaisants en terme de prcision.
Rgulateur comportant des calculs partir de lerreur entre la position dsire et la position relle de type Proportionnel, Intgrateur et Drive 5 Sur la base de modles de rponse connus des axes du robot, ce terme vient anticiper la rponse de laxe command 6 Les robots de ce type effectuent leurs mouvements dans un plan
4

66

Risques lis lutilisation des muscles articiels de McKibben

P0

P0

P0+P

P0-P

F IG . 2.9 Principe de lactionnement dune articulation au moyen de deux muscles antagonistes Bien que les rsultats de ces diffrents travaux sur lasservissement en position des muscles soient satisfaisants pour les applications dveloppes au sein du laboratoire, ils comportent tout de mme certains points ngatifs. Tout dabord en terme de prcision, les rsultats sur un muscle sont trs satisfaisants car on obtient des prcisions infrieures au millimtre, mais lorsque lon passe une structure comportant plusieurs muscles, comme une articulation, la non-linarit propre chaque muscle mne des calculs complexes et lourds pour les calculateurs. Certaines solutions savrent alors difcilement utilisables en raison des contraintes temps rel. Cependant, pour certaines applications ne ncessitant pas une prcision infrieure au millimtre, ou dont la structure rend difcile la commande (comme des structures parallles), il est possible dutiliser une simple commande en boucle ouverte grce la stabilit naturelle du muscle en boucle ouverte. Cette souplesse naturelle du muscle, rend les applications robotiques travaillant dans lespace, fortement dpendantes de la gravit. En effet, pour un robot de type SCARA dont les mouvements se font dans un plan, la force de gravit sera toujours orthogonale aux axes du robot. Mais pour un robot comme un bras articul plusieurs axes, les efforts exercs sur une articulation dpendront de la conguration des axes du robot. Par exemple, pour un bras anthropomorphe tendu lhorizontale, leffort que devra fournir une paule sera moins important si lon plie le coude. On dplace alors le centre de gravit vers lpaule. Cette problmatique doit encore tre tudie car cela peut gnrer des asservissements complexes.

2.2.6 Validation sur un bras sept axes anthropomorphe

Le LESIA7 a dvelopp avec le laboratoire de mcanique de lINSA de Toulouse, un bras anthropomorphe sept axes actionn exclusivement par des muscles articiels (Tondu et al., 2003). Ces 7 axes correspondent 7 liaisons de rotation comme prsent sur la gure 2.10. La nalit tait une validation exprimentale de lactionnement grce aux muscles articiels
7

Laboratoire dtude des Systmes Informatiques et Automatiques

2.2 Description du muscle articiel

67

q 3 q 1 q 2

q 4

q 7 q 6

q 5

F IG . 2.10 Sens de rotation des 7 axes du bras anthropomorphe sur une structure robotique complexe. La structure mcanique reproduit les sept articulations du bras humain, en se limitant une taille humaine. Des photos de ce bras sont donnes gures 2.11, 2.12 et 2.13. Le contrleur de ce robot a t dvelopp en UML, et implant en C++ sur le noyau temps rel VxWorks. Une commande en boucle ouverte et un simple proportionnel ont permis de valider cette technologie et dobtenir des premiers rsultats exprimentaux. Ce bras permet notamment deffectuer des tches de service en tlopration comme la pose dun verre reprsent sur la gure 2.14. Le fait dtre en tlopration a rduit la complexit de la loi de commande possible pour contrler les mouvements de ce bras. Mais cela nous a permis de valider la faisabilit dune telle structure, et de prochaines tudes automatiques devraient tre ralises au sein du laboratoire. Pour raliser la tlopration, loprateur utilise deux joysticks et un palonnier qui lui permettent de contrler chaque articulation du robot. Si lapprentissage savre complexe pour loprateur, nous avons pu raliser et valider des tches comme la pose dun verre, le suivi dune surface et la rencontre dobstacles, et ainsi valider lapport trs important de la compliance pour la ralisation et la scurit de ces tches complexes.

68

Risques lis lutilisation des muscles articiels de McKibben

F IG . 2.11 Vue de dos du bras anthropomorphe 7 axes

F IG . 2.12 Vue de face du bras anthropomorphe 7 axes

2.2 Description du muscle articiel

69

F IG . 2.13 Vue de prol du bras anthropomorphe 7 axes

70

Risques lis lutilisation des muscles articiels de McKibben

F IG . 2.14 Manipulation dun verre par le bras anthropomorphe 7 axes

2.3 Identication des dangers et estimation du risque

Angle (degrs)
200

71

1
150

100

2
50

3
-50

-100 10 20 30 40 50

Temps (secondes)

F IG . 2.15 Dbattements des axes 1 3 du bras anthropomorphe 7 axes Dun point de vue mcanique, les dbattements que nous avons obtenus sont proches de ceux du bras humain et sont reprsents sur les gures 2.15 et 2.16.

2.3

Identication des dangers et estimation du risque

partir des caractristiques du muscle articiel, on analyse ici les dangers induits par lutilisation de ces muscles. En rfrence au premier chapitre, la notion de danger que lon emploie ici inclut, comme cela est prsent dans la section 1.3.6, les notions de phnomnes dangereux, situations dangereuses, et vnements dommageables. En premier lieu nous analyserons les phnomnes dangereux que sont les dfaillances du muscle. Et pour cela nous tudierons les modes de dfaillance des composants du muscle, pour en dduire les modes de dfaillance du muscle lui-mme. Il est vident quun muscle articiel ne peut constituer lui seul une source de dommage et cest le contexte dutilisation qui permet de dterminer les dangers induits par le muscle articiel. En consquence, nous analyserons les situations dangereuses les plus communes et que lon peut identier de manire gnrale sans se rfrer une application robotique particulire.

72
Angle (degrs)

Risques lis lutilisation des muscles articiels de McKibben

4 5

7 6

10

Temps (secondes)

F IG . 2.16 Dbattements des axes 4 7 du bras anthropomorphe 7 axes

2.3.1 Phnomnes dangereux de type dfaillances

Pour cette section nous utilisons la technique de lAMDEC prsente au chapitre 1. Par souci de clart, ne sont prsentes ici que les analyses des composants les plus importants : la tresse et son systme de maintien, et le tube de caoutchouc. 2.3.1.1 Dfaillances de la tresse et de son systme de maintien

Ces composants dont un schma a t prsent sur la gure gure 2.2 conduisent lidentication de deux modes de dfaillance principaux : la rupture totale de la tresse, et le dsengagement de la tresse hors de la zone de pincement forme entre lembout mtallique et la jupe mtallique. Certains autres modes de dfaillances comme ltirement de la tresse ou la dformation du systme de maintien ne sont pas envisags car ils sont physiquement impossibles. La rupture totale de la tresse est une dfaillance qui na pas encore t observe dans la pratique, et cela pour la simple raison que cette tresse est forme de plusieurs centaines de bres dun textile trs rsistant. Bien que des essais rels naient pas t effectus, on peut penser que cette tresse puisse rsister plusieurs tonnes dtirement. Dans le cadre de la robotique de service, les efforts natteignent jamais des valeurs aussi importantes. On peut donc

2.3 Identication des dangers et estimation du risque

Risque

73
Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Dfinir rgles dutilisation b. Entourer les muscles dun matriau de protection a. Dfinir rgles dutilisation Pincement de la jupe mtallique plus important b. Entourer les muscles dun matriau de protection

Composant

Mode de dfaillance

Causes

Effets

Tresse

Rupture tresse

Systme de maintien

Dsengagement de la tresse

a. Mauvaise conception b. Mauvaise utilisation c. Mauvaise conception d. Mauvaise utilisation

a. Force mcanique 1 I I b. Capteur de pression transmise nulle b. Flot dair c. Projections d. Force mcanique 1 P H b. Capteur de pression transmise nulle e. Flot dair f. Projections

F IG . 2.17 Analyse des modes de dfaillance de la tresse et du systme de maintien estimer la probabilit doccurrence dune telle dfaillance comme invraisemblable suivant lchelle qualitative prsente la section 1.4.3.4. Le dsengagement de la tresse hors de la zone de pincement est un phnomne plus probable. Sur lensemble des manipulations des muscles articiels au sein du LESIA depuis une dizaine dannes, un seul cas de dsengagement total a t observ. Il na provoqu aucun dommage grave, et lon peut qualier lvnement dincident. Puis, quelques cas dun dsengagement progressif sur une anne sans quil y ait dsengagement total ont t observs suite une modication de la conception. Cest pour cette raison que nous attribuons le niveau de probable ce mode de dfaillance. Leffet direct de ces modes de dfaillances est en premier lieu la rupture de la chane cintique, produisant une force nulle aux deux extrmits du muscle, et qui peut produire un dommage sur le systme en fonction de larchitecture du robot choisie. Cependant, il convient de prendre en compte les effets pouvant produire des dommages directement vers les autres composants du systme et sur son environnement, et notamment les acteurs humains se trouvant proximit. Tout dabord, une rupture totale peut entraner des projections dlments comme les pices mtalliques composants le muscle, puis le volume dair ntant plus contraint, cela mne un ot dair incontrl dlivr par le practionneur. Le systme le plus simple pour dtecter ces modes de dfaillance est lintroduction de capteurs de pression en amont du muscle, relis soit un systme de coupure de la pression, soit un contrleur capable de prendre une dcision. Les moyens de prvention concernent alors la fabrication du muscle, et sont abords ultrieurement dans la section relative la matrise du risque. Lensemble de ces lments peut tre rsum dans un tableau de type AMDEC, prsent sur la gure 2.17. Sur ce tableau sont prsents des solutions envisageables sur lesquelles nous reviendrons dans la section 2.4. Cependant, il est dj possible didentier deux causes principales pour ces modes de dfaillance qui sont une mauvaise conception (tresse fragile ou abme), et une mauvaise utilisation (proximit dobjet tranchant, frottements, etc.), et den dduire des moyens de prvention et de protection que nous dtaillerons dans la section 2.4.

Gravit Occurrence Risque

Moyens de dtection possibles (en ligne) a. Mode dfaillance b. Effets

74

Risques lis lutilisation des muscles articiels de McKibben

Risque

Composant

Mode de dfaillance

Causes

Effets

Gravit Occurrence Risque

Moyens de dtection possibles (en ligne) a. Mode dfaillance b. Effets b. Capteur de pression, capteur de longueur

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Rgles dutilisation b. Protection autour des muscles

Tube de aoutchouc

Crevaison

a. Mauvaise conception b. Mauvaise utilisation

a. Chute de la pression et drive de la contraction vers zro b. Flot dair c. Bruit

F IG . 2.18 Analyse du mode de dfaillance du tube de caoutchouc 2.3.1.2 Dfaillance du tube de caoutchouc

Il nexiste quun mode dfaillance de ce composant, mais comportant plusieurs degrs. Il sagit dune ssure dans le tube, plus communment appele crevaison. Cette ssure peut tre de diffrentes tailles, et donner lieu une crevaison importante ou une simple fuite. Dans tous les cas, les causes de cette dfaillance sont soit lies une mauvaise conception (fragilit du caoutchouc), soit une mauvaise utilisation (hors limites, intensive, etc.). LAMDEC de ce mode de dfaillance est donn gure 2.18. Il convient de noter quune des causes de la crevaison est lusure naturelle du tube. Elle est incluse dans la cause Mauvaise utilisation, puisque que lon considre alors que lutilisation dun muscle usag ou trop vieux est une erreur de loprateur. Pour ce mode de dfaillance, il est important de souligner que leffet nest pas comme prcdemment, une force mcanique nulle, car le muscle stirera au maximum jusqu sa longueur pression nulle. Leffet est donc une drive de la longueur du muscle, qui peut tre traduit comme une diminution de la force transmise vers une valeur xe. Par exemple, dans le cas dune masse suspendue un muscle, la masse ne sera pas livre la seule force de son poids, car la tresse du muscle dlivrera au minimum elle seule une force de raction permettant de maintenir la masse. Ceci est fondamental pour la suite de lanalyse. Les effets en terme de longueur et de pression sont illustrs sur les gures 2.19 et 2.20, dans les mmes conditions de test que pour lidentication de la force dynamique, avec une masse de 15 kg, et un des plus gros muscles que lon utilise (l0 = 230mm, 0 = 17, 1 , r0 = 12mm). partir du troisime crneau on peut observer le phnomne de crevaison qui nexistait pas jusqualors. Dautres tests ont montr que ce mode de dfaillance se comportait globalement toujours de la mme manire, cest dire en une drive progressive de la longueur et de la pression. Ainsi, sur ces diagrammes, on peut observer, pour une commande en crneau 0-5 bars, une chute de pression 1,75 bar en quatre paliers, et une chute de contraction de 72% en plusieurs dizaines de secondes. Ceci mne considrer cette dfaillance, comme douce : le muscle drive lentement vers une valeur xe de longueur, puis y reste. Les effets sur le systme robotique utilisant le muscle sont alors directement dpendants de larchitecture choisie. Cet aspect est dvelopp dans la section sur la matrise du risque (cf. section 2.4). Les autres effets prendre en compte sont le ot dair continu schappant par la ssure et le bruit associ. Ces effets peuvent notamment tre une source de dommage sur lenvironnement (par exemple

2.3 Identication des dangers et estimation du risque

75

Longueur de contraction (cm) 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 0 10 20 30 40 50 60 70 80 90 100 Temps (secondes)

F IG . 2.19 Rponse en longueur une crevaison

Pression (bar) 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 0 10 20 30 40 50 60 70 80 Temps (secondes)

F IG . 2.20 Rponse en pression une crevaison

76

Risques lis lutilisation des muscles articiels de McKibben

dans un milieu aseptis), voire psychologique (peur, stress de la part des humains proximit du muscle). Il est alors difcile destimer la gravit du dommage que peut gnrer cette dfaillance, car elle dpend videmment de lapplication robotique. Cependant, il est possible destimer qualitativement la frquence doccurrence de ce mode de dfaillance frquent, car on la mesure aujourdhui, sur les diffrentes plates-formes du LESIA (robotiques ou non), plusieurs crevaisons par an. Une estimation quantitative thorique de la dure de vie des muscles a t aborde de manire mathmatique par une quipe de luniversit de Washington (Klute et Hannaford, 1998), mais elle concerne principalement lutilisation de modles mathmatiques de dure de vie du caoutchouc. Or, au sein du muscle articiel, les frottements de la tresse sur le tube, non mesurables en terme deffets, sont difcilement intgrables ce calcul. De plus, une estimation exprimentale comme nous lavons faite, doit se limiter un type de muscle, une charge donne, mais surtout un type de commande (triangle, sinusode, crneau, ou constante), et les rsultats sont encore difcilement exploitables. En conclusion, la crevaison est aujourdhui encore le mode de dfaillance le plus commun. Les solutions possibles pour matriser le risque associ cette dfaillance sont bases sur lexpertise du LESIA au travers des diffrents projets utilisant les muscles. Ces solutions sont dveloppes dans la section 2.4.

2.3.2 Situations dangereuses

Contrairement la section prcdente, lidentication de situations dangereuses ne peut se faire que lorsque lon connat le systme global o sont intgrs les muscles. Cependant, nous avons identi deux situations dangereuses gnriques. Ainsi, dans le cas dun bras robot, une premire situation dangereuse induite par la gravit peut tre identie. En effet, comme prsent dans la section 2.2.5, la compliance des muscles articiels peut rendre certaines architectures fortement dpendantes de la gravit. Il est alors possible de passer par certaines congurations o le poids du robot lui-mme entrane un cart de mouvement, et ceci est fortement augment si le robot comporte une charge. Les effets de tels dplacements, lors dune tche de service, peuvent tre critiques pour la scurit, et les moyens de matriser ce risque rsident principalement dans le contrle des mouvements comme cela est prsent dans la section 2.4. La deuxime situation dangereuse gnrique que lon peut identier est la contrainte dun muscle dans une position, puis la libration instantane. Par exemple, lors dun contact entre un obstacle et un bras robot actionn par des muscles articiels, le choc sera fortement rduit grce la compliance du muscle. Cependant, lors du relchement de la contrainte, si la commande na pas t adapte sufsamment rapidement, il est possible dobtenir un mouvement de relchement dont la vitesse peut engendrer une nergie cintique dangereuse. Cest donc la souplesse elle-mme qui peut encore une fois tre source potentielle de dommage. Cet

2.4 Solutions possibles pour la matrise du risque

77

vnement ne se limite pas quaux bras robots, et peut concerner toute architecture articule (jambes, robots parallles, etc.).

2.4

Solutions possibles pour la matrise du risque

Cette section reprend les principaux moyens de matrise des risques abords dans la section danalyse du risque. Il est deffectuer de la prvention en rduisant la probabilit dapparition du danger, et donc du dommage. Mais on peut aussi utiliser des techniques de protection pour rduire la gravit dun dommage.

2.4.1 Moyens de prvention

La prvention passe dabord par la conception du muscle lui-mme. Le systme de maintien de la tresse par une jupe mtallique est ralis par un systme de presse hydraulique permettant deffectuer un sertissage homogne et aussi puissant que lon dsire (ou du moins jusqu la rsistance des pices de mtal). Le matriau du tube de caoutchouc qui est utilis aujourdhui est du simple latex, qui fournit une dure de vie nettement suprieure au butyle ou aux autres matriaux utiliss prcdemment. Ces donnes nont pas encore t chiffres, mais le latex semble au moins dix fois plus endurant que les anciens tubes. Ce latex est nanmoins sensible aux agressions de lenvironnement comme la lumire, la temprature et lhumidit. Pour lutilisation des muscles, il est donc prfrable de prvoir des emplacements protgs contre ces agressions. De plus, la dure de vie limite du tube impose un programme de maintenance prventive adapt lapplication robotique concerne, et la sollicitation des muscles8 . Cependant, les rsultats actuels de dure de vie de ces muscles sont encore assez variables et il est extrmement difcile de proposer des rgles de remplacement de ces muscles. Les moyens de prvention de situations dangereuses sont encore ltat de recherche. Ils concernent en effet, la commande de ces muscles, pouvant intgrer des situations dangereuses comme le contact avec un obstacle, le blocage dans une conguration donne puis le relchement brutal, ainsi que la gestion de la force de gravit. Ces aspects ont encore tre dvelopps et concernent principalement les contrleurs informatiques.

2.4.2 Moyens de protection

Des systmes de muscles redondants comme le sont les bres dun muscle humain, ou des dispositifs externes aux muscles que nous naborderons pas ici (revtement visco-lastique, freins sur articulations, etc.), pourraient permettre au robot de ragir en cas de dfaillance dun
Sur lutilisation mme des muscles, le type de commande joue fortement sur la dure de vie de ces muscles. Par exemple des fronts de pression sont viter
8

78

Risques lis lutilisation des muscles articiels de McKibben

muscle, et protger les biens ou les personnes. Cependant un des principaux intrts du muscle est son faible poids, et ces moyens ncessitent des montages plus lourds et volumineux. Des systmes de protection autour des muscles, permettent de protger lenvironnement extrieur des projections ou du ot dair en cas de crevaison ou de rupture dun muscle, tout en protgeant les muscles des agressions extrieures (pointes, frottements). De tels systmes doivent nanmoins rendre possible la maintenance des muscles comme par exemple le remplacement. En dernier point, nous voulons souligner ici toute limportance de larchitecture du robot face aux effets des dfaillances des muscles. Comme nous lavons prsent, la principale dfaillance dun muscle tant la crevaison, le muscle sallonge jusqu la longueur initiale. Dans ce cas, une architecture permettant un geste de retrait de leffort appliqu par le robot sur lenvironnement en cas dallongement dun muscle, permet dobtenir une scurit intrinsque.

2.5

Synthse et conclusion

Les principales caractristiques du muscle articiel ayant une incidence sur la scurit ont t prsentes travers les diffrentes sections de ce paragraphe. Tout dabord, la fabrication du muscle consiste en lassemblage de matriaux rsistants et limits en nombre9 dont les deux principaux lments sont la tresse et le tube de caoutchouc. Ce principe simple de fonctionnement rduit le nombre de dfaillances possibles propres cet actionneur. En comparaison, les modes de dfaillance des autres actionneurs sont en gnral : drive de la position, saut de position ou pic dacclration, position ou vitesse alatoire, position ge, ot dun type dnergie non prvue (choc lectrique, dcharge lectrostatique, etc.). Les modes de dfaillance les plus dangereux sont sans doute le pic dacclration et la sortie alatoire. Dans le cas du muscle articiel, les puissances atteintes sont trs importantes (jusqu 400 kg pour un muscle de 23 cm !), et de tels modes de dfaillance pourraient engendrer des dommages importants. Cependant nous avons montr quil nexiste quune dfaillance probable, la crevaison, dont les effets sont une diminution douce de la longueur de contraction, et un ot dair vers lenvironnement extrieur. Dans ce cadre, pour de nombreuses applications robotiques cette dfaillance pourra avoir un effet ngligeable suivant larchitecture choisie. Par exemple, dans le cas dun bras robot, si un muscle dune articulation se perce, leffet sera un mouvement lent vers une position xe dpendant de la conguration dans laquelle se trouvait le bras. De plus nous avons montr quun ensemble de moyens de prvention concernant la fabrication, lutilisation, et la maintenance, permettent de rduire la probabilit doccurrence de la crevaison.
9

Notons que cet aspect en fait un des actionneurs le moins coteux du march

2.5 Synthse et conclusion

79

Le risque le plus important est sans doute loccurrence de situations dangereuses, induites par la force de gravit et les perturbations extrieures. Les effets peuvent tre des mouvements brusques et non matriss pouvant induire des dommages importants. Ce risque, peut tre rduit par le contrle des mouvements, mais cet aspect trs complexe doit tre encore dvelopp. Un des axes de recherche est le contrle de la raideur dune articulation comme celle de la gure 2.9, en augmentant la pression de base P0 des deux muscles antagonistes. Un autre axe de recherche est la dcouverte de nouvelles architectures robotiques permettant de limiter les effets de la gravit. Ainsi, il est possible de crer des architectures, comme celle du robot mdical parallle TER prsent dans le chapitre 5, pratiquement indpendantes de la gravit. De plus, de par son architecture, le robot TER limite les effets des dfaillances des muscles, en rduisant la pression sur le patient en cas de crevaison dun muscle. Les muscles articiels sont donc une technique nouvelle de la robotique, permettant de rduire les risques suivant larchitecture du robot. Un muscle seul est actionneur intrinsquement sr, car son principal mode de dfaillance, la crevaison, a un effet doux . Cependant, si les muscles articiels apportent une garantie supplmentaire de scurit, il est vident quune commande errone de pression les rend dangereux. Or dans un systme robotique, cette commande rsulte de linteraction de nombreux lments. Et la matrise de la scurit ne peut donc venir que de la matrise de lensemble de ces lments, soit la matrise de la scurit du systme. Pour cela, les chapitres suivants proposent une dmarche systme (chapitre 4 et 5), permettant danalyser les risques dun systme de robotique de service, en se basant notamment sur un langage de modlisation prsent dans le chapitre 3.

Chapitre 3 La modlisation oriente objet avec UML

3.1 Introduction

Au chapitre 2 nous avons tabli que les muscles articiels constituaient une technique permettant de rduire le risque gnralement associ aux actionneurs. Cependant, nous avons vu que le risque principal dune application de robotique de service, rsidait dans la complexit du systme global. La matrise de la scurit ne peut se rduire lutilisation de techniques particulires comme les muscles articiels, mais doit intgrer une gestion des risques comme nous lavons prsent au premier chapitre. Or, les diffrentes activits de la gestion du risque doivent tre effectues avant que la fabrication ait eu lieu. Pour cela les concepteurs sappuient sur des modles, reprsentation abstraite dun problme et de sa solution, permettant de dcrire de manire prcise et non ambigu larchitecture du systme. Dans de nombreux projets, lexpression textuelle, est la technique principale pour dcrire lensemble des lments. Cette mthode est cependant trs limite puisquelle ne favorise pas les relations inter-domaines (o les langages sont diffrents), et la qualit de la description est entirement dpendante du savoir-faire du concepteur. Lalternative cette dmarche est lutilisation de langages particuliers, et idalement de langages formels. Pour mener une analyse, diffrents critres de slection de ces langages peuvent tre utiliss. Il est avant tout important de se baser sur un langage existant, ou familier du fabricant. La facilit de comprhension et dapplication du langage permet de crer rapidement des documents et de mieux communiquer les informations. Il existe de nombreux langages qui permettent aujourdhui de modliser la conception dun systme. Mais dans le cadre dune tude sur le risque, il convient dintgrer toutes les composantes du systme dans son environnement, et dadopter une vue plus globale. On parle aujourdhui de vue systme (par opposition systme informatique ou lectronique, etc.). Un des aspects importants, est la reprsentation graphique qui facilite la lecture et la comprhension rapide et qui permet de communiquer avec des personnes non spcialistes. Pour ces diffrentes raisons, le langage UML (Unied Modeling Language), semble convenir lexpression dun modle en vue dune gestion du risque. De plus ce langage est devenu un standard dans le domaine des technologies et de nombreux industriels lutilisent.

82

La modlisation oriente objet avec UML

Une tude de conception dun contrleur de robot base sur UML, a t effectue au sein du laboratoire lors dune thse prcdente (Carroll, 1999), et au regard de la complexit et des particularits du contrleur de robot, la conclusion est que ce langage a permis de modliser lensemble du contrleur. De plus, une tude de comparaison (Caroll et al., 1998) a permis de montrer lapport de la conception oriente objet par rapport une approche fonctionnelle. Avant daborder la problmatique de lanalyse du risque couple avec UML au chapitre 4, nous prsenterons dans la section 3.2 une synthse des concepts importants de ce langage et des notions que nous utiliserons par la suite. Puis, la section 3.3 prsente une rapide description de quelques travaux sur les interactions entre la modlisation oriente objet et la sret de fonctionnement de systmes scurit critique, et permet de positionner nos travaux dans ce cadre de recherche.

3.2

UML : notation pour le dveloppement orient objet

Bien avant lapparition des techniques permettant de modliser des systmes entiers incluant des acteurs humains, des systmes externes, et des composants informatiques, mcaniques, ou lectroniques, les informaticiens avaient travaill sur des techniques de modlisation permettant de dcrire et de raliser les logiciels. Ainsi, ce que lon appelle aujourdhui la thorie des systmes doit beaucoup au dveloppement de linformatique, et cest pour cette raison que de nombreux concepts prsents ici font rfrence ce domaine.

3.2.1 Le paradigme objet

3.2.1.1 La complexit des systmes

La complexit grandissante des systmes informatiques et lexplosion de leurs domaines dapplications, ont rendu le dveloppement lent, chaotique, induisant des risques de dfaillances dangereuses ou trs coteuses. La maintenance de tels systmes sest alors rvle extrmement complexe. La situation fut dcrite la n des annes 70 comme la crise du logiciel . Pour pallier cette complexit, une solution ft de dvelopper des vues simples des systmes, en cachant certaines informations. De plus la technique du diviser pour mieux rgner fut applique, et dans cette logique deux approches sont aujourdhui possibles. Lune concerne la vision du systme comme un ensemble de fonctions et de sous-fonctions permettant de dlivrer le service voulu, lautre sappuie sur une structure compose dentits collaborant entre elles an de fournir le service attendu, on parle alors de dveloppement orient objet. Cette deuxime approche de la programmation est apparue aprs la programmation fonctionnelle, mais a intgr beaucoup de techniques valides au fur et mesure des expriences de la programmation fonctionnelle. Les principales caractristiques de la programmation objet sont lencapsulation, lhritage et le polymorphisme. Ces trois techniques, largement dcrites dans les ouvrages sur lobjet (Jacobson, 1992; Booch, 1994; Rumbaugh et al., 1991),

3.2 UML : notation pour le dveloppement orient objet

A B
A et B communiquent

83

A B C

A contient B et C

Agrgation (faible)

Composition (forte)

F IG . 3.1 Interactions entre les objets permettent dapporter un systme une vision plus claire, une sparation entre entits plus importante, et ont amen les dveloppeurs introduire les notions de rutilisabilit, modiabilit et traabilit. Le dbat entre programmation fonctionnelle et programmation objet nest toujours pas termin aujourdhui. Des systmes trs complexes, valids exprimentalement utilisent encore une approche fonctionnelle et il est difcile pour les industriels de faire la transition vers lobjet. Beaucoup sont encore sceptiques quant lutilisation de lobjet dans certains domaines comme les systmes scurit critique1 . 3.2.1.2 La notion dobjet

Les objets du monde informatique sont des entits modlisant des entits physiques du monde rel (un capteur, un moteur, etc.) et des entits conceptuelles (un gnrateur de trajectoire, un contrleur daxe, etc.). Ces objets donnent une reprsentation simplie du monde rel, mais en communiquant entre eux, ils ralisent le service demand par lutilisateur. Chaque objet possde une identit unique, une partie visible (publique) pour les autres objets et une partie cache (prive). On reprsente les objets comme des rectangles, communiquant par des liens de communication comme reprsent en gure 3.1. Sur cette gure apparat une deuxime relation entre objets qui est la contenance. Nous verrons ultrieurement comment UML reprsente ces relations. 3.2.1.3 Les classes dobjet

Des objets distincts ayant une structure et un comportement commun, peuvent tre regroups en classes dobjets. Cela permet de spcier pour un ensemble dobjets, comme par exemple plusieurs capteurs de position, les aspects statiques et dynamiques, puis de dcrire le nombre et lidentit des objets qui vont tre instancis partir de cette classe. La gure 3.2 illustre le cas o lon instanciera deux objets capteurs de position, CapteurPosition1 et CapteurPosition2, partir de la classe CapteurPosition.
Voir les discussions sur le Safety http ://www.cs.york.ac.uk/hise/hise4/frames11.html
1

Critical

Forum

ladresse

web

84

La modlisation oriente objet avec UML

Instance Classe CapteurPosition LirePosition() Instance CapteurPosition2 CapteurPosition1

F IG . 3.2 Exemple de deux instances de la classe CapteurPosition

3.2.2 Le langage de modlisation UML

3.2.2.1 Pourquoi modliser ?

De la mme manire qu lorigine de la programmation oriente objet, le besoin daccder plus facilement aux informations de la conception a conduit la modlisation. Modliser un systme informatique sert donner des angles de vue diffrents la manire dun plan darchitecte. Par cet ensemble de vues, le modle permet de mieux comprendre le problme et sa solution. Les diffrents intervenants de la conception peuvent alors communiquer sur la base dune documentation avant que la fabrication (ou lintgration) ait eu lieu. Cela permet notamment dexprimer les rsultats de chaque tape du processus de dveloppement et ainsi de mieux dtecter les erreurs de dveloppement comme les omissions, les incomprhensions, les inversions, etc. Un des derniers points que lon peut noter est la gnration automatique de code depuis les modles, ce qui produit un gain de temps et une abilit plus importante si les modles ont t valids. Ce point est encore ltude, particulirement pour la modlisation en UML, qui comporte beaucoup dimprcisions et de choix laisss lutilisateur (ce qui en fait un langage semi-formel et non formel). Dune manire gnrale, la modlisation est un des moyens les plus importants pour la prvention des fautes de dveloppements, et aujourdhui, indpendamment du langage utilis, tous les projets industriels de grande envergure utilisent cette technique. 3.2.2.2 Bref historique de UML

UML (Unied Modeling Language) est un langage pour la reprsentation des constructions des systmes complexes. Ce langage a t propos suite une requte (RFP, Request For Proposal) lance par lOMG (Object Management Group) concernant une mthode oriente objet standard. Grady Booch, Jim Rumbaugh et Ivar Jacobson proposrent ce langage (et non une mthode comme cela tait demand) en uniant une partie de leurs travaux respectifs et en intgrant dautres travaux orients objet ou pouvant sappliquer lobjet comme les Statecharts dvelopps par Harel (1987). La premire version valide par lOMG fut la 1.1 en 1997, la version 1.4 est actuellement disponible (OMG, 2001), et les rexions pour la version 2.0 sont en cours (voir gure 3.3). Ds 1996, UML devint un enjeu stratgique et de

3.2 UML : notation pour le dveloppement orient objet

UML 2.0 UML 1.4 (Sept. 2001)
UML 1.3 UML 1.2

85

UML 1.1 (Nov. 1997) UML 0.9

(1996)

OMT Booch OOSE (Rumbaugh et al.) (Booch et al.) (Jacobson et al.)

F IG . 3.3 volution des versions du langage UML nombreux partenaires industriels participrent son laboration. Le succs que connat aujourdhui UML, faisant de ce langage un standard industriel, doit beaucoup la participation des industriels son dveloppement et son utilisation, mais prouve aussi que la communaut des informaticiens prouvait un rel besoin de clarication au sein des diffrents langages objets qui existaient. Le pari dUML est aujourdhui de se stabiliser une version 2.0, et de rsoudre les diffrentes critiques qui lui ont t faites (voir par exemple les articles de Hitz et Kappel (1998) et Simons et Graham (1999)). Les travaux se portent notamment sur des extensions de ce langage, appels prols, des domaines spciques comme le temps rel, ou les systmes scurit critique. 3.2.2.3 Les diagrammes UML

Le but de cette partie nest pas de proposer un cours sur la notation UML, largement dcrite dans de nombreux ouvrages (Muller, 2000; Booch et al., 1999; Roques et Valle, 2002), mais de prsenter les diffrents diagrammes qui seront utiliss par la suite. UML possde neuf diagrammes permettant de modliser les aspects structurels (ou statiques), les aspects dynamiques (changements dtats et rponses aux messages venant des autres objets), et les aspects propres la reprsentation des exigences fonctionnelles (diagramme des cas dutilisation). Le dtail de ces diagrammes est fourni en annexe A, nous donnons cependant une courte description pour chacun deux : 1. Les diagrammes des cas dutilisation dcrivent la faon dont le systme sera utilis. Ils montrent les relations entre les acteurs et les cas dutilisation du systme. Jacobson (1992) dnit les acteurs comme les entits interagissant avec le systme (les acteurs sont en gnral des utilisateurs ou des dispositifs extrieurs), et un cas dutilisation comme une manire spcique dutiliser le systme. 2. Les diagrammes de squence dcrivent une interaction entre plusieurs objets organise dans le temps. Cette interaction est un ensemble de messages changs entre les objets pour effectuer une opration ou obtenir un rsultat.

86

La modlisation oriente objet avec UML

3. Les diagrammes de collaboration prsentent linteraction organise autour des objets et de leurs liaisons. la diffrence des diagrammes de squence, ils ne montrent pas le temps comme une dimension spare. Ces diagrammes, ainsi que les diagrammes de squence, sont appels diagrammes dinteraction. 4. Les diagrammes de classes expriment de manire gnrale la structure statique dun systme, en termes de classes et de relations entre ces classes. 5. Les diagrammes dobjets sont des instances des diagrammes de classes, utiliss pour prsenter un contexte particulier du problme. 6. Les diagrammes dtats montrent le comportement des classes. Ils sont bass sur les statecharts dnis par Harel (1987). Ce sont des automates hirarchiques, permettant une certaine reprsentation du paralllisme. 7. Les diagrammes dactivits sont des variantes des diagrammes dtats, organiss par rapport aux actions (ou oprations). Ils sont utiliss pour reprsenter le comportement interne dune mthode ou dun cas dutilisation. 8. Les diagrammes de composants sont utiliss pour modliser les diffrents composants du systme et leurs relations. Ces composants peuvent tre des modules (ou units de compilation ou chiers), des sous-programmes (ou entits fonctionnelles), des tches (ou modules destins limplmentation des processus) et des sous-systmes (ou regroupement de modules, de sous-programmes, de tches et/ou dautres sous-systmes). 9. Les diagrammes de dploiement montrent lorganisation des composants matriels et le rattachement du logiciel aux dispositifs matriels (ou nuds). La particularit de ce langage est la possibilit dutiliser les diagrammes pour les concepteurs de la manire dont ils le dsirent. Si la smantique est normalise par lOMG, lutilisation et la modication nen reste pas moins ouverte. Cette caractristique, et la varit des diagrammes a conduit des utilisations trs varies dUML, et dans de nombreux domaines, allant de la modlisation de systmes organisationnels la modlisation de systmes temps rel. Bien que ce langage ait t cr la base pour des systmes informatiques, son volution spectaculaire fait de lui un langage systme au sens le plus large du terme. 3.2.2.4 Le mtamodle

Un mtamodle est un modle qui dcrit dautres modles. Ainsi, les diffrents concepts du langage UML ont t eux-mmes modliss avec UML comme le montre la gure 3.4. Cette modlisation rcursive, qui constitue le mtamodle, dcrit de manire semi-formelle les lments de modlisation ainsi que la syntaxe et la smantique de la notation qui permet de les manipuler. Le mtamodle devient, entre autres, loutil vricateur qui facilite lidentication des incohrences, notamment par lutilisation de rgles de bonne modlisation2 , exprimes dans la version 1.4 en langage OCL (Object Constraint Language). Dans les versions venir
2

qui peut tre une traduction de well-formedness rules

3.2 UML : notation pour le dveloppement orient objet

Contrleur Axe2 Contrleur Mouvements2Axes Contrleur Axe1

87

Objets

///////////////////////////////////////////////////////////////////////////////////////////////////////

Classes Contrleur Mouvements ContrleurAxe

///////////////////////////////////////////////////////////////////////////////////////////////////////

Mtamodle Classe Association

F IG . 3.4 Objets, classes et mtamodle dUML, la spcication dUML est spare ce jour en deux documents complmentaires. Tout dabord linfrastructure (OMG, 2003b) dnit les concepts fondamentaux du langage mme et se place en tant que mtamodle ou mta-mtamodle 3 . Puis la superstructure (OMG, 2003a) se place un niveau utilisateur en se basant sur les concepts de linfrastructure.

3.2.3 Processus de dveloppement et UML

Bien que la demande lance par lOMG concernait une mthode de dveloppement orient objet, UML na t introduit quen tant que langage. Il nexiste pas aujourdhui de mthode de dveloppement standard propre UML, et lon peut trouver suivant les domaines dapplications des mthodes diffrentes (et sans doute autant que de dveloppeurs !). Ainsi, malgr un effort de standardisation autour du Processus Uni (Jacobson et al., 1999), commercialis par la socit Rational4 sous le nom de RUP (Rational Unied Process, prsent par Kruchten (1999)), on peut trouver des mthodes comme COMET de Gomaa (2000) ou ROPES de Douglass (1999), adaptes aux systmes temps rel. Bien que ces mthodes aient une approche diffrente de lenchanement des activits du processus de dveloppement, et utilisent de manire diffrente les diagrammes UML, il existe nanmoins des rgles communes que lon retrouve dans ces mthodes. Selon les auteurs de UML, le processus utilisant cette notation doit tre : itratif et incrmental, centr sur larchitecture, pilot par les cas dutilisation. Comme pour la cration dUML, ces principes drivent de nombreux travaux sur le domaine, et le concept est de les runir pour se diriger vers un standard.
Il est possible de remonter de niveau conceptuel un grand nombre de fois, et pour simplier le terme de mtamodle suft 4 http ://www.rational.com
3

88
Analyse
Capturer et valider les CU

La modlisation oriente objet avec UML

Conception et ralisation
Raliser les CU

Test
Vrifier que les CU sont satisfaits

Les cas dutilisation relient ces tches

F IG . 3.5 Dveloppement pilot par les cas dutilisation (CU) 3.2.3.1 Pilot par les cas dutilisation

Les cas dutilisation, dvelopps par Jacobson (1992), permettent didentier et de modliser les besoins fonctionnels lors de lanalyse. Dans un dveloppement utilisant UML, ils permettent de relier les diffrentes activits comme le montre la gure 3.5. Le fait de sappuyer sur ces cas dutilisation, impose aux concepteurs pour chaque tape du dveloppement de faire le lien avec les exigences. Et en effet, depuis lanalyse jusquaux tests, chaque quipe de dveloppement, ou chaque concepteur, peut raliser ou tester un ou plusieurs cas dutilisation. 3.2.3.2 Itratif et incrmental

Un processus itratif consiste intgrer le fait que les exigences voluent au cours dun projet, en dveloppant des prototypes. La plupart des mthodes sappuient sur le modle en spirale de Boehm (1988) qui consiste raliser des prototypes en enrichissant chaque version de nouvelles exigences. La reprsentation de ce modle de processus sous forme de spirale, permet de dnir des cadrans dactivits communs chaque itration. Par exemple, pour chaque prototype, il est possible de dnir des tapes danalyse, conception, implmentation et de test. Les premires itrations permettent dexprimenter et de valider des technologies, de planier la suite du dveloppement, et surtout de dnir le noyau darchitecture du systme. Chaque itration permet de raliser une partie des fonctionnalits du systme. On parle alors de processus incrmental. Le point important concerne alors le choix des exigences que lon souhaite dvelopper, et par extension UML, le choix des cas dutilisation raliser. Il convient donc dtablir des priorits entre cas dutilisation. Certains lient cette problmatique la notion de risque (Gomaa, 2000; Douglass, 1999) et utilisent le terme danalyse des risques pour classer les cas dutilisation. Lemploi de ce terme est ici relatif aux dommages lis la gestion de projet, cest--dire les performances du systme ralis, les dlais, les cots, etc. Cette analyse des risques est donc en fait une valuation des diffrentes contraintes qui psent sur le concepteur, et qui lamneront choisir les cas dutilisation quil ralisera en premier lieu. Ltude que nous ralisons dans ce mmoire, ne concerne pas ce type de risques, puisque les seuls dommages que nous traiterons concernent la scurit des biens et des personnes. Cependant la terminologie et les concepts fondamentaux sont communs ces diffrents domaines.

3.2 UML : notation pour le dveloppement orient objet

89

Vue logique Vue des cas dutilisation Vue de ralisation

Vue des processus

Vue de dploiement

F IG . 3.6 Le modle darchitecture 4+1 vues, gure tire de Kruchten (1999) 3.2.3.3 Centr sur larchitecture

La recherche de la forme gnrale du systme doit tre faite ds le dbut du dveloppement et va ensuite tre complte tout au long des diffrentes tapes. Une approche systmatique consiste rechercher une architecture : adapte aux changements, pour et avec la rutilisation, comprhensible intuitivement, satisfaisant les cas dutilisation. La notion darchitecture est trs diffuse et parfois mal apprhende. Elle consiste nanmoins, pour un systme logiciel, dnir la faon dont le systme est construit. Ainsi elle est souvent reprsente par des packages et des sous-systmes interagissant entre eux pour fournir le service demand. Cependant la vision de larchitecture ne peut se rduire ces reprsentations. Par analogie, un architecte peut sil le dsire, consulter les plans dune maison suivant diffrentes vues, ayant chacune une granularit (niveau de dtail) diffrente. De la mme manire, le systme logiciel peut tre reprsent suivant cinq vues reprsentes sur la gure 3.6 : La vue logique dcrit les aspects statiques et dynamiques du systme en termes de classes et dobjets. Elle se concentre sur labstraction et lencapsulation et met en jeu des objets et des classes, ainsi que des collaborations et des interactions autour de ces objets. Cette vue est compose de diagrammes de classes, dobjets, de squence, de collaboration et dtats. La vue de ralisation se proccupe de lorganisation des modules dans lenvironnement de dveloppement. Elle montre lallocation des classes dans les modules, et lallocation des modules dans les sous-systmes. Les sous-systmes sont eux-mmes organiss en niveaux hirarchiques comportant des interfaces bien dnies. Cette vue traite les modules, les sous-programmes, les sous-systmes et les tches, dans des diagrammes de composants. La vue des processus reprsente la dcomposition en ots dexcution (processus, ls dexcution et tches), la synchronisation entre ots et lallocation des objets et des classes au sein des diffrents ots. Elle prend toute son importance dans des environne-

90

La modlisation oriente objet avec UML

ments multitches. Elle fait apparatre les tches, les ls dexcution, les processus et les interactions, dans des diagrammes de squence, de collaboration et dtats. La vue de dploiement dcrit les ressources matrielles et limplantation du logiciel dans ces ressources. Elle prend toute son importance lorsque le systme est distribu. Cette vue se concentre sur les nuds, les modules et les programmes principaux, dans des diagrammes de dploiement. La vue des cas dutilisation unie les quatre vues prcdentes. Les cas dutilisation permettent didentier les interfaces critiques, et forcent les concepteurs se concentrer sur les exigences fonctionnelles. Elle rend compte des acteurs, des cas dutilisation, des classes et des collaborations laide de diagrammes des cas dutilisation et de diagrammes de squence ou de collaboration. Il est important de noter que ce concept nest pas une proposition de mthode, et que ces vues sont compltes tout au long du processus itratif et incrmental mme si certaines de ces vues sont plus en rapport avec certaines tapes du processus de dveloppement. Bien que cette vision ait t propose ds la cration dUML, il est cependant possible de trouver dautres reprsentations. Gomaa (2000) propose notamment de faire la distinction entre la reprsentation du comportement dynamique (vies possibles des objets) et celle du comportement interactif (ots de contrle entre les objets). Douglass (1999) utilise pour dcrire les vues de la conception les notions de conception architecturale (structures physiques, tches, composants, etc.), de conception mcanistique5 (ensemble des classes dobjets collaborant), et de conception dtaille (chaque classe est rafne en terme dattributs et doprations). La conclusion que lon peut tirer de ces diffrentes approches est que UML, "pouvant sappliquer nimporte quelle mthode" selon ses auteurs (Booch et al., 1999), impose tout de mme par lensemble de ses diagrammes un cadre dexploration du systme et de son architecture qui tend se standardiser.

3.3

Travaux actuels sur le dveloppement orient objet et la sret de fonctionnement

Bien que largement tudie dans le domaine de la recherche, lintgration du dveloppement orient objet dans des projets industriels de systmes scurit critique est encore ltat dvaluation. An deffectuer un tat de lart des tudes sur les rapports entre lorient objet et la scurit, nous avons considr globalement la sret de fonctionnement (la scurit tant un des attributs de la sret de fonctionnement). Il est en effet beaucoup plus rare de trouver des tudes sur les liens entre le risque et ce langage. Il existe cependant des travaux comme ceux de Tah et Carr (2001) et de Gabbar et al. (2001), o les auteurs utilisent la notation UML pour modliser le processus de gestion du risque (acteurs et activits de la gestion
5

Traduction de Mechanistic Design

3.3 Travaux actuels sur le dveloppement orient objet et la sret de fonctionnement

91

du risque), de la mme manire que cela tait fait pour le processus de dveloppement avec UP (Unied Process) (Jacobson et al., 1999)) et plus rcemment SPEM (Software Process Engineering Metamodel6 ). Il est important de noter que ni UP ni SPEM incluent les notions relatives au risque. Cependant les travaux actuels concernant la modlisation de lactivit de gestion du risque au sein du processus de dveloppement se placent un niveau dabstraction trs lev et ont pour vocation daider les concepteurs sorganiser au sein de lentreprise. Cela ne concerne donc pas lactivit de gestion du risque elle-mme, ce qui nous intresse ici. De plus les particularits du domaine de la robotique de service et la nouveaut du domaine font quil est encore impossible aujourdhui davoir le recul ncessaire pour effectuer une telle analyse. Pour ces raisons, nous nous limiterons donc aux tudes plus techniques concernant la sret de fonctionnement. En suivant la classication de Laprie (1992), il est possible de classer les moyens de la sret de fonctionnement suivant quatre concepts rsums ci-dessous : la prvention des fautes, ou comment empcher loccurrence ou lintroduction de fautes, qui relve de lingnierie systme (application de mthodes de dveloppement, utilisation de langages formels ou semi-formels comme UML, etc.) ; la prvision des fautes ou comment estimer la prsence, la cration et les consquences des fautes des composants du systme, en utilisant des techniques danalyse quantitatives et qualitatives. Cest principalement cette activit qui est couverte pas lanalyse du risque ; llimination des fautes, ou comment rduire le nombre et la gravit des fautes, par exemple par des techniques de vrication (test fonctionnel, structurel, etc.) ; et la tolrance aux fautes, ou comment fournir un service mme de remplir la fonction du systme en dpit de fautes, qui concerne par exemple le traitement derreur par le systme (dtection, diagnostic et recouvrement). Cette terminologie permet deffectuer une classication des aspects lis la sret de fonctionnement. Cependant les analyses couvrent en gnral simultanment plusieurs de ces aspects. Par exemple, lorsque lon effectue une analyse du risque comme prsente au chapitre 1, une partie importante concerne la prvision des fautes par lutilisation de techniques comme lAMDEC, ou les arbres de fautes. Le fait de baser cette analyse sur une modlisation semi-formelle en UML contribue la prvention des fautes. Puis, les rsultats de lanalyse du risque peut mener des choix de mcanismes de tolrance aux fautes comme par exemple la redondance, quil conviendra de tester et de valider en utilisant des techniques dlimination des fautes. Ceci montre bien que cette sparation entre les diffrents moyens est dun niveau dabstraction lev et que, dans la pratique, les tudes couvrent plusieurs aspects. Il est important de noter que le but de cette section nest pas deffectuer un tat de lart exhaustif sur la sret de fonctionnement en gnral et lorient objet, mais de se concentrer sur les aspects
6

http ://www.omg.org/technology/documents/formal/spem.htm

92

La modlisation oriente objet avec UML

concernant (ou pouvant concerner) la scurit et lutilisation de langages de modlisation orients objet.

3.3.1 Prvention des fautes

Lutilisation de langages de modlisation, contribue la prvention des fautes. En effet, la qualit du formalisme utilis aide le dveloppeur raliser des modles clairs et non ambigus. Ainsi, en UML, la reprsentation des modles dynamiques repose sur de nombreuses informations prsentes dans les modles statiques (nom des mthodes, des attributs, des classes, etc.), et il est alors ais dutiliser des outils simples de vrication de la cohrence de ces informations communes. De plus, un langage de modlisation comme UML contribue la tracabilit qui est une des exigences fondamentales de la certication (notamment pour les systmes scurit critique). En effet, lutilisation de cette notation et des mmes diagrammes pour les diffrentes tapes du processus de dveloppement, permet de suivre le cycle de vie de chaque exigence ou de chaque composant. Lutilisation dUML en tant que langage semi-formel contribue la prvention des fautes, mais comporte certaines limites et notamment au niveau de lexpression de certaines contraintes. Ainsi Bitsch (2002) propose dutiliser UML pour les exigences fonctionnelles et TimeLogic pour les contraintes de temps (exigences non fonctionnelles). De manire similaire, Cichocki et Grski (2000) utilisent lorient objet puis Z pour exprimer les contraintes de scurit dun systme. Bondavalli et al. (2001) sappuient sur des extensions dUML (les tagged values, les strotypes, et les contraintes dnies dans la norme de lOMG (2001)) permettant de prendre en compte un certain nombre dexigences lies la sret de fonctionnement. Lutilisation de ces techniques combines, permet en premier lieu de reprsenter de faon formelle ou semi-formelle les contraintes non-fonctionnelles, puis de les driver pour la conception ou la validation des modles (ce dernier point concerne llimination des fautes prsente dans la section 3.3.4). La modlisation des exigences de sret de fonctionnement ntait pas traite dans les premires versions dUML. Les exigences taient dcrites de manire textuelle et gnralement en accompagnement des cas dutilisation. Cependant il existe aujourdhui plusieurs travaux concernant la reprsentation de ces contraintes. La notion de QoS, Quality of Service, semble accepte aujourdhui dans de nombreux domaines pour regrouper des caractristiques dun service, telles que les performances et les attributs de la sret de fonctionnement (abilit, scurit, etc.). Dans une rponse un appel de lOMG sur les problmes temps rel, Selic et al. (2000) ont prsent plusieurs moyens de modlisation des contraintes de type temps rel en utilisant la notion de QoS, ce qui a donn lieu aujourdhui un prol UML (OMG, 2002b). De la mme manire Douglass (1999) intgre ces notations pour exprimer des contraintes de performances, de scurit et de abilit. La notion de QoS, principalement utilise lorigine pour les systmes distribus, a fait lobjet dun RFP de lOMG (2002a), pour une application au langage UML.

3.3 Travaux actuels sur le dveloppement orient objet et la sret de fonctionnement

93

Laspect prvention des fautes concerne aussi la manire dont le langage UML sera utilis. Il existe en effet un certain nombre de travaux abordant cet aspect, qui pourrait correspondre une analyse des risques lis lutilisation dUML. Plus gnralement, lapproche objet est analyse en terme de certication, et certaines caractristiques de lobjet juges dangereuses sont contraintes ou interdites. Rierson (1999) a rdig un rapport pour la FAA (Federal Aviation Administration) o sont recenss les problmes engendrs par les concepts objets. partir de ce travail, lAVSI (Aerospace Vehicule Systems Institute) a rdig un guide (AVSI, 2002) sur lutilisation de lorient objet en vue dune nouvelle version de la norme avionique DO178B/ED-12 Revision B (1992). Si certaines constructions sont dangereuses, dautres en revanche ont t valides sur de nombreuses applications. Ces constructions gnriques ont alors t assimiles des patrons (patterns en anglais) pouvant tre utiliss pour dautres applications. Les patrons sont des solutions des problmes prcis dans des contextes bien dnis. Manhes (1998) prsente une synthse des diffrentes traductions que lon peut trouver pour cette notion. Ces patrons sont en gnral prsents sous forme de catalogues. Il existe un certain nombre de patrons modliss en UML dans louvrage de Gamma et al. (1995). Douglass (1998) propose un srie de patrons propres aux applications temps rel scurit critique les plus frquents. Dans un rapport prsentant une rponse pour un RFI (Request For Information) lanc par lOMG, Daugherty et al. (2002) proposent un ensemble de patrons de spcication et de conception permettant de justier de la qualit dun logiciel en vue de la certication. Les catalogues de patrons prsents dans les rfrences prcdentes concernent plus gnralement lanalyse ou la conception. Cependant, il est possible de trouver des "rgles" de programmation pour les langages objet, comme le prsente Binkley (1995) pour le langage de programmation C++, qui constituent des patrons dimplantation.

3.3.2 Prvision des fautes

Cette activit doit permettre danticiper les fautes par des techniques didentication, et dvaluation de leur effets. De nombreux travaux ont t effectus sur la notion de composant, qui est proche de celle dobjet, en considrant que ces composants ont tous des entres et des sorties (par analogie avec les composants lectroniques). Yacoub et al. (2000) identient les composants critiques dun systme logiciel en calculant pour chaque composant un facteur de risque valu en fonction de la complexit (avec des mtriques dnis) et de la gravit dune dfaillance de ce composant. Cela permet ensuite de se concentrer sur certains composants jugs critiques au dtriment dautres moins important pour la scurit. De la mme manire Papadopoulos et Maruhn (2001), se basent sur des modles de composants et utilisent la technique danalyse HAZOP (Hazard Operability) pour gnrer automatiquement par la suite des arbres de fautes. Ces aspects rejoignent la notion de SIL (Safety Integrity Level), utilise dans les normes IEC 61508 (2001), mais sont difcilement applicables un systme modlis en

94

La modlisation oriente objet avec UML

UML. En effet la notion dobjet (qui peut devenir par la suite un composant) se diffrencie trop de celle de composant (Booch et al., 1999) pour utiliser efcacement une dmarche similaire. Plus proche de lobjet et dUML, Grski et Nowicki (1997) dnissent des attributs critiques dobjets du systme, et se concentrent sur les effets des variations nfastes de ces attributs. Ces travaux ont notamment men les auteurs aux notions de sous-systmes critiques (un sous-systme est trs proche de la notion de composant) et lidentication de comportements dangereux sur la base des diagrammes dtats (Nowicki et Grski, 1998). La dmarche est identique aux prcdentes, et consiste donc identier des parties du systme susceptibles de crer des dommages. Cependant les rapports avec les objets mmes du systme sont encore difciles valuer. Parmi les mthodes analytiques permettant la prvision des fautes, lAMDEC (cf. chapitre 1) est sans doute une des plus utilises lors des analyses fonctionnelles. Elle peut tre nanmoins applique des composants logiciels et leurs liens comme le font Yacoub et al. (2000). Cette approche est similaire ltude des composants lectroniques et ne prend pas en compte les concepts importants de lapproche objet. Bitsch (2002) propose dutiliser cette technique en analysant les mthodes des objets du systme la manire dune analyse de fonctions, et identie ainsi les rpercussions sur le systme. Dans un cas dtude sur la conception dune voiture, Johannessen et al. (2001) utilisent les cas dutilisation dUML pour exprimer les besoins et effectuent une AMDEC sur ces diagrammes. Le lien avec UML est cependant rduit car les cas dutilisation identis dans cet article, comme Stabilit lors du freinage , correspondent des besoins non fonctionnels et ne peuvent donc pas tre drivs vers des objets. Parmi les autres techniques danalyse, il convient de citer lanalyse des arbres de fautes, qui est en gnral couple avec une AMDEC. Grski et al. (1996) montrent comment ils se basent sur les arbres de fautes pour exprimer des classes de fautes dun modle. Le rapport avec les objets du systme reste complexe, et ltude des arbres semble tre faite en parallle sans vritable interaction avec les modles UML. Pai et Dugan (2002) prsentent une mthode et des algorithmes permettant de gnrer automatiquement des arbres de fautes partir de modles UML. Les arbres de fautes qui sont gnrs par cette mthode sont en fait des modles de abilit, qui permettent de dcrire en parallle des modles UML, comment une dfaillance peut survenir. Bondavalli et al. (2001) ont construit de la mme manire des modles de abilit (IM pour Intermediate Model) bass sur les diagrammes UML, drivs ensuite en Timed Petri Nets (Bondavalli et al., 1999b; Majzik et Bondavalli, 2000; Bondavalli et al., 1999a). Ces techniques permettent avant tout de fournir des outils aux ingnieurs souhaitant utiliser UML, en palliant certains manques dUML comme lexcution des modles. Cependant, les techniques que lon vient de prsenter sappuient fortement sur la notion de composant qui est diffrente de celle dobjet ou de classe. De plus, elles requirent la connaissance dautres langages ou techniques en complment UML ce qui complique le dveloppement.

3.3 Travaux actuels sur le dveloppement orient objet et la sret de fonctionnement

95

3.3.3 Tolrance aux fautes

Les tudes lies la tolrance aux fautes concernent principalement des analyses darchitectures tolrantes aux fautes, ou des mcanismes intgrs au systme, permettant de raliser les activits de dtection, de diagnostic et de recouvrement derreur. Lutilisation dUML permet alors de modliser la fois les aspects purement fonctionnels et les aspects concernant la tolrance aux fautes (Ferreira et Rubira, 1998). Beaucoup de travaux concernent cependant la abilit et les systmes distribus (Selic, 2000), et plus rarement la scurit dans des systmes temps rel. De plus, cet aspect de la sret de fonctionnement concerne plus frquemment la conception que lanalyse. Cest pour ces raisons que les aspects de la tolrance aux fautes que nous aborderons par la suite au sein de lanalyse du risque, ne concerneront que lutilisation de patrons de sous-systmes de tolrance aux fautes modlisables en UML.

3.3.4 limination des fautes

Cet aspect que lon peut aussi qualier de validation ou vrication de la sret de fonctionnement (Geffroy et Motet, 1998, Chap.9) regroupe principalement des techniques de vrication et de test. Ces vrications peuvent tre effectues plusieurs niveaux du processus de dveloppement. Au niveau des spcications, il convient de valider la compltude du modle, qui exprime le fait quil existe une rponse du systme pour toutes les squences dentres possibles, et sa consistance retant labsence dexigences conictuelles ou de non dterminisme. Ces aspects sont frquemment tudis en utilisant des diagrammes dtats lors de lanalyse (Pap et al., 2001). Pendant la conception, ce sont encore les diagrammes dtats qui sont le plus tudis, mais les solutions consistent en gnral transformer ces diagrammes UML en modles exprims avec dautres langages formels (Bitsch, 2002; Traon et al., 2000; Chevalley et Thvenod-Fosse, 2001). Ceci est principalement d au fait quil existe des logiciels de validation des modles trs performants sappuyant sur dautres langages formels que UML, alors que pour UML certains logiciels quivalents sont encore ltat de dveloppement. Au sein dun processus de dveloppement, llimination des fautes fait partie intgrante de nombreuses mthodes, comme par exemple le cycle en V conseill dans la norme IEC 61508 (2001), et est fortement li au processus de gestion du risque (validation des exigences non fonctionnelles de scurit par exemple). Cependant, pour notre tude nous naborderons pas ce point considrant que les techniques dlimination des fautes sont utilises aprs les principales tapes dune analyse du risque sans quil y ait dinteraction entre ces activits.

96

La modlisation oriente objet avec UML

3.3.5 Conclusions sur la sret de fonctionnement et le dveloppement orient objet

Cette section a montr quil existait pour chacun des moyens de la sret de fonctionnement (prvention, prvision, limination et tolrance aux fautes) des interactions avec UML. Une grande partie de ces travaux concerne la prvention des fautes, et notamment celles introduites par lhomme. Lutilisation dun langage de modlisation permet en effet de rduire les erreurs humaines de conception. Une autre partie de ces travaux concerne les techniques dlimination des fautes comme le test des modles qui se concentre sur certaines constructions (diagramme dtats principalement). En raison de limpossibilit dexcuter les modles UML (dans sa version actuelle), de nombreux travaux de recherche sorientent vers la conversion des diagrammes UML vers dautres modles excutables. La tolrance aux fautes regroupe principalement des recherches sur des architectures de systmes distribus, modlisables en UML. Dans le cadre de la gestion du risque, les techniques de tolrance aux fautes sont introduites lors de la matrise du risque. Ces techniques sont principalement des solutions technologiques qui ne seront abordes quau titre dexemple dans ce mmoire. La prvision des fautes concerne des techniques que lon retrouve au sein des la gestion du risque. En effet, on retrouve dans cette thmatique des travaux sur les interactions entre des techniques comme lAMDEC ou les arbres de fautes avec UML. Au sein de lanalyse du risque, lidentication des dangers inclut la prvision des fautes et sappuie donc sur les mmes techniques que celles de la sret de fonctionnement. La plupart des travaux sappuient sur la notion de composant et des premires connexions entre UML et ces techniques ont pu tre faites. Sur ce point, nous montrerons dans le chapitre suivant comment notre approche se dmarque de ces travaux, notamment par la prise en compte de concepts diffrents de celui de composant.

3.4

Conclusion

Il est important de noter que UML est un langage et non une mthode et cest sans doute une des raisons qui a fait son succs. Cela nous permet donc de lutiliser pour notre dmarche base sur lanalyse du risque et prsente dans le chapitre suivant. Les diffrentes rgles dutilisation induites par les concepts objets et propres ce langage, ainsi que la varit des diagrammes permettant diffrents points de vue, et les trois principes lis au processus de dveloppement (itratif et incrmental, pilot par les cas dutilisation, et centr sur larchitecture), en font une technique dite de prvention des fautes dans le vocabulaire du domaine de la sret de fonctionnement. Ces diffrents lments permettent en effet de suivre un dveloppement cohrent, o chaque tape repose sur les diagrammes de ltape prcdente, et permettent de rduire loccurrence de fautes ou de modlisation errone.

3.4 Conclusion

97

Les diagrammes des cas dutilisation permettent notamment de garantir la traabilit qui est un aspect fondamental de la certication. Il est aujourdhui admis que lutilisation des langages objets ont aussi des apports en modiabilit et rutilisabilit. De plus, le langage UML est un langage centr humain , de par la modlisation des besoins par les cas dutilisation dont cest la caractristique principale, mais aussi par la possibilit de reprsenter les acteurs humains dans la plupart des diagrammes. Une des caractristiques dUML, qui rpond un des besoins de notre dmarche exprim dans la conclusion du premier chapitre, est son aspect systme de par la complmentarit des diagrammes, dont la smantique tout en tant formalise par lOMG permet des adaptations en fonction de lapplication dveloppe. De plus la notation graphique permet de communiquer plus facilement avec tous les acteurs du dveloppement dun systme complexe. Cependant, ce langage comporte des points ngatifs quil convient de souligner. Tout dabord le pouvoir de vrication automatique des modles est rduit. Ceci a conduit au dveloppement de techniques de conversion de ce langage vers dautres langages, permettant dutiliser des outils de vrication formelle. Ce point dtude, source de nombreuses recherches, ne sera pas abord dans ce mmoire. Un autre point important identi dans ce chapitre est lincompatibilit des techniques de la sret de fonctionnement utilises jusquici pour des analyses fonctionnelles ; le fait de passer en langage objet remet en question ces techniques. Il ressort travers des tudes prsentes dans la dernire section (3.3), que les rapports entre ces techniques et la modlisation oriente objet sont encore ltat dvaluation. En dernier point, lutilisation des concepts objet est aussi une technique qui peut tre lorigine dincompatibilits avec le domaine des systmes scurit critique. Tout dabord en terme de performance des logiciels, les programmes dvelopps en objet ont tendance tre plus volumineux, dont lexcution requiert la collaboration de nombreux objets informatiques. De plus, pour une utilisation systme, les concepts mme de lobjet peuvent crer des difcults de comprhension, notamment pour des concepteurs utilisant lanalyse fonctionnelle. Cependant, nous considrons que ces problmatiques, concernant en n de compte lanalyse et lvaluation des risques lis lutilisation dun langage objet pour le dveloppement des systmes scurit critique, sont sujets dautres travaux complmentaires ce mmoire.

Chapitre 4 Intgration dUML pour lanalyse du risque

4.1 Introduction

La matrise de la scurit dune application de robotique de service ne peut se rduire lutilisation de techniques particulires comme les muscles articiels prsents au chapitre 2. Le chapitre 1 avait en effet montr quune approche de la scurit plus gnrale et lie la notion de risque tait possible, et nous avions conclu sur les besoins dune telle approche pour la robotique de service. Tout dabord, face la ncessit de dnir un vocabulaire du risque stable et non ambigu, le chapitre 1 a prsent une synthse des diffrents concepts prsents dans dautres domaines, et les a adapts au domaine de la robotique de service (et plus particulirement la robotique mdicale). Ceci a conduit lidentication dactivits permettant de grer le risque, la principale tant lanalyse du risque. Cette analyse, reposant sur la notion de modle, doit pouvoir tre couple un langage utilis pour le processus de dveloppement. Le chapitre 3 a prsent les caractristiques du langage UML, et a montr comment il rpond diffrents besoins identis dans le chapitre 1. Parmi les points importants, il a t soulign la possibilit dutiliser cette notation au sein des diffrentes tapes du dveloppement, et ceci pour de nombreux domaines. Cet aspect pluridisciplinaire fait dUML un langage adapt la modlisation systme. De plus, grce aux cas dutilisation, la prise en compte de lhumain est au centre de nombreux modles. Enn, lutilisation de ce langage contribue amliorer la traabilit des choix de conception, essentielle pour la scurit et la certication. La dmarche prsente dans ce chapitre valide lutilisation dUML pour lanalyse du risque dun systme de robotique de service. Les sections de ce chapitre suivent les tapes de lanalyse du risque introduites au chapitre 1. Une vue gnrale de ces tapes est donne gure 4.1. Une premire section (4.2) traite de la dnition du systme et de son utilisation, o sont prsentes les tapes de dnition du mtier, dintgration du robot dans la tche de service, de dnition des frontires du systme et de description des tches des acteurs. Ces activits permettront de souligner limportance des cas dutilisation et des concepts lis

100

Intgration dUML pour lanalyse du risque

Analyse du risque

1
Analyse du risque
Modlisation en UML

1 Identification de

lemploi prvu, dfinition du systme

2 Identification des

2
Analyse prliminaire des risques

phnomnes dangereux et estimation du risque

Analyse des Modes de Dfaillance et de leurs Effets Critiques

Analyse des arbres de fautes

F IG . 4.1 Vue globale de la dmarche prsente dans ce chapitre aux facteurs humains. Ceci conduira la ralisation de modles, qui seront exploits dans une deuxime section (4.3) sur lidentication des dangers et lestimation du risque. Les techniques danalyse que sont lAPR (Analyse Prliminaire des Risques), lAMDEC (Analyse des Modes de Dfaillance et de leurs Effets Critiques) et les arbres de fautes seront utilises lors de cette tape. Une partie de cette analyse, concernant lutilisation de lAMDEC, montrera comment la notion de Message en UML permet de dnir des modles derreur applicables aux diffrents domaines que sont la mcanique, llectronique, linformatique et les erreurs humaines. Tout au long de la prsentation de cette dmarche, laccent est mis sur limportance des analyses transversales. Comme cela est soulign prcdemment, il est fondamental pour la scurit, deffectuer un moment donn une analyse permettant de regrouper les diverses informations fournies par les spcialistes de chaque domaine. Cest ce niveau que se place cette dmarche systme .

4.2

Description du systme et de son utilisation

La partie 1.4.3.2 indique que toute analyse du risque sappuie sur une description du systme et de son utilisation prvue. Certains lments comme les ux dnergie, les frontires du systme et les interfaces doivent tre correctement dnis pour pouvoir effectuer lanalyse du risque. Ces diffrents points peuvent se retrouver dans la vue des cas dutilisation (cf. section 3.2.3.3) qui exprime la manire dont les acteurs veulent utiliser le systme. Il est en effet possible, grce au diagramme des cas dutilisation, de modliser les exigences fonctionnelles. Nous prsenterons notamment ici une manire de rajouter les exigences non fonctionnelles lies la scurit. De plus, UML est un langage dit orient utilisateur , en raison notamment de la modlisation des utilisateurs au sein de la plupart des diagrammes.

4.2 Description du systme et de son utilisation

101

Ceci est fondamental pour un systme scurit critique, o, tout instant du dveloppement, le concepteur doit garder lesprit lexigence principale : la scurit des acteurs humains.

4.2.1 Modlisation du mtier

Il existe des tches impossibles raliser sans laide dun robot, comme par exemple lextraction de minerai sur Mars, cependant si lon se place dans un cadre humain (pas sur Mars), la plupart des applications de robotique de service reproduisent des gestes que lhomme tait amen faire auparavant. Dans la smantique dUML, le terme de mtier est utilis pour dsigner entre autres1 une tche ou un ensemble de tches, spciques un domaine, et gnralement ralises par plusieurs acteurs spcialiss. Ainsi, une opration chirurgicale de la hanche est un mtier, comme lest lassistance des personnes handicapes. Bien avant que ces mtiers incluent lutilisation de robots, les humains ont dvelopps des organisations pour la ralisation de ces tches. En vue de linclusion du robot pour lexcution de ces tches, nous proposons dutiliser UML et une extension de ce langage, la modlisation mtier (ou business modeling prsent par Eriksson et Penker (2000)), permettant de dcrire les tches propres un mtier. Cela permet de mieux le comprendre, et de faciliter la communication, surtout lorsque des spcialistes, comme par exemple les mdecins, et les ingnieurs en charge du dveloppement devront collaborer. La modlisation dun mtier peut tre faite avec un diagramme de cas dutilisation, comme cela sera prsent dans le chapitre 5. Nous ne donnons pas ici dexemple complet car cela demande une description complte de lorganisation dun mtier. Cependant, les cas dutilisation mtier correspondent en gnral aux diffrentes tches qui incombent aux acteurs comme par exemple dans le cadre mdical : grer les rglages dun dispositif mdical, raliser un geste mdico-chirugical, tablir un diagnostic, grer les instruments chirurgicaux, etc. ces cas dutilisation sont relis les diffrents acteurs du mtier (docteur, assistant, et patient), et il est possible de reprsenter les interactions entre ces acteurs avec des diagrammes de classes ou de squence. Ainsi, Jannin et al. (2001) utilisent un diagramme de classes pour reprsenter les diffrents objets quun chirurgien manipule lors de la planication doprations de neurochirurgie guide par limage. Dune manire gnrique, cette modlisation mtier permet de reprsenter les objets ncessaires la planication (tapes, cibles, actions, section du cerveau, etc.) qui permettent de comprendre la problmatique du mtier et de spcier les besoins du logiciel de planication. Le travail danalyse du mtier consistant en sances dobservation, en interviews dacteurs et en analyses diverses, est souvent ralis de manire empirique o toutes les informations sont stockes de manire non formelle. Il est alors difcile dassurer la traabilit de ces informations lors de la suite du dveloppement. Les cas dutilisation permettent de donner un cadre aux diffrentes analyses du mtier. Par exemple, le cas dutilisation que lon nomme
1

Il est possible de trouver des objets mtier, comme une sonde chographique par exemple

102

Intgration dUML pour lanalyse du risque

Raliser geste mdical (cf. gure 4.2(a)) dans le cadre dune opration chirurgicale, doit tre clairement dni en terme damplitude de mouvements et de forces appliques sur le patient, mais est indpendant par exemple du cas dutilisation Rgler les paramtres dun dispositif mdical. Une modlisation complte doit alors permettre de classer chaque action des acteurs dans un cas dutilisation. Les cas dutilisation sont documents par une description textuelle que les concepteurs adaptent en fonction de lapplication. Dans le cadre des robots de service nous proposons de dcrire les cas dutilisation suivant plusieurs champs : nom du cas dutilisation ; acteurs principaux et secondaires ; description du scnario principal du cas dutilisation ; pr-condition lexcution du cas dutilisation ; post-condition lexcution du cas dutilisation ; alternative au scnario principal ; contraintes relatives la qualit du service (QoS) ; contraintes techniques lies la conception ; remarques diverses. Le concept de qualit de service (QoS) sera dcrit ultrieurement (section 4.2.3), et un exemple de description textuelle dun cas dutilisation sera donn sur la gure 4.4. Sur la base des cas dutilisation mtier, et de leur description textuelle, il est ensuite plus facile de formuler les exigences pour lintgration dun robot au sein de la tche comme cela est prsent dans la section suivante.

4.2.2 Intgration du dispositif technologique dans la tche de service

Cette tape consiste intgrer la technologie que lon va utiliser, en loccurrence un robot, au mtier considr. Il va alors falloir choisir quels cas dutilisation seront associs aux diffrents acteurs. Le choix des relations entre les acteurs et les cas dutilisation vont inuer sur la scurit. En effet, les cas dutilisation sont une modlisation de la manire dont certains acteurs vont utiliser le systme, mais ceci peut faire lobjet dun choix, et cest ce que lon nomme lallocation des tches. Il sagit de dcider quelle sera la distribution de la charge de travail entre les acteurs et le systme. Ceci est particulirement critique pour des tches qui existaient auparavant, et que lon souhaite raliser grce un systme technologique comme un systme de robotique de service. Par exemple, les travaux sur les robots mdicaux de (Coste-Manire et al., 2002) de lquipe CHIR2 , ont amen les auteurs a dvelopper une procdure comportant des tapes de planication, validation, vrication et excution. Ceci rend plus complexe la tche du chirurgien qui doit alors raliser des actions quil neffectuait pas jusqualors. Face cet ensemble de nouvelles tches, il est donc important de bien dnir qui les ralisera et dans quelles conditions. Notons que cette procdure rsulte de lidentication
2

http ://www.inria.fr/chir

4.2 Description du systme et de son utilisation

103

Raliser geste mdical Spcialiste Figure (a) Patient

Site matre

Robot
Raliser geste mdical

Oprateur

Figure (b)

Patient

F IG . 4.2 Modlisation dun geste mdical (a), et dun cas de tl-mdecine robotise (b) dun phnomne dangereux d la complexit du systme, qui est la prsence dtats problmatiques comme la collision des diffrents bras du robot portant des outils et un endoscope. Bien que lallocation des tches soit fondamentale pour la scurit, il est encore rare de trouver dans les conceptions de systmes robotiques de telles analyses. Lorsquun concept nat dans lesprit dun concepteur, il est souvent associ une premire ide darchitecture sans quil y ait eu mise plat des besoins, des acteurs et des contraintes. Nous proposons dutiliser UML an de modliser la rpartition des tches. La dtermination de cette allocation peut alors suivre des algorithmes comme ceux prsents par Laprie et al. (1995, p.231-236), Beevis et al. (1994) et Mersiol et al. (1998). Bien que cette approche seffectue au dbut du processus de dveloppement, elle permet nanmoins de guider les premiers choix technologiques, et de commencer laborer une architecture du systme, et plus particulirement du robot. Cest donc ds le dbut du dveloppement que nous proposons dutiliser la modlisation mtier prsente dans la partie prcdente, puis de driver, de rednir ou de complter chaque cas dutilisation pour intgrer le nouveau dispositif technologique. Par exemple, pour un cas de tl-mdecine, le cas dutilisation Raliser geste mdical, identi prcdemment, ne sera plus reli au spcialiste car celui-ci se trouve un autre endroit, mais un acteur que lon peut nommer Site matre et un Oprateur tant sur place. Ce cas est reprsent sur la gure 4.2(b).

4.2.3 Dnition des frontires du systme

Une des tapes de lanalyse du risque est la dnition des frontires du systme et, par extension, la dnition des frontires de lanalyse. Elles sont modlises en premier lieu sur les diagrammes de cas dutilisation grce un cadre, o tout ce qui est lintrieur (cas dutilisation ou acteurs) concerne le systme que lon souhaite analyser. On choisit alors parmi les cas dutilisation identis prcdemment, ceux qui vont concerner le sous-systme analys. Les cas non retenus sont considrs comme appartenant un autre sous-systme quil convient

104
Contrleur de robot

Intgration dUML pour lanalyse du risque

Contrler outil <<include>>

Oprateur

Raliser tche <<include>>

Robot

Contrler mouvements

F IG . 4.3 Exemple de diagramme des cas dutilisation

Cas dutilisation Acteurs Description Contrler Mouvements Oprateur, Robot Loprateur contrle les mouvements du robot en mode cartsien grce 2 joysticks. Un joystick permettant la localisation de leffecteur suivant les axes x,y et z rfrencs par rapport au bti, lautre permettant deffecteur les 3 rotations en D, 2, et N Le robot est en position de repos Le robot est remis en position de repos Loprateur peut sil le dsire passer en mode articulaire La vitesse de leffecteur ou dun axe ne doit pas dpasser 25 cm/s Les joysticks utiliss seront des LESIA2000 dj utiliss pour un autre projet

Pr-condition Post-condition Alternative QoS Contraintes techniques Remarques

F IG . 4.4 Exemple de che de cas dutilisation nanmoins danalyser sparment. Ainsi, sur la gure 4.3, on modlise avant tout les acteurs, lOprateur et le robot, ainsi que le Contrleur de robot dont les frontires sont dnies par le cadre extrieur. Cet exemple prsente le cas trs classique de la ralisation dune tche par un robot manipulateur comportant un outil (que ce soit un robot industriel ou de service). Ce cas dutilisation est dtaill de manire textuelle dans un document qui existe pour chaque cas dutilisation. En effet, il est parfois impossible de reprsenter lensemble des exigences de manire graphique. Les informations concernant la scurit peuvent apparatre dans ce document, et lon peut choisir de regrouper lensemble des contraintes de scurit, de abilit et de performances sous lappellation QoS (Quality of Service) prsente au chapitre 3. Ce concept, dont lintgration dans le langage UML est encore ltude au sein de lOMG, devrait apparatre dans les prochaines versions dUML. Lutilisation que lon en fait ici est la plus simple qui existe, puisque nous proposons dutiliser cette notion pour crer une rubrique supplmentaire dans la description textuelle des cas dutilisation. Ainsi, pour le cas dutilisation Contrler mouvements, on peut raliser une description textuelle comme celle prsente en gure 4.4. Cependant, la notion de QoS, comme il est dit au chapitre 3, est troitement lie la notion de scurit, et les travaux actuels concernant les interactions entre la smantique dUML et cette notion, devraient permettre de faire le lien avec la gestion du risque.

4.2 Description du systme et de son utilisation

105

: Oprateur

Contrleur de robot

: Robot

Arrter Dbrayer Dplacer la main Relancer

F IG . 4.5 Exemple de diagramme de squence pour un scnario du cas dutilisation Raliser tche de la gure 4.3

4.2.4 Description des tches des acteurs

La description du systme est faite grce aux cas dutilisation, mais aussi grce des reprsentations plus concrtes, les diagrammes de squence ou de collaboration, qui permettent de modliser des scnarios appartenant aux cas dutilisation. On dit alors que les diagrammes de squence ralisent les cas dutilisation, puisquils donnent une description dun cas concret de scnario. La gure 4.5 illustre lutilisation dun diagramme de squence permettant de dcrire un scnario du cas dutilisation Raliser tche de la gure 4.3. Lorsque le systme analyser est simplement reprsent par une instance, comme Contrleur de robot, on parle de diagramme de contexte. On exprime effectivement le contexte dans lequel le systme est utilis. En dnissant ainsi chaque scnario pour chaque cas dutilisation, on regroupe lensemble des actions que les acteurs devront effectuer. Ceci permet de reprsenter lordre des actions qui doit tre respect, et de dtailler les tches dvolues chaque acteur du systme, et plus particulirement aux acteurs humains. Cette activit, est fonction du degr davancement du dveloppement, puisquil est possible de dcrire chaque action avec un simple message gnral, comme par exemple Arrter sur la gure 4.5, mais aussi de rentrer dans les dtails pour exprimer comment lOprateur effectue cette action (boutons, interrupteurs, etc.), quel moment, pourquoi, etc. Cette modlisation, tout en assurant une continuit avec le dveloppement du systme et donc la cohrence du modle, permet de dnir des tches prcises et dtailles, donc non ambigus pour les acteurs. Un avantage supplmentaire de cette reprsentation est de fournir une spcication des interfaces homme-machine. En effet, lensemble des messages mis par les acteurs humains permet de dresser lensemble des exigences fonctionnelles des interfaces. Le langage UML contribue ainsi la prvention des fautes de conception, dues des incomprhensions ou des ambiguts au niveau des interfaces.

106
ragir
E! A

Intgration dUML pour lanalyse du risque

Dommages utiliser Acteur Sous-systme

perturber

Environnement extrieur

F IG . 4.6 Interactions principales lors de lutilisation dun sous-systme

4.3

Analyse des dangers et estimation du risque

4.3.1 Problmatique
Dune manire simplie, pour tout systme on peut reprsenter les interactions avec le diagramme de collaboration prsent sur la gure 4.6. LEnvironnement extrieur est reprsent sous la forme dun bonhomme (un stickman) pour signier quil agit la manire dun acteur sur le systme. Le message perturber nest pas forcment ngatif, car le systme peut tre prvu pour rpondre certaines perturbations. Sur ce diagramme trs simple ne sont reprsents que les ots de contrle. Tous les ots dinformations en sens direct ou inverse des sens des messages sont sous-entendus. Les dangers que lon peut identier sur ce diagramme sont : des perturbations ngatives lies lenvironnement extrieur (message perturber) ; des mauvaises utilisations (message utiliser) ; des dfaillances internes (message ragir) ; des combinaisons de ces phnomnes dangereux ; et des combinaisons dinteractions (change de messages) non errones mais induisant un danger (situation dangereuse). Cette manire de reprsenter les interactions dun systme permet didentier les techniques ncessaires lanalyse des dangers que lon effectue ici. Tout dabord, la complexit dun systme socio-technique comme celui reprsent ici, ncessite la collaboration de nombreux spcialistes de chaque domaine. Ainsi, une premire tape, largement utilise dans de nombreux domaines, consiste dialoguer avec ces spcialistes pour identier les dangers dun tel systme dune manire trs globale. Cette technique, intitule analyse prliminaire des dangers, est prsente dans la section 4.3.2. Les trois premiers dangers de la liste ci-dessus, concernant les perturbations extrieures, les mauvaises utilisations et les dfaillances internes, peuvent tre vues comme des modes de dfaillance des messages mis par lenvironnement extrieur, les utilisateurs et le soussystme considr. Cette analyse peut donc se faire entit par entit, en utilisant la technique de lAMDEC, qui consiste identier puis analyser lensemble de ces modes de dfaillance en se basant sur la notion de Message fondamentale UML. Ce point est abord dans la section 4.3.3, et lon tudiera dans la section 4.3.4 comment cette dmarche sapplique aux diffrents domaines.

4.3 Analyse des dangers et estimation du risque

107

Les deux derniers points de la liste, concernant les combinaisons des trois phnomnes dangereux identis ci-dessus et les combinaisons de messages non-errons mais induisant une situation dangereuse (comme par exemple un interblocage), ne peuvent tre traits par la technique de lAMDEC. La technique danalyse des arbres de fautes est un des moyens permettant de raliser une telle analyse, et nous tudierons comment cette technique sintgre dans une modlisation en UML dans la section 4.3.5. N.B. : Lidentication des phnomnes dangereux et lestimation du risque tant des activits que lon mne simultanment, il convient de dnir ds le dpart les niveaux de probabilit doccurrence et de gravit que lon choisit pour lestimation du risque. Sans dnir quels risques seront acceptables ou non, on peut utiliser des chelles de valeur propre lapplication considre. Dans les sections suivantes, nous utiliserons, titre dexemple, les chelles de valeur prsentes la section 1.4.3.4.

4.3.2 Analyse prliminaire des dangers

Beaucoup de travaux font rfrence lAPR (analyse prliminaire du risque) ou PHA (Preliminary Hazard Analysis), pour introduire au sein de lanalyse du risque une tape prcdent lanalyse technique dtaille. Cette analyse prliminaire consiste dialoguer avec des spcialistes du mtier ou des utilisateurs, pour identier les principaux vnements redouts. Cest une mthode participative au sein de groupes de travail. Il est possible de faire cette analyse trs tt dans le processus de dveloppement. Par exemple, on peut effectuer une analyse du concept de tl-mdecine, en rchissant sur les dangers majeurs, sans se proccuper de la ralisation. Les diffrences de terminologie au sein de cette activit (certains emploient le terme de risque, dautres de danger, ou de facteur de risque) proviennent en partie de son aspect transversal et du fait de la collaboration entre des acteurs ayant une culture du risque , et des acteurs du domaine concern, possdant leur propre langage. Nous utilisons ici le terme de danger et non de phnomne dangereux comme prconis par certaines normes (comme la ISO 14971 (2000)), car nous pensons quil est possible didentier lors de cette tape la fois des phnomnes dangereux, mais aussi des situations et des vnements dangereux, ce que lon englobe par la notion de danger. De plus, lors de cette tape, intervenant ds le dbut de la conception, il est impossible dvaluer les probabilits doccurrence des vnements redouts, et donc de calculer le risque associ. Pour cela, le terme danalyse prliminaire du risque ne peut tre utilis. Dans le cadre de la robotique de service il est possible dutiliser les diffrents moyens prsents en 1.4.3.3, comme la consultation de bases de donnes, linterview de spcialistes, dutilisateurs, etc. Les diagrammes des cas dutilisation servent alors spcier les acteurs exposs aux dangers et dnir dans quel cas dutilisation le systme se trouve. Beaucoup dtudes sur les robots industriels sappuient sur une classication des dangers suivant les

108
Domaine Danger Acteurs Oprateur
Dplacement sur une zone sensible ou dangereuse du patient Pression trop importante sur le patient Cas dutilisation

Intgration dUML pour lanalyse du risque

Solutions possibles
Gravit

Remarques

Configurer tche

Raliser tche

Patient

Robot

Physique

1 Spcification dune
zone de travail avant la tche. Contraindre les mouvements dans cette zone.

Envisager des solutions logicielles mais aussi matrielles

X X X X

X X X

1 Contraindre les efforts

des mouvement grce un capteur de force

Electrique

Electrocution

1 Aucune partie

Dcharge lectrostatique

Rpondre aux mtallique ne doit tre normes en vigueur en contact avec le pour le systme patient lectrique (fusible, alimentation aux normes, etc) 2 Les parties mtalliques du robot doivent tre relies la masse

F IG . 4.7 Exemple de tableau pouvant servir pour lanalyse prliminaire des dangers domaines mcanique, physique, chimique, psychologique, etc. De telle dmarches aident les concepteurs identier les dangers, et la prsentation que lon fait sous forme de tableaux permet de donner diffrents points de vue. Il est possible deffectuer alors des classements en fonction des acteurs, ou des cas dutilisation, ou du domaine du danger comme sur la gure 4.7. Cest pourquoi nous proposons dutiliser un tableau modulaire contenant lensemble de ces informations. Il est possible dutiliser pour ce tableau la classication de la gravit expose dans la partie 1.2.1.2. Lorsque cela est possible, les concepteurs peuvent aussi indiquer la probabilit doccurrence du dommage, et ainsi exclure du traitement les dangers prsentant un risque nul ou minime. Une premire itration de cette activit permet ds le dbut de se poser des questions concernant la scurit. Et plutt que de proposer des solutions de conception, ce tableau doit permettre de complter les cas dutilisation et notamment les descriptions textuelles en introduisant des exigences de type QoS, ou des alternatives de scnarios. La reprsentation de tels tableaux permet de guider les concepteurs dans lidentication des dangers. Ainsi, une reprsentation des dangers en fonction des cas dutilisation, ou des acteurs exposs, offre un point de vue diffrent sur la problmatique, et peut permettre ainsi de complter lanalyse. De plus, lors des tapes suivantes, dautres dangers seront identis, et ce type de tableau permet de synthtiser les informations.

4.3.3 Analyse des modes de dfaillance

La technique prsente ci-dessus ne saurait sufre une analyse de la scurit, et il est vident quelle ne traite quun ensemble de dangers facilement identiables. De plus, les mcanismes de production de ces dangers ne sont pas analyss. Une autre technique complmentaire, dite de forward, part des dfaillances des composants du systme, puis identie les

4.3 Analyse des dangers et estimation du risque

109

dangers et les dommages induits par ces dfaillances. Pour suivre cette dmarche, la technique de lAMDEC (Analyse des Modes de Dfaillance et de leurs Effets Critiques), prsente dans le premier chapitre (1.5) est la plus utilise. Elle est base sur la connaissance des modes de dfaillance des composants et de leurs effets sur le systme. Le tableau prsent dans le chapitre 1 est un exemple dutilisation de lAMDEC pour des composants lectroniques, mais cette technique est utilise dans de nombreux autres domaines, dont celui des facteurs humains. 4.3.3.1 Analyse des modes de dfaillance des messages

La notion de mode de dfaillance est proche de celle de type derreur, et dans le cadre de notre analyse, nous utiliserons par la suite lun ou lautre de ces concepts de manire quivalente. La technique de lAMDEC consiste avant tout identier les erreurs pouvant apparatre au sein dun systme avant que la fabrication ait eu lieu. Pour la plupart des analyses, les erreurs identies sont spciques lapplication. titre dexemple, une rotation trop importante dun actionneur dun robot neuro-chirurgical est une erreur propre lapplication, et une mme rotation sera considre comme un fonctionnement normal pour une autre utilisation. Pour automatiser lidentication des erreurs, il est nanmoins possible dutiliser des modles derreurs gnriques et donc utilisables pour diffrentes applications. Par exemple, lorsque des lectroniciens analysent les circuits comportant des portes logiques, ils utilisent un modle derreur commun tous les systmes utilisant ces composants : sortie colle 1, sortie colle 0. De la mme manire en robotique, il existe des classes de composants que lon retrouve dans de nombreuses applications, comme les actionneurs et les capteurs, et il est possible dutiliser des modles derreur de ces composants. Cependant, ces modles derreur sappliquent de manire trs rduite et ne concernent que quelques lments physiques. Ainsi, des modles derreurs plus labors devraient permettre de ne pas se restreindre aux composants lectroniques. Pour cela, nous proposons de nous concentrer sur un des lments qui nest pas propre une application : le langage de modlisation UML. En effet, par analogie avec les dispositifs lectroniques comme les actionneurs et les capteurs, les constructions dUML sont utilises dune application lautre. De plus, une autre dimension cette gnricit provient de la pluridisciplinarit du langage permettant de modliser les lments lectroniques, informatiques, mcaniques et les acteurs humains. Cette gnricit est double : elle devrait permettre de proposer des modles derreur gnriques aux applications (applicables diffrents systmes), mais aussi transversaux aux diffrents domaines (de llectronique la composante humaine). La richesse de la notation UML nous amne nous concentrer vers une des constructions de ce langage quil convient de dnir avant de proposer des modles derreurs. Le langage UML est dni par un mtamodle, o toutes les constructions sont inclues dans des pa-

110

Intgration dUML pour lanalyse du risque

Activity Graphs

Collaborations

Use cases State machines

Common Behavior

F IG . 4.8 Package Behavioral Elements, diagramme tir de la spcication 1.4 dUML ckages. La construction que nous proposons danalyser, fait partie du package Collaborations (lui mme inclus dans un des packages fondamentaux dUML, Behavioral Elements prsent sur la gure 4.8), et concerne tous les lments ayant trait la notion de Message. Diffrentes raisons ont conduit ce choix. Tout dabord, lanalyse des dfaillances doit permettre didentier le comportement du systme pouvant induire des dommages. Il sagit de considrer le systme lors de son utilisation, et donc lorsquil est en action. Par analogie, un composant qui a une dfaillance mais nchange aucun message avec les autres composants qui sont euxmmes en relation avec les acteurs du systme, ne sera pas dangereux, et ne ncessitera donc aucune analyse relative la scurit. Le danger provient de lchange de ces messages entre composants ; sil ny a pas de message, il ny a pas de danger. Cest donc lanalyse des modes de dfaillance de ces messages et non des composants que nous proposons danalyser. Cette manire daborder le problme est dj sous-jacente en lectronique, mme si lapproche est de prime abord base sur la notion de composant. En effet, lorsque les lectroniciens utilisent lAMDEC pour les composants lectroniques, ils tudient chaque composant et analysent les sorties de ces composants, et donc les messages qui sont envoys. Par exemple, une analyse dun capteur de position permet didentier les modes de dfaillance suivants : sortie nulle, constante, alatoire, drive, etc. qui ne correspondent en fait quaux modes de dfaillance du message LirePosition() mis par les composants souhaitant utiliser ce service. Comme il sagit de son unique fonction, et par soucis de simplication, on parle alors de lanalyse des modes de dfaillance du Capteur, alors quil sagit de lanalyse des modes de dfaillance de sa fonction principale, appele par le message LirePosition(). Par extension, on peut donc dire que lanalyse des modes de dfaillance du systme passe par lanalyse des messages changs entre les composants du systme. Cependant, le fait de se concentrer sur la notion de Message rduit la gnricit de notre approche. Il existe en effet au sein de la notation UML le concept dAction qui est llment

4.3 Analyse des dangers et estimation du risque

111

fondamental du mtamodle pour la modlisation du comportement dynamique. Cependant, an de limiter notre tude et de se restreindre des concepts proche des utilisateurs dUML (le mtamodle est un concept qui nest pas orient utilisateur), nous avons prfr nous concentrer sur la notion de Message. De plus, les travaux actuels de formalisation dUML montrent des diffrences importantes sur le concept dAction. Ainsi, la version 1.5 dUML, publie par lOMG (2003c) lors de la rdaction de ce manuscrit, a fortement modi les concepts lis lAction en introduisant notamment un package Action, absent de la version 1.4 (OMG, 2001). De plus, cette spcication diffre actuellement des travaux actuels pour la version 2.0 (OMG, 2003a). En revanche, au sein de ces trois documents formalisant UML, la notion de Message semble stable, prouvant ainsi la force et limportance de ce concept. 4.3.3.2 Modles derreur des messages

Nous avons donc choisi de nous concentrer sur une des constructions dUML : les Messages. Il sagit maintenant de dterminer les erreurs possibles lies ce concept. Certains langages (comme ADA par exemple), possdent ce que lon nomme une smantique oprationnelle et une smantique de vrication. La smantique oprationnelle permet de spcier les aspects fonctionnels dun systme, et dcrit donc la manire dont le systme dlivrera le service. En UML, cest lensemble des diagrammes que lon peut nommer smantique oprationnelle. La smantique de vrication dnit des proprits permettant de vrier si des rgles sont respectes. Par exemple, en ADA, il est possible dexprimer des contraintes sur les valeurs des variables utilises dans la partie oprative dun programme. Cette smantique permet dune part didentier les erreurs consistant en un non-respect dune de ces proprits, puis de les traiter. La dmarche possible est alors de regrouper lensemble des proprits de la smantique de vrication, et den driver des modles derreur. Par exemple, dans le cas classique du typage en ADA (on spcie les valeurs admissibles dune variable), un modle derreur est lutilisation dune variable en dehors de ses limites. Cette dmarche peut sappliquer la plupart des langages, dont UML, mais dans de nombreux cas, la smantique de vrication est implicite, noye dans la smantique oprationnelle, voire absente du langage. En UML, il existe un certain nombre dlments que lon peut classer dans la smantique de vrication. Tout dabord lutilisation de contraintes, reprsentes graphiquement par de accolades (comme par exemple {ordered}), permet de spcier pour certains lments une restriction dutilisation, et ceci fournit donc une source derreur si elle nest pas respecte. Il existe aussi, dans la spcication dUML, les Well-Formedness Rules dnissant un ensemble de contraintes exprimes avec le langage OCL (OMG, 2001). Cependant, la plupart des proprits de vrication ne sont pas exprimes explicitement, et sont intgres implicitement dans la smantique oprationnelle. Par exemple, le fait davoir une squence ordonne de messages, au sein dune interaction, est reprsent dans le mtamodle, comme prsent sur la gure 4.9, par des associations +predecessor et +successor. Ces lments ne sont pas des contraintes ou des proprits permettant de vrier le modle, alors que

112
1 1..*

Intgration dUML pour lanalyse du risque

+predecessor

Interaction

Message

* *

+successor

F IG . 4.9 Mtamodle des lments Interaction et Message dans la spcication 1.4 dUML
Nom de linteraction Nom de lobjet Nom du Arguments du message message

Interaction

Objet1

Objet2
vnement de reception message1 (arguments)

vnement denvoi vnement de reception

retour1(arguments)

Traitement du message

Temps

message2 (arguments)
retour2(arguments)

vnement denvoi

Rponse au message
(en gnral implicite)

F IG . 4.10 lments dune interaction ralise par lenvoi de deux messages le fait de ne pas respecter lordre des messages est une source derreur. En conclusion, au lieu de chercher regrouper lensemble des contraintes ou des Well-Formedness Rules relatives la notion de Message au sein de la spcication 1.4 dUML, nous proposons de dnir les concepts inhrents la notion de Message dune manire gnrale. Cette dmarche synthtise les lments spcis dans la version 1.4, et permet en plus dintgrer des lments comme les contraintes de temps actuellement absentes du mtamodle (travail en cours par lOMG notamment pour la version 2.0 dUML). Un message pouvant tre la cration dun signal, lappel dune opration, la destruction ou la cration dune instance, nous prsentons une description gnrique de lensemble des caractristiques dun Message. La reprsentation graphique sous forme de diagramme de squence est donne gure 4.10. On dnit alors les diffrents lments dun message : 1. linteraction laquelle il appartient ; 2. les messages suivants et prcdents ; 3. les objets metteur et receveur de ce message ; 4. les vnements denvoi et de rception ; 5. les arguments dnis en nombre, type et valeur ; 6. la rponse implicite dnie aussi par des arguments, et des vnements denvoi et de rception ;

4.3 Analyse des dangers et estimation du risque

113

7. une dure de traitement du message. partir de ces lments, on tablit les erreurs possibles pour un message. Tout dabord, un message appartient une interaction, et lenvoi non prvu de ce message au sein dune autre interaction est un type derreur que lon trouve notamment lors de la manipulation dinterface homme-ordinateur. Dune manire gnrale on peut largir ce type derreur en tablissant un premier modle derreur : E.1. Envoi dun message nappartenant pas linteraction prvue. Le deuxime point concernant lordre des messages peut aussi tre la source derreur, et notamment pour les objets du type acteur humain. En effet, un utilisateur ayant raliser plusieurs tches consistant en lenvoi de message, peut alors inverser ou oublier une des tches. Il est alors possible dtendre cette erreur tout modle en spciant deux types derreur : E.2. Excution dun ou plusieurs messages dans un ordre incorrect. E.3. Omission dun message au sein dune squence de messages. Un message est envoy par un objet, mais il est possible que lobjet receveur soit inexistant. Ce type derreur, commun en informatique, permet de formuler une erreur gnrique : E.4. Absence de linstance devant recevoir le message. Les caractristiques lies aux vnements denvoi et de rception des messages permettent de dnir des proprits temporelles. En effet, pour ces vnements, le temps est llment fondamental, et on en dduit des erreurs comme les retards (voire des retards innis comme des blocages), ou mme des messages en avance par rapport aux spcications : E.5. Envoi ou rception dun message en dehors des limites de temps spcies (trop tt ou trop tard) Les arguments dun message constituant les paramtres de lopration ou du signal appel doivent correspondre en nombre, type, et valeur celles attendues pour lobjet receveur. Cette proprit partiellement exprime en OCL dans les Well-Formedness Rules de la spcication dUML, permet dexprimer trois types derreur : E.6. Le type des arguments dun message est diffrent du type des paramtres attendus par le receveur. E.7. Le nombre darguments dun message est diffrent du nombre de paramtres attendu par le receveur. E.8. La valeur des arguments dun message est diffrent de la valeur des paramtres attendus par le receveur. La rponse souvent implicite un message peut tre caractrise par des arguments (par exemple lappel dune opration retourne une valeur), mais aussi par des vnements denvoi et de rception. Les erreurs temporelles lies la rception ou lenvoi de la rponse sont

114

Intgration dUML pour lanalyse du risque

dj exprimes dans lerreur E.5. Ceci mne lidentication dune erreur lie en gnral un message faisant appel une opration (comme par exemple LirePosition pour un capteur de position) : E.9. Les valeurs retournes par la rponse dun message ne correspondent pas aux valeurs attendues (comme par exemple : constante, alatoire, hors limites, etc.) La dernire caractristique concernant la dure de traitement dun message, correspond au temps compris entre le moment o lobjet reoit le message et le moment o le receveur renvoie une rponse. Cette rponse peut tre une valeur retourne, la construction ou la destruction de lobjet, lenvoi dun signal, etc.). On identie alors le type derreur suivant : E.10. Traitement dun message en dehors des limites de temps spcies En complment des lments que lon a nots sur le diagramme, il convient de prendre en compte llment lien caractrisant la relation entre les objets metteur et rcepteur, et permettant le transmission du message. Cela permet alors de formuler le type derreur suivant : E.11. Absence du lien entre les objets metteur et rcepteur 4.3.3.3 Proposition de tableau gnrique de lAMDEC pour une analyse systme

En se basant sur les normes (MIL-STD-1629A, 1980) pour des analyses fonctionnelles ou par composants, ainsi que sur les concepts exposs au chapitre 1 et sur la notion de message analyses prcdemment, nous proposons ici de reprsenter dans le tableau de lAMDEC les lments suivants (cf. gure 4.11) : le nom du composant sil na quune fonction, ou le nom du message analys, les modes de dfaillance, ou les erreurs identies grce des modles derreur comme ceux proposs dans la section 4.3.3.2, les causes de ces modes de dfaillance en restant dans une limite de causalit assez rduite, les effets locaux, sur un niveau suprieur, et sur le systme (et notamment les dommages), les donnes pour lestimation du risque (gravit du dommage, occurrence du mode de dfaillance, risque associ), les moyens de dtection en ligne des modes de dfaillance et des effets, les moyens possibles de prvention et de protection du risque, et diverses informations. Il est important de bien noter lutilisation de la terminologie du risque expose au chapitre 1. Dans lAMDEC, ce qui est nomm Modes de dfaillance correspond la notion derreur que lon retrouve dans la terminologie de la sret de fonctionnement expose par Laprie (1992). Le but de ces tableaux nest pas deffectuer une tude en profondeur de chacun des points et, notamment pour la colonne relative aux causes, il est important de ne pas se perdre

4.3 Analyse des dangers et estimation du risque

Date :17/01/2003 Par : J.Guiochet Composant / Fonction/ Message Code

115
Nom du projet Page : /

Occurrence

Mode de dfaillance (erreur)

Cause de la dfaillance

Gravit

F IG . 4.11 Exemple de tableau de lAMDEC dans des causes de causes, mais de synthtiser les principales informations qui permettent dobtenir une analyse systme. Le risque est ici calcul partir dune estimation qualitative de la probabilit doccurrence dun mode de dfaillance et de la gravit du dommage induit. Or, par dnition (cf. chapitre 1), le risque doit tre calcul avec la probabilit doccurrence du dommage lui-mme (et non du mode de dfaillance). De plus dans une analyse comme celle-ci, il est possible de retrouver le mme dommage pour diffrents modes de dfaillance. Cette diffrence sexplique par les besoins pratiques des concepts de calcul du risque. Il est plus facile de calculer dabord qualitativement le risque relatif chaque mode de dfaillance, puis den dduire le risque du dommage associ, en combinant les diffrents calculs de probabilit des modes de dfaillance. La colonne Solutions possibles du tableau de la gure 4.11 concerne des moyens possibles pour la rduction du risque. Il est important de noter que ces moyens ne sont pas implments directement, et quune valuation du risque doit tre faite pralablement. Nous avons choisi de reprsenter les moyens de prvention et de protection, mais une telle analyse peut mener dautres moyens. Par exemple, ayant identi des messages dont il est difcile destimer la probabilit doccurrence, mais que lon peut qualier de critiques, un moyen de rduire le risque est lutilisation de techniques dlimination des fautes (vrication, validations, tests, etc.). Dune manire gnrale, lutilisation de lAMDEC que lon propose ne suit pas une dmarche systmatique, o chaque mode de dfaillance est valu en terme de probabilit et de gravit, puis trait. La principale raison vient de limpossibilit destimer la probabilit, mme de manire qualitative, de tous les modes de dfaillance. Un des exemples le plus probant est sans doute les modes de dfaillance du logiciel dont il est impossible de dterminer la probabilit doccurrence. Ainsi, lAMDEC permet avant tout de souligner des points de conception critiques en terme de scurit, et lorsque cela est possible destimer le risque. En dernier lieu, lutilisation de lAMDEC dpend fortement du degr davancement du dveloppement, car elle est directement dpendante du niveau de dtails des modles. Dans notre approche, il nous semble important de se concentrer sur les premires tapes du processus de dveloppement, car cest ce moment que les exigences de scurit, les choix darchitecture, et les principaux phnomnes dangereux sont identis.

Risque

Effets : a. Niveau local b. Niveau suprieur c. Niveau systme

Risque

Moyens de dtection possibles (en ligne) a. Mode dfaillance b. Effets

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques

116

Intgration dUML pour lanalyse du risque

4.3.4 Application aux diffrents domaines

Une approche systme doit permettre la prise en compte de toutes les composantes (lectronique, informatique, mcanique et facteurs humains), mais il est vident que ce sont les spcialistes de chaque domaine qui possdent la matrise des informations. Chacun possdant son propre langage et ses propres techniques, il est parfois complexe de runir lensemble de ces informations pour effectuer une analyse globale du systme. En utilisant le langage UML, ainsi que les modles derreur associs au concept de message, on peut rendre homogne lanalyse du risque des diffrents domaines. Les sections suivantes prsentent des exemples dutilisation des modles derreur identis dans la section prcdente an de dmontrer la faisabilit dun telle dmarche. Tout dabord, les modles derreur seront appliqus aux acteurs identis dans la modlisation en UML. Les acteurs, dans la smantique dUML, sont en gnral les utilisateurs ou les dispositifs extrieurs interagissant avec le systme. Les particularits de ces deux types nous amnent les traiter de manire spare dans cette section. Il existe cependant un autre type dacteur qui apparat sur le diagramme de collaboration prsent prcdemment sur la gure 4.5 : lenvironnement extrieur. Dans notre cas nous nanalyserons pas les perturbations provenant de cet acteur, car pour une tche de service en milieu protg humain comme une tche mdicale, ces interactions sont minimes, ou prvues par la spcication. Cependant, il est possible danalyser les effets des messages mis par lacteur environnement extrieur en rpertoriant toutes ses actions nfastes sur le systme. Cette partie prsente donc des exemples danalyses des diffrents messages : les messages mis par les acteurs de type dispositif extrieur (section 4.3.4.1) ; les messages mis par les acteurs humains (section 4.3.4.2) ; les messages changs entre composants lectroniques (section 4.3.4.3) ; les messages changs entre composants mcaniques (section 4.3.4.4) ; le messages changs au sein du logiciel (section 4.3.4.5). Pour chaque domaine trois points seront abords. Tout dabord la manire dont il est possible de modliser les objets du domaine est prsente (paragraphe Modlisation des objets et des interactions), puis les types derreur spciques au modle sont identis partir des modles derreur tablis prcdemment (paragraphe Types derreur), et enn un exemple danalyse des erreurs des messages est dvelopp (paragraphe Analyse des modes de dfaillance). Pour les paragraphes Types derreur, les modles derreur de E.1 E.10 ne seront pas instancis systmatiquement considrant quil existe des cas impossibles ou triviaux.

4.3 Analyse des dangers et estimation du risque

117

: Site matre

Systme de contrle Site esclave

Mettre robot en position initiale Contrler_mouvements(consignes)

F IG . 4.12 Diagramme de squence illustrant des interactions entre un site matre et un systme esclave 4.3.4.1 Analyse des modes de dfaillance des messages provenant des acteurs de type dispositif extrieur

Modlisation des objets et des interactions Pour de nombreux systmes, il est possible de reprsenter des dispositifs extrieurs comme des acteurs, sils interagissent avec le systme de manire autonome. Ainsi, pour la tlmdecine, le Site matre de la gure 4.2 peut tre not comme un acteur. Les messages changs avec le systme peuvent se modliser grce des diagrammes de collaboration ou de squence comme sur la gure 4.12. Les dispositifs extrieurs annots en tant quacteurs reprsentent souvent des systmes imposants des contraintes de temps. Par exemple, certains utilisateurs dUML (Douglass, 1999) reprsentent de simples timers en tant quacteurs, pour exprimer notamment le fait quil sagit dune application temps-rel. Les messages envoys sont alors annots de contraintes exprimes en tant que notes comprises entre accolades. Dans les modles que lon a prsents prcdemment, nous avons fait apparatre un acteur propre la robotique : le robot rduit son architecture mcanique. Ce choix est trs controvers, car il est possible de considrer le robot comme un dispositif au mme titre que les capteurs et les actionneurs faisant partie du systme modlis par les cas dutilisation. Cependant, au cours des diffrentes modlisations que nous avons pu raliser, il sest avr que la structure mme du robot devait faire lobjet dune sparation du systme ne serait-ce que pour les interactions particulires entre les humains et la structure mcanique du robot. Bien que nous abordions cet acteur dans cette section, il est vident que lanalyse des modes de dfaillance de cet acteur particulier concerne le domaine mcanique. La notion dacteur est une notion transversale aux diffrents domaines. Types derreur Pour un acteur du type dispositif extrieur, les messages changs correspondent soit des oprations, soit des signaux. Tous les modles derreur de E.1 E.10, peuvent tre utiliss pour ces messages. Ainsi, pour le message Contrler_mouvements(consignes) de la gure 4.12, les erreurs peuvent tre lenvoi darguments faux (erreur E.6, E.7 et E.8), des

118
Date :17/01/2003 Par : J.Guiochet Composant / Fonction/ Message Code

Intgration dUML pour lanalyse du risque

Nom du projet
Mode de dfaillance (erreur) Cause de la dfaillance Effets : a. Niveau local b. Niveau suprieur c. Niveau systme c. Mouvement non dsir Risque Occurrence Moyens de dtection possibles (en ligne) a. Mode dfaillance b. Effets

Page :

Gravit

Contrler_mouvements Consignes (consignes) fausses (erreur de type E.6 E.8)

Faute Site Matre ou faute lien

Risque

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques

Vrification cohrence des a. Utilisation protocole consignes (filtrage standardis numrique) b. Ignorer la valeur des consignes, mettre le contrleur en position dattente

F IG . 4.13 Analyse dun mode de dfaillance du message Controler_mouvements() retards ou des dcalages dans le temps (E.5 et E.10), ou des erreurs du Site matre lors de lenvoi des messages (E.1, E.2, E.3, et E.4). Pour un acteur de ce type, il est important de noter que les types derreur incluent les dfaillances de lobjet metteur mais aussi les dfaillances du lien avec lobjet receveur (E.11). Cela permet entre autres de couvrir les aspects de tlcommunication de certaines applications comme celles de la tlmdecine. Analyse des modes de dfaillance La modlisation de lensemble des messages changs en diagramme de squence permet deffectuer une analyse trs tt dans le processus de dveloppement, et de formuler ds le dbut des exigences de scurit ou de sret de fonctionnement, sans prciser les choix de conceptions pour la communication entre les dispositifs. Par exemple, dans le cas du diagramme de la gure 4.12, le type de communication nest pas spci (intranet, internet, RS232, etc.), mais il est possible dores et dj denvisager les dfaillances des messages provenant du site matre. La gure 4.13 montre une analyse gnrique du mode de dfaillance de type E.6 ou E.7 ou E.8, du message Contrler_mouvements(consignes) du diagramme de squence de la gure 4.12. En se basant sur les autres diagrammes UML, on value les effets de ce mode de dfaillance. Puis, partir de cette analyse, il est possible de proposer une solution pour ce mode de dfaillance en modiant les modles UML du systme. La solution propose ici consiste changer temporairement ltat du contrleur de robot. Ceci est illustr sur le diagramme dtat de la gure 4.14. Lors des premires tapes du processus de dveloppement, il est parfois difcile destimer la probabilit doccurrence dun mode de dfaillance. Ce champ est laiss vide dans le tableau de lAMDEC, alors que la gravit est estime un niveau 1 (cf. tableau destimation du risque du chapitre 1). Cependant, lorsque les modles sont dvelopps plus prcisment, et que certains choix de conception sont effectus, lestimation de la probabilit doccurrence devient possible.

4.3 Analyse des dangers et estimation du risque

Contrler_mouvements( consignes )

119

En mouvement
Consignes non valides

Dbut tche

Consignes valides

Repos Dlai expir / Mettre en position initiale

Pause

Contrler_mouvements( consignes )

F IG . 4.14 Diagramme dtats prenant en compte un mode de dfaillance de Contrler_mouvements()

: Oprateur

Systme

Mettre sous tension Mettre sous pression Initialiser systme

F IG . 4.15 Procdure de mise en route dun systme quelconque 4.3.4.2 Analyse des modes de dfaillance des messages provenant des acteurs humains

Modlisation des objets et des interactions La modlisation des acteurs et de leurs interactions avec les objets du systme est dcrite dans la premire partie de ce chapitre (4.2). Les acteurs apparaissent effectivement dans de nombreux diagrammes, les plus importants tant les diagrammes des cas dutilisation (voir gures 4.2 et 4.3) et de squence (voir gure 4.15). Les messages provenant des acteurs sont principalement identis sur les diagrammes de squence et constituent les tches qui incombent aux acteurs. Ces tches sont souvent dnies comme des squences ordonnes de messages envoys au systme. Lobjet receveur de ces interactions est avant tout le systme global. Mais en rafnant les diagrammes, on fait apparatre les vritables objets recevant les messages mis par les acteurs : les interfaces. Ceci montre bien limportance de ces objets dans lanalyse des erreurs humaines et notamment pour la rduction des risques.

120 Types derreur

Intgration dUML pour lanalyse du risque

Lensemble des types derreur que lon a identi sappliquent ce domaine. Les erreurs les plus communes sont par exemple lexcution dans un ordre incorrect dune squence de message (erreur E.2), lomission dun message (erreur E.3) et loccurrence dun message non connu au sein dun interaction (erreur E.1). Cette dernire erreur peut consister en lappui non prvu sur un bouton au sein dun scnario. Un autre type derreur commun est le passage darguments qui ne correspondent pas ceux attendus en nombre, en type ou en valeur par le receveur (erreurs E.6, E.7 et E.8). Linterprtation que lon peut donner de cette erreur est la mauvaise excution dune tche, de sorte que les donnes envoyes au systme soient fausses. Un exemple est la mise sous pression dun systme hydraulique, o loprateur tourne un bouton proche dun manomtre. Laction Mettre sous pression modlise comme un message sur la gure 4.15, sous-entend le passage dun argument quest la pression dsire. Loprateur peut alors sil ny a pas de sous-systme prvu, monter la pression du systme jusqu un niveau trop important ou insufsant. Le moyen de rduire le risque est alors dintroduire des moyens de prvention comme par exemple un manomtre bien visible comportant des marquages, ou un mcanisme de protection limitant la pression quoique fasse loprateur. De nombreux mcanismes prsents dans les interfaces rduisent ainsi le risque li cette erreur humaine. Un autre exemple plus courant est la vrication au niveau de linterface graphique dun ordinateur de la validit des donnes entres par un utilisateur. Lerreur de type E.4 est plus rare car elle consiste en labsence de lobjet devant recevoir le message, cest--dire en labsence dinterface. Dans un systme graphique de fentres, cette erreur est possible mais reste tout de mme assez rare. En revanche lerreur E.5 peut tre la source dimportants dgts sil existe des contraintes de temps sur lenvoi des messages, mais ceci reste trs spcique chaque application tout comme lerreur E.10 (dure de traitement du message). Le type derreur E.9 concernant la validit des valeurs retournes aprs lenvoi dun message, comme par exemple laccs une variable dtat dun systme, peut tre une source de dommage si lacteur doit ensuite agir en fonction de cette valeur. Analyse des modes de dfaillance La dmarche que nous proposons pour lanalyse des erreurs humaines, suit le mme processus que pour lanalyse des autres phnomnes dangereux, mais intgre des notions supplmentaires. Au sein de lanalyse du risque la dmarche que lon propose suit les tapes de la gure 4.16. Cette reprsentation est proche de celle propose par Pocock et al. (2001), qui nincluaient cependant pas les liens avec les modles et le processus danalyse du risque. Cest la connaissance croise entre les propositions dinterface, les scnarios dutilisation et les modles derreur humaine qui permettent didentier les erreurs possibles propres lapplication. Pour chaque cas dutilisation o des scnarios sont dclenchs par des acteurs humains, une description complte des messages avec des diagrammes de squence,

4.3 Analyse des dangers et estimation du risque

Analyse du danger et estimation du risque Solutions possibles pour la matrise du risque

121

Dfinition du systme

Propositions dinterfaces

Description des scnarios Modles derreurs humaines

Cas dutilisation

Identification de lerreur humaine

Analyse de lerreur humaine

Propositions de modifications des exigences, de la conception, ou de lutilisation

F IG . 4.16 Gestion du risque induit par les erreurs humaines permet danalyser lensemble des erreurs humaines. Il est possible de reprsenter graphiquement certaines erreurs (inversion de message, omission, etc.) directement sur les modles, et den dduire les effets sur le systme et leur gravit. Lestimation du risque reste cependant difcile puisque la probabilit doccurrence dune erreur humaine reste insondable. Cependant des modles de performance exprimentaux (bases de donnes) mais aussi des donnes empiriques (comme le bon sens commun ) peuvent aider estimer le risque li chaque erreur. Lanalyse que lon fait est avant tout une estimation de la criticit de certaines tches (ou certains messages) qui permet ensuite de scuriser les plus critiques. Comme pour le cas prcdent, les tableaux de lAMDEC conviennent la documentation de cette analyse, et les solutions possibles identies sont directement rinjectes dans les modles UML, ou dans la conception des interfaces. 4.3.4.3 Analyse des modes de dfaillance des composants lectroniques

Modlisation des objets et des interactions Les diagrammes de dploiement sont en gnral utiliss pour la modlisation des composants lectroniques. Ceux-ci ont t crs la base pour montrer les nuds dinformations, et la manire dont le logiciel se dployait sur ces nuds. Ces diagrammes sont particulirement adapts aux systmes distribus, o les objets informatiques qui communiquent peuvent tre disposs sur des processeurs diffrents. Pour les systmes de linformatique industrielle, dont font partie les robots, ces diagrammes ont t adapts (Douglass, 1999), et lutilisation des nuds a t tendue aux diffrents dispositifs se trouvant en relation avec les processeurs. Un exemple de diagramme de dploiement est prsent sur la gure 4.17. Il sagit dun systme de contrle dun actionneur fonctionnant avec une pression rgule par un Convertisseur Intensit/Pression. Lintrt dun tel diagramme est quil montre les choix technologiques qui sont faits (par exemple le PC sous VxWorks), mais son utilisation pour une analyse des dfaillances du systme est trs rduite. En effet, seuls les composants purement lectroniques sont modliss et le sens des informations changes nest pas reprsent. Pour effectuer une analyse des modes de dfaillance, une reprsentation sous forme de diagramme de classes est plus complte et peut sufre. Un exemple est donn sur la gure 4.18. Il est possible dannoter sur ce

122

Intgration dUML pour lanalyse du risque

PC VxWorks

<<BUS ISA>>

<<BUS ISA>>

Carte entres

Carte sorties

Capteur position

Convertisseur Intensit / Pression

F IG . 4.17 Exemple dutilisation dun diagramme de dploiement en informatique industrielle

<<external output device>>

Oprateur Interagit avec Envoie une commande de presssion

Convertisseur I/P
14 1 Fournit pression 1
<<external device>>

1
<<system>>

Systme de Contrle
1
Fournit position

Muscle artificiel
Transmet 1 dplacements

14

<<external input device>>

Capteur de position

Fournit nergie mcanique

Robot

F IG . 4.18 Diagramme de classes reprsentant les dispositifs extrieurs au logiciel

4.3 Analyse des dangers et estimation du risque

123

diagramme de classes, comme le propose Gomaa (2000), le type de relation entre les classes en notant le sens des informations changes et en utilisant les strotypes external device, external output device et external input device. Le diagramme ainsi reprsent exprime le fait que les classes modlisent des dispositifs extrieurs au sous-systme comportant du logiciel annot par le strotype system, car lutilisation dUML dans ce cas est essentiellement oriente vers le dveloppement du logiciel. Lintrt de ce diagramme est sa capacit reprsenter sur une mme vue les composants lectroniques, les sous-systmes comportant du logiciel comme le Systme de contrle, et des composants matriels directement dpendants de composants lectroniques comme le Muscle articiel. Le but nest pas de reprsenter ici la composition mme des composants lectroniques mais didentier les modes de dfaillances de ces composants et danalyser les effets sur le systme. En consquence, sans connatre la nature des changes lectroniques (intensit, tension, trames, etc.) entre les dispositifs, il est possible deffectuer une analyse en se basant sur la notion de message. Ainsi, un capteur de position peut tre vu comme un composant dlivrant le service lirePosition() qui retourne une valeur lue de la position. On peut aussi parler de lopration lirePosition() que lon peut invoquer par un message. Il est possible de faire le lien avec une AMDEC classique qui se base sur la notion de fonction pour dcrire ce service. Dans notre approche objet, on peut interprter la notion de message, comme un appel un service. Les diagrammes de squence ou de collaboration sont alors utilisables. Pour identier les effets des dfaillances, il peut tre aussi utile de sappuyer sur des modles mathmatiques, non exprimables en UML. Le cas le plus courant est la modlisation dune boucle de rtroaction, toujours prsente dans les contrleurs de robot, grce aux schmas blocs dcrivant la formule mathmatique du calcul de la commande dpendant de valeurs fournies par les diffrents composants lectroniques. On peut imaginer que dautres modles (formules, autres diagrammes, etc.) dcrivant laspect automatique ou mathmatique peuvent tre intgrs pour identier les effets, et cela bien avant quune modlisation en UML du contrleur soit effectue. Types derreur Comme prsent prcdemment, laccs un service rendu par un capteur (comme lirePosition) peut tre interprt comme un message retournant une valeur. Lerreur la plus frquente est donc une valeur retourne diffrente de celle attendue (erreur E.9) et donc ne retant pas la vritable valeur de la grandeur mesure. Les instances communes derreur sont un pic de valeur, une drive, une valeur constante, une valeur alatoire, etc. Il est possible dobserver ces mmes erreurs pour lenvoi dargument (erreur E.8). Par exemple, lenvoi dun message avec un argument faux est le cas dun convertisseur tension/intensit envoyant un pic dintensit un moteur. Linstance principale de lerreur E.1 (envoi dun message nappartenant pas linteraction prvue) est en gnral caractrise par lenvoi dun ux dnergie non prvu, vers un objet

124

Intgration dUML pour lanalyse du risque

receveur non prvu, lobjet receveur pouvant tre un humain, ou une partie du systme. Les plus communs sont les dcharges lectrostatiques, les explosions, etc. Par exemple, une erreur de ce type est possible pour le Convertisseur Intensit/Pression de la gure 4.18, qui peut provoquer un ot dair en cas de fuite, vers les acteurs humains (un autre effet tant la chute de pression dans un muscle). Il est donc important pour cette analyse de bien prendre en compte dune part les messages mis par chaque composant vers le composant de mme niveau pour identier la propagation des fautes, mais aussi dimaginer les actions possibles vers dautres composants du systme (acteurs ou non). Les erreurs E.5 ainsi que E.10 exprimant lenvoi dun message et le traitement dun message en dehors des limites de temps spcies, sont des modes de dfaillance frquents pour les dispositifs lectroniques effectuant un traitement complexe dune information. Le cas le plus agrant est celui des microprocesseurs, dont lactivit peut rsulter en un retard des messages changs. En considrant ici laspect purement lectronique (laspect logiciel est trait ultrieurement), ces dispositifs peuvent tre vus comme les autres composants lectroniques, mais avec des responsabilits supplmentaires. Il est possible dinstancier le type derreur E.11, concernant labsence de lien entre les objets, notamment pour les composants lectroniques dont les communications requirent des liens complexes comme des bus de donnes. Analyse des modes de dfaillance Dans des systmes lectroniques complexes, la techniques de lAMDEC est utilise pour dcrire des erreurs un niveau de dtail trs lev. Par exemple, on dcrit pour les composants lectroniques les erreurs de type micro-coupure, ou les dfaillances dun transistor (courtcircuit ou circuit ouvert), et cela permet dobtenir des estimations du risque quantitative. Une autre utilisation de lAMDEC est celle qui consiste considrer non pas chaque composant, mais chaque dispositif lectronique dun point de vue fonctionnel. Le niveau de dtail tant plus faible, les analyses permettent destimer les effets plus facilement. Dans notre cas, pour les systmes robotiques, le fait de se placer dans une analyse systme des messages modie lutilisation que lon peut faire de ces techniques et plus particulirement de lAMDEC. Un concept fondamental de cette approche est de ne pas dissocier les composants de leur utilisation. Dans une approche plus classique, le fait de savoir quun capteur peut avoir un certain nombre de dfaillances sans les associer des messages fournit des modles derreurs mais ne met pas en valeur le contexte dans lequel ce capteur est utilis. Or le contexte dutilisation est particulirement important pour le dveloppement de systmes innovants o les composants peuvent tre dtourns de leur utilisation habituelle. Un autre intrt dutiliser une analyse en fonction des messages est la prise en compte des dfaillances des liens de communication (des associations) entre les composants. Cet aspect est trs important pour les composants lectroniques. En effet, chaque message est dpendant de la cohrence du lien entre deux objets, et lorsque lon analyse une erreur de message

4.3 Analyse des dangers et estimation du risque

125
Capteur de position

Axe

Moteur

Limiteur de couple

Rducteur

F IG . 4.19 Diagramme de blocs tir de larticle de Dombre et al. (2001)

Transmet rotation rduite Rducteur Transmet rotation Entrane Moteur Axe Limite le couple Limiteur de couple Capteur de position

F IG . 4.20 Diagramme de classes reprsentant les composants mcaniques dune articulation il convient de prendre en compte la dfaillance de ce lien. Par exemple, si lon tudie les erreurs du message LirePosition() envoy un capteur, et que lon identie une erreur du type incohrence des valeurs retournes (E.9), les causes peuvent tre des dfaillances internes du capteur, mais aussi des perturbations lectromagntiques sur le capteur ou sur le lien reliant le capteur. Ceci nous permet de soulever le fait que la probabilit doccurrence de dfaillance dun message invoquant un service dun composant ne se rduit pas aux donnes concernant les dfaillances de ce composant fournis par le constructeur. Elle prend en compte lensemble des probabilits doccurrence des modes derreur lis ce message. Une fois les modes de dfaillance identis, les modles UML permettent danalyser les effets. Comme prcdemment, les solutions possibles pour la matrise du risque concernent des modications des exigences, de lutilisation et de la conception. 4.3.4.4 Analyse des modes de dfaillance des composants mcaniques

Modlisation des objets et des interactions Larchitecture et les composants mcaniques dun robot sont choisis par les mcaniciens en fonction des exigences fonctionnelles et de performances. Pour ce dveloppement, les techniques de modlisation sont trs spcialises la mcanique. Il est possible de trouver cependant dans les tudes mcaniques une modlisation trs simplie en schma blocs prsent en gure 4.19 (reproduction partielle de larticle de Dombre et al. (2001)). Un tel diagramme fait apparatre les composants les plus importants de la chane cintique permettant deffectuer les mouvements dune articulation, et le Rducteur ralise une mise en

126

Intgration dUML pour lanalyse du risque

forme de lamplitude de la rotation de laxe en vue dune mesure par le Capteur de position. Cette reprsentation prend en compte laspect physique de la distribution des composants, et bien que les composants interagissent avec laxe, ils sont reprsents de manire squentielle comme dans la ralit. La modlisation en objets ne tient compte que des interactions, et donc permet de mettre en vidence les principaux changes de messages. Il est important de noter que tout message sera du type transmission dnergie mcanique. Cela nous conduit proposer une modlisation reprsente sur la gure 4.20. Il est ainsi possible dinterprter une conception mcanique en un ensemble dobjets communicants. Ainsi, lobjet Moteur recevant un message dont les arguments sont une commande en position ou en vitesse, traitera ce message, et entranera le moteur ce qui peut tre vu comme un message Tourner(vitesse) par exemple. Types derreur Les messages reus ou mis par les composants tant identis comme prsent prcdemment, il est possible dutiliser les modles derreur. Tout dabord, avant de considrer les dfaillances du service rendu par les composants, il est possible didentier des erreurs de type E.1, consistant en lenvoi de messages non prvus au sein dune interaction. Par exemple, cela correspond aux dfaillances mcaniques rsultant en des projections, des explosions, des fouets, des dcharges lectrostatiques, etc. Ce type derreur dpend entirement de la catgorie du composant physique (une poulie ne produira pas de dcharge lectrostatique par exemple), et correspond une dfaillance nayant aucun rapport avec la fonction de lobjet. Bien que lon puisse appliquer pratiquement tous les modles derreur que nous avons proposs, les types derreur E.2, E.3 et E.4 ne sont pas applicables car, dans la plupart des cas, les composants mcaniques ne reoivent ou nmettent quun seul type de message. Il en est de mme du type E.9 puisque aucune valeur nest retourne par un dispositif mcanique (en considrant que les capteurs sont des dispositifs lectroniques). En revanche, les erreurs lies au temps E.5 et E.10, sont envisageables pour certains composants dont le temps de rponse par exemple peut tre critique pour la scurit. Cest notamment le cas pour des composants comme les freins lectromagntiques par exemple. Le cas le plus courant est sans doute lerreur de type E.8 concernant la valeur des arguments envoys par un message. Ce mode de dfaillance peut en effet tre assimil une transmission dnergie mcanique errone par rapport ce qui est attendu. Les cas les plus courants sont : une nergie nulle (rupture de la chane cintique) ; une nergie constante (blocage par exemple) ; un pic (discontinuit) ; une drive (pices qui se desserrent) une nergie trop faible ou trop forte.

4.3 Analyse des dangers et estimation du risque

127

Analyse des modes de dfaillance Lapproche que lon propose se base sur la notion de message an de pouvoir utiliser les modles derreur. Cependant, lanalyse des modes de dfaillance peut se faire grce aux tableaux de lAMDEC, en introduisant les noms des composants (et non des messages) lorsque le service se rduit un seul message, et dont le nombre derreur est rduit. Le fait danalyser les erreurs des messages changs entre les composants et non pas les erreurs des composants eux-mmes contribue amener une dimension systme lanalyse. Par exemple, nous travaillons au laboratoire LESIA sur des actionneurs pneumatiques, les muscles articiels prsents dans le chapitre 2, qui peuvent tre tudis suivant lanalyse classique de lAMDEC mais aussi suivant notre dmarche. Dans une analyse classique, on identie partir du composant un ensemble de modes de dfaillance du type crev (fuite dair) ou rupture totale (rupture des bres). Les causes identies sont du type mauvaise conception, mauvaise maintenance, ou mauvaise utilisation, etc. Cette approche concerne lanalyse quun mcanicien pourrait faire pour tudier les aspects concernant essentiellement le muscle articiel. Mais dans le cadre dune application concrte et de lutilisation de ces muscles, nous proposons didentier le service principal dun muscle qui est de convertir une nergie pneumatique en nergie mcanique. Les modes de dfaillance sont alors diffrents, on peut identier suivant les modes derreur proposs prcdemment : nergie transmise trop faible / trop forte (erreur E.8), nergie transmise nulle ou constante (erreur E.8), drive de lnergie transmise (erreur E.8), conversion trop lente (erreur E.10) . Dans ce cas, ceux qui prcdemment taient identis en tant que modes de dfaillance deviennent les causes (la crevaison, la rupture, etc). LAMDEC permet alors de se poser les questions relatives lutilisation des muscles pour cette application (le temps de rponse estil sufsant ? Les exigences de performances sont-elles respectes ? Etc.). 4.3.4.5 Analyse des modes de dfaillance du logiciel

Modlisation des objets et des interactions Dans les systmes informatiques comme les robots mdicaux, il existe des composants part, ce sont les sous-systmes incluant du logiciel. Sur la gure 4.18, lobjet Systme de contrle est celui qui contient le logiciel de lapplication comme cela est prsent sur la gure 4.21. Le modlisation du composant Logiciel de lapplication peut alors tre ralise en utilisant lensemble des diagrammes UML, et notamment les diagrammes de squence. Les messages changs peuvent tre des signaux ou des appels de service (oprations) comportant des arguments et parfois des contraintes de temps. Cet objet est critique dans la plupart des cas, car il peut tre lorigine de nombreux dommages.

128

Intgration dUML pour lanalyse du risque

Systme de contrle
PC

Logiciel du contrleur

Systme d'exploitation

F IG . 4.21 Package reprsentant les lments du Systme de contrle de la gure 4.18 Types derreur et analyse des modes de dfaillance Il est possible dinstancier lensemble des modles derreur pour les messages changs entre les objets informatiques. Cependant, deux contraintes principales propres au logiciel apparaissent. Tout dabord, alors que pour les dispositifs lectroniques et mcaniques il est possible destimer la probabilit de la dfaillance dun message (en gnral lie au composant lui mme et ses connexions), cela est en revanche impossible pour un objet informatique. Cette dfaillance tant due une erreur de programmation, il est impossible den prvoir la probabilit doccurrence. Et ensuite, limportance du nombre de messages changs au sein dun logiciel rend toute analyse systmatique trs difcile. La norme gnrique IEC 61508 (2001), concernant les dispositifs lectroniques programmables, aborde ce problme en introduisant la notion de SIL (Safety Integrity Level). Nous dtaillons ce concept car il semble quaujourdhui cette norme soit la plus utilise dans le domaine des dispositifs lectroniques programmables. Le SIL est un niveau (chiffr de 1 4) attribu un logiciel, qui est considr comme un des composants du systme (composant bote noire), en fonction des dommages quil peut induire pour le systme. Puis, en fonction des choix darchitecture de ce logiciel et les sparations possibles en diffrents modules logiciels indpendants, un niveau SIL est attribu chacun de ces modules. Lintgration de techniques permettant de modier larchitecture de ces modules comme la redondance, les voteurs3 , etc., permet dattribuer de nouveaux SIL aux diffrents modules. Cette norme propose ensuite dutiliser, en fonction du SIL, des tableaux permettant de choisir des techniques de prvention (langages de modlisation), dlimination (vrications, validations, tests, etc.) et de tolrance aux fautes, en donnant pour chaque technique un critre de slection : Non Recommand (NR) ; Recommand (R) ; Hautement Recommand (HR).
Les voteurs sont des sous-systmes qui effectuent un choix entre plusieurs sorties possibles calcules par des sous-systmes redondants
3

4.3 Analyse des dangers et estimation du risque

129

A dfaut de pouvoir estimer les risques de certaines constructions, cette norme se concentre sur la manire de construire le systme, et considre le logiciel comme un composant. Dans le cas des robots de service ayant des contacts avec les humains, le SIL du logiciel sera toujours au maximum (en loccurrence 4), et les techniques seront donc toujours les mmes. Les constructions UML bases sur la notion dobjet permettent de modliser un logiciel en modules indpendants qui correspondent aux composants dans la terminologie dUML. Cependant, les notions mme dobjet et de classe ne peuvent tre values en terme de criticit. Cest le service dlivr par le systme, induit par la collaboration des diffrents objets, qui peut tre quali de critique, et pas les objets. Cette diffrence fondamentale rend impossible lapplication directe de la notion de SIL un logiciel dvelopp en UML. De plus, tous les aspects humains et mcaniques ont t volontairement carts de la norme IEC 61508 (2001). Cependant, en considrant les messages changs entre les objets, il est possible didentier ceux dont les erreurs pourraient induire plus ou moins de dommages. Il est alors possible dattribuer un niveau de criticit, proche du concept de SIL, chaque message. Cependant, en raison du trs grand nombre de messages changs au sein dun logiciel, il semble trs difcile de pouvoir effectuer une analyse complte du logiciel. An deffectuer tout de mme une analyse, il est possible de se restreindre diffrentes catgories de messages (liste non exhaustive) : messages entre objets instancis partir de classes dites actives (celles qui possdent leur propre l dexcution), messages mis ou reus par les interfaces, messages annots par des contraintes de type QoS, messages lis la surveillance des capteurs et des actionneurs (dtection, signalisation, gestion des dfauts), ventuellement lauto-surveillance du logiciel. Il est vident que pour tout systme o il est impossible deffectuer une analyse complte, le choix des messages qui seront analyss dpendra du concepteur. Cependant, en suivant cette liste et en appliquant les modles derreurs prsents dans la section 4.3.3.2, il sera possible de guider les choix de conception du logiciel en fonction de la criticit de certains messages. Comme pour les sections prcdentes, les tableaux de lAMDEC sont utilisables, en enlevant la colonne cause qui ne concerne que les erreurs humaines de conception. Laspect probabilit du risque peut aussi tre retir, mais il est important de conserver la notion de gravit. Lanalyse des risques induits par le logiciel est lobjet de nombreuses tudes du fait de sa complexit. Et le fait que lon propose dans notre dmarche de se limiter des messages critiques , montre bien toute la subjectivit qui peut exister dans une telle analyse. Lapproche que lon propose ici ne permet donc pas de donner une mthode exhaustive, elle se base comme la majorit des activits de lanalyse du risque sur lexpertise du concepteur. La complexit des systmes robotiques actuels, impose lutilisation de techniques non formelles, et qualitatives comme celle que nous proposons.

130

Intgration dUML pour lanalyse du risque

4.3.5 Analyse des arbres de fautes

Lanalyse des arbres de fautes est une mthode inverse de lAMDEC, puisque lon part dun danger et on remonte aux vnements source qui peuvent tre des dfaillances (des erreurs), ou dautres vnements. Il sagit dune technique dite de backward. En complment de lAMDEC, lanalyse des arbres de fautes permet de prendre en compte les dfaillances multiples, ainsi que les interactions entre les fautes de diffrents domaines (lectronique, informatique, mcanique, et erreurs humaines). De plus, elle permet didentier des situations dangereuses rsultant de linteraction de fonctionnements normaux non dfaillants (comme un interblocage par exemple). Un des intrts de lutilisation des arbres de fautes en complment de lAMDEC est de reconsidrer le systme en changeant de point de vue. Cest la richesse des diffrents points de vue qui permettra daborder le problme dans son intgralit4 . Un arbre de faute permet dillustrer la terminologie prsente au chapitre 1, puisque lon peut retrouver dans la combinaison de ces vnements des phnomnes dangereux (dfaillances, tats dangereux, et des proprits inhrentes dangereuses), des situations dangereuses et des vnements dommageables. Le lien se fait naturellement avec les tableaux de lAMDEC puisque des nombreux vnements sont identis dans les colonnes des modes de dfaillance et des effets. Cependant, lanalyse des arbres de fautes ne peut sappuyer directement sur la notion de message, car un arbre est constitu dvnements qui peuvent tre notamment : des vnements non modlisables en UML (par exemple Inattention de loprateur), des situations plus complexes quun simple tat et non modlisables en tant que message (par exemple Un oprateur pntre dans la zone de travail du robot), un tat dun sous-systme (comme Robot en mouvement). Lutilisation que lon en a faite sest donc restreinte ltude dun cas particulier, celle de la dfaillance de linteraction prvue entre le robot et lhumain. Pour partir de ce danger, appel lment racine de larbre, rsultant dune interaction ngative entre un acteur et le systme technologique, il est possible de sappuyer sur une modlisation de cette interaction en UML. En effet, il est possible de spcier cette interaction grce un diagramme de classes comme celui de la gure 4.22. Dans ce cas, linteraction qui nous intresse est les dplacements de la sonde sur le patient. Pour dterminer larbre de fautes, on peut partir dune interaction nfaste entre la sonde et le patient, et remonter les composants jusquau contrleur. Les vnements ici sont gnriques, mais il est possible de dtailler chaque vnement en prcisant les dfaillances (la dfaillance robot pouvant tre une pice qui tombe, un axe qui est bloqu, etc.). Une partie de cette analyse est donne gure 4.23. partir du diagramme de classes de la gure 4.22, on identie donc les composants pouvant mener au danger racine. Cependant, il existe dautres interactions non modlisables
Cependant les points de vue concernent la manire dont on dcrit un systme, et ce nest pas la multiplication de techniques ou de langages utiliss qui augmentent le nombre de points de vue. Comme dans UML, on peut utiliser le mme langage pour exprimer plusieurs points de vue (voir section 3.2.3.3).
4

4.3 Analyse des dangers et estimation du risque

131

Site matre envoie consignes envoie commande

<<system>>

<<external output device>>

Contrleur de robot

Actionneur

fournit position fournit force

capte la position

fournit nergie mcanique

<<external input device>>

Capteur de position Robot

transmet mouvements

<<external input device>>

<<external device>>

Capteur de force capte les efforts

Sonde

se dplace sur

Patient

F IG . 4.22 Diagramme de classes dun robot manipulateur dune sonde quelconque pour lexamen dun patient

Pression exerce par la sonde sur le patient trop importante

OU
Erreur de commnande

Dfaillance robot

Dfaillance actionneur

OU

Dfaillance capteur de position

Erreur consigne

Dfaillance capteur de force

Erreur de calcul de la commande

Dfaillance contrleur

F IG . 4.23 Exemple darbre de fautes pour un effort de la sonde trop important sur le patient

132

Intgration dUML pour lanalyse du risque

comme un pice projete sur le patient, des transferts dnergie non prvus, etc. Ces cas restent tout de mme moins complexes car ils rsultent de leffet direct dune dfaillance sur les humains dans lenvironnement du robot, et lutilisation des arbres de fautes apporte une synthse des lments de lAMDEC correspondants. Ltape suivante danalyse correspond une utilisation classique des arbres de fautes, qui consiste identier des coupes minimales correspondant un ensemble de fautes directement relies llment racine (Leveson, 1995). Puis chaque vnement est trait par des techniques dlimination, de prvention et de tolrance aux fautes. Ces informations sont communes aux rsultats de lAMDEC, mais on obtient une vue plus synthtique du risque li un danger.

4.4

Conclusion

La dmarche propose sintgre dans un processus de dveloppement utilisant la notation UML. Les diffrentes tapes peuvent tre compltes de manire continue, et suivre un processus itratif et incrmental. Pour cela, il suft de rafner les diffrents tableaux de lanalyse prliminaire et de lAMDEC, puis de complter les arbres de fautes avec les dfaillances des mcanismes et des composants introduits au fur et mesure des itrations. Il existe donc en permanence des relations entre le processus de dveloppement et lanalyse du risque. On peut modliser de faon trs simple le processus comme prsent sur la gure 4.24, et pour la premire itration suivre ces tapes : modliser le mtier en analysant chaque cas dutilisation et en se concentrant sur les changes dnergie, les mouvements effectus par les acteurs, les contacts entre acteurs et lments dinterface avec la tche ; intgrer le robot dans la modlisation du mtier, allouer les tches entre les acteurs et la technologie et dtailler les ches des cas dutilisation (notamment les contraintes de scurit et de performances) ; dnir les frontires du systme et dcrire les tches des acteurs avec des diagrammes de squence ; identier les principaux dangers par une analyse prliminaire et complter les cas dutilisation avec les rsultats de cette analyse ; identier les phnomnes dangereux et estimer les risques lis aux messages en utilisant lAMDEC et en se basant sur des analyses faites par des spcialistes de chaque domaine ; synthtiser les diffrentes analyses de lAMDEC avec des arbres de fautes en prenant en compte les dfaillances multiples. Cette dmarche permet dans un premier temps de dnir les tches et les rles des acteurs de manire non ambigu grce aux cas dutilisation et aux diagrammes de squence. Il est vident que les modles ne peuvent sufre eux seuls la capture des besoins et des informations sur le systme. Cependant, les modles doivent toujours tre le point de dpart dtudes

4.4 Conclusion

133

Modlisation mtier

Modlisation du systme
Cas dutilisation
Diagrammes dinteractions

Autres diagrammes

Description de lutilisation Description des exigences Description de la conception

Modification de lutilisation Modification des exigences Modification de la conception

Analyse prliminaire des risques

Domaine Danger Acteurs Oprateur
Dplacement sur une zone sensible ou dangereuse du patient Pression trop importante sur le patient Cas dutilisation

Solutions possibles

Remarques

Gravit

Configurer tche

Raliser tche

Patient

Robot

Physique

1 Spcification dune
zone de travail avant la tche. Contraindre les mouvements dans cette zone.

Envisager des solutions logicielles mais aussi matrielles

X X X X

X X X

1 Contraindre les efforts

des mouvement grce un capteur de force Aucune partie mtallique ne doit tre en contact avec le patient Rpondre aux normes en vigueur pour le systme lectrique (fusible, alimentation aux normes, etc)

Electrique

Electrocution

Dcharge lectrostatique

2 Les parties mtalliques

du robot doivent tre relies la masse

Occurrence

Code

Date :17/01/2003 Par : J.Guiochet Composant / Fonction/ Message

AMDEC
Nom du projet
Risque Svrit Mode de dfaillance (erreur) Cause de la dfaillance Risque Effets : a. Niveau local b. Niveau suprieur c. Niveau systme Moyens de dtection possibles (en ligne) a. Mode dfaillance b. Effets

Page :

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques

Analyse des arbres de fautes

F IG . 4.24 Rsum de la dmarche prsente

134

Intgration dUML pour lanalyse du risque

plus pointues. Ainsi, un diagramme de classes des acteurs permet de dcrire les interactions entre acteurs et les responsabilits de chacun, mais peut tre accompagn de documents relatant les capacits mentales et physiques, les comptences ou la formation de chaque acteur. La documentation lie aux cas dutilisation permet de donner un cadre aux diffrentes analyses effectues ds le dbut dun projet. Ainsi, il est possible de spcier pour le cas dutilisation gnrique Raliser tche, tous les changes dnergie critiques pour la scurit et le type dinteractions entre le systme et les humains. Il est alors fondamental daccompagner les cas dutilisation de leur description textuelle. De plus, il est possible de faire apparatre dans ces documents des contraintes de scurit absente de la modlisation graphique. Enn, il est important de souligner que les cas dutilisation permettent de dnir les frontires du systme analys, et concentrer ainsi les efforts des analystes. Lapparition de dommages au sein dun systme nest due qu sa propre dynamique. Et par consquent, les dangers sont en partie lis lchange de messages au sein dun systme. En se basant sur la notion de Message en UML, nous avons prsent des modles derreur lis ce concept. Nous avons montr comme ces modles taient applicables diffrents domaines dtudes. De plus lensemble des exemples montre que ces modles derreur peuvent tre utiliss de manire gnrique diffrentes applications. Le lien a donc pu tre tabli entre les concepts objet, et la technique de lAMDEC pourtant ddie lorigine lanalyse fonctionnelle. Notons que la terminologie prsente au chapitre 1 sadapte ces diffrentes techniques, et lon a notamment illustr certains concepts au sein des tableaux de lAMDEC. Cependant, un tel travail na pu tre men avec lanalyse des arbres de fautes, dont lutilisation ne prend en compte quun type de danger et un effort doit tre ralis dans ce sens. Lutilisation combine des techniques de lAMDEC, des arbres de fautes et dUML, permet davoir vritablement une analyse systme. Certains diagrammes du langage UML permettent en effet de reprsenter les interactions entre les humains et diffrents composants lectroniques ou mcaniques, et les arbres de fautes regroupent les dfaillances de tous les domaines. Au sein des tableaux de lAMDEC, les modes de dfaillance sont propres un domaine, mais les effets identis ainsi que les solutions proposes couvrent tous les domaines, dont les facteurs humains. Ce dernier aspect sil nest pas voqu explicitement lors dune tape apparat tout au long de la dmarche. En effet, la description du systme inclut les activits dallocation et danalyse des tches, et lidentication des dangers inclut lanalyse des erreurs humaines. Il est alors possible de regrouper ces activits (Guiochet et al., 2003b) pour souligner laspect novateur de cette dmarche, mais elles doivent tre intgres tout au long du processus. Un dernier point relatif aux exigences que lon stait xes au dpart, concerne lanalyse du risque du logiciel. Cette problmatique, tant traite actuellement par plusieurs normes, est encore sujette de nombreux travaux. La solution que lon propose dans ce chapitre repose en partie sur lexpertise du concepteur et sa capacit identier les messages critiques, ce qui ne peut tre ni exhaustif ni vriable. Cependant, pour une dmarche systme, le fait de considrer le logiciel comme un composant part entire permet dj de rduire les principaux

4.4 Conclusion

135

risques. Lanalyse plus pointue du logiciel, et des messages changs entre ses objets, est un domaine ouvert de nombreuses recherches. La dmarche propose semble rpondre aux diffrentes exigences identies au premier chapitre. On dispose dune analyse du risque systme, incluant les facteurs humains, reposant sur des techniques connues des ingnieurs, intgrant les analyses des dfaillances du logiciel, et favorisant la traabilit par lutilisation du langage UML. Bien que certains aspects soient limits dans leur prsentation thorique, nous proposons dans le chapitre suivant une application de cette dmarche un systme de robot mdical pour la tl-chographie.

Chapitre 5 Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

5.1 Introduction

Ce chapitre consiste en lapplication de la dmarche propose au chapitre 4 et lutilisation des muscles articiels prsents dans le chapitre 2, un robot mdical pour la tlchographie. Des membres du LESIA sont intervenus titre dexperts pour la fabrication et la commande des muscles articiels, ainsi que pour une analyse de la scurit du site esclave. Ce travail a pu tre ralis grce un travail en collaboration avec Adriana Vilchis de lquipe GMCAO du laboratoire TIMC/IMAG1 . Le lecteur pourra trouver de nombreuses informations relatives la conception de ce systme dans son mmoire de thse (Vilchis, 2003). Bien que la dmarche propose prcdemment sapplique ds le dbut du processus de dveloppement, nous navons pu intervenir qu une tape avance du dveloppement du site robotis. Il nexistait alors aucune modlisation du systme et le processus de dveloppement ne suivait aucune mthode spcique. Par ailleurs, il nexistait pas dtude dtaille concernant la scurit. Ceci tait principalement d au fait que ce dveloppement se faisait dans le cadre dun projet de recherche, et que le premier objectif tait de valider des choix de conception du robot et de sa commande, et de prouver la faisabilit dun tel projet en vue dune version ultrieure. Le travail a donc consist synthtiser et modliser en UML les rsultats de diffrentes tapes du processus de dveloppement. Puis appliquer la dmarche danalyse du risque base sur ces modles. Les rsultats de cette analyse ont servi rednir certaines exigences et modier certains points de la conception. Cependant, ltat davancement du projet a rendu impossible certaines propositions qui pourront tre implantes sur une prochaine version.
1

http ://www-timc.imag.fr/gmcao

138

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Les sections de ce chapitre suivent les tapes prsentes au chapitre 3 concernant lanalyse du risque. Ainsi, aprs une prsentation du projet TER dans la section 5.2, la section suivante (5.3) aborde la description du systme et de son utilisation. La section 5.4 tudie ensuite lidentication des phnomnes dangereux et lestimation du risque.

5.2

Prsentation du projet TER

Lchographie est un examen trs frquent dans le milieu mdical, notamment lors dune grossesse, pour vrier ltat de sant du ftus et de la mre. Le diagnostic repose sur la confrontation entre la lecture des images de lchographie et la connaissance des dplacements de la sonde sur le ventre de la patiente. Pour cela, cet examen dpend entirement de lexpertise du mdecin, et demande un long apprentissage et des connaissances trs spciques. Cet examen est donc difcile daccs pour les patients se trouvant loin de grands centres hospitaliers. La tl-mdecine, grce aux tlcommunications, permet des spcialistes de raliser de tels gestes, en se trouvant dans une rgion diffrente de celle du patient. Il est donc possible dappliquer ce concept lexamen dchographie comme cela a t propos par de nombreux projets. Vilchis et al. (2001b) proposent une synthse de diffrents projets. Le projet TER concerne la Tl-chographie Robotise et se place dans le cadre plus gnral de la tl-mdecine. Il devrait permettre un spcialiste dausculter distance une patiente, grce un systme robotis permettant de raliser les dplacements de la sonde sur la patiente. Cest un projet regroupant plusieurs industriels (France Telecom, SINTERS, PRAXIM), hpitaux (CHU Trousseau, CHU de Grenoble) et laboratoires (TIMC/IMAG, LVR) franais (Vilchis et al., 2001a), et nanc par le Ministre de lducation Nationale, de la Recherche et de la Technologie en 1999. Le systme propos pour la tl-chographie consiste en un site matre et un site esclave. Le mdecin spcialiste se trouvant sur le site matre, dplace une sonde virtuelle et consulte les images produites par les dplacements de la sonde relle sur le ventre de la patiente se trouvant sur le site esclave. Larchitecture gnrale du systme est reprsente sur la gure 5.1. Les informations changes entre les sites concernent les images de lchographie, les donnes lies aux dplacements du robot, les forces exerces par la sonde (donnes haptiques), et des informations audiovisuelles concernant les oprateurs des deux sites. Cette architecture a t choisie par les diffrents partenaires avant deffectuer lanalyse prsente par la suite. Elle correspond une solution qui dcoule de nombreuses tudes menes par les consortium TER dont les documents ne sont pas tous accessibles. Cependant nous reviendrons sur cette solution pour justier les choix qui ont t faits.

5.3 Dnition du systme et de son utilisation

Site Matre Rseau Site esclave

139

Informations audiovisuelles Informations du robot

Informations haptiques

Images chographiques

F IG . 5.1 Vue gnrale du systme TER

5.3

Dnition du systme et de son utilisation

Comme prsent dans le chapitre 3, la dnition du systme constitue la premire tape dune analyse du risque. Elle concerne successivement la modlisation du mtier (section 5.3.1), lintroduction du robot dans le mtier avec une allocation des tches (section 5.3.2), la dnition des frontires de lanalyse (section 5.3.3), puis une analyse des tches (section 5.3.4).

5.3.1 Modlisation du mtier : lexamen chographique

Lobservation dexamens chographiques, la consultation dexperts, linterview des diffrents acteurs, et lobservation de documents vido, ont abouti sur un concept de dispositif technologique de tl-chographie original mais, sans avoir rellement pris en compte lensemble du systme comprenant les acteurs. La premire tape de notre dmarche, qui correspond ce qui a t fait par les quipes du consortium TER, est lobservation du mtier de lchographie sans introduire le systme robotique. En donnant un cadre par une modlisation, on assure que les diffrents lments ont bien t apprhends et seront drivs pour la suite du dveloppement. La dtermination de ces cas dutilisation dcoule dun travail didentication des acteurs et des tches effectues, puis de synthse pour exprimer les relations avec chaque acteur. Le point de vue que lon prend ici est celui de lacteur principal, le spcialiste mdical, que lon nommera par la suite Spcialiste. Un autre acteur est videmment le Patient. Nous avons choisi de reprsenter le Systme dchographie, aussi appel chographe, comme un acteur au sens o le Spcialiste interagit avec ce systme et modie ses actions en fonction des rsultats fournis par le systme. De plus le systme dchographie est fourni par des constructeurs et peut tre modlis avec le diagramme de dploiement de la gure 5.2, en reprsentant les deux composants principaux : la sonde et la station de contrle. Les acteurs et leurs relations peuvent tre exprims avec un diagramme de classes comme sur la gure 5.3. On identie ainsi lors de lexamen chographique quatre cas dutilisation reprsents sur la gure 5.4 :

140

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Station de contrle

<<RS232>>

Sonde

F IG . 5.2 Diagramme de dploiement du systme dchographie

Patient Spcialiste

Systme d'chographie

F IG . 5.3 Diagramme de classes des acteurs de lexamen chographique tablir un diagnostic ; Raliser le geste mdical ; Gestion du systme dchographie ; Gestion patient. Cette reprsentation fournit un cadre pour lobservation et la collecte dinformations relatives au mtier. Il est en effet possible de noter grce aux descriptions textuelles des cas dutilisation, toutes les informations concernant lexamen. Sil existe une information ne pouvant rentrer dans un cas dutilisation, il y a de fortes chances pour que le diagramme des cas dutilisation soit incomplet. Un autre point qui est fondamental pour la modlisation en cas dutilisation est le fait quils doivent pouvoir sexcuter en parallle, ce qui est bien respect ici. Les descriptions textuelles des cas dutilisation sont donnes ci-dessous en utilisant les ches prsentes dans le chapitre prcdent (4.2). Cas dutilisation Acteurs Description tablir un diagnostic Spcialiste Le Spcialiste tablit un diagnostic en confrontant les images fournies par le systme dchographie et la connaissance des dplacements de la sonde sur le Patient Les images sont afches et le Spcialiste connat les mouvements effectus Le Spcialiste informe le Patient du diagnostic

Pr-conditions Post-conditions

5.3 Dnition du systme et de son utilisation

141

Etablir un diagnostic

Systme d'chographie

Raliser geste mdical

Spcialiste

Gestion Systme d'Echographie

Gestion patient Patient

F IG . 5.4 Diagramme des cas dutilisation de lexamen chographique Cas dutilisation Acteurs Description Gestion du systme dchographie Principal : Spcialiste Secondaire : Systme dchographie Le systme dchographie fournit les images au Spcialiste. Le Spcialiste modie tout moment les rglages du Systme dchographie et notamment les paramtres des ultrasons. Il utilise certains outils disponibles de traitement de limage (calcul de longueur, agrandissements, etc.) La gestion du systme dchographie doit pouvoir tre ralise tout en effectuant les dplacements de la sonde Les systmes dchographie utiliss sont certis et les interfaces sont standardises

QoS Contraintes techniques

142

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Cas dutilisation Acteurs Description

QoS

Gestion patient Spcialiste et Patient Le Spcialiste installe et dsinstalle le Patient et rpond ses questions. Il recouvre la surface qui sera en contact avec la sonde avec du gel permettant une meilleure conduction des ultrasons et facilitant les dplacements. Il dlivre au Patient par voie orale le rsultat du diagnostic (sachant que le diagnostic peut tre une impossibilit dinterprtation). Le Patient rpond aux questions du Spcialiste ou met des requtes. Il sagit de mettre en conance le Patient et linstaller de faon limiter le stress. La dose de gel doit tre sufsante et prsente partout o la sonde se dplacera

5.3 Dnition du systme et de son utilisation

143

Cas dutilisation Raliser le geste mdical Acteurs Principal : Spcialiste Secondaire : Systme dchographie Description Le Spcialiste ralise le geste de lchographie en dplaant la sonde sur la surface recouverte de gel. Il adapte ses mouvements en fonction des images fournies par le systme dchographie. Les mouvements de la sonde sont : des translations dans le plan lies la surface du Patient, des rotations suivant les trois axes x, y, et z rfrencs par rapport la sonde, une translation orthogonale la surface pour augmenter la pression. Une tude dtaille de ces mouvements est fournie dans les thses de Guerraz (2002) et Vilchis (2003). Pr-conditions Le systme dchographie est connect et fonctionne correctement. Le Patient est install et la surface pour lauscultation est recouverte de gel. Alternative Le Spcialiste peut stopper tout moment le geste et retirer la sonde du Patient puis : il peut ensuite reprendre lexamen, il peut alors remettre du gel et reprendre le geste, il peut arrter lexamen. QoS La pression sur le ventre ne dpasse pas 1,5 daN (effort maximum mesur de 1,3daN (Guerraz, 2002)) sur une surface de 20cm2 La vitesse de dplacement de la sonde est de lordre du centimtre par seconde Les dplacements ne sortent pas de la zone o le gel est appos

5.3.2 Systme robotis pour la tl-chographie et allocation des tches

partir de la modlisation prcdente, il est possible de spcier les tches des acteurs et du systme, et de conserver ainsi une cohrence (donc rduire les risques derreurs) entre la tche sans robot et celle de tl-mdecine robotise. Lutilisation dun robot peut se rsumer aux cas dutilisation gnriques prsents sur le diagramme de la gure 5.5. On dnit ces cas dutilisation ainsi :

144

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Configuration du robot Robot Technicien

Raliser tche

F IG . 5.5 Diagramme des cas dutilisation dun robot Cas dutilisation Raliser tche Acteurs Technicien et Robot Description Le Robot ralise une tche en suivant les ordres du Technicien. LOprateur sil le dsire peut interrompre la tche tout moment. Pr-conditions Le contrleur est congur pour effectuer la tche. QoS Les contraintes sont spciques la tche Cas dutilisation Conguration du Robot Acteurs Technicien et Robot Description Le Technicien entre les donnes qui permettent de raliser la tche. Il installe et dsinstalle certaines composantes du Robot. Il assure la maintenance du Robot. Remarques Les tapes dinstallation et de conguration sont particulirement critiques pour la scurit. Lintgration dun systme robotique dans une tche dchographie implique lintgration des cas dutilisation lis lutilisation dun robot. Il faut donc intgrer les deux cas dutilisation de la gure 5.5 au diagramme de la gure 5.4. Le fait dintroduire un systme de tl-opration modie le diagramme des cas dutilisation de diffrentes manires : il existe maintenant deux points de vue suivant le site sur lequel on effectue lanalyse, le Site matre et le Site esclave. Le Spcialiste est localis sur le Site matre. Nous nous intressons pour la suite au Site esclave o la scurit est critique ; lacteur Spcialiste ne se trouve plus sur le site esclave, mais il est remplac par lacteur Site matre avec lequel le systme communique. De ce fait, le cas dutilisation tablir un diagnostic napparat pas sur le diagramme des cas dutilisation du site matre ; le choix a t fait dintroduire un sous-systme de visio-confrence pour grer la communication entre les deux sites. Les acteurs doivent alors grer ce sous-systme ;

5.3 Dnition du systme et de son utilisation

145

Site matre

Raliser tche Robot esclave

Gestion Visio Confrence Oprateur

Configuration du robot

Gestion patient Gestion Systme d'Echographie

Patient Systme d'chographie

F IG . 5.6 Diagramme des cas dutilisation du site esclave le cas dutilisation de la gure 5.4 nomm Raliser geste mdical devient Raliser tche (en considrant que la tche effectue par le Robot sera le geste mdical qui consiste dplacer la sonde chographique). On identie alors les diffrents cas dutilisation de la gure 5.6, qui dcrivent les rles des acteurs, et la manire dont ils vont utiliser le systme. Une description plus prcise des tches est effectue dans la section suivante au travers des diagrammes de squence. On dnit ainsi un nouvel acteur nomm Oprateur, qui hrite dune partie des aptitudes du Spcialiste, et du Technicien. Pour exprimer le fait quil existe un acteur pouvant tre capable de grer le Patient et de rgler le systme dchographie, on peut introduire un nouvel acteur nomm Assistant nayant pas la formation pour effecteur le geste mdical et le diagnostic. Le Spcialiste hrite donc de cet acteur car il possde toutes les caractristiques de lAssistant plus dautre aptitudes (en UML on parle alors de spcialisation). Ces concepts sont modliss sur le diagramme de classes de la gure 5.7. De lanalyse du diagramme des cas dutilisation de la gure 5.6, on peut dj conclure que le rle de lOprateur sera important, car il concerne cinq cas dutilisation. Ceci peut mener se poser la question des capacits de lOprateur raliser lensemble des tches qui lui seront assignes, et ainsi rduire la probabilit doccurrence dune erreur humaine due une tche trop complexe. Cette allocation, fondamentale pour la scurit, doit faire lobjet dun choix des concepteurs. Une autre solution aurait t de prvoir

146

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Assistant

Technicien

Spcialiste

Oprateur

F IG . 5.7 Diagramme de classes des acteurs la prsence sur le site esclave de deux acteurs, un Assistant et un Technicien. Ces deux acteurs sont dcrits dans le diagramme de classes de la gure 5.7. Lallocation des tches effectue ici rsulte des tapes prcdentes mais aussi de lanalyse des tches que lon effectue ultrieurement. La prsentation des modles est faite ici de manire squentielle mais leur ralisation a suivi un processus itratif et incrmental.

5.3.3 Dnition des frontires de lanalyse

Sur la base du diagramme des cas dutilisation de la gure 5.6, il convient de dnir les frontires du systme que lon souhaite analyser. Dans le cadre du projet global TER, lensemble des cas dutilisation doit tre trait. En ce qui concerne notre analyse guide par lanalyse du risque, on choisit de se restreindre au systme de contrle du robot du site esclave. Les cas dutilisation qui sont exclus alors du systme de contrle sont Gestion Visio-confrence et Gestion Systme dchographie. Ces cas dutilisation concernent en effet deux sous-systmes qui ninterviennent pas dans la ralisation de la tche dchographie. Il est alors possible de reprsenter ces deux sous-systmes sous forme de packages comme cela est prsent sur la gure 5.8. Il est aussi intressant de modliser la rpartition des acteurs au sein des packages comme cela est reprsent. Le fait que le package Visio-confrence esclave utilise le package Systme dchographie exprime le fait que les images de lchographie seront traites en mme temps que les autres donnes audio-visuelles envoyes sur le rseau. An dallger les diagrammes, nous nutiliserons plus par la suite la notion de Site esclave qui sera implicite ; nous noterons Systme de contrle TER au lieu de Systme de contrle du site esclave. On en dduit alors le diagramme gnral des cas dutilisation de la gure 5.9. Les diffrents points suivants consistent dcrire chaque cas dutilisation pour rafner les tches que les acteurs auront effectuer. Cela permet aussi de dnir lensemble des contraintes, dont certaines inuent sur la scurit, et de dnir une base pour lanalyse du risque.

5.3 Dnition du systme et de son utilisation

147

Site matre

Site esclave

Systme de contrle matre

Spcialiste

Systme de contrle esclave

Oprateur Patient

Robot matre

Robot esclave

Visio-confrence Matre

Visio-confrence esclave

Systme dchographie

F IG . 5.8 Packages et acteurs du systme global

Systme de contrle TER

Site matre

Raliser tche

Robot esclave Configuration du robot

Oprateur Patient

Gestion patient

F IG . 5.9 Diagramme des cas dutilisation du systme de contrle esclave, que lon note par la suite Systme de contrle TER

148

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Sonde

Anneau de rotation Anneau de translation

Cables

F IG . 5.10 Vue de leffecteur du robot esclave TER

5.3.4 Analyse des tches

Pour chaque cas dutilisation, nous montrons comment la modlisation guide certains choix de conception du systme, puis comment les tches des acteurs peuvent tre analyses en utilisant les diagrammes de squence. 5.3.4.1 Cas dutilisation Raliser tche

La description de la tche dchographie en terme de mouvements et les diffrentes contraintes exprimes dans la partie 5.3.1, ont conduit les concepteurs proposer une architecture robotique originale. Ils ont aussi pris en compte des contraintes dencombrement rduit et de portabilit systme en vue dune utilisation dans des rgions isoles. Larchitecture conue se diffrencie des structures de type bras manipulateur par une architecture parallle, comme prsente sur la gure 5.10. Ce robot ne comporte donc aucune articulation en srie, comme un bras articul, et les mouvements se font par des variations de longueur des diffrents cbles relis aux anneaux soutenant la sonde chographique. Une description plus dtaille est fournie par Vilchis et al. (2001a,b); Vilchis (2003). Un autre point important de la conception est lutilisation des muscles articiels prsents dans le chapitre 2. Le choix de ces actionneurs a dabord t fait dans un but de recherche, et non en suivant les rsultats dune analyse du risque. Nous montrerons par la suite ce quapportent ces actionneurs la scurit de lexamen chographique robotis. Le cas dutilisation Raliser tche est principalement dclench par le Site matre. Cest lui qui envoie les consignes de mouvements au site esclave, et ce dernier retourne les informations lies au dplacement rel du Robot sur le Patient. Une des exigences dun tel systme est la transmission au site matre des efforts exercs sur le patient. Le scnario principal du cas dutilisation Raliser tche est reprsent sur la gure 5.11. Ce cas dutilisation trs clas-

5.3 Dnition du systme et de son utilisation

149

: Site matre Lancer chographie Contrler robot (consignes)

Systme de contrle TER

Contrler mouvements

Lire position Lire force Mise jour donnes (position,force)

Arrter chographie

Ce message devient par la suite un cas dutilisation luimme dcompos en deux cas dutilisation pour les diffrents modes de fonctionnement.

F IG . 5.11 Diagramme de squence du scnario principal de Raliser tche sique en robotique inclut trs souvent trois cas dutilisation prsents par Carroll (1999), et reprsents sur le diagramme des cas dutilisation de la gure 5.12 : la planication et/ou linterprtation des tches ; le contrle des mouvements ; le contrle de loutil. Dans le cas du robot esclave TER, il ny a pas de planication de tche effectuer puisque le site esclave reoit directement des ordres de mouvements. Cependant, il est possible de conserver un cas dutilisation nomm Interprter tche, notamment pour interprter les changements de modes de dplacement exposs ultrieurement. De plus, labsence doutil sur le robot esclave TER nous conduit supprimer le cas dutilisation Contrle de loutil. An de pouvoir rpondre aux exigences lies la ralisation du geste mdical, deux modes de fonctionnement ont t identis : un mode de tl-opration continu : les consignes sont envoyes avec une priode xe 500 ms ; un mode de suivi de trajectoire : le site matre envoie la position initiale, la position nale, la vitesse du dplacement et lacclration, puis le site esclave gnre et contrle les mouvements suivant cette trajectoire. En considrant que lanalyse est pour linstant de trs haut niveau, et comme le nombre de cas dutilisation est trs rduit, il est possible de crer deux cas dutilisation qui hritent du cas dutilisation Raliser tche et qui reprsentent les deux modes de fonctionnement : Contrler mouvements en tl-opration et Contrler mouvements en trajectoire gnre.

150

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Interprter tche <<include>> Site matre <<include>> Contrler mouvements en Tlopration

Raliser tche Contrler mouvements <<include>>

Oprateur

Contrler mouvements en trajectoire gnre Contrler outil

F IG . 5.12 Cas dutilisation en relation avec Raliser tche partir des ches des cas dutilisation Raliser tche et Raliser le geste mdical des diagrammes exposs prcdemment, on dnit une nouvelle che pour le cas dutilisation Raliser tche propre au site esclave TER. Cette description textuelle est donne ci-dessous.

5.3 Dnition du systme et de son utilisation

151

Cas dutilisation Acteurs Description

Raliser tche Site matre, Robot et Oprateur Les consignes de mouvements de la sonde sont envoyes par le site matre. Ces mouvements sont effectus par le Robot auquel est x la sonde. Les donnes de position relle du Robot esclave et de force exerce sur le Patient sont renvoyes au site matre. Deux modes de fonctionnement sont prvus : mode tlopration : les consignes de mouvements sont envoyes toutes les 500ms et le Robot suit les mouvements du Site matre mode gnration : le Site matre envoie un point de dpart, un point darrive, une vitesse et une acclration, les points de la trajectoire sont calculs, puis le mouvement est contrl. Patient et Robot installs, contrleur congur pour la tche et la connexion au site matre tablie. Le Robot est retir du Patient. LOprateur peut contrler lexcution de la tche : il peut suspendre la tche et lannuler ou la reprendre il peut annuler la tche.

Pr-conditions Post-conditions Alternative

QoS

La pression sur le ventre ne dpasse pas 3daN sur une surface de 20cm2 . La vitesse de dplacement de la sonde est de lordre du centimtre par seconde. Les dplacements ne sortent pas de la zone o le gel est appos. Les dplacements ne sortent pas dune zone pr-dnie non dangereuse. Contraintes techniques La localisation 3D de la sonde se fera grce un systme Polaris (produit de Northern Digital Inc, http ://www.ndigital.com) dj utilis pour dautres applications. Les actionneurs du robot sont des muscles articiels. Larchitecture du robot est parallle comme prsente sur la gure 5.10. Remarques En raison de la structure innovante du robot, et de lutilisation des muscles articiels dont la commande en boucle ferme est complexe, le contrle des mouvements doit faire lobjet dune valuation trs pousse pour estimer la stabilit et la uidit des mouvements. De cette description, on peut en dduire le diagramme de squence de la gure 5.13 reprsentant le scnario principal du contrle de lexcution de la tche par lOprateur (ligne

152

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

: Oprateur

: Systme de contrle TER

Figer le systme

: Site matre

Suspendre la tche

: Robot

: Patient

Informer

Relancer la tche
Contrler mouvements

Informer

Annuler la tche
Retirer nergie du robot

Informer
Peut se faire en urgence ou aprs avoir suspendu la tche

Dsinstaller

Dsinstaller

F IG . 5.13 Diagramme de squence du contrle de lexcution de la tche par lOprateur Alternative dans le tableau ci-dessus). Les diffrents messages que peut envoyer lOprateur sont indpendants, mais ils sont reprsents ici sur le mme diagramme pour en limiter le nombre. Il ny a en effet aucune contrainte sur lordre de ces messages. Cette contrainte sera exprime ultrieurement avec un diagramme dtats, et on reprsente ici tous les messages possibles que lOprateur peut mettre. Les diffrents messages que lon identie ici peuvent faire lobjet dun cas dutilisation spar de Raliser tche. Tout en sy rapportant, ces scnarios sont en effet diffrents du cas dutilisation principal, ils reprsentent une utilisation particulire. UML permet alors dutiliser la notion dextension pour le diagramme des cas dutilisation (strotype extend). On modlise ainsi un nouveau cas dutilisation, Contrler lexcution de la tche qui tend le cas dutilisation Raliser tche (cf. gure 5.14). Les cas dutilisation Contrler mouvements, Contrler mouvements en tlopration, et Contrler mouvements en trajectoire gnre, ne sont pas dtaills ici sous forme de ches, car ils sont inclus dans la description du cas dutilisation Raliser tche. Le cas dutilisation Interprter tche ne fait pas non plus lobjet dune description textuelle car dans le cas dun systme TER, il se limite linterprtation dun message mis par le site matre.

5.3 Dnition du systme et de son utilisation

153

Raliser tche <<extend>>

Contrler l'excution de la tche

Oprateur

F IG . 5.14 Cas dutilisation Contrler lexcution de la tche 5.3.4.2 Cas dutilisation Gestion patient

Ce cas dutilisation est proche de celui prsent lors de la modlisation mtier. Lacteur Oprateur hrite donc dune partie des tches du Spcialiste, ou plus prcisment dun acteur Assistant dni dans le diagramme de classes de la gure 5.7. Cas dutilisation Acteurs Description Gestion patient Oprateur et Patient LOprateur installe et dsinstalle le Patient, le surveille et rpond ses questions. Il recouvre la surface qui sera en contact avec la sonde avec du gel permettant une meilleure conduction des ultrasons et facilitant les dplacements. Le Patient rpond aux questions de lOprateur ou met des requtes. Lors de lexcution de la tche, lOprateur peut suspendre la tche (cas dutilisation Contrler lexcution de la tche), et remettre du gel sur certaines parties de la surface. Il sagit de mettre en conance le Patient et linstaller de faon limiter le stress. La dose de gel doit tre sufsante et prsente partout o la sonde se dplacera.

Alternative

QoS

5.3.4.3

Cas dutilisation Conguration du robot

La Conguration du robot peut souvent faire lobjet de deux cas dutilisation spars : la programmation de la tche et la conguration du contrleur exposs par Carroll (1999). Dans le cas du robot TER, la structure particulire du robot esclave, et surtout le fait quil faille installer dabord le patient, puis le robot, implique une imbrication de ces deux cas dutilisation. Nous avons donc choisi de reprsenter ces exigences en un seul cas dutilisation que lon nomme donc Conguration du robot. Lensemble des actions que lOprateur aura effectuer sont dcrites par le diagramme de squence de la gure 5.15. Au sein de ce diagramme on

154

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

: Oprateur

: Systme de contrle TER Installer Mettre sous tension Connexion au site matre Mettre sous pression Installer Calibrer Installer Calibrer

: Patient

: Robot

Mettre en position initiale Mettre en tat d'attente de consignes

F IG . 5.15 Diagramme de squence de la conguration du robot

5.3 Dnition du systme et de son utilisation

155

Configuration du robot <<include>> Oprateur Robot

Gestion patient

Patient

F IG . 5.16 Diagramme des cas dutilisation illustrant la relation include peut trouver un message nomm Installer qui sadresse au Patient. Or ce message dclenche un scnario (linstallation du Patient, la pose du gel, etc.) qui appartient au cas dutilisation Gestion patient. Ceci permet de noter une relation de type include entre les cas dutilisation Conguration du robot et Gestion patient (cf. gure 5.16). De la mme manire que pour les autres cas dutilisation, il est possible de dcrire les cas dutilisation de manire textuelle comme prsent dans le tableau ci-dessous. Cas dutilisation Conguration du robot Acteurs Oprateur et Robot Description LOprateur installe et dsinstalle le Robot. Il entre les donnes lies au Patient et au Robot pour raliser la tche. Il assure la maintenance du Robot. Alternative Si lOprateur dcle un problme lors de linstallation, il peut rsoudre le problme et poursuivre la conguration, ou arrter linstallation. QoS Les oprations doivent tre sufsamment rapides pour ne pas faire attendre le Patient dans une position inconfortable. Remarques Ces tapes sont particulirement critiques pour la scurit du Patient

5.3.5 Diagramme global des cas dutilisation, structure dynamique et statique du Systme de contrle TER
Le diagramme global des cas dutilisation est donn gure 5.17. Il reprend chaque relation identie prcdemment. Il est alors possible de dnir un diagramme dtats partiel prsent gure 5.18, reprsentant les tats du Systme de contrle TER. Les changements dtats, principalement induits par les messages envoys par lOprateur et le Site matre sont retranscrits

156

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Systme de contrle TER

<<include>>

<<include>> Contrler mouvements Raliser tche <<extend>> Interprter tche Site matre Contrler l'excution de la tche

Contrler mouvements en Tlopration

Contrler mouvements en trajectoire gnre

Robot
Configuration du robot <<include>> Oprateur Patient Gestion patient

F IG . 5.17 Diagramme gnral des cas dutilisation

Installation, Configuration et Connexion

Configuration

/ mettre robot position initiale

Repos

Arrt tche d'chographie / mettre en position initiale Dbut tche d'chographie

Contrle des Mouvements

Annulation tche Suspension tche Relancer tche

Arrt Annulation tche

Suspendu

F IG . 5.18 Diagramme dtats du Systme de contrle TER

5.4 Identication des dangers et estimation du risque

157

<<external output device>> Site Matre Interagit avec Envoie une commande de presssion

Fournit et rgule la pression

<<external device>>

Convertisseur I/P 14

Muscle artificiel
1
Fournit nergie mcanique

1
<<system>>

Transmet dplacements Fournit position

Contrleur TER 1 1
Interagit avec

1
<<external input device>>

Capteur de position
Fournit force Robot Transmet des mouvements <<external device>>

1
<<external input device>> Oprateur Fournit position 3D

Sonde
Transmet les efforts

Capteur de force

1
Se dplace sur

1
<<external input device>>

Localisateur de Rigid Body

Transmet sa position

1 2

1
Est dplac sur

<<external device>>

Rigid Body
Patient

Manipule

F IG . 5.19 Diagramme de classes du Systme de contrle TER ici en tant quvnements. Ainsi, Arrt tche dchographie et Dbut tche dchographie correspondent aux messages du Site matre prsents sur le diagramme de squence de la gure 5.11. Suspension, Relancer et Annulation tche correspondent aux messages mis par lOprateur, prsents sur le diagramme de squence de la gure 5.13, et correspondant au contrle de lexcution de la tche. Sur la base des exigences fonctionnelles et des contraintes techniques (dont lutilisation des muscles articiels et dun localisateur 3D Polaris), une structure lectronique, dcrite par le diagramme de classes de la gure 5.19, a t conue.

5.4

Identication des dangers et estimation du risque

Bien que cette section constitue en gnral le cur de lanalyse du risque, ltape prcdente de dnition du systme est fondamentale pour notre dmarche. Tout dabord elle a permis de dnir des tches cohrentes pour les diffrents acteurs, ce qui est fondamental pour la scurit, puis a fourni une base pour la suite de lanalyse du risque. Comme cela est prsent dans le chapitre 4, les modles UML sont injects dans les diffrentes analyses, puis

158

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Gravit du dommage 4 1 3 2 Minime Catastrophique Majeure Mineure

Frquence dvnement

5 Ngligeable I I L T T T

Frquente Probable Occasionnelle Rare Improbable Invraisemblable

H H H H I I

H H H I I L

H H I I L T

H I I L T T

F IG . 5.20 Table destimation du risque les modications concernant lutilisation, les exigences et la conception sont intgres aux modles. Pour chaque tape de lanalyse prsente ici, il convient destimer, lorsque cela est possible, le risque induit par un phnomne dangereux, une situation dangereuse ou un vnement dommageable. Pour cela, il convient de choisir des niveaux de gravit et de probabilit doccurrence, selon une table de risque comme cela est prsent au chapitre 1. Dans notre analyse nous utiliserons cette table destimation du risque qui est reproduite gure 5.20. Les couples (frquence, gravit) rsultant en un risque lev (H), sont mis en valeur car ils reprsentent les risques les moins tolrables. Nous neffectuerons pas dvaluation du risque, qui consiste choisir le niveau de risque acceptable, mais an dillustrer la dmarche, nous nous appuierons tout de mme sur le fait quun risque de niveau H, fera sans aucun doute lobjet dune rduction. Cela permet alors de proposer des solutions cohrentes et dillustrer comment les moyens de matrise du risque sont introduits dans notre dmarche. Une premire section prsente lanalyse prliminaire des risques induits par le systme robotique esclave TER. Les sections suivantes sont ddies lanalyse des modes de dfaillance des messages changs entre tous les lments du systme (acteurs et lments lectroniques, mcaniques ou informatiques). Une dernire section prsente une utilisation des arbres de fautes. Par souci de prsentation, les diagrammes UML et les tableaux de lAMDEC dvelopps sur papier lors de cette analyse, ne seront pas tous prsents. Seuls les plus importants, et ceux qui illustrent au mieux notre dmarche seront inclus dans ce chapitre. Des diagrammes et tableaux danalyse supplmentaires sont donnes en annexe B.

5.4.1 Analyse prliminaire des dangers

On effectue sur la base de la description du systme, prsente prcdemment, une analyse prliminaire des dangers. On choisit de classer ces phnomnes dangereux en plusieurs catgories :

5.4 Identication des dangers et estimation du risque

159

physique : le phnomne dangereux est dorigine physique, il rsulte en gnral en un dommage physique ; lectrique (lectrocution, dcharge lectrostatique, etc.) ; psychologique : le phnomne dangereux peut conduire des dommages dordre psychologique ; environnement : le phnomne dangereux concerne lenvironnement dun acteur (auditif, visuel, temprature, etc.). Il peut rsulter en des dommages psychologiques (stress) ou mme physiques (perte de laudition). Une analyse prliminaire peut devenir complexe si lon souhaite trop dtailler chaque lment. Il est important de bien faire la diffrence entre les phnomnes dangereux et les dommages. La gure 5.21 reprsente lanalyse prliminaire des phnomnes dangereux que lon peut identier ds le dbut du projet. Les colonnes Solutions possibles et Remarques fournissent des modications que lon peut intgrer diffrents niveaux du dveloppement : modication de lutilisation (comme par exemple la spcication dune zone travail avant la ralisation de la tche) que lon introduit dans les diagrammes de squence ; modication des exigences et plus particulirement des contraintes de type QoS (rduire le temps dattente du Patient avec le Robot install, contraindre la vitesse de dplacement, etc.) qui sont ajoutes aux ches des cas dutilisation correspondantes ; modication de la conception des dispositifs matriels (implantation dun arrt durgence, isolation des composants relatifs la pression, implanter un visuel de la force exerce sur le Patient) et du logiciel (contraindre la vitesse de dplacement) que lon rpercute sur les modles. La modication des modles concerne tous les diagrammes. Lexemple classique est ici limplantation dun arrt durgence qui provoque la sortie de ltat En fonctionnement regroupant tous les tats du diagramme de la gure 5.18. Ce changement dtat implique alors la mise zro de la pression dans les muscles de manire matrielle, puis les actions correspondant la dsinstallation du Robot et du Patient (cf. gure 5.22). Il convient alors de mettre jour le diagramme de squence du contrle de lexcution de la tche par lOprateur de la gure 5.13, en ajoutant le message Arrter durgence, envoy par lOprateur vers le Systme de contrle TER. On assigne ainsi lOprateur une nouvelle responsabilit qui est la surveillance, et lon introduit un arrt durgence rsultant en la mise zro de la pression des muscles. Larrt durgence, qui est implant lors de lactivit de matrise du risque, doit donc consister en un sous-systme coupant directement lalimentation en pression des muscles. Cette exigence est fondamentale, car les systmes darrt durgence sont en gnral des coupe-circuits lectroniques, ce qui ne convient pas ici.

5.4.2 Analyse des modes de dfaillance des acteurs

Les acteurs principaux du site esclave TER sont le Site matre, lOprateur et le Robot. Les modes de dfaillance du Robot seront abords dans la section concernant les composants

160

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Danger

Acteurs

Cas dutilisation

Solutions possibles Gravit

Remarques

Oprateur Patient Robot Gestion du patient

Dplacement sur une zone sensible ou dangereuse du patient Pression trop importante sur le patient

Configurer tche

Raliser tche

1 - Spcification dune zone de

travail avant la tche. - Contraindre les mouvements dans cette zone. - Prvoir un arrt durgence.

Envisager des solutions logicielles mais aussi matrielles

1 - Contraindre les efforts des

mouvement grce un capteur de force. - Visuel de la force exerce sur le patient. - Prvoir un arrt durgence coupant la pression dans les muscles 2 Contraindre la vitesse de dplacement de manire logicielle.

Estimer la force maximale de larchitecture envisage (comprenant les muscles artificiels)

Physique

Dplacement brusque sur le patient Projections dlments (fouet des cbles, explosion des muscles, etc.)

X X X

1 - Isoler au maximum les

composants matriels transmettant les forces mouvement du patient et de loprateur. - Prvoir un programme de maintenance. 1 Systme maintenant le robot en cas de dfaillance

Chute du robot Frottement des cbles sur le patient Electrocution

X X X

X X

2 Crer un systme intermdiaire

pour isoler le patient des cbles

X X X

1 Aucune partie mtallique ne doit

tre en contact avec le patient

Electrique

Rpondre aux normes en vigueur pour le systme lectrique (fusible, alimentation aux normes, etc.)

Dcharge lectrostatique Attente

X X X X

X X X

X X

2 Les parties mtalliques du robot

doivent tre relies la masse

4 Si le systme est bloqu,

Psychologique

Stress

Il convient de loprateur doit pouvoir annuler la rduire au maximum tche en cours et dgager le le temps dattente du patient patient lors de linstallation du patient 4 Le patient doit pouvoir accder au systme de visioconfrence pour dialoguer avec le spcialiste

Bruit d au flot dair dans les muscles

X X

4 Isoler les composants

transmettant la pression (compresseur, convertisseur I/P, muscle artificiels)

Environnement

Flot dair sur le patient

3 Isoler les composants

transmettant la pression (compresseur, convertisseur I/P, muscle artificiels)

Choc sonore (fuite dair)

3 Isoler les composants

transmettant la pression (compresseur, convertisseur I/P, muscle artificiels)

F IG . 5.21 Table danalyse prliminaire des dangers

5.4 Identication des dangers et estimation du risque

161

En fonctionnement do/ Contrler mouvements

Arrt d'urgence / Couper pression

Arrt entry/ Enlever robot entry/ Dsinstaller patient

F IG . 5.22 Diagramme dtats illustrant limplantation dun arrt durgence mcaniques. Nous dnissons en effet le Robot par la structure mcanique articule compose essentiellement de composants mcaniques. Tous les autres composants comme les capteurs et les actionneurs sont intgrs dans le sous-systme que lon nomme Systme de contrle TER (cf. gure 5.17). 5.4.2.1 Modes de dfaillance du Site matre

On analyse les messages provenant du Site matre, en se basant sur le diagramme de squence prsent prcdemment sur la gure 5.11. Le scnario principal du cas dutilisation Contrler mouvements en tlopration est prsent gure 5.23. Ce diagramme de squence fait apparatre une contrainte de temps exprime prcdemment en utilisant le formalisme de la version 1.4 dUML (OMG, 2001), qui consiste tiqueter les messages (ici a et b), puis exprimer une contrainte en utilisant les mots cls SendTime, ReceiveTime, etc. En plus de cette contrainte, il est possible de rajouter sur ces diagrammes des notes sur le ct pour exprimer de faon textuelle certaines informations (la limite tant xe par la lisibilit du diagramme). partir de ce diagramme, on utilise un tableau de lAMDEC pour analyser les messages, en utilisant les modles derreur fournis au chapitre 4. Il est important de noter que la partie communication avec le Site matre a t gre par France Telecom R&D, qui a tabli un systme de communication bas sur un protocole et des algorithmes de dtection des fautes. La modlisation de ce partage de travail est reprsente sur la gure 5.24. Le tableau danalyse des modes de dfaillance du message Contrler_robot est prsent gure 5.25. An de faire le lien avec les moyens de matrise du risque, on estime le risque la plus forte valeur (H) et lon propose des moyens pour le rduire. Lomission ou le retard du message provoque ltablissement dun signal, Perte connexion, que nous introduisons dans

162

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

: Site matre

: Systme de contrle TER

Le site matre envoie une consigne toutes les 500 ms via le rseau vers le site esclave Les consignes sont du type Position (x,y,z,,,) et force dsire Le site esclave retourne les infos de position relle et force relle

a:Contrler_robot (consignes)
Contrler mouvements Lire position Lire force

Mise__jour_donnes (position,force)

{a.ReceiveTime b.ReceiveTime<500ms}

b:Contrler_robot (consignes)
Contrler mouvements

Etc...

F IG . 5.23 Diagramme de squence principal du cas dutilisation Raliser tche

Systme de contrle TER

Communication (FT R&D)

F IG . 5.24 Utilisation du package Communication par le Systme de contrle TER

5.4 Identication des dangers et estimation du risque

Composant / Fonction/ Message Mode de dfaillance (erreur) Cause de la dfaillance Effets : a. Niveau local b. Niveau suprieur c. Niveau systme
Risque Moyens de dtection Solutions possibles
Gravit Occurrence Risque

163

possibles (en ligne) a. Mode dfaillance b. Effets

a. b. c. d.

Prvention Protection Autres actions Remarques

Contrler_robot (consignes)

Trop tard ou omission

Faute Site Matre ou faute lien

Trop tt

Faute Site Matre

Ordre incorrect du message dans la squence Arguments errons (nombre, type ou valeur)

Faute Site Matre

4 F H a. Utilisation dune a. Les consignes ne tempo, tablir signal sont pas mises jour Perte connexion. b. Contrle des mouvements sur anciennes valeurs c. Dplacements par saccades 3 F H a. Le contrleur na a. Le contrle des pas termin le mouvements nest pas contrle de position termin b. Commande interrompue c. Dplacement brusque a. Comportement 1 P H a. Le contrleur nest inconnu pas en tat dattente de ce message

a. Utilisation protocole (fournit par France Telecom R&D) b. Figer le robot , si le dlai expire mettre en position initiale c. Informer Oprateur

a. Utiliser des tches indpendantes au sein du contrleur b. Le contrleur valide la fin du contrle dun mouvement

b. Ignorer le message c. Informer Oprateur

Faute Site Matre ou faute lien

c. Mouvement non dsir

1 F H a. Filtrage numrique

a. Protocole de communication (cheksum, etc.) b. Ignorer les valeurs, si trop de valeurs fausses la suite mettre au repos c. Informer Oprateur

F IG . 5.25 AMDEC du message Contrler_robot mit par le Site matre le diagramme dtats de la gure 5.26. Par rapport au diagramme dtats prsent prcdemment (cf. gure 5.18), on introduit un nouvel tat temporaire, Pause, qui permet de mettre le systme en attente si le message subit un simple retard, ou sil existe une coupure momentane. Si un dlai ( xer par la suite) est expir alors le systme met le robot dans la position initiale, et attend soit une reconnection, soit une annulation de la tche par lOprateur. Les diagrammes dtats impliquent que les changements dtat sont effectus uniquement lorsque les vnements spcis arrivent. Cela signie que si lon se trouve dans ltat Mise en fonctionnement, et que lvnement Lancer tche dchographie arrive, alors il ny aura pas de changement dtat. Ainsi, le modle ne permettant pas de changement dtats non matris, il convient ensuite de concevoir notamment au moyen de patterns dimplantation des machines tats respectant cette contrainte (Douglass, 1999). Les solutions proposes dans lAMDEC concernant les tches et leur synchronisation, impliquent une connaissance de la conception du logiciel, alors que nous nous situons encore dans la spcication. Au niveau actuel, ceci peut tre vu comme une exigence pour le logiciel, qui est la ncessit dutiliser un noyau temps rel pour la gestion des tches. On ajoute alors cette information au cas dutilisation Raliser tche. Ceci illustre bien le fait quune analyse du risque qui seffectue en parallle du processus de dveloppement, permet de proposer des solutions, et donc de guider certains choix technologiques. Les points abords ci-dessus sont trs courants dans de tels systmes. Les temporisations dans la perte de connexion, et lexigence dun noyau temps rel pour le contrleur, sont des

164

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Installation, Configuration et Connexion

Mise en Fonctionnement

/ mettre robot position initiale

Repos connect

Connexiontablie

Repos non connect do/ Connexion

Perte Connexion

Arrt tche Consignes d'chographie fausses / mettre en position Lancer tche initiale d'chographie

Dlai expir / mettre en position initiale

Contrle des Mouvements Annulation tche

Suspension tche

Connexion OK Perte connexion

Pause do/ Connexion

Relancer tche

Annulation tche

Suspendu

Annulation tche

Arrt
entry/ Dgonfler muscles

F IG . 5.26 Diagramme dtats du Systme de contrle TER prenant en compte les modes de dfaillance du message Contrler_robot

5.4 Identication des dangers et estimation du risque

165

solutions trs classiques. Cependant, un processus de dveloppement cohrent doit pouvoir justier lutilisation de telles techniques comme cela est prsent dans cette dmarche. 5.4.2.2 Modes de dfaillance de lOprateur

Lorsquun acteur est un humain, lanalyse des modes de dfaillance de cet acteur correspond lanalyse des erreurs humaines. Comme prsent dans le chapitre 4, nous basons cette dmarche sur les descriptions des scnarios (pour chaque cas dutilisation), les descriptions des interfaces lorsque cela est possible, et des connaissances sur le comportement et les performances des acteurs considrs. Lanalyse de lAMDEC se base sur le diagramme de squence de la gure 5.15, qui correspond la conguration du robot, et celui de la gure 5.13 qui dcrit le contrle de lexcution de la tche. Cependant, ces diagrammes ne sont pas sufsamment dtaills pour effectuer une analyse. En effet, il convient de dcrire prcisment chacune des tches exprimes par des messages. Ainsi, le message Installer de la gure 5.15, entre lOprateur et le Systme de contrle TER, exprime diffrentes actions comme les branchements des tuyaux dalimentation en air et des cbles dalimentation lectrique. Toutes ces actions peuvent tre dcrites par des diagrammes de squence, dtaills par des documents textuels. Les diagrammes UML permettent alors de guider les diffrentes analyses des erreurs humaines. Dans les diagrammes de squence prsents prcdemment, les interfaces ne sont pas prcises et elles peuvent tre matrielles ou logicielles. Cest la nature mme du message qui guide lanalyse, et ce sont les spcialistes de chaque domaine qui peuvent proposer des solutions. Ainsi, pour laction Mettre la pression, il est possible deffectuer lanalyse prsente sur la gure 5.27, o les erreurs principales sont prsentes partir du modle derreur du chapitre 3. Dans ce tableau, nous ne faisons pas apparatre les causes des erreurs humaines car elles sont multiples, et complexes. Le but nest pas ici deffectuer une analyse sur la production de ces erreurs qui concerne les sciences cognitives, mais dintgrer dans le systme les moyens pour matriser ces erreurs. titre dexemple, une solution possible est alors dutiliser le systme prsent la gure 5.28. Ainsi, lOprateur tablit la pression progressivement, et consulte un manomtre pour surveiller visuellement la pression. Il est possible dinstaller un sous-systme logiciel de surveillance avec un capteur de pression, et de crer au niveau du logiciel des interblocages pour que lordre des messages soit respect. Les autres messages, Installer, Calibrer, et Mettre en position initiale, aprs avoir t dtaills ont fait lobjet dune mme analyse. Puis, les cas dutilisation Contrler lexcution de la tche et Gestion patient en relation avec lOprateur ont t analyss de cette manire. An de nous limiter dans ce mmoire, lensemble des modications des exigences, de lutilisation et de la conception, nest pas prsent ici.

166

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Mettre la pression

Omission

Ordre incorrect : avant mise sous tension

Pression rgle trop forte

a. Pas dnergie dans les 4 P I a. Oprateur lit le manomtre muscles artificiels b. Ncessit de recommencer initialisation c. Attente du patient (stress) Avant la fin de linitialisation 5 P I lectronique les sorties ne sont pas zro c. Comportement inconnu (mouvements brusques des muscles) a. Destruction 2 O H a. Oprateur lit le convertisseurs I/P manomtre

Gravit Occurrence Risque

Composant / Fonction/ Message

Mode de dfaillance (erreur)

Effets : a. Niveau local b. Niveau suprieur c. Niveau systme

Risque Moyens de dtection Solutions possibles :

possibles (en ligne) a. Mode dfaillance b. Effets

a. b. c. d.

Prvention Protection Autres actions Remarques

a. Guide dutilisation, formation, tapes dtailles l cran b. Faire un test de gonflage des muscles lors de linitialisation c. a. Guide dutilisation, formation.

Pression rgle trop faible (infrieure alimentation des convertisseursI/P = 6bar)

a. Pression insuffisante dans les muscles b. Pas assez de pression sur le patient c. Fonctionnement non dangereux mais chaotique (stress patient)

4 F H a. Oprateur lit le manomtre b. Capteur de pression

d. La limite maximum tant fixe par la pression d alimentation, il convient de dterminer la pression max dentre des convertisseurs (voir fabricant) a. Indication sur le manomtre b. Faire un test de gonflage des muscles linitialisation et vrifier la pression par le logiciel.

F IG . 5.27 AMDEC du message Mettre la pression

Rglage de la pression

Lecture de la pression dalimentation

P alim

Convertisseur I/P

P muscle

F IG . 5.28 Systme dalimentation en air

5.4 Identication des dangers et estimation du risque

Fournit et rgule la pression 1 Convertisseur 1 I/P

167

Transmet nergie mcanique Muscle artificiel 3 1 Anneau de rotation 1 1 Transmet nergie de translation

Convertisseur 1 I/P

Muscle artificiel

1 Multiplicateur 4 (X10)

Anneau de translation

Fournit et rgule la pression

Transmet nergie mcanique

Transmet nergie mcanique modifie

F IG . 5.29 Principaux composants mcaniques pour lactionnement des anneaux de dplacement

5.4.3 Analyse des modes de dfaillance des composants matriels

Dans le cadre de la robotique, lanalyse des modes de dfaillance des composants matriels correspond ltude mcanique de lacteur Robot. Le spcialiste du domaine, choisit les technologies et les constructions en fonction des exigences exprimes par les cas dutilisation. Pour une analyse du risque systme, il est vident que la dmarche nest pas de remettre en cause les choix fondamentaux de la mcanique, mais de rednir certaines exigences, et didentier les effets des dfaillances sur le systme. Ces dfaillances sont spcies par le spcialiste du domaine mcanique mais les effets sont calculs grce une connaissance du systme global. Ainsi, connatre exactement la composition de la mcanique ne permettrait pas une analyse synthtique. La modlisation, que lon peut effectuer en diagramme de classes, est prsente sur la gure 5.29. Une description plus dtaille de la mcanique est donne par Vilchis et al. (2001a), et une photo de la conception a t donne en gure 5.10. Sur la base dun tel diagramme il est possible deffectuer une AMDEC classique comme celle de la gure 5.30, et den dduire des moyens possibles de rduction du risque. On peut noter que si certains lments ne sont pas sufsamment dnis, il sont mis en vidence au sein de lAMDEC. Ainsi, la question de la stabilit du robot en cas de crevaison dun muscle est une question importante pour la scurit quil convient dtudier. Cest une situation dangereuse qui peut apparatre dans certaines congurations du robot.

5.4.4 Analyse des modes de dfaillance des composants lectroniques

Lanalyse des modes de dfaillance des messages mis par les composants lectroniques peut se faire comme pour les autres domaines. Cependant, par simplication, et du fait de la teneur de ces messages qui ne consistent quen un change de donnes, nous considrerons chaque composant et ses modes de dfaillance. Ainsi, lunique fonction dun capteur de position tant de fournir la position lue, nous analyserons les modes dfaillance de la fonction de lecture de position, et plus particulirement les erreurs de la valeur retourne.

168
Composant / Fonction/ Message

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Mode de dfaillance (erreur) Cause de la Effets : dfaillance a. Niveau local b. Niveau suprieur c. Niveau systme
Risque Moyens de dtection

Gravit Occurrence Risque

possibles (en ligne) a. Mode dfaillance b. Effet c. Cause

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Maintenance prventive b. Systme de maintient du robot, puis suspendre et annuler la tche c. Dterminer sil existe des positions pour lesquelles le robot peut basculer en cas de crevaison dun muscle a. loigner au maximum les muscles du patient b. Protection autour des muscles.

Muscle artificiel nergie Crevaison transmise trop faible (crevaison)

a. Longueur augmente b. Effort sur patient diminue c. Bruit, souffle dair, dsagrments c. Dterminer si le robot peut basculer

5 F I a. Capteur de pression

1 ? ?

Energie transmise non prvue (explosion)

Rupture de la tresse ou du sertissage

a. Projections b. Blessures physiques

2 R I

F IG . 5.30 AMDEC dun muscle articiel

Xd

Transformation coordonnes

ld +

lm

Correcteur PIDa

Robot

F IG . 5.31 Commande en boucle ferme avec un rgulateur de type PIDa Une vue densemble des composants a t prsente sur le diagramme de classes de la gure 5.19. Sur cette modlisation, les ots de donnes sont reprsents mais la corrlation entre ces donnes nest pas modlise. Plutt que de dtailler le logiciel du contrleur, on peut utiliser ici des modles automatiques pour exprimer lutilisation des valeurs changes. Ainsi, on peut modliser la boucle de rtroaction avec le diagramme de bloc classique de la gure 5.31. Sur ce diagramme sont nots les diffrents paramtres de la boucle : Xd est la position 3D du robot dsire par le Site matre, ld est la longueur des cbles, calcule pour obtenir la position Xd du robot sur le patient, lm est la longueur relle des cbles, est lerreur entre ld et lm , et U est la commande envoye aux actionneurs du robot. Cette commande est un rgulateur en position de type PID, avec un terme danticipation (Carroll, 1999). La force nest pas prise en compte dans cette version du contrleur, elle est transmise titre dinformation au Site matre. Cependant, la mesure de force peut tre utilise pour des mcanismes de protection, mais nous nabordons pas cet aspect ici. Nous considrons le systme dans sa version premire et purement fonctionnelle (sans aucun mcanisme de protection). Dans cette dmarche, les tableaux de lAMDEC des composants Capteur de position, Convertisseur Intensit/Pression et Contrleur TER sont prsents sur les gures 5.32 5.33 et 5.34. Les analyses des composants Capteur de position et Convertisseur Intensit/Pression, conduisent modier la squence dinitialisation du robot en introduisant une procdure de

5.4 Identication des dangers et estimation du risque

Composant / Fonction/ Message Mode de Cause de la Effets : dfaillance dfaillance a. Niveau local b. Niveau suprieur (erreur) c. Niveau systme
Risque Moyens de dtection

169
Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Test des capteurs linitialisation b. Si force>3daN dgonfler les muscles c. Oprateur peut annuler la tche (au pire enclencher larrt durgence) a. Test des capteurs linitialisation b. Ignorer la valeur, si trop derreur suspendre la tche a. Oprateur peut annuler la tche (au pire enclencher larrt durgence)

Capteur de position
Lire la position

Valeur nulle Dfaillance interne ou capteur, ou constante connectique

1 P H a. a. Calcul erreur faux b. Capteur de force b. Commande fausse c. Mouvement non dsir

Pic ou valeur alatoire

Dfaillance interne du capteur ou bruit sur la connectique

1 P H a. Filtrage numrique (de a. Calcul erreur faux type Kalman) b. Commande fausse b. Capteur de force c. Mouvement non dsir

F IG . 5.32 AMDEC dun capteur de position test dcrite sur le diagramme de squence de la gure 5.35. Lobjet principal, le Contrleur TER, est ici considr comme un simple composant dont le message analys est lenvoi de la commande aux Convertisseurs intensit/pression. Sans dtailler les modes de dfaillance des diffrents lments qui le composent (cf. gure 5.36), il est possible de mener une analyse comparable aux autres composants lectroniques comme cela est prsent sur la gure 5.34. Cependant, lanalyse du Contrleur TER concerne aussi le logiciel de lapplication qui est un lment critique puisque une dfaillance de ce composant peut entraner des dommages importants (graves). Cet aspect est abord dans la section suivante.

5.4.5 Analyse des modes de dfaillance du logiciel

On dcrit le logiciel de la mme manire que les autres composants du systme grce des diagrammes de classes, dinteractions et dtats. Lapproche systme que nous avons prsente jusquici est entirement utilisable pour la modlisation du logiciel. En effet, les objets du monde informatique reprsentent une vue abstraite du monde rel, et lon modlise des objets tels que les capteurs, les actionneurs, ainsi que des objets dits de contrle comme un Contrleur daxe. Lapproche objet permet aussi dutiliser pour la modlisation du logiciel les diagrammes dtats labors lors de lanalyse systme. En effet, le diagramme dtats prsent prcdemment sur la gure 5.26, reprsente les changements dtats que le contrleur de mouvements doit intgrer. Ces remarques qui sont propres lutilisation dUML montrent lapport de ce langage dans la prvention des fautes ; la cohrence et la traabilit des modles sont assures par lensemble de ces diagrammes utilisables depuis lexpression des besoins jusqu la conception du logiciel. Le diagramme de classes de la gure 5.37 montre une dcomposition du logiciel en classes dobjets. Ce diagramme dcoule de la modlisation des scnarios de chaque cas dutilisation, et nous reprsentons ici les premires classes dobjet que lon peut identier. Cest un dia-

Gravit Occurrence Risque

possibles (en ligne) a. Mode dfaillance b. Effets

170

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Convertisseur Pression Intensit/Pression nulle

Fournit et rgule la pression

Dfaillance interne

Pression alatoire (pic) ou drive

Dfaillance interne

3 P H a. Capteur de pression a. Muscles dgonfls b. Le robot peut basculer sil se trouve dans certaines configurations ( dterminer) c. Stress patient a. Mouvement non 1 P H a. Capteur de pression dsir b. Capteur de force

Gravit Occurrence Risque

Composant / Fonction/ Message

Mode de Cause de la Effets : dfaillance dfaillance a. Niveau local (erreur) b. Niveau suprieur c. Niveau systme

Risque Moyens de dtection

possibles (en ligne) a. Mode dfaillance b. Effets

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Maintenance prventive et squence de test linitialisation b.

Fuite dair

a. Chute de la pression Dfaillance b. Mouvements non interne dsir, mais non pneumatique dangereux c. Flot dair et bruit

3 P H a. Oprateur

Rgulation instable
(oscillations)

Dfaillance interne

a. Instabilit commande 3 P H a. Oprateur b. Oscillation de la longueur des muscles c. Tremblements du robot sur le patient, et bruit

a. Maintenance prventive et squence de test linitialisation b. Dgonfler muscles c. Arrt durgence par loprateur a. Maintenance prventive et squence de test linitialisation b. Protection autour du circuit dair c. Annulation de la tche, changement du convertisseur a. Maintenance prventive et squence de test linitialisation

F IG . 5.33 AMDEC dun convertisseur Intensit/Pression

Gravit Occurrence Risque

Composant / Fonction/ Message

Mode de Cause de la Effets : dfaillance dfaillance a. Niveau local (erreur) b. Niveau suprieur c. Niveau systme

Risque Moyens de dtection

possibles (en ligne) a. Mode dfaillance b. Effets

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Techniques de prvention pour le dveloppement logiciel b. Dgonfler les muscles et rinitialiser le systme par le Watchdog a. Techniques de prvention de fautes pour le dveloppement logiciel b. Solution dpendante de la technique de redondance choisie c. Arrt durgence par loprateur a. Inclure le gonflage des muscles dans la squence de test lors de linitialisation b. Modifier la conception pour maintenir le robot en cas de dgonflement des muscles

Contrleur

Envoyer commande (fig)

Commande Interblocage a. Robot fig du logiciel ou b. Stress patiente constante dfaillance du matriel

4 P H a. Contrle de lactivit lcran par loprateur ou systme de type Watchdog

Commande Dfaillance interne du alatoire logiciel, ou (pic) de matriel

a. Mouvements non dsirs

1 O H a. Systme redondant avec voteur (voir le patron double canal)

4 O I a. Capteur de pression a. Muscles dgonfls Sortie nulle Problme alimentation, b. Le robot peut basculer sil se trouve ou dans certaines dfaillance configurations ( matrielle ou dterminer) logicielle

F IG . 5.34 AMDEC du Contrleur TER

5.4 Identication des dangers et estimation du risque

171

: Oprateur

Systme de contrle TER Installer

L'oprateur branche les tuyaux d'alimentation en air, les cbles lectriques, etc...

Mettre sous Tension Lancer test cartes

Test cartes entres / sorties

Fin test cartes

Mettre sous Pression Lancer test

Gonfler Muscles

Vrifier capteurs de position et pression

Dgonfler muscles
Fin Vrification

F IG . 5.35 Diagramme de squence des tests lors de linitialisation (cas dutilisation Congurer Robot)

Contrleur TER
PC

Logiciel du contrleur

Systme d'exploitation QNX

Carte entres

Carte sorties

F IG . 5.36 Contenu du package Contrleur TER

172

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Interface Oprateur
annulerTache() suspendreTache() lancerTache()

construit et valide

Interprteur de tches
interpreterTache()

Contrleur TELEOP
envoie des ordres

Contrleur GENE
controlerMouvements()

Interface Site Matre

recevoirConsignes() envoyerDonnees() lancerEcho() arreterEcho()

controlerMouvements()

MGI
creerModelePatient() creerModeleRobot() calculerLongueurCables()

Mouvement Cartesien Contrleur de mouvements controlerMouvements() mettrePositionInit() 1 1 genererTrajectoire()

fournit position 3D de la sonde

fournit position 3D du palpeur

Localisateur
lirePosition3D()

Modle du robot Modle du patient

gre

7 Contrleur d'axe
asservirAxe() calculerCommande()

Fournit force

fournit la l'effort de la sonde sur le patient

Fournit position

Fournit position

envoie commande vers

1 0..1 Actionneur
pression envoyerCommande()

0..1

Capteur de Force
force lireForce()

Codeur
position lirePosition()

Dtecteur position position lirePosition()

Capteur
offset setOffset()

F IG . 5.37 Diagramme de classes du logiciel gramme danalyse, et lon ne fait pas apparatre les tches, les choix de synchronisation de ces tches, etc. Cependant lanalyse prsente dans cette section doit pouvoir tre effectue un niveau de dveloppement plus avanc comme lors de la conception. Le diagramme de squence de la gure 5.38 reprsente le scnario principal du cas dutilisation Raliser tche. On exprime notamment deux contraintes temporelles qui correspondent aux priodes dchantillonnage de la rception des consignes du site matre et de lasservissement en position du robot. Ce diagramme montre une partie des messages changs, et sousentend notamment lensemble des messages entre la classe Contrleur daxe, et les classes Capteur et Actionneur que lon peut reprsenter sur un diagramme part (cf. gure 5.39). La dmarche dune analyse du logiciel propose ici, nest pas de trouver les causes de dfaillances telles que les dpassements de mmoire, les pointeurs fous, etc. Il sagit de dter-

5.4 Identication des dangers et estimation du risque

173

: Interface Site Matre

: Interprteur de tches

: Contrleur TELEOP

: MGI

: Contrleur d'axe

: Capteur de Force

: Localisateur

a:recevoirConsignes( )

interpreterTache( ) controlerMouvements( )
calculerLongueurCables( )

A:asservirAxe( ) {B.sendTime A.sendTime < 10ms} B:asservirAxe( ) C:asservirAxe( ) Etc...

Priode de 10ms

lireForce( ) lirePosition3D( )
envoyerDonnees( )

{b.sendTime a.sendTime < 500ms}

b:recevoirConsignes( )

Etc... Priode de 500ms

F IG . 5.38 Diagramme de squence du logiciel du scnario principal de Raliser tche

: Contrleur d'axe asservirAxe( ) lirePosition( )

calculerCommande( )

: Capteur

: Actionneur

envoyerCommande( )

F IG . 5.39 Diagramme de squence du logiciel de lasservissement en position

174

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Composant / Fonction/ Message Mode de Effets : dfaillance a. Niveau local b. Niveau suprieur (erreur) c. Niveau systme Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques d. Ces fluctuations sont sans effet dommageable si lInterface site matre possde son propre flot dexcution (une tche est rattache cet objet) b. Crer une tche de haut niveau permettant dannuler la tche dchographie

RecevoirConsignes() Trop tt ou trop tard Retourne les (dans une consignes limite < 500ms)

Omission (blocage)

Valeurs retournes fausses

a. Consignes pas mises 5 jour b. Interprtation de la tche identique litration prcdente c. Asservissement dans la mme position a. Consignes pas mises 4 jour b. Asservissement dans la mme position c. Robot fig (Stress patient) 1 a. Consignes fausses a. Mouvement non dsir b. Effort trop important sur le patient

Gravit

b. Autosurveillance de la cohrence des valeurs retournes

F IG . 5.40 AMDEC du message recevoirConsigne() miner les messages critiques qui devront faire lobjet danalyses plus approfondies lors de la conception (tests, validations, etc.), ou qui doivent lobjet dauto-surveillance logicielle. En suivant les consignes prsentes dans la section 4.3.4.5, on peut effectuer titre dexemple lanalyse des messages du diagramme de squence de la gure 5.38. Ce diagramme montre les messages changs pour raliser le cas dutilisation Raliser tche. Ne sont modliss sur ce diagramme que les messages lis aux besoins fonctionnels de ce cas dutilisation, et pas ceux lis une surveillance (comme ceux qui concernent la mesure de la force). Il est vident que ce diagramme est une base, quil convient ensuite de complter, et notamment avec des messages issus des propositions faites lors de lanalyse du risque. Les tableaux des gures 5.40 et 5.41 montrent une analyse des modes de dfaillance de deux messages comportant une contrainte temporelle. La gravit identie, de niveau 1, montre que ces messages sont critiques en terme de scurit. Les moyens proposs sont alors de modier la conception en introduisant un sous-systme de surveillance des valeurs changes, et de complter les exigences du logiciel en terme dordonnancement des tches informatiques. Ainsi, lobjet Interface site matre doit possder son propre l dexcution, et donc tre ce que lon nomme objet actif (OMG, 2001). Cela montre que lanalyse du risque du logiciel permet daider aux choix de conception effectus par la suite. ce niveau du dveloppement il est encore possible dtre exhaustif en terme danalyse, cependant lors de la conception, lexplosion du nombre de messages rend cette analyse complexe. Il faut alors se limiter aux messages risque , que lon a prsents dans la section 4.3.4.5.

5.4 Identication des dangers et estimation du risque

Composant / Fonction/ Message Mode de Effets : dfaillance a. Niveau local b. Niveau suprieur (erreur) c. Niveau systme Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques d. Le temps dexcution des oprations, EnvoyerCommande, lirePosition et calculerCommande doit tre infrieur 10ms (priode dchantillonnage) b. Crer une tche de haut niveau permettant dannuler la tche dchographie b. Surveillance des donnes par lobjet Actionneur (vrification limites, cart type, etc.)

175

EnvoyerCommande()
Envoie une commande en pression

Ralisation a. Le message asservirAxe 1 de arrive alors que lopration envoyerCommande nest trop longue pas termin b. Commande non dsire c. Mouvement non dsir Omission (blocage) Valeurs envoyes fausses a. b. c. a. b. Commande fige Robot fig Stress patient Commande non dsire Mouvement non dsir 4

F IG . 5.41 AMDEC du message envoyerCommande()

Svrit

5.4.6 Analyse des arbres de fautes

Nous avons utilis les arbres de fautes comme une technique permettant de synthtiser les analyses fournies par lAMDEC. Comme pour lAMDEC, il serait important danalyser les interactions entre les vnements que lon trouve dans un arbre de fautes et les modles UML. Ceci doit faire lobjet de prochaines tudes et nous prsentons ici, quune vue partielle de lutilisation de cette technique. Lvnement racine le plus important est une pression de la sonde sur le patient trop importante. Larbre de fautes identi est prsent sur la gure 5.42. Pour analyser lvnement racine, on se base sur le diagramme gnral de classes dobjets de la gure 5.19. On se place au niveau de linteraction entre le systme et le patient (exprime par un lien entre la Sonde et lacteur Patient) et on remonte la chane cintique, puis lectronique, et enn informatique en identiant chaque fois les dfaillances possibles. On introduit simultanment les erreurs humaines responsables de certains vnements. Dans notre cas, en partant de la sonde, on identie de manire squentielle les vnements suivants : chute de la sonde, dfaillance du robot, dfaillance des convertisseurs intensit / pression, envoie dune mauvaise commande, et une mauvaise installation du systme (incluant le Patient) de la part de lOprateur. Puis on rafne les vnements qui peuvent rsulter dautres vnements comme lenvoie dun mauvaise commande, en sappuyant sur les diagrammes modlisant le logiciel. Les vnements qui peuvent tre rafns sont dcrits dans dautres arbres comme larbre de la gure 5.43 qui illustre deux erreurs possibles que peut faire lOprateur, et qui peuvent crer lvnement redout. Lutilisation des arbres de fautes au niveau de lanalyse ne fait en gnral apparatre que des portes OU. En effet, on value lensemble des vnements (en gnral les dfaillances) pouvant causer, indpendamment des autres, lvnement racine. Il existe cependant des cas

176

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

Pression exerce par la sonde sur le patient trop importante

OU

Chute de la sonde

Dfaillance mcanique du robot

Dfaillance convertisseur I/P

Erreur de commnande

Erreur dinstallation du systme

OU

OU

Multiplicateur bloqu

Cbles bloqus

Erreur du calcul de la commande

Dfaillance capteur de position

Dfaillance OS

Erreur consigne

Dfaillance processeur

Modles faux

OU

Erreur de lecture

Erreur site matre

Erreur transmission

F IG . 5.42 Arbre de fautes de llment racine Pression trop importante sur le patient

Erreur dinstallation du systme

OU

Mauvaise installation du robot

Mauvaise installation du patient

F IG . 5.43 Arbre de fautes concernant linstallation du systme

5.4 Identication des dangers et estimation du risque

Pression exerce par la sonde sur le patient trop importante

177

ET
Pression exerce par la sonde sur le patient dpasse seuil de tolrance

Arrt durgence non effectif

OU

OU

Dfaillance mcanique du robot

Erreur de commnande

Dfaillance arrt durgence

Dfaillance du systme de mesure de la force

A
Chute de la sonde Dfaillance convertisseur I/P

B
Erreur dinstallation du systme

D
Inatention de loprateur

F IG . 5.44 Arbre de fautes illustrant lintroduction du sous-systme darrt durgence o lon aura besoin dutiliser la porte ET, pour exprimer la combinaison de deux vnements. Dans notre cas, larbre que lon peut identier ne fait pas apparatre de porte ET. Cest lors de la rduction du risque, et de lintgration des moyens pour les rduire que lon fait apparatre les portes ET. titre dexemple, puisque le propos nest pas de traiter de la rduction du risque, on peut exprimer le fait que lon introduit un arrt durgence que lOprateur doit enclencher aprs avoir consult la force exerce sur le Patient. On obtient alors larbre de fautes de la gure 5.44. Larrt durgence peut aussi tre utilis pour dautres situations, comme des explosions, qui sont dcrites par dautres arbres de fautes. Pour lvnement racine considr ici, le fait dintroduire un sous-systme darrt durgence mne complter larbre de fautes avec une porte ET, et plusieurs vnements. Le fait dintroduire une porte ET diminue la probabilit doccurrence de lvnement Pression exerce par la sonde sur le patient trop importante, puisque cela ncessite loccurrence simultane des deux vnements Pression exerce par la sonde sur le patient dpasse seuil de tolrance et Arrt durgence non effectif. On peut noter que cette reprsentation fait rfrence plusieurs notions quil faut dnir pour le systme comme le seuil de tolrance de la force exerce sur le Patient. En avanant dans le processus de dveloppement, les arbres de fautes sont enrichis par les sous-systmes introduits. On peut alors prouver que certains vnements ont une probabilit doccurrence trs faible par des preuves formelles (calculs mathmatiques), des vidences comme la chute de la sonde mcaniquement impossible, de manire non formelle par des tests, ou en utilisant des donnes de constructeurs (comme pour les convertisseurs intensit/pression par exemple). Pour chaque vnement, il est ensuite possible dintroduire des mcanismes de

178

Application de lanalyse du risque au dveloppement en UML dun robot tl-chographe

protection pour rduire la gravit du dommage, comme larrt durgence prsent ci-dessus, mais aussi des moyens de prvention. Comme prsent au chapitre 1, la prvention concerne la rduction de la probabilit doccurrence dun dommage. Dans lanalyse des arbres de fautes, il est possible dappliquer ce principe aux vnements induisant le dommage. Ainsi, on peut se poser la question : comment faire pour rduire la probabilit doccurrence de lvnement Inattention de loprateur ? Parmi les solutions existent des moyens comme un afchage voyant de la force exerce et de la limite tolrable, des systmes qui attirent lattention comme des signaux lumineux ou sonores, etc. Les modications sont alors introduites dans les modles UML, et rinjectes dans lanalyse du risque, jusqu lobtention dun risque acceptable.

5.5

Conclusion

Ce chapitre a prsent une application de la dmarche prsente au chapitre 3. Lanalyse du risque ralise a permis de reprendre lensemble des lments du dveloppement du robot esclave TER. Bien que ce chapitre ne prsente pas lanalyse dans son ensemble, les principaux rsultats ont ts prsents. Ainsi, travers une description du systme et de son utilisation au moyen des diagrammes de cas dutilisation, nous avons montr comment dnir de manire non ambigu lensemble des tches alloues aux acteurs. Ceci a permis notamment de dnir les capacits des acteurs humains requises pour les diffrentes tches et de mettre en valeur la problmatique lie loprateur et sa charge de travail. La modlisation a permis par la suite deffectuer une analyse du risque des diffrents messages changs lors de la ralisation des cas dutilisation. Bien que dans certains cas lestimation du risque soit complexe, voire impossible, il est cependant possible dutiliser les modles derreurs prsents au chapitre 4, pour identier les messages critiques. Lapproche a t applique aux diffrents domaines que sont llectronique, la mcanique, linformatique, et les facteurs humains. Ces diffrentes activits ont men lidentication de dangers ncessitant un traitement. Certains dangers identis ont permis de dnir des analyses supplmentaires effectuer, comme par exemple ltude de la stabilit du robot lors de la dfaillance dun muscle, ou de rednir des exigences de scurit comme la ncessit dintroduire une coupure de lalimentation en air. Dautres ont men la modication de lutilisation comme llaboration dune squence de test impliquant la participation de loprateur. Enn, certains dangers prsentant un risque non ngligeable ont men la modication des modles de conception comme la prsence dun watchdog permettant la rinitialisation du contrleur. Au regard de lavancement du projet, ces diffrents points nont pu tre tous implants au sein du robot TER. Il ont donc permis dans un premier temps de valider le fait que le robot dans sa version premire (premier prototype) prsente un haut niveau de risque, et quil sera ncessaire pour la suite dintroduire les diffrents moyens de rduction du risque.

5.5 Conclusion

179

La principale difcult pour raliser cette analyse a t due la multitude dacteurs au sein du consortium TER, et limpossibilit dobtenir certains documents de travail inaccessibles ou inexistants. Le fait que ce projet soit innovant a conduit les concepteurs vers un premier objectif, qui ntait pas la scurit mais la validation de la structure particulire du robot actionn par les muscles articiels. Cependant, travers les diffrentes runions du consortium TER et du travail ralis au laboratoire TIMC/GMCAO de Grenoble, lanalyse a permis dune part de valider notre approche mais aussi de proposer des solutions possibles pour une prochaine version du robot esclave TER. Bien que lanalyse prsente ici ne reprsente quune itration, les diagrammes et les diffrents tableaux danalyse ont t raliss en plusieurs itrations. De plus, UML tant un langage pouvant tre utilis tout au long du processus de dveloppement, nous pouvons penser que cette dmarche danalyse du risque est utilisable de manire itrative et incrmentale. Cependant, nous nous sommes restreints des diagrammes de spcication, et donc ne comportant que peu dobjets et de messages par rapport des diagrammes de conception. Pour une utilisation dans des systmes plus importants, ou lors de la conception dtaille, lexplosion du nombre de messages rend le travail sur papier long et fastidieux, et peut induire des mises jour lentes et chaotiques, et ainsi gnrer des erreurs. Or en se basant sur les diagrammes de squence et les modles derreur que nous avons proposs, des outils informatiques pourraient aider les concepteurs grer cette complexit et effectuer une telle analyse du risque. Malheureusement, le fait quUML soit un langage semi-formel, et limpossibilit actuelle (version 1.4) dexcuter les modles, rend complexe tout dveloppement doutils informatiques permettant deffectuer des analyses systmatiques.

Synthse, contributions majeures et perspectives

Synthse La complexit grandissante des systmes de la robotique de service, et le transfert de responsabilits de lhomme vers la machine, posent aujourdhui le problme de la conance que lon peut leur accorder. Cette conance est notamment lie au concept de scurit, qui exprime aujourdhui une scurit relative. Nous lavons en effet dnie comme labsence de risque inacceptable. Face aux difcults pour les concepteurs apprhender le concept de scurit, lobjectif de cette thse tait de proposer une dmarche de matrise de la scurit au sein dun processus de dveloppement. Dans les systmes dvelopps aujourdhui, la scurit est souvent apprhende par lapplication de techniques de la sret de fonctionnement. Nous avons propos une nouvelle approche plus globale base sur la notion de risque. La matrise de la scurit dpend alors de lactivit de gestion du risque, dont le cur est lanalyse du risque. Cette activit centrale consiste prvoir les dangers, et estimer les risques de dommage induits par lutilisation du systme. Elle doit tre ralise partir dune description du systme et de son utilisation, et nous avons pour cela propos dutiliser la notation UML. Lutilisation de ce langage a permis de traiter des activits du domaine des facteurs humains que nous avons incluses dans lanalyse du risque. Parmi ces activits, lallocation et lanalyse des tches permettent de dnir de manire non ambigu les tches des acteurs, et de dcrire prcisment lutilisation du systme. Les diagrammes des cas dutilisation et de squence permettent alors de formaliser les rsultats de ces analyses, et sont directement utilisables pour les tapes suivantes de la conception du systme. Les diagrammes UML permettent par la suite de raliser une analyse des modes de dfaillance des lments du systme. Nous avons montr que les lments fondamentaux taient les messages changs entre tous les objets du systme, dont les acteurs. Un premier travail a consist dnir des modles derreur de ces messages, puis les appliquer pour effectuer une AMDEC systme. Ces analyses ont pu tre ralises sur lensemble des messages changs entre les objets lectroniques, mcaniques, informatiques et les utilisateurs modliss en tant quobjets de type acteur.

182 Contributions majeures et perspectives

Synthse, contributions majeures et perspectives

Cette dmarche est ralise sur la base des modles UML du systme, et elle permet de coupler le processus de dveloppement lanalyse du risque. Les informations, qui sont dveloppes dans lune ou lautre de ces activits, sont donc cohrentes car elles se basent sur les mmes modles. Lun des points essentiels des cette approche est de rendre accessible lanalyse du risque aux concepteurs utilisant UML. Bien que la dmarche propose ait t applique aux premires phases du dveloppement, il devrait tre possible de lexcuter de manire itrative et incrmentale, de faon enrichir lanalyse du risque en fonction de lvolution des modles UML. Cet aspect reste valider, et notamment la manire dont les techniques de lAMDEC et celle des arbres de fautes supportent un tel cycle mrite une attention particulire. Par rapport aux objectifs xs, nous avons pu utiliser la terminologie lie au risque sans rencontrer dambigut, ou de terme non dni. Certains concepts nont cependant pas t utiliss, comme accident ou incident. Ils font en effet rfrence des vnements concrets, dont loccurrence a t observe, or le travail prsent ici se place dans un cadre de prvision ; on ne manipule alors que des vnements potentiels. Malgr tout, cette terminologie reste complexe, et pouvoir faire la diffrence entre les concepts2 demande une certaine culture du risque . Or, dans un processus de dveloppement faisant intervenir des acteurs de diffrents domaines, chacun possde en gnral son propre langage, et encore plus pour aborder les notions lies au risque qui sont nouvelles. La mise en place dun langage commun peut alors savrer trop coteux3 . Grce aux diagrammes UML et aux modles derreur gnriques que nous avons dvelopps, il a t possible danalyser lensemble du systme, et notamment les erreurs humaines. Cest en ce sens que lon peut parler dun approche systme. Cela a pu tre fait en conservant les modles UML dans leur forme nominale et sans modier la notation. Lun des aspects importants du travail ralis concerne lutilisation de techniques connues des concepteurs. Le fait de sappuyer sur la version standard de ce langage, devrait permettre aux concepteurs de comprendre et dappliquer plus facilement et plus rapidement notre dmarche, et cela pour lensemble du systme. Un point important qui reste dvelopper plus en dtail est lanalyse du risque du logiciel. Le nombre et la complexit des messages changs entre les objets informatiques rend en effet difcile lapplication des modles derreur dvelopps dans le chapitre 3. En se basant sur des critres de slection nous avons pu nous concentrer sur les messages dits critiques et analyser leurs modes de dfaillance ainsi que les effets induits. Cependant, un travail important doit encore tre men sur ce thme ; un axe de recherche peut consister raliser des outils informatiques permettant de simuler les modes de dfaillance des messages sur la base de
Faire la diffrence entre estimation et valuation, ou entre matrise et gestion nest pas naturel... On peut alors analyser le risque li une telle dmarche au sein dun projet, le dommage induit tant une perte de temps et dargent...
3 2

Synthse, contributions majeures et perspectives

183

modles derreur comme le font les simulateurs de fautes. Le principal frein de tels travaux est limpossibilit dexcuter les modles UML (dans la version 1.4), ce qui rend impossible la simulation des effets de ces erreurs. Le dernier point relatif aux objectifs xs au dpart concerne la traabilit en vue de la certication. Bien que cette proprit ne soit pas tudie explicitement tout au long de ce mmoire, elle dcoule cependant des techniques que nous avons utilises. En effet, lutilisation du langage UML permet de dcrire, tout au long du processus de dveloppement, lvolution des choix de conceptions. De plus, les tableaux de lanalyse prliminaire des dangers et de lAMDEC, et les arbres de fautes, produisent une documentation ncessaire la traabilit, que lon peut enrichir de manire itrative. Il reste cependant de nombreux travaux faire et des outils raliser car les exigences ou les choix de conception tracer relvent parfois de proprits dont la formulation reste un thme dtude4 . Matriser la scurit dune application de robotique de service est une problmatique complexe, et malgr limportance des travaux quil reste mener, cette thse propose une approche pour apprhender ce concept. En travaillant sur des techniques largement utilises dans ce domaine, nous esprons que la dmarche propose sera facilement applicable dautres projets. Le travail de cette thse est transversal de nombreux domaines, et une des difcults a consist ne pas se perdre dans un domaine au dtriment des autres. Ceci a t particulirement difcile pour le domaine des sciences cognitives, qui ma fortement intress. Se maintenir la frontire de ces domaines est dautant plus complexe quil existe peu de moyens de diffusion de tels travaux, et cela se traduit par lmergence de nouveaux groupes de travail. Ainsi, une partie de ce mmoire contribue la mise en place du groupe UML et Certication initi par le LESIA5 , qui est aujourdhui lorigine de plusieurs thses en cours et venir.

4 5

Comme par exemple les contraintes temps rel http ://www.lesia.insa-tlse.fr/UML-certication

Annexe A La notation UML

Cette annexe prsente les principaux diagrammes dUML. Les notations prsentes ici se limitent ce qui est utilis dans ce mmoire.

A.1

Concepts transversaux

Les concepts de package, de dpendance, de note et de strotype peuvent tre utiliss dans tous les types de diagramme. Le terme de paquetage est parfois utilis au lieu de package.

<<Nom du stereotype>>

Nom du package 1
Note textuelle 1

dpendance

Nom du package 2

Note textuelle 2 {Contraite textuelle}

Nom du package 3

F IG . A.1 Package, dpendance, note et strotype

186

La notation UML

A.2

Diagramme des cas dutilisation

Nom de l'association

Nom de l'acteur Nom du cas d'utilisation

F IG . A.2 Acteur, cas dutilisation et association

se note aussi :
Nom de l'acteur

<<Acteur>>

Nom de lacteur

F IG . A.3 Strotype Acteur

A.3

Diagramme de classes

Nom de la classe attribut Nom de la classe opration()

F IG . A.4 Classe

Nom de la classe 1

Nom de l'association

Nom de la classe 2

F IG . A.5 Association

A.3 Diagramme de classes

187

Nom de la classe 1 0..1

Agrgation navigabilit unidirectionnelle

Cardinalit (nombre d'objets instanciables pour la relation considre)

0..1
Composition navigabilit bidirectionnelle

0..* Nom de la classe A

0..* Nom de la classe B

F IG . A.6 Agrgation, composition et cardinalit

Super classe
Gnralisation

Classe abstraite opration()

Spcialisation

Sous classe 1

Sous classe 2 opration()

F IG . A.7 Gnralisation et spcialisation

188

La notation UML

A.4

Diagramme dtats-transitions

Nom de l'tat entry/ action d'entre do/ activit exit/ action de sortie

Etat initial

Etat final

Syntaxe dune transition : vnement(arguments)[condition]/action^envoi

F IG . A.8 tats et transitions

Super etat Etat 1

Etat 2

F IG . A.9 Embotement dtats

A.5 Diagrammes dinteraction

189

A.5

Diagrammes dinteraction

objet 1 : Nom de la classe 1

: Nom de l'acteur

objet 2

: Nom de la classe 2

action Script textuel message

opration

a.opration (paramtres) {b.sendTimea.sendTime<30ms} b.opration(paramtres)

Contrainte temporelle

F IG . A.10 Diagramme de squence

3: opration

1: action
: Nom de l'acteur 2: message

objet 1 : Nom de la classe 1

objet 2

4: opration (paramtres) 5: opration(paramtres)

: Nom de la classe 2

F IG . A.11 Diagramme de collaboration

190

La notation UML

A.6

Diagramme de composants

Composant 1

Composant 2

F IG . A.12 Composant

A.7

Diagramme de dploiement

Noeud 1 Nom du lien

Noeud 2

F IG . A.13 Nud et lien

Annexe B Complments lanalyse des modes de dfaillance du robot TER

B.1 Diagramme des cas dutilisation simpli
Systme de contrle TER

<<extend>>

Raliser tche

Site matre Contrler l'excution de la tche

Robot

Configuration du robot <<include>> Oprateur Patient

Gestion patient

F IG . B.1 Cas dutilisation du systme de contrle du site esclave de TER

192

Complments lanalyse des modes de dfaillance du robot TER

B.2

Diagramme de squence principal du cas dutilisation Raliser tche

: Site matre Lancer chographie Contrler robot (consignes)

Systme de contrle TER

: Robot

: Patient

Contrler mouvements

Dplacer la sonde sur le patient

Ausculte

Lire position Lire force Mise jour donnes (position,force)

Arrter chographie

Ce message devient par la suite un cas dutilisation luimme dcompos en deux cas dutilisation pour les diffrents modes de fonctionnement (voir chapitre 4)

F IG . B.2 Ralisation de la tche dchographie

B.2 Diagramme de squence principal du cas dutilisation Raliser tche

193

Gravit Occurrence Risque

Date :17/01/2003 Par : J. Guiochet Interaction/ Mode de Message dfaillance (erreur)

Projet TER
Cause de la dfaillance Effets a Niveau local b. Niveau suprieur c. Niveau systme
Risque Moyens de dtection

possibles (en ligne) a. Mode de dfaillance b. Effets

Solutions possibles : a. Prvention b. Protection c. Autres actions d. Remarques a. Consignes au patient b. Mise au repos du robot (muscles dgonfls) si erreur trop importante

Ralisation de la tche d'chographie

Mouvement du patient (erreur E.1) ou saisie du robot esclave (erreur E.1)

Mauvaise installation Stress du patient

a. Perturbation importante du mouvement du robot b. Mouvement non dsir

a. Surveillance de l'Oprateur b. Erreur importante

F IG . B.3 AMDEC des messages mis par le patient lors de linteraction Ralisation de la tche dchographie

Contrler_robot (consignes)

Trop tard ou omission (E.3 et E.5)

Faute Site Matre ou faute lien

Trop tt (E.5) Faute Site Matre

Ordre Faute Site incorrect du Matre message dans la squence (E.2) Arguments Faute Site errons Matre ou (nombre, faute lien type ou valeur) (E.6,E.7,E.8)

a. Les consignes ne 4 F H a. Utilisation dune sont pas mises jour tempo, tablir signal b. Contrle des Perte connexion. mouvements sur anciennes valeurs c. Dplacements par saccades a. Le contrle des 3 F H a. Le contrleur na mouvements nest pas pas termin le termin contrle de position b. Commande interrompue c. Dplacement brusque a. Comportement 1 P H a. Le contrleur nest inconnu pas en tat dattente de ce message

Gravit Occurrence Risque

Interaction/ Message

Mode de dfaillance (erreur)

Cause de la dfaillance

Effets : a. Niveau local b. Niveau suprieur c. Niveau systme

Risque Moyens de dtection Solutions possibles

possibles (en ligne) a. Mode dfaillance b. Effets

a. b. c. d.

Prvention Protection Autres actions Remarques

a. Utilisation protocole (fournit par France Telecom R&D) b. Figer le robot , si le dlai expire mettre en position initiale c. Informer Oprateur

a. Utiliser des tches indpendantes au sein du contrleur b. Le contrleur valide la fin du contrle dun mouvement

b. Ignorer le message c. Informer Oprateur

c. Mouvement non dsir

1 F H a. Filtrage numrique

a. Protocole de communication (cheksum, etc.) b. Ignorer les valeurs, si trop de valeurs fausses la suite mettre au repos c. Informer Oprateur

F IG . B.4 AMDEC du message Contrler_robot mis par le site matre

194

Complments lanalyse des modes de dfaillance du robot TER

B.3

Diagramme de squence principal du cas dutilisation Contrler lexcution de la tche

: Oprateur

: Systme de contrle TER

Figer le systme

: Site matre

Suspendre la tche

: Robot

: Patient

Informer

Relancer la tche
Contrler mouvements

Informer

Annuler la tche
Retirer nergie du robot

Informer
Peut se faire en urgence ou aprs avoir suspendu la tche

Dsinstaller

Dsinstaller

F IG . B.5 Contrle de lexcution de la tche

B.4 Diagrammes de squence du cas dutilisation Conguration du robot

195

B.4

Diagrammes de squence du cas dutilisation Conguration du robot

: Oprateur La connexion est effectue au dbut pour rduire au maximum le temps d'attente de la patiente. S'il y a des problmes ou des retards dans la connexion avec le site matre, l'oprateur ne doit pas installer la patiente Configuration du contrleur

: Systme de contrle TER

: Patient

: Robot

connexion au site matre

installer calibrer identifier position du patient

Ce message synthtise l'interaction rprsente dans le diagramme de squence "Configuration du contrleur"

installer

Calibrer

identifier position du robot

mettre en position initiale dplacer en position initiale

mettre en tat d'attente de commandes

F IG . B.6 Conguration de la tche

196

Complments lanalyse des modes de dfaillance du robot TER

Mettre en position initiale

Ordre incorrect a. Contrleur non calibr (E.2) : avant b. Mouvement non de calibrer dsir du robot

Gravit Occurrence Risque

Date :17/01/2003 Par : J. Guiochet Interaction/ Mode de Message dfaillance (erreur)

Projet TER
Effets : a. Niveau local b. Niveau suprieur c. Niveau systme
Risque Moyens de dtection

possibles (en ligne) a Mode de dfaillance b Effets

Solutions possibles a. Prvention b Protection c Autres actions d Remarques

a. Affichage des tapes pour l'oprateur (validation pas-pas) b. Blocage si pas de calibrage b. Robot en dehors d'une zone d'initialisation a. Dfinir une zone globale o le robot doit se trouver avant de lancer la tche c. L'interface doit contraindre l'oprateur respecter l'interaction

Omission (E.3) ou la position initiale est incorrecte (E.8)

a. Au dmarrage le robot est dans une position quelconque b. Mouvement non dsir du robot

F IG . B.7 AMDEC du message Mettre en position initiale

: Oprateur L'oprateur branche les tuyaux d'alimentation en air, les cbles lectriques, etc... Installer

Systeme de contrle TER

Mettre sous Tension Lancer test cartes Test cartes entres / sorties Fin test cartes Mettre sous Pression Lancer test Gonfler Muscles Vrifier capteurs de position et pression Dgonfler muscles Fin Vrification

F IG . B.8 Conguration du contrleur

Mettre la pression

Omission (E.3)

Ordre incorrect : avant mise sous tension (E.2)

Pression rgle trop forte (E.8)

a. Pas dnergie dans les 4 P I a. Oprateur lit le manomtre muscles artificiels b. Ncessit de recommencer initialisation c. Attente du patient (stress) Avant la fin de linitialisation 5 P I lectronique les sorties ne sont pas zro c. Comportement inconnu (mouvements brusques des muscles) a. Destruction 2 O H a. Oprateur lit le convertisseurs I/P manomtre

Gravit Occurrence Risque

Interaction/ Message

Mode de dfaillance (erreur)

Effets : a. Niveau local b. Niveau suprieur c. Niveau systme

Risque Moyens de dtection Solutions possibles :

possibles (en ligne) a. Mode dfaillance b. Effets

a. b. c. d.

Prvention Protection Autres actions Remarques

a. Guide dutilisation, formation, tapes dtailles l cran b. Faire un test de gonflage des muscles lors de linitialisation c. a. Guide dutilisation, formation.

Pression rgle trop faible (infrieure alimentation des convertisseursI/P = 6bar)(E.8)

a. Pression insuffisante dans les muscles b. Pas assez de pression sur le patient c. Fonctionnement non dangereux mais chaotique (stress patient)

4 F H a. Oprateur lit le manomtre b. Capteur de pression

d. La limite maximum tant fixe par la pression d alimentation, il convient de dterminer la pression max dentre des convertisseurs (voir fabricant) a. Indication sur le manomtre b. Faire un test de gonflage des muscles linitialisation et vrifier la pression par le logiciel.

F IG . B.9 AMEDC du message Mettre la pression

Index
Accident, 2729, 182 Acteur, 85, 116, 117, 140, 145147, 159 AMDEC, 41, 42, 55, 91, 94, 106, 107, 109, 114 Analyse des arbres de fautes, 41, 94, 130, 134, 175 Analyse du risque, 31, 34, 37, 41, 52, 53, 55, 56, 91, 95, 99, 157, 163, 167 Analyse prliminaire des dangers, 107, 108, 158, 160 Analyse prliminaire du risque, 107 Cas dutilisation, 85, 88, 90, 186 Certication, 34, 52, 54, 183 Classe, 83, 87, 186 Compliance, 47, 49, 63, 76 Danger, 25, 28, 29, 31 Diagramme dtats, 119, 155, 156, 161, 163, 164, 188 Diagramme dinteraction, 189 Diagramme de classes, 86, 186 Diagramme de collaboration, 189 Diagramme de composants, 190 Diagramme de dploiement, 121, 122, 139, 140, 190 Diagramme de squence, 105, 112, 117, 118, 189 Disponibilit, 17 Dommage, 2225, 2830, 36, 37, 73, 74, 76, 115, 159 limination des fautes, 91, 92, 95, 115 Estimation du risque, 26, 36, 41, 43, 55, 106, 107, 114, 118, 121, 158 vnement dommageable, 29, 30 valuation du risque, 27, 37, 3941, 43, 53, 55, 158 Facteur humain, 32 Fiabilit, 17, 27, 32, 48, 84, 92, 94, 95, 104 Gestion du risque, 28, 3133, 55, 90, 121 Gravit, 2325, 91 Incident, 29, 73, 182 Incrmental, 88 Itratif, 88 Mtamodle, 86 Matrise du risque, 40, 43, 44, 55, 77 Objet, 82, 83 OCL, 86, 111, 113 OMG, 84 Package, 110, 128, 146, 185 Phnomne dangereux, 2831, 35, 41, 107 Prvention, 23, 27, 40, 73, 77, 78, 114, 115, 120, 128, 178 Prvention des fautes, 84, 9193, 105 Prvision des fautes, 91, 93, 94 Processus Uni, 87 Protection, 21, 40, 43, 45, 47, 73, 77, 78, 114, 115, 120, 168, 178 QoS, 92, 102, 104, 108, 129, 141144, 151, 153, 155, 159 Rduction du risque, 40, 115, 177 Risque, 25, 26, 30, 31, 3638

200 Risque acceptable, 26, 27, 37, 38, 40, 53, 158 Risque tolrable, 38 Scurit, 17, 18, 2123, 27, 3234, 45, 47, 48, 50, 53, 92 Scurit-condentialit, 17 Scurit-innocuit, 17 Svrit, 24 Sret de fonctionnement, 17, 18, 24, 33, 9092, 96, 97, 114 Safety, 17 Safety cases, 54 Security, 17 SIL, 93, 128, 129 Situation dangereuse, 28, 30, 31, 76, 167 Tolrance aux fautes, 40, 91, 95, 128, 132 Traabilit, 56, 83, 97, 99, 101, 135, 169 UML, 84

INDEX

Bibliographie
90/385/CEE (1990). Directive du conseil du 20 juin 1990 relative aux dispositifs mdicaux implantables actifs. Journal ofciel des Communauts europennes (JOCE) N L189. 93/42/CEE (1993). Directive du conseil du 14 juin 1993 concernant les dispositifs mdicaux. Journal ofciel des Communauts europennes (JOCE) N L169. 98/79/CE (1998). Directive du parlement europen et du conseil du 27 octobre relative aux dispositifs mdicaux de diagnostic in vitro. Journal ofciel des Communauts europennes (JOCE) N L220. AVSI (2002). A guide to the certication of systems with embedded object-oriented software. Project AVSI AFE #7 certication issues for embedded object-oriented software Version 1.4, Aerospace Vehicule Systems Institute. Baerveldt, A. (1992a). Cooperation between man and robot : interface and safety. IEEE International workshop on Robot and Human Communication, p. 183187. Baerveldt, A. (1992b). A safety system for close interaction between man and robot. Safety of Computer Control Systems SAFECOMP92, p. 2529. Bargar, W., Bauer, A., et Borner, M. (1998). replacement using the ROBODOC system. Primary and revision total hip Joint Surgeons of Sacramento. http ://www.jointsurgeons.com/clinical.htm.

Beevis, D., Bost, R., Dring, B., Nord, E., Oberman, F., Papin, J.-P., Schuffel, H., et Streets, D. (1994). Analysis techniques for man-machine systems design. Rapport technique AC/243(Panel 8)TR/7, NATO, Canada. Binkley, nique D. (1995). NISTIR 5769, C++ in National safety critical systems. Institute of Standards Rapport techand Technology.

http ://hissa.ncsl.nist.gov/sw_develop/safety.html.

Bitsch, F. (2002). Requirements on methods and techniques in perspective to approval process for railway systems. Dans Second International Workshop on Integration of Specication Techniques for Applications in Engineering (INT 2002), Grenoble, France.

202

BIBLIOGRAPHIE

Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), p. 6172. Boitier, V. (1999). Mise en uvre et contrle dun robot SCARA deux degrs de libert, actionn par des muscles articiels pneumatiques de McKibben. Thse de doctorat, Institut National des Sciences Appliques de Toulouse, France. Bondavalli, A., Cin, M. D., Latella, D., Majzik, I., Pataricza, A., et Savoia, G. (2001). Dependability analysis in the early phases of UML based system design. International Journal of Computer Systems - Science & Engineering, 16(5), p. 265275. Bondavalli, A., Majzik, I., et Mura, I. (1999a). Automated dependability analysis of UML designs. Dans 2nd IEEE International Symposium on Object-Oriented Real-time Distributed Computing (ISORC99), Saint Malo, France, p. 139144. IEEE Computer Society Press. Bondavalli, A., Majzik, I., et Mura, I. (1999b). Automatic dependability analysis for supporting design decisions in UML. Dans 4th IEEE High Assurance System Engineering Symposium (HASE99) Washington D.C., USA, p. 6471. IEEE Computer Society Press. Booch, G. (1994). Object-oriented analysis and design with applications. Menlo Park, CA : Addison-Wesley, 2me dition. Booch, G., Rumbaugh, J., et Jacobson, I. (1999). Unied Modeling Language Users Guide. Addison Wesley Longman. Brigeston Corporation (1987). Soft Arm ACFAS Robot System. Tokyo, Japan. Brigeston Corporation and Taicubo Engeneering (1993). Soft Body : Advanced Painting System Unit. Tokyo, Japan. Cain, P., Kazanzides, P., Zuhars, J., Mittelstadt, B., et Paul, H. (1993). Safety considerations in a surgical robot. Biomedical Sciences Instrumentation, Proc. of the 30th Annual Rocky Mountain Bioengineering Symp., p. 291194. Caroll, L., Tondu, B., Baron, C., et Geffroy, J. (1998). Comparison of two signicant development methods applied to the design of real-time robot controllers. Dans IEEE International Conference on Systems, Man and Cybernetics (SMC98), La Jolla, USA, p. 33943399. Carroll, L. (1999). Vers la matrise du dveloppement dun contrleur temps rel sr de fonctionnement pour les robots manipulateurs. Thse de doctorat, Institut National des Sciences Appliques de Toulouse, France. Carroll, L., Mahout, V., Tondu, B., et Lopez, P. (1997). Sliding mode control of a 2 d.o.f. SCARA robot arm actuated by McKibben articial muscles. Dans Confrence IFAC de Commande des Systmes Industriels (CIS97), Belfort, France, p. 299304.

BIBLIOGRAPHIE

203

Chevalley, P. et Thvenod-Fosse, P. (2001). Automated generation of statistical test cases from UML state diagrams. Dans 25th Annual International Computer Software and Applications Conference (COMPSAC01), Chicago, USA, p. 201210. Cichocki, T. et Grski, J. (2000). Failure mode and effect analysis for safety-critical systems with software components. Dans SAFECOMP 2000, edit par F. Koornneef et M. van der Meulen, p. 382394. Springer-Verlag Berlin Heidelberg. Cinquin, P. (1993). Gestes mdicaux-chirurgicaux assists par ordinateur. Annales de Radiologie, 36(6/7), p. 386406. Cosgriff, P. (1994). Quality assurance of medical software. Journal of medical engineering and technology, 8(1), p. 110. Coste-Manire, E., Adhami, L., Bondyfalat, D., et Dowek, G. (2002). Formal methods for safe integration in medical robotics. Dans Proc. of the 2nd IARP IEEE/RAS joint workshop on Technical Challenge for Dependable Robots in Human Environments, Toulouse, France, p. 217227. http ://www.laas.fr/drhe02/preprints.pdf. Daouk, M. et Leveson, N. (2001). An approach to human-centered design. Workshop on Human Error and System Development, Linkoping, Sude. http ://sunnyday.mit.edu/safety. Dario, P., Guglielmelli, E., Allotta, B., et Carrozza, M. (1996). Robotics for medical applications. IEEE Robotics and Automation Magazine, 3(3), p. 4456. Daugherty, G., Haverkamp, D., Richard, R., Bradford, R., et Statezni, D. (2002). Response to realtime safety critical RFI. Rapport technique orbos/2000-01-18, Rockwell Collins Advanced Technology Center. Davies, B. (1993). Safety of medical robots. ICAR93, p. 311313. Davies, B., Harris, S., Lin, W., Hibberd, R., Middleton, R., et Cobb, J. (1997). Active compliance in robotic surgery - the use of control as a dynamic constraint. Proceedings of the Institution of Mechanical Engineers, 211(4), p. 285292. Degoulange, E., Urbain, L., Caron, P., Boudet, S., Gariepy, J., Pierrot, F., et Dombre, E. (1998). Hippocrate : an intrinsically safe robot for medical applications. 1998 IEEE/RSJ International Conference on Intelligent robots and Systems, 2, p. 959964. Delnondedieu, Y. (1997). Un robot scurit passive en rponse aux problmes dergonomie et de scurit en Robotique mdicale. Thse de doctorat, Institut National Polytechnique de Grenoble, France. Dhillon, B. (1991). Robot Reliability and Safety. Springer-Verlag.

204

BIBLIOGRAPHIE

Dhillon, B. et Anude, O. (1993). Robot safety and reliability : a review. Microelectronics and Reliability, 33(3), p. 413429. Dhillon, B. et Fashandi, A. (1997). Safety and reliability assessment techniques in robotics. Robotica, 15, p. 701708. DO178B/ED-12 Revision B (1992). Software considerations in airbone systems and equipment certication. Requirement and Technical Concepts for Aviation (RTCA) Inc. Dombre, E., Poignet, P., Pierrot, F., Duchemin, G., et Urbain, L. (2001). Intrinsically safe active robotic systems for medical applications. Dans Proc. of the 1st IARP/IEEE-RAS Joint Workshop on Technical Challenge for Dependable Robots in Human Environments, Seoul, Korea. Douglass, B. (1998). Rapport technique, i-Logix, Inc. http ://www.nohau.se/articles/pdf/safcritdes.pdf. Safety-critical systems design.

Douglass, B. (1999). Doing hard time : developping real-time systems with UML, objects, framewoks and patterns. Object Technology Series. Addison-Wesley. EN 1441 (1997). Medical devices - risk analysis. CEN, European Committee for standardization. E.P.W. (1984). Rubber muscles take robotics one step further. Rubber Development, 37(4), p. 117119. Eriksson, H. et Penker, M. (2000). Business modeling with UML : business patterns at work. John Wiley and Sons, Inc. Eskiizmirliler, S., Forestier, N., Tondu, B., et Darlot, C. (2002). A model for the cerebellar pathways applied to the control of a single-joint robot arm actuated by mc kibben articial muscles. Biological Cybernetics, 86, p. 379394. Felciano, R. (1995). Human error : designing for error in medical information systems. Invited talk in the journal club Human Error as a Tool in Design Health Care Information Systems . http ://www.smi.stanford.edu/people/felciano/research/humanerror/. Ferreira, L. L. et Rubira, C. M. F. (1998). Reective design patterns to implement fault tolerance. Dans OOPSLA98 Workshop #13, Vancouver, CA. http ://www.csg.is.titech.ac.jp/ chiba/oopsla98/proc/. Food and Drug Administration (2000). Medical device use-safety : incorporating human factors engineering into risk management. Rapport technique, U.S. Departement of Health and Human Service. http ://www.fda.gov/cdrh/humfac/1497.pdf.

BIBLIOGRAPHIE

205

Gabbar, H., Suzuki, K., et Shimada, Y. (2001). Design of plant safety model in plant enterprise engineering environment. Reliability Engineering and System Safety, 73, p. 3547. Gamma, E., Helm, R., Johnson, R., et Vlissides, J. (1995). Design patterns : elements of reusable object-oriented software. Addison Wesley Longman, MA. Geffroy, J. et Motet, G. (1998). Sret de fonctionnement des systmes informatiques. Paris : InterEditions. Geffroy, J. et Motet, G. (2002). Design of Dependable Computing Systems. Kluwer Academic Publishers. Glauser, D., Flury, P., Burckhardt, C., et Kassler, M. (1993). Mechanical concept of the neurosurgical robot Minerva. Robotica, 11(6), p. 567575. Gomaa, H. (2000). Designing concurrent, distributed, and real-time applications with UML. Object Technology Series. Addison-Wesley. Greenhill, S. (1993). The digit muscle. Indust. Robot, 20(5), p. 2930. Grski, J. et Nowicki, B. (1997). Object oriented safety monitor synthesis. Dans Third International conference on reliability, quality and safety of software intensive systems (ENCRESS97), Athens, Greece, edit par D. Gritzalis, p. 121133. Chapman and Hall. Grski, J., Nowicki, B., et Wardzinski, A. (1996). Holistic and partial system models in safety analysis. Dans International conference on probabilistic safety assessment (PSA96), Park City, USA, tome 2, p. 13011309. Guerraz, A. (2002). Etude du tlgeste mdical non invasif utilisant un transducteur gestuel retour deffort. Thse de doctorat, Universit Joseph Fourier de Grenoble. Guiochet, J. (2001). La scurit des robots. Rapport technique 060401, INSA/LESIA, Toulouse, France. Guiochet, J., Motet, G., Tondu, B., et Baron, C. (2003a). La scurit des systmes de la robotique mdicale. Le travail humain. Soumis en seconde lecture aprs corrections. Guiochet, J., Tondu, B., et Baron, C. (2001). Safety analysis and integration for robotic systems - application to medical robot for tele-echography. Dans Proc. of the IASTED International Conference on Robotics and Applications (RA01), Tampa, USA, edit par M. Hamza, p. 158162. ACTA press. Guiochet, J., Tondu, B., et Baron, C. (2003b). Integration of UML in human factors analysis for safety of a medical robot for tele-echography. Dans Proc. of the IEEE/RSJ International Conference on Intelligent Robots and Systems, Intelligent Robots and Systems for Human Security, Health, and Prosperty IROS 2003. Accepted.

206

BIBLIOGRAPHIE

Guiochet, J. et Vilchis, A. (2002). Safety analysis of a medical robot for telend echography. Dans Proc. of the 2 IARP IEEE/RAS joint workshop on Technical Challenge for Dependable Robots in Human Environments, Toulouse, France, p. 217227. http ://www.laas.fr/drhe02/preprints.pdf. Hannaford, B. et Winters, J. (1990). Multiple muscle systems : biomechanics and movement organization, chapitre 7, Actuator properties and movement control : biological and technological models, p. 101120. Springer-Verlag. Harel, D. (1987). Statecharts : a visual formalism for complex systems. Science of Computer Programming, 8, p. 231274. Hitz, M. et Kappel, G. (1998). Developing with UML - Some pitfalls and workarounds. Dans The Unied Modeling Language, UML98 - Beyond the Notation. First International Workshop, Selected Papers, edit par J. Bzivin et P.-A. Muller, tome 1618, p. 920. Mulhouse, France : Springer. HSE (1999). Reducing risk, protecting people. Rapport technique Discussion Document, Health and Safety Executive, UK. http ://www.hse.gov.uk. HSE (2001a). Marine risk assessment. Rapport technique 2001/063, Health and Safety Executive, UK. http ://www.hse.gov.uk. HSE (2001b). Proposed framework for addressing human factors in IEC 61508. Rapport technique 373/2001, Health and Safety Executive, UK. http ://www.hse.gov.uk. IEC 60300-3-9 (1995). Dependability management - Part 3 : Application guide - Section 9 : Risk analysis of technological systems. International Electrotechnical Commission. IEC 61508 (2001). Functional safety of electrical/electronic/programmable electronic safetyrelated systems. International Electrotechnical Commission. Ikuta, K. et Ishii, H. (2003). Safety evaluation method of design and control for human-care robot. The International Journal of Robotics Research, 22(5), p. 281297. Immega, G. (1986). ROMAC muscle powered robots. Dans Proc. RI-SME Conf. Robotics Research, Scottdale, AZ, p. 1821. Inoue, K. (1988). Rubbertuators and applications for robots. Dans Proceedings of the fourth Int. Symp. on Robotics Research, Cambridge, p. 5763. INRS (1998). Sites robotiss - Guide technique de scurit. Rapport technique ND 1728-13589, Institut National de Recherche et de Scurit, Paris. ISO 14971 (2000). Dispositifs mdicaux - Application de la gestion des risques aux dispositifs mdicaux. International Organization for Standardization.

BIBLIOGRAPHIE

207

ISO 9000-3 (1997). Partie 3 : Lignes directrices pour lapplication de lISO 9001 :1994 au dveloppement, la mise disposition, linstallation et la maintenance du logiciel. International Organization for Standardization. ISO/CEI Guide 51 (1999). Aspects lis la scurit - Principes directeurs pour les inclure dans les normes. International Organization for Standardization. Jacobson, I. (1992). Object-oriented software engineering : a use case driven approach. Addison-Wesley. Jacobson, I., Booch, G., et Rumbaugh, J. (1999). The Unied Software Development Process. Addison Wesley Longman. Jannin, P., Raimbault, M., Morandi, X., et Gibaud, B. (2001). Modeling surgical procedures for multimodal image-guided neurosurgery. Dans MICCAI2001, Utrecht, The Netherlands, tome 2208 de Lecture Notes in Computer Science, p. 139152. Springer Verlag. Johannessen, P., Grante, C., Alminger, A., Eklund, U., et Torin, J. (2001). Hazard analysis in object oriented design of dependable systems. Dans 2001 International Conference on Dependable Systems and Networks, Gteborg, Sweden, p. 507512. Johnson, W. (1980). MORT safety assurance systems. New York : Deker, Marcel Incorporated. Karlsson, J. (1999). Les ventes de robots sont en plein essor en Europe et en Amrique du nord mais seffondrent au Japon et en Asie. Communiqu de presse ece/stat/99/2, ONU-CEE. http ://www.unece.org/press/99stat2f.htm. Khodabandehloo, K. (1996). Analyses of robot systems using fault and event trees : case studies. Reliability Engineering and System Safety, 53, p. 247264. Klafter, R., Chmielewski, T., et Negin, M. (1989). Robotic engineering : an integreted approach. New Jersey - USA : Prentice Hall. Klute, G. et Hannaford, B. (1998). Fatigue characteristics of mckibben articial muscle actuators. Dans Proc. IROS98, Victoria B.C., Canada, p. 17761786. Kruchten, P. (1999). The Rational Unied Process - an introduction. Object Technology Series. Addison-Wesley. Kumamoto, H., Soto, Y., et Inoue, K. (1986). Hazard identication and safety assessment of human-robot systems. Engineering Risk and Hazard Assessment, 1, p. 6180. Laible, U., Brger, T., et Pritschow, G. (2001). A fail-safe dual channel robot control for surgery applications. Proceedings of SAFECOMP01, Springer-Verlag Berlin Heidelberg, p. 7585.

208

BIBLIOGRAPHIE

Laprie, J.-C. (1992). Dependability : Basic concepts and terminology in English, French, German, Italian and Japanese, tome 5 de Dependable Computing and Fault Tolerance. Austria : Springer-Verlag. Laprie, J.-C., Arlat, J., Blanquart, J.-P., Costes, A., Crouzet, Y., Deswarte, Y., Fabre, J.-C., Guillermain, H., Kaniche, M., Kanoun, K., Mazet, C., Powell, D., Rabjac, C., et Thvenod, P. (1995). Guide de la sret de fonctionnement. Toulouse, France : Cpadus ditions. Leplat, J. (1985). Erreur humaine, abilit humaine dans le travail. Paris : Armand Colin. Leveson, N. (1995). Safeware - System safety and computers. University of Washington : Addison-Wesley. Majzik, I. et Bondavalli, A. (2000). Automatic dependability modeling of systems described in UML. Dans 9th International Symposium on Software Reliability Engineering (ISSRE98), Paderborn, Germany, edit par R. Chillarege, tome 2, p. 47. Th. Illgen, IEEE Computer Society. Manhes, S. (1998). Les patterns mtier : extraction dans lexistant logiciel. Rapport de DEA, Universit de Nantes, Facult des Sciences et des Techniques. Mersiol, M., Mazet, C., Guillerman, H., et Waeselynck, H. (1998). Human dependability in complex system : an issue of task consistency and task allocation. International Conference on Probabilistic Safety Assessment and Management (PSAM4), 4, p. 26932698. MIL-STD-1629A (1980). Procedures for performing a Failure Mode, Effects and Criticality Analysis. Military Standard. Morita, T., Iwata, H., et Sugano, S. (1999). Development of human symbiotic robot : WENDY. Proceedings 1999 IEEE International Conference on Robotics and Automation, 4, p. 3183 3184. Morita, T. et Sugano, S. (1997a). Development of an anthropomorphic force controlled manipulator WAM 10. 8th International Conference on Advanced Robotics, p. 701706. Morita, T. et Sugano, S. (1997b). Double safety measure for human symbiotic manipulator. IEEE/ASME International Conference on Avanced Intelligent Mechatronics97, p. 130. Muller, P. (2000). Modlisation objet avec UML. Eyrolles, 2me dition. NF EN 46003 (1999). Systmes qualit - Dispositifs mdicaux - Exigences particulires relatives lapplication de lEN ISO 9003. International Organization for Standardization. Ng, W. et Tan, C. (1996). On safety enhancements for medical robots. Reliable Engineering and System Safety, 54(1), p. 3445.

BIBLIOGRAPHIE

209

Noritsu, T., Tanaka, T., et Yamanaka, T. (1996). Application of rubber articial muscle manipulator as a rehabilitation robot. Dans 5th IEEE Int. Workshop on Robot and Human Communication (ROMAN96), Tsukuba, Japan, p. 112117. Nowicki, B. et Grski, J. (1998). Object oriented safety analysis of an extra high voltage substation bay. Dans SAFECOMP98, edit par W. Ehrengerber, p. 306315. SpringerVerlag. OMG (2001). OMG Unied Modeling Language Specication v1.4. Rapport technique, Object Management Group. http ://www.omg.org. OMG (2002a). RFP : UML Prole for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms. Rapport technique ad/2002-01-07, Object Management Group. http ://www.omg.org. OMG (2002b). UML prole for schedulability, performance, and time specication. Rapport technique ptc/02-03-02, Object Management Group. http ://www.omg.org/. OMG (2003a). 2nd revised submission to OMG RFP ad/00-09-02 - Unied Modeling Language : Superstructure - version 2.0. Rapport technique ad/2003-01-02, Object Management Group. http ://www.u2-partners.org. OMG (2003b). 3rd revised submission to OMG RFP ad/00-09-01 - Unied Modeling Language : Infrastructure - version 2.0. Rapport technique ad/2003-01-01, Object Management Group. http ://www.u2-partners.org. OMG (2003c). OMG Unied Modeling Language Specication v1.5. Rapport technique formal/03-03-01, Object Management Group. http ://www.omg.org. Pack, R., Christopher, J., et Kawamura, K. (1997). A rubbertuator based structure climbing inspection robot. Dans Proc. IEEE Int. conf. on Robotics ans Automation, Albuberque, NM, p. 18691874. Pai, G. et Dugan, J. (2002). Automatic synthesis of dynamic fault trees from UML system models. Dans Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE02). Pap, Z., Majzik, I., Pataricza, A., et Szegi, A. (2001). Completeness and consistency analysis of uml statechart specications. Dans Proc. IEEE Design and Diagnostics of Electronic Circuits and Systems Workshop (DDECS2001), Gyor, Hungary, p. 8390. Papadopoulos, Y. et Maruhn, M. (2001). Model-based automated synthesis of fault trees from matlab-simulink models. Dans Int. Conf. on Distributed Systems and Networks (DSN2001), Gothenburg, Sweden, p. 7782.

210

BIBLIOGRAPHIE

Papadopoulos, Y. et McDermid, J. (1998). The potential for a generic approach to certication of safety critical systems in the transportation sector. Reliability Engineering and Systems Safety, 63, p. 4766. Pocock, S., Fields, B., Harrison, M., et Wright, P. (2001). THEA - A Reference guide. Rapport technique 336, University of York Computer Science. http ://www.cs.york.ac.uk/ftpdir/reports/. Pr ISO 14971 (1999). Projet de norme : Dispositifs mdicaux - Application de la gestion des risques aux dispositifs mdicaux. International Organization for Standardization. Pransky, J. (1997). Robodoc - surgical robot success story. Industrial Robot, 24(3), p. 231 233. Prasad, H. (1988). Safety standards. International Encyclopedia of Robotics : Applications and Automation, p. 14281438. R.C. Dorf and S.Y. Nof(eds), John Wiley. Reason, J. (1990). Human Error. Cambridge University Press. Reichenspurner, H., Boehm, D., Gulbins, H., Schulze, C., Wildhirt, S., Detter, C., et Reichart, B. (2000). Three-dimensional video and robot-assisted port-access mitral valve operation. The Society of Thoracic Surgeons, 69, p. 117682. Rierson, L. (1999). Object-Oriented Technology (OOT) In Civil Aviation Projects : Certication Concerns. Rapport technique, Federal Aviation Administration, Washington, D.C. http ://av-info.faa.gov/software/Other_Documents.htm. Rodrigues, J. (1993). What every molder should know about robot safety and maintenance. Plastics technology, 39(11), p. 6972. Roques, P. et Valle, F. (2002). UML en action. Eyrolles, 2me dition. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., et Lorenson, W. (1991). Object oriented modeling and design. Englewood Cliffs, NJ : Prentice Hall. Sackier, J. et Wang, Y. (1994). Robotically assisted laparoscopic surgery. Surgical Endoscopy, 8(1), p. 6366. Sanchez, A. (2000). Approche non linaire de la commande en contraction dun muscle articiel pneumatique de McKibben. Thse de doctorat, Institut National des Sciences Appliques de Toulouse. Schulte, H. (1961). The characteristics of the McKibben articial muscle. Dans Appendix H, The Application of External Power in Prosthetics and Orthotics, 87, p. 94115. Washington, DC : National Academy of Sciences.

BIBLIOGRAPHIE Selic, B. tems.

211

(2000). Fault tolerance techniques for distributed sysThe Rational Edge : e-zine for the rational community. http ://www.therationaledge.com/content/dec_00/t_fault.html.

Selic, B., Moore, A., Bjorkander, M., Gerhardt, M., Watson, B., et Douglass, B. (2000). Response to the OMG RFP for Schedulability, Performance, and Time. Rapport technique Document version 1.0, Object Management Group. http ://www.omg.org. Simons, A. J. H. et Graham, I. (1999). 30 things that go wrong in object modelling with UML 1.3. Dans Behavioral Specications of Businesses and Systems, edit par H. Kilov, B. Rumpe, et I. Simmonds, p. 221242. Kluwer, Dordrecht. http ://citeseer.nj.nec.com/simons99things.html. Smith-Guerin, N. (2000). Contribution laide robotise au geste chirurgical - Nouvelle approche en ophtalmologie. Thse de doctorat, Institut National des Sciences Appliques de Lyon, France. Tah, J. et Carr, V. (2001). Towards a framework for project risk knowledge management in the construction supply chain. Advances in Engineering Software, 32, p. 835846. Tondu, B., Daidi, A., Ippolito, S., et Guiochet, J. (2003). A seven d.o.f. robot arm driven by pneumatic articial muscles for humanod robots. Advanced Robotics. Soumis en juillet 2003. Tondu, B. et Lopez, P. (1997). The McKibben articial muscle and its use in actuating robotarms showing similarities with human arm behavior. Industrial Robot, 24(6), p. 44324339. Tondu, B. et Lopez, P. (2000). Modeling and control of McKibben articial muscle robot actuators. IEEE Control Systems, 20(2), p. 1538. Traon, Y. L., Jron, T., Jzquel, J., et Morel, P. (2000). Efcient OO integration and regression testing. IEEE Transactions on Reliability, p. 1225. Troccaz, J. (1999). La robotique mdicale en France. Journes Nationales de la Recherche en Robotique, p. 251255. Troccaz, J. et Delnondedieu, Y. (1996). Semi-active guiding systems in surgery. A two-DOF prototype of the passive arm with dynamic constraints (PADyC). Mechatronics, 6(4). Urbain, L. et Guiochet, J. (2001). Guide pour lanalyse de sret de fonctionnement du programme de Tl-Echographie Robotis (TER). Rapport Interne Consortium TER 2231-852, SINTERS/LESIA, Toulouse. Vial, D. (1997). Etude et commande oue dactionneurs muscles articiels de McKibben la motorisation de robots-manipulateurs. Thse de doctorat, Institut National des Sciences Appliques de Toulouse, France.

212

BIBLIOGRAPHIE

Vilchis, A. (2003). Tl-chographie Robotise. Thse de doctorat, Institut National Polytechnique de Grenoble. Vilchis, A., Cinquin, P., Troccaz, J., Guerraz, A., Hennion, B., Pellissier, F., Thorel, P., Courreges, F., Gourdon, A., Poisson, G., Vieyres, P., Caron, P., Mrigeaux, O., Urbain, L., Daimo, C., Lavalle, S., Arbeille, P., Althuser, M., Ayoubi, J.-M., Tondu, B., et Ippolito, S. (2001a). TER : a system for Robotic Tele-Echography. Lectures Notes in Computer Science, Medical Image Computing and Computer-Assisted Intervention (MICCAI01), p. 326334. Vilchis, A., Troccaz, J., Cinquin, P., Courreges, F., Poisson, G., et Tondu, B. (2001b). Robotic tele-ultrasound system (TER) : slave robot control. Dans IFAC Conference on Telematics Applications in Automation and Robotics, TA2001. Visinsky, L., Cavallero, J., et Walker, I. (1994). Robotic fault detection and fault tolerance : A survey. Reliability Engineering and System Safety, 46, p. 139158. Wadegaonkar, A., Sunnapwar, V., et Modak, J. (1996). Development of a knowledge-based system for robot work-station safety. Proceedings of International Manufacturing Engineering, 2000 and beyond, p. 359361. Walker, I. et Cavallero, J. (1996). Failure mode analysis for a hazardous waste clean-up manipulator. Reliability Engineering and System Safety, 53, p. 277290. Worthington, J. et Burns, W. (1988). Maintenance and repair, robotic. International Encyclopedia of Robotics : Applications and Automation, p. 833840. R.C. Dorf and S.Y. Nof(eds), John Wiley. Wright, P., Fields, B., et Harrison, M. (1994). Deriving human-error tolerance requirements from tasks. IEEE International Conference on Requirements Engineering (ICRE94), 1, p. 462467. Wu, C. (1988). Compliance. International Encyclopedia of Robotics : Applications and Automation, 1, p. 192202. R.C. Dorf and S.Y. Nof(eds), John Wiley. Yacoub, S., Ammar, H., et Robinson, T. (2000). A methodology for architectural-level risk analysis. Dans 11th International Symposium on Software Reliability Engineering (ISSRE2000), San Jose, CA, p. 210221. Yamada, Y., Hirasawa, Y., Huang, S., et Umetani, Y. (1996). Fail-safe human/robot contact in the safety space. 5th IEEE International Workshop on Robot and Human Communication, p. 5964.

M ATRISE DE LA SCURIT DES SYSTMES DE

LA ROBOTIQUE DE SERVICE

A PPROCHE UML BASE SUR UNE

ANALYSE DU RISQUE SYSTME

Rsum : Les systmes de la robotique de service, tels que les robots mdicaux, permettent de raliser des tches complexes en milieu humain, et sintgrent ce titre dans les systmes scurit critique. Lors de la conception de ces nouvelles applications, la scurit est souvent traite grce des techniques de sret de fonctionnement. Nous proposons cependant une nouvelle approche plus globale, base sur la notion de risque. Lobjectif de cette thse est de proposer une dmarche aux concepteurs pour apprhender la scurit de tels systmes, en intgrant le concept de risque et en se plaant un niveau systme. La matrise de la scurit dpend alors de lactivit de gestion du risque dont le cur est lanalyse du risque. Cette activit centrale se dcompose en trois tapes : la description du systme et de son utilisation, lidentication des dangers, et lestimation des risques de dommages induits par lutilisation du systme. Nous proposons dutiliser la notation UML (Unied Modeling Language) pour la description du systme. Les modles UML sont alors coupls avec des activits du domaine des facteurs humains, incluses dans lanalyse du risque propose. Puis, pour les deux tapes suivantes, les interactions entre cette notation et des techniques danalyse du risque comme lAMDEC (Analyse des Modes de Dfaillance, et de leurs Effets Critiques) et les arbres de fautes sont tudies. Cette dmarche est ensuite applique sur le cas concret du dveloppement dun robot tl-chographe actionn par des muscles articiels de McKibben. Mots cls : Scurit des robots, analyse du risque, UML, robot mdical, muscle articiel.

S AFETY MANAGEMENT OF SERVICE ROBOT SYSTEMS UML APPROACH BASED ON SYSTEM RISK ANALYSIS
Abstract : Service robot systems, as medical robots, can perform complex tasks and share their working area with humans. Therefore, they belong to safety critical systems. In nowadays development process, safety is often managed by the way of dependability techniques. We propose a new global approach, based on the risk concept in order to guide designers along the safety analysis of such complex systems. Safety depends on risk management activity, which core is risk analysis. This one consists in three steps : system denition, hazard identication and risk estimation. We rst propose the use of UML (Unied Modeling Language) as the description language and we integrate human factors activities for the system denition step. Then, for the next steps, interactions of UML and risk analysis techniques such as FMECA (Failure Mode, Effects and Criticality Analysis) and FTA (Fault Tree Analysis) are studied. As an illustration of its potentiality, the proposed approach is then applied to the case study of a system for robotic tele-echography (ultrasound scan examination) actuated by articial muscles of McKibben. Keywords : Robot safety, risk analysis, UML, medical robot, articial muscle.