ARINC 653 - Définition

Introduction

ARINC 653 est un standard de partitionnement temporel et spatial de ressources informatiques. Ce standard définit également des interfaces de programmation et de configuration qui permettent d'assurer l'indépendance de l'application vis-à-vis du logiciel et du matériel sous-jacent.

Le principe de partitionnement permet la coexistence sur la même plateforme, de fonctions avioniques de niveaux DO-178B DAL (Design Assurance Level) différents, et permet un processus de qualification incrémentale de ces fonctions, ainsi qu'un processus de ségrégation des fournisseur de fonctions.

Il définit une API de portabilité pour les logiciels applicatifs avioniques adoptée notamment par les architectures AMI (Avionique modulaire intégrée).

Généralités

Une fonction avionique est réalisée par une décomposition logicielle et matérielle traçable par rapport aux spécifications de cette fonction. Dans le cadre d'une architecture IMA adoptant l'interface A653, cette décomposition est effectuée de la manière suivante:

• le logiciel applicatif décomposé en une ou plusieurs partitions exécutées par une ou plusieurs plateformes dont l'interface est l'A653.
• une ou plusieurs plateformes IMA composée d'une interface A653, de son implémentation logicielle et matérielle.

Logiciel applicatif

Chaque partition a son propre espace mémoire et temporel, la ségrégation étant assurée par le système d'exploitation. Au sein de chaque partition, le multi-tâches est autorisé. Le langage d'implémentation recommandé par la norme est Ada, bien que le C soit également mentionné. Un simple fichier d'interface des services est fourni en annexe.

La portabilité de l'application est assurée par l'utilisation stricte des services de l'API standard, et ne doit en aucun cas reposer sur des comportements liés à l'implémentation matérielle et logicielle de la plateforme.

L'initialisation

L'initialisation de la partition A653 est fondamentale. Elle a pour objectif la création des ressources, la gestion des modes de démarrage et des pannes (avec le Error Handler).

La création des ressources (PROCESS, EVENT, SEMAPHORE...) est effectuée par l'appel des services CREATE_xxxx. L'appel de ces services vérifie l'existence et la disponibilité des ressources demandées avant l'attribution d'un handler ou identifiant utilisable par l'application.

L'initialisation est effectuée au sein d'un processus pourvu d'une pile, et que l'on peut assimiler au "main" d'une application native. Ce processus se termine par l'appel du service SET_PARTITION_MODE.

L'A653-2 précise que l'implémentation de la plateforme peut laisse le processus s'exécuter après l'appel de ce service, mais l'application ne doit en aucun dépendre de ce point pour garantir sa portabilité.

Le Error Handler

Le Error Handler est créé par l'appel du service CREATE_ERROR_HANDLER dans la phase d'initialisation de la partition.

Dès lors que le Error Handler a été créé avec succès, il peut être exécuté en cas d'exception.

Le Error Handler est un processus non préemptible. Il peut être vu comme le processus de plus forte priorité.

Lorsqu'un évènement (exception) asynchrone (interruption matérielle, deadline de processus) ou synchrone (violation mémoire) est détectée par la plateforme A653, le processus Error Handler préempte le processus en cours d'exécution.

Ce processus est censé traiter la cause de l'exception (ex: stopper le processus fautif, envoyer un message de maintenance). Lorsque le Error handler se termine par l'appel du service STOP_SELF, le scheduler est appelé et élit le processus READY le plus prioritaire.

La norme A653 ne précise pas de comportement dans le cas ou le Error Handler n'effectuerait pas une action qui traite la cause de l'exception. Une implémentation possible de l'A653 est de ré-exécuter immédiatement le Error Handler, ce qui mènerait à une boucle infinie entre le processus fautif et le Error Handler.

Le Error Handler dispose du service GET_ERROR_STATUS pour obtenir des informations sur la source de l'exception et du contexte d'apparition (compteur de programme, identifiant de processus)

Le Error Handler joue un rôle particulier avec le processus d'initialisation. Le comportement opérationnel d'une partition avionique dépend beaucoup du design de ce processus.

La gestion de mode

La partition dispose d'un attribut de mode qui prend sa valeur dans:

• COLD_START
• WARM_START
• NORMAL
• IDLE

Dans les mode COLD_START et WARM_START, seul le processus d'initialisation est exécuté.

Dans le mode NORMAL, le processus d'initialisation est stoppé, et les autres processus sont elus par le scheduler selon leur priorité.

Dans le mode IDLE, aucun processus n'est exécuté. Ceci étant une vision logique, l'implémentation peut être d'exécuter un processus caché de priorité minimum effectuant une boucle infinie.

Le service SET_PARTITION_MODE permet de transiter parmi ces 4 états et peut être appelé par n'importe quel processus.

Seul l'état IDLE est irréversible pour la partition. Seul un évènement externe à la partition (redémarrage de la plateforme) peut la faire changer de mode.

Les processus ou PROCESS

Une partition comprend au moins un processus. Un processus est une unité logicielle qui s'exécute en concurrence avec les autres processus de la partition. Un processus dispose d'attributs statiques et dynamiques.

Les attributs statiques:

• Le nom
• Le point d'entrée
• La taille de la pile
• La priorité de base
• La période (une valeur particulière est utilisée pour APERIODIC)
• La capacité temporelle
• Le type de contrôle d'échéance (matériel par interruption timer ou logiciel par polling)

Les attributs dynamiques:

• La priorité courante
• La date d'échéance (DEADLINE)
• L'état du processus

L'état du processus prend les valeurs suivantes:

• DORMANT : arrêté
• READY : présent dans la liste des processus disponibles pour l'exécution
• WAITING : en attente, absent de la liste des processus disponibles pour l'exécution
• RUNNING : en cours d'exécution

L'état WAITING dispose de sous-états qui précisent la raison de mise en attente:

• attente sur suspension
• attente d'une ressource
• attente du mode NORMAL (en mode COLD ou WARM)
• attente de la période suivante...

Le séquencement des processus est préemptif a priorité fixe. Le séquenceur de processus est soit appelé par une interruption matérielle (timer), soit induit par appel de certains services de l'API. Le séquenceur dispose de la liste de processus READY, et examine leur priorité courante afin d'élire le processus le plus prioritaire qui passera à l'état RUNNING. Le processus précédemment à l'état RUNNING passant à l'état READY.

L'utilisation des services

L'utilisation de certains services doit être très scrupuleuse:

SUSPEND et RESUME : ces deux services permettent de suspendre et résumer un processus P2 depuis un processus P1. Or si le processus P1 devient défaillant et s'arrête, le processus P2 est condamné a rester suspendu indéfiniment.

STOP : Si un processus P1 fait l'acquisition d'une ressource R1, puis est stoppé par P2. La ressource R1 restera inaccessible pour les autres processus indéfiniment. Il n'est d'ailleurs pas recommandé à l'implémentation de STOP, de libérer les ressources acquises par P1, car elles ont probablement été laissées dans un état indéterminé.