ARINC 653

Publication originale du 04/10/1996.

Publication du 16/10/2003. L'évolution majeure de cette révision est l'introduction de l'IMA (§1.3.1)

Publication du 07/03/2006. Le changement majeur a été la division de la norme en trois parties :

• Part1 : interface standard
• Part2 : interfaces optionnelles d'extension
• Part3 : procédure de test de conformité

Cette version précise certains points. Le fait que le processus d'initialisation continue à s'exécuter ou pas en mode NORMAL est dépendant de l'implémentation.

Le Standard Airbus est un exemple de standard industriel né en 2001/2002, entre les publications A653 et A653-1, dans le cadre des premiers développements IMA sur le programme A380. La publication A653-1 s'inspire largement du standard Airbus. La portabilité d'une application n'est donc que partielle entre ce standard industriel et la norme A653.

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_..... 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 laisser le processus s'exécuter après l'appel de ce service, mais l'application ne doit en aucun cas dépendre de ce point pour garantir sa portabilité.

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, date d'échéance de processus) ou synchrone (violation mémoire) est détecté 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 où 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 de la conception de ce processus.

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

• COLD_START
• WARM_START
• NORMAL
• IDLE

Dans les modes 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 élus 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.

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 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é à 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é.

La cible est généralement composée d'un microprocesseur, de timers et d'horloges précises, de RAM (Mémoire Vive), de ROM (Mémoire morte), et d'entrée sorties.

Elle fournit les services de "bas niveau" pour partitionner les ressources de la cible. Elle utilise généralement les services MMU (Memory Management Unit) de la cible pour effectuer le partitionnement spatial, c'est-à-dire exclure l'accès mémoire à une partition depuis une autre partition. Ce mécanisme peut être en outre être effectué / complété par un ASIC externe sur le bus microprocesseur / mémoire. Le partitionnement temporel est généralement effectué par des timers matériels internes au microprocesseur ou dans un ASIC externe piloté par un oscillateur à quartz précis. Le séquencement temporel des partitions est configuré statiquement.

Les drivers permettent l'abstraction de l'interface des entrées / sorties avioniques (bus A429, bus AFDX, USB, CAN (Controller area network), entrées sorties numériques et analogiques, mémoire non volatile)

Les services sont répartis en 7 catégories :

1. Gestion de la partition
2. Gestion des processus
3. Gestion du temps
4. Gestion de la mémoire
5. Gestion des communications inter-partition
6. Gestion des communications intra-partition
7. Gestion des pannes

Chaque catégorie comprend au moins un service de création de ressource. Son implémentation peut être statique ou dynamique. Si elle est dynamique, l'implémentation devra s'assurer de la cohérence au domaine d'utilisation (disponibilité des ressources physiques…).

L'ensemble des services retourne un paramètre RETURN_CODE pointé en cas d'exception. Le type énuméré RETURN_CODE prend les valeurs suivantes :

• NO_ERROR : requête valide et le service est effectuée nominalement
• NO_ACTION : l'état du système est inchangé par l'appel du service
• NOT_AVAILABLE : le service est temporairement indisponible
• INVALID_PARAM : au moins un paramètre du service est invalide
• INVALID_CONFIG : au moins un paramètre du service est incompatible de la configuration courante du système
• INVALID_MODE : le service est incompatible du mode courant du système
• TIMED_OUT : le délai imparti a l'exécution du service a expiré. L'état du système n'a pas été modifié par le service.

La valorisation des paramètres "OUT" est effective si et seulement si le RETURN_CODE est égal à NO_ERROR.

La partition est définie par son mode et sa condition de démarrage.

Le mode est un énuméré dans :

• IDLE : la partition est arrêtée. Aucun process n'est exécuté. Une implémentation classique est une boucle infinie, attendant une interruption de changement de partition ou un redémarrage matériel.
• COLD_START : la partition est en cours d'initialisation. Elle utilise ce mode pour effectuer un démarrage "lent", c'est-à-dire pour effectuer tous les tests requis par les analyses "safety".
• WARM_START : la partition est en cours d'initialisation. Elle utilise ce mode pour effectuer un démarrage "rapide", souvent requis en vol.
• NORMAL : l'ordonnancement des process est effectué dans ce mode.

Les services :

• GET_PARTITION_STATUS : retourne le statut courant de la partition
• SET_PARTITION_MODE : change le mode courant de la partition

Le passage en mode normal élabore les données suivantes :

1. les points de relaxation des process périodiques sont positionnés au début de la prochaine période de la partition (pour synchroniser les process périodiques), en ajoutant de délai éventuellement demandé par le service DELAYED_START
2. Les dates d'échéance des process sont positionnées.

• GET_PROCESS_ID : retourne un identifiant unique pour le process dont le nom est fourni en paramètre
• GET_PROCESS_STATUS : retourne l'état du processus dont l'identifiant est en paramètre
• CREATE_PROCESS : créé le processus dont le nom est en paramètre
• SET_PRIORITY : modifie la priorité du processus dont l'identifiant est en paramètre
• SUSPEND_SELF : suspend le processus courant (RUNNING)
• SUSPEND : suspend le processus dont l'identifiant est en paramètre
• RESUME : relaxe le processus dont l'identifiant est en paramètre
• STOP_SELF : termine le processus courant (RUNNING)
• STOP : termine le processus dont l'identifiant est en paramètre
• START : démarre le processus dont l'identifiant est en paramètre
• DELAYED_START : démarre le processus périodique dont l'identifiant est en paramètre, avec un offset temporel
• LOCK_PREEMPTION : verrouille la préemption pour protéger une section critique
• UNLOCK_PREEMPTION : déverrouille la préemption
• GET_MY_ID : retourne l'identifiant unique du processus dont le nom est fourni en paramètre

• TIMED_WAIT : met en attente le processus courant pendant un temps donné.
• PERIODIC_WAIT : met en attente le processus périodique jusqu'à son prochain point de relaxation
• GET_TIME : retourne le temps absolu
• REPLENISH : ajoute un budget de temps à la date d'échéance du processus

la partition est libre de sa propre gestion mémoire. Aucun service n'est spécifié à cette fin.

• CREATE_QUEUING_PORT
• SEND_QUEUING_MESSAGE
• RECEIVE_QUEUING_MESSAGE
• GET_QUEUING_PORT_ID
• GET_QUEUING_PORT_STATUS

• CREATE_SAMPLING_PORT
• WRITE_SAMPLING_MESSAGE
• READ_SAMPLING_MESSAGE
• GET_SAMPLING_PORT_ID
• GET_SAMPLING_PORT_STATUS

• REPORT_APPLICATION_MESSAGE
• CREATE_ERROR_HANDLER
• GET_ERROR_STATUS
• RAISE_APPLICATION_ERROR

• CREATE_BUFFER
• SEND_BUFFER
• RECEIVE_BUFFER
• GET_BUFFER_ID
• GET_BUFFER_STATUS

• CREATE_BLACKBOARD
• DISPLAY_BLACKBOARD
• READ_BLACKBOARD
• CLEAR_BLACKBOARD
• GET_BLACKBOARD_ID
• GET_BLACKBOARD_STATUS

• CREATE_EVENT
• SET_EVENT
• RESET_EVENT
• WAIT_EVENT
• GET_EVENT_ID
• GET_EVENT_STATUS

• CREATE_SEMAPHORE
• WAIT_SEMAPHORE
• SIGNAL_SEMAPHORE
• GET_SEMAPHORE_ID
• GET_SEMAPHORE_STATUS