Systèmes embarqués avioniques

Systèmes embarqués avioniques

PROBLÉMATIQUE

Problème de recherche Nous posons le problème de recherche avec la question suivante : « Dans le contexte des systèmes IMA, comment serait-il possible d’adapter un noyau de partitionnement robuste monocoeur existant afin de le rendre compatible à un environnement multicoeur ? » Le problème est motivé par la stagnation des performances des processeurs monocoeurs depuis le milieu des années 2000 [13], ce qui force l’industrie avionique à considérer l’éventuelle adoption des processeurs multicoeurs [37]. Dans le cadre du projet CRIAQ AVIO-509, des partenaires industriels du domaine de l’avionique sont intéressés à l’utilisation éventuelle des processeurs multicoeurs pour augmenter le niveau d’intégration des plateformes avioniques afin d’en réduire les coûts. Le problème posé ci-haut a été identifié comme une première étape dans cette direction lors de réunions des chercheurs de notre équipe de projet. 1.2 Objectifs Dans le cheminement vers la solution du problème de recherche, trois objectifs sont visés. À notre connaissance, il n’existe actuellement aucun prototype librement disponible permettant l’évaluation du partitionnement robuste sur processeurs multicoeurs pour les applications avioniques. 1. Le premier objectif consiste à adapter un noyau de partitionnement robuste existant à une architecture multicoeur. Le noyau adapté devra permettre : 8 • la consolidation d’un plus grand nombre d’applications avioniques sur une même machine en exploitant des processeurs multicoeurs existants ; • l’exploration des principaux modèles de partitionnement temporels parallèles (AMP, SMP et hybride) ; • le prototypage d’applications IMA embarquées dans un environnement logiciel comparable aux solutions commerciales existantes. L’implémentation d’un noyau de partitionnement robuste multicoeur vise à rendre possible l’intégration sécuritaire d’un nombre plus élevé de fonctions avioniques dans chaque boîtier physique. La mise en oeuvre d’une implémentation multicoeur du partitionnement robuste permettra de relever des problèmes d’intégration et de sûreté encore inconnus ou encore non validés expérimentalement. 2. Le second objectif consiste à identifier des problèmes d’intégration et de sûreté découlant du partitionnement robuste multicoeur. Les noyaux de partitionnement robuste font partie de la classe logicielle des systèmes d’exploitation. Ils doivent prendre le contrôle total du matériel afin d’isoler adéquatement les applications. Les systèmes d’exploitation embarqués sont notoirement difficiles à développer, car les bogues surviennent le plus souvent à un niveau où l’utilisation de débogueurs est difficile, voire impossible et où les conséquences de bogues sont souvent le plantage dur de la machine. L’utilisation de plateformes virtuelles a été suggérée dans la littérature [43] pour simplifier le développement et la validation des logiciels embarqués. 3. Le troisième objectif consiste à implémenter la totalité du prototype sur une plateforme virtuelle afin d’évaluer les avantages et inconvénients de ce type d’outil pour le prototypage et le test de logiciels avioniques complexes. 1.3 Contributions Nous identifions ici les contributions découlant de la réalisation de nos travaux de recherche et de l’atteinte des objectifs du projet. 9 En premier lieu, nous réalisons un prototype de noyau de partitionnement robuste multicoeur adapté à partir d’un noyau existant. Le code source, la documentation et les exemples découlant de la réalisation de cette adaptation pourront servir de base à des travaux de recherche ultérieurs qui nécessitent un noyau de partitionnement robuste multicoeur fonctionnel. En second lieu, nous présentons les problèmes d’adaptation que nous avons relevés, ainsi que la description du processus d’adaptation. Le contenu du présent mémoire sera utile à nos successeurs qui voudront réaliser le même genre d’exercice dans un environnement industriel. En dernier lieu, nous présentons une étude de cas de l’utilisation de notre noyau adapté. Cette étude de cas est réalisée sur la plateforme virtuelle Simics. Par ailleurs, nous avons développé une méthode d’instrumentation nouvelle vouée aux plateformes virtuelles lors du débogage de notre implémentation du noyau XtratuM-PPC. Cette méthode, nommée VPI (« Virtual Platform Instrumentation »), a fait l’objet d’un article de conférence présenté à l’« IEEE International Symposium on Rapid System Prototyping » (RSP 2011). L’article est reproduit à l’annexe II. Notre couverture de l’utilisation de plateformes virtuelles sera donc réduite dans le présent mémoire, car ces résultats ne sont pas nécessaires à la compréhension de nos contributions principales liées à l’adaptation du noyau XtratuM. 1.4 Hypothèses et suppositions Nous identifions dans cette section les hypothèses et suppositions générales qui ont servi à guider la méthodologie de recherche. Notre hypothèse centrale est que l’adaptation multicoeur d’un noyau de partitionnement robuste existant est possible. De plus, nous émettons l’hypothèse que cette adaptation pourra supporter des plans d’exécution parallèles symétriques (SMP), asymétriques (AMP) et hybrides (SMP et AMP). 10 Ces hypothèses sont basées sur l’analyse préalable des architectures des systèmes d’exploitation Linux et RTEMS. Linux et RTEMS supportent déjà des modèles de programmation parallèles. De plus, le système d’exploitation temps réel RTEMS a déjà fait l’objet d’une adaptation afin de supporter le partitionnement robuste selon la norme ARINC-653 sur des processeurs monocoeurs. Cette adaptation avait été réalisée par l’équipe du projet AIR (« ARINC-653 in RTEMS ») [56], sans support de traitement parallèle. Enfin, le noyau de partitionnement robuste de PikeOS supporte maintenant les processeurs multicoeurs [30, 62]. Ce dernier est apparu vers la fin de nos travaux. Il est donc raisonnable de croire qu’il sera possible d’adapter un noyau de partitionnement robuste monocoeur à un modèle multicoeur dans nos travaux. Afin de circonscrire plus précisément notre problématique, nous soulignons les suppositions suivantes : • La cible des développements expérimentaux est l’architecture PowerPC. Plusieurs processeurs multicoeurs commerciaux emploient déjà cette architecture. • La plateforme matérielle modélisée est considérée comme fiable et déterministe au sens de ses spécifications. Nous n’évaluerons pas la fiabilité intrinsèque de la plateforme matérielle cible. • La plateforme virtuelle employée pour les travaux de prototypage est supposée fiable et déterministe. • Aucune contrainte de certifiabilité n’est appliquée aux développements expérimentaux, malgré la considération de ces mêmes contraintes dans la résolution du problème posé. • Le modèle de partitionnement robuste défini par la norme ARINC-653 est prépondérant en industrie, mais nos travaux d’adaptations ne viseront que le respect de l’esprit de la norme et non pas son implémentation. Ces suppositions générales s’appliquent en général à l’intégralité de nos travaux. Ces dernières s’ajoutent aux suppositions propres à chacune des tâches d’adaptation, qui seront présentées dans leur contexte particulier.

Table des matières

INTRODUCTION
CHAPITRE 1 PROBLÉMATIQUE
1.1 Problème de recherche
1.2 Objectifs
1.3 Contributions
1.4 Hypothèses et suppositions
CHAPITRE 2 REVUE DE LA LITTÉRATURE ET FONDEMENTS
2.1 Survol
2.2 Systèmes embarqués avioniques
2.2.1 Fonctions avioniques
2.2.2 Sûreté des systèmes avioniques
2.2.2.1 Fiabilité des systèmes avioniques
2.2.2.2 Lignes directrices de certification
2.2.2.3 Directive DO-178B visant le développement logiciel
2.2.3 Architecture des systèmes embarqués avioniques
2.2.3.1 L’avionique fédérée
2.2.3.2 L’avionique modulaire intégrée
2.3 Partitionnement robuste
2.3.1 Définition du partitionnement robuste
2.3.2 Partitionnement spatial
2.3.3 Partitionnement temporel
2.3.4 Le partitionnement robuste selon la norme ARINC-653
2.3.5 Interdépendances entre partitionnement spatial et temporel
2.4 Méthodes de partitionnement spatial
2.5 Méthodes de partitionnement temporel
2.6 Choix d’un noyau de partitionnement robuste à adapter
2.7 Processeurs multicoeurs
CHAPITRE 3 ARCHITECTURE ET IMPLÉMENTATION DU NOYAU XTRATUM
SUR PROCESSEURS LEON
3.1 Survol
3.2 Historique de XtratuM
3.3 Architecture de XtratuM
3.4 Plan de configuration du système
3.5 Déploiement du système partitionné
3.5.1 Configuration et construction du noyau
3.5.2 Génération de la table de configuration binaire
3.5.3 Construction des partitions
3.5.4 Construction de l’image de déploiement
3.5.5 Déploiement sur la carte matérielle
3.6 Services de base du noyau
3.6.1 Gestion de l’horloge
3.6.2 Gestion des interruptions et exceptions
3.6.3 Virtualisation des opérations superviseur
3.7 Mécanisme d’hyperappels
3.8 Partitionnement temporel
3.9 Partitionnement spatial
3.10 Communication inter-partitions
3.11 Moniteur de santé du système
3.12 Récapitulation
CHAPITRE 4 ANALYSE DE L’ADAPTATION MULTICOEUR DE XTRATUM
4.1 Survol
4.2 Support existant pour traitement parallèle
4.3 Méthodologie d’adaptation
4.3.1 Hypothèses et suppositions
4.3.2 Identification des besoins
4.4 Plan de configuration du système
4.5 Déploiement du système partitionné
4.6 Services de base du noyau
4.6.1 Duplication du fil d’exécution du noyau
4.6.2 Démarrage du noyau
4.6.3 Gestion de l’horloge
4.6.4 Gestion des interruptions et exceptions
4.7 Mécanisme d’hyperappels
4.8 Partitionnement temporel
4.8.1 Plans d’exécution multicoeur
4.8.1.1 Modèle asymétrique (AMP)
4.8.1.2 Modèle symétrique (SMP)
4.8.1.3 Modèle hybride
4.8.2 Ordonnancement multicoeur
4.8.3 Hyperappels de support multicoeur
4.8.4 Problèmes liés au partitionnement temporel multicoeur
4.8.4.1 Analyse du délai maximal d’exécution des tâches
4.8.4.2 Synchronisation temporelle des ordonnanceurs
4.8.4.3 Gestion des fautes
4.8.4.4 Modèles de programmation parallèle
4.9 Partitionnement spatial
4.9.1 Exploitation du MMU
4.9.2 Adaptation multicoeur du modèle de partitionnement spatial
4.9.3 Protection des données partagées
4.9.4 Problèmes liés au partitionnement spatial multicoeur
4.10 Communication inter-partitions
4.11 Moniteur de santé du système
4.12 Récapitulation
CHAPITRE 5 RÉALISATION DE XTRATUM-PPC SUR POWERPC
5.1 Survol
5.2 Plateforme cible
5.2.1 Architecture du PowerPC MPC8641D
5.2.2 Plateforme virtuelle
5.2.2.1 Motivations
5.2.2.2 Choix de la plateforme virtuelle
5.2.3 Configuration de la plateforme cible sous Simics
5.2.4 Chaîne de compilation 5.3 Démarrage du système
5.3.1 Vecteurs d’exceptions
5.3.2 Procédure de démarrage
5.3.3 Identification des coeurs
5.3.4 Problèmes potentiels
5.4 Gestion du temps
5.4.1 Horloges locales
5.4.2 Minuteries
5.4.3 Synchronisation des horloges locales
5.4.4 Problèmes potentiels 5.5 Gestion des interruptions
5.5.1 Pilote du contrôleur d’interruptions OpenPIC
5.5.2 Gestionnaires d’interruptions et d’exceptions
5.5.3 Problèmes potentiels
5.6 Synchronisation multicoeur
5.6.1 Opérations atomiques
5.6.2 Verrous
5.6.3 Barrières
5.6.4 Problèmes
5.7 Mécanisme d’hyperappels
5.8 Exploitation du MMU
5.8.1 Application du modèle de partitionnement spatial sur le MMU
5.8.2 Caches d’entrées des TLB
5.8.3 Problèmes
5.9 Changement de contexte de partitions
5.9.1 Appel de l’ordonnanceur
5.9.2 Composante générique du changement de contexte
5.9.3 Implémentation du changement de contexte principal sur e600
5.9.4 Gestion des registres spécialisés
5.10 Mise à l’essai
5.10.1 Objectifs
5.10.2 Présentation de l’étude de cas
5.10.3 Méthodologie de mesure
5.10.4 Résultats
5.10.5 Conclusions
5.11 Récapitulation
CONCLUSION
ANNEXE I TABLEAUX ET FIGURES SUPPLÉMENTAIRES
ANNEXE II ARTICLE DE CONFÉRENCE SUR LA MÉTHODE VPI
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES

Télécharger le rapport complet