Frameworks de génération de code pour SETRC

Le premier aspect que nous abordons est la génération de code pour SETRC. Nous nous fo- calisons sur les processus qui assurent les trois phases suivantes : la modélisation du SETRC, sa validation et sa traduction en code exécutable. La traduction automatique du modèle en code exé- cutable permet de s’abstraire de la complexité de mise en œuvre du système. Dans cette section, nous présentons différents générateurs de code s’appuyant sur cette démarche. Pour chacun, nous introduisons le formalisme dans lequel est décrit le système. Nous traitons en particulier des ob- jectifs fixés par le générateur en terme de validation et nous soulignons ses limitations éventuelles.Ocarina [49] est une suite d’outils développée à Télécom ParisTech pour la vérification et la génération de SETRC modélisés en langage AADL [83]. Ocarina assure l’analyse syntaxique et sémantique des modèles AADL et fournit des passerelles vers des outils d’analyse spécifiques :– CPN-AMI [41] : réseaux de Pétri (simulation, model checking)– Cheddar [85] : analyse d’ordonnancement (tests de faisabilité et simulation)– Bound-T [37] : analyse statique du code généré (calcul du WCET)– REAL [38] : analyse de contraintes (conformité à des patrons architecturaux)Le listing 2.1 donne un exemple de modèle AADL dans sa notation textuelle. Le modèle AADL est constitué d’un ensemble de composants de différents types. Ceux-ci peuvent être connectés à travers leurs features pour modéliser des échanges entre ces composants. Ils sont également annotés avec des propriétés qui précisent leur sémantique d’exécution et leur déploiement. Par ex- emple, la propriété Period d’un composant thread indique une activation périodique d’une certaine fréquence. Le composant processor modélise les éléments matériels et logiciels responsables de l’exécution des thread. Il est annoté pour préciser l’ordonnancement des threads.

Démarche d’analyse

L’objectif d’Ocarina est d’assurer d’une part que la génération de code n’ait lieu que pour un système pour lequel les contraintes de dimensionnement et d’ordonnança- bilité ont été vérifiées au préalable : en réalisant des traductions du modèle AADL vers des formats compatibles avec les outils d’analyse. D’autre part, le second objectif est de minimiser l’écart en- tre le modèle et le code exécutable en optimisant l’empreinte mémoire et le surcoût temporel du binaire final (support d’exécution + applicatif généré). Pour cela, il s’appuie sur des supports d’exécution (intergiciels/micro-noyaux) conçus dans cette optique : PolyORB-HI-C, PolyORB- HI-Ada [48] et POK [27]. Plus précisément, Ocarina détermine à partir du modèle AADL l’ensem-ble des fonctionnalités du support d’exécution qui sont requises pour mettre en œuvre le système modélisé : les fonctionnalités non requises ne sont alors pas incluses dans le binaire. Par exemple, si le modèle AADL spécifie l’utilisation de communications à travers un réseau, alors Ocarina va générer une directive appropriée pour le compilateur de manière à inclure les pilotes réseau dans le binaire. Dans le cas contraire, le binaire ne contiendra pas ces pilotes. Ocarina détermine ainsi les ressources requises et configure le support d’exécution en conséquence. Cela renforce également le déterminisme du code généré en dimensionnant statiquement les ressources nécessaires (évitant l’utilisation d’allocation dynamique). Par exemple, le nombre de tâches et de files de messages sont déterminés statiquement. Les constantes correspondantes sont générées afin de dimensionner les structures contenant l’ensemble des tâches et des files de message.

Limitations La démarche d’analyse d’Ocarina intervient donc essentiellement lors de la phase de conception. Le niveau d’abstraction assez élevé du modèle AADL facilite la spécification mais rend difficile l’évaluation du surcoût de la génération de code. Le surcoût du code généré, même minimisé par le support d’exécution, n’est pas pris en compte lors de la validation du système. En effet, la génération introduit nécessairement des fonctionnalités (e.g. composants logiciels) du support d’exécution qu’il faut prendre en compte. Par conséquent, Ocarina limite l’écart entre modèle et code mais n’assure pas complètement la validité du code généré.Pour assister les concepteurs de systèmes temps-réel, le centre de recherche de l’INRIA Paris- Rocquencout propose la méthodologie appelée AAA [39, 40] (Algorithm Architecture Adequation) et son logiciel de conception assistée par ordinateur (CAO) SynDEx [39]. SynDEx se focalise sur les systèmes synchrones multi-processeurs et son objectif est de minimiser les ressources mises en œuvre pour l’exécution du programme sur la machine cible. La spécification fonctionnelle de ces systèmes est écrite en langage SIGNAL [80] et formalisée sous forme de graphe de flot d’exécution : chaque noeud représente une activité de calcul pouvant être détaillée dans un sous- graphe. La figure 2.1 donne un exemple de flot d’exécution modélisé avec SynDEx.