Choix d’un noyau de partitionnement robuste à adapter

Lors de la phase d’exploration de nos travaux, nous avons cherché des noyaux de partition- nement robuste académiques existants afin d’en trouver un qui pourrait servir de base à notre adaptation multicoeur. Nous pouvons classifier les noyaux identifiés au sein de trois catégo- ries : 1) ceux qui supportent directement ARINC-653, 2) ceux qui supportent des modèles similaires à ARINC-653 et 3) ceux qui ne supportent pas des modèles similaires à ARINC- 653.

Parmi ceux qui supportent directement ARINC-653, nous retrouvons les projets AIR et POK. AIR est un projet de collaboration industrielle entre l’Université de Lisbonne et Skysoft Por- tugal, supporté par l’agence spatiale européenne (« European Space Agency » ou ESA, en anglais). Le nom AIR provient de l’acronyme « ARINC-653 In RTEMS ». Comme son nom l’indique, le projet AIR visait à adapter le système d’exploitation temps réel à code source libre RTEMS, déjà employé dans le domaine spatial, afin de supporter un modèle de partition- nement ARINC-653. La première phase du projet (AIR1 [56]), achevée en novembre 2007, vi- sait à déterminer les adaptations nécessaires à RTEMS pour supporter l’APEX. La deuxième phase du projet (AIR2 [58]), achevée en novembre 2009, visait la réalisation d’une preuve de concept d’une implémentation complète de l’APEX par-dessus RTEMS sous les architec- tures IA32 et LEON. Le noyau de partitionnement robuste POK [22], quant à lui, est un projet démarré par Julien Delange à TELECOM ParisTech. Le nom POK provient de l’acronyme « Partitioned Operation Kernel ». POK est un noyau temps réel conçu dès le départ pour les applications partitionnées. En particulier, les fonctions critiques à la sûreté sont réalisées dans un noyau temps réel minimal, alors que les différentes interfaces de partitionnement robuste, dont l’APEX, sont réalisées à travers des librairies qui font appel aux services de base du noyau. La conception minimaliste du noyau simplifie sa vérification par des outils d’analyse statique et de couverture de code. POK vise principalement l’utilisation en recherche sur le

partitionnement aidé par des outils de modélisation de systèmes. Les architectures supportées par POK sont LEON, PowerPC et IA32.

Dans la catégorie des noyaux qui supportent un modèle similaire à ARINC-653, on retrouve le noyau XtratuM [19]. Ce projet est une collaboration entre l’Université Polytechnique de Va- lence, Astrium SAS et Teletel. Comme AIR, ce projet est supporté par l’ESA et vise l’applica- tion du partitionnement robuste au domaine spatial. La cible de ce noyau est LEON. XtratuM est un « hyperviseur » de type 1 selon la classification de Goldberg [31], soit un moniteur de machines virtuelles natives. Contrairement à AIR et POK, XtratuM réalise le partitionnement à l’échelle de machines virtuelles complètes, au lieu de gérer un ensemble de tâches dans le noyau. Il est ainsi possible d’implémenter des systèmes d’exploitation de partition qui ont l’illusion d’avoir le contrôle total de la machine. Cependant, XtratuM ne supporte pas directe- ment l’APEX, ni la description de configuration spécifiée dans ARINC-653. Au lieu de cela, un modèle de partitionnement et un ensemble de fonctions calqués sur la sémantique ARINC- 653 sont fournis. Il serait possible de réaliser un système compatible ARINC-653 basé sur XtratuM en programmant un système d’exploitation de partition qui emploierait les fonction- nalités du noyau XtratuM pour réaliser les interfaces logicielles spécifiées dans la norme.

Nous n’avons pas étudié en détail les noyaux temps réel dont les objectifs de conception n’étaient pas en lien avec le domaine aérospatial. Nous mentionnerons par contre les micro- noyaux basés sur le modèle L4 [40], qui peuvent servir à construire des systèmes partitionnés. Parmi la famille L4, les plus intéressants sont L4Ka::Pistachio [39] et OKL4 [50], car ces deux noyaux supportent les processeurs multicoeurs et servent à partitionner des systèmes embarqués. Dans la famille L4, on retrouve aussi seL4 [38] (« Secure Embedded L4 »), une implémentation dont il a été formellement prouvé qu’elle respecte ses spécifications d’origine.

Lorsqu’est venu le moment de choisir un point de départ pour notre adaptation, nous avons considéré les noyaux XtratuM et AIR. Ces deux noyaux offraient un modèle de partitionne-

33

ment basé sur ARINC-653 et étaient dotés d’une suite d’outils et d’exemples complets. Nous avons appris l’existence du support ARINC-653 dans POK plusieurs mois après le début de nos travaux, c’est pourquoi ne l’avons pas considéré.

Dès le départ, AIR semblait plus adéquat, car son état d’avancement était meilleur que celui de XtratuM. En effet, à ce moment, XtratuM en était à la version 2.1, qui était instable et ne possédait qu’un support minimal des fonctions de communication inter-partitions. Après avoir contacté les responsables du projet AIR, il s’avérait que le code source de ce noyau n’était pas disponible en dehors de leur projet. Il ne nous restait donc comme alternative que XtratuM. XtratuM était plus attrayant qu’AIR au niveau de la simplicité, car le support de RTEMS nécessaire à AIR était lourd et complexe. Finalement, après avoir contacté les auteurs de Xtra- tuM, nous avons réussi à obtenir le code source en licence GPL (« GNU Public License ») de XtratuM 2.2.2, une version beaucoup plus avancée que la version 2.1 évaluée initialement. En raison de la durée restante au projet, nous avons choisi de commencer immédiatement l’adap- tation de XtratuM au lieu de rechercher plus en profondeur des alternatives. Malgré certains désavantages, dont un manque de documentation dans le code source, XtratuM s’est avéré être un bon choix pour nos travaux. En effet, la simplicité de XtratuM et son niveau d’achèvement nous ont permis d’être immédiatement productifs.