Vous êtes sur la page 1sur 16

Analyse de syst` mes temps r el distribu s par e e e simulation: observation des t ches et des piles a

Mika l B RIDAY, Jean-Luc B E CHENNEC, Yvon T RINQUET e prenom.nom@irccyn.ec-nantes.fr IRCCyN Institut de Recherche en Communication et Cybern tique de e Nantes UMR 6597 BP 92101 - 1, rue de la No e 44321 Nantes Cedex 3 Equipe Syst` me temps r el e e
abstract : Cet article pr sente quelques concepts de loutil de simulation ReTiS, d di e e e ` a lanalyse dapplications temps r el distribu es. La simulation prend en compte lare e chitecture op rationnelle : larchitecture mat rielle (processeurs, r seaux, . . . ) et lare e e chitecture logicielle (code applicatif et code syst` me). Lanalyse exploite une mod lie e sation ne de larchitecture mat rielle (simulateur de jeu dinstruction ou simulateur e au niveau cycle) et permet de reconstruire lordonnancement des t ches et lusage a e des pile en se fondant sur lobservation des ev nements bas niveau de simulation. Cette observation est bas e sur un m canisme g n rique : laction, traitement de e e e e l v nement observ . Ce m canisme ne n cessite aucune modication du code ape e e e e plicatif ou syst` me. e 1 Introduction 2.1 Mod lisation du processeur Inneon C167 e 2.2 Mod lisation du contr leur CAN e o 2.3 Simulation de larchitecture compl` te e 2 Loutil ReTiS 3 Les actions 4 Analyse de lordonnancement des t ches a 4.1 Principe g n ral e e 4.2 Analyse des activations des t ches a 4.3 D marrage dune t che e a 4.4 Changement de contexte au cours de lex cution de la t che e a 5 Analyse de la pile 5.1 D tection de la taille utile e 5.2 D tection des d bordements de pile e e 6 Conclusion mot-cl s : Syst` me distribu temps r el, Simulation au cycle pr` s, Analyse tempoe e e e e relle, Analyse de pile, Mise au point de programmes.

Introduction

Les syst` mes temps r el sont de plus en plus omnipr sents avec la g n ralisation e e e e e des calculateurs embarqu s, puissants et peu co teux. Ces syst` mes sont utilis s dans e u e e des domaines tr` s vari s, par exemple les moyens de transport (automobile, a ronaue e e tique), les chanes de production, . . . Ces syst` mes informatiques ont des exigences e fonctionnelles, comme tout syst` me informatique, mais egalement extra-fonctionnele les, comme par exemple les exigences temporelles. La validation est bien s r une u activit indispensable sur de tels syst` mes car les cons quences dune erreur peuvent e e e etre graves tant sur le plan humain qu conomique. e La validation dun syst` me temps r el est une op ration complexe. Un grand e e e nombre de m thodes sont disponibles, beaucoup sont compl mentaires. De nombreux e e crit` res interviennent dans le choix dune m thode, crit` res souvent d pendants les e e e e uns des autres. On peut citer par exemple : le positionnement dans le cycle de d veloppement. On privil gie g n ralement e e e e une approche formelle dans les premiers stades de d veloppement alors quune e approche par simulation est in vitable dans les derni` res phases de test, quand e e un grand nombre dinformations sont disponibles (support dex cution d termie e n , code partiel ou complet de lapplication) ; e ` le compromis entre lexhaustivit et la pr cision du mod` le par rapport a la e e e cible. Une etude par simulation permet une pr cision tr` s importante sur un e e ` sc nario, mais bien s r ne peut pas pr tendre a la compl tude ; e u e e la couverture de la m thode, selon quelle prend en consid ration larchitecture e e mat rielle sous-jacente (monoprocesseur, multiprocesseur), avec ou non le supe port logiciel dex cution (ex cutif temps r el par exemple), la mod lisation de e e e e lenvironnement, etc Dans les premiers stades du d veloppement la d marche de V&V (Validation et e e ` V rication) consiste souvent a utiliser une mod lisation formelle de lapplication, en e e utilisant par exemple des formalismes tels que les automates [15] [5] ou les r seaux e de Petri [2]. On peut alors obtenir la garantie, ou non, de lexistence des propri t s ee ` que lon cherche a prouver. Ceci doit toutefois etre temp r , dune part par le fait ee que lon travaille sur mod` le et donc que cette preuve ne sera valide que si la dise tance entre le mod` le et la r alit est faible, et dautre part par les limitations quant e e e ` a la taille des probl` mes analysables avec ces techniques. Plus tard dans le cycle de e ` d veloppement, une autre approche, compl mentaire, consiste a faire la validation par e e ` la simulation. On se heurte alors a la difcult de la repr sentativit des tests mais la e e e taille des probl` mes analysables est maintenant pratiquement sans limites. e 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 nal est disponible, au e moins partiellement, et que le support dex cution est d termin . Lapproche utilis e e e e e est celle de la simulation car la nesse de mod lisation que nous souhaitons prendre e en compte ne peut etre exploitable avec des m thodes formelles. Notre approche ne e ` soppose donc pas a dautres approches de v rication, elle les compl` te en se placant e e ` a un niveau qui permet dobtenir une tr` s grande pr cision temporelle, donc qui permet e e dobtenir des r sultats tr` s proches de la r alit . e e e e

Lanalyse ne, en vue de v rication, du comportement temporel de programmes e ne peut senvisager quen prenant en compte le support dex cution correspondant, e cest-` -dire le mat riel (processeur, r seau, . . . ) et le logiciel de base (ex cutif temps a e e e r el, services de communication, pilotes des dispositifs mat riels). On parle alors de e e v rication sur larchitecture op rationnelle, celle-ci pouvant etre consid r e comme e e ee la projection de larchitecture logicielle (les programmes qui apportent les fonctionnalit s) sur le support dex cution. Lobjectif vis est donc la simulation dune archie e e tecture op rationnelle comprenant une architecture mat rielle d crite nement, et une e e e architecture logicielle connue (indirectement) au travers des programmes ex cutables e (code applicatif et code syst` me). L tude sest concr tis e par la r alisation dun sie e e e e mulateur darchitecture op rationnelle [7], pour le processeur Inneon C167 incluant e un contr leur CAN [4] (tous deux tr` s utilis s dans le domaine du transport automoo e e e bile). Trois aspects ont et particuli` rement etudi s : e e la trace des variables. Une variable pertinente de lapplication est trac e au e ` e cours de la simulation. Ces informations peuvent servir a d terminer la cause ` du non respect dune contrainte temporelle, relatif a une production de donn e e tardive ou un processeur / r seau surcharg , par exemple ; e e la d tection de la t che en cours permet de d terminer lordonnancement des e a e t ches de lapplication, et eventuellement de le mettre en relation avec une anaa lyse dordonnancabilit analytique ; e l tude de la pile associ e a une t che. Dans le cas de lutilisation dun ex cutif e e ` a e avec des t ches statiques, un m canisme permettant de v rier et dimensionner a e e correctement les piles associ es aux t ches est propos . Cest un des probl` mes e a e e majeurs rencontr s par les concepteurs de logiciels temps r el. e e Cet article porte sur les deux derniers aspects mentionn s ci-dessus (pour le pree mier voir [8] [6]). La section suivante d crit les principes utilis s pour loutil danae e ` e lyse, et les deux suivantes sattachent a pr senter les r sultats obtenus avec lanalyse e de lordonnancement et des piles des t ches temps r el. Les techniques pr sent es ne a e e e ` se basent que sur le code ex cutable de lapplication a valider (aucune instrumentation e du code source).

Loutil ReTiS

ReTiS est constitu de deux parties : e un simulateur darchitecture mat rielle multiprocesseurs permettant dex cuter e e une application distribu e. La simulation est fonctionnellement exacte et la e pr cision temporelle d pend de la pr cision des mod` les employ s. e e e e e une interface graphique permettant de synth tiser sous une forme exploitable e 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. e a La plateforme de mod lisation et de simulation est bas e sur SystemC [9]. Syse e temC est un framework orient objet ecrit en C++ et support par lOSCI (Open Syse e temC Intitative), une organisation ind pendante r unissant une vingtaine dindustriels e e (micro lectronique, syst` me, logiciel embarqu , . . . ). Il est distribu sous une licence e e e e

Open Source. Plusieurs types de mod lisation et de simulation sont possibles : du nie ` veau transfert de registre a registre (RTL) au niveau syst` me. Une biblioth` que de e e classes et de templates permet de mod liser des composants, des liens pour relier e les composants et des signaux pour v hiculer des informations sur les liens. Les cae ` ract ristiques de base de SystemC sont comparables a celles que lon trouve dans les e langages de description de composants mat riels (HDL) comme VHDL ou Verilog. e De plus, depuis la version 2, SystemC propose des objets plus adapt s a la simulation e ` e e de syst` mes : les canaux, les interfaces et les ev nements. Ce niveau plus elev de e conception est appel TLM : Transaction Level Modelling. Le fait dadopter SystemC e comme environnement de travail pr sente plusieurs avantages : e les mod` les disponibles aupr` s des fondeurs peuvent etre facilement incorpor s ; e e e toute biblioth` que C ou C + + peut etre utilis e par un mod` le SystemC ; e e e la disponibilit du code source permet dadapter le moteur de simulation si e n cessaire. e Larchitecture distribu e pr sent e ci-dessous est constitu e de plusieurs procese e e e seurs Inneon C167 connect s par un r seau CAN. Ce type darchitecture est courame e ment employ dans les syst` mes temps r el embarqu s pour lautomobile et permet e e e e de mod liser un syst` me r aliste et raisonnablement complexe. La mod lisation de e e e e larchitecture op rationnelle compl` te est trait e en d tail dans [7] [6]. e e e e

2.1

Mod lisation du processeur Inneon C167 e

` Le cur du microcontr leur C167[14] est compos dun pipeline a 4 etages (avec o e un cache de saut), dune unit arithm tique et logique (ALU) 16 bits ainsi que dun e e ensemble de registres sp ciques (Special Function Registers). Il dispose, de plus, e dune unit de multiplication / division s par e, dune unit de masquage de bit et e e e e dun barrel shifter 1 . Sa fr quence peut atteindre 33 MHz. e Dans le contexte temps r el, il est n cessaire non seulement de simuler le compore e tement fonctionnel du processeur, mais aussi son comportement temporel, en respectant les d lais d s au mat riel. On peut distinguer deux types dapproches int ressantes e u e e pour la simulation : le simulateur de jeu dinstructions (ISS pour Instruction Set Simulator)[3], ne ` reproduit que le comportement fonctionnel du processeur, cest a dire que larchitecture interne (pipeline, unit s de calculs d di es, . . . ) nest pas du tout e e e mod lis e. Dans ce contexte, toutes les instructions ont la m me dur e : 1 cycle ; e e e e la simulation pr cise au cycle pr` s prend en compte un mod` le pr cis de larchie e e e tecture interne du processeur an de simuler non seulement le fonctionnement du processeur, mais aussi fournir des informations temporelles au cycle pr` s. La e complexit qui en d coule entrane des temps de calculs plus importants. e e Ces deux sch mas de simulation ont chacun leurs int r ts et leurs inconv nients. e ee e Le premier est rapide et le deuxi` me pr cis, ce qui est essentiel dans notre cas. An e e e dutiliser les avantages de ces deux approches, un simulateur modulaire a et concu. Il permet de commuter dun sch ma vers lautre au cours de la simulation. Ainsi, e une s quence critique du logiciel peut etre simul e nement avec les informations e e
1 registre

` e a d calage qui peut d caler plusieurs bits en une seule fois e

temporelles et une autre partie moins critique ex cut e plus rapidement en mode de e e simulation du jeu dinstructions. De facon a assurer la synchronisation et la communication avec les autres dispo ` sitifs, comme les contr leurs CAN, le mod` le de processeur est encapsul dans un o e e module SystemC. Le module poss` de une entr e dhorloge, et une transition sur cette e e derni` re provoque lappel dune m thode C ++ qui simule 1 cycle de fonctionnement e e e du processeur. Des mod` les (p riph riques, el ments de lenvironnement) peuvent fae e e cilement etre ajout s. e

2.2

Mod lisation du contr leur CAN e o

Le protocole CAN (Controller Area Network) de Bosch[4] est un protocole de ` communication s rie assurant la diffusion able de messages sur un bus a faible co t. e u Cest un protocole mature (exp rimentations depuis 1986) qui d nit une surveillance e e e tr` s stricte du bus. La gestion du bus est dirig e par les ev nements (Event-Triggered ). e e Le bus est de type multi-matres asynchrone. Il ny a pas de m moire commune, pas e de contr leur de trac, pas dhorloge globale et une station peut emettre d` s que le o e bus est libre. ` Une trame est compos e dun identiant de message. Cet identiant sert a la fois e ` a caract riser la donn e embarqu e dans le message (vitesse du v hicule, vitesse de e e e e ` rotation du moteur par exemple) et a donner sa priorit . En cas de collision sur le bus, e le message le plus prioritaire nest pas d truit, le ou les autres messages seront r emis e e d` s que le bus sera de nouveau libre. e ` Labsence dhorloge globale conduit a synchroniser l metteur et le r cepteur sur e e les transitions entre 0 et 1. Si le message contient plus de 5 bits cons cutifs de valeur e identique, un bit suppl mentaire de valeur oppos e est ins r . Ce syst` me, le bit stufe e ee e ng, peut augmenter le temps de transmission dun message jusqu` 18%. Cest lune a des raisons qui n cessite une mod lisation sufsamment ne du contr leur CAN pour e e o simuler correctement le comportement temporel du bus. e e e ` La mod lisation du contr leur CAN a et r alis e a deux niveaux diff rents, la e o e pr cision requise dans les deux cas est celle du bit, cest-` -dire que la transmission / e a r ception des messages seffectue au niveau du bit. La premi` re m thode est bas e sur e e e e une approche par composants de type VHDL en utilisant SystemC, la mod lisation e ` etant au niveau RTL. La deuxi` me approche conduit a une mod lisation au niveau e e transactionnel et, fonctionellement, le mod` le s loigne quelque peu du composant e e r el en int grant un arbitre dans le bus. Cette derni` re mod lisation utilise lapproche e e e e TLM, cest celle que nous utilisons car elle est la plus efcace.

2.3

Simulation de larchitecture compl` te e

Larchitecture dans son ensemble peut comprendre autant de nuds que n cessaire, e la seule limite etant la quantit de m moire disponible. Chaque nud comprend les e e modules SystemC pr sent s pr c demment (processeur et contr leur CAN) qui sont e e e e o synchronis s via SystemC. An dobtenir de meilleures performances du simulateur, e ni les acc` s m moire ni les acc` s aux circuits p riph riques (contr leur CAN, timers, e e e e e o

. . . ) ne sont mod lis s au niveau RTL. Toutefois, les d lais engendr s par ces acc` s e e e e e sont mod lis s pr cis ment. e e e e

Les actions

e Une action est une portion de code qui est ex cut e a la suite dun ev nement e e ` g n r par le simulateur, par exemple lors dun acc` s en lecture ou en ecriture dans e ee e la m moire du processeur. Une action est dat e par le num ro du cycle de lhorloge e e e de base de la simulation. Cette technique est, dune part, particuli` rement int ressante e e pour interfacer le processeur avec certains composants internes comme les timers, les composants r seaux (CAN, interface s rie), le contr leur dinterruption, les ports I/O, e e o . . . Dautre part, laction est l l ment de base qui permet lanalyse des piles et des ee t ches. a Trois types d v nements sont utilis s et associ s a des actions pour cette analyse : e e e e ` un acc` s en lecture a une adresse m moire. On entend par m moire, dans ce e e e ` e contexte, tout el ment qui permet lenregistrement de donn es, que ce soit la e m moire programme / donn es ou les registres g n raux ou sp ciques (ree e e e e gistres dacc` s a des composants mat riels) ; e ` e un acc` s en ecriture a une adresse m moire ; e e ` une ex cution de linstruction a une adresse du code programme. e `

Analyse de lordonnancement des t ches a

Dans les syst` mes embarqu s critiques, les t ches sont g n ralement statiques et e e a e e ont donc la m me dur e de vie que lapplication, comme par exemple dans le syst` me e e e dexploitation OSEK-VDX2 . Le m canisme pr sent ici nest applicable que dans ce e e e cas de gure, cest-` -dire que lallocation dynamique de t che nest pas trait e. Dans a a e ce dernier cas, il serait n cessaire de d tecter linstant de cr ation et de destruction de e e e chaque t che. a Une approche statique, comme celle pr sent e dans [11] serait inefcace dans ce e e contexte. En effet, cette approche ne peut pas traiter les formes bas es sur des sauts e calcul s au moment de lex cution (saut indirect), utilis s notamment dans les routines e e e de changement de contexte dun ex cutif temps r el. Elle permet par contre (dans le e e cas mono-processeur) dobtenir des r sultats exhaustifs sur lutilisation de la pile. e Ce m canisme ne requiert pas que la pile soit correctement dimensionn e, cest-` e e a dire quune corruption de pile par d passement avant (underow) ou apr` s (overow) e e la zone de pile initialement allou e est admissible. Cette hypoth` se forte est indispene e sable pour permettre lanalyse des piles dans la section 5. Nous consid rons ici un ex cutif temps r el dont nous ne connaissons pas le e e e comportement lors des changements de contexte. Les sources de lex cutif peuvent e
2 http://www.osek-vdx.org. OSEK-VDX est noyau temps r el multi-t ches pr emptif qui e a e e e couvre les applications de contr le embarqu dans les v hicules. Il a et d velopp pour fournir une intero e e e face de programmation (API) standard entre les diff rents composants logiciels, favorisant une portabilit e e des applications au niveau source.

dailleurs ne pas etre disponibles. Les hypoth` ses sur lex cutif temps r el a analyser e e e ` sont : lutilisation de t ches statiques, cest-` -dire que leurs dur es de vie corresa a e ` pondent a la dur e de vie du programme ; il ny a pas de cr ation de t che e e a ` en cours dex cution ; elles sont donc d nies a linitialisation de lapplication ; e e le syst` me est multit che, sans hypoth` se sur lordonnancement ; e a e chaque t che poss` de sa propre pile ; a e aucune connaissance a priori sur lex cutif nest n cessaire, mais le changement e e ` de contexte est r alis suite a un appel de fonction ; e e lex cutif fait un usage correct du jeu dinstructions, cest-` -dire que la e a s mantique associ e aux instructions du processeur est respect e. Par exemple, e e e ` ` linstruction calls correspond bien a un appel de fonction, et rets a un retour de fonction. Cette hypoth` se est respect e par les compilateurs. e e Quand une t che est ex cut e, le pointeur de pile (Stack Pointer) est positionn a e e e ` e dans la plage de pile de la t che. Une premi` re approche consiste alors a d tecter la a e t che courante (en cours dex cution) en se basant sur la valeur courante du pointeur a e de pile. Cependant, si la pile est corrompue, la connaissance de la valeur du pointeur de pile peut sav rer insufsante et linterpr tation de la t che courante est alors erron e. e e a e Dans le cas de deux piles contigu s par exemple, un d bordement de pile serait alors e e interpr t comme un changement de contexte, car le pointeur de pile evolue alors dans ee la plage dadresse de la pile dune autre t che. a Le m canisme de d tection des t ches que nous proposons ici est bas sur la e e a e ` d tection des changements de contexte a la n des fonctions. Il sensuit quun changee ment de contexte sera d tect d` s quune fonction syst` me de changement de contexte e e e e termine son ex cution. e

4.1

Principe g n ral e e

Consid rons le sc nario avec deux t ches pr sent dans la gure 1, avec trois chane e a e e gements de contexte. Les 2 t ches sont pr tes a etre ex cut e, et la t che 1 est la plus a e ` e e a ` prioritaire. La t che 1 est d marr e ( 1 ), elle commence a sex cuter puis appelle la a e e e ` fonction waitEvent. Cette fonction syst` me (interne a lex cutif) bloque la t che 1 et e e a effectue un changement de contexte vers lautre t che ( 3 ). La t che 2 nouvellement a a d marr e appelle alors la fonction f ( 4 ) qui se termine normalement ( 5 ). La fonce e tion syst` me setEvent est ensuite appel e ( 6 ) qui r veille la t che 1 et donc r alise un e e e a e nouveau changement de contexte. La t che 1 continue son ex cution puis se termine a e en appelant la fonction syst` me terminateTask ( 8 ). La t che 2 continue alors son e a ex cution. Cet exemple utilise ainsi trois fonctions syst` mes qui r alisent un changee e e ` ment de contexte (waitEvent, setEvent et terminateTask). La fonction g quant a elle peut etre une fonction utilisateur ou syst` me. Dans cet exemple, les appels syst` mes e e sont emprunt s a lex cutif OSEK-VDX, mais le principe pr sent ici est ind pendant e ` e e e e de lex cutif consid r . Dans cet exemple, les changements de contextes ont lieu direce ee tement dans lappel syst` me (et non pas dans une autre fonction d di e qui r aliserait e e e e le changement de contexte). Dans ce sc nario, les changements de contexte (qui ne peuvent etre d tect s qu` e e e a

waitEvent
{

Tche 1 a
1

Tche 2 a
3

{
4

setEvent
6

fonction f
{
5

{
7

} }
8 9

} }

terminateTask
{

F IG . 1 Un exemple simple avec des changements de contexte de deux t ches. Les a ` fonctions syst` mes (internes a lex cutif) waitEvent, setEvent et terminateTask effece e ` tuent un changement de contexte. La fonction f quant a elle est une simple fonction appel e par la t che 2. e a

la n de la fonction) doivent etre d tect s en quatre points ( 1 , 3 , 7 et 9 ) dans e e le ot dex cution, cest-` -dire quand les t ches sont r veill es. Il est n cessaire de e a a e e e diff rencier deux cas : e celui du d marrage dune t che (ou la r activation) qui peut etre d tect en e a e e e utilisant une action dat e, plac e une fois au d marrage du simulateur, associ e e e e e ` e a un ev nement dex cution de code, sur la premi` re instruction de la t che, aux e e a points 1 et 3 ; celui du changement au cours de lex cution de la t che. Celui-ci est produit e a par une interruption qui provoque un changement de contexte (si la pr emption e est autoris e) ou un appel syst` me. Il est n cessaire dans ce cas deffectuer un e e e traitement pour chaque appel de fonction et pour chaque retour de fonction, aux points 7 et 9 .

4.2
4.2.1

Analyse des activations des t ches a


D marrage dune t che e a

Les deux seules informations qui sont n cessaires au simulateur sont le nom de la e fonction principale de la t che, cest-` -dire la fonction qui sera appel e la premi` re a a e e fois que la t che est lanc e, ainsi que la valeur initiale de la pile. La valeur initiale de a e la pile est d tect e automatiquement la premi` re fois que la t che est d marr e. e e e a e e D` s quune t che est d marr e, une action dat e (associ e a l v nement ex cue a e e e e ` e e e tion du code ) plac e a la premi` re instruction de la t che est activ e. Celle-ci va alors e ` e a e 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 a e a e comparer les valeurs de piles initiales car plusieurs t ches peuvent utiliser le m me a e code de t che. On ne peut alors les diff rencier quavec la pile. a e

En effet, si deux t ches poss` dent la m me fonction principale, elles seront d a e e e clar es de la m me mani` re par lutilisateur. Au d marrage de la premi` re des deux, e e e e e la valeur initiale de la pile va etre d tect automatiquement. Lors dune autre activae e tion de t che, si la pile a une valeur diff rente que celle pr c demment d tect e, cest a e e e e e que la deuxi` me t che est activ e et la valeur initiale de pile correspondante est enree a e gistr e. Les deux t ches sont alors correctement distingu es au niveau du simulateur. e a e ` a Le principe s tend a n t ches partageant la m me fonction principale. e e 4.2.2 Changement de contexte au cours de lex cution de la t che e a

Le m canisme est d coup en une partie qui est ex cut e quand il y a un appel de e e e e e fonction et une autre partie qui va etre d clench e lors dun retour de fonction. e e Consid rons lexemple de code suivant : e 0x1bc8 : bset PSW.11 0x1bca : calls #0x0, f (0x1FFA) ;appel de la fonction f 0x1bce : mov T0IC, #0x4C ;premi`re instruction e ;apr`s le retour de f e

` Dans un premier temps, a chaque fois quune fonction est appel e (ici en 0x1bca), e la valeur du pointeur de pile ainsi que la t che courante sont enregistr es et une aca e tion dat e (associ e a l v nement ex cution de linstruction) est plac e a ladresse e e ` e e e e ` de linstruction qui suit lappel 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. e Pour le C167, il faut prendre en compte les instructions calla, callr, calli, calls, pcall, trap ainsi que les m canismes dinterruptions mat rielles. Dans e e le cas des interruptions mat rielles, une action dat e est plac e au niveau de linstruce e e tion qui aurait d etre ex cut e sil ny avait pas eu dinterruption. Cette instruction u e e est la premi` re instruction ex cut e au retour de linterruption. e e e Dans un deuxi` me temps, lors dun retour de fonction, laction dat e est d clench e e e e e et le comportement de laction d pend de la comparaison entre la valeur du pointeur e de pile et celle qui est enregistr e. La valeur de la pile doit etre la m me avant lappel e e de fonction et au retour de cet appel car le pointeur dinstruction (Program Counter) est toujours enregistr en haut de la pile3 . Le principe est le m me pour les interrupe e tions, qui peuvent etre percues comme des appels de fonctions (car une interruption empile, comme une instruction dappel de fonction, le pointeur dinstruction). Les deux valeurs sont compar es et il sen suit que : e si les deux valeurs sont egales, la t che en cours dex cution est la m me que a e e celle qui etait active lors de lappel de la fonction. La t che courante est alors a d tect e a cet instant. On ne se sert dans ce cas de la valeur du pointeur de pile e e ` ` que pour la comparer a la pr c dente, et d terminer ainsi la t che courante. e e e a
3 eventuellement

avec dautres registres comme le registre de segment.

si les deux valeurs ne sont pas egales, cest que la t che courante nest pas celle a qui etait active lors de lappel de fonction. Ce cas se produit pour deux t ches a (ou plus) qui partagent le m me code. Les deux t ches vont appeler les m mes e a e fonctions et par cons quent placer des actions dat es sur les m mes adresses e e e m moires. Bien entendu, une seule des actions dat es eveill es aura une valeur e e e ` de pile egale a la valeur courante du pointeur de pile. Cest donc la comparaison entre la valeur du pointeur de pile enregistr et la valeur e courante qui permet de d terminer correctement la t che en cours dex cution. e a e Cependant, il se peut quaucune t che ne soit d tect e a cet instant. Ceci arrive sil a e e ` y a une action dat e, mais que les valeurs de pile (celle enregistr e et la courante) ne e e sont pas identiques. Dans ce cas, le simulateur d tecte bien quil y a eu un changement e ` de t che, mais celui-ci ne correspond a aucune des t ches quil doit suivre. Comme a a le simulateur ne peut pas d terminer la t che courante, on introduit la notion de t che e a a inconnue. ` Ce principe sapplique a chaque appel de fonction, et il y a alors autant dactions dat es de cr ees pour une t che quil y a de fonctions (et dinterruptions) imbriqu es. e e a e De plus, ce principe ne requiert pas dutiliser directement linstruction de n de fonction (ret), une instruction effectuant un saut indirect est aussi acceptable, comme ce quon peut retrouver sur une routine de changement de contexte dans un ex cutif. e Avec une telle mod lisation, si un d passement de pile intervient (stack overow e e e / underow), la d tection des t ches reste correcte. Si la pile na pas et correctement e a g r e, par un nombre dempilements diff rent du nombre de d pilements, la d tection ee e e e en retour de fonction est impossible. Cependant ce cas g n` re un fonctionnement ere e ron du programme imm diatement. Cest ainsi, une bonne estimation de la t che e e a courante permet deffectuer une analyse dynamique de la validit des piles. e Les actions dynamiques sont cr ees pour chaque instruction capable de faire un e appel de fonction. Limpl mentation au niveau du simulateur de ces instructions est e donc l g` rement modi e pour pr venir le simulateur quun appel a lieu. Ces actions e e e e dat es doivent cependant etre d truites d` s que leur utilisation nest plus n cessaire. e e e e Ainsi, d` s que la fonction retourne, laction dat e est d clench e et d truite ensuite. e e e e e Cependant, dans certains cas, ce comportement nest pas sufsant. Consid rons par e ` exemple une pile qui est r initialis e, par exemple a chaque fois que la pile est ace e tiv e. Dans ce cas, il est n cessaire de non seulement supprimer la derni` re action e e e dat e, mais aussi de v rier lors de lajout dune action dat e, que cette nouvelle e e e ` entr e correspond bien, dans la liste des actions dynamiques, a la valeur de pile la plus e profonde.

4.3

Un exemple d tude e

Un exemple de commande de moteur va permettre de pr senter la visualisation e des r sultats de ReTiS. Comme le montre la gure 2, la plate-forme mat rielle utilis e e e e est compos e de deux processeurs C167 reli s par un bus CAN. Lex cutif utilis pour e e e e les deux nuds est OSEK / VDX OS [10], avec les services de communication OSEK / VDX COM. ` Limpl mentation de lex cutif a notre disposition utilise deux t ches pour la gese e a

nud de commande Superviseur


acheur LCD Nud 0 consigne vitesse Port P5 consigne (task40 ) (task30 ) (task41 ) (task31 ) vitesse port P5 Moteur Nud 1 commande PWM (task51 )

COM EXTERNE CAN bus vitesse moteur consigne moteur

COM EXTERNE vitesse moteur consigne moteur

F IG . 2 Exemple d tude. Le nud 0 est le superviseur. Le nud 1 est le nud e de commande, qui fait lasservissement en vitesse du moteur. Les t ches Task30 , a Task41 et Task51 sont p riodiques. Les t ches Task40 et Task31 sont activ es e a e sur r ception dun message CAN. e

tion de lex cutif (une t che principale, et une pour le traitement des interruptions), e a et deux t ches pour la communication (une pour l mission des trames, Task1, et a e lautre pour la r ception, Task2). Pour chaque nud, un timer est activ , g n rant e e e e une interruption toutes les millisecondes. Le premier nud (node0) est le superviseur. Il est equip dun afcheur LCD et e dune connexion permettant de rentrer la valeur de la consigne (` travers le port 16 a bits P5). Il poss` de deux t ches (Task30 4 et Task40 ). e a la t che Task30 est p riodique (p riode de 4ms). Elle lit la valeur de la consigne a e e sur le port P5 et envoie cette valeur au nud node1 ; la t che Task40 est charg e de la gestion de lafcheur LCD. Elle est activ e a e e d` s quune trame CAN contenant la valeur de la vitesse du moteur est recue. e Le second nud (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 cape e teur sur le moteur permet dobtenir une image de la vitesse ; elle est accessible via le port 16 bits P5 : la t che Task31 est activ e d` s quune trame contenant la consigne de vitesse a e e est recue. La valeur de la consigne est alors stock e dans une variable globale e (consigne), prot g e en utilisant une ressource (en utilisant la m thode du e e e Priority Ceiling Protocol [12]), car lacc` s a une variable nest pas atomique ; e ` la t che Task41 est p riodique. Elle envoie toutes les 4 ms la valeur de la a e vitesse au nud superviseur pour lafchage ; la t che Task51 est la t che de contr le du moteur. Elle est p riodique de a a o e p riode 2 ms. e
4 Dans limpl mentation dOSEK-VDX a notre disposition, les t ches sont d clar es en utilisant la ` e a e e macro TASK(id). Lutilisateur na donc pas le choix du nom de la t che. Pour diff rentier les t ches a e a de chaque nud, le num ro du nud est mis en indice. e

` F IG . 3 Diagramme de Gantt des t ches. A chaque ligne correspond une t che. Quand a a aucune t che nest d tect e, la t che 0 est utilis e (une par processeur). Elle est visuaa e e a e lis e dune autre couleur. Les dates, afch es en petit, indiquent les dates dactivations e e et de n dex cution de la t che. Lutilisateur a le choix des t ches quil veut visualiser. e a a

4.4

Exploitation des r sultats e

La d tection des t ches, an de construire le diagramme de Gantt de lordonnancee a ment des t ches, est r alis e en deux temps, cest-` -dire avec une phase dinitialisation a e e a et une autre phase dexploitation des r sultats. e ` Durant la phase dinitialisation, les t ches a analyser sont d clar es au simulaa e e teur. Dans notre cas, la t che principale de lex cutif est d clar e (main), ainsi que a e e e les t ches applicatives (Task30 , Task40 , Task31 , Task41 et Task51 ). Les deux a t ches utilis es pour la communication externe et la t che utilis e pour le traitement a e a e des interruptions ne sont pas d clar es, elles apparatrons dans la t che inconnue. e e a Apr` s la simulation, lactivation des t ches est pr sent e par un diagramme de e a e e Gantt de la m me mani` re que dans les diagrammes dordonnancement. Ainsi, les e e t ches sont repr sent es sur laxe des ordonn es. Un rectangle plein est utilis pour a e e e e chaque instance de t che (gure 3). Toutes les p riodes dactivit s des t ches sont a e e a ` ` dat es (la date en haut correspond a lactivation et la date en bas correspond a la n e dactivit de la t che). Dans cet exemple, on peut remarquer la pr sence des interrupe a e tions caus es par le timer toutes les millisecondes, sur les deux processeurs, ainsi que e les interruptions li es a larriv e ou lenvoi de trames CAN. On peut de m me remare ` e e quer que la t che Task40 occupe longtemps le processeur (par rapport aux autres a t ches), entre les dates 288358 et 291002, soit 2644 cycles (132 s). Ceci vient du a fait que la fonction printf pour l criture sur le LCD n cessite beaucoup de calcul. e e Linterruption li e a l mission ou la r ception correcte dun message CAN est prise e ` e e en compte en m me temps sur les deux nuds, aux dates 284561 et 287081 cycles. e

Analyse de la pile

Le dimensionnement des piles des t ches est un probl` me difcile et le besoin a e ` dune aide a ce dimensionnement est tr` s fr quemment exprim chez les concepteurs e e e ` dapplications temps r el. Cette information, extraite a partir de l tude de la pile, e e peut etre utilis e pour v rier la s ret de la pile ainsi que pour essayer de r duire e e u e e lespace m moire allou initialement. Lanalyse de la pile dune t che est largement e e a e e bas e sur la technique de d tection de la t che courante qui a et pr sent e dans la e e a e section pr c dente. e e Lanalyse des piles se fonde sur une approche de protection m moire impl ment e e e e dans le simulateur. Tout acc` s a une plage m moire avant et apr` s la plage m moire e ` e e e r serv e a la pile est d tect e et signal e a lutilisateur. Cette protection m moire se e e ` e e e ` e e base elle m me sur des actions dat es qui sont associ es a des ev nements acc` s en e e e ` e ecriture a une adresse m moire. Les limites de la piles sont ainsi d termin es : la taille e e e ` de la pile est connue et son origine est obtenue la premi` re fois que la t che est activ e. e a e

5.1

D tection de la taille utile e

An de d tecter la taille de pile effectivement exploit e, une action est plac e sur e e e chaque octet de la zone de la pile. Chacune de ces actions est dot e dun drapeau qui e est positionn lors dun acc` s en ecriture. Apr` s que le sc nario d ni par lutilisateur e e e e e e e e de la simulation ait et ex cut , le dernier octet ecrit donne la taille de pile r ellement e exploit e. Cette m thode nest pas d pendante de la mani` re dont les compilateurs e e e e utilisent la pile. En effet, certains compilateurs C ne modient pas le pointeur de pile dans les fonctions terminales (celles qui nappellent pas dautre fonction) ou bien copient le pointeur de pile dans un autre registre avant de faire des acc` s indirects en e m moire. Dans ces cas, le pointeur de pile nindique pas lutilisation r elle de la pile. e e

5.2

D tection des d bordements de pile e e

La d tection de la corruption de la pile est bas e sur la protection m moire. Pour e e e chaque pile, deux plages dadresses sont sp ci es. Pour chaque octet de la zone de e e protection, une action dat e est plac e an d tre activ e sur les acc` s en ecriture. Si e e e e e un acc` s en ecriture a lieu dans lune de ces zones et que la pile est bien celle de la e t che courante, une erreur est d tect e. Il est important de v rier quelle est la t che a e e e a en cours car une zone prot g e pour une t che peut etre une zone correcte pour une e e a autre t che. a La zone de protection doit etre sufsamment large pour d tecter les corruptions de e pile. En effet, si les piles syst` me et utilisateur sont r unies en une unique pile, le come e pilateur peut effectuer des d calages pour acc der aux donn es locales. Dans le cas e e e dune pile syst` me seule, une zone de protection dun octet est sufsante. Cependant, e cette zone de protection ne doit pas etre trop importante non plus car le m canisme e peut interf rer avec de la m moire utilis e autrement, par des variables globales par e e e exemple. Dans le C167, les registres g n raux sont situ s en m moire, dans une zone e e e e proche de la zone r serv e aux piles, ce qui peut etre g nant dans certains cas. e e e

Conclusion

Les travaux pr sent s dans cet article concernent la simulation dune architecture e e op rationnelle comprenant une architecture mat rielle d crite nement (processeurs et e e e r seaux), et une architecture logicielle connue au travers des programmes ex cutables e e (code applicatif et code syst` me). Simuler n tait bien s r pas un but en soi : lobjectif e e u etait de tirer des sc narii etudi s un ensemble de r sultats exploitables par le concepe e e teur dune application temps r el. Une contribution de ces travaux se situe dans les e ` m canismes g n riques dextraction dinformations a partir de la simulation bas e e e niveau de lex cution des programmes, pour en d duire des informations haut nie e veau exploitables par le concepteur. Ces m canismes, construits autour des actions, e restent utilisables pour les architectures evolu es (plus complexes que celle du C167) e comprenant, entre autres, des m moire cache et des architectures dex cution come e plexes (superscalaires, ex cution dans le d sordre, . . . ). e e e e Une contribution au niveau de lanalyse de lordonnancement a et pr sent e. Un e m canisme permettant de d tecter la t che courante en ex cution sur un processeur, e e a e e et donc de reconstruire lordonnancement des t ches a et propos . Ce m canisme a e e ne fait que tr` s peu dhypoth` ses (tr` s r alistes) sur lex cutif temps r el. Lexploie e e e e e tation des r sultats est faite graphiquement sous la forme dun diagramme de Gantt e par loutil ReTiS. Une autre application, indirecte car ce nest pas la seule mani` re de e faire, est lobservation des temps dex cution des t ches. Ceci est tr` s important pour e a e la v rication dhypoth` ses faites bien avant dans le cycle de conception, en terme de e e budgets allou s aux t ches. e a Une autre contribution au niveau de lanalyse de la pile associ e a chaque t che e ` a e e e a et pr sent e. Un m canisme a et propos permettant de d tecter la corruption e e e e des piles (d passement dans les deux sens), et daider au dimensionnement des piles e en d terminant lutilisation r elle sur un sc nario. Ce probl` me du dimensionnement e e e e des piles fait partie de ceux fr quemment evoqu s par les ing nieurs de conception e e e dapplication temps r el, lanalyse statique ne permettant en effet pas de prendre en e compte un certain nombre de cas. e Toutes ces fonctionnalit s ont et impl ment es dans loutil prototype ReTiS, coue e e pl avec une chane industrielle de production de code. Mis en uvre sous forme dun e serveur et dun client communiquant aux moyens de sockets, les parties simulation et exploitation peuvent etre distribu es sur des machines adapt es. e e Les travaux se poursuivent actuellement dans deux axes : dune part nous souhaitons am liorer le niveau dexpression des contraintes e temps r el sur lanalyse des variables, an de faciliter la sp cication des cone e ` e traintes a v rier, par exemple entre la production et la consommation dune valeur ; dautre part nous travaillons sur la d nition dun langage de description de e larchitecture mat rielle (aspects structurels et comportementaux), int grant le e e concept daction et la s mantique des instructions pour la trace des variables. e ` Ceci permettrait de r duire leffort n cessaire a la mod lisation dun nouveau e e e processeur, ainsi que la prise en compte darchitectures plus complexes.

R f rences ee
[1] Lars Albertsson and Peter S. Magnusson. Using complete system simulation for temporal debugging of general purpose operating systems and workloads. In MASCOTS 2000, 2000. [2] P.O Ribet et F. Vernadat B. Berthomieu. Loutil tina. construction despaces d tats abstraits pour les r seaux de petri et r seaux temporels. In Colloque Frane e e cophone sur la Mod lisation des Syst` mes R actifs (MSR03), Octobre 2003. e e e [3] Robert Bedichek. Some efcient architecture simulation techniques. In Winter 1990 USENIX Conference, pages 5363, January 1990. [4] Robert BOSCH. CAN Specication version 2.0, 1991. [5] B atrice B rard, Patricia Bouyer, and Antoine Petit. Analysing the pgm protoe e col with UPPAAL. International Journal of Production Research, 42(14) :2773 2791, 2004. [6] Mika l Briday. Validation par simulation ne dune architecture op rationnelle. e e PhD thesis, IRCCyN - Universit de Nantes, december 2004. e [7] Mika l Briday, Jean-Luc B chennec, and Yvon Trinquet. Modelisation of a dise e tributed hardware system for accurate simulation of real time applications. In Proceedings of 5th IFAC International Conference on Fieldbus Systems and their Applications (FeT03), july 2003. [8] Mika l Briday, Jean-Luc B chennec, and Yvon Trinquet. Retis : a real-time e e simulation tool for the analysis of distributed real-time applications. In 5th IEEE International Workshop on Factory Communication Systems. WFCS04, Vienna, Austria, pages 257264, 2004. [9] Cadence. An introduction to system http ://www.systemc.org, November 2002. design with systemc.

[10] OSEK Group. Osek/vdx operating system specication - version 2.2.2. http ://www.osek-vdx.org, july 2004. [11] Alastair Reid John Regehr and Kirk Webb. Eliminating stack overow by abstract interpretation. In 3rd International Conference on Embedded Software, pages 306322. Springer-Verlag, october 2003. [12] Sha L., Raikumar R., and Lehocsky J.P. Priority inheritance protocol : an approach to real-time synchronization. IEEE Transaction On Computer, 39(9) :11751185, 1990. [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 3443. IEEE, Winter 1995. [14] Inneon Technologies. C167cr derivatives 16-bi t single-chip microcontroller, users manual v3.1, 2000.

[15] Stavros Tripakis and Sergio Yovine. Verication of the fast reservation protocol with delayed transmission using the tool KRONOS. In Proc. 4th IEEE RealTime Technology and Applications Symposium (RTAS98), pages 165170. IEEE Computer Society Press, 1998.