Composant indépendant de sécurité - Tolérance aux fautes dans les systèmes autonomes

Comme unité indépendante d’un système, chargé de faire respecter des consignes de sécurité-innocuité, le principe de composant indépendant de sécurité a connu plusieurs applications efficaces dans les systèmes informatisés, par exemple avec le système d’aiguillage ferroviaire automatisé ELEKTRA [Klein 1991], ou le système de surveillance SPIN pour centrale nucléaire [Guesnier et al. 1997]. Une définition est proposée dans [Guiochet & Powell 2006], et caractérise un (sous-)système indépendant de sécurité4_{comme étant :}

• indépendant vis-à-vis du sous-système fonctionnel principal, c’est-à-dire qui possède son propre fil d’exécution et une mémoire protégée,

• dont la spécification est différente de celle du sous-système fonctionnel, no- tamment en ce qui concerne les règles de sécurité,

• qui surveille en permanence le système global (donc le sous-système fonctionnel), afin d’empêcher toute transition vers un état dangereux,

• qui, en cas de danger, amène le système global dans un état sûr, tel que défini par les concepteurs du système.

Nous nous intéressons dans cette section à l’application de ce type de composant aux systèmes autonomes, en présentant tout d’abord leurs caractéristiques, puis deux exemples d’implantation.

3_{voir plus loin, section 2.3.2.1.} 4_{independent safety (sub)system}

2.2 Composant indépendant de sécurité

43

2.2.1 Caractéristiques

Un composant indépendant de sécurité est principalement caractérisé par ses règles de sécurité, et ses moyens d’observation et d’action. Tous deux dépendent à la fois de l’application envisagée, et du système dans lequel le composant est implanté.

2.2.1.1 Règles de sécurité

Un composant indépendant de sécurité peut permettre de tolérer différents types de situations adverses pour améliorer la sécurité-innocuité du système. Dans les systèmes autonomes, ces situations comportent :

• des désaccords entre différents composants du système, en s’assurant que des actions contradictoires ne sont pas entreprises par les composants du système (tolérance aux fautes),

• des fautes dans les mécanismes d’inférence ou les connaissances des méca- nismes décisionnels, dues à la complexité et aux difficultés de validation des mécanismes décisionnels, (tolérance aux fautes),

• des situations adverses imprévues face auxquelles le système ne réagit pas correctement, dues à un environnement ouvert qui rend impossible un test exhaustif comprenant tous les contextes d’exécution (robustesse).

L’expression des règles de sécurité est fondamentale au composant indépen- dant de sécurité, et conditionne quelles situations adverses celui-ci permet de to- lérer. Cependant, peu de travaux se sont concentrés sur la définition de ces règles, privilégiant plutôt la conception et la mise en place du composant de sécurité. À notre avis, le développement des règles de sécurité passe par différentes phases- clés, dont :

• la mise en place d’un modèle du système, représentant son état et son évo- lution à partir des informations accessibles au composant de sécurité, • l’identification des situations adverses dangereuses ; cette identification est

basée sur les spécifications du système, des outils et résultats de prévision des fautes, et le modèle précédemment établi,

• l’établissement des règles de sécurité à partir de l’étape précédente, et leur traduction dans un langage formel utilisable par le composant de sécurité. Une étape de validation des règles formelles nous semble aussi indispensable, en utilisant le test et des méthodes formelles.

2.2.1.2 Observation et action

Afin de mettre à jour son modèle du système, et vérifier le respect des règles de sécurité, un composant indépendant de sécurité a besoin d’accéder à des informations sur l’état du système qu’il supervise.

Dans les systèmes informatisés, une approche boîte noire est souvent privilé- giée, c’est-à-dire que les développeurs considèrent que le composant de sécurité ne doit pas accéder à l’état interne du système qu’il surveille, cet état étant potentiellement erroné, et ne doit baser ses observations que sur ses propres capteurs.

Une approche boîte blanche est aussi envisageable pour les systèmes autonomes. Elle part du principe que les capteurs et les mécanismes de communication

44 Chapitre 2 - Architectures et Méthodes

du système disposent de leurs propres mécanismes de tolérance aux fautes, et que le composant de sécurité a pour but principal de surveiller les composants logiciels décisionnels et exécutifs. Pour répondre à ses besoins d’observation, le composant de sécurité intercepte dans ce cas des paramètres internes du système, qui peuvent être de deux types différents :

• D’une part, des données de capteurs de la plate-forme matérielle, brutes ou déjà traitées par d’autres composants du système, permettent de connaître l’état du système dans son environnement (vitesse, présence d’obstacles, etc...).

• D’autre part, des données propres à l’exécution de la tâche du système, en particulier les commandes de lancement de requêtes, doivent être intercep- tées afin que le composant de sécurité détermine les intentions du méca- nisme décisionnel, et stoppe une requête potentiellement dangereuse avant son exécution.

Une fois qu’une intention du mécanisme décisionnel ou une évolution dans l’état du système risque d’enfreindre une règle de sécurité, le composant de sécu- rité peut effectuer différents types de rétablissement, dont principalement :

• l’exécution d’une séquence d’actions dans le but de revenir dans un comportement sûr de fonctionnement, ultimement à travers une mise en état sûr du système,

• le rejet préventif d’une tâche demandée par le mécanisme décisionnel et qui risquerait d’enfreindre les règles de sécurité.

2.2.2 Applications dans les systèmes autonomes

Des composants indépendants de sécurité ont déjà été conçus pour des systèmes autonomes. Nous présentons ci-dessous l’exemple du R2C dans l’architecture LAAS [Py 2005], et le principe de Guardian Agent présenté dans [Fox & Das 2000].

2.2.2.1 Request and Report Checker

Le Request and Report Checker, ou R2C, est un composant développé pour l’architecture de type hiérarchisé LAAS, dont la structure est présentée sur la Figure 2.2.

Le R2C possède une base de données sur l’état du système, qu’il met à jour à partir de bilans et de requêtes interceptés entre le mécanisme décisionnel et les différents modules fonctionnels du robot. Cette base de données est utilisée pour vérifier si une nouvelle requête est valide, et déterminer l’action à suivre en cas d’infraction aux règles de sécurité : généralement l’abandon de la requête incrimi- née, ou l’arrêt d’une tâche contradictoire en cours d’exécution.

Intégré à l’architecture LAAS, le R2C vérifie en particulier le comportement correct des interactions entre modules du niveau fonctionnel, qui s’exécutent de façon asynchrone et concurrente. En ce sens, il cherche à tolérer des désaccords entre l’activité de différents modules, et implicitement des fautes dans le méca- nisme décisionnel ou dans la programmation des modules qui pourraient en être responsables. D’autres règles de sécurité lui ont aussi été appliquées, comme le

2.2 Composant indépendant de sécurité

45

tampon d’entrée contrôleur

actions

d’état

(lancement, arrêt)

tampon de sortie écriture base de données sur l’état du système

mise à jour lecture

requêtes

bilans de requête

bilans d’action

Figure 2.2: Composant R2C

contrôle de la vitesse maximale du robot, permettant de tolérer dans une certaine mesure des situations adverses imprévues (par exemple une collision avec un obs- tacle, un sol glissant, etc...) ou d’autres fautes de conception.

2.2.2.2 Guardian Agent

Le principe de Guardian Agent [Fox & Das 2000] essaie d’appliquer et d’étendre le concept de composant indépendant de sécurité aux mécanismes déci- sionnels, en particulier aux systèmes experts. Pour cela, les auteurs proposent un langage formel comportant des axiomes relatifs à la sécurité pour permettre une analyse et un contrôle pertinent des intentions et des actions du système, et éven- tuellement l’utilisation de mécanismes décisionnels pour obtenir une meilleure compréhension et réaction face aux situations adverses rencontrées.

Le langage proposé par les auteurs, nommé LSafe, inclut par exemple des no-

tions de permission, d’obligation ou d’autorisation sur l’exécution d’une action. Un exemple de proposition est : L’action A doit être autorisée avant d’être permise, et l’action B est obligatoire avant que l’action A ne soit permise ; elle signifie qu’avant que l’action A ne puisse être exécutée par le système, elle doit d’une part être autorisée par une autorité supérieure (un opérateur, ou un autre système), et d’autre part être précédée par l’exécution de l’action B. Les auteurs avancent aussi différents éléments de réflexion sur le processus d’identification et de construction des règles de sécurité.

Cependant, le Guardian Agent n’a pas été mis en pratique sur un système exis- tant, et les difficultés soulevées par sa mise en œuvre n’ont pas encore été étudiées.

46 Chapitre 2 - Architectures et Méthodes

2.3 Mécanismes liés au contrôle d’exécution et à la

Dans le document Tolérance aux fautes dans les systèmes autonomes (Page 42-46)