N dordre 04ISAL0052.. Anne 2004

Thse

Dveloppement formel de systmes temps rel l'aide de SDL et IF

(Compilation pour systme temps rel)

prsente devant LInstitut National des Sciences Appliques de Lyon

pour obtenir

le grade de docteur

Ecole doctorale :EDIIS (Informatique et Information pour la Socit) Spcialit : ISCE (Informatique et Systmes Coopratifs pour lEntreprise)

par Ahmad Badreddin ALKHODRE

Soutenue le 20 septembre 2004

Jury MM.

M.SIFAKIS Joseph, Professeur CNRS-Verimag Grenoble (Prsident). M.MAMMERI Zoubir, Professeur IRIT-Toulouse (Rapporteur). M.TERRIER Franois Professeur CEA Paris (Rapporteur). M.BONIOL Frdric Matre de confrence l'ONERA-CERT-Toulouse (Examinateur). M.SCHWARZ Jean-Jacques, Professuer UCBL (Directeur de thse). M.BABAU Jean-Philippe, Matre de confrence l'INSA de Lyon (co-encadrant).

Cette thse a t prpare au Laboratoire de CITI Centre dInnovations en Tlcommunications et Intgration de Services de LINSA de Lyon.

ii

Introduction gnrale ........................................................................................................................................... 1

Objectif de la thse............................................................................................................................................. 3 Structure du mmoire ......................................................................................................................................... 4

Partie I ................................................................................................................................................................... 5

Contexte de travail. ............................................................................................................................................... 5

1 Notions de systme ractif et de contraintes temps rel ........................................................................... 6 1.1 Les systmes ractifs....................................................................................................................... 6 1.2 Les systmes temps rel .................................................................................................................. 6 1.3 Les contraintes temps rel ............................................................................................................... 6 1.4 Conclusion ...................................................................................................................................... 8

2 Mthodologies ........................................................................................................................................ 10 2.1 Principes gnraux des mthodologies.......................................................................................... 10

2.1.1 Le modle en cascade............................................................................................................... 10 2.1.2 Le modle "cycle de vie en V" ................................................................................................. 11 2.1.3 Discussion ................................................................................................................................ 12

2.2 Les techniques formelles............................................................................................................... 12 2.3 Dveloppement de systmes temps rel ........................................................................................ 13 2.4 Conclusion .................................................................................................................................... 15

3 Langages de dveloppement des systmes temps rel............................................................................. 16 3.1 Langage de spcification............................................................................................................... 16

3.1.1 SA-RT ....................................................................................................................................... 16 3.1.1.1 Introduction..................................................................................................................... 16 3.1.1.2 Caractristiques du langage ............................................................................................ 16 3.1.1.3 Conclusion ...................................................................................................................... 17

3.1.2 UML ......................................................................................................................................... 17 3.1.2.1 Introduction..................................................................................................................... 17 3.1.2.2 Principes d'UML............................................................................................................. 18 3.1.2.3 Caractristiques du langage ............................................................................................ 18 3.1.2.4 Conclusion ...................................................................................................................... 20

3.1.3 SDL........................................................................................................................................... 21 3.1.3.1 Introduction SDL ......................................................................................................... 21 3.1.3.2 Principes de SDL ............................................................................................................ 21 3.1.3.3 Caractristiques du langage. ........................................................................................... 24 3.1.3.4 Discussion....................................................................................................................... 31

3.2 Langage de conception.................................................................................................................. 32 3.2.1 LACATRE................................................................................................................................ 32 3.2.2 SDL-RT .................................................................................................................................... 33 3.2.3 Autre langage de conception .................................................................................................... 34 3.2.4 Discussion ................................................................................................................................ 34

3.3 Conclusion gnrale de la partie langages..................................................................................... 35 4 Validation et vrification ........................................................................................................................ 36

4.1 Vrification comportementale....................................................................................................... 36 4.1.1 Relation d'quivalence.............................................................................................................. 36

4.1.1.1 Systme de transitions tiquetes (LTS) : ....................................................................... 36 4.1.1.2 Bisimulation forte ........................................................................................................... 37 4.1.1.3 Bisimulation faible.......................................................................................................... 37 4.1.1.4 F-simulation .................................................................................................................... 38

4.1.2 Model-checking........................................................................................................................ 39 4.1.2.1 Le principe du Model-checking ...................................................................................... 39

4.2 Vrification temps rel .................................................................................................................. 40 4.2.1 Les automates temporiss......................................................................................................... 40 4.2.2 La logique temps rel ............................................................................................................... 40 4.2.3 Techniques ddies la validation des systme temps rel...................................................... 42

i

4.2.3.1 Principes.......................................................................................................................... 42 4.2.3.2 Vrification des implmentations multitches ................................................................ 44

4.2.4 Discussion ................................................................................................................................ 45 4.3 Conclusion .................................................................................................................................... 46

Partie II ................................................................................................................................................................ 48

5 Description de la mthodologie .............................................................................................................. 49 5.1 Les tapes de la mthodologie....................................................................................................... 49

5.1.1 Modle de contraintes............................................................................................................... 50 5.1.2 Modle dexcution .................................................................................................................. 50 5.1.3 Implmentation......................................................................................................................... 50 5.1.4 Choix des langages................................................................................................................... 50

5.2 Validation...................................................................................................................................... 51 6 Le modle de contraintes ........................................................................................................................ 52

6.1 Modle d'interaction...................................................................................................................... 52 6.2 Modle temporel de lenvironnement ........................................................................................... 54

6.2.1 Introduction .............................................................................................................................. 54 6.2.2 Activation priodique ............................................................................................................... 54

6.2.2.1 Introduction..................................................................................................................... 54 6.2.2.2 Spcification en SDL ...................................................................................................... 55 6.2.2.3 La smantique en IF :...................................................................................................... 56

6.2.3 Activation sur interruption ....................................................................................................... 57 6.2.3.1 Source dinterruption rgulire ....................................................................................... 57 6.2.3.2 Source d'interruption en rafale ........................................................................................ 58

6.2.4 Le modle temporel des donnes.............................................................................................. 61 6.2.4.1 Spcification en SDL ...................................................................................................... 61 6.2.4.2 La smantique en IF........................................................................................................ 62

6.2.5 Activation par message............................................................................................................. 63 6.2.5.1 La spcification en SDL.................................................................................................. 63 6.2.5.2 La smantique en IF........................................................................................................ 64

6.3 Le modle temporel des actions .................................................................................................... 65 6.3.1 Spcification SDL du modle temporel d'action. ..................................................................... 65 6.3.2 La smantique du modle temporel d'action. ........................................................................... 68

6.4 L'chance et l'ge de donne ....................................................................................................... 69 6.4.1 Introduction .............................................................................................................................. 69 6.4.2 L'ge dune donne................................................................................................................... 70 6.4.3 Echance................................................................................................................................... 70 6.4.4 Politique temps rel : ................................................................................................................ 71

6.4.4.1 Filtrage : Vrification de dure de sparation ................................................................. 71 6.4.4.2 Vrification dchance .................................................................................................. 73 6.4.4.3 Vrification de lge de donnes..................................................................................... 74

6.5 Utilisation des modles ................................................................................................................. 74 6.6 Conclusion .................................................................................................................................... 75

7 Le modle dexcution ............................................................................................................................ 76 7.1 Introduction................................................................................................................................... 76 7.2 Elments applicatifs ...................................................................................................................... 78

7.2.1 Les routines .............................................................................................................................. 78 7.2.1.1 La routine dinterruption................................................................................................. 78 7.2.1.2 La routine dalarme......................................................................................................... 80

7.2.2 Les tches ................................................................................................................................. 81 7.2.2.1 Les tches priodiques .................................................................................................... 82 7.2.2.2 Les tches sporadiques.................................................................................................... 83 7.2.2.3 Les serveurs scrutation................................................................................................. 84 7.2.2.4 Les tches logicielles ...................................................................................................... 86

7.2.3 Les donnes .............................................................................................................................. 90 7.3 Modle d'excution pour l'environnement .................................................................................... 90

7.3.1 Source d'interruption et alarme priodique............................................................................... 90 7.4 Contrleur programmable des interruptions.................................................................................. 91

ii

7.4.1 La modlisation du PIC en SDL ............................................................................................... 91 7.4.2 La smantique du PIC en IF ..................................................................................................... 92

7.5 Politique temps rel....................................................................................................................... 92 7.5.1 Utilisation du chien de garde.................................................................................................... 93

7.5.1.1 La modlisation en SDL ................................................................................................. 93 7.5.1.2 La smantique en IF 2.0.................................................................................................. 94

7.5.2 Utilisation de la fonction check ................................................................................................ 95 7.5.2.1 La modlisation en SDL ................................................................................................. 95 7.5.2.2 La smantique en IF 2.0.................................................................................................. 96

7.6 Politique dordonnancement ......................................................................................................... 97 7.7 Elments spcificques ................................................................................................................... 98

7.7.1 La base de temps ...................................................................................................................... 99 7.8 Mode d'utilisation.......................................................................................................................... 99 7.9 Conclusion .................................................................................................................................. 100

8 Gnration de code............................................................................................................................... 101 8.1 Introduction................................................................................................................................. 101 8.2 Principe ....................................................................................................................................... 102 8.3 La communication entre objets ................................................................................................... 103 8.4 Les annotations formelles : La politique dordonnancement et la priorit .................................. 104 8.5 Code pour des OS classiques embarqus (Windows) ................................................................. 105

8.5.1 Windows et temps rel ........................................................................................................... 105 8.5.2 Du modle dexcution Win32......................................................................................... 105

8.5.2.1 La communication entre les objets................................................................................ 105 8.5.2.2 La routine dinterruption............................................................................................... 106 8.5.2.3 Alarme .......................................................................................................................... 106 8.5.2.4 La routine dalarme....................................................................................................... 106 8.5.2.5 La tche priodique....................................................................................................... 107 8.5.2.6 Le serveur scrutation .................................................................................................. 107 8.5.2.7 La tche logicielle ......................................................................................................... 108 8.5.2.8 Le main ..................................................................................................................... 108 8.5.2.9 La gestion de priorits................................................................................................... 108

8.6 Code pour des excutif temps rel .............................................................................................. 109 8.6.1 VxWorks et le temps rel ..................................................................................................... 109 8.6.2 Du modle dexcution vers VxWorks ................................................................................. 110

8.6.2.1 La communication entre les objets................................................................................ 110 8.6.2.2 La routine d'interruption ............................................................................................... 110 8.6.2.3 Lalarme........................................................................................................................ 110 8.6.2.4 La routine dalarme....................................................................................................... 111 8.6.2.5 La tche priodique....................................................................................................... 111 8.6.2.6 Le serveur scrutation .................................................................................................. 111 8.6.2.7 La tche logicielle ......................................................................................................... 112 8.6.2.8 Le main ..................................................................................................................... 112 8.6.2.9 La gestion de priorits................................................................................................... 113

8.6.3 Restrictions sur l'action Afaire................................................................................................ 113 8.6.4 Contrle temps rel................................................................................................................. 113

8.7 La compilation du modle dexcution vers Win32 ou VxWorks ........................................ 116 8.7.1 Lanalyseur lexical et lanalyseur syntaxique......................................................................... 116 8.7.2 Lanalyse smantique ............................................................................................................. 118 8.7.3 La gnration du code C/ Win32 ou C / VxWorks........................................................... 119

8.8 Conclusion .................................................................................................................................. 120 9 Validation ............................................................................................................................................. 122

9.1 Introduction................................................................................................................................. 122 9.2 Validation formelle ..................................................................................................................... 123

9.2.1 Technique de validation ......................................................................................................... 123 9.2.2 Dfinition de problme........................................................................................................... 124 9.2.3 Formalisation du problme de compatibilit .......................................................................... 125

9.2.3.1 Modle de contraintes ................................................................................................... 125 9.2.3.2 Modle d'excution ....................................................................................................... 126 9.2.3.3 Algorithme .................................................................................................................... 128

iii

9.3 Mthodologie de la validation formelle ...................................................................................... 129 9.3.1.1 Redfinir une base de temps unitaire ............................................................................ 129 9.3.1.2 La deuxime tape : le renommage............................................................................... 130 9.3.1.3 La troisime tape : abstraction et rduction des modles : .......................................... 130 9.3.1.4 La quatrime tape : comparaison................................................................................. 131

9.3.2 Exemple d'application ............................................................................................................ 131 9.3.2.1 Exemple d'activations sporadiques ............................................................................... 131 9.3.2.2 Exemple d'activations priodiques................................................................................ 135 9.3.2.3 Observation d'chance................................................................................................. 138

9.3.3 Conclusion.............................................................................................................................. 140 9.4 Vrification des proprits temps rel......................................................................................... 142

9.4.1 Modle RMA.......................................................................................................................... 142 9.4.2 Extraction des paramtres temporels pour RMA.................................................................... 142 9.4.3 Les proprits vrifier.......................................................................................................... 143

9.4.3.1 Vrification d'une chance simple............................................................................... 143 9.4.3.2 Vrification d'une chance de bout en bout................................................................. 145 9.4.3.3 Vrification la validit d'une donne ............................................................................ 146

9.5 Conclusion .................................................................................................................................. 147

Conclusion gnrale. ......................................................................................................................................... 149

Perspectives.................................................................................................................................................... 151

Rfrences.......................................................................................................................................................... 152

Bibliographie lie l'tude ............................................................................................................................... 168

Annexes .............................................................................................................................................................. 169

Annexe 1 ......................................................................................................................................................... 170

iv

Introduction gnrale

1

Un systme temps rel est un systme qui interagit avec un environnement physique en remplissant souvent des missions critiques pour lesquelles une faute du systme peut avoir des consquences graves. Il sera dit correct s'il possde les bonnes fonctionnalits et si celles-ci sont ralises temps, c'est--dire avec le respect des contraintes temporelles imposes par lenvironnement ou par une certaine qualit de service offerte un utilisateur. La validation fonctionnelle et temporelle des systmes temps rel est ainsi une ncessit forte. Toutes les situations, tous les comportements du systme doivent tre envisags pour que la validation fournisse des rsultats fiables.

Si l'on sait maintenant comment faire pour dvelopper des systmes temps rel (aller de la spcification vers la ralisation) il est indispensable, vu les consquences possibles d'une faute temporelle, de porter un intrt particulier la sret de fonctionnement, aux mthodes permettant de valider le dveloppement avec pour objectif de garantir l'avance le bon fonctionnement du point de vue temporel.

Afin de garantir le bon fonctionnement du systme, il faut utiliser lors du dveloppement de ce systme, des techniques de modlisation et outils formels (possdant des reprsentations mathmatiques que l'on peut associer un programme) qui permettent d'effectuer des preuves de modles.

Le dveloppement d'un systme temps rel passe par l'utilisation de langages et d'outils adapts aux besoins des diffrentes tapes de dveloppement (la spcification, la conception, l'implmentation et la vrification) et les contraintes temps rel se doivent d'tre exprimes et prise en compte chacune de ces tapes. Le modle associ l'tape de spcification est le modle de contraintes. On y dcrit le comportement du systme et les contraintes temporelles du systme (ce que le systme doit faire). Le modle associ la conception est appel le modle d'excution : on y dcrit l'architecture d'excution de l'application (comment le systme doit s'excuter). Ce modle est une abstraction de l'implmentation, qui cache tous les dtails de l'implmentation, comme par exemple les moyens de communication. Diffrentes solutions dpendantes des technologies d'implmentation sont, bien sr, possibles et chacune dentre elles aura recours un outillage appropri. Dans le cadre de ce travail nous n'tudions que l'implmentation base sur lutilisation dun systme multitches monoprocesseur. Ce type dimplmentation qui s'appuie donc sur les services d'un excutif temps rel est largement utilis par les industriels cause de la relative facilit dutilisation, mais na pas bnficier de beaucoup de dveloppement doutils pour la valididation.

Les travaux de recherches lis au dveloppement de systme temps rel se divisent en plusieurs axes.

Dans un premier axe, les travaux mens se concentrent sur une tape particulire du dveloppement telle que la spcification, la conception ou l'implmentation. En ce que concerne la spcification, les travaux mens s'appuient en gnral sur l'utilisation dun langage de haut niveau. Ainsi, titre dexemple, vu la facilit de son utilisation, SA-RT (Structure Analysis - Real Time) [79] a t utilis pour la spcification de systmes temps rel, mme sil nest quun langage informel. D'autres approches adoptent des langages de modlisations orients objet comme UML (Unified Modelling Language) [136]. Ce dernier est un langage semi-formel qui ne possde pas une smantique prcise. Enfin, des approches utilisent des langages formels comme SDL (Specification and Description Language) [85]

2

[125]. Il reste toutefois que SDL ne possde pas de mcanismes lui permettant d'exprimer prcisment les contraintes temps rel. Afin de pallier cette lacune, plusieurs travaux ont t dvelopps pour enrichir SDL sur ce point, soit par l'adjonction une autre langage temps rel [30], soit par l'ajout de nouvelles syntaxes [7] [145].Lors de la conception, toutes les approches telles que LACATRE [160], UML-RT [124] ou SDL-RT [175] proposent des botes outils qui s'appuient sur des botes grises instancier lors de la conception. Les langages UML-RT et SDL-RT permettent d'intgrer les aspects temps rel mais ils ne proposent pas un cadre formel de conception. L'approche de LACATRE [160] [158] propose un cadre formel pour le dveloppement, mais pas pour la prise en compte des contraintes temps rel. Finalement, peu de travaux sont dvelopps autour de la problmatique concernant la transformation entre le modle associ la spcification et le modle associ la conception tels que proposs dans [72] [106]. En ce qui concerne la correction de cette transformation, elle peut tre garantie en utilisant les techniques d'abstraction et de vrification. Les approches dveloppes dans [60] [61] [121] [150] ne s'appliquent que dans le cas o le modle d'excution est une adaptation du modle de contraintes.

Dans le deuxime axe, les travaux se concentrent sur la mise en place d'une architecture d'excution. On essaie alors d'optimiser le dplacement des actions dans les tches [72] [106]. A titre d'exemple l'approche CODARTS propose des rgles et des principes aidant mapper une spcification dun systme temps rel sur une conception base sur le langage Ada [72].

Les travaux dans du troisime axe se focalisent sur le dveloppement de techniques de validation du systme temps rel telles que proposes par [91] [75] [37][185]. Ces techniques permettent de valider des proprits par rapport un modle donn, par exemple l'approche de model-checking [104] [119], soit de valider la conformit de modles en sappuyant sur la notion d'quivalence [60] [121].

Toutes ces tudes apportent des principes, des solutions ou des modles intressants pour le dveloppement de systmes temps rel. Cependant ces approches se concentrent spcifiquement sur une tape particulire du dveloppement indpendamment des autres. Donc, aujourd'hui, il existe peu d'approches compltes et formelles qui regroupent tous les aspects ncessaires pour le dveloppement d'un systme temps rel en passant de la spcification la ralisation (implmentation).

Objectif de la thse

Dans le cadre des implmentations base dexcutifs multitche temps rel, le travail prsent dans cette thse tente dapporter une approche complte formelle de la suite spcification, conception et implmentation. Dans ce cadre, il porte aussi un intrt particulier une mthode de validation de la transformation entre le modle de contraintes et le modle d'excution

Dans un premier temps, nous dcrivons plus particulirement la formalisation des phases aboutissant la dfinition du modle de contraintes et du modle dexcution de lapplication. Dans ce but, nous utilisons le langage SDL [67] [85] [122] prsentant suffisamment de caractristiques formelles. SDL, langage normalis par lITU-T, est trs utilis dans la communaut des tlcommunications, mais son cadre dapplication actuel dpasse largement ce domaine : il est employ avec succs dans des domaines comme les systmes embarqus

3

ou le multimdia [64]. Le monde industriel lapprcie car il est soutenu par un environnement de dveloppement intgr (objectGEODE [135], Tau [200]). Par contre, SDL ne possde pas dlments de spcification clairs et prcis de lcoulement du temps et il ne fournit pas une description complte de la faon dont le modle doit sexcuter dans le temps [29].

Ensuite, le but de cette tude est de prendre en considration la dimension temporelle dans nos modles SDL. Cest le langage IF [28] qui sera exploit pour fixer une smantique temporelle utile la validation.

Afin de prouver la correction de la transformation entre le modle de contraintes et le modle d'excution, nous proposons une relation de compatibilit comportementale entre ces deux modles. Cette relation de compatibilit sera exploite par une mthodologie en quatre tapes pour vrifier la correction de la transformation entre le modle de contraintes et le modle d'excution.

Finalement, afin de valider l'implmentation multitche propose, nous prsentons une approche de validation qui s'appuie sur l'analyse d'ordonnanabilit RMA [98]. Cette approche permet de vrifier, d'une part, la cohrence temporelle de modle d'excution et d'autre part les proprits temps rel exprimes dans les modles (de contraintes et d'excution) telles que l'chance et la dure de la validit d'une donne.

Structure du mmoire

Dans cette optique, ce document est constitu de deux parties. La premire partie prsente le contexte de notre travail : les systmes temps rel et leur contraintes en faisant tat de leurs spcificits et exigences. Nous dcrivons divers lments pris en compte lors de leur dveloppement (chapitre 1), en particulier les mthodologies de dveloppement (chapitre 2), les langages utiliss (chapitre 3) et les techniques de validation (chapitre 4).

Dans la deuxime partie nous prsentons la structuration de notre contribution, puis chaque tape (spcification, conception et implmentation) sera dtaille. Nous prsentons la description de la mthodologie suivre dans le chapitre 5. Les modles de contraintes et d'excution exprims en SDL avec la smantique en IF font lobjet des chapitres 5 et 6. Le chapitre 8 est consacr aux principes de gnration de code et, au final, le chapitre 9 traite le problme de la validation et de la vrification. Nous y abordons le problme de la conformit du modle d'excution par rapport au modle de contraintes et nous montrons comment il est possible de vrifier les contraintes temps rel par une analyse de type RMA partir des modles proposs.

4

Partie I

Contexte de travail.

Lobjectif de cette partie du mmoire est de prsenter le domaine vis par notre contribution que sont les systmes temps rel. En particulier, on s'intresse aux divers lments mis en place lors du dveloppement de tels systmes que sont les mthodologies, les langages et les techniques de validation et de vrification.

5

1 Notions de systme ractif et de contraintes temps rel

1.1 Les systmes ractifs

Les systmes informatiques sont traditionnellement classs suivant trois catgories [78] :

Les systmes transformationnels transforment des donnes pour produire un ou plusieurs rsultats. Les programmes de calcul scientifique sont des exemples de systmes transformationnels. Les rsultats produits dpendent uniquement des donnes traites.

Les systmes interactifs interagissent avec leur environnement. Leur excution est contrle par une boucle dattente des vnements auxquels sont associs des traitements. Pour ces systmes, lenvironnement est gnralement limit un utilisateur humain. Les programmes de bureautique sont des exemples de systmes interactifs. Les rsultats produits dpendent des donnes et des vnements.

Les systmes ractifs ragissent aux stimuli mis par leur environnement. A la diffrence des systmes interactifs, lenvironnement volue de manire indpendante et nattend pas la fin du traitement associ un stimulus mis. Les systmes de contrle - commande sont des exemples de systmes ractifs. Les rsultats dpendent des donnes, des vnements et de leur enchanement en lien avec l'tat de l'environnement.

Dans ce travail, nous nous intressons aux systmes ractifs et plus prcisment aux systmes ractifs temps rel.

1.2 Les systmes temps rel

Les systmes temps rels sont une classe de systmes informatiques ractifs dont le but est de suivre et piloter les volutions dun procd dynamique avec des contraintes de temps physique [57]. Le temps de raction du systme aux stimuli du procd doit tre assujetti la dynamique du procd. La correction dun systme temps rel ne svalue donc pas uniquement du point de vue fonctionnel (justesse des rsultats calculs) et temporel (enchanement correct des vnement) mais galement du point de vue temps rel (dates darrive des vnements) : "Un rsultat juste mais hors dlai est un rsultat faux" [177].

Ces systmes sont aujourdhui prsents dans des domaines tels que lautomobile, lavionique, le spatial mais aussi le contrle de chanes de production, de processus chimique, etc.

Le caractre critique souvent attach aux systmes temps rel rsulte principalement du souci de prserver le procd (par exemple un engin spatial), son environnement (par exemple une centrale nuclaire) et les personnes (par exemple un engin de transport). En consquence, il est ncessaire dappliquer des techniques de validation tout au long du processus de dveloppement de tels systmes [168]. La validation doit aussi bien porter sur les contraintes fonctionnelles que sur les contraintes temporelles et sur les contraintes temps rel.

1.3 Les contraintes temps rel

Dans le cycle de vie dun systme temps rel, les contraintes temps rel apparaissent ds la phase dexpression des besoins. Ainsi, lorsque sont spcifies les fonctionnalits du

6

systme lies au contrle du procd, les contraintes temps rel ncessaires la garantie de ce contrle doivent tre donnes. En fait, les systmes ractif temps rel, sont vus comme un ensemble d'actions qui oprent sur des donnes en prenant en compte l'coulement du temps et des vnements qui apparaissent au niveau du systme ractif ou de son environnement [125]. De ce fait, les contraintes temps rel doivent tre exprimes sur ces trois lments principaux.

Contraintes temps rel associes aux actions Une action peut correspondre tout traitement ayant une fonctionnalit bien prcise au

niveau d'un systme. Selon [88] une action peut tre :

Une action primitive : cest une opration consommant une quantit borne de ressource du systme.

Une action composite : cest une squence dactions primitives.

Les contraintes temporelles portant sur les actions sont :

La date de rveil : c'est l'instant o l'action peut dmarrer.

L'instant dexcution : il reprsente l'instant o une action commence s'excuter.

La dure d'excution : il reprsente le temps coul pendant l'excution d'une action.

La date de fin dexcution : il reprsente l'instant o l'action se termine.

Contraintes temps rel associes aux vnements Un vnement est un marqueur temporel, c'est--dire une occurrence qui marque un point

temporel ayant son importance dans la description du comportement du systme. Les vnements sont classs en plusieurs types :

Un vnement priodique est un vnement ponctuel, mais revenant priodiquement, par exemple tous les 5 millisecondes. Il est donc caractris par sa priode.

Un vnement sporadique est un vnement alatoire, mais il existe une dure minimale et une autre maximale entre deux occurrences de deux vnements successifs.

Un vnement apriodique est un vnement alatoire dont on ne possde pas d'informations temporelles quant sa date d'occurrence.

Les contraintes temporelles exprimes sur les vnements sont :

Une dure sparative minimale et maximale entre l'occurrence de deux vnements successifs : Dans le cas des vnements priodiques un seule dure (priode) caractrise l'occurrence des vnements. Par contre, deux dures caractrisent l'occurrence des vnements sporadiques.

Une chance de bout en bout (End-to-End Deadline) reprsente un intervalle de temps maximum entre un vnement en entre et un vnement en sortie du systme. Elles sont typiquement associes une action (celle dclenche par l'vnement entre) et se rpercutent alors sur les diffrentes entits qui participent la ralisation de cette action.

7

Une chance relative qui porte sur la terminaison dune action, soit entre les deux vnements date de rveil et date de fin d'excution. Ces contraintes apparaissent par exemple avec lclatement de contraintes de bout en bout correspondant au dcoupage du logiciel.

Contraintes temps rel associes aux donnes Une donne reprsente toute information utilise par une ou plusieurs actions pour

s'excuter. Les donnes appartiennent aux deux types suivants :

Les donnes actives : ce sont des donnes dont la mise jour provoque une raction du systme et qui se matrialise par le dclenchement dactions (mises jour dautres donnes, dclenchement dune alarme,...). La mise jour des donnes suit soit une loi priodique (par exemple, la mise jour priodique de la vitesse dun avion dclenche la mise jour de laltitude [186] ), soit une loi sporadique.

Les donnes temporelles sont des donnes dates qui permettent de grer lhistorique de leur volution [168]. Ces donnes sont soient lues sur le procd, soit mises vers le procd.

Pour prendre des dcisions correctes en tenant compte de ltat rel de lenvironnement, les donnes manipules par une application temps rel doivent tre cohrentes du point de vue temporel.

Les contraintes temporelles exprimes sur ces deux types de donnes sont :

La contrainte de cadence : elle caractrise un intervalle de temps entre deux mises jour. De telles contraintes sont caractristiques des systmes chantillonns.

L'ge d'une donne est lintervalle maximum entre la date de production par le procd et la date de consommation par toute action du systme.

La latence est le dlai requis par le systme de contrle pour prendre en compte une donne (cest dire la date maximum entre la date de production de la donne par le procd et la date de consommation par toute action du systme).

Selon quil faille absolument respecter une contrainte ou quil soit possible de la violer occasionnellement, il est usuel de classer les contraintes dans deux catgories [125]. Les contraintes temps rel dures sont celles quil faut tout prix respecter. Les contraintes temps rel souples sont celles quil faut respecter autant que possible, mais qui supportent occasionnellement dtre violes.

1.4 Conclusion

Les systmes temps rel, sont vus comme un ensemble d'actions qui oprent sur des donnes en prenant en compte l'coulement du temps et les vnements qui apparaissent au niveau du systme ractif ou de son environnement. Ces vnements sont soit des vnements priodiques, soit des vnements sporadiques. Ils sont caractriss d'une part par leurs frquences d'arrives et des dures dmin et dmax, et d'autre part, par la contrainte de dlai entre un vnement en entre et un vnement en sortie. Les donnes sont caractrises par une frquence de mise jour et possdent une dure de validit.

8

Nous prsentons maintenant les travaux mens autour du dveloppement des systmes temps rel. Nous parlons d'abord des mthodologies de dveloppement.

9

2 Mthodologies Nous prsentons dans ce chapitre les principales mthodologies, les techniques formelles

et enfin, les travaux principaux mens dans le dveloppement du systme temps rel.

2.1 Principes gnraux des mthodologies

Le modle du cycle de vie dune application est un modle des tapes ou des activits qui commencent quand le logiciel est conu et se termine quand le produit nest plus disponible pour lutilisation [126]. Le cycle de dveloppement dune application comprend typiquement une tape dexpression des besoins, une tape de spcification, une tape de conception, une tape d'implmentation, une tape dintgration et de test, une tape dinstallation et de vrification ainsi que des tapes dopration et de maintenance. Selon le cycle de dveloppement choisi, ces tapes ou activits peuvent survenir une ou plusieurs fois dans un ordre prdtermin. Ces tapes font partie de tous les cycles de dveloppement de systmes indpendamment de la nature, du domaine, de la taille et de la complexit du systme dvelopper.

Plusieurs modles de cycle de dveloppement dune application existent : le modle en cascade [155], la cycle de vie en V[169], le prototypage rapide [152], le prototypage volutif [69], le rutilisation de logiciel [70], le dveloppement incrmental [81], etc. Nous prsentons rapidement les principes des modles classiques qui sont le modle en cascade et le cycle en V.

2.1.1 Le modle en cascade Le modle en cascade (figure 2.1) dcrit le cycle de vie comme une succession d'tapes

conduisant raffiner des niveaux de description du problme jusqu' sa ralisation, en partant de la dfinition jusqu' l'exploitation et la maintenance. Chaque tape est lie l'tape suivante pour reprsenter le raffinement, et l'tape prcdente pour reprsenter les corrections par retour-arrire. A chaque tape est associe une phase de vrification ayant pour but de s'assurer de la conformit de la solution retenue avec les spcifications en entre de l'tape. Un dfaut de conformit implique de reprendre l'tape ou de revoir le rsultat de l'tape prcdente.

Ce modle s'appuie sur le fait qu'un accroissement important de l'effort de validation durant les premires tapes favorise une correction rapide des premires erreurs et rduit le cot de correction considrable lors de l'implmentation.

10

Besoin Logiciel

Besoin Systme

Conception Prliminaire

Implmentation et Vrification

Intgration et Test

Exploitation et Maintenance

Lgende Etape

Raffinement

Rectification Vrifi KO

Vrifi KO

Vrifi KO

Vrifi KO

Vrifi KO

Vrifi KO

Vrifi OK

Vrifi OK

Vrifi OK

Vrifi OK

Vrifi OK

Vrifi OK

Conception dtaill

Fig. 2.1 : Le modle en cascade.

2.1.2 Le modle "cycle de vie en V" Le modle "cycle en V" considre la vrification et l'valuation du systme chaque tape

de ralisation. Il montre que la dmarche de spcification/conception est globalement descendante tandis que la phase de ralisation/vrification est globalement ascendante. Il s'agit alors d'assembler les constituants pour obtenir les fonctionnalits souhaites. Le cycle de vie en V du gnie logiciel (figure 2.2) [169], a largement inspir le cycle de vie des Systmes Automatiss de Production.

Lapproche par tapes est adapte aux systmes temps rel car ce sont des systmes dont

les besoins sont figs et clairement identifiables. En effet, lorsquun systme est destin piloter un procd, lanalyse des besoins se dduit naturellement des lois de commande conues pour assurer ce pilotage et des caractristiques physiques de linstallation contrler.

De plus, en identifiant clairement les dbuts et fins des diffrentes tapes, une approche par tape est statique et donc bien adapte la certification (ce qui est une ncessit pour la

CAHIER DES CHARGES

SPECIFICATION SYSTEME

SPECIFICATION LOGICIELLE

CONCEPTION PRELIMINAIRE

CONCEPTION DETAILLEE

REALISATION

EVALUATION TEST OPERATIONNEL

TEST INTEGRATION SYSTEME

TEST PERFORMANCE

TEST UNITAIRE

TEST INTEGRATION

Validation Ralisation

Spcification

Correction Conception

Certification

Validation

Validation

Vrification

Fig. 2.2 : Cycle de vie en V du gnie logiciel.

11

majorit des systmes critiques). De plus, dans les domaines comme l'automobile, une sparation claire et faite entre ceux qui spcifient (constructeur) et ceux qui conoivent (constructeur/quipementier) et implmentent (quipementier).

2.1.3 Discussion A partir de ces deux modles du cycle de dveloppement, on peut conclure que les

grandes tapes suivre afin de dvelopper un systme sont la spcification, la conception et l'implmentation. La spcification dcrit ce que le systme doit faire, mais pas comment il le fait. La conception modlise une abstraction de haut niveau de l'implmentation qui cache tous les dtails de l'implmentation. Limplmentation dcrit prcisment l'excution de l'application.

Lors du dveloppement d'un tel systme, le passage d'un niveau un autre est assur par des oprations de transformations. La nature du problme li aux systmes temps rel ncessite donc lutilisation dun processus de dveloppement et de maintenance rigoureux. Les proprits que le systme doit satisfaire doivent tre identifies puis maintenues tout au long du dveloppement lors de chaque transformation. Ceci suppose la mise en uvre dune ou de plusieurs techniques formelles.

Les modles proposs fournissent des principes gnraux pour le dveloppement des systmes temps rel, mais ne fournissent pas un cadre formel ncessaire aux systmes viss par cette tude. Nous prsentons maintenant, quelques travaux de recherche recentrs sur les techniques formelles.

2.2 Les techniques formelles

Dans le cadre du gnie logiciel, un technique est qualifie de formelle lorsque les diffrentes oprations qu'elle supporte, les objets manipuls par ces oprations ainsi que le systme de preuve qu'elle possde sont exprims dans un langage syntaxe et smantique formelles, base mathmatiques. Les techniques formelles relvent de la smantique, c'est--dire de la reprsentation mathmatique que l'on peut associer un programme.

La vrification de la correction lors du dveloppement de systmes temps rel ncessite dutiliser des techniques formelles dont lobjectif final est dassurer que les systmes dvelopps satisfont les proprits exprimes dans le cahier de charges (figure 2.3 et 2.4). Dans ce but, la dfinition et lutilisation de techniques rigoureuses de dveloppement apparaissent comme une composante indispensable des tapes de production dun systme correct. Ces deux activits sont indispensables dans le cycle de dveloppement des applications temps rel et interviennent tous les niveaux.

Le travail men dans [8] prsente une dmarche dutilisation des techniques formelles. Aprs avoir identifier les proprits que le systme tudi doit satisfaire et le langage ou la technique formelle utiliser, la dmarche propose deux cadres d'utilisation des techniques formelles. Le premier assure la vrification des proprits dune application exprimes par des techniques ou langages permettant leur reprsentation formelle. La figure 3 reprend ces principes o OPp est lobjet programme reprsentant le systme tudi et Pp lensemble de proprits de OPp. On parlera de vrification de la correction d'un modle.

12

OPp Pp

Reprsentation du systme Reprsentation des proprits

Expression et vrification de proprits

Fig. 2.3 : L'utilisation des techniques formelles pour la vrification.

La deuxime approche assure la maintenance des proprits de programme lors dune opration de transformation ou de raffinement. La figure 4 reprend ces principes o OPp, Pp sont dfinis comme ci-dessus, OP'p est lobjet programme obtenu suite la transformation, et P'p lensemble de proprits de OP'p. On ainsi assure la validation du programme transform et on parlera de conformit de la transformation d'un modle.

Reprsentation du systme Reprsentation des proprits

OPp Pp

Lutilisation de techniques formelles rend possible de nombreux dveloppements de programmes et de nombreuses vrifications de proprits. Par contre, des efforts doivent tre faits pour les rendre utilisables, grande chelle, dans la pratique.

2.3 Dveloppement de systmes temps rel

Aprs ces prsentations d'ordre gnral, nous prsentons, dans cette section, les travaux plus spcifiquement lis au dveloppement des systmes temps rel. Les travaux de recherche mentionns dans ce domaine peuvent tre classs selon quatre axes principaux. Un premier axe concerne les travaux qui ne se concentrent sur une certaine tape de dveloppement (la spcification, la conception ou l'implmentation). Dans un deuxime axe, les travaux se concentrent sur le raffinement et la transformation entre les tapes. On peut, par exemple, citer les travaux concernant la traduction de langage orient spcification vers un langage orient conception. La troisime catgorie de travaux propose de coupler des langages informels des langages formels. Le dernier axe, enfin, concerne des mthodes globales de dveloppement qui regroupent plusieurs tapes du dveloppement.

Dans le premier axe, les travaux mens dans [40] [170] se recentrent sur l'tape de spcification. Plus prcisment, ces travaux traitent des langages de spcification et de leurs capacits d'expression de contraintes temps rel. Le travail prsent dans [153] propose d'introduire le temps dans le diagramme de classe d'UML (Unified Modelling Language)

pPO pP

Conformit de la transformation

Opration de dveloppement

Fig. 2.4 : L'utilisation des techniques formelles lors d'une transformation ou d'un raffinement.

13

[137]. D'autres travaux sont orients sur l'tape de conception [113]. Par exemple le travail men dans [155] propose d'intgrer des techniques d'ordonnancement temps rel dans une conception oriente objet (en utilisant le langage UML-RT [171] comme un langage de conception). Enfin, en ce qui concerne la phase de l'implmentation, on peut situer le travail men dans [11]. Ce travail se concentre sur la traduction automatique d'un programme ESTEREL vers un code microprocesseur. Enfin de nombreux de travaux portant sur la validation et la vrification de systmes temps rel, nous dtaillons ces aspects par ailleurs dans le document.

En ce qui concerne le deuxime axe, il s'agit de raffiner un modle ou transformer un modle (par exemple la spcification) vers un autre modle (par exemple la conception). Par exemple, dans lapproche propose par [106], les auteurs se concentrent sur l'optimisation de code gnre partir d'une conception faite en SDL (Specification and Description Language). L'approche tudie deux stratgies pour gnrer le code partir du modle de conception. La premire stratgie (Activity Server) est de gnrer partir d'un chaque processus SDL un processus VHDL combin avec une bote aux lettres. La deuxime stratgie prconise la mise en place dun modle dexcution orient vnement nomm BAT (Basic Activity Thread). Dans ce cas, on associe une tche chaque enchanement d'actions provoqu par un vnement externe. CODARTS [72] est une mthode base sur SA-RT. CODARTS fournir des lments pour construire partir dun modle SA-RT (Structure Analysis - Real Time) un modle dexcution multitche pour une architecture monoprocesseur. Ces lments sont des rgles et des principes aidant mapper une spcification dun systme temps rel sur une conception base sur Ada comprenant des tches et des informations de communications entre les tches. Cette approche est trs intressante mais elle reste limite du fait de l'aspect informel de SA-RT et des rgles de transformation. D'autres travaux [139] ont t proposs dans le cadre de SA-RT/CODARTS : ils proposent d'utiliser le rseau de Ptri color avec pour objectif daugmenter la capacit temporelle analytique de CODARTS, laspect qualit de service et la conception de la concurrence. Cette approche propose de mapper les tches de CODARTS, les modles de communication et lexclusion mutuelle par des donnes partages en rseau de Ptri color.

Enfin, l'approche prsente dans [100] propose de combiner UML avec SDL. Cette approche permet de dfinir les rgles de transformation automatique dun sous ensemble formalis dOMT [100] not OMT* [130] vers SDL. Cette approche n'intgre pas tous les diagrammes supports par UML comme le diagramme de composant et de dploiement. Une autre approche propose par [87] dfinit un profil d'UML pour SDL nomm "SDL with UML". Ce profil dfinit un ensemble de spcialisations UML qui permettent d'utiliser un ensemble de concepts d'UML en conjonction avec SDL.

En ce qui concerne le troisime axe, les travaux mettent laccent sur plusieurs phases de dveloppement des systmes temps rel, telles que la spcification, la conception, l'implmentation et la vrification. Dans ce sens, le projet DESS de l'ITEA [114] propose d'utiliser le langage UML afin de spcifier les systme temps rel. Les contraintes temps rel (chances) sont spcifies au travers de timers virtuels proposs dans le diagramme de classe. Ce projet propose aussi de traduire la spcification semi formelle d'UML dans un formalisme formel tel que Trio [75], Esterel [38] ou Kronos [185] afin de vrifier des contraintes temps rel.

[58] propose d'utiliser une ou plusieurs techniques formelles dans la phase de conception pour dcrire le comportement du systme par niveaux d'abstraction. Cette formalisation est traduite partir d'une spcification informelle des besoins. L'implmentation est faite

14

automatiquement en utilisant des synthses partir de cette abstraction afin d'assurer que l'implmentation est correcte. La validation dans cette approche est faite via la simulation.

Au final, dans le dernier axe, l'approche prsente dans [172] recentre sur deux phases du dveloppement du systme temps rel, la spcification et la conception. Tout d'abord, la spcification dans cette approche est faite en utilisant la smantique UML+. Cette dernire est inspire des StateCharts temporiss [99]. La conception est la traduction de cette spcification en un modle UML-RT [171]. L'implmentation est base sur le fait que UML-RT peut produire directement du code en utilisant les outils existants comme Rational ROSE-RT [192]

PROSEUS [35] [21] est un guide mthodologique qui peut tre utilis par des concepteurs voulant utiliser UML pour la description et la spcification et SDL pour l'implmentation de diagrammes UML. Il propose d'utiliser SDL comme un langage intermdiaire entre UML et l'implmentation finale. PROSEUS propose d'utiliser le modle de SDL pour le prototypage, la gnration de code et la vrification de l'application. Il dfinit les diffrentes tapes de dveloppement et la mthode de passage entre tapes. Dans chaque tape, PROSEUS propose un formalisme utiliser et la manire dont il peut tre mis en uvre, mais pas un cadre formel de dveloppement.

2.4 Conclusion

En conclusion, le dveloppement de systmes temps rel doit s'appuyer sur des tapes de spcification, conception et implmentation. Les contraintes temps rel doivent tre exprimes chaque tape du dveloppement. Le passage d'une tape lautre, si ncessaire, est assur par des oprations de transformations ou de raffinements. Enfin, la vrification de proprits fonctionnelles, comportementales et la validation des transformations doit s'appuyer sur des techniques formelles.

Nous allons dsormais tudier les langages du domaine temps rel susceptibles de supporter une telle approche.

15

3 Langages de dveloppement des systmes temps rel. Dans ce chapitre, nous tudions, les langages qui peuvent tre utiliss dans le cycle de

dveloppement de Systmes Temps Rel (STR). Il sagit au premier lieu de langages utiliss pour spcifier et modliser les besoins des STR tels que SA-RT, UML et SDL, puis de langages utiliss pour leur conception (LACATRE, SDL-RT). Un point particulier est mis sur SDL.

3.1 Langage de spcification

Au niveau de la spcification, la description des systmes sappuie classiquement sur des langages qui permettent de les spcifier sous diffrents aspects (les types de donnes, les fonctionnalits, les protocoles de communication, etc.). Certains de ces langages sont informels comme SA-RT [79], semi-formels comme UML [136] ou formels comme SDL [135].

3.1.1 SA-RT

3.1.1.1 Introduction

Le langage SA-RT fut dvelopp par D.J. Hatley et I.A. Pirbhai afin de spcifier et de concevoir des systmes temps rel [79]. Il rpond aux besoins de ces systmes en intgrant lanalyse structure de DeMarco [49] et la thorie des machines tats finis pour la reprsentation dune structure de contrle [187]. Le langage SA-RT [44] est un langage permettant de spcifier les aspects dynamiques non dcrits dans la mthode SA.

Ce langage dissocie les aspects fonctionnels et vnementiels dune application temps rel. Laspect fonctionnel est une reprsentation de la transformation que le systme opre sur les donnes via des processus de transformation des donnes. Laspect vnementiel est une reprsentation des vnements qui conditionnent lvolution dun systme et la spcification de la logique de contrle. Cette dernire dclenche les actions, produit des vnements en fonction dvnements en entre et fait changer dtat le systme.

3.1.1.2 Caractristiques du langage

SA-RT [49] est un langage fonctionnel qui permet de spcifier un systme temps rel tant du point de vue logiciel que matriel (via des diagrammes d'architecture). De plus ce langage comprend plusieurs points importants concernant les aspects gnie logiciel.

Le raffinement est assur par la dcomposition descendante de SA-RT. Par ailleurs, la lisibilit dans une spcification SA-RT provient de la hirarchisation du modle en utilisant plusieurs niveaux de diagrammes. Ainsi la spcification dun systme permet de dcomposer celui-ci en plusieurs sous systmes.

La spcification SA-RT est informelle et ne permet donc pas de vrifier le modle dcrit. Afin de pallier ce manque, le projet IPTES (Incremental Prototyping of Technology for Embedded System) [188] propose une mthode base sur des prototypes. Ces prototypes sont dcrits par un langage de spcification qui est une extension de diagrammes SA-RT complte par des descriptions en Meta-IV. Ce dernier est un langage bas sur le langage formel VDM (Vienna Development Method) [17], pour spcifier les donnes et les transformations. Les

16

besoins temporels sont exprims en utilisant un formalisme qui sappelle High Level Timed Petri Net, dans lequel les modles SA-RT sont transforms.

A L'aspect temps rel

Laspect temps rel dans SA-RT s'appuie sur des spcifications des temps de rponse et des frquences de rptitions. Ces deux contraintes ne sont apparentes qu'aux signaux prsents l'interface du systme ou ceux prsents dans les diagrammes de contexte. La frquence de rptition est spcifie pour les signaux primitifs externes dans le dictionnaire de donnes.

Le temps de rponse entre une entre et une sortie est dfini sous forme de table listant les vnements qui sont dtects aux entres du systme, les vnements correspondants qui doivent se produire aux sorties du systme et les contraintes d'chance lintrieur desquels le systme doit gnrer ces rponses.

Enfin le travail men dans [142] propose de complter la spcification SA-RT par des spcifications exprimes sous forme de Rseaux de Petri avec pour un objectif damliorer les aspects formels et temporels. La spcification du contrle est faite par les rseaux de Petri qui permet de prendre en compte certains aspects temps rel comme, par exemple, l'utilisation du chien de garde pour dfinir des fentres temporelles associes la prise en compte de certains vnements. Linconvnient majeure rside dans la gnration du graphe de marquage avec le nombre de places et de connections qui peut tre assez trs grand mme pour des petits systmes.

3.1.1.3 Conclusion

Le langage SA-RT est trs rpandue et trs utilise pour spcifier les systmes temps rel, vraisemblablement cause de sa simplicit dutilisation et son pouvoir dexpression, graphique en particulier : SA-RT possde l'avantage d'tre bien lisible car la spcification est faite dune manire hirarchique. Cependant cette spcification est informelle et ne permet pas de vrifier directement le modle.

Les travaux mens s'appliquent fixer une smantique au langage. Pour autant, actuellement, peu de travaux sont en cours et peu d'outils formels disponibles.

Dans la suite, nous prsentons les travaux mens autour du langage UML, langage semi formel et orient objet.

3.1.2 UML

3.1.2.1 Introduction

Lutilisation de lapproche Oriente Objet (OO) dans le dveloppement de logiciel augmente la qualit du fait de la mise en oeuvre des principes de modularit (un logiciel est form dun ensemble dobjets), dencapsulation (une donne n'est pas accessible que via une interface) et de rutilisation (principe dhritage). Dans le domaine des langage OO, UML [136] simpose comme un standard. UML est un langage de modlisation graphique qui se veut universel pour les systmes dinformation. Il est utilis pour percevoir et documenter les phases de dveloppement des systmes.

17

UML a t standardis en 1997 par lorganisme de normalisation industriel OMG (Object Management Group) [194] et a fait lobjet damliorations successives jusqu ses dernires versions (UML 0.8 UML 0.9 UML 1.0 UML-2.0 [194] ). En fait, UML drive de trois diffrentes approches orientes objet, OMT [154], OOSE [132] et BOOCH [39] [22] UML dfinit une smantique pour les modles objets et fournit des notations pour capturer la structure et le comportement du systme.

3.1.2.2 Principes d'UML

Lors de la modlisation d'un systme, UML voit le systme travers plusieurs niveaux d'abstraction exprims par divers diagrammes. Le diagramme de cas dutilisation est utilis pour dcrire les interactions entre l'environnement et l'application. Ce diagramme se compose de l'ensemble des acteurs, du systme et des cas d'utilisation eux-mmes. Chaque acteur reprsente un rle jou par une personne ou un lment qui interagit avec le systme. Le cas d'utilisation regroupe la famille des squences dinteraction (les scnarios) du point de vue de lutilisateur.

Le diagramme de classe lui, exprime la structure statique dun systme, en termes de classes et de relations entre ces classes. Chaque classe consiste un ensemble d'attributs qui reprsentent les donnes et un ensemble des mthodes qui reprsentent les services. Le diagramme d'instance dcrit les objets qui constituent le systme.

Pour prsenter le comportement dynamique dun classe, le diagramme d'tat transition (Statechart) dfinit les mthodes excuter en fonction de ltat courant et des messages reus. Enfin, le diagramme d'activit permet de dcrire un enchanement d'actions.

Les diagrammes de squence et de collaboration permettent de modliser les interactions entre les objets au cours de scnarios donns. Ils s'appuient sur les cas d'utilisation, les diagrammes de classe et d'instance.

Tous ces modles peuvent tre "dcors" de contraintes non fonctionnelles (temps, prcdence, etc.) l'aide de mcanismes d'extension d'UML et du langage de description de contraintes OCL (Object Constraint Language specification) [136].

Les architectures matrielles et logicielles d'un systme peuvent tre dcrites en UML via les diagrammes de dploiement et de composants respectivement.

Dans la suite, nous prsentons les caractristiques du langage (aspect gnie logiciel, formel et temps rel) et les travaux mentionns autour de chaque aspect.

3.1.2.3 Caractristiques du langage

A Aspect gnie logiciel

UML a t cr dans le but de fournir lutilisateur la possibilit de modliser tous les aspects dun systme. Le raffinement nest pas formellement dfini mais on peut lexprimer par les relations de dpendances entre paquetages en utilisant le strotype refine [15]. La validation du raffinement seffectue de manire manuelle.

18

La lisibilit dans UML est assure au travers des neuf diagrammes d'UML. Chacun reprsente une vue diffrente du systme. Dautre part, UML n'utilise pas de termes syntaxiques apparents du code source.

UML est un langage gnraliste et son mtamodle est applicable un grand nombre de cas (conception de rseaux, systme rpartis, etc.). Un des avantages d'UML est la possibilit de dfinir des extensions, afin dadapter le langage au type de systme spcifier via les strotypes, profil et frameworks.

B Aspect formel

UML est considr comme un langage de notation semi-formel [113] et ne possdant pas une smantique prcise [182]. Deux approches ont t proposes pour pallier ce derniier manque.

La premire approche consiste rester dans UML et formaliser UML laide de lui-mme. C'est--dire, modliser le domaine smantique dUML en UML. Cette formalisation rcursive, qui constitue le mtamodle d'UML, dcrit de manire formelle les lments de modlisation ainsi que la syntaxe et la smantique de la notation qui permet de les manipuler. Le mtamodle d'UML devient loutil vrificateur qui facilite lidentification des incohrences. On retrouve dans cette catgorie certains travaux initis par le groupe precise UML (pUML) [55]. De mme la proposition du groupe de travail sur lAction Semantics [137] qui travaille llaboration de la smantique qui est officiellement adopte pour UML par lOMG [137]. Le langage dAction Semantics reprsente certainement lun des efforts les plus significatifs visant donner UML les bases formelles permettant de lui appliquer avec succs des techniques formelles.

La deuxime approche est de lier UML avec dautres formalismes formels. Un certain nombre de travaux publis rcemment ont choisi une approche par traduction afin de permettre lutilisation de techniques formelles avec UML. Dans la majorit des cas, ces travaux sattachent plus particulirement au diagramme tats transitions d'UML. Loutil ObjectGeode [183] contient un module permettant de compiler les statecharts d'UML en processus du langage SDL. Il est ensuite possible de simuler le comportement de la spcification [87]. Certaines travaux assurent un lien entre les statecharts dUML et les MSC [200]. Dautres travaux, enfin, portent sur un couplage entre UML et les rseaux de Petri [140], Lotos [44], SMV [127] et SyncChart [50].

C Aspects temps rel

La modlisation des aspects temps rel fait lobjet de nombreux travaux car la notation UML est de plus en plus utilise par les concepteurs de systmes temps rel. Dans les faits, ce nest pas un, mais plusieurs UMLs temps rel qui sont en comptition pour rpondre aux exigences proposes par lOMG [15]. La recherche dans ce domaine se divise selon trois axes.

a Profils

Tout dabord, un profil UML concernant le temps, lordonnanabilit et la performance SPT (UML profile for Performance, Scheduling and Time) [15] a t dfini et standardis par lOMG. Ce profil a pour objectif daugmenter la capacit de modlisation de la qualit de service lie au temps (chances et dures). De plus, ce profil permet de dfinir un systme temps rel sous forme de ressources, de dfinir leurs proprits temporelles et de modliser leur dploiement sur une architecture cible. Pour la modlisation de ces contraintes, des

19

strotypes sont mis en place comme par exemple deadline pour reprsenter une chance simple. Ce profil est utilis par Rhapsody [196] et son couplage l'outil de validation RapidRMA

[195] qui permet lanalyse dordonnanabilit du systme [15]. Lavantage du SPT est d'avoir t adopt par lOMG [15] et d'tre capable de spcifier directement en UML des informations quantitatives [141].

Dautre part, MAST [197] propose un nouveau profil, bas sur UML, avec pour objectif de construire un modle temps rel analysable. On trouve un modle d'architecture matrielle, un modle dexcution (tches) et un modle des politiques dordonnancement. Le principal avantage de MAST est quil permet de modliser dune manire indpendante les aspects temps rel, les oprations logiques, la plateforme matrielle et les dtails du systme dexploitation. De plus, MAST a t dvelopp pour sintgrer avec Rational Rose [94] afin de raliser une analyse RMA [98].

b Extension

Un autre travail porte sur une extension de la notation UML base de strotypes. C'est le cas du langage UML-RT [171] support par loutil ROSE-RT [192]. Cette notation est drive du langage ROOM [110] pour prsenter des types spciaux d'objets actifs avec des rgles de connexion qui spcifient une smantique particulire. Ces objets sappellent capsules. Ils interagissent entre eux au travers des messages via des ports. Le port est un objet qui sert dintermdiaire entre une capsule et son environnement et implmente un protocole spcifique.

La notation UML-RT permet de se rapprocher de larchitecture relle du systme mais, malheureusement, ne permet pas la validation et il existe un nombre limit d'outils automatiques qui supporte ROOM [110]. De plus, elle apporte une modularit forte dans le sens o les ports de communication entre capsules sont des interfaces entre la capsule et ses liens de communication entre les capsules. Cette notation semble pallier certaines lacunes dUML au niveau des aspects lis la communication l'architecture des systmes rels [13].

c Approches conjointes

Enfin, des travaux de recherche portent sur lutilisation conjointe dUML et dun langage formel possdant une smantique temps rel. Dans ce cadre, des travaux ont dfini une passerelle entre les diagrammes dtats transitions et les diagrammes des collaborations et les automates temporiss et UPPAAL [12]. Cette passerelle permet la vrification formelle dune collaboration dobjets temporiss [110]. Dautres travaux ont t proposs avec l'utilisation des rseaux de Petri [140], Z [52], de langages synchrones [10], de E-LOTOS [35] et d'UML-IF [138].

3.1.2.4 Conclusion Le langage UML de modlisation se veut universel pour les systmes dinformation mais

ne propose pas de mthodologie ou de cadre formel au dveloppement des STR. De plus, lapproche objet, de part ses besoins de modularit et d'encapsulation amnent introduire de nombreuses classes, ce qui induit une architecture pouvant ne pas tre performante du point de vue temporel [83]. De plus, des analyses fines sont ncessaires lors de la gnration du modle dexcution pour introduire des politiques temps rel [20].

20

Les travaux de recherche, autour d'UML, prsents ci avant peuvent se deviser en plusieurs catgories. Dans une premire approche les travaux (MAST [197] et SPT [15]) se recentrent sur la spcialisation du langage UML pour le domaine de temps rel en utilisant des profils et des strotypes. La deuxime approche propose d'ajouter des smantiques formelles UML afin de valider le modle. Enfin, des travaux proposent d'associer UML un autre langage qui permet de valider les modles tels que SDL, UPPAAL et rcemment IF [138].

Au-del de SA-RT et UML, il existe des langages formels pour la modlisation des systmes concurrents tels que SDL. Dans la suite, nous prsentons SDL et les travaux mens autour de SDL [85] [122].

3.1.3 SDL

3.1.3.1 Introduction SDL

SDL [122] [85] [67] est un langage de description formel trs utilis dans la communaut des tlcommunications. Cependant son cadre dapplication actuel dpasse largement ce domaine. SDL est employ avec succs dans des domaines comme les systmes embarqus ou multimdia [64]. SDL est un langage normalis (ITU-T) et utilis dans le monde industriel car soutenu par un environnement de dveloppement intgr (objectGEODE [135], Tau [200]).

Au travers de SDL, lunivers se divise en deux parties : le systme et son environnement. Les spcifications dcrites en SDL sont limites au systme.

3.1.3.2 Principes de SDL

Dans cette section, nous rappelons brivement les principes de base de SDL. SDL est une technique de description formelle base sur les automates tats finis communicants EFSM (Extended Finite State Machines) [85] [135] [122]. La premire version a t publie par le CCITT (devenu ITU-T) en 1976. Ractualis tous les quatre ans pour tenir compte des nouveaux besoins de ses utilisateurs, SDL est la technique la plus rpandue dans la communaut des tlcommunications. Il possde deux modes quivalents de spcification : SDL textuel et SDL graphique. Une spcification SDL est architecture autour de 3 niveaux d'abstraction :

Le systme, qui dfinit les limites entre le systme spcifi et l'environnement ;

Le bloc, contenu dans le systme, qui englobe un ou plusieurs processus (ou blocs). Il permet de subdiviser les lments d'un systme afin d'en faciliter la gestion.

Le processus, qui regroupe les actions effectues. Un processus est une machine tat fini (FSM).

Ces lments sont interconnects au moyen de routes et de canaux. Le concept de route a t supprim dans la dernire version de SDL (SDL-2000) [67]. Les canaux et routes peuvent tre unidirectionnels ou bidirectionnels. Les routes sont rserves la communication intra-processus tandis que les canaux peuvent tre utiliss pour interconnecter des blocs entre eux et les blocs avec l'environnement du systme. Les canaux peuvent tre avec ou sans dlai de communication, le dlai tant alatoire.

21

A La communication

Les processus communiquent via des signaux de manire asynchrone (non bloquant pour 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 (Processus IDentifier), le signal est consomm par la premire des instances du processus pouvant le consommer. Dans lexemple prsent la figure 3.1, par exemple, le signal IT est transmis du bloc capteur vers le bloc appli via le canal can1. Il est ensuite consomm par le processus capteur. Ce dernier produit son tour le signal I.

Un autre type de communication entre les processus dans SDL est le partage de donne. Une donne est toujours encapsule dans un processus. Mais, il est possible de la rendre visible par un autre processus (View/Revealed). Par contre la donne ne peut tre utilise que par les processus se trouvant dans le mme bloc que la variable partage. Lopration View na pas le droit de modifier la variable. L'autre mode de partage consiste sauvegarder explicitement (mot cl EXPORT) une copie de la donne et la consulter explicitement (mot cl IMPORT) dans un autre processus.

Process Command Inoccup

I

changement

false

Inoccup

true

calcule

O

Inoccup

Fig. 3.1-asystem A IPPL

can1

IT can2

Com

horloge

can3 TOP_1

ICapteur appli

Lgende : Systme Bloc, sous-bloc

Canal Processus

[Signal]

Block appli Fig. 3.1-b

CommandeCapteur Actionneur[IT] [I] [O] [com]

Signal en entre Signal en sortie

Fig. 3.1-c

IActionneur

tat Condition

Fig. 3.1 : Un spcification en SDL

B Concurrence

Les instances de processus (process en SDL) s'excutent en parallle. Dans un tat donn, une transition consomme un ou plusieurs signaux, excute selon des conditions des actions (tche au sens SDL ou procdure) puis met ventuellement un ou plusieurs signaux. Si deux instances de processus) sont tirables au mme instant, aucune relation d'ordre n'est donnedonnes a priori. Il nexiste pas de concurrence intra instance de processus.

22

C 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 de validation (base sur un calcul) 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.

Dans la transition, on trouve, en plus des actions et des envois de signaux, des crations d'autres processus. Les conditions permettent dexprimer plusieurs chemins possibles pour une transition. Un tat particulier est ltat de dpart o se place linstance sa cration.

Dans lexemple de la figure 3.1-c, lorsque le processus commande est dans ltat inoccup et quil reoit un signal I, si les donnes vhicules par le signal respectent une certaine condition changement, une procdure Calcul est excute afin de produire un nouveau signal O. Sinon le processus neffectue aucune action et revient ltat inoccup.

D 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 FIFO). 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.

E SDL et les types

SDL n'est pas un langage orient objet (OO) mais il contient des mcanismes ncessaires pour couvrir les concepts principaux de l'OO (classe, objet, mthode et hritage). Dans SDL, le type correspond la classe, l'instance correspond l'objet, les processus, procdures correspondent aux mthodes et le mcanisme de l'hritage simple correspond l'hritage simple dans l'OO. Il est d'ailleurs possible de traduire un modle OO exprim selon OMT [100] en SDL.

Les types peuvent tre empaquet dans des libraires (package). De plus, chaque type (donc processus type, bloc type ou systme type) peut tre paramtr par des paramtres formels de contexte qui peuvent tre un processus, une procdure, un signal, une variable, un

23

timer ou un type de donne. A partir d'un type paramtr, d'autres types peuvent tre cres en replaant les paramtres formels de contexte par des paramtres rels de contexte.

SDL permet de spcialiser les types en utilisant le mot-cl inherits. Cette spcialisation permet d'obtenir un nouveau type qui hrite du comportement du type parent.

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 conceptuels pour la spcification de systmes.

3.1.3.3 Caractristiques du langage.

Par analogie la prsentation du langage SA-RT et UML, nous prsentons le langage SDL suivant les mmes aspects (formel, gnie logiciel et temps rel). En ce qui concerne l'aspect formel, ds la dfinition SDL, nous avons mentionn que SDL est un langage formel. Nous prsentons, d'abord, l'aspect gnie logiciel puis nous prsentons les travaux mens autour de l'aspect temps rel.

A Aspect gnie logiciel

SDL est trs bien adapt la conception de rseaux, de protocoles, de systmes rpartis, ractifs et de tlcommunication [85]. SDL permet davoir une dmarche de haut niveau pour la spcification et permet la gnration de code source, la simulation et la mise en place de preuves.

Le raffinement et labstraction sont assurs et dfini par l'utilisation des lments structurels de base que sont les types. Le concept objet a aussi t ajout. Il est possible, en effet, de dfinir des objets (et des classes dobjet) avec leurs attributs et leurs mthodes [67] [179].

Par ailleurs, la lisibilit en SDL provient de la hirarchisation du systme.

B Aspect temps rel

a Introduction

SDL ne possde pas dlments de spcification clair et prcis de lcoulement du temps. Il ne fournit pas une description complte de la faon dont le modle doit sexcuter dans le temps [29]. Il est, par exemple, impossible dassurer lactivation dune transition dun processus une date prcise 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 temps rel par linstance de processus est lie au contexte de lapplication (tat de la bote 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.

24

En conclusion, il n'y a aucun moyen de vrifier (en ltat de la smantique) si le modle respecte bien les contraintes temps rel 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 plusieurs approches telles que les approches manipulant l'aspect de l'expression de temps et l'aspect d'ordonnancement.

b Modlisation du temps avec SDL.

Les travaux mens dans ce domaine peuvent tre diviss en plusieurs approches. Dans la premire approche (TSDL [31], QSDL [51] [68] [165]), on se propos