Télécharger le fichier pdf d’un mémoire de fin d’études
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és2. 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 (cf. figure II.1).
2 Ces autorités sont spécifiques aux pays du constructeur. Ainsi en Europe, il s’agit de l’agence européenne de la sécurité aérienne EASA (European Aviation Safety Agency), pour les Etats Unis, il s’agit de l’administration fédérale d’aviation (Federal Aviation Administration). Un agrément doit être accordé par les autres autorités aéronautiques dans le monde.
Comme le montre la Figure II.1, 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 (DO-178B).
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…
Les résultats de la FHA sont les données initiales de la PSSA, et de même pour les résultats de la PSSA vis-à-vis de la SSA. La Figure II.2 montre les principales relations entre les quatre étapes précisées ci-dessus et le processus de développement des systèmes.
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.
Evaluation de la sécurité des systèmes (SSA)
Une SSA est une analyse itérative complète des fonctions systèmes implémentées destinée à montrer que les exigences de sécurité sont satisfaites. Le processus est similaire à celui de la PSSA du point de vue des activités, mais différent dans l’intention : une PSSA évalue des architectures proposées et en déduit des exigences de sécurité, alors qu’une SSA vérifie que l’architecture sélectionnée satisfait aux exigences qualitatives et quantitatives définies dans la FHA et la PSSA.
Une SSA combine les résultats des différentes analyses menées pour vérifier la sécurité du système complet et couvrir toutes les considérations spécifiques de sécurité identifiées dans la PSSA.
Comme l’avons mentionné, la norme ARP 4754 (cf. Figure II.1) est liée au développement des systèmes avioniques. Dans le cadre de nos travaux, nous nous intéressons à la composante logicielle des systèmes avioniques. Les recommandations de développement d’applications logicielles sûres de fonctionnement dans le domaine avionique sont décrites dans la norme DO-178B que nous proposons de présenter dans la section suivante.
Sécurité des entités logicielles en avionique DO-178B
Dans l’avionique, la certification des systèmes embarqués met principalement l’accent, d’un point de vue de la sûreté de fonctionnement, sur la sécurité-innocuité. La prise en compte explicite des aspects liés à la sécurité-immunité fait l’objet de travaux en cours pour faire évoluer la norme (DO-178C).
La démarche générale repose sur un processus d’analyse de la sécurité-innocuité (intégrant des études de risques préliminaires, fonctionnelles et architecturales) qui consiste à analyser les fonctions et l’architecture des systèmes avioniques et à identifier leurs modes de défaillance. Ceux-ci sont classés en fonction d’une échelle de sévérité (vis-à-vis des conséquences de ces défaillances sur la sécurité des vols et des passagers) qui comprend cinq niveaux: catastrophique, dangereux, majeur, mineur et sans effet. La criticité d’un système est alors déterminée par la plus forte sévérité de ses modes de défaillance. On définit alors cinq niveaux d’assurance de développement (Development Assurance Level DAL) notés DAL-A, DAL-B, DAL-C, DAL-D et DAL-E par ordre décroissant. Ainsi, les logiciels critiques sont développés au niveau DAL-A alors que les logiciels qui n’ont aucun impact sur la sécurité de l’appareil sont développés au niveau DAL-E (correspondant généralement au niveau des applications existantes dans le monde ouvert). Cette classification détermine ainsi le niveau d’assurance que le système doit satisfaire. Pour chacun de ces niveaux, un ensemble de critères et de preuves est requis.
Comme nous l’avons précédemment indiqué, la norme DO-178B est consacrée au processus de développement des logiciels embarqués (cf. Figure II.1). Elle est basée sur une approche orientée processus. On distingue trois types de processus dans le cycle de vie du logiciel :
• le processus de développement, qui comprend la spécification, la conception, le codage et l’intégration ;
• les processus intégraux, qui comprennent la vérification, la gestion de configuration, l’assurance qualité et la coordination pour la certification ;
• le processus de planification qui coordonne le processus de développement et les processus intégraux.
Pour chaque processus et chaque niveau d’assurance, les objectifs sont définis et une description des données du cycle de vie permettant de démontrer que les objectifs sont satisfaits est également fournie. La norme n’impose aucune méthode pour atteindre les objectifs fixés. C’est à la charge du postulant à la certification (donc les constructeurs avioniques) d’apporter les preuves que les méthodes employées permettent de répondre aux objectifs. De même, bien que la norme ne l’impose pas, elle recommande d’utiliser des stratégies de tolérance aux fautes qui peuvent être employées pour la détection et le recouvrement d’erreurs. Le tableau II.1 résume le lien entre les différents niveaux de DAL présents dans la DO-178B et les objectifs en termes de probabilité et de sévérité de défaillance.
Afin d’atteindre l’objectif de probabilité d’erreur inférieure à 10-9 (comme le montre le Tableau II.1), les systèmes avioniques se basent habituellement sur la redondance pour implanter des systèmes tolérant les fautes, comme nous allons le détailler dans la Section II.2. Il convient en particulier de souligner que la notion de redondance logicielle diversifiée a été identifiée et détaillée dans la norme DO-178B. Nous proposons de présenter les considérations liées à une telle diversification logicielle, sachant que ces considérations guideront les analyses de fautes menées dans le cadre de l’étude présentée dans ce manuscrit.
Considéations pour la diversification des logiciels selon la DO-178B
L’utilisation d’une diversification (cf. Section II.2.2.3 pour la terminologie utilisée) permet d’augmenter le niveau de confiance que l’ont peut avoir dans le résultat fourni par l’ensemble des logiciels diversifiés. Cependant, l’ajout de mécanismes de diversification doit s’accompagner d’un processus de vérification qui doit en particulier prouver qu’un tel ajout n’a pas d’effet de bord sur les propriétés de sécurité-innocuité du système, telles qu’elles ont été définies par les différentes évaluations présentées dans la Section II.1.1.1. La diversification logicielle est ainsi assurée en combinant les règles de diversification suivantes :
• Le code source est implanté en utilisant deux ou plusieurs langages de programmation différents.
• Le code exécutable est généré en utilisant un ou plusieurs compilateurs différents.
• Chaque version de code exécutable est exécutée sur un processeur différent. Dans le cas où un seul processeur serait utilisé, il faut s’assurer du bon fonctionnement des mécanismes d’isolation entre les versions exécutées.
• Les besoins logiciels, la phase de conception et d’implantation sont réalisées sur plus de deux environnements de développement. De plus, il est possible que chaque version mise en œuvre soit vérifiée sur des environnements de test différents.
• Le code exécutable est lié (linked) puis chargé (loaded) en utilisant deux ou plusieurs éditeurs de liens et chargeurs.
• Les besoins logiciels, la conception et l’implémentation de chaque version doit être réalisée en utilisant respectivement des standards de besoins logiciels (Software Requirements Standards), standards de conception et standards de code source différents.
Ainsi ces différentes règles peuvent être combinées pour implanter des applications logicielles diversifiées. Dans ce cas, le processus de vérification dépend de la nature de la règle (ou des règles) choisie pour la diversification, en particulier en fonction de la diversification introduite au niveau matériel et/ou logiciel. Cependant, il faut également montrer que chaque version est correcte, et que les versions sont également compatibles entre elles, vis-à-vis des spécifications (et ce pour un fonctionnement normal ou défectueux du système). De plus, il faut montrer que la solution diversifiée est au moins aussi performante qu’un système non diversifié par rapport à la détection d’erreurs.
Selon la norme ARP 4754, l’utilisation d’une diversification (logicielle et/ou matérielle) permet de réduire les efforts de validation pour réaliser une tâche d’un niveau de criticité élevé. Cette vision est différente de celle requise dans la DO-178B dans laquelle on demande qu’au moins l’une des versions soit développée au même niveau que celui de la tâche la plus critique. Nous présenterons plus en détails cet aspect lié à la diversification dans le Chapitre III.
Remarquons que pour la norme ARP 4754 présentée, les fonctions avioniques possèdent des niveaux de DAL qui leur sont propres. Ces fonctions sont développées généralement sur un composant matériel dédié à l’exécution des applications implantant ces fonctionnalités. Cependant, depuis quelques années, une nouvelle génération de calculateurs permet d’intégrer sur un même module physique, plusieurs applications à criticité disjointes. Il s’agit des architectures IMA (Integrated Modular Avionics). Cette approche est fort intéressante puisqu’elle rejoint la problématique traitée dans ce manuscrit, à savoir la communication entre applications à multiples niveaux de criticité. Nous proposons dans ce qui suit de présenter plus en détail les architectures IMA.
Architectures IMA
Les architectures IMA sont des architectures avioniques qui permettent de répondre à des besoins que les architectures avioniques classiques ne possédaient pas. Ces besoins sont essentiellement d’ordre économique (coûts de développement, de possession, de maintenance, d’immobilisation, etc.) Nous proposons de présenter dans un premier temps ces architectures classiques, puis détailler les caractéristiques d’une architecture IMA.
Systèmes avioniques classiques
Les premières fonctions logicielles utilisées en avionique sont des fonctions dédiées à une tâche bien spécifique dans l’appareil. Chaque fonction est associée à un ensemble d’entités matérielles en charge d’exécuter cette fonction. De tels systèmes sont appelés systèmes fédérés (federated systems) puisque la partie logicielle d’un tel système est fortement liée au matériel sous-jacent. Les normes avioniques classiques (celles présentées dans la section précédente) utilisent cette vision de systèmes avioniques lors des processus d’évaluation de la sécurité-innocuité de tels systèmes. Par exemple, pour calculer le pire temps d’exécution (WCET : Worst Case Execution Time) d’une fonction avionique, il faut prendre en considération aussi bien les aspects applicatifs propres à la fonction que les interactions qui existent avec le matériel d’exécution.
De tels systèmes ont été largement utilisés aussi bien dans le monde avionique que dans le domaine spatial. Ainsi, dans la station spatiale internationale (International Space Station : ISS), un grand nombre d’entités logicielles fédérées a été utilisé. Ces entités sont appelées unités orbitales remplaçables (Orbital Replacable Units : ORU) et correspondent aux unités de lignes remplaçables du monde avionique (Line Replaceable Units : LRU). Ces unités sont conçues pour des fonctions bien spécifiques (pouvant intégrer quelques modes de configuration), et sont facilement remplaçables en cas de défaillance.
Cependant, cette vision classique de systèmes fédérés présente des inconvénients (liées à cette forte dépendance entre le logiciel et le matériel) que nous résumons dans les points suivants :
1. La durée de vie d’un avion est de l’ordre de plusieurs dizaines d’années (25-30 ans, voire plus). Cette durée de vie est longue relativement à la durée de vie d’un matériel. En effet, vu les avancées technologiques actuelles, un matériel devient obsolète au bout seulement de quelques années. Dans de nombreux cas, le matériel planifié durant la conception peut même devenir obsolète au moment de la construction de l’appareil. De plus, même si ce matériel est mis à jour, il faut bien s’assurer de la portabilité du logiciel qui n’a pas été originellement développé pour ce nouveau matériel. Cette tâche s’avère particulièrement coûteuse vu le lien étroit qui existe entre le logiciel et le matériel dans un système fédéré.
2. L’hétérogénéité des matériels utilisés dans les applications avioniques. En effet, chaque application possède ses propres contraintes fonctionnelles, et est exécutée sur un matériel qui lui a été conçu. Assurer la maintenance matérielle dans ces conditions est une tâche fort coûteuse, d’un point de vue économique.
3. La communication entre systèmes dépend des applications et également du matériel d’exécution. Toute mise à jour d’une entité logicielle implique une modification importante dans le mécanisme de communication, entraînant souvent la modification des autres entités logicielles pour permettre une interopérabilité.
L’expérience dans le monde avionique montre que même si les systèmes fédérés sont robustes vis-à-vis des défaillances (compte tenu de la forte indépendance entre les supports d’exécution matériels des fonctions avioniques), ils sont cependant lents et difficiles à développer et à mettre à jour [Alena et al. 2007].
Caractéristiques des architectures IMA
Les architectures IMA ont été proposées pour répondre à ce besoin de dissocier les composants logiciels des composants matériels dans les systèmes fédérés. Cette architecture présente une plateforme unique pour toutes les applications logicielles avioniques. La plateforme consiste en une architecture temps-réel distribué, permettant à différentes applications de s’exécuter en parallèle. Ces applications partagent alors les ressources fournies par la plateforme IMA (ressource de calcul, de mémoire,…). Il est donc clair qu’une telle architecture doit assurer un partage de ressource sûr entre les applications. Dans ce cas, il est question d’une isolation forte entre les modules logiciels, ou encore connue dans la littérature par partitionnement. Ce partitionnement est classé en partitionnement spatial (par exemple, la gestion de la mémoire) et temporel (la gestion des ressources temporelles par la CPU) [J. Rushby 2000]. Cependant, nous trouvons que cette classification ne présente aucune limite claire entre la notion de spatial et temporel. Dans le cadre de ce manuscrit, nous désignerons par partitionnement (ou isolation) tous les mécanismes mis en place pour assurer une gestion des ressources qui ne mettent pas en défaut le fonctionnement des applications utilisant ces ressources.
Ainsi, avec cette vision du partitionnement, une architecture IMA n’est autre qu’un gestionnaire de ressources matérielles pour des applications avioniques embarquées. Ces applications sont implantées dans des modules pouvant avoir des niveaux de criticité hétérogènes. L’architecture IMA se doit d’être sûre afin de permettre un tel partitionnement entre applications à criticités multiples. Ainsi, dans [ARINC 653 1997], le partitionnement doit assurer une isolation totale entre des applications ayant des niveaux de DAL distincts. L’isolation est réalisée en introduisant des partitions qui sont des espaces d’exécution logiques attribués à chaque fonction avionique. L’accès aux ressources (CPU, mémoire,…) est ensuite contrôlé pour qu’il n’y ait aucune altération du fonctionnement des entités les plus critiques (des entités du niveau DAL-A ou DAL-B, par exemple).
Remarquons qu’une telle architecture est similaire à l’architecture d’un système d’exploitation classique. En effet, un système d’exploitation offre aux différentes applications qui y sont installées de s’exécuter en parallèle, indépendamment de la couche matérielle. Une architecture IMA, tout comme un système d’exploitation, offre des services (par exemple service de communication) aux applications qui y sont installées. Ces services sont accessibles via une interface de programmation des applications (Application Programming Interface : API, cf. Chapitre IV) unique pour toutes les fonctions avioniques. Cependant, les architectures IMA se distinguent des systèmes d’exploitation classiques par les fortes contraintes auxquelles elles sont soumises lors de leur développement, ainsi que de l’aspect distribué des différentes partitions dans l’appareil.
Ainsi, une plateforme IMA est constituée d’un certain nombre de modules distribués dans l’avion. Ces modules sont connectés entre eux et également avec des périphériques de l’avion (typiquement des périphériques d’entrée/sortie comme des capteurs ou des interfaces homme machine). La Figure II.3 présente l’aspect en couche d’un module IMA.
Comme le montre la Figure II.3, le module est constitué d’un système d’exploitation en charge d’exécuter plusieurs partitions. La communication entre les partitions et le système d’exploitation du module se fait via l’API. Le système du module communique avec la matériel via un noyau exécutif (Core Executive : CO-EX). Ce noyau offre une transparence du support matériel pour le système d’exploitation du module. Notons également que la seule couche visible pour une application dans une partition donnée est la couche API.
Cette abstraction est intéressante est présente les avantages suivants :
• Compte tenu de la transparence du matériel par rapport aux fonctions avioniques, il est possible d’utiliser du matériel différent pour assurer une diversification matérielle (cf. section suivante pour la tolérance aux fautes), sans que cela n’impacte le fonctionnement de l’application. Cette diversification serait donc gérée au niveau du système d’exploitation qui se charge de traduire les instructions applicatives en instructions matérielles.
• La robustesse du partitionnement fait qu’une application peut être développée et testée d’une façon incrémentale, sans que cela n’altère le fonctionnement des autres partitions.
• Grâce à l’interopérabilité des modules, en cas de défaillance d’un module, il est possible de reconfigurer une application logicielle pour qu’elle s’exécute sur un second module, ce qui présente une propriété fort intéressante en terme de disponibilité de l’appareil.
Les architectures IMA sont déjà utilisées pour des fonctionnalités spécifiques sur certains appareils. Par exemple, le système d’exploitation DEOS (Digital Engine Operating System) [Libin Dong et al. 1999] qui implémente l’IMA a été utilisé dans des avions commerciaux certifiés. Cependant, la certification des systèmes avioniques utilise toujours la vision des systèmes fédérés. La DO-178B ne présente le partitionnement que dans le cas d’une séparation logique entre sections d’une application unique. Ainsi, certifier un système IMA en se basant sur cette vision fédérée implique un effort de validation considérable, ce qui rend l’utilisation de tels systèmes coûteuse (d’un point de vue économique) [Conmy et McDermid 2001].
Comme nous avons pu le constater, la sécurité, au sens innocuité, est l’une des premières exigences qui a guidé le développement des fonctions avioniques (aussi bien au niveau matériel que logiciel). Cependant, depuis quelques années (surtout après les événements du 11 septembre 2001), la composante sécurité-immunité est devenue de plus en plus présentes dans le monde avionique. Nous proposons de détailler quelques pistes de réflexions sur l’aspect immunité. Ces pistes sont encore en cours d’analyse et d’investigation dans le monde avionique.
Sécurité-immunité dans les systèmes avioniques
Depuis plusieurs années, le développement des architectures avioniques tend vers une intégration de plus en plus importante de composants issus des technologies de l’information grand public (typiquement des composants sur étagères ou aussi communément identifiés par le vocable COTS : Commercial-Off-The-Shelf). De plus, l’augmentation du nombre des modules IMA dans les appareils durant les dernières années prouve que la tendance d’utiliser des fonctionnalités étendues s’impose sur le terrain des constructeurs avioniques.
L’utilisation croissante des composants COTS est accompagnée d’un besoin de communication bidirectionnel entre les modules avioniques et le monde ouvert. En effet, il est fort souhaitable d’utiliser toutes les fonctionnalités étendues qu’offrent les applications COTS dans des modules avioniques, et ces fonctionnalités nécessitent dans la majorité des cas une forte interaction avec le monde ouvert. Nous présentons dans un premier temps l’approche sécurité-immunité en avionique. Nous présentons ensuite les considérations de sécurité-immunité déjà existantes au bord des appareils. Nous détaillons enfin les communications bord-sol et les aspects de sécurité qui y sont liés.
L’approche sécurité-immunité dans l’avionique
L’approche de la sécurité-immunité dans l’avionique consiste à traiter les menaces qui pourraient avoir un impact sur la sécurité-innocuité des fonctions avioniques. Ainsi, une menace est appréhendée en fonction de son influence sur l’altération des propriétés de safety de l’appareil. Ces menaces sont classées alors selon différents niveaux, comme le montre le tableau II.2.
Remarquons que cette classification est liée à celle proposée par la DO-178B. Les menaces classifiées dans le tableau présentent des conséquences sur les paramètres de sécurité-innocuité du vol [ED-127 2009]. Les paramètres principaux sont les suivants :
• Réduction des marges de sécurité-innocuité de l’appareil, ou des capacités fonctionnelles de l’appareil.
• Augmentation de la charge de travail de l’équipage ou altération des conditions de travail de l’équipage, réduisant ainsi sa capacité à remplir correctement ses fonctions.
• Détresse ou blessure des occupants de l’appareil.
Les menaces considérées sont essentiellement d’origine humaine (utilisation inappropriée, attaque délibérée, faute accidentelle, résultant d’un accès non autorisé, etc). La menace humaine peut être couplée avec d’autres facteurs (environnementaux, par exemple) pour conduire à l’aboutissement de l’attaque. Pour pallier ces menaces, les systèmes internes à l’avion sont développés de façon à ce qu’il y ait des contraintes de communication entre les différents composants avioniques, afin de réduire les risques de contamination en cas d’attaque réussie, comme nous allons le montrer dans la section suivante.
Contraintes de sécurité-immunité dans l’avion
Les systèmes avioniques ont été développés en respectant la classification de la DO-178B en affectant à chaque composant logiciel un niveau de criticité. Cette même vision de niveaux de criticité est utilisée dans [ARINC 811 2005] pour distinguer différents domaines de sécurité au sein de l’avion [Olive et al. 2006]. Comme le montre la Figure II.4, quatre domaines sont définis en fonction de différents critères : sécurité (existence de contrôle ou pas), responsabilité (constructeur, compagnie aérienne, passager), opération aérienne (secrète, privée, publique) et rôle (commande de l’avion, exploitation avionique, information et divertissement des passagers). Nous présentons dans ce qui suit les différents domaines identifiés dans la Figure II.4 et détaillés dans le rapport ARINC 811, sans pour autant spécifier les spécifications internes de chaque domaine :
• Le domaine de commande de l’appareil (Aircraft Control Domain) est le domaine le plus critique dans le monde avionique. Il contient les applications de contrôle et de commande de l’appareil. Ces applications sont généralement installées sur des calculateurs qui récupèrent les commandes du pilote, les transforment (en fonctions des lois de pilotage et des données environnementales par exemple) en données numériques, et les communiquent (via un réseau dédié) aux différents actionneurs de l’appareil.
• Le domaine de services d’information de la compagnie (Airline Information Services Domain) contient les différents supports relatifs au vol, la cabine, la maintenance (cf. Figure II.4). Ce domaine est moins critique que le précédent, mais il reste tout de même d’un niveau assez élevé de criticité. En effet, les informations contenues dans ce domaine sont critiques pour l’exploitaton de l’appareil (surtout par rapport à la maintenance) par les compagnies aériennes.
• Le domaine de services d’information et de divertissement des passagers (Passenger Information and Entertainment Services Domain) est en charge de la communication avec les passagers. Ainsi la gestion des écrans de divertissement (In Flight Entertainment : IFE) ainsi que l’interface de connexion (à l’Internet par exemple) des périphériques du passager. Ce domaine est fortement lié à l’image de marque de la compagnie aérienne auprès des passagers. Aussi, les compagnies accordent une grande importance aux équipements de divertissement des passagers, certaines allant même jusqu’à refuser l’autorisation de décollage d’un appareil si un terminal de divertissement (IFE) est en panne.
• Le domaine des équipements des passagers (Passenger-owned Devices) est réservé à tous les équipements électroniques des passagers (ordinateurs portables, PDA, téléphones, consoles de jeu,…). Dans certains avions récents, ces équipements sont connectables, via des interfaces spécifiques (présentes dans le domaine précédent), à un réseau que la compagnie aérienne peut configurer en fonction de sa stratégie commerciale (par exemple proposer une connexion Internet aux passagers).
|
Table des matières
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 Architectures de Sécurités pour les applications critiques embarquées
Introduction
V.1 Hypothèses de fautes et de fonctionnement
V.1.1 Hypothèses de fautes de l’architecture déployée
V.1.1.1 Fautes au niveau du matériel
V.1.1.2 Fautes au niveau du moniteur de machines virtuelles
V.1.1.3 Fautes au niveau des systèmes invités
V.1.1.4 Fautes au niveau de l’objet de validation et son environnement d’exécution
V.1.1.5 Fautes au niveau des applications
V.1.1.6 Synthèse des hypothèses de fautes
V.1.2 Déterminisme des versions et validation
V.1.2.1 Sources d’indéterminisme
V.1.2.2 Renforcement du déterminisme
V.2 Formalisation du modele totel
V.2.1 Dépendances causales et flux d’informations
V.2.1.1 Dépendance causale directe et indirecte
V.2.1.2 Flux et causalité
V.2.2 Contrôle d’intégrité : utilisation du modèle Totel avec les dépendances causales
V.2.2.1 Rappel des règles de contrôle d’intégrité
V.2.2.2 Conventions de notations dans le modèle Totel
V.2.2.3 Objets de validation par vraisemblance
V.2.2.4 Objets de validation par réplication
V.2.3 Validité des résultats de l’objet de validation
V.2.3.1 Niveau de confiance et validation des flux
V.2.3.2 Observations réelles et validation des flux
V.3 Analyse fonctionnelle et conception
V.3.1 Niveaux d’identification et de validation des flux
V.3.1.1 Niveaux d’identification et de capture
Au niveau de l’objet
Au niveau d’un intergiciel
Au niveau du système virtualisé
Au niveau de l’hyperviseur
V.3.1.2 Niveaux de validation
Implantation au niveau du MMV
Implantation au niveau d’un binaire
Implantation au niveau d’une machine virtuelle sûre
V.3.2 La TCB : entre complexité, validation et environnement distribué
V.3.2.1 Décomposition de la TCB
V.3.2.2 Adaptation au contexte distribué
V.4 Conclusion
Chapitre VI Cas d’etude et mise en oeuvre
Introduction
VI.1 1er cas d’etude : l’ordinateur de maintenance
VI.1.1 Cadre d’utilisation
VI.1.1.1 Tâches de maintenance classique
VI.1.1.2 Opérations de maintenance avec support électronique
VI.1.2 Analyse des flux de données
VI.1.3 Application du modèle Totel à l’ordinateur de maintenance
VI.2 2ème cas d’étude : l’ordinateur du pilote
VI.2.1 Cadre d’utilisation
VI.2.1.1 Calcul classique du profil de décollage
VI.2.1.2 Nouvelle utilisation de l’ordinateur du pilote
VI.2.2 Analyse des flux de données
VI.2.3 Application du modèle Totel à l’ordinateur du pilote
VI.3 Considérations de mise en œuvre
VI.3.1 Capture des flux ascendants des applications redondantes en vue de leur validation
VI.3.1.1 Implémentation de la diversification par virtualisation
VI.3.1.2 Capture au niveau du matériel
VI.3.1.3 Capture au niveau de l’hyperviseur
VI.3.1.4 Capture au niveau des appels des machines virtuelles Java
VI.3.1.5 Capture au niveau des entrées graphiques des bibliothèques java
VI.3.2 Interactions avec les applications diversifiées
VI.3.2.1 Gestion de l’interaction avec l’opérateur
VI.3.2.2 Cas des applications existantes
VI.4 Mise en œuvre ArSec
VI.4.1 Interception des appels Java Swing et Awt
VI.4.1.1 Description d’une machine virtuelle non sûre
VI.4.1.2 Description d’une machine virtuelle sûre
VI.4.1.3 Capture des sorties et exécution
VI.4.2 Contrôle au niveau d’une machine virtuelle sûre
VI.4.3 Déterminisme dans ArSec
VI.4.4 Description du démonstrateur ArSec
VI.5 Conclusion
VI.6 Recommandations pour les applications futures
Chapitre VII Conclusion Générale
VII.1 Bilan
VII.2 Perspectives
Références bibliographiques
Télécharger le rapport complet
