Soutenance mémoire
Le domaine du transport aérien est historiquement lié à la notion de sécurité des passagers. Cette contrainte de sécurité a conduit à des exigences de conception et de construction des appareils de manière à ce que ce moyen de transport soit au moins aussi sûr que les autres moyens de transport en commun classiques (par exemple, le ferroviaire) Les moyens de transport font partie d’une famille de systèmes considérés comme des systèmes critiques (au même titre que les centrales nucléaires, par exemple). La notion de criticité est liée à la gravité des conséquences d’une défaillance affectant le système. Ainsi, un train est considéré comme système critique parce qu’en cas de défaillance, les conséquences peuvent entraîner des pertes de vies humaines, ce qui correspond à un événement catastrophique. Il en est clairement de même pour un avion.
Un système avionique est donc un système critique qui doit répondre aux exigences de sécurité requise par de tels domaines d’application. Par sécurité, nous désignons ici la sécurité des passagers (donc sécurité au sens safety, ou encore sécurité innocuité). Cependant, depuis quelques années, une nouvelle contrainte de sécurité s’est imposée dans le monde avionique : la sécurité au sens immunité (connue par le terme security). En effet, depuis l’apparition des premiers systèmes de commande de vol électrique (CDVE) dans les années 1980, les entités logicielles à bord sont de plus en plus présentes. L’intégration de composants logiciels de différent niveaux de criticité et de plus en plus complexes (y compris des composants sur étagères ou COTS) et l’ouverture des systèmes bord vers d’autres systèmes (par exemple, communications numériques) induisent des risques liés non seulement aux fautes accidentelles (bugs) pouvant affecter ces logiciels, mais aussi à l’exploitation de vulnérabilités potentielles par des actes malveillants.
APPLICATIONS AVIONIQUES : ETAT DE L’ART
Le processus d’évaluation de la sécurité d’un appareil a pour but de vérifier la conformité de la conception avec les exigences de navigabilité spécifiées par les autorités . Chaque constructeur apporte ses propres directives allant souvent au-delà de ces exigences de sécurité (exemple ADB d’Airbus Directives chez le constructeur Airbus). Des recommandations ou des normes internationales ont été émises pour rendre standards ces exigences. Nous proposons dans cette section de présenter les standards avioniques liés à la sécurité-innocuité (ARP 4754, DO-178B) et ensuite les nouvelles architectures modulaires émergentes dans l’avionique (IMA, ARINC 653). Nous présenterons ensuite les contraintes de sécuritéimmunité (ARINC 811) liées aussi bien au déploiement de telles architectures mais également à l’interfaçage des applications avioniques avec le monde ouvert.
Standards avioniques pour la sécurité-innocuité
La principale norme qui a guidé le développement des systèmes avioniques sûrs (au sens safety) est la norme ARP 4754. Elle concerne la notion de sécurité dans les systèmes avioniques complexes, et de cette norme ont découlé diverses normes et recommandations pour le développement avionique .
La norme ARP 4754 concerne tout le processus de développement des systèmes avioniques complexes. Par système, cette norme désigne un ensemble de fonctions avioniques, basées en grande partie sur des entités logicielles, et nécessitant une forte interaction les unes avec les autres. Pour le développement de tels systèmes, on distingue entre le processus de développement d’applications logicielles et du matériel. Ainsi, la DO-178B [DO178-B 1992] propose des recommandations pour le développement des logiciels, et la DO-254 [DO-254 2000] est lié au matériel. Afin d’évaluer le processus de développement d’un point de vue sécurité-innocuité, des recommandations ont été émises dans la norme ARP 4761 [ARP 4761 ]. Nous proposons de détailler les aspects liés à l’évaluation de la sécurité-innocuité dans les systèmes avioniques (ARP 4754), puis lors du processus de développement logiciel (DO178B).
Sécurité des systèmes avioniques : ARP 4754
Le processus d’évaluation de la sécurité tel qu’il est décrit dans cette norme comprend la génération, la mise à jour et la vérification d’exigences en parallèle avec des activités de développement de l’avion. Il fournit une méthodologie pour évaluer les fonctions de l’avion et la conception des systèmes qui remplissent ces fonctions, afin de déterminer si les risques associés ont bien été pris en compte. Le processus d’évaluation de la sécurité est qualitatif et quantitatif. Le processus doit être planifié et supervisé pour fournir l’assurance nécessaire que toutes les conditions de défaillances (Failure Condition : FC) aient été identifiées et que toutes les combinaisons significatives de ces conditions aient été considérées. Ce processus d’évaluation de la sécurité pour des systèmes intégrés doit tenir compte de toute complexité ou interdépendance complémentaire qui surgit en raison de l’intégration. Dans tous les cas impliquant des systèmes intégrés, le processus d’évaluation de la sécurité a une importance fondamentale pour établir les objectifs de sécurité appropriés pour le système et déterminer si la mise en oeuvre les satisfait.
L’évaluation de la sécurité se décompose en quatre étapes :
• évaluation des risques fonctionnels (Functional Hazard Assessment : FHA) : cette évaluation concerne les fonctions avion et système afin de déterminer les défaillances fonctionnelles possibles et classifier les risques associés à des conditions de défaillances spécifiques.
• évaluation préliminaire de la sécurité des systèmes (Preliminary System Safety Assessment : PSSA) : cette étape établit les exigences de sécurité spécifiques aux systèmes et aux composants des systèmes et fournit une première évaluation de la conformité de l’architecture avec les exigences de sécurité à satisfaire. La PSSA est mise à jour tout au long du processus de développement de chaque système.
• évaluation de la sécurité des systèmes (System Safety Assessment : SSA) : la SSA vérifie que le système implémenté satisfait aux exigences formulées dans la FHA et la PSSA.
• analyse des causes communes (Common Cause Analysis : CCA) : complément des FHA, PSSA, SSA, la CCA permet de minimiser les risques liés à des causes communes au système ou à plusieurs systèmes ; elles concernent entre autres les aspects : installation des systèmes, facteurs humains…
Evaluation des risques fonctionnels (FHA)
Une FHA correspond à un examen complet systématique des fonctions afin d’identifier et de classifier les défaillances de ces fonctions selon leur sévérité. Il existe deux types de FHA : la FHA avion (Aircraft Level FHA) et la FHA système (System Level FHA). La FHA avion est une étude de haut niveau, une évaluation qualitative des fonctions principales de l’avion définies au début du développement de l’appareil. Une FHA avion identifie et classifie les conditions de défaillances (FC) associées aux fonctions de niveau avion. La classification de toutes ces FC définit les exigences de sécurité que doit satisfaire l’avion. La FHA système est également une évaluation qualitative. Elle est conduite de façon itérative de manière à ce que cette évaluation soit de plus en plus précise au fur et à mesure que les fonctions de l’avion évoluent. La FHA système est liée à une défaillance ou une combinaison de défaillances qui affectent les fonctions du système puis de l’avion. Lorsque les fonctions de l’appareil ont été affectées à des systèmes par le processus de conception, chaque système fait l’objet d’une FHA système.
Evaluation préliminaire de la sécurité des systèmes (PSSA)
Une PSSA sert à démontrer comment le système est susceptible de satisfaire aux exigences, qualitatives et quantitatives, relatives aux différents risques identifiés. La PSSA sert également à compléter la liste de FC et les exigences de sécurité correspondantes. La PSSA identifie les moyens utilisés permettant d’atteindre les objectifs de sécurité. Cette analyse identifie et recense toutes les exigences de sécurité système dérivées (par ex : l’autotest, les tâches à accomplir,…). La PSSA constitue une analyse itérative dans la continuité des FHA. Elle permet aussi d’allouer au niveau équipement les exigences sécurité du niveau système. Pratiquement, il s’agit d’identifier les fautes qui contribuent aux FC recensées dans la FHA système en utilisant des arbres de fautes ou des diagrammes de dépendance. Le calcul de probabilité d’une FC diffère selon que les défaillances sont ou non cachées. Par exemple, le temps durant lequel un équipement de secours peut défaillir ou être défaillant avant d’être détecté et réparé doit être considéré. Dans de nombreux cas, les défaillances sont décelées par l’équipage : soit par observation directe, soit par des tests. Dans certains cas, la latence de détection est associée à l’intervalle de temps entre tests de l’équipement en atelier ou entre tâches de maintenance avion. Ces tâches et intervalles de temps sont identifiés durant la PSSA et vérifiés durant la SSA, en utilisant des arbres de fautes ou des diagrammes de dépendance.
|
Table des matières
Chapitre I Introduction Générale
Chapitre II Avionique et Tolérance aux Fautes : Etat de l’Art
Introduction
II.1 Applications avioniques : état de l’art
II.1.1 Standards avioniques pour la sécurité-innocuité
II.1.1.1 Sécurité des systèmes avioniques : ARP 4754
Evaluation des risques fonctionnels (FHA)
Evaluation préliminaire de la sécurité des systèmes (PSSA)
Evaluation de la sécurité des systèmes (SSA)
II.1.1.2 Sécurité des entités logicielles en avionique DO-178B
II.1.1.3 Considérations pour la diversification des logiciels selon la DO-178B
II.1.2 Architectures IMA
II.1.2.1 Systèmes avioniques classiques
II.1.2.2 Caractéristiques des architectures IMA
II.1.3 Sécurité-immunité dans les systèmes avioniques
II.1.3.1 L’approche sécurité-immunité dans l’avionique
II.1.3.2 Contraintes de sécurité-immunité dans l’avion
II.1.3.3 Communications bord-sol et contraintes de sécurité-immunité
II.2 Sûreté de fonctionnement : concepts et terminologie
II.2.1 Définitions
II.2.1.1 La sûreté de fonctionnement
II.2.1.2 Entraves à la sûreté de fonctionnement
II.2.1.3 Moyens de la sûreté de fonctionnement
II.2.2 La tolérance aux fautes
II.2.2.1 Tolérance aux fautes accidentelles
Mécanismes de détection
Mécanismes de recouvrement
II.2.2.2 Tolérance aux fautes malveillantes
Mécanismes de détection
Recouvrement avec la fragmentation – redondance – dissémination
II.2.2.3 Tolérance aux fautes et redondance
II.3 Conclusion
Chapitre III Considérations Immunité – Innocuité
Introduction
III.1 Intégrité et Sécurité-innocuité
III.1.1 Retour sur les normes de développement des systèmes critiques
III.1.1.1 Les critères SQUALE
III.1.1.2 La norme IEC 61508
III.1.2 Considérations multiniveaux
III.1.2.1 Criticité et confiance
III.1.2.2 Paramètres de confiance
III.2 Intégrité dans les systèmes à criticités multiples
III.2.1 Modèle Biba
III.2.1.1 Définition du treillis
III.2.1.2 Concepts et notations de la politique d’intégrité
III.2.1.3 Spécification de la politique
III.2.2 Modèle de non interférence
III.2.3 Modèle de dépendances causales
III.2.4 Modèle Clark & Wilson
III.2.5 Modèle Totel
III.2.5.1 Définitions et notation
III.2.5.2 Flux de données entre les SLO
III.3 Conclusion
Chapitre IV La virtualisation pour la tolérance aux fautes
Introduction
IV.1 Retour sur la tolérance aux fautes
IV.1.1 La redondance et les systèmes tolérants aux fautes
IV.1.2 La redondance logicielle
IV.2 La virtualisation
IV.2.1 Origines de la virtualisation
IV.2.2 Définition simple de la virtualisation
IV.2.3 Interfaces d’abstraction logicielles
IV.2.3.1 Interface binaire d’application (ABI)
IV.2.3.2 Interfaces de Programme d’Application
IV.2.4 Virtualisation et Interfaces Logicielles
IV.2.4.1 Machine virtuelle de processus
La multiprogrammation
L’émulation
Les langages de haut niveau
IV.2.4.2 Machine virtuelle de système
IV.3 Implémentation et utilisation de la virtualisation
IV.3.1 Implémentations de machines virtuelles de système
IV.3.1.1 Isolateur
IV.3.1.2 Virtualisation complète
IV.3.1.3 Virtualisation assistée par le matériel
IV.3.1.4 Paravirtualisation
IV.3.1.5 Combinaisons des implémentations de machines virtuelles
IV.3.2 Exemples d’utilisation des techniques de virtualisation système
IV.3.2.1 Isolation
IV.3.2.2 Observation d’activités de systèmes virtualisés
Traçage d’activité d’un système
Détection d’intrusion
IV.3.2.3 Contrôle de systèmes virtualisés
Rajeunissement
Sauvegarde et reprise des activités d’un système
Equilibrage de charge
IV.4 Conclusion
Chapitre V Conclusion Générale
