• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 05/12/2019

Évaluez la sécurité des systèmes embarqués en vol

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Fondamentaux de la sûreté de fonctionnement

Comme vous l’avez vu, les évaluations de sécurité des systèmes font partie des analyses générales de sûreté de fonctionnement et elles contribuent à démontrer le principe : plus c’est grave, moins ça doit se produire.

Ce principe est général, et le but des évaluations de sécurité sont de l’évaluer de manière pragmatique et rigoureuse. Pour faire cela, une première étape consiste à transformer ce principe en exigence que l’on pourra vérifier sur les systèmes.

Une fois le principe pour ce système identifié et que nous avons obtenu les exigences applicables au système, on effectue des calculs, des évaluations, des analyses pour s’assurer que le système satisfait bien les exigences.

Ce processus d’identification des exigences et de vérifications est refait plusieurs fois dans le cycle de développement du système. Ceci afin de détecter au plus tôt les problèmes, de tracer progressivement les choix qui sont faits et de s’assurer que l’on est cohérent tout au long du cycle de vie du système.

Déclinaison des exigences de sécurité

Nous allons rentrer un petit peu dans le détail de la déclinaison des exigences de sécurité. Pour arriver à faire ce travail, il faut partir d’une base communément acceptée où sont définis le sens des mots graves et les seuils d’acceptation des événements graves. Dans l’aéronautique par exemple, ces termes sont définis dans un règlement européen.

Prenons l'exemple concret que vous avez déjà pu voir :  le terme « Catastrophic », qui est le plus haut niveau de gravité pour un événement.

Dans l’aéronautique civile, l’échelle de gravité comprend les échelons « Catastrophique », « Dangereux », « Majeur », « Mineur » et puis « Sans effet de sécurité ». Et si on prend la définition précise de l’échelon « Catastrophique » il signifie que la panne, l’événement redouté, va conduire à des pertes de vie humaine et éventuellement à la destruction de l’avion.

Gravité du cas de panne

Seuils d'acceptation qualitatifs et quantitatifs

Catastrophique : conditions de défaillance, qui entraîneraient des accidents mortels, généralement avec la perte de l'avion.

1. Objectif de sécurité en cas de défaillance : les défaillances isolées ne devraient pas être catastrophiques.

2. Les conditions de défaillance catastrophiques doivent être extrêmement improbables, c'est-à-dire une probabilité moyenne par heure de vol de l'ordre de 1x10^(-9) ou moins.

C'est la caractérisation d’un échelon de gravité. En face de cet échelon, sont inscrits des seuils d’acceptation de l’événement redouté et on met deux types de seuils.

Le seuil qualitatif traditionnel en aéronautique civile est conditionné par l’objectif de conception « Fail Safe ». Que dit cet objectif ? Il spécifie qu’une panne unique ne doit pas conduire à un événement redouté catastrophique. Dès qu'une condition de panne amène un événement catastrophique, tous les systèmes qui conduisent à cet événement devront être « Fail Safe ».

Les référentiels définissent de manière précise ces échelles de gravité et les seuils d’acceptation des évènements redoutés. Il nous faut encore préciser ces notions par rapport au système que nous sommes en train d’étudier. Pour identifier ce qui est grave pour le système, nous allons prendre les fonctions réalisées par le système les unes après les autres, puis nous allons élaborer des scénarios pour répondre à la question « quel est l’effet d’une défaillance de cette fonction ? ».

Pour cette méthode, il existe des guides pour l’appliquer dans l’aéronautique. Ils s’appellent « Aerospace Recommended Practice, 4754 et 4761 », et on trouve dans ces guides le cas de la fonction de freinage de l’avion au sol.

Fonctions remplies par le système

Revue et classification des cas de panne / fonction

Freinage de l'avion au sol

Cas de panne 1 : perte non annoncée de la capacité de freinage à l'atterrissage

Effet : l'équipage ne peut pas décélérer suffisamment l'avion avant la fin de la piste

Classification : catastrophique

Cas de panne 2 : ... 

L’équipage n’étant pas averti, l’effet de cette panne est que l’équipage ne peut pas déployer des solutions de secours pour compenser la perte des systèmes qui réalisent le freinage au sol, et donc l’avion a de très grandes « chances » de sortir de la piste. Ce qui est catastrophique dans cet événement est donc : il y a des « chances » pour que l’on ait plusieurs morts consécutifs à cette défaillance. On peut aussi imaginer une perte de freinage annoncée mais la situation ne sera pas la même. Ce travail est effectué pour toutes les fonctions de notre système et on débouche sur les exigences associées au fait que le cas de panne est catastrophique, dangereux, majeur, etc., etc. 

Les causes de défaillances

Nous venons de voir comment préciser les exigences de sécurité en tenant compte des fonctions réalisées par le système pour couvrir au mieux les risques ; il nous faut aussi concrétiser ces exigences en tenant compte des causes possibles des défaillances des fonctions.

Causes potentielles des défaillances d'un item

Types d'exigences applicables à l'item pour limiter sa défaillance

Vieillissement, usure interne

Taux de défaillance de l'item par heure de vol

Erreur de conception

Niveau d'assurance qualité (Development Assurance Level) requis selon la gravité des défaillances.

DAL A requis pour prévenir des cas de panne catastrophiques.

Propagation indue des défaillances d'un autre item

Exigence de ségrégation entre items pour prévenir les causes communes de défaillance

On peut trouver au moins trois causes primaires de défaillance.

Une première cause est l’usure, le vieillissement naturel des équipements. On est capable de caractériser les phénomènes de vieillissement de manière statistique, donc on a tout intérêt pour maîtriser ces causes à mettre des exigences de nature probabiliste sur l’occurrence des événements associés. On raisonnera par exemple sur les taux de défaillance de l’item impacté par l’usure.

Un second type de cause de défaillance est l’erreur de conception. Dans ce cas, on ne peut plus faire de raisonnements statistiques car l’erreur est présente dès la conception et se manifestera dans des conditions qui restent à déterminer. Donc, pour maîtriser ce type d’erreur et le limiter, on définit des niveaux d’assurance qualité appelés en anglais « Development Assurance Level » (DAL) pour la partie aéronautique. Nous allons nous  efforcer, pour un niveau d’assurance qualité donné, d’éliminer un maximum d’erreurs de conception. En aéronautique, le DAL A est le niveau qui est associé aux fonctions les plus critiques.

Le dernier type de cause porte sur les causes externes aux composants considérés. L’enjeu est de s’assurer que des interférences entre le composant considéré et d’autres composants ne vont pas amener à des défaillances. On pose donc des exigences de ségrégation pour formaliser ce besoin.

Vérification des exigences de sécurité

Pour la vérification, il existe un principe de base en analyse de sécurité : modéliser la propagation des défaillances.

Un premier schéma d’analyse de la propagation des défaillances consiste à réaliser une analyse inductive. On part des causes élémentaires et on recherche les effets induits.

Par exemple, au bord d’un avion, on a un système hydraulique. Cause : le système hydraulique tombe en panne. Effet : on ne peut plus déployer le système de freinage. Ce type d’analyse se fait composant par composant, puis à l’intérieur des composants, puis grande fonction par grande fonction des composants. On regarde les effets au niveau plus général de l’avion ou du système qui intègre les composants. Cela s’appelle une « analyse des modes de défaillances et de leurs effets ». C’est une analyse standard dans plusieurs domaines.

Exemple d'arbre à défaillance
Exemple d'arbre de défaillance

Dans un autre type d’analyse, c’est le contraire. On part du cas de panne et on cherche les causes du cas de panne.  Cette analyse peut s'effectuer grâce aux « arbres de défaillance ». Le schéma ci-dessus montre un arbre de défaillance pour la perte non annoncée de la fonction de freinage. On peut voir que la perte non annoncée de la fonction de freinage est causée par la perte non annoncée de trois systèmes : le système normal de freinage, le système alternatif de freinage et le système de secours de freinage, puisqu’on en a trois à bord d’un avion.

La modélisation de la propagation de la défaillance est réalisée par les experts en fonction de leur compréhension du fonctionnement et du dysfonctionnement du système. Pour assister l’exploitation de ces modèles de propagation de défaillance, il faut utiliser des outils mathématiques comme le petit arbre du schéma.

Dans ce cas, il s'agit d'une fonction mathématique « booléenne ». Les paramètres de cette fonction sont les défaillances élémentaires des composants qui peuvent amener à la perte totale de la fonction. La fonction « booléenne » dit vrai si l’événement redouté est vrai, et faux sinon. Le fait que ce soit une fonction « booléenne » est très important car on peut ainsi automatiser différents calculs et obtenir des résultats de manière sûre.

Les calculs que l’on peut faire consistent à rechercher automatiquement les combinaisons de défaillance, les feuilles de l’arbre qui amènent à l’événement redouté « racine » ; ça s’appelle les « coupes ». On peut aussi, à partir des probabilités d’occurrence des défaillances des feuilles, calculer la probabilité de la défaillance de la racine, de l’événement redouté que l’on veut étudier.

L’arbre de défaillance est un modèle mathématique bien connu, bien défini par les standards. On a aussi des méthodes plus empiriques pour capturer des évaluations liées aux règles de l’art. Un exemple précis d’évaluation lié aux règles de l’art du domaine, ce sont les règles d’allocation des niveaux d’assurance qualité aux composants. Ces règles sont énoncées  dans le standard « Aerospace Recommended Practice 4754A ».

Les fonctions dont les défaillances contribuent à un cas de panne catastrophique doivent :

  • avoir un niveau d'assurance qualité compris entre A et C ;

  • comprendre doit 1 fonction de DAL A soit 2 fonctions de DAL B ségréguées.

Exemple : les règles d'allocation des DAL selon l'ARP 4754A
Exemple : les règles d'allocation des DAL selon l'ARP 4754A

Les règles d’allocation précisent que si un ensemble de fonctions sont les causes possibles d’une défaillance catastrophique, alors le niveau d’assurance qualité de chacune des fonctions qui contribuent à l’événement catastrophique, doit être au moins C. Cela peut être d’un niveau d’assurance qualité A, B ou C.

Seconde contrainte : parmi les combinaisons de fonctions qui amènent à la défaillance, il faut absolument que l’on ait, soit au moins une fonction de niveau A, le plus haut, ou alors deux fonctions de niveau « B ». Il faut veiller cependant à ce que la défaillance des fonctions de niveau « B » soient totalement indépendantes, c'est-à-dire ségréguées, comme les fonctions de niveau « B ». Donc la règle empirique, quelque part, c’est qu'un « A » va valoir deux « B », à condition que les deux « B » soient indépendants.

Processus d’évaluation de la sécurité

Nous avons vu comment identifier les exigences de sécurité, comment vérifier avec des pratiques en vigueur que ces activités-là s’inscrivent tout au long du processus d’évaluation de la sécurité des systèmes. Dans un premier temps, il faut spécifier le système et concevoir petit à petit les exigences. Une fois que l’on a conçu toutes les exigences du système, on produit les composants physiques élémentaires et on les intègre. Puis on vérifie que, progressivement, les exigences sont tenues tout d’abord sur les composants les plus élémentaires, puis préservées dans l’intégration des composants.

En résumé

Nous espérons vous avoir convaincu que les principes d’analyse de la sécurité des systèmes sont simples ! Nous avons essayé de vous montrer que l’on a des réglementations et des guides pour cadrer l’application des principes qui sont tout de même assez généraux pour vous guider dans l’application. Nous avons aussi besoin d’outils mathématiques pour faire des calculs sur des bases rigoureuses et pour automatiser les calculs.

Enfin, ces méthodes et outils sont utilisés tout au long du processus de conception du système. Cela peut être lourd d’utiliser ces techniques et on peut rater des choses... Il est donc important de les utiliser avec bon sens, en exploitant sa connaissances des systèmes, et de le faire progressivement tout au long du processus de conception. La conception est un pas important pour garantir que le système va être sûr, mais il faut plus tard, en opération, réitérer ces analyses pour s’assurer qu’on reste en opération.

Voyons à présent de plus près quelles sont les exigences liées à la certification des logiciels embarqués en aéronautique...

Exemple de certificat de réussite
Exemple de certificat de réussite