La sécurité-innocuité dans les systèmes autonomes

«La sûreté de fonctionnement d’un système est la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il leur délivre.» [Laprie 1996] .

La sécurité-innocuité est l’attribut de la sûreté de fonctionnement défini comme «la non-occurrence de conséquences catastrophiques pour l’environnement» dues au système [Laprie 1996] [Avižienis 2004]. Les conséquences catastrophiques comprennent, bien évidemment, le décès et les blessures des utilisateurs et des opérateurs, mais aussi des dommages matériels et financiers, s’ils sont sans commune mesure avec le service fourni par le système. Beaucoup de systèmes ne sont pas concernés par cette propriété car leurs limites physiques ne leur permettent pas de causer de tels dommages. Les autres systèmes sont appelés systèmes critiques. On abrégera dans la suite sécurité-innocuité par sécurité. La sécurité entretient des relations paradoxales avec la continuité du service correct, caractérisée en sûreté de fonctionnement par la fiabilité et la disponibilité. D’une part, la continuité de service participe à la sécurité : des défaillances récurrentes suscitent des usages incorrects, potentiellement dangereux. D’autre part, sécurité et continuité de service peuvent être antagonistes. Un système de sécurité est traditionnellement responsable de l’arrêt d’urgence, c’est-à-dire de mettre le système dans un état stable et non-fonctionnel, supposé être sûr. L’arrêt empêche ou diminue les dommages mais ne permet pas de fournir le service attendu. Toutefois l’arrêt n’est pas nécessairement l’état le plus sûr. Par exemple, le freinage d’urgence d’une voiture soulève des problèmes de sécurité. L’arrêt est très utilisé car c’est un état qui peut être atteint avec une grande fiabilité. C’est la troisième interaction entre sécurité et continuité de service : la sécurité ne peut être assurée que par un système de sécurité fiable, capable de fournir un service correct même dans des situations exceptionnelles.

Les systèmes autonomes critiques

Définition et caractéristiques des systèmes autonomes

Il n’existe pas de consensus autour d’une définition de l’autonomie des systèmes. Certaines se rapprochent du sens étymologique : «se gouverner d’après ses propres lois». Une définition plus technique et qui reflète plus la réalité de la robotique autonome a été proposée par le Nist (National Institute of Standards and Technology) [Huang 2008] :

«L’autonomie est la capacité d’un système à percevoir, analyser, communiquer, planifier, établir des décisions et agir, afin d’atteindre des objectifs assignés par un opérateur humain.» .

Cette définition n’établit pas de distinction franche entre les systèmes autonomes et les systèmes automatiques. En effet, l’autonomie est une propriété graduelle que le Nist propose d’évaluer par la complexité et la variété des missions, la difficulté de l’environnement et les interactions homme-robot. Des éléments sont communs à tous les systèmes physiques : la perception, l’actionnement. La commande, décomposée en analyse, communication, planification et décision est largement plus développée que dans les systèmes automatiques. La capacité d’analyse suppose différents niveaux d’abstraction et la planification une vision à long terme. Par exemple, la commande d’une voiture autonome doit mettre en œuvre le contrôle moteur mais aussi tenir compte des piétons et du code la route, tout en planifiant le trajet sur plusieurs kilomètres. Un déambulateur robotisé qui aide le patient à s’équilibrer pendant la marche a un degré d’autonomie moindre car il ne peut que rejoindre sa base de manière autonome. D’autre part, son environnement, l’hôpital, est bien moins accidenté. La complexité de la commande permet au système de remplir des missions plus complexes et/ou plus diversifiées, sans intervention de l’opérateur, dans un environnement ouvert, peu ou pas structuré. S’adapter à l’environnement nécessite une certaine puissance physique et une latitude de mouvement, ce qui donne aussi au système les moyens de causer des dommages. C’est pourquoi les systèmes autonomes sont, pour la plupart, critiques. Les systèmes autonomes ne sont pas tous robotiques, citons par exemple les voitures électriques. Par ailleurs la robotique est loin de se limiter aux systèmes autonomes. Toutefois une grande part des systèmes autonomes relève de la robotique, et les techniques propres à l’autonomie, telles que la planification, sont issues de la communauté de la robotique. Même si la définition de l’autonomie ne fait pas référence à la robotique, l’autonomie y est historiquement et technologiquement liée.

La robotique automatique a répondu au problème de la sécurité par des mesures structurant l’environnement. D’une part, l’environnement est figé ou normalisé pour être connu et exempt de situations adverses. Un robot manufacturier dont la trajectoire est complètement programmée à la conception ne peut saisir une pièce que si elle arrive précisément à l’endroit prévu. Dans le cas de la navigation dans une usine, des rails peuvent être mis en place, ou une carte des obstacles (qui sont donc considérés comme fixes) établie ; ou encore les obstacles peuvent être modifiés afin qu’ils soient détectables à la hauteur des capteurs laser des robots. D’autre part, l’espace est réparti entre les robots et les humains ; la délimitation a été marquée par des barrières physiques puis des rideaux infra-rouges. Dans le cas des systèmes autonomes, il est au contraire souhaitable que le système puisse évoluer dans un environnement le moins structuré possible, et en particulier en milieu humain. Dans ce contexte, l’enjeu est évidemment de déterminer les mesures de sécurité permettant cette évolution .

Architecture et outils de développement

Plusieurs types d’architectures ont été proposés pour la commande des systèmes autonomes. Une présentation en est par exemple faite dans [Lussier 2007a]. Cependant, une grande majorité des systèmes autonomes ont maintenant une architecture de type hiérarchisé, et nous nous y limiterons. l’architecture hiérarchisée est classiquement structurée en trois niveaux :

Le niveau décisionnel est le plus haut niveau de l’architecture. Il reçoit des objectifs et génère des plans à partir d’une représentation abstraite du système et de son environnement. Ce niveau n’offre pas de garantie en terme de temps d’exécution.

Le niveau exécutif convertit les plans qu’il reçoit du niveau décisionnel en fonctions élémentaires du niveau fonctionnel. Ce niveau a des exigences temps-réel.

Le niveau fonctionnel gère l’interface matérielle. Le niveau est décomposé en fonctions élémentaires qui communiquent entre elles mais ne partagent pas de représentation globale du système. Le temps d’exécution doit être adapté à l’interface avec les capteurs et les actionneurs.

De plus, chaque niveau rend compte au niveau supérieur de l’accomplissement des tâches et des éventuelles erreurs qui ne pourraient pas être traitées localement. L’architecture hiérarchisée existe en de nombreuses versions, par exemple sans niveau décisionnel ou avec des niveaux exécutif et fonctionnel fusionnés. Les architectures hybrides permettent aux observations du niveau fonctionnel d’être propagées directement au niveau décisionnel, pour accélérer leur prise en compte. L’hétérogénéité au sein de l’architecture soulève des problèmes de communication entre les différents niveaux et fonctions. C’est pourquoi la communication entre composants logiciels est réalisée par des intergiciels (ou middleware), tels que ROS (Robot Operating System, [Quigley 2009]). Les intergiciels facilitent aussi la réutilisation et l’échange des composants développés, et contribuent à la qualité du logiciel en fournissant des services et des formats standardisés. Dans un objectif d’efficacité et de prévention des fautes, des environnements de développement propres à la robotique existent. Par exemple, GenoM ([Fleury 1997], [Mallet 2010]) permet d’abstraire le niveau fonctionnel et de rendre modulaire chaque fonction. Pour chaque composant, un minimum de code est écrit par le développeur, la gestion de la communication entre les composants étant générée automatiquement.

Interactions avec l’homme

Une caractéristique importante des systèmes autonomes est liée aux interactions avec l’homme. À l’opposé du robot solitaire sur Mars, un défi majeur de la robotique autonome actuelle est de faire cohabiter et collaborer des robots avec des êtres humains. La sécurité est très représentée dans les rôles que peut remplir un homme visà-vis d’un système autonome en opération [Alexander 2009a] : l’être humain peut être responsable de la sécurité, en appliquant des procédures normalisées mais aussi en faisant face aux situations inattendues, voire en secourant le robot. Les interactions de ce type sont un moyen de traitement des dangers et sont communes à tous les systèmes complexes. Les interactions physiques[Alami 2006], plus spécifiques aux systèmes autonomes, sont sources de dangers. Elles sont définies comme des contacts entre un être humain et une partie physique du système. Pour réduire la gravité de ces interactions, des robots à faible raideur et capables de percevoir les forces externes ont été développés (voir par exemple [Tonietti 2005]). Les interactions physiques deviennent alors propices à la communication entre l’être humain et le système. Pour assurer la sécurité, la démarche classique de séparation spatiale homme-robot n’est alors plus valide, puisque le contact est désiré. Au contraire des interactions physiques, les interactions cognitives se font sans contact ; elles passent en général par la vision ou le son. Par exemple, un robot transportant un couteau pointant vers l’avant est considéré comme dangereux par un utilisateur. Pour y remédier, des approches de planification prenant en compte la présence humaine ont été développées, dont [Sisbot 2012]. Ainsi, la sécurité est prise en compte comme une propriété ressentie par l’utilisateur. Cet aspect s’insère dans le contexte plus large de la confiance [Schaeffer 2013] et de l’acceptabilité d’un système autonome. Dans [Kruse 2013], l’acceptabilité est déclinée en trois paramètres :

— Le confort est l’absence de perturbation ou de stress provoqués par le robot. Cela comprend des limites de distances, de vitesse, d’accélération modulées, par la position de l’utilisateur (assis ou debout, de face ou de dos, etc.).
— Le naturel est la ressemblance du robot avec l’humain. Des mouvements naturels sont notamment plus prévisibles.
— La sociabilité est le respect des conventions culturelles. Par exemple, on évite de passer à travers un groupe .

Le sentiment de sécurité des utilisateurs est assez différent et décorrélé de la sécurité telle qu’elle est envisagée par les experts et les normes.

Table des matières

Introduction
1 La sécurité-innocuité dans les systèmes autonomes
1.1 Les systèmes autonomes critiques
1.1.1 Définition et caractéristiques des systèmes autonomes
1.1.2 Architecture et outils de développement
1.1.3 Interactions avec l’homme
1.1.4 Normes de sécurité en vigueur
1.1.5 Fautes des systèmes autonomes
1.2 Prévision des fautes
1.3 Elimination des fautes
1.3.1 Test
1.3.2 Vérification statique
1.4 Tolérance aux fautes
1.4.1 Mécanismes dans le niveau décisionnel
1.4.2 Mécanismes dans le niveau exécutif
1.4.3 Mécanismes séparés de la commande principale
1.4.4 Identification et expression des règles de sécurité
1.5 Bilan
1.5.1 Du moniteur de sécurité et de ses spécifications
1.5.2 Des interventions
1.5.3 De l’anticipation du danger et de la polyvalence
1.6 Conclusion
2 Problématique : la spécification des règles de sécurité
2.1 Le moniteur de sécurité
2.2 Propriétés désirées
2.2.1 Sécurité
2.2.2 Permissivité
2.3 Règles et stratégies de sécurité
2.4 L’approche par états d’alerte
2.5 Synthèse de stratégies
2.6 Conclusion
3 Modélisation
3.1 Exemple introductif
3.2 Structure et contenu du modèle
3.2.1 Comportement
3.2.1.1 Abstraction des états
3.2.1.2 Définition de l’automate
3.2.2 Interventions
3.2.3 Stratégie
3.2.4 Propriétés
3.2.5 Résumé
3.3 Encodage du modèle
3.3.1 Outil de vérification de modèle utilisé
3.3.2 Construction du modèle avec NuSMV
3.3.2.1 Encodage par l’utilisateur
3.3.2.2 Partie générée et outil
3.4 Existence et choix d’une stratégie
3.5 Conflits entre stratégies
3.5.1 Mise en cohérence des observations
3.5.2 Mise en cohérence des interventions
3.5.3 Vérifications
3.6 Conclusion
4 Synthèse des stratégies de sécurité
4.1 Spécification de la synthèse
4.1.1 Formalisation des stratégies
4.1.2 Ensembles de solutions
4.1.3 Propriétés de complétude et d’exclusivité
4.2 Algorithme de synthèse
4.2.1 Arbre de stratégie
4.2.2 Relation entre les stratégies
4.2.3 Parcours de l’arbre
4.3 Critères de coupe
4.3.1 Critère de permissivité
4.3.2 Critère de validité
4.3.3 Critère de correction
4.3.4 Critère de sécurité partielle et coupe du sous-arbre
4.3.5 Critère de sécurité partielle et coupe des frères combinés
4.4 L’outil de synthèse
4.4.1 Les variantes du parcours d’arbre
4.4.2 Implémentation
4.4.3 Performances
4.5 Ouverture sur la théorie des jeux
4.5.1 Approche par les jeux
4.5.2 Modélisation sous TIGA
4.5.3 Résultats et comparaison
4.6 Conclusion
5 Étude d’un cas industriel
5.1 Présentation du robot
5.2 Analyse de risque et formulation des invariants
5.3 Modélisation et synthèse
5.3.1 Les invariants simples (SI1 à SI4)
5.3.2 SI5 : Le bras ne doit pas être étendu au-delà de la plateforme lorsque la plate-forme bouge
5.3.3 SI6 : Une boîte saisie par la pince ne doit pas être penchée avec un angle supérieur à α0
5.3.4 SI7 : Une collision entre le bras du robot et un être humain ne doit pas blesser l’être humain
5.3.5 Les autres invariants (SI8 à SI13)
5.3.6 Analyse de conflit
5.4 Implémentation et tests des stratégies
5.4.1 Conditions d’expérimentation
5.4.2 Cas de test
5.4.3 Résultats
5.5 Conclusion
Conclusion générale

Lire le rapport complet