Modélisation de systèmes avioniques en AADL

Les systèmes avioniques sont composés de différents équipements, composés eux-mêmes de matériel et de logiciel, qui interagissent ensemble pour accomplir certaines fonctionnalités. L’interaction ou l’échange d’informations entre ces équipements est assuré par des interfaces physiques/logiques. Pour avoir une bonne intégration et coopération entre les équipements avioniques, il faut que les interfaces soient décrites d’une manière claire, précise, complète et non ambiguë. Dans le milieu de l’aéronautique, on capture souvent les informations liées aux interfaces dans des documents de contrôle d’interface (Interface Control Document, ICD). Les équipements avioniques sont conçus et fabriqués par différents fournisseurs, ce qui rend ces documents plus complexes dans l’absence d’un langage commun pour la définition des ICD et d’une spécification standard de ce qu’il faut préciser dans un ICD ou de son organisation (Louadah, H. et al., 2014).

Le traitement manuel des ICD hétérogènes est compliqué puisqu’il n’y a pas de solution standard, commune et automatisée pour la gestion de ces documents. Ceci peut engendrer des problèmes dans l’intégration des équipements des systèmes avioniques, considérés comme critiques. De plus, le processus de production et de traitement des ICD n’est ni standardisé ni automatisé, ce qui entraîne des risques d’erreurs et une lenteur significative dans la conception, la fabrication et l’intégration des équipements avioniques.

Dans les systèmes avioniques, il y a essentiellement deux architectures couramment utilisées: l’architecture fédérée, où chaque fonction avionique possède ses propres ressources et sa plateforme d’exécution, et l’architecture modulaire intégrée (Integrated Modular Avionics, IMA) qui est basée sur un environnement partitionné où plusieurs fonctions avioniques sont exécutées par une plateforme d’exécution partagée (Watkins, C. B., & Walter, R., 2007). Chacune de ces architectures a des besoins différents et spécifiques en termes d’ICD.

Les architectures des systèmes avioniques 

Un système avionique, d’un point de vue fonctionnel, est un ensemble de sous-systèmes assurant diverses fonctionnalités, comme la navigation, le pilotage, l’atterrissage, la communication (entre avions, entre différents éléments de l’avion ou entre l’avion et la terre), le contrôle de vol, la connaissance de l’environnement, etc.

D’un point de vue architectural, on retrouve principalement deux architectures dans les systèmes avioniques: l’architecture fédérée et l’architecture modulaire intégrée (IMA), cette dernière étant relativement récente par rapport à la première. L’IMA, considérée comme successeur des architectures fédérées, a été adoptée pour faire face aux divers défis de l’architecture classique fédérée (Alena R. et al., 2007).

L’architecture classique des systèmes avioniques a été conçue en définissant des fonctions qui sont implémentées comme des unités fonctionnelles fédérées où chaque unité fonctionnelle est une application qui possède ses propres ressources ou plateforme matérielle, et qui accomplit des fonctions bien déterminées. Il s’agit dans ce cas d’avoir un calculateur par unité fonctionnelle. La communication entre ces calculateurs est effectuée par des canaux dédiés,De même, les interfaces qui assurent l’échange d’information entre ces applications sont conçues selon les besoins de communication entre les applications. Dans cette figure, chaque interconnexion représente un bus de données possédant un seul équipement émetteur et un ou plusieurs équipements récepteurs. Par exemple, l’équipement EADI #1 reçoit des informations de neuf autres équipements. Il faut donc neuf bus de données pour assurer la communication.

Les fonctionnalités demandées en avionique sont en pleine croissance, il s’ensuit un accroissement exponentiel de la complexité des systèmes fédérés à cause de l’augmentation des nombres de calculateurs et du câblage, entraînant aussi des problèmes de poids, de dimension, de consommation et de coût (Alena R. et al., 2007). De plus, ces systèmes ne sont pas assez flexibles pour permettre des modifications ou extensions. Grâce à l’évolution de la puissance des processeurs, la solution apportée par l’IMA est fondée sur le principe de l’exécution de plusieurs fonctions avioniques sur le même calculateur. Une architecture IMA est donc constituée de deux éléments essentiels: des calculateurs génériques et configurables pour l’exécution de plusieurs applications et un réseau de communication partagé assurant l’échange de données entre les calculateurs. Ces calculateurs sont des unités d’exécution standardisées ayant leurs propres ressources (processeur, mémoire, …), appelés Line Replaceable Module (LRM) et regroupés généralement sur des bâtis (racks) . En IMA, il y a trois types de LRM :

• le Core Processing Module (CPM) qui est un module de calculs chargé de l’exécution des applications avioniques;
• l’Inpout Output Module (IOM) qui permet la communication entre les sous-systèmes hétérogènes (IMA et non IMA);
• le GateWay Module (GWM) qui permet la communication entre les différentes étagères de LRM.

Standards avioniques pertinents 

Aeronautical Radio, Incorporated (ARINC) est une société détenue par les principaux constructeurs et compagnies aéronautiques. Elle définit et publie les principaux standards de communications des aéronefs portant sur les réseaux, les bus et les protocoles utilisés dans les systèmes avioniques. Dans cette section nous présentons trois standards pertinents dans notre projet: un standard lié à l’architecture fédérée (ARINC 429) et deux standards liés à l’architecture IMA (ARINC 653 et ARINC 664). Nous nous concentrons sur ces deux derniers standards puisque notre recherche est focalisée sur l’architecture IMA.

ARINC 429
Ce standard décrit le bus de données qui permet d’acheminer des données entre calculateurs. La topologie de ces bus est très simple: les calculateurs sont connectés point à point par une liaison directe unidirectionnelle. Ces types de bus sont utilisés dans le contexte fédéré où les communications sont dédiées. Pour chaque bus ARINC 429, le standard exige qu’il y ait un seul émetteur et un ou plusieurs récepteurs .

ARINC 653
Dans une architecture IMA, plusieurs applications logicielles sont hébergées dans une seule plateforme matérielle intégrée, appelée aussi module  , où peuvent se trouver un ou plusieurs microprocesseurs (Samolej, S., 2011). Chaque application est décomposée en plusieurs partitions par mesure de protection et de séparation fonctionnelle entre ces applications (Ananda C.M. et al., 2013). Chaque partition est composée d’un ou plusieurs processus et chaque processus est de même composé d’une ou plusieurs tâches. Le standard ARINC 653 est adopté par l’IMA pour la gestion du partitionnement spatial et temporel des ressources favorisant ainsi une bonne portabilité des applications avioniques.

Le partitionnement spatial vise à interdire tout partage de ressources physiques entre partitions. Il faut s’assurer que chaque partition a ses propres ressources (chaque ressource partageable est allouée à une seule partition) et qu’aucune partition n’affecte ou ne change les données allouées à une autre. Des exemples de ressources sont: le processeur, la mémoire, les bus de données, etc.

Le partitionnement temporel vise à accorder pour chaque partition un accès exclusif au processeur pendant un laps du temps. Un ordonnanceur gère le plan d’exécution entre les partitions et assigne des tranches de temps pour chacune. L’ordonnancement est géré par une fenêtre ou un bloc d’activation majeur (Major Frame Period) ayant une durée fixe et cyclique. Une fenêtre d’activation majeure est prédéfinie pour chaque module durant laquelle un ensemble de partitions seront exécutées en allouant pour chacune d’elles un laps de temps.

L’objectif de ce standard est de définir une interface exécutive d’application (APplication EXecutive, APEX) entre le noyau logiciel du module (Core Software) et l’application logicielle (ARINC 653 Part 0). L’APEX fournit une interface commune pour l’application logicielle en offrant des requêtes et des services de gestion normalisés et groupés en souscatégories: gestion de partition, gestion de processus, gestion du temps, communication inter et intra-partition, gestion de la mémoire, monitorage de la santé du système ou gestion des pannes.