Analyse de systèmes temps réel distribués par simulation: observation des tâches et des piles

Transcription

1 Analyse de systèmes temps réel distribués par simulation: observation des tâches et des piles Mikaël BRIDAY, Jean-Luc BÉCHENNEC, Yvon TRINQUET IRCCyN Institut de Recherche en Communication et Cybernétique de Nantes UMR 6597 BP , rue de la Noë Nantes Cedex 3 Équipe Système temps réel abstract : Cet article présente quelques concepts de l outil de simulation ReTiS, dédié à l analyse d applications temps réel distribuées. La simulation prend en compte l architecture opérationnelle : l architecture matérielle (processeurs, réseaux,... ) et l architecture logicielle (code applicatif et code système). L analyse exploite une modélisation fine de l architecture matérielle (simulateur de jeu d instruction ou simulateur au niveau cycle) et permet de reconstruire l ordonnancement des tâches et l usage des pile en se fondant sur l observation des événements bas niveau de simulation. Cette observation est basée sur un mécanisme générique : l action, traitement de l événement observé. Ce mécanisme ne nécessite aucune modification du code applicatif ou système. 1 Introduction 2.1 Modélisation du processeur Infineon C Modélisation du contrôleur CAN 2.3 Simulation de l architecture complète 2 L outil ReTiS 3 Les actions 4 Analyse de l ordonnancement des tâches 4.1 Principe général 4.2 Analyse des activations des tâches 4.3 Démarrage d une tâche 4.4 Changement de contexte au cours de l exécution de la tâche 5 Analyse de la pile 5.1 Détection de la taille utile 5.2 Détection des débordements de pile 6 Conclusion mot-clés : Système distribué temps réel, Simulation au cycle près, Analyse temporelle, Analyse de pile, Mise au point de programmes.

2 1 Introduction Les systèmes temps réel sont de plus en plus omniprésents avec la généralisation des calculateurs embarqués, puissants et peu coûteux. Ces systèmes sont utilisés dans des domaines très variés, par exemple les moyens de transport (automobile, aéronautique), les chaînes de production,... Ces systèmes informatiques ont des exigences fonctionnelles, comme tout système informatique, mais également extra-fonctionnelles, comme par exemple les exigences temporelles. La validation est bien sûr une activité indispensable sur de tels systèmes car les conséquences d une erreur peuvent être graves tant sur le plan humain qu économique. La validation d un système temps réel est une opération complexe. Un grand nombre de méthodes sont disponibles, beaucoup sont complémentaires. De nombreux critères interviennent dans le choix d une méthode, critères souvent dépendants les uns des autres. On peut citer par exemple : le positionnement dans le cycle de développement. On privilégie généralement une approche formelle dans les premiers stades de développement alors qu une approche par simulation est inévitable dans les dernières phases de test, quand un grand nombre d informations sont disponibles (support d exécution déterminé, code partiel ou complet de l application) ; le compromis entre l exhaustivité et la précision du modèle par rapport à la cible. Une étude par simulation permet une précision très importante sur un scénario, mais bien sûr ne peut pas prétendre à la complétude ; la couverture de la méthode, selon qu elle prend en considération l architecture matérielle sous-jacente (monoprocesseur, multiprocesseur), avec ou non le support logiciel d exécution (exécutif temps réel par exemple), la modélisation de l environnement, etc Dans les premiers stades du développement la démarche de V&V (Validation et Vérification) consiste souvent à utiliser une modélisation formelle de l application, en utilisant par exemple des formalismes tels que les automates [15] [5] ou les réseaux de Petri [2]. On peut alors obtenir la garantie, ou non, de l existence des propriétés que l on cherche à prouver. Ceci doit toutefois être tempéré, d une part par le fait que l on travaille sur modèle et donc que cette preuve ne sera valide que si la «distance» entre le modèle et la réalité est faible, et d autre part par les limitations quant à la taille des problèmes analysables avec ces techniques. Plus tard dans le cycle de développement, une autre approche, complémentaire, consiste à faire la validation par la simulation. On se heurte alors à la difficulté de la représentativité des tests mais la taille des problèmes analysables est maintenant pratiquement sans limites. Cet article se situe dans le cadre de la validation par simulation [13], [1], dans les tous derniers stades du développement, alors que le code final est disponible, au moins partiellement, et que le support d exécution est déterminé. L approche utilisée est celle de la simulation car la finesse de modélisation que nous souhaitons prendre en compte ne peut être exploitable avec des méthodes formelles. Notre approche ne s oppose donc pas à d autres approches de vérification, elle les complète en se plaçant à un niveau qui permet d obtenir une très grande précision temporelle, donc qui permet d obtenir des résultats très proches de la réalité.

3 L analyse fine, en vue de vérification, du comportement temporel de programmes ne peut s envisager qu en prenant en compte le support d exécution correspondant, c est-à-dire le matériel (processeur, réseau,... ) et le logiciel de base (exécutif temps réel, services de communication, pilotes des dispositifs matériels). On parle alors de vérification sur l architecture opérationnelle, celle-ci pouvant être considérée comme la projection de l architecture logicielle (les programmes qui apportent les fonctionnalités) sur le support d exécution. L objectif visé est donc la simulation d une architecture opérationnelle comprenant une architecture matérielle décrite finement, et une architecture logicielle connue (indirectement) au travers des programmes exécutables (code applicatif et code système). L étude s est concrétisée par la réalisation d un simulateur d architecture opérationnelle [7], pour le processeur Infineon C167 incluant un contrôleur CAN [4] (tous deux très utilisés dans le domaine du transport automobile). Trois aspects ont été particulièrement étudiés : la trace des variables. Une variable pertinente de l application est tracée au cours de la simulation. Ces informations peuvent servir à déterminer la cause du non respect d une contrainte temporelle, relatif à une production de donnée tardive ou un processeur / réseau surchargé, par exemple ; la détection de la tâche en cours permet de déterminer l ordonnancement des tâches de l application, et éventuellement de le mettre en relation avec une analyse d ordonnançabilité analytique ; l étude de la pile associée à une tâche. Dans le cas de l utilisation d un exécutif avec des tâches statiques, un mécanisme permettant de vérifier et dimensionner correctement les piles associées aux tâches est proposé. C est un des problèmes majeurs rencontrés par les concepteurs de logiciels temps réel. Cet article porte sur les deux derniers aspects mentionnés ci-dessus (pour le premier voir [8] [6]). La section suivante décrit les principes utilisés pour l outil d analyse, et les deux suivantes s attachent à présenter les résultats obtenus avec l analyse de l ordonnancement et des piles des tâches temps réel. Les techniques présentées ne se basent que sur le code exécutable de l application à valider (aucune instrumentation du code source). 2 L outil ReTiS ReTiS est constitué de deux parties : un simulateur d architecture matérielle multiprocesseurs permettant d exécuter une application distribuée. La simulation est fonctionnellement exacte et la précision temporelle dépend de la précision des modèles employés. une interface graphique permettant de synthétiser sous une forme exploitable les informations extraites de la simulation. Les deux parties communiquent selon une architecture client-serveur. Dans la suite, nous ne nous intéressont qu à la partie simulateur. La plateforme de modélisation et de simulation est basée sur SystemC [9]. SystemC est un framework orienté objet écrit en C++ et supporté par l OSCI (Open SystemC Intitative), une organisation indépendante réunissant une vingtaine d industriels (microélectronique, système, logiciel embarqué,... ). Il est distribué sous une licence

4 Open Source. Plusieurs types de modélisation et de simulation sont possibles : du niveau transfert de registre à registre (RTL) au niveau système. Une bibliothèque de classes et de templates permet de modéliser des composants, des liens pour relier les composants et des signaux pour véhiculer des informations sur les liens. Les caractéristiques de base de SystemC sont comparables à celles que l on trouve dans les langages de description de composants matériels (HDL) comme VHDL ou Verilog. De plus, depuis la version 2, SystemC propose des objets plus adaptés à la simulation de systèmes : les canaux, les interfaces et les événements. Ce niveau plus élevé de conception est appelé TLM : Transaction Level Modelling. Le fait d adopter SystemC comme environnement de travail présente plusieurs avantages : les modèles disponibles auprès des fondeurs peuvent être facilement incorporés ; toute bibliothèque C ou C + + peut être utilisée par un modèle SystemC ; la disponibilité du code source permet d adapter le moteur de simulation si nécessaire. L architecture distribuée présentée ci-dessous est constituée de plusieurs processeurs Infineon C167 connectés par un réseau CAN. Ce type d architecture est couramment employé dans les systèmes temps réel embarqués pour l automobile et permet de modéliser un système réaliste et raisonnablement complexe. La modélisation de l architecture opérationnelle complète est traitée en détail dans [7] [6]. 2.1 Modélisation du processeur Infineon C167 Le cœur du microcontrôleur C167[14] est composé d un pipeline à 4 étages (avec un cache de saut), d une unité arithmétique et logique (ALU) 16 bits ainsi que d un ensemble de registres spécifiques (Special Function Registers). Il dispose, de plus, d une unité de multiplication / division séparée, d une unité de masquage de bit et d un barrel shifter 1. Sa fréquence peut atteindre 33 MHz. Dans le contexte temps réel, il est nécessaire non seulement de simuler le comportement fonctionnel du processeur, mais aussi son comportement temporel, en respectant les délais dûs au matériel. On peut distinguer deux types d approches intéressantes pour la simulation : le simulateur de jeu d instructions (ISS pour Instruction Set Simulator)[3], ne reproduit que le comportement fonctionnel du processeur, c est à dire que l architecture interne (pipeline, unités de calculs dédiées,... ) n est pas du tout modélisée. Dans ce contexte, toutes les instructions ont la même durée : 1 cycle ; la simulation précise au cycle près prend en compte un modèle précis de l architecture interne du processeur afin de simuler non seulement le fonctionnement du processeur, mais aussi fournir des informations temporelles au cycle près. La complexité qui en découle entraîne des temps de calculs plus importants. Ces deux schémas de simulation ont chacun leurs intérêts et leurs inconvénients. Le premier est rapide et le deuxième précis, ce qui est essentiel dans notre cas. Afin d utiliser les avantages de ces deux approches, un simulateur modulaire a été conçu. Il permet de commuter d un schéma vers l autre au cours de la simulation. Ainsi, une séquence critique du logiciel peut être simulée finement avec les informations 1 registre à décalage qui peut décaler plusieurs bits en une seule fois

5 temporelles et une autre partie moins critique exécutée plus rapidement en mode de simulation du jeu d instructions. De façon à assurer la synchronisation et la communication avec les autres dispositifs, comme les contrôleurs CAN, le modèle de processeur est encapsulé dans un module SystemC. Le module possède une entrée d horloge, et une transition sur cette dernière provoque l appel d une méthode C ++ qui simule 1 cycle de fonctionnement du processeur. Des modèles (périphériques, éléments de l environnement) peuvent facilement être ajoutés. 2.2 Modélisation du contrôleur CAN Le protocole CAN (Controller Area Network) de Bosch[4] est un protocole de communication série assurant la diffusion fiable de messages sur un bus à faible coût. C est un protocole mature (expérimentations depuis 1986) qui définit une surveillance très stricte du bus. La gestion du bus est dirigée par les événements (Event-Triggered). Le bus est de type multi-maîtres asynchrone. Il n y a pas de mémoire commune, pas de contrôleur de trafic, pas d horloge globale et une station peut émettre dès que le bus est libre. Une trame est composée d un identifiant de message. Cet identifiant sert à la fois à caractériser la donnée embarquée dans le message (vitesse du véhicule, vitesse de rotation du moteur par exemple) et à donner sa priorité. En cas de collision sur le bus, le message le plus prioritaire n est pas détruit, le ou les autres messages seront réémis dès que le bus sera de nouveau libre. L absence d horloge globale conduit à synchroniser l émetteur et le récepteur sur les transitions entre 0 et 1. Si le message contient plus de 5 bits consécutifs de valeur identique, un bit supplémentaire de valeur opposée est inséré. Ce système, le bit stuffing, peut augmenter le temps de transmission d un message jusqu à 18%. C est l une des raisons qui nécessite une modélisation suffisamment fine du contrôleur CAN pour simuler correctement le comportement temporel du bus. La modélisation du contrôleur CAN a été réalisée à deux niveaux différents, la précision requise dans les deux cas est celle du bit, c est-à-dire que la transmission / réception des messages s effectue au niveau du bit. La première méthode est basée sur une approche par composants de type VHDL en utilisant SystemC, la modélisation étant au niveau RTL. La deuxième approche conduit à une modélisation au niveau transactionnel et, fonctionellement, le modèle s éloigne quelque peu du composant réel en intégrant un arbitre dans le bus. Cette dernière modélisation utilise l approche TLM, c est celle que nous utilisons car elle est la plus efficace. 2.3 Simulation de l architecture complète L architecture dans son ensemble peut comprendre autant de nœuds que nécessaire, la seule limite étant la quantité de mémoire disponible. Chaque nœud comprend les modules SystemC présentés précédemment (processeur et contrôleur CAN) qui sont synchronisés via SystemC. Afin d obtenir de meilleures performances du simulateur, ni les accès mémoire ni les accès aux circuits périphériques (contrôleur CAN, timers,

6 ... ) ne sont modélisés au niveau RTL. Toutefois, les délais engendrés par ces accès sont modélisés précisément. 3 Les actions Une action est une portion de code qui est exécutée à la suite d un événement généré par le simulateur, par exemple lors d un accès en lecture ou en écriture dans la mémoire du processeur. Une action est datée par le numéro du cycle de l horloge de base de la simulation. Cette technique est, d une part, particulièrement intéressante pour interfacer le processeur avec certains composants internes comme les timers, les composants réseaux (CAN, interface série), le contrôleur d interruption, les ports I/O,... D autre part, l action est l élément de base qui permet l analyse des piles et des tâches. Trois types d événements sont utilisés et associés à des actions pour cette analyse : un accès en lecture à une adresse mémoire. On entend par mémoire, dans ce contexte, tout élément qui permet l enregistrement de données, que ce soit la mémoire programme / données ou les registres généraux ou spécifiques (registres d accès à des composants matériels) ; un accès en écriture à une adresse mémoire ; une exécution de l instruction à une adresse du code programme. 4 Analyse de l ordonnancement des tâches Dans les systèmes embarqués critiques, les tâches sont généralement statiques et ont donc la même durée de vie que l application, comme par exemple dans le système d exploitation OSEK-VDX 2. Le mécanisme présenté ici n est applicable que dans ce cas de figure, c est-à-dire que l allocation dynamique de tâche n est pas traitée. Dans ce dernier cas, il serait nécessaire de détecter l instant de création et de destruction de chaque tâche. Une approche statique, comme celle présentée dans [11] serait inefficace dans ce contexte. En effet, cette approche ne peut pas traiter les formes basées sur des sauts calculés au moment de l exécution (saut indirect), utilisés notamment dans les routines de changement de contexte d un exécutif temps réel. Elle permet par contre (dans le cas mono-processeur) d obtenir des résultats exhaustifs sur l utilisation de la pile. Ce mécanisme ne requiert pas que la pile soit correctement dimensionnée, c est-àdire qu une corruption de pile par dépassement avant (underflow) ou après (overflow) la zone de pile initialement allouée est admissible. Cette hypothèse forte est indispensable pour permettre l analyse des piles dans la section 5. Nous considérons ici un exécutif temps réel dont nous ne connaissons pas le comportement lors des changements de contexte. Les sources de l exécutif peuvent 2 OSEK-VDX est noyau temps réel multi-tâches préemptif qui couvre les applications de contrôle embarqué dans les véhicules. Il a été développé pour fournir une interface de programmation (API) standard entre les différents composants logiciels, favorisant une portabilité des applications au niveau source.

7 d ailleurs ne pas être disponibles. Les hypothèses sur l exécutif temps réel à analyser sont : l utilisation de tâches statiques, c est-à-dire que leurs durées de vie correspondent à la durée de vie du programme ; il n y a pas de création de tâche en cours d exécution ; elles sont donc définies à l initialisation de l application ; le système est multitâche, sans hypothèse sur l ordonnancement ; chaque tâche possède sa propre pile ; aucune connaissance a priori sur l exécutif n est nécessaire, mais le changement de contexte est réalisé suite à un appel de fonction ; l exécutif fait un «usage correct» du jeu d instructions, c est-à-dire que la sémantique associée aux instructions du processeur est respectée. Par exemple, l instruction calls correspond bien à un appel de fonction, et rets à un retour de fonction. Cette hypothèse est respectée par les compilateurs. Quand une tâche est exécutée, le pointeur de pile (Stack Pointer) est positionné dans la plage de pile de la tâche. Une première approche consiste alors à détecter la tâche courante (en cours d exécution) en se basant sur la valeur courante du pointeur de pile. Cependant, si la pile est corrompue, la connaissance de la valeur du pointeur de pile peut s avérer insuffisante et l interprétation de la tâche courante est alors erronée. Dans le cas de deux piles contiguës par exemple, un débordement de pile serait alors interprété comme un changement de contexte, car le pointeur de pile évolue alors dans la plage d adresse de la pile d une autre tâche. Le mécanisme de détection des tâches que nous proposons ici est basé sur la détection des changements de contexte à la fin des fonctions. Il s ensuit qu un changement de contexte sera détecté dès qu une fonction système de changement de contexte termine son exécution. 4.1 Principe général Considérons le scénario avec deux tâches présenté dans la figure 1, avec trois changements de contexte. Les 2 tâches sont prêtes à être exécutée, et la tâche 1 est la plus prioritaire. La tâche 1 est démarrée ( 1 ), elle commence à s exécuter puis appelle la fonction waitevent. Cette fonction système (interne à l exécutif) bloque la tâche 1 et effectue un changement de contexte vers l autre tâche ( 3 ). La tâche 2 nouvellement démarrée appelle alors la fonction f ( 4 ) qui se termine normalement ( 5 ). La fonction système setevent est ensuite appelée ( 6 ) qui réveille la tâche 1 et donc réalise un nouveau changement de contexte. La tâche 1 continue son exécution puis se termine en appelant la fonction système terminatetask ( 8 ). La tâche 2 continue alors son exécution. Cet exemple utilise ainsi trois fonctions systèmes qui réalisent un changement de contexte (waitevent, setevent et terminatetask). La fonction g quant à elle peut être une fonction utilisateur ou système. Dans cet exemple, les appels systèmes sont empruntés à l exécutif OSEK-VDX, mais le principe présenté ici est indépendant de l exécutif considéré. Dans cet exemple, les changements de contextes ont lieu directement dans l appel système (et non pas dans une autre fonction dédiée qui réaliserait le changement de contexte). Dans ce scénario, les changements de contexte (qui ne peuvent être détectés qu à

8 Tâche 1 1 { 2 waitevent { } setevent { 6 3 Tâche 2 { 4 5 fonction f { } 7 8 } terminatetask { 9 } } } FIG. 1 Un exemple simple avec des changements de contexte de deux tâches. Les fonctions systèmes (internes à l exécutif) waitevent, setevent et terminatetask effectuent un changement de contexte. La fonction f quant à elle est une simple fonction appelée par la tâche 2. la fin de la fonction) doivent être détectés en quatre points ( 1, 3, 7 et 9 ) dans le flot d exécution, c est-à-dire quand les tâches sont réveillées. Il est nécessaire de différencier deux cas : celui du démarrage d une tâche (ou la réactivation) qui peut être détecté en utilisant une action datée, placée une fois au démarrage du simulateur, associée à un événement d exécution de code, sur la première instruction de la tâche, aux points 1 et 3 ; celui du changement au cours de l exécution de la tâche. Celui-ci est produit par une interruption qui provoque un changement de contexte (si la préemption est autorisée) ou un appel système. Il est nécessaire dans ce cas d effectuer un traitement pour chaque appel de fonction et pour chaque retour de fonction, aux points 7 et Analyse des activations des tâches Démarrage d une tâche Les deux seules informations qui sont nécessaires au simulateur sont le nom de la fonction principale de la tâche, c est-à-dire la fonction qui sera appelée la première fois que la tâche est lancée, ainsi que la valeur initiale de la pile. La valeur initiale de la pile est détectée automatiquement la première fois que la tâche est démarrée. Dès qu une tâche est démarrée, une action datée (associée à l événement «exécution du code») placée à la première instruction de la tâche est activée. Celle-ci va alors comparer la valeur courante du pointeur de pile avec les valeurs initiales des pointeurs de pile de chaque tâche pour détecter quelle est la tâche courante. Il est nécessaire de comparer les valeurs de piles initiales car plusieurs tâches peuvent utiliser le même code de tâche. On ne peut alors les différencier qu avec la pile.

9 En effet, si deux tâches possèdent la même fonction principale, elles seront déclarées de la même manière par l utilisateur. Au démarrage de la première des deux, la valeur initiale de la pile va être détecté automatiquement. Lors d une autre activation de tâche, si la pile a une valeur différente que celle précédemment détectée, c est que la deuxième tâche est activée et la valeur initiale de pile correspondante est enregistrée. Les deux tâches sont alors correctement distinguées au niveau du simulateur. Le principe s étend à n tâches partageant la même fonction principale Changement de contexte au cours de l exécution de la tâche Le mécanisme est découpé en une partie qui est exécutée quand il y a un appel de fonction et une autre partie qui va être déclenchée lors d un retour de fonction. Considérons l exemple de code suivant : 0x1bc8 : bset PSW.11 0x1bca : calls #0x0, f (0x1FFA) ;appel de la fonction f 0x1bce : mov T0IC, #0x4C ;première instruction ;après le retour de f Dans un premier temps, à chaque fois qu une fonction est appelée (ici en 0x1bca), la valeur du pointeur de pile ainsi que la tâche courante sont enregistrées et une action datée (associée à l événement exécution de l instruction) est placée à l adresse de l instruction qui suit l appel de fonction (en 0x1bce). On entend ici par appel de fonction, toute instruction susceptible de provoquer un changement de fonction par des appels directs ou indirects, mais aussi les interruptions logicielles ou matérielles. Pour le C167, il faut prendre en compte les instructions calla, callr, calli, calls, pcall, trap ainsi que les mécanismes d interruptions matérielles. Dans le cas des interruptions matérielles, une action datée est placée au niveau de l instruction qui aurait dû être exécutée s il n y avait pas eu d interruption. Cette instruction est la première instruction exécutée au retour de l interruption. Dans un deuxième temps, lors d un retour de fonction, l action datée est déclenchée et le comportement de l action dépend de la comparaison entre la valeur du pointeur de pile et celle qui est enregistrée. La valeur de la pile doit être la même avant l appel de fonction et au retour de cet appel car le pointeur d instruction (Program Counter) est toujours enregistré en haut de la pile 3. Le principe est le même pour les interruptions, qui peuvent être perçues comme des appels de fonctions (car une interruption empile, comme une instruction d appel de fonction, le pointeur d instruction). Les deux valeurs sont comparées et il s en suit que : si les deux valeurs sont égales, la tâche en cours d exécution est la même que celle qui était active lors de l appel de la fonction. La tâche courante est alors détectée à cet instant. On ne se sert dans ce cas de la valeur du pointeur de pile que pour la comparer à la précédente, et déterminer ainsi la tâche courante. 3éventuellement avec d autres registres comme le registre de segment.

10 si les deux valeurs ne sont pas égales, c est que la tâche courante n est pas celle qui était active lors de l appel de fonction. Ce cas se produit pour deux tâches (ou plus) qui partagent le même code. Les deux tâches vont appeler les mêmes fonctions et par conséquent placer des actions datées sur les mêmes adresses mémoires. Bien entendu, une seule des actions datées éveillées aura une valeur de pile égale à la valeur courante du pointeur de pile. C est donc la comparaison entre la valeur du pointeur de pile enregistré et la valeur courante qui permet de déterminer correctement la tâche en cours d exécution. Cependant, il se peut qu aucune tâche ne soit détectée à cet instant. Ceci arrive s il y a une action datée, mais que les valeurs de pile (celle enregistrée et la courante) ne sont pas identiques. Dans ce cas, le simulateur détecte bien qu il y a eu un changement de tâche, mais celui-ci ne correspond à aucune des tâches qu il doit suivre. Comme le simulateur ne peut pas déterminer la tâche courante, on introduit la notion de tâche inconnue. Ce principe s applique à chaque appel de fonction, et il y a alors autant d actions datées de créées pour une tâche qu il y a de fonctions (et d interruptions) imbriquées. De plus, ce principe ne requiert pas d utiliser directement l instruction de fin de fonction (ret), une instruction effectuant un saut indirect est aussi acceptable, comme ce qu on peut retrouver sur une routine de changement de contexte dans un exécutif. Avec une telle modélisation, si un dépassement de pile intervient (stack overflow / underflow), la détection des tâches reste correcte. Si la pile n a pas été correctement gérée, par un nombre d empilements différent du nombre de dépilements, la détection en retour de fonction est impossible. Cependant ce cas génère un fonctionnement erroné du programme immédiatement. C est ainsi, une bonne estimation de la tâche courante permet d effectuer une analyse dynamique de la validité des piles. Les actions dynamiques sont créées pour chaque instruction capable de faire un appel de fonction. L implémentation au niveau du simulateur de ces instructions est donc légèrement modifiée pour prévenir le simulateur qu un appel a lieu. Ces actions datées doivent cependant être détruites dès que leur utilisation n est plus nécessaire. Ainsi, dès que la fonction retourne, l action datée est déclenchée et détruite ensuite. Cependant, dans certains cas, ce comportement n est pas suffisant. Considérons par exemple une pile qui est réinitialisée, par exemple à chaque fois que la pile est activée. Dans ce cas, il est nécessaire de non seulement supprimer la dernière action datée, mais aussi de vérifier lors de l ajout d une action datée, que cette nouvelle entrée correspond bien, dans la liste des actions dynamiques, à la valeur de pile la plus profonde. 4.3 Un exemple d étude Un exemple de commande de moteur va permettre de présenter la visualisation des résultats de ReTiS. Comme le montre la figure 2, la plate-forme matérielle utilisée est composée de deux processeurs C167 reliés par un bus CAN. L exécutif utilisé pour les deux nœuds est OSEK / VDX OS [10], avec les services de communication OSEK / VDX COM. L implémentation de l exécutif à notre disposition utilise deux tâches pour la ges-

11 nœud de commande afficheur LCD Superviseur Nœud 0 consigne vitesse Port P5 vitesse port P5 Moteur Nœud 1 consigne (task5 1 ) commande PWM (task4 0 ) (task3 0 ) (task4 1 ) (task3 1 ) COM EXTERNE COM EXTERNE CAN bus vitesse moteur consigne moteur vitesse moteur consigne moteur FIG. 2 Exemple d étude. Le nœud 0 est le superviseur. Le nœud 1 est le nœud de commande, qui fait l asservissement en vitesse du moteur. Les tâches Task3 0, Task4 1 et Task5 1 sont périodiques. Les tâches Task4 0 et Task3 1 sont activées sur réception d un message CAN. tion de l exécutif (une tâche principale, et une pour le traitement des interruptions), et deux tâches pour la communication (une pour l émission des trames, Task1, et l autre pour la réception, Task2). Pour chaque nœud, un timer est activé, générant une interruption toutes les millisecondes. Le premier nœud (node0) est le superviseur. Il est équipé d un afficheur LCD et d une connexion permettant de rentrer la valeur de la consigne (à travers le port 16 bits P5). Il possède deux tâches (Task3 0 4 et Task4 0 ). la tâche Task3 0 est périodique (période de 4ms). Elle lit la valeur de la consigne sur le port P5 et envoie cette valeur au nœud node1 ; la tâche Task4 0 est chargée de la gestion de l afficheur LCD. Elle est activée dès qu une trame CAN contenant la valeur de la vitesse du moteur est reçue. Le second nœud (node1) a la charge de la commande du moteur. La commande du moteur est réalisée par une commande PWM (Pulse Width Modulation). Un capteur sur le moteur permet d obtenir une image de la vitesse ; elle est accessible via le port 16 bits P5 : la tâche Task3 1 est activée dès qu une trame contenant la consigne de vitesse est reçue. La valeur de la consigne est alors stockée dans une variable globale (consigne), protégée en utilisant une ressource (en utilisant la méthode du Priority Ceiling Protocol [12]), car l accès à une variable n est pas atomique ; la tâche Task4 1 est périodique. Elle envoie toutes les 4 ms la valeur de la vitesse au nœud superviseur pour l affichage ; la tâche Task5 1 est la tâche de contrôle du moteur. Elle est périodique de période 2 ms. 4 Dans l implémentation d OSEK-VDX à notre disposition, les tâches sont déclarées en utilisant la macro TASK(id). L utilisateur n a donc pas le choix du nom de la tâche. Pour différentier les tâches de chaque nœud, le numéro du nœud est mis en indice.

12 FIG. 3 Diagramme de Gantt des tâches. À chaque ligne correspond une tâche. Quand aucune tâche n est détectée, la tâche 0 est utilisée (une par processeur). Elle est visualisée d une autre couleur. Les dates, affichées en petit, indiquent les dates d activations et de fin d exécution de la tâche. L utilisateur a le choix des tâches qu il veut visualiser. 4.4 Exploitation des résultats La détection des tâches, afin de construire le diagramme de Gantt de l ordonnancement des tâches, est réalisée en deux temps, c est-à-dire avec une phase d initialisation et une autre phase d exploitation des résultats. Durant la phase d initialisation, les tâches à analyser sont déclarées au simulateur. Dans notre cas, la tâche principale de l exécutif est déclarée (main), ainsi que les tâches applicatives (Task3 0, Task4 0, Task3 1, Task4 1 et Task5 1 ). Les deux tâches utilisées pour la communication externe et la tâche utilisée pour le traitement des interruptions ne sont pas déclarées, elles apparaîtrons dans la tâche inconnue. Après la simulation, l activation des tâches est présentée par un diagramme de Gantt de la même manière que dans les diagrammes d ordonnancement. Ainsi, les tâches sont représentées sur l axe des ordonnées. Un rectangle plein est utilisé pour chaque instance de tâche (figure 3). Toutes les périodes d activités des tâches sont datées (la date en haut correspond à l activation et la date en bas correspond à la fin d activité de la tâche). Dans cet exemple, on peut remarquer la présence des interruptions causées par le timer toutes les millisecondes, sur les deux processeurs, ainsi que les interruptions liées à l arrivée ou l envoi de trames CAN. On peut de même remarquer que la tâche Task4 0 occupe longtemps le processeur (par rapport aux autres tâches), entre les dates et , soit 2644 cycles (132 µs). Ceci vient du fait que la fonction printf pour l écriture sur le LCD nécessite beaucoup de calcul. L interruption liée à l émission ou la réception correcte d un message CAN est prise en compte en même temps sur les deux nœuds, aux dates et cycles.

13 5 Analyse de la pile Le dimensionnement des piles des tâches est un problème difficile et le besoin d une aide à ce dimensionnement est très fréquemment exprimé chez les concepteurs d applications temps réel. Cette information, extraite à partir de l étude de la pile, peut être utilisée pour vérifier la sûreté de la pile ainsi que pour essayer de réduire l espace mémoire alloué initialement. L analyse de la pile d une tâche est largement basée sur la technique de détection de la tâche courante qui a été présentée dans la section précédente. L analyse des piles se fonde sur une approche de protection mémoire implémentée dans le simulateur. Tout accès à une plage mémoire avant et après la plage mémoire réservée à la pile est détectée et signalée à l utilisateur. Cette protection mémoire se base elle même sur des actions datées qui sont associées à des événements accès en écriture à une adresse mémoire. Les limites de la piles sont ainsi déterminées : la taille de la pile est connue et son origine est obtenue la première fois que la tâche est activée. 5.1 Détection de la taille utile Afin de détecter la taille de pile effectivement exploitée, une action est placée sur chaque octet de la zone de la pile. Chacune de ces actions est dotée d un drapeau qui est positionné lors d un accès en écriture. Après que le scénario défini par l utilisateur de la simulation ait été exécuté, le dernier octet écrit donne la taille de pile réellement exploitée. Cette méthode n est pas dépendante de la manière dont les compilateurs utilisent la pile. En effet, certains compilateurs C ne modifient pas le pointeur de pile dans les fonctions terminales (celles qui n appellent pas d autre fonction) ou bien copient le pointeur de pile dans un autre registre avant de faire des accès indirects en mémoire. Dans ces cas, le pointeur de pile n indique pas l utilisation réelle de la pile. 5.2 Détection des débordements de pile La détection de la corruption de la pile est basée sur la protection mémoire. Pour chaque pile, deux plages d adresses sont spécifiées. Pour chaque octet de la zone de protection, une action datée est placée afin d être activée sur les accès en écriture. Si un accès en écriture a lieu dans l une de ces zones et que la pile est bien celle de la tâche courante, une erreur est détectée. Il est important de vérifier quelle est la tâche en cours car une zone protégée pour une tâche peut être une zone correcte pour une autre tâche. La zone de protection doit être suffisamment large pour détecter les corruptions de pile. En effet, si les piles système et utilisateur sont réunies en une unique pile, le compilateur peut effectuer des décalages pour accéder aux données locales. Dans le cas d une pile système seule, une zone de protection d un octet est suffisante. Cependant, cette zone de protection ne doit pas être trop importante non plus car le mécanisme peut interférer avec de la mémoire utilisée autrement, par des variables globales par exemple. Dans le C167, les registres généraux sont situés en mémoire, dans une zone proche de la zone réservée aux piles, ce qui peut être gênant dans certains cas.

14 6 Conclusion Les travaux présentés dans cet article concernent la simulation d une architecture opérationnelle comprenant une architecture matérielle décrite finement (processeurs et réseaux), et une architecture logicielle connue au travers des programmes exécutables (code applicatif et code système). Simuler n était bien sûr pas un but en soi : l objectif était de tirer des scénarii étudiés un ensemble de résultats exploitables par le concepteur d une application temps réel. Une contribution de ces travaux se situe dans les mécanismes génériques d extraction d informations à partir de la simulation «bas niveau» de l exécution des programmes, pour en déduire des informations «haut niveau» exploitables par le concepteur. Ces mécanismes, construits autour des actions, restent utilisables pour les architectures évoluées (plus complexes que celle du C167) comprenant, entre autres, des mémoire cache et des architectures d exécution complexes (superscalaires, exécution dans le désordre,... ). Une contribution au niveau de l analyse de l ordonnancement a été présentée. Un mécanisme permettant de détecter la tâche courante en exécution sur un processeur, et donc de reconstruire l ordonnancement des tâches a été proposé. Ce mécanisme ne fait que très peu d hypothèses (très réalistes) sur l exécutif temps réel. L exploitation des résultats est faite graphiquement sous la forme d un diagramme de Gantt par l outil ReTiS. Une autre application, indirecte car ce n est pas la seule manière de faire, est l observation des temps d exécution des tâches. Ceci est très important pour la vérification d hypothèses faites bien avant dans le cycle de conception, en terme de budgets alloués aux tâches. Une autre contribution au niveau de l analyse de la pile associée à chaque tâche a été présentée. Un mécanisme a été proposé permettant de détecter la corruption des piles (dépassement dans les deux sens), et d aider au dimensionnement des piles en déterminant l utilisation réelle sur un scénario. Ce problème du dimensionnement des piles fait partie de ceux fréquemment évoqués par les ingénieurs de conception d application temps réel, l analyse statique ne permettant en effet pas de prendre en compte un certain nombre de cas. Toutes ces fonctionnalités ont été implémentées dans l outil prototype ReTiS, couplé avec une chaîne industrielle de production de code. Mis en œuvre sous forme d un serveur et d un client communiquant aux moyens de sockets, les parties «simulation» et «exploitation» peuvent être distribuées sur des machines adaptées. Les travaux se poursuivent actuellement dans deux axes : d une part nous souhaitons améliorer le niveau d expression des contraintes temps réel sur l analyse des variables, afin de faciliter la spécification des contraintes à vérifier, par exemple entre la production et la consommation d une valeur ; d autre part nous travaillons sur la définition d un langage de description de l architecture matérielle (aspects structurels et comportementaux), intégrant le concept d action et la sémantique des instructions pour la trace des variables. Ceci permettrait de réduire l effort nécessaire à la modélisation d un nouveau processeur, ainsi que la prise en compte d architectures plus complexes.

15 Références [1] Lars Albertsson and Peter S. Magnusson. Using complete system simulation for temporal debugging of general purpose operating systems and workloads. In MASCOTS 2000, [2] P.O Ribet et F. Vernadat B. Berthomieu. L outil tina. construction d espaces d états abstraits pour les réseaux de petri et réseaux temporels. In Colloque Francophone sur la Modélisation des Systèmes Réactifs (MSR 03), Octobre [3] Robert Bedichek. Some efficient architecture simulation techniques. In Winter 1990 USENIX Conference, pages 53 63, January [4] Robert BOSCH. CAN Specification version 2.0, [5] Béatrice Bérard, Patricia Bouyer, and Antoine Petit. Analysing the pgm protocol with UPPAAL. International Journal of Production Research, 42(14) : , [6] Mikaël Briday. Validation par simulation fine d une architecture opérationnelle. PhD thesis, IRCCyN - Université de Nantes, december [7] Mikaël Briday, Jean-Luc Béchennec, and Yvon Trinquet. Modelisation of a distributed hardware system for accurate simulation of real time applications. In Proceedings of 5th IFAC International Conference on Fieldbus Systems and their Applications (FeT 03), july [8] Mikaël Briday, Jean-Luc Béchennec, and Yvon Trinquet. Retis : a real-time simulation tool for the analysis of distributed real-time applications. In 5th IEEE International Workshop on Factory Communication Systems. WFCS 04, Vienna, Austria, pages , [9] Cadence. An introduction to system design with systemc. http :// November [10] OSEK Group. Osek/vdx operating system specification - version http :// july [11] Alastair Reid John Regehr and Kirk Webb. Eliminating stack overflow by abstract interpretation. In 3rd International Conference on Embedded Software, pages Springer-Verlag, october [12] Sha L., Raikumar R., and Lehocsky J.P. Priority inheritance protocol : an approach to real-time synchronization. IEEE Transaction On Computer, 39(9) : , [13] Mendel Rosenblum, Stephen A. Herrod, Emmett Witchel, and Anoop Gupta. Complete computer system simulation : The simos approach. In IEEE Parallel and Distributed Technology : Systems and Applications, pages IEEE, Winter [14] Infineon Technologies. C167cr derivatives 16-bi t single-chip microcontroller, user s manual v3.1, 2000.

16 [15] Stavros Tripakis and Sergio Yovine. Verification of the fast reservation protocol with delayed transmission using the tool KRONOS. In Proc. 4th IEEE Real- Time Technology and Applications Symposium (RTAS 98), pages IEEE Computer Society Press, 1998.