Travaux sur la déclinaison d’exigences de sûreté de fonctionnement

Dans la littérature, il existe quelques travaux qui traitent de déclinaison d’exigences de sûreté de fonctionnement. Principalement, des travaux ont été réalisés dans les universités de York (Grande-Bretagne) et de Queensland (Australie).

3.1. Travaux de Peter Lindsay, John McDermid et David

Tombs

Les travaux de Peter Lindsay, John McDermid et David Tombs, des universités de York et de Queensland, [Lindsay & al., 1999], [Lindsay & al., 2000] et [Lindsay & al., 2002], sont plutôt orientés vers les systèmes logiciels. Ils partent du constat qu’une grande variété de

70

techniques d’analyse de sûreté de fonctionnement existe, mais que individuellement, ces techniques sont limitées pour faire face aux systèmes complexes, ou pour dériver et prioriser les exigences de sûreté des composants. Ils ont aussi constaté une confusion ou une ambigüité entre les techniques à utiliser pour évaluer les risques et celles plutôt destinées à assigner des objectifs de sûreté.

En fait, chaque composant individuel d’un système complexe a son propre comportement de défaillance, et les défaillances de ces composants mènent aux défaillances du système de façon plus ou moins prévisible. Un système complexe typique possède alors de multiples modes de défaillance. Dans leurs travaux, ils ont donc développé un processus pour dériver les exigences de sûreté de fonctionnement pour tous les composants du système. Ils ont notamment identifié deux aspects concernant la sûreté des composants :

 Un aspect fonctionnel, relatif à ce que le composant est supposé faire ou ne pas faire,

 Un aspect quantitatif, relatif au degré avec lequel le système peut tolérer la défaillance d’une fonction et continuer à fonctionner avec un risque acceptable. Ainsi, pour traiter ces deux aspects, ils proposent un processus qui permet de classer les accidents potentiels et les risques systèmes, de montrer comment les défaillances systèmes conduisent aux risques, d’analyser les défaillances systèmes, et d’identifier les combinaisons de fautes de composants qui peuvent les causer. En utilisant un modèle d’erreur quantifié et basé sur les taux de défaillances tolérés des différentes classes d’accidents, et en exploitant les taux de défaillance des composants connus, ils dérivent des exigences quantifiées sur les composants restants.

Leur processus intègre des techniques existantes d’analyse de sûreté de fonctionnement pour une évaluation complète et quantifiée des risques du système. Il évalue la robustesse du système par rapport aux défaillances des composants et dérive des exigences de sûreté de fonctionnement pour les composants. En résumé, les étapes principales du processus sont les suivantes :

1. Construction d’un modèle de conception du système, qui définit le cadre du système et les fonctions de ses composants.

2. Identification et classification des risques du système. Une analyse de défaillance du type Functional Failure Analysis est suggérée.

3. Identification des fonctions de sûreté système et des mesures de protection à travers la considération de séquences d’accidents. L’utilisation d’arbre d’événements (Event

Tree) est suggérée.

4. Construction d’un modèle détaillé de causes et effets, pour enregistrer comment les fautes se propagent dans le système du niveau composant au niveau système, et pour identifier les causes communes possibles. L’utilisation d’arbre de défaillance (Fault Tree) est suggérée.

5. Allocation d’un budget d’exigences de sûreté, en utilisant les modèles des étapes précédentes pour justifier les objectifs quantitatifs. C’est dans cette dernière étape que se concrétise la déclinaison des exigences de sûreté.

Chapitre 3 Méthodologie de déclinaison d’exigences de sûreté de fonctionnement

71 1. Comment fonctionne le système ?

2. Qu’est ce qui peut arriver de mal ? 3. Comment ce mal peut arriver ? 4. Pourquoi ce mal peut arriver ?

5. Quelle est la probabilité pour que ce mal arrive ?

Plus de détails sur ce processus sont disponible dans le rapport [Lindsay & al., 1999]. Pour appuyer la proposition de ce processus, des exemples sont proposés : celui d’une presse industrielle dans [Lindsay & al., 2000] et [Lindsay & al., 1999], ou celui d’un missile dans [Lindsay & al., 2002].

3.2. Travaux de Tim Kelly et al.

A l’université de York, les travaux sur la dérivation d’exigences de sûreté de fonctionnement ont continué. En particulier, dans [Wu & al., 2006] il est proposé un processus semblable à celui vu dans le paragraphe précédent, ainsi qu’une approche à base de Use Case Maps. L’objet de la proposition concerne aussi la génération d’exigences de sûreté de fonctionnement, et ce le plus tôt possible dans la phase de conception.

La problématique du travail se base sur un constat inclus dans celui que nous avions synthétisé à la fin du chapitre 1, qui est que des exigences inadaptées ou mal-comprises sont la cause majeur de problème de sûreté de fonctionnement. Elle s’appuie aussi sur le fait que des études ont montré l’énorme intérêt en termes de coût à régler les erreurs d’exigences tôt dans le processus de développement.

Le processus proposé s’inspire en fait du modèle Twin Peaks vu dans l’introduction générale, qui explicite clairement l’évolution parallèle et de manière évolutive des processus de définition des exigences et de définition des architectures (voir Figure III.2). Le principe de base de ce modèle est qu’un choix d’exigences peut déterminer un espace d’architectures, et qu’un choix d’architectures candidates peut à son tour contraindre les concepteurs à des exigences particulières.

Figure III.2 : Evolution parallèle des processus de Définition des Exigences et de Définition de l’architecture

Ainsi, de manière condensée, le processus peut se résumer de la manière suivante : Les risques sont identifiés par des analyses de risques faites à partir des descriptions disponibles de l’architecture du système et de son environnement opérationnel. Les risques identifiés sont évalués en termes de probabilité et de sévérité. Des décisions de conception architecturelle sont ensuite faites pour choisir les actions ou stratégies appropriées de réduction des risques, et des exigences de sûreté sont définies en réponse à ces choix de mécanismes de réduction de risques. Pendant que le processus de conception progresse et

72

que des détails supplémentaires sur le système sont obtenus, des risques vont être redéfinis et de nouveaux risques peuvent émerger. Les choix de mécanismes d’atténuation de risques peuvent eux-mêmes être à l’origine de nouveaux problèmes de sûreté. Ainsi, de nouvelles actions de réduction des risques doivent être identifiées et les exigences de sûreté doivent être affinées. Le processus évolue jusqu’à ce que tous les risques soient suffisamment atténués.

Un exemple de système de véhicule guidé automatiquement est également traité dans [Wu & al., 2006], afin d’illustrer le processus.

Dans des travaux précédents, T. Kelly, avec Karen Allenby, s’était également penché sur la possibilité d’utiliser les diagrammes de cas d’utilisation UML et des scénarios associés au cas d’utilisation pour conduire les analyses de risques. Plus de détails sur cette proposition sont disponible dans [Allenby & al., 2001]. Notamment, cette publication présente un exemple relatif au contrôle des reverses (ou inverseurs de poussée) d’un avion de ligne. Il illustre bien le fait que de nouvelles exigences de sûreté de fonctionnement sont créées suite à une analyse de risques, ceci pour différentes conditions de défaillance. Ces exigences de sûreté sont alors soit des contraintes de performance (comme un taux de défaillance ou un temps de réponse), soit des exigences fonctionnelles additionnelles.

Finalement, on s’aperçoit que le processus de dérivation d’exigences de sûreté de fonctionnement reste le même, quelques soit les techniques utilisées. C’est exactement ce qui est expliqué dans [Alexander & al., 2009], où les trois phases fondamentales des processus de dérivation d’exigences de sûreté ont été identifiées :

1. Identification des risques, 2. Analyse des risques,

3. Dérivation des exigences de sûreté de fonctionnement.

Il existe de nombreuses méthodes différentes, qui, en les combinant astucieusement, permettent la réalisation de chacune de ces étapes, et donc l’accomplissement du processus de dérivation. La même publication, [Alexander & al., 2009], cite un certain nombre de ces méthodes.

Les différents travaux que nous venons de présenter ne s’intéressent pas explicitement à la gestion de la traçabilité lors de la génération des exigences à différents niveaux. A notre connaissance, ce sont les seuls travaux traitant de la problématique de déclinaison des exigences de sûreté à différents niveaux du système.