Modélisation de plate-forme avionique pour exploration de performance en avance de phase

Suivant la loi de Moore, la miniaturisation des composants électroniques a conduit à une augmentation du nombre de composants intégrés au sein d’une puce, augmentant par là ses performances. Le domaine avionique, qui constitue notre cadre de recherche, a été confronté comme tous les domaines industriels à la nécessité d’augmenter la puissance de calcul de ses systèmes, afin de pouvoir traiter un plus grand nombre d’applications. Toutefois, l’intégration de nouveaux composants ou nouvelles technologies ne peut se faire qu’en adaptant ceux-ci aux contraintes spécifiques du domaine, notamment les contraintes de sécurité et de consommation énergétique.

Plate-forme avionique : nos travaux portent sur les systèmes que l’on appelle plate-forme avionique. Il s’agit d’un système embarqué temps réel critique, composé de plusieurs calculateurs chargés d’exécuter les fonctions avioniques qui permettent le bon déroulement du vol. Comme le précise [Brunette et al., 2005], ces calculateurs sont eux-mêmes des sous-systèmes avioniques, composés d’éléments matériels, d’un système d’exploitation et hébergeant une ou plusieurs applications. En tant que système embarqué, la plate-forme doit pouvoir fonctionner avec des contraintes de ressources limitées, comme un espace mémoire limité ou encore une consommation énergétique autorisée plafonnée. La notion de temps réel implique que le système doit exécuter ses fonctions dans le respect de contraintes temporelles (deadlines), au risque de défaillances graves. Enfin, l’aspect critique induit que le non respect de ces contraintes temporelles peut avoir des conséquences dramatiques allant jusqu’au crash de l’avion et la perte de vies humaines.

Au niveau logiciel, le développement d’une application avionique se fait suivant le respect de la norme DO-178B, ”Règlementation pour le développement de logiciels dans le secteur aéronautique” [RTCA, 1992]. Dans l’optique de la certification, chaque application doit, en plus de fournir certains documents de conception, être conforme à certains objectifs de tests et de couverture de tests. Il existe plusieurs niveaux de criticité au sein de la DO-178B, appelés niveaux DAL (Design Assurance Level), traduisant les conséquences d’une erreur dans le fonctionnement d’une application :

• Niveau DAL A : conséquences catastrophiques ;
• Niveau DAL B : conséquences dangereuses ;
• Niveau DAL C : conséquences majeures ;
• Niveau DAL D : conséquences mineures ;
• Niveau DAL E : sans effet sur la sécurité.

A titre d’exemple, une application chargée du contrôle des commandes de vol sera d’un niveau DAL A, tandis que les applications de gestion des services de détente des passagers (projection de films, etc.) seront DAL E. Ainsi, les objectifs de tests et de couverture de tests sont différents suivant le niveau DAL de l’application. Au niveau le plus élevé (niveau A), la couverture de code par les jeux de tests doit être complète, c’est-à-dire qu’elle doit couvrir toutes les conditions d’exécution et vérifier que le comportement dans telle condition est conforme au scénario prévu.

Architecture fédérée : auparavant, l’exécution des applications avioniques se faisait au travers d’une architecture dite fédérée.  chaque calculateur a la charge d’exécuter une unique application. De plus, les communications entre applications de chaque calculateur se font via un canal dédié. Cette architecture implique que chaque calculateur est conçu et optimisé pour l’application qu’il doit exécuter, de même que les interfaces et liens de communications doivent être adaptés aux besoins des échanges à effectuer.

Architecture intégrée : lors de la dernière décennie, une nouvelle architecture a fait son apparition . Cette architecture suit un nouveau principe dit d’architecture intégrée ou IMA (Integrated Modular Avionics). Les enjeux de cette nouvelle architecture sont de concevoir des calculateurs plus génériques, configurables, et pouvant exécuter plusieurs applications dont le niveau DAL est différent. L’IMA a pour but de réduire l’empreinte environnemental de la plate-forme : moins de calculateurs implique une consommation d’énergie et un poids réduits, et moins d’espace occupé dans l’appareil [Li and Xiong, 2009]. Un autre aspect qui accompagne l’IMA concerne les communications entre les calculateurs. Auparavant entièrement dédiées, certaines communications se font désormais au travers d’un réseau standardisé, l’ARINC-664, que présentent [Alena et al., 2006] et [Alena et al., 2007].

ARINC-664 : réseau avionique : l’ARINC-664, via le standard [Aeronautical-RadioInc, 2002c] définit un réseau déterministe basé sur Ethernet (norme 802.3). Comme le précise la partie 2 du standard [Aeronautical-Radio-Inc, 2002b], il assure la bonne transmission des données d’un calculateur à l’autre dans le respect de contraintes temporelles. Le fait de regrouper la majeure partie des communications au sein de ce réseau autorise là aussi une réduction de l’espace occupé, et sa réutilisation dans différentes architectures.

Concernant la description physique du réseau, celui-ci est composé de terminaux et de switchs. Les terminaux communiquent directement avec le calculateur et envoient les données sur le réseau. Les switchs sont chargés de router les messages vers le bon terminal. Concernant la partie logique, des ”Virtual Links” (VL), ou chemins logiques, sont définis lors de la configuration du réseau. Ils représentent les différentes routes utilisées pour faire transiter les données d’un terminal à un autre. [Charara, 2007] nous donne plusieurs exemples de configurations d’un réseau ARINC664. La partie 1 du standard, [Aeronautical-Radio-Inc, 2002a], définit que chaque chemin logique reçoit une priorité et une bande passante, permettant d’acheminer les données en un temps maximum borné et connu.

ARINC-653 : interface de programmation standard pour architecture intégrée : le principe d’architecture intégrée permet d’assurer une indépendance entre le développement des applications et le développement de la plate-forme d’exécution (système d’exploitation et architecture matérielle). En effet, une application avionique comporte deux ensembles d’instructions : les instructions de calcul et les appels aux services du système d’exploitation. Ce dernier offre un ensemble de services standardisés par le standard ARINC-653 [Aeronautical-Radio-Inc, 2006] .

Le standard ARINC-653 [Aeronautical-Radio-Inc, 1997] permet de faire cohabiter les différentes applications d’un même calculateur tout en respectant les principes de sûreté. Car si l’IMA permet de réduire le nombre de calculateurs en regroupant plusieurs applications sur un nombre réduit d’entre eux, cela ne doit pas se faire au détriment de la performances ni de la sûreté. Une application doit avoir accès aux ressources matérielles suffisamment souvent, et ce malgré la ”concurrence” des autres applications sur le même calculateur. De même, une erreur lors de l’exécution de l’une de ces applications ne doit pas avoir de conséquences sur les autres applications hébergées sur le même calculateur. Afin de respecter ces exigences de sûreté, le standard ARINC-653 définit le principe de partitionnement spatial et temporel. Chaque application avionique est découpée en une ou plusieurs partitions, ”boites” logicielles isolées les unes des autres. Cette isolation permet de contenir une erreur d’exécution au sein d’une partition, sans contagion aux autres applications. Ainsi pour résumer, nous avons deux types de partitionnement :

• Le partitionnement spatial : chaque partition logicielle possède son propre espace mémoire dans lequel elle seule peut aller écrire ;
• Le partitionnement temporel : chaque partition s’exécute au moins une fois pendant la MAF. Pendant cette période, la partition a accès à l’ensemble des ressources matérielles auxquelles elle est ”abonnée” (processeur, zone mémoire dédiée et les entrées-sorties auxquelles elle a l’autorisation d’accéder).