UMR CNRS 7253

Dans le prototypage rapide, l'objectif est de valider une approche pragmatique de la programmation graphique sur système temps réel. Nous arrivons à augmenter la productivité d'ingénierie pour un gain important en temps et en efficacité humaine afin de réaliser une preuve de concept. Dans notre cas, l'optimisation n'est pas primordiale même si on peut d'ors et déjà améliorer l'implémentation dans les codes de chaque bloc. La programmation graphique facilite le travail de l'ingénieur dans la synthèse procédurale en diminuant le facteur humain dans le sourcing. A partir du fonctionnement diagrammatique, un programme doit également doter d'un comportement prédictible et simulable de l'ensemble par un simulateur externe. Pour toutes ces raisons, nous souhaitons utiliser Matlab Simulink pour réaliser la saisie rapide des schémas fonctionnels.

Concernant le système temps réel, nous avons choisi un micro-noyau compatible Linux, Xenomai. Le temps réel est une brique importante dans la gestion des modules. Xenomai est une extension libre du noyau Linux lui apportant des fonctionnalités temps réel dures. Plus performant que les autres noyaux RT, Xenomai est libre de son utilisation. Il apporte une approche unifiée entre programmation noyau et utilisateur sous Linux. Il utilise la couche de virtualisation Adeos. Il introduit le concept de machine virtuelle en programmation temps réel. Enfin, il permet de disposer de plusieurs interfaces de programmation, appelées skins. Il fournit des API génériques pour la mise en oeuvre des programmes écrits pour les autres systèmes temps réels. De cette façon, certaines fonctionnalitées d'une API propriétaire peut être émulée par Xenomai.

Le protocol de communication utilisé par défaut pour le contrôle et communication intercomposants dans Matlab est l“External Mode”. Ce protocol est basé sur TCP/IP, en mode connecté. Nous avons alors pensé que dans certains cas l'utilisation d'un protocol UDP/IP, en mode non connecté semble plus adapté dans le fonctionnement temps réel des programmes. En outre, cela nous permet aussi de s'affranchir certaines contraintes sur la propriété intellectuelle de l'External Mode. Nous avons décidé d'élaborer le protocol NETRPC, basé sur UDP/IP. Le protocol NETRPC utilise 2 mécanismes principaux pour la communication intercomposants. Le premier est la communication par messages spontanés. Le deuxième est la communication par canal permanent. Dans tous les cas, les systèmes possèdent une table de liste des fonctions. Lorsque les systèmes établissent la communication, ils doivent rechercher les ports ouverts dans cette table. Ce service de renseignement est démarré au début de l'exécution du programme. Il se trouve sur un port fixe, soit le port RPC_SERVICE_PORT. Pour chaque canal permanent ouvert, un port est ouvert spécifiquement à partir du numéro RPC_MBX_SERVICE_PORT.

Actuellement nous visons la synthèse de code en multi-rates / multi-systèmes, à 2 niveaux distinguables. Ce serait très intéréssant de déléguer au noyau temps réel l'ordonnancement des tâches. Les diagrammes Simulink sont composés des procédures dites “Sample Rate”, de différentes fréquences d'échantillonage de données. Chacune d'elles sont en réalité des tâches. Toutes les tâches sont ordonnancées suivant le “rate monotonic” par la fonctione principale “main()” du programme. C'est à ce niveau là que les appels au noyau Xenomai interviennent pour prendre en charges l'exécution des tâches. Chaque tâche s'est attribuée d'une priorité en fonction de la durée minimale exigée. Puis, chaque tâche est démarré et synchronisé par la tâche de la fréquence de base, appelé “Base Rate Task”.

Le code généré sera directement déployable sur notre système embarqué. L'accès au périphérique du hardware est assuré par les composants S-Function, qui appellent les fonctions du driver. Ces fonctions permettent l'émission et la réception de données temps réel. Nous espérons ainsi étendre la possibilité pour couvrir le processeur embarqué compatible.

Les caractéristiques sont les suivantes:

• Génération automatique de codes pour Xenomai Co-noyau temps réel
• Xenomai scheduler de tâches
• Compatible avec toutes les platformes supportant Xenomai
• Une palette de blocks Simulink pour enrichir les fonctionnalités
• La librairie contient 2 drivers supplémentaires, le RS232 temps réel (PXA270) et l'Ethernet temps réel (DM9000, SMSC Lan9221 pour RTNet).
• Fonctionne sur 2 canaux de communication possible: soit en Netrpc(udp), soit en External Mode (tcp).
• XTQrtailab (Qrtailab Xenomai Edition), interface graphique pour contrôler le programme sur la cible à distance

Ethernet en définition standard, c'est un protocol de communication non déterministe. Bien qu'il soit présent dans de larges gammes de produits du domaine de l'embarqué, cela n'est pas directement utilisable dans notre projet à caractéristiques temps réels. Nous avons décidé le portage du driver ethernet en RTnet sur Xenomai. Ce nouveau driver permets de prendre en paramètre une addresse MAC arbitraire. Après ce portage, nous avons mesuré avec RTPing (de période 1 s) pour caractériser la dérive, et nous avons constaté une dérive de 2.4 us par paquet émis, avec un jitter de l'ordre de 400 us. Dans certains cas, une dérive accumulative peut rendre le système peu fiable à longue terme.

Nous allons donc imposer un protocole de communication de type multiplexé sur RTNET pour assurer la communication inter-systèmes sans dérive. Nous avons choisi l'utilisation du TDMA dans RTNet. Le TDMA est un mode de multiplexage basé sur la répartition temporelle, permettant de transmettre plusieurs signaux sur un seul canal à différentes intervalles de temps. Le principe est de découper le temps disponible entre les différentes composants. Par ce moyen, le bus est utilisé par plusieurs sous-composants simultanément sans conflit. Le calibrage du TDMA au démarrage nous indique un jitter de l'ordre de 40 us, mais avec aucune dérive constatée durant le test.

Ensuite, nous avons mesuré le temps de la traversée d'un switch. La latence crée est de l'ordre de 200 us par paquet. Ceci reste relativement faible au regard de la fréquence de communications inter-composants, de l'ordre d'un kHz. Enchaîner les systèmes par l'utilisation de 2 switch est donc envisageable, cependant avec un délai de propagation plus important. Nous pouvons décider 2 architectures suivantes:

• Solution 1: Toutes les cartes sont reliées par un switch externe (en bleu), qui se trouve au coeur du système.

• Solution 2: Chaque carte embarque un switch interne (en bleu), qui est auxiliaire au système.

Pour le système embarqué, l'environnement de compilation pour OpenEmbedded est mise en place. Nous avons mise en oeuvre l'exploitation des Gumstix Overo. Malgré leur petite taille (17 mm x 58 mm x 4.2 mm), la puissance de calcul permet d'exécuter un large éventail de fonctions. Le Gumstix Overo utilisé embarque un processeur OMAP3730 cadencé à 1Ghz et un coproceseur DSP C64x+, et 512 Mo de Nand et 512 Mo de RAM, le tout empilé en PoP (package over package). Pour le prototype fonctionnant en TDMA, ceci est basé sur la carte mère Gumstix Stagecoach. Elle relie les modules Gumstix Overo sur un réseau Ethernet 100Mbit. Chaque module dispose de sa propre adresse IP. Le switch externe est un Micrel KSZ8999 qui peut traiter jusqu'à 9 ports ethernet simultanément. La consommation totale du système est bornée à 10W.

En cours de test pour 2 clusters.