l’analyse des risques de niveau avion.

Parmi ces exigences, certaines ont été émises par des experts opérationnels en sécurité à partir d’analyses de risques. Cette application permet de vérifier l'intérêt des modèles proposés aux analystes opérationnels en sécurité.

Les principes de la sûreté de fonctionnement

Avant de présenter les analyses de sécurité réalisées lors de la conception de l'avion, nous définissons dès la section 2 la sécurité opérationnelle et les concepts sur lesquels elle repose. En fonction des risques que l'on souhaite contrôler sur un système donné, on peut s'intéresser à différents aspects, sans lien entre eux, de la sécurité opérationnelle, notamment principalement.

Importance de la sécurité dans l'aéronautique

ARP4754A / ED-79A] : Ce document fournit des recommandations sur les processus permettant d'assurer la sécurité des aéronefs lors de la conception. Le reste du chapitre 1 s'appuie largement sur le document [ARP4754A / ED-79A] pour présenter le processus d'analyse de la sécurité des avions en développement tel qu'appliqué par Airbus.

Fig. 1.2 - Évolution du taux d'accident mortel dans le transport aérien (Source : EASA)

Le processus de la conception et de la sécurité

Dans la phase descendante du cycle en V, la conception représente la définition des architectures de l'avion, puis de ses systèmes, jusqu'à une spécification précise de tous les équipements qui composent l'ensemble des systèmes de l'avion. Ce processus suit un cycle en forme de V, très similaire à celui de la conception (voir Figure 1.4).

Fig. 1.5 - Processus de sécurité réalisé lors de la conception d'un avion

Activités du processus de sécurité

Il s'agit d'activités proches des analyses préliminaires mais qui diffèrent dans leurs intentions : tandis que le PASA/PSSA assiste la conception, l'ASA/SSA vise à vérifier enfin les architectures tant sur les aspects qualitatifs que quantitatifs des exigences. Cette activité est l’analyse préliminaire des risques (PRA), également appelée analyse préliminaire des risques (PHA).

Présentation générale de l'analyse des risques

Historiquement, l'identification des risques était réalisée dès les premiers processus de sécurité, à partir de listes d'erreurs survenues sur les appareils en fonctionnement. Les résultats de l'analyse des risques sont consignés dans des tableaux sous la forme du tableau 1.1.

Étude des scénarios de pannes fonctionnelles

Le tableau 1.3 est un exemple d'application de ces principes avec une perte totale de la fonction de contrôle de trajectoire au sol comme scénario de défaillance. La deuxième hypothèse concerne les moyens de détection de la perte de contrôle de la direction.

Fig. 1.6 - Scénario de vol simple du décollage à l'atterrissage

Identification des exigences de sécurité

Pour le scénario d'échec concernant la perte totale de contrôle sur l'orbite terrestre, nous dérivons un FC qui profite du fait que ce scénario est classé comme catastrophique. L'objectif quantitatif lié au CF ne permet donc pas de définir un degré de rigueur dans la conception.

Axes d'amélioration de l'analyse des risques

Les modèles de pannes dans AADL ont l’avantage d’être directement dérivés des modèles de conception.

Modélisation, métamodélisation

La construction du modèle doit alors respecter des contraintes de modélisation, formant un langage de modélisation. Les langages de modélisation dédiés (DSML pour « Domain Specific Modeling Language ») sont comme leur nom l'indique des langages de modélisation propres à chaque métier ([Spinellis 2001], [Taha 2008], [Jézéquel et al. 2012]).

Fig. 2.1 - Pyramide de modélisation de l'OMG

Transformation de modèle

Mac* est un ensemble de mappages d'une syntaxe abstraite à n'importe quelle syntaxe concrète ; – SD* est un ensemble de domaines sémantiques. Une transformation de modèle est horizontale si les modèles source et cible sont au même niveau d'abstraction.

Fig. 2.2 - Génération de modèle, conformément au MOF

Express, un langage pour la modélisation et la transformation de modèle

Dans la section 3.1, nous introduisons les concepts généraux de modélisation des architectures opérationnelles et fonctionnelles des systèmes socio-techniques. La section 3.2 présente le diagramme d'activités qui est aujourd'hui la syntaxe concrète la plus utilisée chez différents constructeurs dans le domaine de la modélisation d'architecture fonctionnelle.

Des modèles d'architectures opérationnelles et fonctionnelles

Langage de modélisation des architectures fonctionnelles – les diagrammes d'activités

Enfin, la section 4 présente les méthodes et outils de modélisation utilisés dans le contexte de la sécurité opérationnelle. Comprendre les dépendances fonctionnelles est la problématique fondamentale des phases d’avant-conception et des modèles A.O.F.

Les modèles A.O.F. chez Airbus

La figure 2.6 présente les différentes composantes de la description opérationnelle et fonctionnelle du projet ALFA. L'un de ces deux objectifs de vol se retrouve dans l'exemple de la figure 2.9 concernant le contrôle de la trajectoire au décollage.

Fig. 2.6 - Périmètre de description opérationnelle et fonctionnelle du projet ALFA

Apports et insuffisances des modèles ALFA pour l'analyse des risques

Nous avons trouvé deux limitations : une limitation dans la description des fonctions et une limitation dans la description de la propagation des défauts fonctionnels. Les modèles de conception étant jugés insuffisants pour faciliter les analyses de risques (voir la section 3.4), les analystes doivent se tourner vers d'autres techniques de modélisation.

Fig. 2.11 - Succession fonctionnelle et fonctionnement parallèle

Les modèles des pannes

Le concept fondamental des arbres de défaillances est de représenter le comportement erroné d'un système dans un modèle logique. L'utilisation d'arbres de défaillances présente l'avantage d'être facilement compris par divers utilisateurs et pas seulement par les analystes de sécurité.

Les modèles d'architectures dysfonctionnelles

L'approche MBSA actuellement utilisée par Airbus, ainsi que par d'autres constructeurs, est représentée en rouge sur la figure 2.15. L'approche MBSA est de plus en plus associée aux approches de formalisation typiques de la planification (en vert sur la figure 2.15).

Fig. 2.15 - L'approche « Model-Based Safety Assessment » (MBSA)

Le langage formel AltaRica

Définition : La sémantique du langage AltaRica (automate de mode) Un modèle AltaRica est un automate de mode, défini par le 7-tuple. Variables de flux : La déclaration des variables de flux commence par le mot-clé flow.

Comparaison du langage AltaRica avec d'autres langages de modélisation

La définition de la sémantique des modèles MBFHA, amorcée dans la section précédente, présente deux problématiques principales. La notion de recherche des causes des situations redoutées est présentée dans la section 4.3 du chapitre 4.

Tab. 2.12 - Évaluation des langages de modélisation de la sécurité des systèmes

La problématique de notre étude

Dans le chapitre 1 nous avons montré dans la section 3.4 que l'analyse des risques est une étape du processus de sûreté qui peut être optimisée, notamment au niveau du format des majuscules des données de l'analyse et en relation avec la complexité des systèmes aéronautiques. Parce que les analystes de sécurité d'Airbus connaissent ces avantages, Airbus a souhaité mettre en œuvre une approche similaire à l'approche MBSA pour faciliter les analyses de risques.

Les objectifs pour une analyse des risques basée sur les modèles

Les applications produites dans nos travaux s'appuient sur les outils CORE et SysML pour la conception des modèles ALFA et sur le langage AltaRica pour les modèles de sécurité. La traçabilité prend tout son sens avec les techniques de modélisation que nous utilisons pour formaliser la passerelle entre les modèles ALFA et nos modèles de sécurité.

Fig. 3.1 - Liens entre les modèles de conception et les modèles de sécurité

Description détaillée de l'approche

La première étape : transformation de l'architecture opérationnelle et fonctionnelle concrète dans le sens du modèle propre à ALFA. Ce dernier intègre les concepts du modèle ALFA en y ajoutant des informations de sécurité.

Notre approche au regard des exigences

Nous proposons une formalisation de modèles dégradés basée sur ces valeurs d'efficacité et montrons que ces modèles permettent l'étude des perturbations fonctionnelles. La section 2 de ce chapitre présente les principes de la sémantique de couche nominale des modèles de sécurité, en omettant la modélisation des fautes.

La syntaxe abstraite de la couche nominale des modèles de sécurité

Mais comme nous l'avons vu dans la section 3.4 du chapitre 2, les modèles MALFA ne fournissent pas une formalisation suffisamment riche des dépendances fonctionnelles pour l'étude des défaillances fonctionnelles. Le chapitre 3 présente les concepts qui permettent d'étudier les activités dégradées par des défauts ou des conditions environnementales.

Tab. 4.1 - Entités des modèles de sécurité et de leurs liens en Express

Introduction de la sémantique de la couche nominale des modèles de sécurité

La propagation des liens à travers chaque activité a ∈ WetMBFHA est formellement définie par la constitution. La sémantique de nos modèles de sécurité est construite sur la base des trois lois de comportement présentées dans la section 2.2.2.

Définition du domaine des valeurs

Cependant, à basse vitesse, le service rendu par le gouvernail contribue bien plus au contrôle de trajectoire que la direction aérodynamique. Dans le cas où cette objection est considérée comme maximale, l’efficacité des données en résulte.

Détails sur la sémantique des données et des conditions environnementales

Il ne nous est pas possible de définir la loi d'agrégation des services au sein des données dans le cadre général. Dans le cas particulier E ℝ, la sémantique des données est définie par : Définition : Loi de comportement des données.

Détails sur la sémantique des activités

Soit valn : ActMBFHA → E la valeur représentant l'agrégation des données requises, définie pour tout a ∈ ActMBFHA par. Soit valu : ActMBFHA → E la valeur représentant l'agrégation des données utiles, définie pour tout a∈ActMBFHA par.

Fig. 4.3 - État d'activation d'une activité

Impacts des pannes fonctionnelles sur le comportement des fonctions

Au niveau sémantique, la prise en compte des défaillances modifie clairement la loi de comportement des fonctions. La section 3 du chapitre 1 a montré que la manière de décrire les défaillances au niveau de la couche fonctionnelle consiste à étudier les modes de défaillance fonctionnelle (perte totale, perte partielle, fonctionnement défectueux et faux fonctionnement).

Tab. 4.5 - Entité Express représentant les fonctions des modèles de sécuritéFig. 4.4 - Impact de pannes fonctionnelles sur une fonction

Effets des pannes fonctionnelles sur les services des fonctions

Dans ce cas, la fonction service a une performance négative évidente par rapport au résultat « chemin contrôlé ». Lors du décollage, fonctionnement intempestif de la fonction de commande des freins de roue.

Tab. 4.7 - Modélisation de la perte partielle d'une fonction

Lien entre la modélisation et les analyses

Le choix des situations redoutées perçues est donc laissé aux analystes de sécurité chargés de l’analyse des risques. Nous pouvons identifier des défaillances fonctionnelles de la fonction Steering Wheel Guidance pouvant conduire à un arrêt du décollage, et analyser les conséquences de ces défaillances fonctionnelles lors de la phase d'arrêt du décollage.

Calcul des conséquences des pannes fonctionnelles

Pour la première phase de vol, la situation redoutée choisie correspond aux conditions conduisant à la deuxième phase de vol. En effet, par définition, les résultats d'un modèle sont les taux de réussite des objectifs à atteindre lors de la phase de vol considérée.

Calcul des causes de situations redoutées

Avec le model check, toutes les situations peuvent être automatiquement testées à partir d’une situation initiale. Ainsi, il est possible de dresser une liste de toutes les combinaisons de dysfonctionnements et de conditions environnementales qui suscitent la peur.

Comparaison avec d'autres approches

Ces combinaisons sont les causes de la situation effrayante, dite aussi « implicite » (voir section 4.1.1 du chapitre 2). D'où notre intérêt à appliquer cette approche basée sur la recherche des causes des situations effrayantes dans nos modèles.

Critiques sur l'approximation lors de l'agrégation des données utiles et nécessaires

Le poids des données pourrait être une caractéristique mise en avant dans les approches futures. Du fait des valeurs agrégées, le poids des données varie d’une fonction à l’autre de manière incontrôlée.

Perspective : liens avec d'autres modèle de sécurité

Nous rappelons, selon la section 2.2 du chapitre 4, que les nœuds dans les modèles d'analyse des aspects dysfonctionnels ont une sémantique de forme. Nous avons montré dans la section 1.1 que les concepts des modèles de sécurité respectent la sémantique du langage AltaRica en ce qui concerne la déclaration et l'évaluation des variables.

Les variables du modèle de sécurité

Dans cette section, nous montrons la correspondance entre ces variables conceptuelles et les variables sémantiques d'AltaRica. Dans la sémantique AltaRica, les variables d'entrée et de sortie sont définies comme des interfaces de nœud et de modèle.

Les assertions du modèle de sécurité

Nous proposons ensuite d'enrichir les concepts de modèles de sécurité en utilisant une meilleure expression des états internes des nœuds (éléments de S). Une fois la compatibilité des modèles de sécurité avec la sémantique du langage AltaRica établie, nous nous intéressons à la modélisation syntaxique.

Domaine des valeurs en AltaRica

En termes de modélisation de l'efficacité, nous n'utilisons pas la modélisation du pouvoir environnemental par Penv=ℝ+, comme nous l'avons proposé comme première approche au chapitre 4. Une telle modélisation serait difficile à interpréter pour les concepteurs et les analystes de la sécurité.

Tab. 5.1 - Codes AltaRica et Express de l'ensemble des valeurs d'efficacité

Modélisation des nœuds « Donnée » et « Environnement »

L'icône sur le côté gauche de la figure 5.3 représente une valeur nulle, c'est-à-dire l'absence de condition environnementale. Dans le code du tableau 5.5, nous avons décrit l'absence d'état environnemental dans l'état initial.

Tab. 5.4 - Code AltaRica des données à deux services entrants

Modélisation des activités

La valeur du service principal provient des propriétés logiques des valeurs agrégées et de l'état interne de la fonction. Si l'efficacité de leur service principal est élevée (c'est-à-dire « Élevée »), les fonctions sont affichées avec deux barres horizontales (voir Figure 5.5).

Tab. 5.6 - Code AltaRica des valeurs d'entrée des activités et de leur agrégation

Représentation du modèle global

Calcul de la situation – la trajectoire contrôlée est inférieure ou égale au seuil situation_redoutee =(traj_contr = Hneg OR traj_contr = Lneg OR traj_contr = None);. La recherche des conséquences d'un scénario de défaillance fait l'objet de la section 3.1 et s'appuie sur le simulateur.

Tab. 5.10 - Code AltaRica d'un observateur sur le contrôle de la trajectoire

Simulation des modèles de sécurité

Sélectionnez un événement : après calcul de la situation initiale, le simulateur permet de déclencher des événements à partir d'une liste mise à disposition par le simulateur. Le simulateur offre la possibilité de charger un tel fichier de sauvegarde pour rejouer une campagne de simulation.

Fig. 5.8 - Simulation : situation nominale du modèle

Recherche de causes de situations redoutées en AltaRica

Sélection des séquences sélectionnées : l'outil dispose de plusieurs algorithmes pour rechercher des séquences d'événements conduisant à la situation effrayante sélectionnée. Format de stockage des séquences : en sélectionnant le point 3, l'outil identifie toutes les séquences d'événements conduisant à la situation redoutée.

Étude de la granularité de l'efficacité

Une telle modélisation a pour effet de limiter fortement la présence de conditions environnementales dans les coupes minimales d'ordre 1 ou d'ordre 2. Le tableau 5.13 montre le nombre de coupes minimales de chaque ordre pour le cas complet avec ou sans conditions environnementales.

Tab. 5.12 - Nombre des coupes minimales jusqu'à l'ordre 3 pour différents modèles

Bilan

Perspectives sur la concrétisation des modèles de sécurité

Le tableau 6.5 montre la prise en compte de l'annotation comme entrée dans la transformation du modèle. Théoriquement, ce rôle incombe aux analystes de sécurité afin qu'ils puissent gérer les données de sécurité et piloter la transformation du modèle.

Fig. 6.1 - Application de la transformation de modèle par métamodélisation

Définition des règles de transformation

Le tableau ci-dessous présente la procédure de transformation du modèle qui se concentre plus spécifiquement sur les fonctionnalités du modèle source. Avec de nombreux tests comme celui-ci, il est possible d’avoir une grande confiance dans la transformation du modèle.

Tab. 6.1 - Entité de la transformation de modèle (génération du modèle cible)

Annotation des modèles sources

Produire un modèle d'annotation : la deuxième approche est que la transformation du modèle s'appuie sur un modèle d'annotation en plus du modèle source. Dans ce cas, le modèle annoté remplace le modèle source dans la transformation du modèle.

Tab. 6.5 - Entité de la transformation de modèle (avec le modèle d'annotation)

Traçabilité dans la transformation de modèle

Un exemple de métamodèle dans le tableau 6.6 est un modèle d'annotation qui décrit, par exemple, une annotation sur diverses fonctions du modèle source. Un exemple de ce métamodèle est par exemple la piste de transformation de la fonction « Aérodynamiquement Guidé ».

Tab. 6.8 - Entité de la transformation de modèle (avec le modèle des traces)

Transformation des concepts

Le nœud représentant cette fonction dans les modèles de contrôle de trajectoire ALFA est stocké en tant que nœud source. Évidemment, la notation des modes de défaillance pertinents dans les fonctions doit être effectuée par un expert en sécurité.

La concrétisation des modèles de sécurité en AltaRica

Les interfaces sont divisées en deux sous-entités : les interfaces d'entrée et les interfaces de sortie, qui correspondent aux variables de nœud d'entrée et de sortie dans la sémantique AltaRica. Le tableau 6.17 illustre une telle méthode pour la somme tronquée des variables d'entrée des nœuds de type "Données".