A partir du modèle fonctionnel réalisé dans l’étape précédente, l’analyse de risque a permis d’identifier les composants critiques (fonctions ou briques selon le modèle) c’est-à-dire ceux dont les modes de défaillance conduisent à des événements redoutés de Romeo2.

La méthodologie d’analyse de sécurité proposée par ALL4TEC et adoptée pour Romeo2 est décrite dans la figure ci-dessous :

Analyse de risque système
Figure 6 : Méthodologie d’analyse de sécurité

Comme décrit dans la méthodologie, l’analyse de risque se déroule en 3 étapes :

  • Analyse Préliminaire des Risques (APR)
  • Analyse des Modes de Défaillance, de leurs Effets et de leurs Criticités (AMDEC)
  • Arbres de Défaillance (AdD)

Analyse Préliminaire des Risques (APR)

Une Analyse Préliminaire des Risques (APR) a pour objectif l’identification et l’évaluation des risques associés à un élément, système ou sous-système. Il s’agit, d’une part, de définir les évènements redoutés susceptibles d’apparaitre lors de la mise en œuvre d’un élément et d’autre part de les hiérarchiser en définissant la gravité et la fréquence d’apparition de chaque évènement.

Un extrait de l’APR Romeo2 réalisé est montré dans la Figure 7.

Analyse Préliminaire des Risques
Figure 7 : Extrait de l’Analyse Préliminaire des Risques

Une des fonctions de Romeo2 consiste à porter des objets et les rapporter à l’utilisateur. Le risque associé à ce scénario d’usage est que Romeo2 laisse tomber ces objets sur l’utilisateur.

La criticité de cet événement redouté est élevée ce qui implique un développement rigoureux et une analyse de risque approfondie de cette fonction dans le but d’éviter la chute d’objets.

Un autre scénario d’usage à conséquence critique concerne la fonction « Appel au secours en cas de problème lié à l’utilisateur ».

Analyse des Modes de Défaillance, de leurs Effets et de leurs Criticités (AMDEC)

L’AMDEC est une méthode d’analyse exhaustive durant laquelle toutes les fonctions et les composants sont analysés les uns après les autres pour établir l’ensemble des modes de défaillance du logiciel et du matériel, leurs causes et leurs effets. Le but est de mettre en évidence toutes les sources possibles de défaillances de chaque fonction et de chaque composant en identifiant les effets de ces défaillances sur le comportement et la sécurité de Romeo2 ainsi qu’établir l’interaction entre les fonctions, les composants et les évènements redoutés.

Analyse des Modes de Défaillance, de leurs Effets et de leurs Criticités (AMDEC)
Figure 8 : Extrait de l’AMDEC

La Figure 8 représente un extrait d’AMDEC appliqué à Romeo2 dans lequel les deux événements redoutés « Appel au secours en cas de problème lié à l’utilisateur » et « Chute d’objets » sont traités.

Ces évènements redoutés sont associés à une défaillance d’une fonction software pour l’un et à une défaillance d’un composant pour l’autre. Les causes possibles sont listées et un plan d’action est mis en place pour prévenir ces risques

Une cotation en fonction de l’occurrence, de la gravité et de la détection permet de hiérarchiser les événements redoutés et ainsi prioriser les actions à mener.

Arbres de Défaillance (AdD)

L’Arbre de Défaillance est une méthode déductive (logique et rigoureuse), qui permet de savoir comment un système peut être indisponible. Il s’agit de représenter les différents événements et leurs liaisons par des portes de logique (porte ET, OU, etc…).

Cette méthode déductive a permis la recherche de toutes les combinaisons de défaillances élémentaires pouvant aboutir à un événement redouté.

Comme pour la tâche précédente, le travail a été réalisé pendant les réunions de travail avec les différents partenaires (ALL4TEC, CEA LIST, SoftBank Robotics) et les experts du robot.

Arbres de Défaillance (AdD)1
Figure 9 : Extrait d’un Arbre de Défaillance

La Figure 9 représente un extrait d’un arbre de défaillance lié à l’événement redouté « Chute de Romeo2 ». L’arbre de défaillance a pour but de chercher toutes les causes racines qui peuvent engendrer la chute du robot.

La suite logique de ces trois analyses est de proposer des modifications de l’architecture de Romeo2 dans le but d’éviter tous les événements redoutés identifiées lors des analyses de risque et rendre le système plus sûr.