Analyse de syst`emes temps réel distribués par simulation

Analyse de syst` emes temps r´ eel distribu´ es par
simulation: observation des tˆ aches et des piles
Mika¨ el BRIDAY, Jean-Luc B´ ECHENNEC, Yvon TRINQUET
[email protected]
IRCCyN Institut de Recherche en Communication et Cybern´ etique de
Nantes
UMR 6597
BP 92101 - 1, rue de la No¨ e
44321 Nantes Cedex 3
´
Equipe Syst` eme temps r´ eel
abstract : Cet article pr´ esente quelques concepts de l’outil de simulation ReTiS, d´ edi´ e
`
a l’analyse d’applications temps r´ eel distribu´ ees. La simulation prend en compte l’ar-
chitecture op´ erationnelle : l’architecture mat´ erielle (processeurs, r´ eseaux, ...) et l’ar-
chitecture logicielle (code applicatif et code syst` eme). L’analyse exploite une mod´ eli-
sation fine de l’architecture mat´ erielle (simulateur de jeu d’instruction ou simulateur
au niveau cycle) et permet de reconstruire l’ordonnancement des tˆ aches et l’usage
des pile en se fondant sur l’observation des ´ ev´ enements bas niveau de simulation.
Cette observation est bas´ ee sur un m´ ecanisme g´ en´ erique : l’action, traitement de
l’´ ev´ enement observ´ e. Ce m´ ecanisme ne n´ ecessite aucune modification du code ap-
plicatif ou syst` eme.
1 Introduction
2.1 Mod´ elisation du processeur Infineon C167
2.2 Mod´ elisation du contrˆ oleur CAN
2.3 Simulation de l’architecture compl` ete
2 L’outil ReTiS
3 Les actions
4 Analyse de l’ordonnancement des tˆ aches
4.1 Principe g´ en´ eral
4.2 Analyse des activations des tˆ aches
4.3 D´ emarrage d’une tˆ ache
4.4 Changement de contexte au cours de l’ex´ ecution de la tˆ ache
5 Analyse de la pile
5.1 D´ etection de la taille utile
5.2 D´ etection des d´ ebordements de pile
6 Conclusion
mot-cl´ es : Syst` eme distribu´ e temps r´ eel, Simulation au cycle pr` es, Analyse tempo-
relle, Analyse de pile, Mise au point de programmes.

1 Introduction
Les syst` emes temps r´ eel sont de plus en plus omnipr´ esents avec la g´ en´ eralisation
des calculateurs embarqu´ es, puissants et peu coˆ uteux. Ces syst` emes sont utilis´ es dans
des domaines tr` es vari´ es, par exemple les moyens de transport (automobile, a´ eronau-
tique), les chaˆ ınes de production, ...Ces syst` emes informatiques ont des exigences
fonctionnelles, comme tout syst` eme informatique, mais ´ egalement extra-fonctionnel-
les, comme par exemple les exigences temporelles. La validation est bien sˆ ur une
activit´ e indispensable sur de tels syst` emes car les cons´ equences d’une erreur peuvent
ˆ
etre graves tant sur le plan humain qu’´ economique.
La validation d’un syst` eme temps r´ eel est une op´ eration complexe. Un grand
nombre de m´ ethodes sont disponibles, beaucoup sont compl´ ementaires. De nombreux
crit` eres interviennent dans le choix d’une m´ ethode, crit` eres souvent d´ ependants les
uns des autres. On peut citer par exemple :
– le positionnement dans le cycle de d´ eveloppement. On privil´ egie g´ en´ eralement
une approche formelle dans les premiers stades de d´ eveloppement alors qu’une
approche par simulation est in´ evitable dans les derni` eres phases de test, quand
un grand nombre d’informations sont disponibles (support d’ex´ ecution d´ etermi-
n´ e, code partiel ou complet de l’application);
– le compromis entre l’exhaustivit´ e et la pr´ ecision du mod` ele par rapport ` a la
cible. Une ´ etude par simulation permet une pr´ ecision tr` es importante sur un
sc´ enario, mais bien sˆ ur ne peut pas pr´ etendre ` a la compl´ etude;
– la couverture de la m´ ethode, selon qu’elle prend en consid´ eration l’architecture
mat´ erielle sous-jacente (monoprocesseur, multiprocesseur), avec ou non le sup-
port logiciel d’ex´ ecution (ex´ ecutif temps r´ eel par exemple), la mod´ elisation de
l’environnement, etc
Dans les premiers stades du d´ eveloppement la d´ emarche de V&V (Validation et
V´ erification) consiste souvent ` a utiliser une mod´ elisation formelle de l’application, en
utilisant par exemple des formalismes tels que les automates [15] [5] ou les r´ eseaux
de Petri [2]. On peut alors obtenir la garantie, ou non, de l’existence des propri´ et´ es
que l’on cherche ` a prouver. Ceci doit toutefois ˆ etre temp´ er´ e, d’une part par le fait
que l’on travaille sur mod` ele et donc que cette preuve ne sera valide que si la «dis-
tance »entre le mod` ele et la r´ ealit´ e est faible, et d’autre part par les limitations quant
`
a la taille des probl` emes analysables avec ces techniques. Plus tard dans le cycle de
d´ eveloppement, une autre approche, compl´ ementaire, consiste ` a faire la validation par
la simulation. On se heurte alors ` a la difficult´ e de la repr´ esentativit´ e des tests mais la
taille des probl` emes 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´ eveloppement, alors que le code final est disponible, au
moins partiellement, et que le support d’ex´ ecution est d´ etermin´ e. L’approche utilis´ ee
est celle de la simulation car la finesse de mod´ elisation que nous souhaitons prendre
en compte ne peut ˆ etre exploitable avec des m´ ethodes formelles. Notre approche ne
s’oppose donc pas ` a d’autres approches de v´ erification, elle les compl` ete en se plac¸ant
`
a un niveau qui permet d’obtenir une tr` es grande pr´ ecision temporelle, donc qui permet
d’obtenir des r´ esultats tr` es proches de la r´ ealit´ e.

L’analyse fine, en vue de v´ erification, du comportement temporel de programmes
ne peut s’envisager qu’en prenant en compte le support d’ex´ ecution correspondant,
c’est-` a-dire le mat´ eriel (processeur, r´ eseau, ...) et le logiciel de base (ex´ ecutif temps
r´ eel, services de communication, pilotes des dispositifs mat´ eriels). On parle alors de
v´ erification sur l’architecture op´ erationnelle, celle-ci pouvant ˆ etre consid´ er´ ee comme
la projection de l’architecture logicielle (les programmes qui apportent les fonction-
nalit´ es) sur le support d’ex´ ecution. L’objectif vis´ e est donc la simulation d’une archi-
tecture op´ erationnelle comprenant une architecture mat´ erielle d´ ecrite finement, et une
architecture logicielle connue (indirectement) au travers des programmes ex´ ecutables
(code applicatif et code syst` eme). L’´ etude s’est concr´ etis´ ee par la r´ ealisation d’un si-
mulateur d’architecture op´ erationnelle [7], pour le processeur Infineon C167 incluant
un contrˆ oleur CAN [4] (tous deux tr` es utilis´ es dans le domaine du transport automo-
bile). Trois aspects ont ´ et´ e particuli` erement ´ etudi´ es :
– la trace des variables. Une variable pertinente de l’application est trac´ ee au
cours de la simulation. Ces informations peuvent servir ` a d´ eterminer la cause
du non respect d’une contrainte temporelle, relatif ` a une production de donn´ ee
tardive ou un processeur / r´ eseau surcharg´ e, par exemple;
– la d´ etection de la tˆ ache en cours permet de d´ eterminer l’ordonnancement des
tˆ aches de l’application, et ´ eventuellement de le mettre en relation avec une ana-
lyse d’ordonnanc¸abilit´ e analytique;
–l’´ etude de la pile associ´ ee ` a une tˆ ache. Dans le cas de l’utilisation d’un ex´ ecutif
avec des tˆ aches statiques, un m´ ecanisme permettant de v´ erifier et dimensionner
correctement les piles associ´ ees aux tˆ aches est propos´ e. C’est un des probl` emes
majeurs rencontr´ es par les concepteurs de logiciels temps r´ eel.
Cet article porte sur les deux derniers aspects mentionn´ es ci-dessus (pour le pre-
mier voir [8] [6]). La section suivante d´ ecrit les principes utilis´ es pour l’outil d’ana-
lyse, et les deux suivantes s’attachent ` a pr´ esenter les r´ esultats obtenus avec l’analyse
de l’ordonnancement et des piles des tˆ aches temps r´ eel. Les techniques pr´ esent´ ees ne
se basent que sur le code ex´ ecutable de l’application ` a valider (aucune instrumentation
du code source).
2 L’outil ReTiS
ReTiS est constitu´ e de deux parties :
– un simulateur d’architecture mat´ erielle multiprocesseurs permettant d’ex´ ecuter
une application distribu´ ee. La simulation est fonctionnellement exacte et la
pr´ ecision temporelle d´ epend de la pr´ ecision des mod` eles employ´ es.
– une interface graphique permettant de synth´ etiser 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´ eressont qu’` a la partie simulateur.
La plateforme de mod´ elisation et de simulation est bas´ ee sur SystemC [9]. Sys-
temC est un framework orient´ e objet ´ ecrit en C++ et support´ e par l’OSCI (Open Sys-
temC Intitative), une organisation ind´ ependante r´ eunissant une vingtaine d’industriels
(micro´ electronique, syst` eme, logiciel embarqu´ e, ...). Il est distribu´ e sous une licence

Open Source. Plusieurs types de mod´ elisation et de simulation sont possibles : du ni-
veau transfert de registre ` a registre (RTL) au niveau syst` eme. Une biblioth` eque de
classes et de templates permet de mod´ eliser des composants, des liens pour relier
les composants et des signaux pour v´ ehiculer des informations sur les liens. Les ca-
ract´ eristiques de base de SystemC sont comparables ` a celles que l’on trouve dans les
langages de description de composants mat´ eriels (HDL) comme VHDL ou Verilog.
De plus, depuis la version 2, SystemC propose des objets plus adapt´ es ` a la simulation
de syst` emes : les canaux, les interfaces et les ´ ev´ enements. Ce niveau plus ´ elev´ e de
conception est appel´ e TLM : Transaction Level Modelling. Le fait d’adopter SystemC
comme environnement de travail pr´ esente plusieurs avantages :
– les mod` eles disponibles aupr` es des fondeurs peuvent ˆ etre facilement incorpor´ es;
– toute biblioth` eque Cou C+ + peut ˆ etre utilis´ ee par un mod` ele SystemC ;
– la disponibilit´ e du code source permet d’adapter le moteur de simulation si
n´ ecessaire.
L’architecture distribu´ ee pr´ esent´ ee ci-dessous est constitu´ ee de plusieurs proces-
seurs Infineon C167 connect´ es par un r´ eseau CAN. Ce type d’architecture est couram-
ment employ´ e dans les syst` emes temps r´ eel embarqu´ es pour l’automobile et permet
de mod´ eliser un syst` eme r´ ealiste et raisonnablement complexe. La mod´ elisation de
l’architecture op´ erationnelle compl` ete est trait´ ee en d´ etail dans [7] [6].
2.1 Mod´ elisation du processeur Infineon C167
Le cœur du microcontrˆ oleur C167[14] est compos´ e d’un pipeline ` a 4 ´ etages (avec
un cache de saut), d’une unit´ e arithm´ etique et logique (ALU) 16 bits ainsi que d’un
ensemble de registres sp´ ecifiques (Special Function Registers). Il dispose, de plus,
d’une unit´ e de multiplication / division s´ epar´ ee, d’une unit´ e de masquage de bit et
d’un barrel shifter1. Sa fr´ equence peut atteindre 33 MHz.
Dans le contexte temps r´ eel, il est n´ ecessaire non seulement de simuler le compor-
tement fonctionnel du processeur, mais aussi son comportement temporel, en respec-
tant les d´ elais dˆ us au mat´ eriel. On peut distinguer deux types d’approches int´ eressantes
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 ` a dire que l’ar-
chitecture interne (pipeline, unit´ es de calculs d´ edi´ ees, ...) n’est pas du tout
mod´ elis´ ee. Dans ce contexte, toutes les instructions ont la mˆ eme dur´ ee : 1 cycle;
– la simulation pr´ ecise au cycle pr` es prend en compte un mod` ele pr´ ecis de l’archi-
tecture interne du processeur afin de simuler non seulement le fonctionnement
du processeur, mais aussi fournir des informations temporelles au cycle pr` es. La
complexit´ e qui en d´ ecoule entraˆ ıne des temps de calculs plus importants.
Ces deux sch´ emas de simulation ont chacun leurs int´ erˆ ets et leurs inconv´ enients.
Le premier est rapide et le deuxi` eme pr´ ecis, ce qui est essentiel dans notre cas. Afin
d’utiliser les avantages de ces deux approches, un simulateur modulaire a ´ et´ e conc¸u.
Il permet de commuter d’un sch´ ema vers l’autre au cours de la simulation. Ainsi,
une s´ equence critique du logiciel peut ˆ etre simul´ ee finement avec les informations
1registre `
a d´ ecalage qui peut d´ ecaler plusieurs bits en une seule fois

temporelles et une autre partie moins critique ex´ ecut´ ee plus rapidement en mode de
simulation du jeu d’instructions.
De fac¸on ` a assurer la synchronisation et la communication avec les autres dispo-
sitifs, comme les contrˆ oleurs CAN, le mod` ele de processeur est encapsul´ e dans un
module SystemC. Le module poss` ede une entr´ ee d’horloge, et une transition sur cette
derni` ere provoque l’appel d’une m´ ethode C++ qui simule 1 cycle de fonctionnement
du processeur. Des mod` eles (p´ eriph´ eriques, ´ el´ ements de l’environnement) peuvent fa-
cilement ˆ etre ajout´ es.
2.2 Mod´ elisation du contrˆ oleur CAN
Le protocole CAN (Controller Area Network) de Bosch[4] est un protocole de
communication s´ erie assurant la diffusion fiable de messages sur un bus ` a faible coˆ ut.
C’est un protocole mature (exp´ erimentations depuis 1986) qui d´ efinit une surveillance
tr` es stricte du bus. La gestion du bus est dirig´ ee par les ´ ev´ enements (Event-Triggered ).
Le bus est de type multi-maˆ ıtres asynchrone. Il n’y a pas de m´ emoire commune, pas
de contrˆ oleur de trafic, pas d’horloge globale et une station peut ´ emettre d` es que le
bus est libre.
Une trame est compos´ ee d’un identifiant de message. Cet identifiant sert ` a la fois
`
a caract´ eriser la donn´ ee embarqu´ ee dans le message (vitesse du v´ ehicule, vitesse de
rotation du moteur par exemple) et ` a donner sa priorit´ e. En cas de collision sur le bus,
le message le plus prioritaire n’est pas d´ etruit, le ou les autres messages seront r´ e´ emis
d` es que le bus sera de nouveau libre.
L’absence d’horloge globale conduit ` a synchroniser l’´ emetteur et le r´ ecepteur sur
les transitions entre 0 et 1. Si le message contient plus de 5 bits cons´ ecutifs de valeur
identique, un bit suppl´ ementaire de valeur oppos´ ee est ins´ er´ e. Ce syst` eme, le bit stuf-
fing, peut augmenter le temps de transmission d’un message jusqu’` a 18%. C’est l’une
des raisons qui n´ ecessite une mod´ elisation suffisamment fine du contrˆ oleur CAN pour
simuler correctement le comportement temporel du bus.
La mod´ elisation du contrˆ oleur CAN a ´ et´ e r´ ealis´ ee ` a deux niveaux diff´ erents, la
pr´ ecision requise dans les deux cas est celle du bit, c’est-` a-dire que la transmission /
r´ eception des messages s’effectue au niveau du bit. La premi` ere m´ ethode est bas´ ee sur
une approche par composants de type VHDL en utilisant SystemC, la mod´ elisation
´
etant au niveau RTL. La deuxi` eme approche conduit ` a une mod´ elisation au niveau
transactionnel et, fonctionellement, le mod` ele s’´ eloigne quelque peu du composant
r´ eel en int´ egrant un arbitre dans le bus. Cette derni` ere mod´ elisation utilise l’approche
TLM, c’est celle que nous utilisons car elle est la plus efficace.
2.3 Simulation de l’architecture compl` ete
L’architecture dans son ensemble peut comprendre autant de nœuds que n´ ecessaire,
la seule limite ´ etant la quantit´ e de m´ emoire disponible. Chaque nœud comprend les
modules SystemC pr´ esent´ es pr´ ec´ edemment (processeur et contrˆ oleur CAN) qui sont
synchronis´ es via SystemC. Afin d’obtenir de meilleures performances du simulateur,
ni les acc` es m´ emoire ni les acc` es aux circuits p´ eriph´ eriques (contrˆ oleur CAN, timers,