Le langage SDL pour les systmes temps rel

Jean-Philippe Babau
CITI : Centre dInnovation en Tlcommunication et Intgration de services, INSA Lyon, F69621 Villeurbanne Cedex - FRANCE jpbabau@if.insa-lyon.fr
RESUME. Le langage SDL est un langage formel, normalis, de haut niveau dabstraction ddi la modlisation de systmes vnement discret. Des extensions SDL ont t proposes afin de prendre en compte des aspects de qualit de service. De par sa smantique formelle, SDL et ses extensions sont relis des outils de vrification bass sur des techniques formelles. A partir dun modle SDL, il est possible de gnrer du code tant pour des systmes dexploitation standards que pour des excutifs temps rel. Le code gnr peut tre utilis soit pour la simulation du modle, soit pour la mise en uvre du modle sur une cible ddie. Enfin, lintgration de lapproche objet et la mise en uvre dapproches ddies apportent un environnement mthodologique SDL. Pour toutes ces raisons, le langage SDL est un bon candidat pour le dveloppement formel des systmes temps rel. MOTS-CLES : SDL, temps rel, langage

1. Introduction Du fait de la complexit croissante des systmes temps rel et de leur ncessaire correction, le dveloppement de tels systmes ncessite de suivre les principes de gnie logiciel et demande la mise en uvre de techniques formelles. En consquence, les langages utiliss doivent possder un haut niveau dabstraction ainsi quune smantique formelle. Ils doivent enfin permettre lexpression de contraintes de qualit de service spcifiques au domaine, soit ici des contraintes temps rel. Enfin, les langages doivent sappuyer sur des mthodologies qui assurent une qualit des modles produits, et facilitent l'accs un domaine spcifique. Le langage SDL (Specification and Description Language) est un langage formel et normalis (ITU-T) particulirement utilis dans le domaine des tlcommunications ddi la description des systmes discrets [1]. C'est un langage de haut niveau qui possde une version graphique (cf. figure 1) et une version textuelle. SDL est bas sur les automates tats finis tendus communicants et les types abstraits de donnes. Il inclut les notions de typage et de gnricit. Sa smantique tant dfinie formellement, il est possible de simuler et de valider une application dcrite en SDL. Il est aussi possible de gnrer le code correspondant pour des excutifs temps rel du march. En complment, le langage MSC (Message Sequence Chart ) [2], normalis par lITU-T, assure la description des diagrammes de squence associs SDL. Dun point de vue historique, une premire version informelle de SDL a t propose en 1976. Depuis, une nouvelle version est produite tous les 4 ans. Le premier standard formel est arriv en 1988. Les versions 92 et 96 [3] sont assez proches et sont la base de cette prsentation. Enfin, la version 2000 [4], non encore outille, introduit des concepts Orient Objet (OO) au sein de SDL. Au niveau des outils, ObjectGode de Verilog et Tau de Telelogic ont pour objectif dassurer une continuit dans la couverture du cycle de dveloppement [4] [5]. Ces outils sappuient sur SDL et les MSC. Ils offrent des possibilits ddition, de simulation, de test et de gnration de code. Il est noter que le rachat de Verilog par Telelogic a bloqu les volutions sur loutil ObjectGode. Cette prsentation se propose de faire un tour dhorizon de lutilisation du langage SDL dans le cadre du dveloppement des systmes temps rel. Dans une premire partie, nous donnons rapidement les principes de base du langage. Ensuite, nous prsentons la prise en compte des contraintes de Qualit de Service (QoS), plus particulirement les aspects temps rel, et les liens vers des outils de preuves. Puis nous donnons les principes de gnration de code temps rel partir dun modle SDL. Enfin, nous parlerons daspects mthodologiques avant de conclure.

Ecole dt Temps Rel 2003

Conception de systme Systme

Diagramme de processus Etat Signal en entre

Bloc, sous-bloc Condition Canal Processus Dcision Dclaration de procdure Dclarations de donnes Signal en sortie Tche, procdure

garde

[signal]
Cration de processus

Figure 1 : lments syntaxiques du langage SDL graphique

2. Principes de SDL 2.1. Structuration

En SDL, dans un premier niveau, le systme modlis est compos de blocs lis les uns aux autres et la frontire du systme au moyen de canaux. Les blocs sont composs de sous-bloc et de processus. Un processus, au sens SDL, est une machine tats finis communicante. Les instances de processus sont cres statiquement ou dynamiquement. Chaque instance possde son identifiant ou PID (Processus Identifier ). Pour exemple, le systme Controle prsent la figure 2 modlise un systme de rgulation basique. Il est compos de trois blocs : Capteur, Regulation, Actionneur. Ces blocs sont relis par les canaux can1 et can2. Le canal can3 permet de relier le bloc Actionneur lenvironnement du systme. Enfin, le bloc Regulation est lui-mme compos des processus ICapteur, Element et IActionneur. 2.2. Communication Les processus communiquent via des signaux de manire asynchrone (pas dattente de lmetteur). Les signaux sont vhiculs par les canaux. Quand un signal est mis, il est transmis, via son canal, au bloc de destination. Sur un canal, lordre dmission entre signaux est conserv. Par contre, si deux signaux arrivent en mme temps ils sont traits arbitrairement. Quand un signal arrive sur un processus, il est mis en attente dans une file gre selon le principe FIFO (premier arriv/premier servi). Si le destinataire du signal nest pas explicit via son PID, le signal est consomm par la premire des instances du processus pouvant le consommer. Dans lexemple prsent la figure 2, par exemple, le signal IT est transmis du bloc Capteur vers le bloc Regulation via le canal can1. Il est ensuite consomm par le processus Icapteur. Ce dernier produit son tour le signal Mesure.

System Controle [IT] capteur can1 Regulation

[Commande] can2

[trace] can3

Processus Element Idle Mesure changement Idle Calcul Consigne Idle

actionneur

Bloc regulation [IT] Icapteur Element [Mesure] [Consigne] [Commande]

IActionneur

Figure 2 : exemple de modlisation SDL

Le langage SDL pour les systmes temps rel

Le deuxime mode de communication propos par SDL est un mode synchrone (attente de lmetteur) bas sur lappel distant de procdure. Il est possible de dclarer une procdure dans un processus et de lappeler dans un processus distinct. Lappel considre lappel comme la rception dun signal implicite dclenchant lappel la procdure. 2.3. Comportement Un processus SDL est une machine tats caractrise par une file dattente FIFO, des donnes, des signaux entrants ou sortants et un ensemble dtats relis par des transitions. Un tat particulier du processus est ltat de dpart o se place linstance de processus sa cration. Une transition est caractrise par une condition de tir et un corps. La fin de la transition aboutit un nouvel tat (pouvant tre le mme que ltat prcdent). Une transition est tire soit sur rception dun signal, soit de manire alatoire (transition spontane). Ce dernier aspect est utile pour modliser des systmes non dterministes. Il est possible de lier une condition (base sur un calcul) de validation une transition.. Dans un tat donn, le signal pouvant tre consomm (signal prsent et condition de validation ok) est absorb. Si le signal nest pas attendu dans ltat courant, il est limin sauf sil est explicitement sauvegard (mot cl save). Si le signal est attendu mais que la condition de validation nest pas valide, le signal reste dans la file dattente. Le corps de la transition est caractris par une squence dactions (tche au sens SDL, appel de procdure ou cration dautres instances de processus) et lmission de plusieurs signaux. Les dcisions permettent dexprimer plusieurs chemins possibles dans une mme transition. Dans lexemple de la figure 2, lorsque le processus Element est dans ltat Idle et quil reoit un signal Mesure, si les donnes vhicules par le signal respectent une certaine condition changement, une procdure Calcul est excute afin de produire un nouveau signal Consigne. Sinon le processus neffectue aucune action et revient ltat idle. 2.4. Les donnes La structuration des donnes se fait via des types (prdfinis ou construits) dclars au niveau des blocs ou du systme, selon la syntaxe ADT (Abstract Data Types). Les donnes sont, elles, exclusivement dclares au sein dun processus. Les donnes et les types ne sont pas visibles lextrieur de leur zone de dclaration. Lchange de donnes entre processus, se fait soit par signal soit par partage des donnes. A cet effet, il existe deux mcanismes : limport/export et le revealed/view. Ces mcanismes de partage sont limits aux donnes dclares au niveau des processus (et non par exemple au niveau des procdures). Dans le premier mcanisme, une donne D1 dclare partage (mot cl exported) possde une copie D2 en variable globale. Le processus doit alors explicitement (mot cl export) signifier la mise jour de la copie D2 partir de la donne D1. Un processus lecteur de cette donne partage dclare une donne locale D3 (mot cl imported). Puis il doit explicitement (mot cl import) signifier la mise jour de la donne locale D3 partir de la copie D2. Ce mcanisme de copie est cr pour chaque instance de processus. Pour viter tout conflit, lors de la consultation, le processus lecteur doit indiquer le PID du processus metteur de la donne. Dans le deuxime mcanisme, une donne est dclare visible de lextrieur (mot cl revealed), et tous les processus appartenant au mme bloc peuvent consulter (mot cl viewed) cette donne (la modification est bien sur interdite !). Le mode revealed/view permet davoir laccs en lecture une donne en continu , alors quavec le mode export/import, laccs porte sur une donne pouvant tre ancienne. 2.5. Concurrence , protection et synchronisation des donnes Les instances de processus s'excutent en parallle. Pour une instance, une seule transition est excute la fois : il nexiste pas de concurrence intra- instance de processus (cest lhypothse RTC Run To Completion ). Par contre, si deux transitions (de 2 instances de processus) sont tirables au mme instant, aucune relation d'ordre n'est donne a priori. En SDL, les donnes tant locales aux processus, elles sont inaccessibles de lextrieur. Comme leur modification a lieu dans une transition et que cette dernire ne peut tre interrompue, les donnes sont implicitement protges car manipules en exclusion mutuelle. Enfin, les oprations de partage se font en mode atomique pour assurer la protection des donnes.

Ecole dt Temps Rel 2003

2.6. Signalisation temporelle et priorits La signalisation temporelle se fait par lactivation ou la dsactivation de timers. Un timer est dclar au niveau dun processus. Il peut tre arm (set) et interrompu (reset). Lors de son initialisation, on associe au timer une date relative ou absolue dexpiration ( la primitive NOW de SDL renvoie lheure courante). On peut alors lui associer des donnes. Sil nest pas dsactiv, la date dchance, le processus reoit dans sa file dattente un signal portant le nom du timer. Ce signal vhicule les donnes associes au timer. Enfin, il est possible de rendre un signal plus prioritaire pour un tat donn (mise en cause du principe premier arriv/premier servi). Cet aspect nest pas rellement li un aspect temporel. Mais il peut permettre de rendre un message plus prioritaire, et donc de prendre en compte des contraintes temporelles dune application. Au-del des ces informations, les notions de Qualit de Service sont absentes du modle SDL. 2.7. Conclusion SDL est un langage de haut niveau dabstraction qui possde de nombreux avantages. Il possde une version graphique et permet dassurer la structuration du modle via les blocs/sous-blocs. Son langage daction est formel et indpendant dun langage dimplmentation. Son diagramme dtat possde une smantique prcise (pas dtat concurrent). Cest un langage utilis dans lindustrie que nous avons expriment pour le prototypage de systme embarqus [6][7]. SDL apparat comme adapt la modlisation des systmes temps rel pour les aspects comportementaux et le traitement des donnes. SDL est de plus relativement simple et ais de prise en main. Par contre, SDL offre une smantique limite pour la modlisation du temps. 3. SDL et le temps rel 3.1. Introduction SDL ne possde pas dlment de spcification clair et prcis de lcoulement du temps et ne fournit pas une description complte de la faon dont le modle doit sexcuter dans le temps [8]. Il est, par exemple, impossible dassurer lactivation dune transition dun processus une date exacte via un timer. En effet, lexpiration du timer est considre en SDL comme un signal classique. Par consquent, la date de prise en compte de lvnement temporel par linstance de processus est lie au contexte de lapplication (tat de la boite aux lettres o est dpos le signal) lors de son excution. De plus, limplmentation, chaque action prend un certain temps pour sexcuter. Comme SDL ne spcifie pas comment le temps global se droule, lors de la simulation dun modle SDL, lhypothse est de considrer que laction sexcute en temps ngligeable ou quelconque. Dautre part, le temps que le processus prend avant de tirer sa prochaine transition est indtermin. En conclusion, il n'y a aucun moyen de vrifier (en ltat de la smantique) si le modle respecte bien les contraintes temporelles exprimes. Ceci pose un problme pour le dveloppement et la validation des systmes temps rel. De nombreux travaux ont t mens dans ce domaine selon deux approches. Dans la premire approche (TSDL [9], QSDL [10], [11],[12]), on se propose denrichir SDL soit par addition des nouveaux lments syntaxiques, soit par ajout de commentaires formels. Dans la deuxime approche, on couple SDL un outil capable de combler ses lacunes au niveau de la modlisation du temps (par exemple de SDL vers les automates temporiss IF [13] ou UPPAAL[14]). Nous prsentons maintenant les formalismes TSDL, QSDL, IF et les travaux mens pour intgrer les concepts des automates temporiss en SDL. 3.2. TSDL TSDL (Timed SDL) est une extension de SDL88 pour prendre en compte les aspects temporels. Lobjectif de TSDL est la vrification de proprits temporelles. Il est noter que TSDL, en se concentrant sur les aspects temporels, n'engendre que peu de modifications dans le langage SDL, ce qui lui permet d'tre compatible avec de nombreuses spcifications existantes. Quelques restrictions sont pour autant apportes au langage, essentiellement au niveau de la structure (pas de bloc/sous-bloc, pas de cration dynamique de processus). La modification porte SDL consiste ne pas associer la notion de temps de manire globale un processus via les timers, mais aux transitions des processus. TSDL comprend plusieurs lments syntaxiques qui permettent dexprimer des contraintes probabilistes (TPROB) et des contraintes de temps (TRATE, TTIME) sur les transitions. Ces contraintes peuvent manipuler des variables et donc tre modifies dynamiquement. Il faut aussi noter que TSDL ajoute une extension pratique SDL. La dfinition des donnes est autorise au niveau du systme. Enfin, TSDL apporte des constructions pour interroger ltat de la file dattente des processus (taille de la queue, signaux prsents dans la queue) et ltat des processus.

Le langage SDL pour les systmes temps rel

Une reprsentation TSDL peut tre transforme en un systme de transition tiquet (LTS) quivalent. Cette transformation est assure par un parseur qui est inclus dans loutil TSDL. Ceci permet dune part de vrifier des proprits sur le modle (transition non tire, signal reu non attendu, timer ractiv alors quil na pas expir) et dautre part dvaluer les performances temporelles du systme ( temps sparant deux entres conscutives dans un tat). 3.3. Queueing SDL Queueing SDL(QSDL) est un autre extension de SDL ddie la spcification de systmes distribus. QSDL se base sur des commentaires formels et lusage de types prdfinis. Les commentaires formels apportent des informations sur le modle comme la limitation de la taille des files dattente. Mais le point essentiel de QSDL reste la modlisation des performances. A cet effet, QSDL propose de modliser les ressources ncessaires lexcution des processus SDL via des machines. Une machine offre des services aux processus SDL accessibles via des requtes. Les requtes sont des actions atomiques utilisables dans les processus au mme titre que les primitives de SDL. Une machine est caractrise par une vitesse dexcution et peut se composer de plusieurs serveurs pouvant sexcuter en parallle. Elle sert modliser le temps pris pour lexcution dune requte. Dans le cas de requtes concurrentes, une machine est caractrise par une politique dordonnancement des requtes : - FIFO : politique premier arriv - premier servi - PS (Processus Sharing) : les requtes sont rparties afin de partager quitablement la capacit du serveur - IS (Infinite Servers) : chaque requte peut sexcuter sans attente - RANDOM : les requtes sont prises au hasard dans la file d'attente - FCFSPP : les requtes sont gres par priorit en mode premptif - FCFSPNP : les requtes sont gres par priorit en mode non premptif Enfin QSDL se propose dtendre SDL pour spcifier plus prcisment lcoulement du temps. Trois possibilits sont offertes par QSDL. La premire concerne linvocation dun service dune machine en utilisant la primitive QSDL request qui a pour effet du bloquer ou pas le processus. La deuxime est la mise en place dtats temporiss ( mot cl AWAKE) qui a pour but dactiver une transition spontan aprs un certaine temps. Cet lment assure une prdictibilit temporelle dans le tir des transition afin de pallier les lacunes du timer SDL. Enfin les signaux peuvent tre retards (mot cl DELAY) afin de modliser le temps pris lors de la transmission dun signal via un canal. QSDL propose des gnrateurs alatoires, qui coupls au lments prcits, assurent la modlisation de lcoulement du temps et de la dure des actions. Pour raliser des mesures de performance, il existe des constructions prdfinies par QSDL appeles sensor. Loutil QUEST, bas sur QSDL, analyse le graphe de couverture et permet de raliser des valuations de performances [15]. 3.4. IF 3.4.1. Introduction

IF est un modle intermdiaire base d'automates temporiss communicants, conu pour la description et la validation formelle de systmes asynchrones. Il existe deux versions de IF (IF1.0 et IF.2.0). IF a t choisi pour satisfaire un certain nombre d'exigences, dont les plus importantes sont l'expressivit par rapport aux formalismes de description de haut niveau, une smantique oprationnelle bien dfinie et un maximum de support pour la validation formelle. IF apparat comme une reprsentation intermdiaire entre SDL, ou dautres langages de haut niveau, et les LTS. La syntaxe de IF est proche de celle de SDL et il existe, de plus, un outil de traduction automatique SDL2IF. Enfin, la boite outil CADP [16], conjointement dveloppe par laction VASY de lINRIA Rhone-Alpes / DYADE et le laboratoire Verimag, proposent de nombreux outils pour la vrification formelle. 3.4.2. SDL Vs IF

En IF, un systme est constitu d'un ensemble d'automates temporiss, qui communiquent soit de manire asynchrone par envoi de signaux travers des files d'attente. Comme en SDL, un processus IF est identifi par un nom unique qui est aussi son PID. Un processus possde une file d'attente et est constitu respectivement d'un ensemble de variables locales types, incluant des horloges, d'un ensemble d'tats de contrle et d'un ensemble de transitions entre ces tats. IF2.0 propose des types de processus, ce qui le rapproche dun langage de modlisation de haut niveau. Pour autant, la structuration des processus en bloc et sous blocs (comme en SDL) est absente de IF. IF correspond en fait une reprsentation plat dun modle de type SDL. Nous prsentons maintenant les diffrences fondamentales entre SDL et IF.

Ecole dt Temps Rel 2003

Au niveau des tats, dans IF2.0, les tats peuvent contenir des sous-tats qui permettent de crer un hirarchie dtat comme dans SDL2000. Au niveau de la communication, alors quen SDL, lorsquun processus reoit un signal non attendu ce signal est perdu ; en IF, le processus se bloque. Cette diffrence nest pas fondamentalement gnante. Dabord parce que les outils comme ObjectGode possde le mme comportement que IF. Ensuite, par dfaut, on peut considrer ncessaire dexpliciter le comportement dun processus pour chaque signal reu dans un tat donn. Mme si la transition ne possde aucune action et revient dans le mme tat, cette rgle de modlisation ne peut quaugmenter la qualit du modle produit. Dautre part, en IF 2.0, la transmission des signaux peut tre perturbe via lutilisation de signalroutes . Ces dernires permettent dintroduire diffrentes affectation la livraison des messages grce aux options : - #fifo ou #multiset en fifo la consommation des signaux se fait dans lordre de leur arrive ; en multiset, la consommation se fait de manire alatoire; - #reliable ou #lossy les signaux peuvent, ou non, tre perdus ; - #peer, #multicast ou #unicast suivant le type de livraison des signaux dsir (respectivement destination dune instance dun processus, de tous les processus vivants ou de toutes les instances dun processus) ; - #urgent, #delay[l,u] ou #rate[l,u] suivant que lon veut que la livraison des signaux soit immdiate, avec dlai (entre l et u), quelle soit priodique ou pseudo-priodique (la priode tant borne par l et u). 3.4.3. IF et le temps rel

En IF, lvolution du temps se fait de manire discrte. Pour modliser les contraintes temporelles dun modle IF, les processus utilisent des horloges. Toutes les horloges du systme voluent de manire synchrone par rapport au temps global. Une horloge sert contraindre le domaine temporel de tir de certaines transitions (mot cl when). On ne peut pas accder directement la valeur de lhorloge (la conversion entre le type clock et le type integer est impossible). Par dfaut, le comportement du systme est de tirer une transition alors que ses contraintes temporelles sont valides. Cependant IF permet de dfinir des variations sur la date de tir dune transition selon les paramtres suivants : - Eager : la transition est prioritaire sur le temps. Le temps ne peut s'couler tant que la transition n'a pas t tire. - Lazy : la transition a la mme priorit que le temps, c'est--dire que lon peut laisser le temps scouler ou tirer la transition. - Delayable : le temps est prioritaire sur la transition, c'est--dire que le temps peut s'couler jusqu' ce que la transition doive sexcuter afin de respecter ses contraintes. IF permet de dfinir des comportements temporels plus fins que SDL, en particulier avec lintroduction de la notion dintervalle de temps. Il peut tre alors intressant, dans le cadre dune modlisation dun systme temps rel, de dfinir un comportement standard en SDL puis daffiner le comportement temporel sur le modle IF associ. 3.5. SDL temporis Lapproche dveloppe dans [11] se propose dintgrer des commentaires formels, bass en grande partie sur la smantique IF, dans le modle SDL. On peut ainsi modliser une dure daction par un intervalle (mot cl delay), une dure de transmission sur un canal par un intervalle (mot cl delay), une frquence de tir dune transition (mot cl periodicity), une priorit des transitions par rapport au temps (cf. IF, mots cls eager, lazy, delayable) ainsi que la fiabilit dun canal (mot cl reliable). De plus, lapproche propose des constructions afin de matriser plus finement le comportement temporel des timers. On peut ainsi modliser des timers cycliques (mot cl cyclic). La date dexpiration dun timer peut tre traite comme une variable. Enfin, un timer spcifique nomm Interruptive timer est introduit. Lorsque ce dernier expire, il lance une exception qui peut tre rcupre pour interrompre une action en cours. Les travaux mens dans [12] compltent ces travaux. Ils proposent en particulier la dfinition dun temps local (li au temps global mais avec une drive ou un dcalage). De plus, ils apportent une smantique prcise sur le droulement en temps des actions. Une transition qui ralise une action est modlise selon deux transitions temporises : la transition qui active laction (elle aboutit ltat in step qui signifie que laction est lance) et la transition qui est tire la fin de laction. Afin de modliser des effets de premption ou de suspension de laction, ltat in step est dcoup en deux tats nomms computing et suspended. On alors peut lier deux informations temporelles une action, le temps dexcution (temps pass dans ltat computing) et le temps absolu li lhorloge. Lordonnancement des actions est modlis via des priorits selon les principes noncs dans [17].

Le langage SDL pour les systmes temps rel

3.4. Conclusion Lapproche par modification syntaxique de SDL implique des adaptations smantiques sur le modle SDL modifi. Des analyses de performance sont possibles mais le modle nest plus conforme au modle SDL originel. Dans la deuxime approche (traduction de SDL vers un autre langage), on assure la coexistence de SDL avec son extension. L'avantage dune telle approche est la totale indpendance qui existe entre la spcification tendue et la spcification SDL. La spcification des aspects non fonctionnels peut tre entirement dtache de SDL pour la vrification de proprit spcifiques. Enfin la lise en place de commentaires formels permet de conserver le modle original tout en fournissant des informations temps rel pouvant conduire la traduction vers un formalisme adquat. Une fois dfinis la smantique de SDL et de ses extensions temporelles, nous parlons maintenant des possibilits de validation dun modle SDL. 4. Validation et tests Les outils commerciaux tels que ObjectGode et Tau offrent des possibilits de test et de validation dun modle SDL [18]. Dun autre cot, comme il a t dit, SDL peut tre traduit dans un format intermdiaire IF qui offre laccs des outils de vrification bass sur des techniques formelles. Dans ce chapitre, nous prsentons rapidement les possibilits des outils commerciaux, ainsi que quelques outils associs IF 4.1. Outils commerciaux Les outils commerciaux sappuient sur la simulation du modle selon trois modes : interactif, alatoire et exhaustif. Dans le mode interactif, lutilisateur joue le rle de lenvironnement et fait voluer le modle (tir des transitions) en pas pas. Il peut alors suivre lvolution du modle (trace) et gnrer pour chaque simulation un diagramme MSC. Ce mode de simulation peut savrer fastidieux dans le cas dun systme o les interactions sont nombreuses. Les outils proposent donc un mode de simulation alatoire ou le simulateur joue le rle de lenvironnement et fait voluer le modle de manire alatoire. La simulation exhaustive du modle parcourt tous les tats du systme (lexhaustivit ne concerne pas les donnes). Pour viter lexplosion combinatoire, on peut contraindre le nombre dtats et de transitions parcourus ainsi que le niveau de profondeur du graphe obtenu. Dans ce cas, la simulation nest bien sur pas exhaustive mais partielle, les rsultats sont donns avec un certain pourcentage de couverture du modle. Dans chaque mode de simulation, il est possible de dfinir des conditions darrt qui sont des expressions boolennes. Ces conditions portent sur les tats des processus, ltat des files dattente des processus, les donnes, les timers. Une condition darrt exprime alors une proprit du systme vrifier. Lorsque la proprit est viole, la simulation sarrte. Lors de la simulation, afin de produire des rsultats intressants, il est ncessaire de modliser lenvironnement extrieur. Ceci doit tre fait pour viter un comportement alatoire non raliste de lenvironnement lors des simulations. La modlisation doit porter sur deux nivaux : la loi darrive des signaux en provenance de lenvironnement et les valeurs des donnes produites par lenvironnement. SDL est adapt la modlisation des procds discrets. Lorsquon doit modliser un procd continu, la solution prconise est dutiliser un autre formalisme plus adapt et de lier le simulateur lmulateur de lenvironnement [19] Pour ce qui est des donnes, il est difficile de modliser lensemble des valeurs possibles. En gnral, on modlise quelques donnes et particulirement les donnes limites. 4.2. IF et les techniques formelles Lintrt de IF est de produire un LTS. Nous prsentons rapidement les possibilits offertes sur ce LTS en terme de rduction et de vrification au travers de deux outils CADP (Aldebaran et Evaluator). 4.2.1. Optimisation des LTS en IF Lutilisation de nombreuses donnes et de nombreuses horloges fait que les LTS cres sont rapidement de trs grande taille. Par exemple, la condition temporelle (mon_horloge < n) en mode Lazy peut produire jusqu (n)chemins. De mme, lutilisation de compteurs qui ne reviennent jamais 0 crent un nombre dtat infini puisque deux tats sont diffrents partir du moment o une seule de leur variable ne possde pas la mme valeur. Pour limiter ce phnomne, IF offre deux mthodes intgres de rduction du nombre dtat : - live : les auteurs de IF ont dfini une quivalence entre les LTS plus forte que la bisimulation forte appele live bisimulation. Cette technique de rduction de lespace des tats est base sur la conservation des variables vivantes (live) et llimination des variables inutiles. Les variables inutiles sont celles dont la valeur nest pas utilises [20].

Ecole dt Temps Rel 2003 - partial order : cest lapplication de la technique de la rduction dordre partiel pour rduire le nombre dtat et de transitions [21]. 4.2.2. Aldebaran

Le rle principal dAldebran est dobtenir partir dun LTS, un nouvel LTS rduit et dune certaine manire quivalent. Les relations quAldebaran peut dterminer sont : strong bisimulation, observational equivalence, delay bisimulation, branching bisimulation, et safety equivalence. Il nest pas dans lobjet de ce document de toutes les dcrire). Ces types de relation permettent de vrifier des proprits sur un systme complexe en utilisant un systme plus simple mais quivalent. La rduction des LTS peut se faire grce aux options rename et hide. La premire permet de renommer certains labels de transitions, en donnant le mme nom plusieurs labels. Ainsi, on obtient un LTS en quelque sorte projet, donc rduit. La commande hide permet une rduction similaire, que lon peut dcrire comme le renommage de certains labels par laction invisible. Ces modifications, si elle sont bien utilises, permettent de garder uniquement un sous-LTS de loriginal mais qui correspond au premier (en terme de comportement) vis vis dune certaine proprit vrifier (observational equivalence). Enfin, il est possible de rduire un automate en un automate quivalent (strong bisimulation), et de comparer deux automates pour savoir si ils possdent le mme comportement (strong bisimulation). 4.2.3. Evaluator

Evaluator permet dvaluer des proprits de logique temporelle sur un LTS. Nous donnons ici deux exemples de proprits, une de vivacit et une de sret. Pour la proprit de vivacit, on souhaite vrifier que si un processus sender envoie un message MSG, alors le processus receiver en recevra un. On procde dabord un renommage (cf. Aldebaran) de toute transition qui envoie, respectivement reoit, un message MSG en sdMSG, respectivement rcMSG. On doit ensuite vrifier que tous les chemins partir de lvnement sdMSG comporte lvnement rcMSG, soit en logique temporelle, la proprit ((sdMSG)*. sdMSG.*. rcMSG). Avec Evaluator, en utilisant les expressions rgulires(true* exprime nimporte quelle transition), on exprime la proprit ainsi : [ (not "sdMSG")* . "sdMSG" .true*. "rcMSG"] true Pour la proprit de sret, on souhaite vrifier que le systme nest jamais dans un tat donn. Dans un premier temps, on doit renommer chaque transition qui abouti cet tat interdit en error. On doit ensuite vrifier si un chemin aboutit cet tat. En logique temporelle, la proprit scrit ( "error") ; avec Evaluator, elle scrit < true* . "error" > true et signifie quil existe au moins un chemin qui mne laction error. Les exemples donnes concernent des actions mais on peut aussi travailler sur les tats. Il est noter que la boite outil CADP contient dautres outils comme par exemple loutil TGV [22] qui permet de gnrer formellement des squences de tests partir dun LTS. 4.3. Conclusion Les simulations en mode interactif et alatoire sont adapts la mise au point du modle et la production de tests. Seul le mode exhaustif peut permettre de produire des preuves (parcours de tout les tats) mais avec deux restrictions importantes : la proprit vrifier ne doit porter que sur le comportement (car le domaine des donnes nest pas parcouru dans son ensemble) et lexplosion combinatoire doit tre vite (sinon le graphe nest pas compltement explor). Tandis que les outils ddition tels que ObjectGode sont orient spcification et simulation des aspects fonctionnels, IF est conu pour tirer profit au maximum des outils de vrification. CADP soccupent de la partie validation proprement dite avec la gnration du graphe de couverture. Lintrt de IF est que tous les lments implicites dans SDL sont exprims de manire explicite dans IF permettant ainsi une analyse statique plus efficace. Dans le cadre du dveloppement de systmes temps rel, une fois un modle SDL construit et valid, il est peut tre intressant de passer une phase dimplmentation. 5. Implmentation 5.1. Principes

Le langage SDL pour les systmes temps rel

Afin de produire un code temps rel partir dun modle SDL, il est ncessaire de fournir lors de la gnration de code des informations supplmentaires au modle originel. Larchitecture tant la base de limplmentation du modle, ces informations portent sur larchitecture matrielle (machines, partitionnement logiciel/matriel, modles de communication) et logicielle (placement des processus, systme dexploitation, modle de tches, politiques dordonnancement). Les travaux mens dans ce domaine se proposent soit de dfinir implicitement un modle dexcution via un gnrateur de code, soit dajouter des informations supplmentaires au modle. Dans cette partie nous prsentons les principes de gnration de code des outils commerciaux tel que ObjectGode. Puis, nous prsentons loutil SDL-RT qui prsente une extension de SDL pour la gnration de code temps rel. Ensuite nous parlerons plus prcisment de la dfinition dun modle dexcution pour une analyse de type RMA [23]. Enfin nous prsentons deux tudes qui se focalisent sur des aspects de QoS lors de la phase dimplmentation. 5.2. ObjectGode Le principe du gnrateur de code dObjectGode est de sappuyer sur une machine virtuelle compose de macros qui implmentent les concepts et les primitives de SDL en sappuyant sur lexcutif sous-jacent. Le gnrateur de code sappuie aussi bien sur les systmes dexploitation standards que les excutifs temps rel du march. 5.2.1. Architecture logicielle gnrale

En marge de la description de lapplication en SDL, le concepteur dcrit larchitecture matrielle par le biais de nuds dexcution. La communication entre les nuds se fait par socket. Chaque processus SDL est ensuite plac sur un nud pour sexcuter (phase de placement statique). Sur un nud donn, une application est mono processus au sens des systme dexploitation. Une fois les processus SDL placs, il existe plusieurs modes de gnration des tches (au sens systme dexploitation) : lutilisateur choisit soit dassocier une tche un bloc, soit une tche un processus, soit enfin une tche une instance de processus. A lexcution, une tche se place en attente dun message, puis droule une structure algorithmique de type switch-case afin de simuler le comportement du processus. Dans le cas o une tche est associe plusieurs instances, la rception dun message, la tche met jour les pointeurs sur les donnes correspondant linstance concerne par le message puis excute lautomate correspondant. 5.2.2. Communication et protection

La communication entre instances de processus situes sur un mme nud ainsi quavec lenvironnement externe se fait par bote aux lettres classique FIFO fournies par le systme dexploitation. Pour la communication entre instances de processus distants, lenvoi se fait par le biais dune primitive denvoi de message distance. Chaque nud possde une tche en attente (priorit forte) qui, la rception dun message, lanalyse, rcupre lidentifiant de la boite au lettre destinatrice et le dpose dans la boite au lettre correspondante. Selon les systmes dexploitation viss, lutilisation des botes aux lettres classiques ne permet pas toujours dimplmenter les concepts de sauvegarde explicite de signal non consomm et de signal plus prioritaire. Pour implmenter ces concepts, le gnrateur de code cre des structures supplmentaires ddis. Lexcution dune transition se fait en section critique. Il nexiste donc pas de protection lie aux donnes. Pour chaque donne partage, une variable globale de la machine virtuelle est cre et manipule directement de faon atomique. Enfin, lors de lexcution des macros dObjectGode, des smaphores sont mis en place pour raliser ces oprations en section critique, ceci afin dassurer la cohrence de la machine virtuelle. 5.2.3. Spcifications temporelles Ordonnancement

Lutilisation dun ou de plusieurs timers gnre une tche (priorit forte) ddies lmulation des timers. Cette tche gre une liste ordonne de dates absolues de rveil. Ces dates correspondent aux dates dexpiration des timers. A ces dates, sont associs les instances de processus aviser lors de lexpiration des timers. Limplmentation ne propose pas de politique dordonnancement temps rel. Les niveaux de priorit des tches peuvent tre fixs par le concepteur lors de la gnration de code. 5.2. SDL-RT SDL-RT (Specification and Description Language - Real Time [24]) est une extension temps rel du langage SDL. SDL-RT introduit les concepts manquants dans SDL pour le dveloppement dapplications temps rel tout en conservant les avantages du langages original. SDL-RT est gratuit. Au niveau de la distribution du code, SDL-RT introduit la notion de diagramme de dploiement avec les nuds et les connections (lien physique) ainsi que la notion de composant.

Ecole dt Temps Rel 2003

Au niveau du modle dexcution, un niveau de priorit est associ chaque processus qui peut tre redfini pour chaque instance. Linstance de processus est donc une tche au niveau du systme dexploitation. Pour la gestion du temps, lunit de base des timers est le tick. Enfin, afin de produire une implmentation efficace, la langage daction propos par SDL-RT est le langage C. Il est donc possible, en particulier de manipuler des pointeurs et de dclarer des variables globales. Ces dernires doivent tre protges par lutilisation explicite de smaphores fournis par SDL-RT. Un outil (Real Time Developer Studio) a t dvelopp et permet de gnrer le code complet de lapplication partir de la description SDL-RT en intgrant les appels aux primitives des systmes dexploitation classiques et des excutifs temps rel. Nous prsentons maintenant les rsultats issus des travaux de recherche pour la phase dimplmentation dun modle SDL. 5.3. SDL et le RMA Dans lapproche propose par [25], la description de larchitecture du systme sappuie sur divers types de processus : les processus matriel , les processus logiciel et les processus pilote qui assure linterface entre le logiciel et le matriel. On distingue ensuite les processus actifs des processus passifs, ces derniers modlisant les ressources partages. Les processus passifs sont des processus composs uniquement dun ensemble de services accessibles par appel de procdure distant. Les processus matriel sont, par exemple, des processus passifs, alors que les pilotes sont des processus actifs. Lapproche se concentre ensuite sur la gestion des priorits qui est un point cl dune implmentation temps rel. Lobjectif affich de ltude est la mise en place dune analyse temporelle de type RMA partir du modle SDL. Les contraintes temporelles sont lies aux vnement externes. Lorsquun vnement externe survient, un ensemble dactions est dclench selon des contraintes temporelles donnes. Dans un modle SDL, les actions sont lies aux transitions des processus et dclenches par larrive de signaux. Par analogie aux messages dans les modles objet temps rel dfinis par [26] [27], les signaux vhiculent donc les contraintes temps rel. Selon les principes de RMA, pour prendre en compte les contraintes temps rel telles que les dlais, les priorits des actions doivent tre calcules selon les algorithmes dordonnancement temps rel [28]. Lapproche propose alors dassocier un niveau de priorit fixe chaque transition. Ainsi, on sassure que chaque action est excute au niveau de priorit requis par les algorithmes dordonnancement temps rel. Il faut aussi veiller rduire ou supprimer le phnomne dinversion de priorit. Nous donnons ici une illustration de ce phnomne induit par lutilisation de langages tels que SDL. Soit deux processus PA et PB excutant des procdures Pr1, Pr2, Pr3 et Pr4 sur larrive de signaux S1, S2, S3 et S4. On suppose que du fait des contraintes temporelles lies S1,S2,S3 et S4, les niveaux de priorits de Pr1, Pr2, Pr3 et Pr4 sont de 10, 20, 30 et 40 (un plus petit niveau implique une plus forte priorit). Enfin, on suppose que PA reoit dans lordre les signaux S4,S2 et S1, puis que PB reoit le signal S3 et que les processus excutent chaque procdure son niveau de priorit. Le rsultat de lexcution du modle est alors le suivant : S4 S2 S1 S3

Pr4

Pr3

Pr4

Pr2

Pr1

Au dpart, le processus PA reoit les signaux S4. PA excute donc la procdure lie au premier signal reu, soit Pr4. Puis, PA reoit ensuite S2 puis S1 qui doivent activer Pr2 et Pr1. Mais ces derniers doivent attendre la fin dexcution de Pr4 (hypothse RTC). Lorsque le signal S3 survient, le processus PB peut excuter Pr3 (il possde alors la priorit de Pr3 suprieure celle de Pr4). Lorsquil a finit, Pr4 reprend, se termine, puis le processus PA excute en squence la liste des procdures Pr2 et Pr1 selon lordre darrive des signaux. Dans cette squence, on constate plusieurs phnomnes dinversion de priorit : - Pr3 sexcute avant Pr2 et Pr1, alors quil est moins prioritaire et indpendant de Pr2 et de Pr1 - Pr2 sexcute avant Pr1, alors quil est moins prioritaire SDL propose un niveau de priorit sur les signaux qui pourrait permettre de limiter les phnomnes dinversion de priorit. Par exemple, si on donne un niveau de priorit durgence S1, on supprime un effet dinversion de priorit (Pr1 sexcute avant Pr2). Mais la granularit des niveaux de priorit nest pas assez fine pour implmenter les algorithmes dordonnancement temps rel. En fait, pour rduire le phnomne dinversion de priorit, la gestion des queues lies au processus doit se faire selon un principe de priorits des signaux avec hritage de priorit [29] [30] (la priorit de la tche est la

Le langage SDL pour les systmes temps rel

priorit maximale entre celle du signal trait et celle des signaux en attente). Ainsi, on sassure que lorsquun signal prioritaire est en attente, seul le signal en cours de traitement sur le mme processus peut bloquer ce signal. Enfin dans lapproche propose, une pire dure dexcution est associe chaque transition. Au final, les paramtres ncessaires (dures, priorit, politique de gestion des ressources partages) sont extraits du modle SDL ainsi tendu. Lapproche donne des lments pour valuer les temps dattente par vnement afin destimer le pire temps de rponse un vnement externe. La gestion des niveaux de priorit des transitions (initialisation et changement de niveau) est possible avec les outils commerciaux par ajout de primitives adquates dans le code gnr. Par contre, la gestion des queues de signaux est plus complexe. En effet, les outils et les excutifs temps rel ne proposent pas de queues gres par niveau de priorit. Il est donc ncessaire de modifier les gnrateurs de code afin dimplmenter des politiques temps rel de gestion de files dattente[31]. 5.4. Gestion de la taille mmoire Le problme de lefficacit du code produit partir dun modle SDL ne dpend pas que du facteur temporel. Dans lapproche propose par [32], afin de gagner en taille mmoire, les notion de donnes rfrences (seules les rfrences sont transmises entre processus et non les donnes) et la mise en place de trame de donnes (regroupement de donnes dans la cadre de la modlisation de protocoles) sont introduites pour viter les copies multiples des donnes. Afin de limiter le nombre de tches, lapproche prconise la mise en place dun modle dexcution orient vnement nomm BAT (Basic Activity Thread) : un mme tche excute la squence daction active par un vnement externe. Plus prcisment, cette squence correspond, par processus travers, au changement dtat du processus, la rception du signal et lexcution de la transition. Puis de manire itrative, cette opration est reproduite pour chaque signal envoy un processus donn. Lorsquune transition rencontre est sans envoi de signal, la tche se termine. Lapproche met laccent sur le respect du principe fondamental datomicit dune transition dans le code gnr. Soit, par exemple, dans une transition dun processus P1, la squence suivante : envoie dun signal S1 puis excution dune action A1. On suppose que le signal S1, reu par un processus P2, active laction A2. Lorsque S1 est envoy, mme si A2 pourrait tre excut, la transition de P1 ntant pas termine, A2 ne doit pas sexcuter avant A1. Pour que le modle BAT fonctionne, les transitions spontanes doivent tre interdites et au plus un signal ne peut tre mis par transition. Pour accepter lmission de plusieurs signaux, le modle BAT doit tre tendu au modle EAT (Extended Activity Thread) o lon cre autant de tches que de signaux mis. 5.5. SDL * Enfin, le langage SDL* [33] dfinit 5 types de commentaires formels concernant des contraintes de QoS sur le modle. Des niveaux de priorits sont associes ces contraintes (par exemple, le mot cl strong rend la contrainte obligatoire). La premire contrainte exprime dans SDL* permet de sparer dans le modle les parties implmenter des parties qui sont seulement mise en place pour les seuls besoins de simulation du modle. La deuxime contrainte porte sur le placement des blocs et des processus sur une machine donne (cpu, asic, etc). La troisime contrainte porte sur les caractristiques des ressources utilises : la mmoire, le nombre de machines utilises par les processus ou les blocs, le dbit des rseaux pour les canaux. Les contraintes temporelles permettent dexprimer des contraintes de dlai pour les processus et de gigue sur les signaux. Enfin, les contraintes de cot portent le cot du matriel ou sa part dans le cot total du systme. 5.6. Conclusion SDL ne permet pas, par sa dfinition, de spcifier les contraintes de Qualit de Service telles, par exemple, les contraintes temps rel. Lors de limplmentation, la politique dordonnancement des actions ne peut donc pas tre gnre de manire optimale. De faon gnrale, les contraintes de QoS ne peuvent conduire limplmentation dun modle SDL. Comme pour les aspects temps rel, les travaux prsents proposent des extensions au langage SDL (extensions syntaxiques ou commentaires formels) ou sa spcialisation (par exemple un processus est un composant matriel ou logiciel) pour dcrire les contraintes et conduire limplmentation. Un travail important reste faire pour la gnration de code temps rel efficace. Les travaux prsents donnent des pistes pour lextension ou la spcialisation du langage SDL pour intgrer ces aspects de QoS et dimplmentation ainsi que la mise au point de gnrateurs de code ddis.

Ecole dt Temps Rel 2003

6. Mthodologie Tout langage ncessite une mthodologie dutilisation afin daccrotre la qualit du logiciel produit. De plus une mthodologie ddie permet un langage gnraliste de sadapter un domaine spcifique. Dans ce chapitre, nous prsentons trs brivement SDL+ qui est une mthodologie lie SDL. Puis nous parlerons des aspects OO lis SDL qui permette daccrotre la qualit des modles. Enfin nous terminerons par la prsentation dune approche ddie au dveloppement de systmes temps rel. 6.1. SDL+ LITU-T propose une mthodologie SDL+ associe au langage SDL. Cette mthodologie sappuie sur un ensemble dactivits qui sont les activits classiques danalyse des besoins, de conception, de mise en uvre, de documentation, de test et de validation. Une activit supplmentaire essentielle est la formalisation qui dcrit les tapes raliser pour spcifier un systme en SDL. On retrouve dans SDL+ des rgles de gnie logiciel (prfrer un appel distant de procdure une consultation directe de donne), des rgles de qualit ( pas plus de 5 blocs pour un systme , un seul canal entre deux blocs, etc.) et des rgles de compltude (un signal reu par un processus doit tre consomm dans au moins une transition). Cette mthodologie reste informelle mais reste utile pour une bonne utilisation du langage. 6.2. SDL et lobjet SDL nest pas proprement parl un langage OO. Par exemple, les notions dencapsulation des donnes, de services ne font pas partie du langage. Pour autant, il existe de plus en plus de liens entre SDL et UML [34] (le standard de fait des langages OO). De par sa formalisation, SDL peut apparatre comme un langage qui fournit une smantique une modlisation UML (approche prconise par Proseus [35]). Le but de PROSEUS est de fournir un guide mthodologique utilisable par un concepteur de systmes embarqus temps rel souhaitant utiliser UML pour la description et la spcification du systme et SDL pour la ralisation d'un prototype de son application. Le modle SDL peut tre ensuite utilis pour la gnration de code et la validation de l'application. SDL est alors un langage intermdiaire entre UML, les modles formels et limplmentation. Une autre approche propose est dinclure les principes de SDL dans UML via des strotypes [36]. Mais lintrt de faire du SDL en UML reste encore dmontrer. Enfin, la dernire solution est dinclure des principes de lOO dans SDL par des notions telles que les types hrits ou par lajout de notion OO comme la relation dassociation. Dans SDL2000, les associations sont destines fournir des annotations structures pour indiquer des proprits supplmentaires sur les lments auxquels sont lies les associations. Un systme SDL qui contient une association a la mme signification et le mme comportement si l'association est supprime. En SDL, ce sont donc les types qui permettent au mieux lintroduction de concepts OO dans SDL. Nous prsentons maintenant les principes de traduction dun modle objet vers SDL puis les notions de type en SDL. 6.3. De UML vers SDL Les premiers travaux mens dans le cadre du projet Europen ESPRIT INSYDE[37] permettent de dfinir les rgles de transformation dun sous ensemble formalis dOMT not OMT* vers SDL. Les limitations sur OMT sont les suivantes : - il nexiste pas dhritage multiples - les associations sont uniquement binaires - pas de contraintes exprimes dans le modle - pas de rgles de discrimination Une fois ces limitations vrifies, il est possible de passer une phase de traduction. 6.3.1. Les classes

Dans INSYDE, une classe devient un bloc. Un sous-classe (relation dagrgation) devient un sous-bloc et ainsi de suite. Plus gnralement, une classe avec comportement produit un processus SDL afin de modliser le diagramme dtat associ la classe. Une classe sans comportement devient un ADT. Au niveau des services, un message devient un signal et une opration devient une procdure. Enfin, les attributs de chaque classe sont exprimes via des dclarations de donnes au niveau des processus.

Le langage SDL pour les systmes temps rel 6.3.2. Les relations

Lorsqu'une classe A possde une relation avec une classe B dont l'arit est n, on doit dclarer dans le processus A n PID. Ces PID correspondent aux n processus B lis A. Ils sont initialiss lors de la cration des instances de processus B (lien statique) ou lors de chaque modification de la relation. Dans certains cas le PID n'est pas ncessaire car il est implicite au modle (une instance relie une seul instance). Enfin, les relations d'hritage peuvent tre soit interprtes et directement implmentes dans le modle SDL, soit tre remplaces par la notion de type en SDL (cf. ci aprs). 6.3.3. Les communications

La communication asynchrone par message se traduit videmment par une communication par signal en SDL. Lappel synchrone dopration se traduit, lui, par un appel distant de procdure. 6.3.4. Lautomate

La description du comportement est raliser en SDL partir du diagramme dtat exprim laide des statecharts UML. Il existe en UML une classe spcifique de statechart qui sont les protocol statecharts . Ils expriment le protocole de communication de lobjet avec son environnement (lien message/opration). La traduction du protocol statechart en SDL revient faire une remise plat de lautomate. En effet, il nexiste pas dtat hirarchique (sauf en SDL2000) et dtats concurrents en SDL. A partir de cette description du comportement, par raffinement, le concepteur passe une tape de traduction de lalgorithme des oprations. Lutilisation dun tat dans la description d'une procdure cre un tat intermdiaire implicite pour lobjet. Afin de respecter l'hypothse RTC pour lobjet, dans cet tat intermdiaire, les signaux arrivants ne doivent tre ni traits, ni perdus (mot cl save). Il existe de nombreux autres diagrammes en UML comme les diagrammes de squence qui sont exprims via les MSC pour SDL. Par contre, les diagrammes de dploiement, de composant, dinstance, de collaboration et dactivit nont pas dquivalent en SDL. 6.4. SDL et les types Les types permettent en SDL de mettre en uvre la notion dhritage simple. Lhritage multiple, par ailleurs souvent dconseill dans lanalyse OO, ne peut pas tre reprsent en SDL. Il existe des types de donnes, de processus, de service, de bloc et de systme. On distingue les types paramtrs des types non paramtrs . Les premiers sont paramtrs par des paramtres formels, une fois ces paramtres fixs, on obtient des types non paramtrs. Linstanciation des types non paramtrs aboutit des lments SDL standard (processus, bloc, systme). Un paramtre formel de contexte peut tre un processus, une procdure, un signal, une variable, un timer ou un type de donne. Lors de la dfinition des paramtres formels, une vrification de la signature est effectue. Afin de produire de nouveaux types partir de types existants, la spcialisation de type est possible (mot cl inherits). On peut soit ajouter des proprits au nouveau type, soit modifier des proprits existantes, soit ajouter de nouveaux paramtres formels. Il est noter que pour pouvoir modifier le comportement du type hrit (par exemple une transition ou une procdure), il est ncessaire de le prvoir dans le modle pre (mot cl virtual). En rsum, on peut avoir les spcialisations suivantes (TP : type paramtr, TNP : type non paramtr) : - TP -> TP : dfinition de certains paramtres formels - TP ->TNP : dfinition de tous les paramtres formels - TP,TNP -> TP,TNP : ajout de proprits, modifications des lments virtual - TNP -> TP ajout de paramtres formels - TNP -> lment SDL : instanciation Ces aspects du langage sont trs intressants dans le cadre du dveloppement. On peut ainsi spcialiser le langage pour un domaine cible particulier. La mise en place darchitectures types prdfinies, values et qualifies assure la qualit de la spcification produite partir de ces modles gnriques. Les types SDL peuvent permettre la dfinition de composants conceptuel pour la spcification de systmes. 6.5. Dveloppement de systmes temps rel Lapproche propose dans [38][39] se propose de donner un cadre formel au dveloppement de systmes temps rel partir de modles SDL. On suppose, que lanalyse des besoins fonctionnels a t ralise soit en

Ecole dt Temps Rel 2003

UML puis traduit en SDL, soit exprims directement en SDL. Au final la spcification est exprime en SDL. Lapproche se concentre alors sur la phase de conception/implmentation du systme. Lapproche dfinit trois niveaux, dont deux exprims en SDL. Dans un premier niveau dit de spcification, sont dcrites les fonctionnalits du systmes ainsi que les contraintes temps rel. Dans un deuxime niveau, on dcrit le modle dexcution (suppos sappuyer sur une machine monoprocesseur). Enfin le troisime niveau correspond limplmentation base sur un excutif temps rel. Pour chaque niveau modlis en SDL, il existe un modle smantique exprim en IF. Le modle SDL sappuie sur des schmas de programme types (signaux, processus) et est orient conception. Le modle IF permet de prciser la smantique du modle conceptuel. Il sert de base la vrification du systme. Au niveau du modle de spcification, la solution propose sappuie sur un typage des signaux changs entre le systme et son environnement (procd contrler, machines, autres applications). Les paramtres des signaux contiennent ces caractristiques temporelles (date darrive, date de validit, chance). Le mode de propagation des contraintes au sein du systme suit les principes noncs dans [27]. Lenvironnement est modlis via des processus type modlis en IF (loi darrive des signaux externes). Enfin, on peut dtailler lexpression de politique temps rel spcifiques (filtrage temporel, raction une faute temporelle). Une fois les contraintes exprimes, ltude se focalise sur la phase de dfinition de larchitecture de lapplication. Cest ce niveau que lon dcrit comment lapplication doit sexcuter. Cette phase est fondamentale dans les systmes embarqus temps rel, car les choix effectus au niveau de larchitecture influent directement sur les performances. Au niveau du modle dexcution, lapproche propose une boite outils base sur des processus type qui introduit les notions de routines (dinterruption ou dalarme), de tches (priodique, apriodique ou serveur) et des rgles dinterconnexion de ces divers lments. La formalisation du modle dexcution permet de vrifier la correction du modle dexcution par rapport sa spcification. On utilise les techniques de bisimulation (outil Aldebaran) pour assurer la correction du raffinement entre les deux niveaux. Enfin, limplmentation est obtenue directement par un gnrateur de code had oc. Ce gnrateur peut produire un code pour la simulation ou pour lexcution. Dans le premier cas, nous privilgions une cible classique, dans le deuxime un excutif temps rel. 7. Conclusion SDL est un langage standardis qui possde de nombreux supports. Ses extensions temporelles ont permis denrichir le langage pour prendre en compte les contraintes temporelles et assurer des mesures de performances. Il est aussi possible de gnrer un code pour de nombreux supports dexcution et enfin dutiliser SDL dans le cadre dun dveloppement formel et de qualit. Le lien avec les approches synchrones, trs utilis dans le mode des systmes critiques, reste un point explorer pour intgrer SDL dans le dveloppement de tels systmes : comment passer de lasynchrone au synchrone ? , comment associer asynchrone et synchrone ? . Il en est de mme pour le lien de SDL avec les systmes continus. Au niveau des langages asynchrones haut niveau dabstraction, larrive dUML2.0 [40] devrait signifier, terme, le dclin de SDL. Les modifications dUML2.0 rapprochent en fait UML et SDL : UML2.0 intgre les MSC comme formalisme pour les diagrammes de squence, le langage daction na pas de syntaxe mais possde dsormais une smantique (les ADT peuvent donc tre un langage daction pour UML2.0). Enfin les diteurs doutils et les industriels sorientent dsormais vers UML. SDL2000 nest pas, ce jour outill, et UML est, de fait, le standard des langages OO. Pour autant, les conclusions des travaux prsents restent pertinents. Dans le cadre de lutilisation de langage asynchrone haut niveau dabstraction, on doit travailler prciser la smantique temporelle des modles et plus gnralement la smantique de la QoS. On doit aussi travailler la mise en place de gnrateur de code ddis efficaces. Enfin on doit assurer des ponts vers des outils de validation formels. Le dveloppement formel passe afin par la mise ne place de mthodologies ddies pour aboutir la mise ne place darchitecture types, valides, et rutilisables. 8. Bibliographie
[1] [2] [3] [4] [4] [5]

Zoubir Mammeri SDL, Modlisation de protocoles et systmes ractifs Herms Science Europe, 2000
ITU-T Recommendation Z.120, Diagrammes des squences de messages (MSC) , 1999. ITU-T Recommendation Z.100, Specification and Design Language (SDL) , 1996. ITU-T Recommendation Z.100, Specification and Design Language (SDL2000) , 1999. ObjectGeode, method guidelines Telelogic. April 2000 http://www.telelogic.com Telelogic Tau SDL suite Telelogic http://www.telelogic.com

Le langage SDL pour les systmes temps rel

[6] [7] [8] [9] [10]

[11] [12] [13] [14] [15] [16]

[17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

[28]
[29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40]

Jean-Philippe Babau Object-Oriented Real-Time Modeling Contest by Daimler&Chrysler 2001, confidential works. Jean-Charles Tournier Prototypage laide du langage SDL dun systme de robotique mobile, rapport de projet de fin dtude, CITI / ESISAR-Valence, 2002. M.Bozga, S.Graf, A. Kerbrat, L. Mounier, I. Ober, D. Vincent SDL for Real Time : What is Missing ? Proceedings of SAM'00, Grenoble, 2000. F. Bause, Peter Buchholz Protocol Analysis Using a Timed Version of SDL FORTE , Madrid, 1990. M. Diefenbruch, Queuing SDL - A Language for the Functional and Quantitative Specification of Distributed Systems University Gesamthochschule Essen, Fachbereich Mathematik und Informatik, 1997, (QUAFOS-Project Report Q1). M. Bozga, S. Graf, L. Mounier, I. Ober, J-L. Roux, D. Vincen Timed Extensions for SDL Proceedings of SDLForum'01, Copenhagen (Denmark), 2001. S. Graf Expression of time and duration constraints in SDL , 3rd SAM Workshop on SDL and MSC, University of Wales Aberystwyth (Wales), 2002 M. Bozga, J.Cl. Fernandez, L. Ghirvu, S. Graf, J.P. Krimm, L. Mounier IF: An Intermediate Representation and Validation Environment for Timed Asynchronous Systems FM'99, Toulouse, 1999. A. Hessel Timing analysis of an SDL subset in Uppaal Master thesis, Department of Information Technology, Uppsala University, 2002. QUEST: http://www.cs.uni-essen.de/Fachgebiete/SysMod/Forschung/QUEST/, 1997 J.-C. Fernandez, H. Garavel, A. Kerbrat, L. Mounier, R. Mateescu, M. Sighireanu CADP A Protocol Validation and Verification Toolbox 8th International Conference on Computer Aided Verification CAV, New Brunswick (USA),1996. K. Altisen, G. Goessler, J. Sifakis Scheduler Modeling Based on the Controller Synthesis Paradigm Real-Time Systems Journal, Vol 23(1/2), pp 55-84, Kluwer, 2002. Laurent Doldi Validation of Communications Systems with SDL: The Art of SDL Simulation and Reachability Analysis , Europe Publishers, Ed. Wiley P.Bjurus, A. Jantsch, Heterogenous System-level Cosimulation with SDL and Matlab , FDL99, Lyon, 1999. M. Bozga, J.Cl. Fernandez, L. Ghirvu State Space Reduction based on Live Variable Analysis SAS'99, Venise, 1999. J.P. Krimm, L. Mounier Compositional State Space Generation with Partial Order Reductions for Asynchronous Communicating Systems TACAS'00, Berlin, 2000. J.-C. Fernandez, C. Jard, T. Jron, L. Nedelka, C. Viho An Experiment in Automatic Generation of Test Suites for Protocols with Verification Technology journal scp, vol 29(1-2), pp 123-146, 1997. M. Klein & all A practionners Handbook for Real-Time Analysis , Kluwer Academic Publishers, 1993. SDL-RT Specification and, http://www.sdl-rt.org/ J. M. Alvarez, M. Diaz, L. Llopis , E. Pimentel and J. M. Troya An Object-oriented Methodology for Embedded Real-time Systems , Computer Journal, Vol 46 (2), pp. 123-145, 2003. F. Terrier, G. Fouquier, D. Bras,L. Rioux, P. Vanuxeem,A. Lagnusse A Real-Time Object Model , TOOLS EUROPE '96, pp.127-141, 1996. J.-P. Babau, J. L. Sourrouille Expressing Real Time Constraints in a Reflective Object Model , Control Engineering Practice , Vol 6, pp 421-430, 1998. C.L. Liu, J.W. Layland Scheduling algorithms for multiprogramming in a hard real time environment ,

Journal of the Ass. for Computing Machinary, Vol 20, pp 46-61, 1973.

M.I. Chen, K.J. Lin Dynamic Priority Ceilings: a Concurrency Control Protocol for Real Time Systems , Real Time Systems, Vol 4 (2), pp 325-346, 1990. L. Sha, R. Rajkumar, J. Lehockzy Priority Inheritance Protocols: an Approach to Real Time Synchronisation IEEE Transaction Computers, Vol 39(9), pp 1175-1185, 1990. M. Saksena, A. Ptak, P. Freedman, and P. Rodziewicz Schedulability Analysis for Automated Implementations of Real-Time Object-Oriented Models IEEE Real-Time Systems Symposium, Madrid, 1998. donnes en SDL S. Spitz, F. Slomka, M. Drfel SDL* An Annotated Specification Language for Engineering Multimedia Communication Systems 6th Open Workshop on High Speed Net- works, Stuttgart, 1997. Unified Modeling Language Specification v.1.4,Object Management Group,February 2001. J.-P. Babau, A. Alkhodre A development method for PROtotyping embedded SystEms by using UML and SDL (PROSEUS) workshop SIVOEES 2001 ECOOP, Budapest, 2001. ITU-T Recommendation Z.100, SDL Combined with UML (SDL/UML) , 1999. V. Jonckers, K. Verschaeve, B. Wydaeghe, L. Cuypers Translating OMT* to SDL, Coupling Object-Oriented Analysis and Design with Formal Description Techniques Method Engineering'96, Atlanta, Georgia, 1996. A Alkhodre, J.Ph Babau, J.J Schwarz Modelling of real-time constraints using SDL for embedded systems design IEE Computing & Control engineering Journal, Vol 13(4), pp 189-196, 2002 J.Ph Babau, A Alkhodre, J.J Schwarz Modeling of Real-Time Embedded Systems using SDL, System on Chip Design Languages, pp 257/265 Kluwer Academic Publishers 2002 Unified Modeling Language Specification v.2.0,Object Management Group,June 2003.