Soutenance mémoire
Sûreté de fonctionnement et architecture embarquée
Les systèmes embarqués avioniques comprennent l’ensemble des équipements (électronique, électrique et informatique) permettant de contrôler un avion. Ces équipements, tels que les instruments de navigation ou les systèmes de communication, peuvent, en cas de dysfonctionnement, porter atteinte à la sécurité des passagers. Cette notion de « sécurité » fait partie intégrante du domaine de la sûreté de fonctionnement que nous présentons dans ce chapitre. Dans un premier temps et afin de faciliter la lecture, nous introduirons une partie du vocabulaire, en considérant les concepts et la terminologie introduits dans le « Guide de la Sûreté de Fonctionnement » [Laprie et al. 1996] et mis à jour dans [Avizienis et al. 2004]. Plus précisément, nous commençons par définir les notions de sûreté de fonctionnement, pour ainsi situer nos travaux par rapport au thème et aux moyens classiques de la sûreté de fonctionnement en général, et de la sécurité informatique en particulier. Dans un second temps, nous présentons une architecture utilisée dans la conception des systèmes embarqués et les normes mises en œuvre pour assurer les propriétés de sécurité .
Sûreté de fonctionnement : notions et taxinomie
La sûreté de fonctionnement d’un système informatique est, selon [Laprie et al. 1996], [Avizienis et al. 2004], l’aptitude à délivrer un service avec un niveau de confiance justifiée. Ce service délivré par un système est son comportement tel qu’il est perçu par son ou ses utilisateurs, l’utilisateur étant un autre système, humain ou non. La sûreté de fonctionnement informatique comporte trois principaux volets : les attributs qui la décrivent, les entraves qui nuisent à sa réalisation et les moyens de l’atteindre .
Attributs
La sûreté de fonctionnement d’un système peut être perçue selon différentes propriétés. Ces propriétés sont appelées les attributs de la sûreté de fonctionnement. Les attributs à considérer dépendent des applications auxquelles le système est destiné. Ces attributs sont au nombre de six :
• La disponibilité : aptitude du système à être prêt à l’utilisation ;
• La fiabilité : continuité du service ;
• La sécurité-innocuité : absence de conséquences catastrophiques pour l’environnement ;
• La confidentialité : absence de divulgations non autorisées de l’information ;
• L’intégrité : absence d’altérations inappropriées de l’information ;
• La maintenabilité : aptitude aux réparations et aux évolutions.
Ces attributs peuvent être combinés pour aboutir à un nouvel attribut. Par exemple, la confidentialité, l’intégrité et de la disponibilité se combinent pour aboutir à la sécuritéimmunité.
Entraves
Une entrave à la sûreté de fonctionnement est une circonstance indésirable, mais non inattendue. Elle est la cause ou le résultat de la non-sûreté de fonctionnement. Nous en distinguons trois sortes : les défaillances, les erreurs et les fautes. Une défaillance survient lorsque le service délivré par le système s’éloigne de l’accomplissement de la fonction du système. Néanmoins, un système ne défaille pas toujours de la même manière, ce qui conduit à définir la notion de mode de défaillance qui peut être caractérisé selon trois points de vues : domaine de défaillance, conséquence des défaillances sur l’environnement du système et perception des défaillances par les utilisateurs du système.
Le domaine de défaillance est divisé en deux catégories :
• Les défaillances en valeur : la valeur du service délivré ne permet plus l’accomplissement de la fonction du système ;
• Les défaillances temporelles : le service n’étant pas délivré dans le temps imparti, la fonction du système ne peut pas être accomplie. Les conséquences des défaillances conduisent à distinguer :
• Les défaillances bénignes, dont les conséquences sont du même ordre de grandeur que le bénéfice procuré par le service délivré en l’absence de défaillance;
• Les défaillances catastrophiques, dont les conséquences sont infiniment différentes du bénéfice procuré par le service délivré en l’absence de défaillance.
Lorsqu’un système a plusieurs utilisateurs, la perception des défaillances conduit à distinguer :
• Les défaillances cohérentes : tous les utilisateurs du système ont la même perception du service délivré ;
• Les défaillances incohérentes : les utilisateurs du système peuvent avoir des perceptions différentes des défaillances ; les défaillances incohérentes sont souvent qualifiées de défaillances byzantines.
La gravité de la défaillance d’un composant définit son niveau de criticité, et par conséquent fixe les exigences de développement qui sont requises.
Les erreurs sont le deuxième type d’entraves à la sûreté de fonctionnement. Une erreur est la partie de l’état du système susceptible d’entraîner une défaillance : une erreur affectant le service est une indication qu’une défaillance survient ou est survenue. Une erreur peut être latente ou détectée ; une erreur est latente tant qu’elle n’a pas été reconnue en tant que telle ; une erreur est détectée par un algorithme ou un mécanisme de détection. Une erreur peut disparaître sans être détectée.
Une faute est la cause adjugée ou supposée d’une erreur. Les fautes sont de nature extrêmement diverses et peuvent être classées selon cinq points de vue : leur cause phénoménologique (fautes physiques ou fautes dues à l’homme), leur nature (fautes accidentelles ou fautes délibérées), leur phase de création ou d’occurrence (fautes de développement ou fautes opérationnelles), leur situation par rapport aux frontières du système (fautes internes ou externes) et leur persistance (fautes permanentes ou fautes temporaires).
Une faute est active lorsqu’elle produit une erreur. Une faute active est soit une faute interne, qui était préalablement dormante et qui a été activée par le processus de traitement, soit une faute externe. Une faute interne peut changer de nature, et ainsi passer d’un état dormant à actif et inversement. Par propagation, une erreur crée de nouvelles erreurs. Une défaillance survient lorsque, par propagation, une erreur affecte le service délivré par le système. Cette défaillance peut alors apparaître comme une faute du point de vue d’un autre composant. On obtient ainsi la chaîne fondamentale suivante :
… → défaillance → faute → erreur → défaillance → faute → …
Les flèches dans cette chaîne expriment la relation de causalité entre fautes, erreurs et défaillances. Elles ne doivent pas être interprétées au sens strict ; par propagation, plusieurs erreurs peuvent être créées avant qu’une défaillance ne survienne. Pour minimiser l’impact de ces entraves sur les attributs retenus d’un système, la sûreté de fonctionnement dispose de moyens.
Moyens
Ces moyens sont les méthodes et techniques qui permettent de conforter les utilisateurs quant au bon accomplissement de la fonction du système. Ces moyens peuvent être utilisés simultanément lors de la phase de conception et développement d’un système sûr de fonctionnement. Ils sont classés suivant l’objectif visé :
• La prévention : empêcher l’occurrence ou l’introduction de fautes.
• La tolérance : fournir un service qui remplit la fonction du système en dépit des fautes.
• L’élimination : réduire la présence (nombre, sévérité) des fautes.
• La prévision : estimer la présence, la création et les conséquences des fautes.
Ces moyens sont complémentaires, dépendants et doivent être utilisés de façon combinée. En effet, en dépit de la prévention des fautes grâce à des méthodes de conception et à des règles de construction rigoureuses, des erreurs surviennent, résultant en des fautes. D’où le rôle de l’élimination des fautes : lorsqu’une erreur est révélée durant la vérification, un diagnostic est entrepris afin de déterminer la, ou les fautes causes de l’erreur, en vuede les éliminer. Cette élimination étant elle même imparfaite, il est également nécessaire d’effectuer de la prévision de fautes. Et, bien entendu, la dépendance croissante que nous avons dans les systèmes informatiques conduit à mettre en œuvre de la tolérance aux fautes.
Dans le cadre de nos travaux, nous nous intéressons essentiellement à la tolérance aux fautes. Nous partons donc de l’hypothèse que des fautes peuvent toujours exister et se manifester, et faisons en sorte que les architectures que nous étudions soient robustes visà-vis ces fautes. Nous proposons de détailler dans ce qui suit la tolérance aux fautes, et plus particuli`rement la notion de redondance, qui est un principe essentiel de la tolérance aux fautes. En effet, pour décider de la validité d’un état ou non (et par conséquent détecter une erreur), il faut disposer d’un critère permettant d’effectuer ce processus de décision. Le critère peut prendre la forme d’un autre état représentant la même information, ou la forme d’une valeur de référence à comparer avec la valeur observée. Cependant, quelle que soit la nature de ce critère, ce dernier doit contenir une information permettant de valider l’état en question, et cette information est toujours une forme de redondance de l’état contrôlé.
|
Table des matières
Introduction
Contexte général
Structure du document
I Sûreté de fonctionnement et architecture embarquée
Introduction
I.1 Sûreté de fonctionnement : notions et taxinomie
I.1.1 Attributs
I.1.2 Entraves
I.1.3 Moyens
I.2 Tolérance aux fautes
I.2.1 Mécanismes de détection
I.2.2 Mécanismes de recouvrement
I.2.3 Tolérance aux fautes malveillantes
I.3 Système avionique
I.3.1 Normes et standards pour l’avionique embarquée
I.3.2 Architectures avioniques
I.3.3 Sécurité-immunité pour l’avionique
I.3.4 Modèle Totel
Conclusion
II Équipements mobiles pour systèmes avioniques
Introduction
II.1 Équipements mobiles
II.2 Scénario de maintenance et son évolution
II.2.1 Maintenance classique
II.2.2 Maintenance avec support électronique
II.3 Problème soulevé
II.4 Architecture logicielle de l’équipement
II.4.1 Modèle Totel et redondance
II.4.2 Présentation de l’architecture logicielle
II.4.3 Utilisation des traces d’exécution pour comparaison
II.5 Proposition d’amélioration de l’architecture logicielle
Conclusion
IIIDétection d’erreurs par analyse comportementale
Introduction
III.1 Axe de développement de l’architecture
III.2 Principe de la détection à l’exécution
III.3 Modèle d’exécution
III.3.1 Description des interactions observées
III.3.2 Construction du modèle d’exécution
III.3.3 Utilisation du modèle
III.4 Instrumentation automatique de l’application
III.5 Complémentarité des méthodes de comparaison
Conclusion
IV Virtualisation : définition et expérimentation
Introduction
IV.1 Types et techniques de virtualisation
IV.1.1 Types de virtualisation
IV.1.2 Moyens techniques d’aide à la virtualisation
IV.2 Évaluation des performances d’un hyperviseur
IV.2.1 Critères considérés pour la présélection des hyperviseurs
IV.2.2 Présentation des hyperviseurs sélectionnés
IV.2.3 Évaluation
IV.2.4 Analyse des résultats
Conclusion
V Conception et développement
Introduction
V.1 Contexte d’utilisation
V.1.1 Détail de l’architecture logicielle du PMAT
V.1.2 Description et utilisation de l’application de maintenance
V.1.3 Installation et expérimentation du démonstrateur GEODESIE
Conclusion
Conclusion
