TP ARINC653

En salle de TP à Télécom Paris, le TP s’effectuera sur la machine virtuelle debianVB. Elle est accessible depuis le menu « démarrez », dans VMCatalog.

Installation des outils

Les outils dont vous aurez besoin pour ce TP ne sont pas tous installés sur la machine virtuelle.

Il faut commencer par configurer le système d’exploitation ARINC653, POK.

Téléchargez POK ici. Extraire l’archive en faisant

cd <emplacement de pok.tar.gz>
tar -zxf pok.tar.gz

Téléchargez QEMU, GCC, g++, BC, emacs, et gedit:

sudo apt-get update
sudo apt-get install qemu
sudo apt-get install gcc
sudo apt-get install g++
sudo apt-get install bc
sudo apt-get install emacs
sudo apt-get install gedit
sudo apt-get install libxml-libxml-perl
sudo apt-get install make

Configurez POK en faisant:

cd <répertoire pok obtenu après désarchivage>
./misc/conf-env.pl

Vous devriez voir en fin d’affichage (sinon, demandez de l’aide):

checking system ... ok
DONE !

N.B. à chaque fois que vous ouvrez un nouveau terminal, vous devrez exporter les variables d’environnement POK_PATH et PATH comme suit :

export POK_PATH=<chemin vers répertoire pok>
export PATH=$POK_PATH:$PATH

Sur vos postes de travail (si vous ne faites pas le TP sur debianVB)

  1. Il faut que vous ayez installé Java, avec une vesion >= 1.8
  2. Si version de qemu supérieur à 2.11 (faire qemu-system-i386 –version pour vérifier), il faudra mettre à jour:
    1. pok/misc/mk/grub-floppy.mk : dans la cible launch-run, remplacer:
    $(QEMU) $(CONFIG_QEMU) $(QEMU_MISC) $(NETWORK_ARGS) -pidfile qemu.pid -hda fat:. -boot a $(QEMU_ENDCOMMAND) &

    par:

    $(QEMU) $(CONFIG_QEMU) $(QEMU_MISC) $(NETWORK_ARGS) -pidfile qemu.pid -drive format=raw,media=disk,file=fat:rw:.,if=ide,index=0 -boot a $(QEMU_ENDCOMMAND) &
  3. Vous aurez (parfois) à supprimer l’option suivante 
    -fstack-check

dans <chemin vers pok>/mk/common-x86.mk

Exemple de référence

Dans cette partie du TP, nous fournissons un exemple simple et sa description. Cet exemple vous permettra de manipuler les outils utiles pour ce TP. L’exemple illustre également la partie de l’APEX (l’API des systèmes ARINC653) dont vous aurez besoin pour ce TP.

Description de l’exemple

L’exemple que nous proposons est un système constitué de 4 partitions : part1, part2, part3 et part4. Chaque partition exécute une tâche périodique de période égale à 1 seconde. Le partitions sont ordonnancés cycliquement avec un « Major Frame » de 1 seconde et chaque partition se voit alloué successivement une « Partition Window » de 250 millisecondes.

Les communications entre partitions se font via des port de type « sampling ». Les partitions part1 et part2 ont chacune un port de sortie, nommés respectivement p1 pour part1 et p2 pour part2. La partitions part3 a deux ports d’entrée p3 et p4, et la partition part4 a un port d’entrée p5.

Dans une partition avec un port de sortie, le code de la tâche périodique exécutée toutes les secondes est simple : il affiche la valeur qu’il s’apprête à envoie sur le port, puis l’envoie. Dans une partition avec port(s) d’entré, le code de la tâche périodique exécutée toutes les secondes est simple : il lit puis affiche la (ou les données) reçue(s) sur le(s) port(s).

Les « channel » de communication permettent aux données d’être transmises depuis un port de sortie vers un port d’entrée. Dans notre exemple, le port p1 est connecté au port p3, le port p2 est connecté aux ports p4 et p5.

Enfin, nous avons définit que chaque partition se voit alloué un espace mémoire de 150000 octets.

Le schéma qui ci dessous résume l’architecture considérée dans cet exemple.

reference_example

FIGURE 1

Description de l’archive

L’archive disponible ici fournit les artefacts correspondants à ce système partitionné.

L’archive est constitué d’un répertoire input et d’un répertoire output.

Le répertoire input contient

  • un fichier xml (example-conf.xml)
  • un Makefile
  • des sous-répertoires (part1, part2, part3 et part4). Chacun de ces sous-répertoires contient également un fichier Makefile et un fichier main.c

Le répertoire output est vide.

Les artefacts que nous allons décrire dans la suite de cette partie sont le fichier XML de configuration et le fichier main.c. Les Makefiles pourraient également être considérés mais vous n’aurez pas besoin d’en éditer dans la suite du TP.

Le fichier XML contient la configuration de l’architecture décrite dans la section précédente: celle illustrée sur la FIGURE 1. Ouvrez ce fichier et lisez le de sorte à faire une correspondance entre la description de l’exemple et le contenu du fichier.

Le fichier part1/main.c contient le code d’initialisation, ainsi que le code de la tâche périodique de la partition part1. Le point d’entrée de la partition est la fonction main, fonction qui sera invoquée à l’initialisation de la partition. Le code de cette fonction crée la tâche périodique de la partition avec une période correspondant à 1 seconde. Le point d’entrée associé à cette tâche (ou « process » selon le vocabulaire ARINC653) est la fonction process1. Cette fonction sera exécutée à chaque « dispatch » de la tâche périodique.

Première manipulation des outils

Nous allons maintenant produire l’image du système et l’exécuter sur un émulateur de carte : QEMU.

Dans un terminal avec les variables POK_PATH et PATH mises à jour (comme indiqué tout en haut du sujet de TP) déplacez vous vers le répertoire input, puis exécutez :

$make

Si, à l’issue de la compilation vous obtenez une erreur: bc: command not found, alors exécutez la commande: sudo apt-get install bc

L’exécution de make a pour effet de

  1. générer, à partir du fichier XML de configuration, des fichiers de code source C dans le répertoire output qui était vide jusque là ;
  2. de compiler le noyau du système d’exploitation partitionné POK, configuré par ces fichiers générés ;
  3. de compiler le code C des partitions part1, part2, part3, et part4.

Vous pourrez ensuite lancer le système sur l’émulateur QEMU comme suit : depuis le terminal, déplacez vous vers le répertoire input, puis exécutez :

$make run

Pour faciliter la visualisation du résultat, vous pouvez rediriger la sortie standard des partitions vers un fichier en procédant comme suit :

$make run QEMU_MISC="-nographic -serial /dev/stdout > pok_exec.trace"

Le fichier pok_exec.trace contiendra la sortie standard des partitions. Il faudra alors terminer le processus qemu en utilisant la commande kill ou killall.

Vous devriez obtenir la trace d’exécution suivante :

partition part1 sends value through port p1: 1
partition part2 sends value through port p2: 1
partition part3 received value through port p3: 0
partition part3 received value through port p4: 0
partition part4 received value through port p5: 0
partition part1 sends value through port p1: 2
partition part2 sends value through port p2: 2
partition part3 received value through port p3: 1
partition part3 received value through port p4: 1
partition part4 received value through port p5: 1
partition part1 sends value through port p1: 3
partition part2 sends value through port p2: 3
partition part3 received value through port p3: 2
partition part3 received value through port p4: 2
partition part4 received value through port p5: 2
partition part1 sends value through port p1: 4
partition part2 sends value through port p2: 4
partition part3 received value through port p3: 3
partition part3 received value through port p4: 3
partition part4 received value through port p5: 3
partition part1 sends value through port p1: 5
partition part1 sends value through port p1: 5
partition part3 received value through port p3: 4
partition part3 received value through port p4: 4
partition part4 received value through port p5: 4

Exercice

configuration temporelle de process ARINC

La société pour laquelle vous travaillez aujourd’hui souhaite faire réaliser 4 applications par des fournisseurs différents et les intégrer sur un unique calculateur sur lequel est déployé le système partitionné POK.

Ces applications sont appelées:

  • Navigation,
  • Radar,
  • Logging,
  • Display

Voici la configuration des tâches de chaque application, telle que négociée avec vos fournisseurs :

  • Navigation : 2 tâches, de période 50 ms et 300 ms. Un budget de 10 ms toutes les 100 ms est nécessaire pour exécuter le code de cette application.
  • Radar : une tâche de période 100 ms. Un budget de 25 ms toutes les 100 ms est nécessaire pour exécuter le code de cette application.
  • Logging : une tâche de période 300 ms. Un budget de 30 ms toutes les 100 ms est nécessaire pour exécuter le code de cette application.
  • Display : deux tâches, de période 100 ms, 300 ms. Un budget de 35 ms toutes les 100 ms est nécessaire pour exécuter le code de cette application.

Déterminez la « major frame » du système et la configuration des partition window pour chaque application.

Nous supposons que l’application Radar communique avec l’application Navigation, qui communique avec l’application Display. Cette chaine de communication met à jour l’affichage produit par le composant Display. Ces communications se feront via des ports de type « sampling » car chaque application n’a besoin de la dernière valeur produite pour fonctionner correctement. Pour simplifier, nous supposons que les applications s’échangent de simples entiers.

L’étude de la trace d’exécution de l’exemple de référence montre que les communications entre partitions sont « décalées » : lorsqu’une partition émettrice envoie la valeur 3, la partition réceptrice reçoit la valeur 1 qui avait été produite au cycle précédent.

Ceci vient du fait que par défaut les vidanges (ou « flush ») de ports sont fait entre deux itérations correspondant chacune à une « Major Frame ». La figure ci-dessous illustre ce comportement.

flush_maf

FIGURE 2

Il est possible de modifier la configuration du système d’exploitation pour corriger cela. POK offre deux mécanismes de configuration classiques dans les systèmes partitionnés:

1. la vidange peut se faire à la fin de chaque « partition window ». La figure ci-dessous illustre ce comportement sur notre exemple de référence:

flush_window

Pour activer cette configuration, il faut modifier le fichier XML en ajoutant un attribut flush_type= »window » à la configuration du module ARINC653.

Exemple:

<ARINC653_Module major_frame="1000" flush_type="window">
...
</ARINC653_Module>

2.  la vidange peut se faire de façon périodique, avec une période MIF telle que (i) pour tout entier k, k*MIF correspond à une date de changement de partition window et (ii) MAF est divisible par MIF. La figure ci-dessous illustre ce comportement sur notre exemple de référence, avec une période MIF à 500 ms:

flush_mif

FIGURE 4

Pour activer cette configuration, il faut modifier le fichier XML en ajoutant (i) un attribut flush_type= »minor_frame » et (ii) un attribut minor_frame= »500″ à la configuration du module ARINC653.

Exemple:

<ARINC653_Module major_frame="1000" flush_type="minor_frame" 
minor_frame="500">
...
</ARINC653_Module>

Instructions: complétez les fichiers fournis ici pour simuler l’exécution du système. Configurez l’ordonnancement et les communications. Veillez à minimiser le temps de transmission des données entre le Radar et le Display, tout en ne surchargeant pas le processeur d’appels systèmes inutiles.

N.B: les noms des ports dans le fichier XML doivent correspondre au noms des ports dans les fichiers source .c

Solution: la solution des exercices 1 et 2 est disponible ici.