N° d’ordre 04ISAL0052….. Année 2004

Thèse

Développement formel de systèmes temps réel à l'aide de SDL et IF

(Compilation pour système temps réel)

présentée devant L’Institut National des Sciences Appliquées de Lyon

pour obtenir

le grade de docteur

Ecole doctorale :EDIIS (Informatique et Information pour la Société) Spécialité : ISCE (Informatique et Systèmes Coopératifs pour l’Entreprise)

par Ahmad Badreddin ALKHODRE

Soutenue le 20 septembre 2004

Jury MM.

M.SIFAKIS Joseph, Professeur CNRS-Verimag Grenoble (Président). M.MAMMERI Zoubir, Professeur IRIT-Toulouse (Rapporteur). M.TERRIER François Professeur CEA –Paris (Rapporteur). M.BONIOL Frédéric Maître de conférence à l'ONERA-CERT-Toulouse (Examinateur). M.SCHWARZ Jean-Jacques, Professuer UCBL (Directeur de thèse). M.BABAU Jean-Philippe, Maître de conférence à l'INSA de Lyon (co-encadrant).

Cette thèse a été préparée au Laboratoire de CITI – Centre d’Innovations en Télécommunications et Intégration de Services de L’INSA de Lyon.

ii

Introduction générale ........................................................................................................................................... 1

Objectif de la thèse............................................................................................................................................. 3 Structure du mémoire ......................................................................................................................................... 4

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

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

1 Notions de système réactif et de contraintes temps réel ........................................................................... 6 1.1 Les systèmes réactifs....................................................................................................................... 6 1.2 Les systèmes temps réel .................................................................................................................. 6 1.3 Les contraintes temps réel ............................................................................................................... 6 1.4 Conclusion ...................................................................................................................................... 8

2 Méthodologies ........................................................................................................................................ 10 2.1 Principes généraux des méthodologies.......................................................................................... 10

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

2.2 Les techniques formelles............................................................................................................... 12 2.3 Développement de systèmes temps réel ........................................................................................ 13 2.4 Conclusion .................................................................................................................................... 15

3 Langages de développement des systèmes temps réel............................................................................. 16 3.1 Langage de spécification............................................................................................................... 16

3.1.1 SA-RT ....................................................................................................................................... 16 3.1.1.1 Introduction..................................................................................................................... 16 3.1.1.2 Caractéristiques 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 Caractéristiques 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 Caractéristiques 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 générale de la partie langages..................................................................................... 35 4 Validation et vérification ........................................................................................................................ 36

4.1 Vérification comportementale....................................................................................................... 36 4.1.1 Relation d'équivalence.............................................................................................................. 36

4.1.1.1 Système de transitions étiquetées (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 Vérification temps réel .................................................................................................................. 40 4.2.1 Les automates temporisés......................................................................................................... 40 4.2.2 La logique temps réel ............................................................................................................... 40 4.2.3 Techniques dédiées à la validation des système temps réel...................................................... 42

i

4.2.3.1 Principes.......................................................................................................................... 42 4.2.3.2 Vérification des implémentations multitâches ................................................................ 44

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

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

5 Description de la méthodologie .............................................................................................................. 49 5.1 Les étapes de la méthodologie....................................................................................................... 49

5.1.1 Modèle de contraintes............................................................................................................... 50 5.1.2 Modèle d’exécution .................................................................................................................. 50 5.1.3 Implémentation......................................................................................................................... 50 5.1.4 Choix des langages................................................................................................................... 50

5.2 Validation...................................................................................................................................... 51 6 Le modèle de contraintes ........................................................................................................................ 52

6.1 Modèle d'interaction...................................................................................................................... 52 6.2 Modèle temporel de l’environnement ........................................................................................... 54

6.2.1 Introduction .............................................................................................................................. 54 6.2.2 Activation périodique ............................................................................................................... 54

6.2.2.1 Introduction..................................................................................................................... 54 6.2.2.2 Spécification en SDL ...................................................................................................... 55 6.2.2.3 La sémantique en IF :...................................................................................................... 56

6.2.3 Activation sur interruption ....................................................................................................... 57 6.2.3.1 Source d’interruption régulière ....................................................................................... 57 6.2.3.2 Source d'interruption en rafale ........................................................................................ 58

6.2.4 Le modèle temporel des données.............................................................................................. 61 6.2.4.1 Spécification en SDL ...................................................................................................... 61 6.2.4.2 La sémantique en IF........................................................................................................ 62

6.2.5 Activation par message............................................................................................................. 63 6.2.5.1 La spécification en SDL.................................................................................................. 63 6.2.5.2 La sémantique en IF........................................................................................................ 64

6.3 Le modèle temporel des actions .................................................................................................... 65 6.3.1 Spécification SDL du modèle temporel d'action. ..................................................................... 65 6.3.2 La sémantique du modèle temporel d'action. ........................................................................... 68

6.4 L'échéance et l'âge de donnée ....................................................................................................... 69 6.4.1 Introduction .............................................................................................................................. 69 6.4.2 L'âge d’une donnée................................................................................................................... 70 6.4.3 Echéance................................................................................................................................... 70 6.4.4 Politique temps réel : ................................................................................................................ 71

6.4.4.1 Filtrage : Vérification de durée de séparation ................................................................. 71 6.4.4.2 Vérification d’échéance .................................................................................................. 73 6.4.4.3 Vérification de l’âge de données..................................................................................... 74

6.5 Utilisation des modèles ................................................................................................................. 74 6.6 Conclusion .................................................................................................................................... 75

7 Le modèle d’exécution ............................................................................................................................ 76 7.1 Introduction................................................................................................................................... 76 7.2 Eléments applicatifs ...................................................................................................................... 78

7.2.1 Les routines .............................................................................................................................. 78 7.2.1.1 La routine d’interruption................................................................................................. 78 7.2.1.2 La routine d’alarme......................................................................................................... 80

7.2.2 Les tâches ................................................................................................................................. 81 7.2.2.1 Les tâches périodiques .................................................................................................... 82 7.2.2.2 Les tâches sporadiques.................................................................................................... 83 7.2.2.3 Les serveurs à scrutation................................................................................................. 84 7.2.2.4 Les tâches logicielles ...................................................................................................... 86

7.2.3 Les données .............................................................................................................................. 90 7.3 Modèle d'exécution pour l'environnement .................................................................................... 90

7.3.1 Source d'interruption et alarme périodique............................................................................... 90 7.4 Contrôleur programmable des interruptions.................................................................................. 91

ii

7.4.1 La modélisation du PIC en SDL ............................................................................................... 91 7.4.2 La sémantique du PIC en IF ..................................................................................................... 92

7.5 Politique temps réel....................................................................................................................... 92 7.5.1 Utilisation du chien de garde.................................................................................................... 93

7.5.1.1 La modélisation en SDL ................................................................................................. 93 7.5.1.2 La sémantique en IF 2.0.................................................................................................. 94

7.5.2 Utilisation de la fonction check ................................................................................................ 95 7.5.2.1 La modélisation en SDL ................................................................................................. 95 7.5.2.2 La sémantique en IF 2.0.................................................................................................. 96

7.6 Politique d’ordonnancement ......................................................................................................... 97 7.7 Eléments sépcificques ................................................................................................................... 98

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

8 Génération 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 d’ordonnancement et la priorité .................................. 104 8.5 Code pour des OS classiques embarqués (Windows) ................................................................. 105

8.5.1 Windows et temps réel ........................................................................................................... 105 8.5.2 Du modèle d’exécution à Win32®......................................................................................... 105

8.5.2.1 La communication entre les objets................................................................................ 105 8.5.2.2 La routine d’interruption............................................................................................... 106 8.5.2.3 Alarme .......................................................................................................................... 106 8.5.2.4 La routine d’alarme....................................................................................................... 106 8.5.2.5 La tâche périodique....................................................................................................... 107 8.5.2.6 Le serveur à scrutation .................................................................................................. 107 8.5.2.7 La tâche logicielle ......................................................................................................... 108 8.5.2.8 Le «main» ..................................................................................................................... 108 8.5.2.9 La gestion de priorités................................................................................................... 108

8.6 Code pour des exécutif temps réel .............................................................................................. 109 8.6.1 VxWorks® et le temps réel ..................................................................................................... 109 8.6.2 Du modèle d’exécution 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 L’alarme........................................................................................................................ 110 8.6.2.4 La routine d’alarme....................................................................................................... 111 8.6.2.5 La tâche périodique....................................................................................................... 111 8.6.2.6 Le serveur à scrutation .................................................................................................. 111 8.6.2.7 La tâche logicielle ......................................................................................................... 112 8.6.2.8 Le «main» ..................................................................................................................... 112 8.6.2.9 La gestion de priorités................................................................................................... 113

8.6.3 Restrictions sur l'action Afaire................................................................................................ 113 8.6.4 Contrôle temps réel................................................................................................................. 113

8.7 La compilation du modèle d’exécution vers Win32® ou VxWorks® ........................................ 116 8.7.1 L’analyseur lexical et l’analyseur syntaxique......................................................................... 116 8.7.2 L’analyse sémantique ............................................................................................................. 118 8.7.3 La génération 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 Définition de problème........................................................................................................... 124 9.2.3 Formalisation du problème de compatibilité .......................................................................... 125

9.2.3.1 Modèle de contraintes ................................................................................................... 125 9.2.3.2 Modèle d'exécution ....................................................................................................... 126 9.2.3.3 Algorithme .................................................................................................................... 128

iii

9.3 Méthodologie de la validation formelle ...................................................................................... 129 9.3.1.1 Redéfinir une base de temps unitaire ............................................................................ 129 9.3.1.2 La deuxième étape : le renommage............................................................................... 130 9.3.1.3 La troisième étape : abstraction et réduction des modèles : .......................................... 130 9.3.1.4 La quatrième é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 périodiques................................................................................ 135 9.3.2.3 Observation d'échéance................................................................................................. 138

9.3.3 Conclusion.............................................................................................................................. 140 9.4 Vérification des propriétés temps réel......................................................................................... 142

9.4.1 Modèle RMA.......................................................................................................................... 142 9.4.2 Extraction des paramètres temporels pour RMA.................................................................... 142 9.4.3 Les propriétés à vérifier.......................................................................................................... 143

9.4.3.1 Vérification d'une échéance simple............................................................................... 143 9.4.3.2 Vérification d'une échéance de bout en bout................................................................. 145 9.4.3.3 Vérification la validité d'une donnée ............................................................................ 146

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

Conclusion générale. ......................................................................................................................................... 149

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

Références.......................................................................................................................................................... 152

Bibliographie liée à l'étude ............................................................................................................................... 168

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

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

iv

Introduction générale

1

Un système temps réel est un système qui interagit avec un environnement physique en remplissant souvent des missions critiques pour lesquelles une faute du système peut avoir des conséquences graves. Il sera dit correct s'il possède les bonnes fonctionnalités et si celles-ci sont réalisées à temps, c'est-à-dire avec le respect des contraintes temporelles imposées par l’environnement ou par une certaine qualité de service offerte à un utilisateur. La validation fonctionnelle et temporelle des systèmes temps réel est ainsi une nécessité forte. Toutes les situations, tous les comportements du système doivent être envisagés pour que la validation fournisse des résultats fiables.

Si l'on sait maintenant comment faire pour développer des systèmes temps réel (aller de la spécification vers la réalisation) il est indispensable, vu les conséquences possibles d'une faute temporelle, de porter un intérêt particulier à la sûreté de fonctionnement, aux méthodes permettant de valider le développement avec pour objectif de garantir à l'avance le bon fonctionnement du point de vue temporel.

Afin de garantir le bon fonctionnement du système, il faut utiliser lors du développement de ce système, des techniques de modélisation et outils formels (possédant des représentations mathématiques que l'on peut associer à un programme) qui permettent d'effectuer des preuves de modèles.

Le développement d'un système temps réel passe par l'utilisation de langages et d'outils adaptés aux besoins des différentes étapes de développement (la spécification, la conception, l'implémentation et la vérification) et les contraintes temps réel se doivent d'être exprimées et prise en compte à chacune de ces étapes. Le modèle associé à l'étape de spécification est le modèle de contraintes. On y décrit le comportement du système et les contraintes temporelles du système (ce que le système doit faire). Le modèle associé à la conception est appelé le modèle d'exécution : on y décrit l'architecture d'exécution de l'application (comment le système doit s'exécuter). Ce modèle est une abstraction de l'implémentation, qui cache tous les détails de l'implémentation, comme par exemple les moyens de communication. Différentes solutions dépendantes des technologies d'implémentation sont, bien sûr, possibles et chacune d’entre elles aura recours à un outillage approprié. Dans le cadre de ce travail nous n'étudions que l'implémentation basée sur l’utilisation d’un système multitâches monoprocesseur. Ce type d’implémentation qui s'appuie donc sur les services d'un exécutif temps réel est largement utilisé par les industriels à cause de la relative facilité d’utilisation, mais n’a pas bénéficier de beaucoup de développement d’outils pour la valididation.

Les travaux de recherches liés au développement de système temps réel se divisent en plusieurs axes.

Dans un premier axe, les travaux menés se concentrent sur une étape particulière du développement telle que la spécification, la conception ou l'implémentation. En ce que concerne la spécification, les travaux menés s'appuient en général sur l'utilisation d’un langage de haut niveau. Ainsi, à titre d’exemple, vu la facilité de son utilisation, SA-RT (Structure Analysis - Real Time) [79] a été utilisé pour la spécification de systèmes temps réel, même s’il n’est qu’un langage informel. D'autres approches adoptent des langages de modélisations orientés objet comme UML (Unified Modelling Language) [136]. Ce dernier est un langage semi-formel qui ne possède pas une sémantique précise. Enfin, des approches utilisent des langages formels comme SDL (Specification and Description Language) [85]

2

[125]. Il reste toutefois que SDL ne possède pas de mécanismes lui permettant d'exprimer précisément les contraintes temps réel. Afin de pallier cette lacune, plusieurs travaux ont été développés pour enrichir SDL sur ce point, soit par l'adjonction à une autre langage temps réel [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 boîtes à outils qui s'appuient sur des boîtes grises à instancier lors de la conception. Les langages UML-RT et SDL-RT permettent d'intégrer les aspects temps réel mais ils ne proposent pas un cadre formel de conception. L'approche de LACATRE [160] [158] propose un cadre formel pour le développement, mais pas pour la prise en compte des contraintes temps réel. Finalement, peu de travaux sont développés autour de la problématique concernant la transformation entre le modèle associé à la spécification et le modèle associé à la conception tels que proposés dans [72] [106]. En ce qui concerne la correction de cette transformation, elle peut être garantie en utilisant les techniques d'abstraction et de vérification. Les approches développées dans [60] [61] [121] [150] ne s'appliquent que dans le cas où le modèle d'exécution est une adaptation du modèle de contraintes.

Dans le deuxième axe, les travaux se concentrent sur la mise en place d'une architecture d'exécution. On essaie alors d'optimiser le déplacement des actions dans les tâches [72] [106]. A titre d'exemple l'approche CODARTS propose des règles et des principes aidant à mapper une spécification d’un système temps réel sur une conception basée sur le langage Ada [72].

Les travaux dans du troisième axe se focalisent sur le développement de techniques de validation du système temps réel telles que proposées par [91] [75] [37][185]. Ces techniques permettent de valider des propriétés par rapport à un modèle donné, par exemple l'approche de model-checking [104] [119], soit de valider la conformité de modèles en s’appuyant sur la notion d'équivalence [60] [121].

Toutes ces études apportent des principes, des solutions ou des modèles intéressants pour le développement de systèmes temps réel. Cependant ces approches se concentrent spécifiquement sur une étape particulière du développement indépendamment des autres. Donc, aujourd'hui, il existe peu d'approches complètes et formelles qui regroupent tous les aspects nécessaires pour le développement d'un système temps réel en passant de la spécification à la réalisation (implémentation).

Objectif de la thèse

Dans le cadre des implémentations à base d’exécutifs multitâche temps réel, le travail présenté dans cette thèse tente d’apporter une approche complète formelle de la suite spécification, conception et implémentation. Dans ce cadre, il porte aussi un intérêt particulier à une méthode de validation de la transformation entre le modèle de contraintes et le modèle d'exécution

Dans un premier temps, nous décrivons plus particulièrement la formalisation des phases aboutissant à la définition du modèle de contraintes et du modèle d’exécution de l’application. Dans ce but, nous utilisons le langage SDL [67] [85] [122] présentant suffisamment de caractéristiques formelles. SDL, langage normalisé par l’ITU-T, est très utilisé dans la communauté des télécommunications, mais son cadre d’application actuel dépasse largement ce domaine : il est employé avec succès dans des domaines comme les systèmes embarqués

3

ou le multimédia [64]. Le monde industriel l’apprécie car il est soutenu par un environnement de développement intégré (objectGEODE [135], Tau [200]). Par contre, SDL ne possède pas d’éléments de spécification clairs et précis de l’écoulement du temps et il ne fournit pas une description complète de la façon dont le modèle doit s’exécuter dans le temps [29].

Ensuite, le but de cette étude est de prendre en considération la dimension temporelle dans nos modèles SDL. C’est le langage IF [28] qui sera exploité pour fixer une sémantique temporelle utile à la validation.

Afin de prouver la correction de la transformation entre le modèle de contraintes et le modèle d'exécution, nous proposons une relation de compatibilité comportementale entre ces deux modèles. Cette relation de compatibilité sera exploitée par une méthodologie en quatre étapes pour vérifier la correction de la transformation entre le modèle de contraintes et le modèle d'exécution.

Finalement, afin de valider l'implémentation multitâche proposée, nous présentons une approche de validation qui s'appuie sur l'analyse d'ordonnançabilité RMA [98]. Cette approche permet de vérifier, d'une part, la cohérence temporelle de modèle d'exécution et d'autre part les propriétés temps réel exprimées dans les modèles (de contraintes et d'exécution) telles que l'échéance et la durée de la validité d'une donnée.

Structure du mémoire

Dans cette optique, ce document est constitué de deux parties. La première partie présente le contexte de notre travail : les systèmes temps réel et leur contraintes en faisant état de leurs spécificités et exigences. Nous décrivons divers éléments pris en compte lors de leur développement (chapitre 1), en particulier les méthodologies de développement (chapitre 2), les langages utilisés (chapitre 3) et les techniques de validation (chapitre 4).

Dans la deuxième partie nous présentons la structuration de notre contribution, puis chaque étape (spécification, conception et implémentation) sera détaillée. Nous présentons la description de la méthodologie à suivre dans le chapitre 5. Les modèles de contraintes et d'exécution exprimés en SDL avec la sémantique en IF font l’objet des chapitres 5 et 6. Le chapitre 8 est consacré aux principes de génération de code et, au final, le chapitre 9 traite le problème de la validation et de la vérification. Nous y abordons le problème de la conformité du modèle d'exécution par rapport au modèle de contraintes et nous montrons comment il est possible de vérifier les contraintes temps réel par une analyse de type RMA à partir des modèles proposés.

4

Partie I

Contexte de travail.

L’objectif de cette partie du mémoire est de présenter le domaine visé par notre contribution que sont les systèmes temps réel. En particulier, on s'intéresse aux divers éléments mis en place lors du développement de tels systèmes que sont les méthodologies, les langages et les techniques de validation et de vérification.

5

1 Notions de système réactif et de contraintes temps réel

1.1 Les systèmes réactifs

Les systèmes informatiques sont traditionnellement classés suivant trois catégories [78] :

− Les systèmes transformationnels transforment des données pour produire un ou plusieurs résultats. Les programmes de calcul scientifique sont des exemples de systèmes transformationnels. Les résultats produits dépendent uniquement des données traitées.

− Les systèmes interactifs interagissent avec leur environnement. Leur exécution est contrôlée par une boucle d’attente des événements auxquels sont associés des traitements. Pour ces systèmes, l’environnement est généralement limité à un utilisateur humain. Les programmes de bureautique sont des exemples de systèmes interactifs. Les résultats produits dépendent des données et des événements.

− Les systèmes réactifs réagissent aux stimuli émis par leur environnement. A la différence des systèmes interactifs, l’environnement évolue de manière indépendante et n’attend pas la fin du traitement associé à un stimulus émis. Les systèmes de contrôle - commande sont des exemples de systèmes réactifs. Les résultats dépendent des données, des événements et de leur enchaînement en lien avec l'état de l'environnement.

Dans ce travail, nous nous intéressons aux systèmes réactifs et plus précisément aux systèmes réactifs temps réel.

1.2 Les systèmes temps réel

Les systèmes temps réels sont une classe de systèmes informatiques réactifs dont le but est de suivre et piloter les évolutions d’un procédé dynamique avec des contraintes de temps physique [57]. Le temps de réaction du système aux stimuli du procédé doit être assujetti à la dynamique du procédé. La correction d’un système temps réel ne s’évalue donc pas uniquement du point de vue fonctionnel (justesse des résultats calculés) et temporel (enchaînement correct des événement) mais également du point de vue temps réel (dates d’arrivée des événements) : "Un résultat juste mais hors délai est un résultat faux" [177].

Ces systèmes sont aujourd’hui présents dans des domaines tels que l’automobile, l’avionique, le spatial mais aussi le contrôle de chaînes de production, de processus chimique, etc.

Le caractère critique souvent attaché aux systèmes temps réel résulte principalement du souci de préserver le procédé (par exemple un engin spatial), son environnement (par exemple une centrale nucléaire) et les personnes (par exemple un engin de transport). En conséquence, il est nécessaire d’appliquer des techniques de validation tout au long du processus de développement de tels systèmes [168]. La validation doit aussi bien porter sur les contraintes fonctionnelles que sur les contraintes temporelles et sur les contraintes temps réel.

1.3 Les contraintes temps réel

Dans le cycle de vie d’un système temps réel, les contraintes temps réel apparaissent dès la phase d’expression des besoins. Ainsi, lorsque sont spécifiées les fonctionnalités du

6

système liées au contrôle du procédé, les contraintes temps réel nécessaires à la garantie de ce contrôle doivent être données. En fait, les systèmes réactif temps réel, sont vus comme un ensemble d'actions qui opèrent sur des données en prenant en compte l'écoulement du temps et des événements qui apparaissent au niveau du système réactif ou de son environnement [125]. De ce fait, les contraintes temps réel doivent être exprimées sur ces trois éléments principaux.

Contraintes temps réel associées aux actions

Une action peut correspondre à tout traitement ayant une fonctionnalité bien précise au niveau d'un système. Selon [88] une action peut être :

− Une action primitive : c’est une opération consommant une quantité bornée de ressource du système.

− Une action composite : c’est une séquence d’actions primitives.

Les contraintes temporelles portant sur les actions sont :

− La date de réveil : c'est l'instant où l'action peut démarrer.

− L'instant d’exécution : il représente l'instant où une action commence à s'exécuter.

− La durée d'exécution : il représente le temps écoulé pendant l'exécution d'une action.

− La date de fin d’exécution : il représente l'instant où l'action se termine.

Contraintes temps réel associées aux événements Un événement est un marqueur temporel, c'est-à-dire une occurrence qui marque un point

temporel ayant son importance dans la description du comportement du système. Les événements sont classés en plusieurs types :

− Un événement périodique est un évènement ponctuel, mais revenant périodiquement, par exemple tous les 5 millisecondes. Il est donc caractérisé par sa période.

− Un événement sporadique est un événement aléatoire, mais il existe une durée minimale et une autre maximale entre deux occurrences de deux événements successifs.

− Un événement apériodique est un événement aléatoire dont on ne possède pas d'informations temporelles quant à sa date d'occurrence.

Les contraintes temporelles exprimées sur les événements sont :

− Une durée séparative minimale et maximale entre l'occurrence de deux événements successifs : Dans le cas des événements périodiques un seule durée (période) caractérise l'occurrence des événements. Par contre, deux durées caractérisent l'occurrence des événements sporadiques.

− Une échéance de bout en bout (End-to-End Deadline) représente un intervalle de temps maximum entre un événement en entrée et un événement en sortie du système. Elles sont typiquement associées à une action (celle déclenchée par l'événement entrée) et se répercutent alors sur les différentes entités qui participent à la réalisation de cette action.

7

− Une échéance relative qui porte sur la terminaison d’une action, soit entre les deux événements date de réveil et date de fin d'exécution. Ces contraintes apparaissent par exemple avec l’éclatement de contraintes de bout en bout correspondant au découpage du logiciel.

Contraintes temps réel associées aux données Une donnée représente toute information utilisée par une ou plusieurs actions pour

s'exécuter. Les données appartiennent aux deux types suivants :

− Les données actives : ce sont des données dont la mise à jour provoque une réaction du système et qui se matérialise par le déclenchement d’actions (mises à jour d’autres données, déclenchement d’une alarme,...). La mise à jour des données suit soit une loi périodique (par exemple, la mise à jour périodique de la vitesse d’un avion déclenche la mise à jour de l’altitude [186] ), soit une loi sporadique.

− Les données temporelles sont des données datées qui permettent de gérer l’historique de leur évolution [168]. Ces données sont soient lues sur le procédé, soit émises vers le procédé.

Pour prendre des décisions correctes en tenant compte de l’état réel de l’environnement, les données manipulées par une application temps réel doivent être cohérentes du point de vue temporel.

Les contraintes temporelles exprimées sur ces deux types de données sont :

− La contrainte de cadence : elle caractérise un intervalle de temps entre deux mises à jour. De telles contraintes sont caractéristiques des systèmes échantillonnés.

− L'âge d'une donnée est l’intervalle maximum entre la date de production par le procédé et la date de consommation par toute action du système.

− La latence est le délai requis par le système de contrôle pour prendre en compte une donnée (c’est à dire la date maximum entre la date de production de la donnée par le procédé et la date de consommation par toute action du système).

Selon qu’il faille absolument respecter une contrainte ou qu’il soit possible de la violer occasionnellement, il est usuel de classer les contraintes dans deux catégories [125]. Les contraintes temps réel « dures » sont celles qu’il faut à tout prix respecter. Les contraintes temps réel « souples » sont celles qu’il faut respecter autant que possible, mais qui supportent occasionnellement d’être violées.

1.4 Conclusion

Les systèmes temps réel, sont vus comme un ensemble d'actions qui opèrent sur des données en prenant en compte l'écoulement du temps et les événements qui apparaissent au niveau du système réactif ou de son environnement. Ces événements sont soit des événements périodiques, soit des événements sporadiques. Ils sont caractérisés d'une part par leurs fréquences d'arrivées et des durées dmin et dmax, et d'autre part, par la contrainte de délai entre un événement en entrée et un événement en sortie. Les données sont caractérisées par une fréquence de mise à jour et possèdent une durée de validité.

8

Nous présentons maintenant les travaux menés autour du développement des systèmes temps réel. Nous parlons d'abord des méthodologies de développement.

9

2 Méthodologies Nous présentons dans ce chapitre les principales méthodologies, les techniques formelles

et enfin, les travaux principaux menés dans le développement du système temps réel.

2.1 Principes généraux des méthodologies

Le modèle du cycle de vie d’une application est un modèle des étapes ou des activités qui commencent quand le logiciel est conçu et se termine quand le produit n’est plus disponible pour l’utilisation [126]. Le cycle de développement d’une application comprend typiquement une étape d’expression des besoins, une étape de spécification, une étape de conception, une étape d'implémentation, une étape d’intégration et de test, une étape d’installation et de vérification ainsi que des étapes d’opération et de maintenance. Selon le cycle de développement choisi, ces étapes ou activités peuvent survenir une ou plusieurs fois dans un ordre prédéterminé. Ces étapes font partie de tous les cycles de développement de systèmes indépendamment de la nature, du domaine, de la taille et de la complexité du système à développer.

Plusieurs modèles de cycle de développement d’une application existent : le modèle en cascade [155], la cycle de vie en V[169], le prototypage rapide [152], le prototypage évolutif [69], le réutilisation de logiciel [70], le développement incrémental [81], etc. Nous présentons rapidement les principes des modèles classiques qui sont le modèle en cascade et le cycle en V.

2.1.1 Le modèle en cascade

Le modèle en cascade (figure 2.1) décrit le cycle de vie comme une succession d'étapes conduisant à raffiner des niveaux de description du problème jusqu'à sa réalisation, en partant de la définition jusqu'à l'exploitation et à la maintenance. Chaque étape est liée à l'étape suivante pour représenter le raffinement, et à l'étape précédente pour représenter les corrections par retour-arrière. A chaque étape est associée une phase de vérification ayant pour but de s'assurer de la conformité de la solution retenue avec les spécifications en entrée de l'étape. Un défaut de conformité implique de reprendre l'étape ou de revoir le résultat de l'étape précédente.

Ce modèle s'appuie sur le fait qu'un accroissement important de l'effort de validation durant les premières étapes favorise une correction rapide des premières erreurs et réduit le coût de correction considérable lors de l'implémentation.

10

Besoin Logiciel

Besoin Système

Conception Préliminaire

Implémentation et Vérification

Intégration et Test

Exploitation et Maintenance

Légende Etape

Raffinement

Rectification Vérifié KO

Vérifié KO

Vérifié KO

Vérifié KO

Vérifié KO

Vérifié KO

Vérifié OK

Vérifié OK

Vérifié OK

Vérifié OK

Vérifié OK

Vérifié OK

Conception détaillé

Fig. 2.1 : Le modèle en cascade.

2.1.2 Le modèle "cycle de vie en V"

Le modèle "cycle en V" considère la vérification et l'évaluation du système à chaque étape de réalisation. Il montre que la démarche de spécification/conception est globalement descendante tandis que la phase de réalisation/vérification est globalement ascendante. Il s'agit alors d'assembler les constituants pour obtenir les fonctionnalités souhaitées. Le cycle de vie en V du génie logiciel (figure 2.2) [169], a largement inspiré le cycle de vie des Systèmes Automatisés de Production.

L’approche par étapes est adaptée aux systèmes temps réel car ce sont des systèmes dont

les besoins sont figés et clairement identifiables. En effet, lorsqu’un système est destiné à piloter un procédé, l’analyse des besoins se déduit naturellement des lois de commande conçues pour assurer ce pilotage et des caractéristiques physiques de l’installation à contrôler.

De plus, en identifiant clairement les débuts et fins des différentes étapes, une approche par étape est statique et donc bien adaptée à la certification (ce qui est une nécessité 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 Réalisation

Spécification

Correction Conception

Certification

Validation

Validation

Vérification

Fig. 2.2 : Cycle de vie en V du génie logiciel.

11

majorité des systèmes critiques). De plus, dans les domaines comme l'automobile, une séparation claire et faite entre ceux qui spécifient (constructeur) et ceux qui conçoivent (constructeur/équipementier) et implémentent (équipementier).

2.1.3 Discussion

A partir de ces deux modèles du cycle de développement, on peut conclure que les grandes étapes à suivre afin de développer un système sont la spécification, la conception et l'implémentation. La spécification décrit ce que le système doit faire, mais pas comment il le fait. La conception modélise une abstraction de haut niveau de l'implémentation qui cache tous les détails de l'implémentation. L’implémentation décrit précisément l'exécution de l'application.

Lors du développement d'un tel système, le passage d'un niveau à un autre est assuré par des opérations de transformations. La nature du problème lié aux systèmes temps réel nécessite donc l’utilisation d’un processus de développement et de maintenance rigoureux. Les propriétés que le système doit satisfaire doivent être identifiées puis maintenues tout au long du développement lors de chaque transformation. Ceci suppose la mise en œuvre d’une ou de plusieurs techniques formelles.

Les modèles proposés fournissent des principes généraux pour le développement des systèmes temps réel, mais ne fournissent pas un cadre formel nécessaire aux systèmes visés par cette étude. Nous présentons maintenant, quelques travaux de recherche recentrés sur les techniques formelles.

2.2 Les techniques formelles

Dans le cadre du génie logiciel, un technique est qualifiée de formelle lorsque les différentes opérations qu'elle supporte, les objets manipulés par ces opérations ainsi que le système de preuve qu'elle possède sont exprimés dans un langage à syntaxe et à sémantique formelles, à base mathématiques. Les techniques formelles relèvent de la sémantique, c'est-à-dire de la représentation mathématique que l'on peut associer à un programme.

La vérification de la correction lors du développement de systèmes temps réel nécessite d’utiliser des techniques formelles dont l’objectif final est d’assurer que les systèmes développés satisfont les propriétés exprimées dans le cahier de charges (figure 2.3 et 2.4). Dans ce but, la définition et l’utilisation de techniques rigoureuses de développement apparaissent comme une composante indispensable des étapes de production d’un système correct. Ces deux activités sont indispensables dans le cycle de développement des applications temps réel et interviennent à tous les niveaux.

Le travail mené dans [8] présente une démarche d’utilisation des techniques formelles. Après avoir identifier les propriétés que le système étudié doit satisfaire et le langage ou la technique formelle à utiliser, la démarche propose deux cadres d'utilisation des techniques formelles. Le premier assure la vérification des propriétés d’une application exprimées par des techniques ou langages permettant leur représentation formelle. La figure 3 reprend ces principes où OPp est l’objet programme représentant le système étudié et Pp l’ensemble de propriétés de OPp. On parlera de vérification de la correction d'un modèle.

12

OPp Pp

Représentation du système Représentation des propriétés

Expression et vérification de propriétés

Fig. 2.3 : L'utilisation des techniques formelles pour la vérification.

La deuxième approche assure la maintenance des propriétés de programme lors d’une opération de transformation ou de raffinement. La figure 4 reprend ces principes où OPp, Pp sont définis comme ci-dessus, OP'

p est l’objet programme obtenu suite à la transformation, et P'

p l’ensemble de propriétés de OP'p. On ainsi assure la validation du programme transformé

et on parlera de conformité de la transformation d'un modèle.

Représentation du système Représentation des propriétés

OPp Pp

L’utilisation de techniques formelles rend possible de nombreux développements de programmes et de nombreuses vérifications de propriétés. Par contre, des efforts doivent être faits pour les rendre utilisables, à grande échelle, dans la pratique.

2.3 Développement de systèmes temps réel

Après ces présentations d'ordre général, nous présentons, dans cette section, les travaux plus spécifiquement liés au développement des systèmes temps réel. Les travaux de recherche mentionnés dans ce domaine peuvent être classés selon quatre axes principaux. Un premier axe concerne les travaux qui ne se concentrent sur une certaine étape de développement (la spécification, la conception ou l'implémentation). Dans un deuxième 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é spécification vers un langage orienté conception. La troisième catégorie de travaux propose de coupler des langages informels à des langages formels. Le dernier axe, enfin, concerne des méthodes globales de développement qui regroupent plusieurs étapes du développement.

Dans le premier axe, les travaux menés dans [40] [170] se recentrent sur l'étape de spécification. Plus précisément, ces travaux traitent des langages de spécification et de leurs capacités d'expression de contraintes temps réel. Le travail présenté dans [153] propose d'introduire le temps dans le diagramme de classe d'UML (Unified Modelling Language)

pPO ′pP′

Conformité de la transformation

Opération de développement

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

13

[137]. D'autres travaux sont orientés sur l'étape de conception [113]. Par exemple le travail mené dans [155] propose d'intégrer des techniques d'ordonnancement temps réel dans une conception orientée objet (en utilisant le langage UML-RT [171] comme un langage de conception). Enfin, en ce qui concerne la phase de l'implémentation, 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 vérification de systèmes temps réel, nous détaillons ces aspects par ailleurs dans le document.

En ce qui concerne le deuxième axe, il s'agit de raffiner un modèle ou transformer un modèle (par exemple la spécification) vers un autre modèle (par exemple la conception). Par exemple, dans l’approche proposée par [106], les auteurs se concentrent sur l'optimisation de code générée à partir d'une conception faite en SDL (Specification and Description Language). L'approche étudie deux stratégies pour générer le code à partir du modèle de conception. La première stratégie (Activity Server) est de générer à partir d'un chaque processus SDL un processus VHDL combiné avec une boîte aux lettres. La deuxième stratégie préconise la mise en place d’un modèle d’exécution orienté événement nommé BAT (Basic Activity Thread). Dans ce cas, on associe une tâche à chaque enchaînement d'actions provoqué par un événement externe. CODARTS [72] est une méthode basée sur SA-RT. CODARTS fournir des éléments pour construire à partir d’un modèle SA-RT (Structure Analysis - Real Time) un modèle d’exécution multitâche pour une architecture monoprocesseur. Ces éléments sont des règles et des principes aidant à mapper une spécification d’un système temps réel sur une conception basée sur Ada comprenant des tâches et des informations de communications entre les tâches. Cette approche est très intéressante mais elle reste limitée du fait de l'aspect informel de SA-RT et des règles de transformation. D'autres travaux [139] ont été proposés dans le cadre de SA-RT/CODARTS : ils proposent d'utiliser le réseau de Pétri coloré avec pour objectif d’augmenter la capacité temporelle analytique de CODARTS, l’aspect qualité de service et la conception de la concurrence. Cette approche propose de mapper les tâches de CODARTS, les modèles de communication et l’exclusion mutuelle par des données partagées en réseau de Pétri coloré.

Enfin, l'approche présentée dans [100] propose de combiner UML avec SDL. Cette approche permet de définir les règles de transformation automatique d’un sous ensemble formalisé d’OMT [100] noté OMT* [130] vers SDL. Cette approche n'intègre pas tous les diagrammes supportés par UML comme le diagramme de composant et de déploiement. Une autre approche proposée par [87] définit un profil d'UML pour SDL nommé "SDL with UML". Ce profil définit un ensemble de spécialisations UML qui permettent d'utiliser un ensemble de concepts d'UML en conjonction avec SDL.

En ce qui concerne le troisième axe, les travaux mettent l’accent sur plusieurs phases de développement des systèmes temps réel, telles que la spécification, la conception, l'implémentation et la vérification. Dans ce sens, le projet DESS de l'ITEA [114] propose d'utiliser le langage UML afin de spécifier les système temps réel. Les contraintes temps réel (échéances) sont spécifiées au travers de timers virtuels proposés dans le diagramme de classe. Ce projet propose aussi de traduire la spécification semi formelle d'UML dans un formalisme formel tel que Trio [75], Esterel [38] ou Kronos [185] afin de vérifier des contraintes temps réel.

[58] propose d'utiliser une ou plusieurs techniques formelles dans la phase de conception pour décrire le comportement du système par niveaux d'abstraction. Cette formalisation est traduite à partir d'une spécification informelle des besoins. L'implémentation est faite

14

automatiquement en utilisant des synthèses à partir de cette abstraction afin d'assurer que l'implémentation est correcte. La validation dans cette approche est faite via la simulation.

Au final, dans le dernier axe, l'approche présentée dans [172] recentre sur deux phases du développement du système temps réel, la spécification et la conception. Tout d'abord, la spécification dans cette approche est faite en utilisant la sémantique UML+. Cette dernière est inspirée des StateCharts temporisés [99]. La conception est la traduction de cette spécification en un modèle UML-RT [171]. L'implémentation est basée 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 méthodologique qui peut être utilisé par des concepteurs voulant utiliser UML pour la description et la spécification et SDL pour l'implémentation de diagrammes UML. Il propose d'utiliser SDL comme un langage intermédiaire entre UML et l'implémentation finale. PROSEUS propose d'utiliser le modèle de SDL pour le prototypage, la génération de code et la vérification de l'application. Il définit les différentes étapes de développement et la méthode de passage entre étapes. Dans chaque étape, PROSEUS propose un formalisme à utiliser et la manière dont il peut être mis en œuvre, mais pas un cadre formel de développement.

2.4 Conclusion

En conclusion, le développement de systèmes temps réel doit s'appuyer sur des étapes de spécification, conception et implémentation. Les contraintes temps réel doivent être exprimées à chaque étape du développement. Le passage d'une étape à l’autre, si nécessaire, est assuré par des opérations de transformations ou de raffinements. Enfin, la vérification de propriétés fonctionnelles, comportementales et la validation des transformations doit s'appuyer sur des techniques formelles.

Nous allons désormais étudier les langages du domaine temps réel susceptibles de supporter une telle approche.

15

3 Langages de développement des systèmes temps réel. Dans ce chapitre, nous étudions, les langages qui peuvent être utilisés dans le cycle de

développement de Systèmes Temps Réel (STR). Il s’agit au premier lieu de langages utilisés pour spécifier et modéliser les besoins des STR tels que SA-RT, UML et SDL, puis de langages utilisés pour leur conception (LACATRE, SDL-RT). Un point particulier est mis sur SDL.

3.1 Langage de spécification

Au niveau de la spécification, la description des systèmes s’appuie classiquement sur des langages qui permettent de les spécifier sous différents aspects (les types de données, les fonctionnalités, 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 développé par D.J. Hatley et I.A. Pirbhai afin de spécifier et de concevoir des systèmes temps réel [79]. Il répond aux besoins de ces systèmes en intégrant l’analyse structurée de DeMarco [49] et la théorie des machines à états finis pour la représentation d’une structure de contrôle [187]. Le langage SA-RT [44] est un langage permettant de spécifier les aspects dynamiques non décrits dans la méthode SA.

Ce langage dissocie les aspects fonctionnels et événementiels d’une application temps réel. L’aspect fonctionnel est une représentation de la transformation que le système opère sur les données via des processus de transformation des données. L’aspect événementiel est une représentation des événements qui conditionnent l’évolution d’un système et la spécification de la logique de contrôle. Cette dernière déclenche les actions, produit des événements en fonction d’événements en entrée et fait changer d’état le système.

3.1.1.2 Caractéristiques du langage

SA-RT [49] est un langage fonctionnel qui permet de spécifier un système temps réel tant du point de vue logiciel que matériel (via des diagrammes d'architecture). De plus ce langage comprend plusieurs points importants concernant les aspects génie logiciel.

Le raffinement est assuré par la décomposition descendante de SA-RT. Par ailleurs, la lisibilité dans une spécification SA-RT provient de la hiérarchisation du modèle en utilisant plusieurs niveaux de diagrammes. Ainsi la spécification d’un système permet de décomposer celui-ci en plusieurs sous systèmes.

La spécification SA-RT est informelle et ne permet donc pas de vérifier le modèle décrit. Afin de pallier ce manque, le projet IPTES (Incremental Prototyping of Technology for Embedded System) [188] propose une méthode basée sur des prototypes. Ces prototypes sont décrits par un langage de spécification qui est une extension de diagrammes SA-RT complétée par des descriptions en Meta-IV. Ce dernier est un langage basé sur le langage formel VDM (Vienna Development Method) [17], pour spécifier les données et les transformations. Les

16

besoins temporels sont exprimés en utilisant un formalisme qui s’appelle High Level Timed Petri Net, dans lequel les modèles SA-RT sont transformés.

A L'aspect temps réel

L’aspect temps réel dans SA-RT s'appuie sur des spécifications des temps de réponse et des fréquences de répétitions. Ces deux contraintes ne sont apparentées qu'aux signaux présents à l'interface du système ou ceux présents dans les diagrammes de contexte. La fréquence de répétition est spécifiée pour les signaux primitifs externes dans le dictionnaire de données.

Le temps de réponse entre une entrée et une sortie est défini sous forme de table listant les événements qui sont détectés aux entrées du système, les événements correspondants qui doivent se produire aux sorties du système et les contraintes d'échéance à l’intérieur desquels le système doit générer ces réponses.

Enfin le travail mené dans [142] propose de compléter la spécification SA-RT par des spécifications exprimées sous forme de Réseaux de Petri avec pour un objectif d’améliorer les aspects formels et temporels. La spécification du contrôle est faite par les réseaux de Petri qui permet de prendre en compte certains aspects temps réel comme, par exemple, l'utilisation du chien de garde pour définir des fenêtres temporelles associées à la prise en compte de certains événements. L’inconvénient majeure réside dans la génération du graphe de marquage avec le nombre de places et de connections qui peut être assez très grand même pour des petits systèmes.

3.1.1.3 Conclusion

Le langage SA-RT est très répandue et très utilisée pour spécifier les systèmes temps réel, vraisemblablement à cause de sa simplicité d’utilisation et son pouvoir d’expression, graphique en particulier : SA-RT possède l'avantage d'être bien lisible car la spécification est faite d’une manière hiérarchique. Cependant cette spécification est informelle et ne permet pas de vérifier directement le modèle.

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

Dans la suite, nous présentons les travaux menés autour du langage UML, langage semi formel et orienté objet.

3.1.2 UML

3.1.2.1 Introduction

L’utilisation de l’approche Orientée Objet (OO) dans le développement de logiciel augmente la qualité du fait de la mise en oeuvre des principes de modularité (un logiciel est formé d’un ensemble d’objets), d’encapsulation (une donnée n'est pas accessible que via une interface) et de réutilisation (principe d’héritage). Dans le domaine des langage OO, UML [136] s’impose comme un standard. UML est un langage de modélisation graphique qui se veut universel pour les systèmes d’information. Il est utilisé pour percevoir et documenter les phases de développement des systèmes.

17

UML a été standardisé en 1997 par l’organisme de normalisation industriel OMG (Object Management Group) [194] et a fait l’objet d’améliorations successives jusqu’à ses dernières versions (UML 0.8 UML 0.9 UML 1.0 à UML-2.0 [194] ). En fait, UML dérive de trois différentes approches orientées objet, OMT [154], OOSE [132] et BOOCH [39] [22] UML définit une sémantique pour les modèles objets et fournit des notations pour capturer la structure et le comportement du système.

3.1.2.2 Principes d'UML

Lors de la modélisation d'un système, UML voit le système à travers plusieurs niveaux d'abstraction exprimés par divers diagrammes. Le diagramme de cas d’utilisation est utilisé pour décrire les interactions entre l'environnement et l'application. Ce diagramme se compose de l'ensemble des acteurs, du système et des cas d'utilisation eux-mêmes. Chaque acteur représente un rôle joué par une personne ou un élément qui interagit avec le système. Le cas d'utilisation regroupe la famille des séquences d’interaction (les scénarios) du point de vue de l’utilisateur.

Le diagramme de classe lui, exprime la structure statique d’un système, en termes de classes et de relations entre ces classes. Chaque classe consiste à un ensemble d'attributs qui représentent les données et un ensemble des méthodes qui représentent les services. Le diagramme d'instance décrit les objets qui constituent le système.

Pour présenter le comportement dynamique d’un classe, le diagramme d'état transition (Statechart) définit les méthodes à exécuter en fonction de l’état courant et des messages reçus. Enfin, le diagramme d'activité permet de décrire un enchaînement d'actions.

Les diagrammes de séquence et de collaboration permettent de modéliser les interactions entre les objets au cours de scénarios donnés. Ils s'appuient sur les cas d'utilisation, les diagrammes de classe et d'instance.

Tous ces modèles peuvent être "décorés" de contraintes non fonctionnelles (temps, précédence, etc.) à l'aide de mécanismes d'extension d'UML et du langage de description de contraintes OCL (Object Constraint Language specification) [136].

Les architectures matérielles et logicielles d'un système peuvent être décrites en UML via les diagrammes de déploiement et de composants respectivement.

Dans la suite, nous présentons les caractéristiques du langage (aspect génie logiciel, formel et temps réel) et les travaux mentionnés autour de chaque aspect.

3.1.2.3 Caractéristiques du langage

A Aspect génie logiciel

UML a été créé dans le but de fournir à l’utilisateur la possibilité de modéliser tous les aspects d’un système. Le raffinement n’est pas formellement défini mais on peut l’exprimer par les relations de dépendances entre paquetages en utilisant le stéréotype «refine» [15]. La validation du raffinement s’effectue de manière manuelle.

18

La lisibilité dans UML est assurée au travers des neuf diagrammes d'UML. Chacun représente une vue différente du système. D’autre part, UML n'utilise pas de termes syntaxiques apparentés à du code source.

UML est un langage généraliste et son métamodèle est applicable à un grand nombre de cas (conception de réseaux, système répartis, etc.). Un des avantages d'UML est la possibilité de définir des extensions, afin d’adapter le langage au type de système à spécifier via les stéréotypes, profil et frameworks.

B Aspect formel

UML est considéré comme un langage de notation semi-formel [113] et ne possèdant pas une sémantique précise [182]. Deux approches ont été proposées pour pallier ce derniier manque.

La première approche consiste à rester dans UML et à formaliser UML à l’aide de lui-même. C'est-à-dire, à modéliser le domaine sémantique d’UML en UML. Cette formalisation récursive, qui constitue le métamodèle d'UML, décrit de manière formelle les éléments de modélisation ainsi que la syntaxe et la sémantique de la notation qui permet de les manipuler. Le métamodèle d'UML devient l’outil vérificateur qui facilite l’identification des incohérences. On retrouve dans cette catégorie certains travaux initiés par le groupe precise UML (pUML) [55]. De même la proposition du groupe de travail sur l’Action Semantics [137] qui travaille à l’élaboration de la sémantique qui est officiellement adoptée pour UML par l’OMG [137]. Le langage d’Action Semantics représente certainement l’un des efforts les plus significatifs visant à donner à UML les bases formelles permettant de lui appliquer avec succès des techniques formelles.

La deuxième approche est de lier UML avec d’autres formalismes formels. Un certain nombre de travaux publiés récemment ont choisi une approche par traduction afin de permettre l’utilisation de techniques formelles avec UML. Dans la majorité des cas, ces travaux s’attachent plus particulièrement au diagramme états transitions d'UML. L’outil 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 spécification [87]. Certaines travaux assurent un lien entre les statecharts d’UML et les MSC [200]. D’autres travaux, enfin, portent sur un couplage entre UML et les réseaux de Petri [140], Lotos [44], SMV [127] et SyncChart [50].

C Aspects temps réel

La modélisation des aspects temps réel fait l’objet de nombreux travaux car la notation UML est de plus en plus utilisée par les concepteurs de systèmes temps réel. Dans les faits, ce n’est pas un, mais plusieurs UMLs temps réel qui sont en compétition pour répondre aux exigences proposées par l’OMG [15]. La recherche dans ce domaine se divise selon trois axes.

a Profils

Tout d’abord, un profil UML concernant le temps, l’ordonnançabilité et la performance SPT (UML profile for Performance, Scheduling and Time) [15] a été défini et standardisé par l’OMG. Ce profil a pour objectif d’augmenter la capacité de modélisation de la qualité de service liée au temps (échéances et durées). De plus, ce profil permet de définir un système temps réel sous forme de ressources, de définir leurs propriétés temporelles et de modéliser leur déploiement sur une architecture cible. Pour la modélisation de ces contraintes, des

19

stéréotypes sont mis en place comme par exemple deadline pour représenter une échéance simple. Ce profil est utilisé par Rhapsody [196] et son couplage à l'outil de validation RapidRMA

[195] qui permet l’analyse d’ordonnançabilité du système [15]. L’avantage du SPT est d'avoir été adopté par l’OMG [15] et d'être capable de spécifier directement en UML des informations quantitatives [141].

D’autre part, MAST [197] propose un nouveau profil, basé sur UML, avec pour objectif de construire un modèle temps réel analysable. On trouve un modèle d'architecture matérielle, un modèle d’exécution (tâches) et un modèle des politiques d’ordonnancement. Le principal avantage de MAST est qu’il permet de modéliser d’une manière indépendante les aspects temps réel, les opérations logiques, la plateforme matérielle et les détails du système d’exploitation. De plus, MAST a été développé pour s’intégrer avec Rational Rose [94] afin de réaliser une analyse RMA [98].

b Extension

Un autre travail porte sur une extension de la notation UML à base de stéréotypes. C'est le cas du langage UML-RT [171] supporté par l’outil ROSE-RT [192]. Cette notation est dérivée du langage ROOM [110] pour présenter des types spéciaux d'objets actifs avec des règles de connexion qui spécifient une sémantique particulière. Ces objets s’appellent capsules. Ils interagissent entre eux au travers des messages via des ports. Le port est un objet qui sert d’intermédiaire entre une capsule et son environnement et implémente un protocole spécifique.

La notation UML-RT permet de se rapprocher de l’architecture réelle du système 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 d’UML au niveau des aspects liés à la communication à l'architecture des systèmes réels [13].

c Approches conjointes

Enfin, des travaux de recherche portent sur l’utilisation conjointe d’UML et d’un langage formel possédant une sémantique temps réel. Dans ce cadre, des travaux ont défini une passerelle entre les diagrammes d’états transitions et les diagrammes des collaborations et les automates temporisés et UPPAAL [12]. Cette passerelle permet la vérification formelle d’une collaboration d’objets temporisés [110]. D’autres travaux ont été proposés avec l'utilisation des réseaux 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 modélisation se veut universel pour les systèmes d’information mais

ne propose pas de méthodologie ou de cadre formel au développement des STR. De plus, l’approche objet, de part ses besoins de modularité et d'encapsulation amènent à 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 nécessaires lors de la génération du modèle d’exécution pour introduire des politiques temps réel [20].

20

Les travaux de recherche, autour d'UML, présentés ci avant peuvent se deviser en plusieurs catégories. Dans une première approche les travaux (MAST [197] et SPT [15]) se recentrent sur la spécialisation du langage UML pour le domaine de temps réel en utilisant des profils et des stéréotypes. La deuxième approche propose d'ajouter des sémantiques formelles à UML afin de valider le modèle. Enfin, des travaux proposent d'associer à UML un autre langage qui permet de valider les modèles tels que SDL, UPPAAL et récemment IF [138].

Au-delà de SA-RT et UML, il existe des langages formels pour la modélisation des systèmes concurrents tels que SDL. Dans la suite, nous présentons SDL et les travaux menés 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 très utilisé dans la communauté des télécommunications. Cependant son cadre d’application actuel dépasse largement ce domaine. SDL est employé avec succès dans des domaines comme les systèmes embarqués ou multimédia [64]. SDL est un langage normalisé (ITU-T) et utilisé dans le monde industriel car soutenu par un environnement de développement intégré (objectGEODE [135], Tau [200]).

Au travers de SDL, l’univers se divise en deux parties : le système et son environnement. Les spécifications décrites en SDL sont limitées au système.

3.1.3.2 Principes de SDL

Dans cette section, nous rappelons brièvement les principes de base de SDL. SDL est une technique de description formelle basée sur les automates à états finis communicants EFSM (Extended Finite State Machines) [85] [135] [122]. La première version a été publiée par le CCITT (devenu ITU-T) en 1976. Réactualisé tous les quatre ans pour tenir compte des nouveaux besoins de ses utilisateurs, SDL est la technique la plus répandue dans la communauté des télécommunications. Il possède deux modes équivalents de spécification : SDL textuel et SDL graphique. Une spécification SDL est architecturée autour de 3 niveaux d'abstraction :

− Le système, qui définit les limites entre le système spécifié et l'environnement ;

− Le bloc, contenu dans le système, qui englobe un ou plusieurs processus (ou blocs). Il permet de subdiviser les éléments d'un système afin d'en faciliter la gestion.

− Le processus, qui regroupe les actions effectuées. Un processus est une machine à état fini (FSM).

Ces éléments sont interconnectés au moyen de routes et de canaux. Le concept de route a été supprimé dans la dernière version de SDL (SDL-2000) [67]. Les canaux et routes peuvent être unidirectionnels ou bidirectionnels. Les routes sont réservées à la communication intra-processus tandis que les canaux peuvent être utilisés pour interconnecter des blocs entre eux et les blocs avec l'environnement du système. Les canaux peuvent être avec ou sans délai de communication, le délai étant aléatoire.

21

A La communication

Les processus communiquent via des signaux de manière asynchrone (non bloquant pour l’émetteur). Les signaux sont véhiculés par les canaux. Quand un signal est émis, il est transmis, via son canal, au bloc de destination. Sur un canal, l’ordre d’émission entre signaux est conservé. Par contre, si deux signaux arrivent en même temps ils sont traités arbitrairement. Quand un signal arrive sur un processus, il est mis en attente dans une file gérée selon le principe FIFO (premier arrivé/premier servi). Si le destinataire du signal n’est pas explicité via son PID (Processus IDentifier), le signal est consommé par la première des instances du processus pouvant le consommer. Dans l’exemple présenté à 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 donnée. Une donnée est toujours encapsulée dans un processus. Mais, il est possible de la rendre visible par un autre processus (View/Revealed). Par contre la donnée ne peut être utilisée que par les processus se trouvant dans le même bloc que la variable partagée. L’opération View n’a pas le droit de modifier la variable. L'autre mode de partage consiste à sauvegarder explicitement (mot clé EXPORT) une copie de la donnée 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

Légende : Système Bloc, sous-bloc

Canal Processus

[Signal]

Block appli Fig. 3.1-b

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

Signal en entrée Signal en sortie

Fig. 3.1-c

IActionneur

État Condition

Fig. 3.1 : Un spécification en SDL

B Concurrence

Les instances de processus (process en SDL) s'exécutent en parallèle. Dans un état donné, une transition consomme un ou plusieurs signaux, exécute selon des conditions des actions (tâche au sens SDL ou procédure) puis émet éventuellement un ou plusieurs signaux. Si deux instances de processus) sont tirables au même instant, aucune relation d'ordre n'est donnéedonnées a priori. Il n’existe pas de concurrence intra instance de processus.

22

C Comportement

Un processus SDL est une machine à états caractérisée par une file d’attente FIFO, des données, des signaux entrants ou sortants et un ensemble d’états reliés par des transitions. Un état particulier du processus est l’état de départ où se place l’instance de processus à sa création. Une transition est caractérisée par une condition de tir et un corps. La fin de la transition aboutit à un nouvel état (pouvant être le même que l’état précédent).

Une transition est tirée soit sur réception d’un signal, soit de manière aléatoire (transition spontanée). Ce dernier aspect est utile pour modéliser des systèmes non déterministes. Il est possible de lier une condition de validation (basée sur un calcul) à une transition. Dans un état donné, le signal pouvant être consommé (signal présent et condition de validation ok) est absorbé. Si le signal n’est pas attendu dans l’état courant, il est éliminé sauf s’il est explicitement sauvegardé (mot clé save). Si le signal est attendu mais que la condition de validation n’est pas validée, le signal reste dans la file d’attente.

Dans la transition, on trouve, en plus des actions et des envois de signaux, des créations d'autres processus. Les conditions permettent d’exprimer plusieurs chemins possibles pour une transition. Un état particulier est l’état de départ où se place l’instance à sa création.

Dans l’exemple de la figure 3.1-c, lorsque le processus commande est dans l’état inoccupé et qu’il reçoit un signal I, si les données véhiculées par le signal respectent une certaine condition changement, une procédure Calcul est exécutée afin de produire un nouveau signal O. Sinon le processus n’effectue aucune action et revient à l’état inoccupé.

D Signalisation temporelle et priorités

La signalisation temporelle se fait par l’activation ou la désactivation de timers. Un timer est déclaré au niveau d’un processus. Il peut être armé (set) et interrompu (reset). Lors de son initialisation, on associe au timer une date relative ou absolue d’expiration (la primitive NOW de SDL renvoie l’heure courante). On peut alors lui associer des données. S’il n’est pas désactivé, à la date d’échéance, le processus reçoit dans sa file d’attente un signal portant le nom du timer. Ce signal véhicule les données associées 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 n’est pas réellement lié à un aspect temporel. Mais il peut permettre de rendre un message plus prioritaire, et donc de prendre en compte des contraintes temporelles d’une application.

E SDL et les types

SDL n'est pas un langage orienté objet (OO) mais il contient des mécanismes nécessaires pour couvrir les concepts principaux de l'OO (classe, objet, méthode et héritage). Dans SDL, le type correspond à la classe, l'instance correspond à l'objet, les processus, procédures correspondent aux méthodes et le mécanisme de l'héritage simple correspond à l'héritage simple dans l'OO. Il est d'ailleurs possible de traduire un modèle 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 système type) peut être paramétré par des paramètres formels de contexte qui peuvent être un processus, une procédure, un signal, une variable, un

23

timer ou un type de donnée. A partir d'un type paramétré, d'autres types peuvent être crées en replaçant les paramètres formels de contexte par des paramètres réels de contexte.

SDL permet de spécialiser les types en utilisant le mot-clé inherits. Cette spécialisation permet d'obtenir un nouveau type qui hérite du comportement du type parent.

Ces aspects du langage sont très intéressants dans le cadre du développement. On peut ainsi spécialiser le langage pour un domaine cible particulier. La mise en place d’architectures types prédéfinies, évaluées et qualifiées assure la qualité de la spécification produite à partir de ces modèles génériques. Les types SDL peuvent permettre la définition de composants conceptuels pour la spécification de systèmes.

3.1.3.3 Caractéristiques du langage.

Par analogie à la présentation du langage SA-RT et UML, nous présentons le langage SDL suivant les mêmes aspects (formel, génie logiciel et temps réel). En ce qui concerne l'aspect formel, dès la définition SDL, nous avons mentionné que SDL est un langage formel. Nous présentons, d'abord, l'aspect génie logiciel puis nous présentons les travaux menés autour de l'aspect temps réel.

A Aspect génie logiciel

SDL est très bien adapté à la conception de réseaux, de protocoles, de systèmes répartis, réactifs et de télécommunication [85]. SDL permet d’avoir une démarche de haut niveau pour la spécification et permet la génération de code source, la simulation et la mise en place de preuves.

Le raffinement et l’abstraction sont assurés et défini par l'utilisation des éléments structurels de base que sont les types. Le concept objet a aussi été ajouté. Il est possible, en effet, de définir des objets (et des classes d’objet) avec leurs attributs et leurs méthodes [67] [179].

Par ailleurs, la lisibilité en SDL provient de la hiérarchisation du système.

B Aspect temps réel

a Introduction

SDL ne possède pas d’éléments de spécification clair et précis de l’écoulement du temps. Il ne fournit pas une description complète de la façon dont le modèle doit s’exécuter dans le temps [29]. Il est, par exemple, impossible d’assurer l’activation d’une transition d’un processus à une date précise via un timer. En effet, l’expiration du timer est considérée en SDL comme un signal classique. Par conséquent, la date de prise en compte de l’événement temps réel par l’instance de processus est liée au contexte de l’application (état de la boîte aux lettres où est déposé le signal) lors de son exécution.

De plus, à l’implémentation, chaque action prend un certain temps pour s’exécuter. Comme SDL ne spécifie pas comment le temps global se déroule, lors de la simulation d’un modèle SDL, l’hypothèse est de considérer que l’action s’exécute en temps négligeable ou quelconque. D’autre part, le temps que le processus prend avant de tirer sa prochaine transition est indéterminé.

24

En conclusion, il n'y a aucun moyen de vérifier (en l’état de la sémantique) si le modèle respecte bien les contraintes temps réel exprimées. Ceci pose un problème pour le développement et la validation des systèmes temps réel. De nombreux travaux ont été menés dans ce domaine selon plusieurs approches telles que les approches manipulant l'aspect de l'expression de temps et l'aspect d'ordonnancement.

b Modélisation du temps avec SDL.

Les travaux menés dans ce domaine peuvent être divisés en plusieurs approches. Dans la première approche (TSDL [31], QSDL [51] [68] [165]), on se propose d’enrichir SDL soit par addition des nouveaux éléments syntaxiques, soit par ajout de commentaires en notation formelle. Dans la deuxième approche, on couple SDL à un outil capable de combler ses lacunes au niveau de la modélisation du temps (par exemple de SDL vers les automates temporisés IF [28] ou UPPAAL [77] ). Nous présentons maintenant les formalismes TSDL, QSDL, IF et les travaux menés pour intégrer les concepts des automates temporisés en SDL.

b.1 TSDL

TSDL (Timed SDL) [31] [32] est une extension de SDL'88 pour prendre en compte les aspects temporels. L’objectif de TSDL est la vérification de propriétés temporelles. Il est à noter que TSDL, en se concentrant sur les aspects temporels, n'engendre que peu de modifications du langage SDL, ce qui lui permet d'être compatible avec de nombreuses spécifications existantes. Quelques restrictions sont pour autant apportées au langage, essentiellement au niveau de la structure (pas de bloc ou sous-bloc, pas de création dynamique de processus).

La modification portée à SDL consiste à ne pas associer la notion de temps de manière globale à un processus via les timers, mais aux transitions des processus. TSDL comprend plusieurs éléments syntaxiques qui permettent d’exprimer des contraintes probabilistes sur des transitions (TPROB) et des contraintes de temps (TRATE, TTIME : pour spécifier la durée de transition) sur les transitions. Ces contraintes peuvent manipuler des variables et donc être modifiées dynamiquement.

Il faut aussi noter que TSDL ajoute une extension pratique à SDL. La définition des données est autorisée au niveau du système. Enfin, TSDL apporte des constructions pour interroger l’état de la file d’attente des processus (taille de la queue, signaux présents dans la queue) et l’état des processus.

Une représentation TSDL peut être transformée en machine d'état équivalent. Cette transformation est assurée par un parseur qui est inclus dans l’outil TSDL. Ceci permet de ne pas être isolé de SDL et d'être compatible avec nombre de spécifications existantes.

b.2 Queueing SDL

Queueing SDL [146] (QSDL) est une autre extension de SDL dédiée à la spécification de systèmes distribués. QSDL se base sur des commentaires formels et l’usage de types prédéfinis. Les commentaires formels apportent des informations sur le modèle comme la limitation de la taille des files d’attente. Mais le point essentiel de QSDL reste la modélisation des performances. A cet effet, QSDL propose de modéliser les ressources nécessaires à l’exécution des processus SDL via des machines. Une machine offre des services aux processus SDL accessibles via des requêtes. Les requêtes sont des actions atomiques

25

utilisables dans les processus au même titre que les primitives de SDL. Une machine est caractérisée par une vitesse d’exécution et peut se composer de plusieurs serveurs pouvant s’exécuter en parallèle. Elle sert à modéliser le temps pris pour l’exécution d’une requête. Dans le cas de requêtes concurrentes, une machine est caractérisée par une politique d’ordonnancement des requêtes :

− FCFS (First-Come-First-Served) : politique premier arrivé - premier servi

− PS (Processus Sharing) : les requêtes sont réparties afin de partager équitablement la capacité du serveur

− IS (Infinite Servers) : chaque requête peut s’exécuter sans attente

− RANDOM : les requêtes sont prises au hasard dans la file d'attente

− FCFSPP (FCFS Priority-Preemptive) : les requêtes sont gérées par priorité en mode préemptif.

− FCFSPNP (FCFS Priority-Non-Preemptive) : les requêtes sont gérées par priorité en mode non préemptif.

Enfin QSDL se propose d’étendre SDL pour spécifier plus précisément l’écoulement du temps. Trois possibilités sont offertes par QSDL. La première concerne l’invocation d’un service d’une machine en utilisant la primitive QSDL request qui a pour effet de bloquer ou pas le processus. La deuxième est la mise en place d’états temporisés (mot clé AWAKE) qui a pour but d’activer une transition spontanée après un certain temps. Cet élément assure une prédictibilité temporelle dans le tir des transitions afin de pallier les lacunes du timer SDL. Enfin les signaux peuvent être retardés (mot clé DELAY) afin de modéliser le temps pris lors de la transmission d’un signal via un canal.

QSDL propose des générateurs aléatoires, qui couplés aux éléments précités, assurent la modélisation de l’écoulement du temps et de la durée des actions. Pour réaliser des mesures de performance, il existe des constructions prédéfinies par QSDL appelées sensor. L’outil QUEST, basé sur QSDL, analyse le graphe de couverture et permet de réaliser des évaluations de performances [145].

b.3 IF

IF est un modèle intermédiaire à base d'automates temporisés communicants, conçu pour la description et la validation formelle de systèmes asynchrones. Il existe deux versions d'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 sémantique opérationnelle bien définie et un maximum de support pour la validation formelle. IF apparaît comme une représentation intermédiaire entre SDL, ou d’autres langages de haut niveau, et les LTS. La syntaxe de IF est proche de celle d'SDL et il existe, de plus, un outil de traduction automatique SDL2IF. Enfin, la boîte à outils CADP propose de nombreux outils pour la vérification formelle [62] [203].

Principes de IF En IF, un système est constitué d'un ensemble d'automates temporisés qui communiquent

soit de manière asynchrone par envoi de signaux à travers des files d'attente, soit de manière

26

synchrone par rendez-vous aux portes de synchronisation. Par analogie à SDL, un processus IF est identifié par un nom unique qui est aussi son PID. Un processus possède une file d'attente et est constitué respectivement d'un ensemble de variables locales typées, incluant des horloges, d'un ensemble d'états de contrôle et d'un ensemble de transitions entre ces états.

IF2.0 propose des types de processus (process type), ce qui le rapproche d’un langage d'objet de modélisation 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 représentation « à plat » d’un modèle de type SDL. Nous présentons maintenant les différences fondamentales entre SDL et IF.

Au niveau des états, dans IF2.0, les états peuvent contenir des sous-états qui permettent de créer une hiérarchie d’état comme dans SDL2000.

Au niveau des données, dans IF2.0 les données peuvent être de type entier, booléen, flottant, PID et horloge. Ces données peuvent être déclarées locale ou globale (public).

Au niveau de la communication, alors qu’en SDL, lorsqu’un processus reçoit un signal non attendu ce signal est perdu ; en IF, le processus se bloque. Cette différence n’est pas fondamentalement gênante. D’abord parce que les outils comme ObjectGéode possèdent ObjectGEODE possède le même comportement que IF. Ensuite, par défaut, on peut considérer nécessaire d’expliciter le comportement d’un processus pour chaque signal reçu dans un état donné. Même si la transition ne possède aucune action et revient dans le même état, cette règle de modélisation ne peut qu’augmenter la qualité du modèle produit.

D’autre part, en IF 2.0, la transmission des signaux peut être perturbée via l’utilisation de Signalroutes. Ces dernières permettent d’introduire différentes affectations à la livraison des messages grâce aux options :

− Politique de stockage : FIFO ou multiset, où en FIFO la consommation des signaux se fait dans l’ordre de leur arrivée, en multiset, la consommation se fait de manière aléatoire.

− Politique de fiabilité : reliable ou lossy, les signaux peuvent ou non être perdus. ;

− Politique de livraison : peer, unicast ou multicast suivant le type de livraison des signaux désiré (respectivement à destination d’une instance d’un processus, de tous les processus vivants ou de toutes les instances d’un processus)(cf. figure 3.2) ;

− Politique de retard : urgent, delay[l,u] ou rate[l,u] suivant que l’on veut que la livraison des signaux soit immédiate, avec délai (entre l et u), qu’elle soit périodique ou pseudopériodique (la période étant bornée par l et u).

27

Fig. 3.2 : La politique de livraison des messages en IF 2.0

En IF, l’évolution du temps se fait de manière discrète. Pour modéliser les contraintes temporelles d’un modèle IF, les processus utilisent des horloges. Toutes les horloges du système évoluent de manière 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 accéder directement à la valeur de l’horloge (la conversion entre le type clock et le type integer est impossible). Par défaut, le comportement du système est de tirer une transition alors que ses contraintes temporelles sont validées. Cependant IF permet de définir des variations sur la date de tir d’une transition selon les paramètres (figure 3.3) suivants :

− Eager : la transition est prioritaire sur le temps. Le temps ne peut s'écouler tant que la transition n'a pas été tirée.

− Delayable : le temps est prioritaire sur la transition, c'est-à-dire que le temps peut s'écouler jusqu'à ce que la transition doive s’exécuter afin de respecter ses contraintes.

− Lazy : la transition a la même priorité que le temps, c'est-à-dire que l’on peut laisser le temps s’écouler ou tirer la transition.

IF permet de définir des comportements temporels plus fins que SDL, en particulier avec l’introduction de la notion d’intervalle de temps. Il peut être alors intéressant, dans le cadre d’une modélisation d’un système temps réel, de définir un comportement standard en SDL puis d’affiner le comportement temporel sur le modèle IF associé.

La figure 3.3 montre graphiquement l'utilisation de ces trois paramètres sur une transition IF entre deux états q0 et q1. Cette transition peut être tirée une fois le temps s'écoule entre 1 et 4 (1<X<4). Selon la variation définie sur la date de tir de cette transition (deadline), son franchissement peut avoir lieu comme présenté dans les trois diagrammes. Si le deadline est eager (en français : urgent), la transition est tirée une fois que la garde (1<X<4) est remplie, c'est-à-dire à l'instant X=2. Si le deadline est delayable (en français que l'on peut retarder), la transition peut être tirée à tous les instants où la garde est remplie, c'est-à-dire quand X = 2 ou 3. Enfin, si le deadline est lazy (en français fainéant), la transition peut aussi être tirée une fois que X est supérieur à la borne gauche de l'intervalle ] 1, 4[, c'est-à-dire pour X = 2, 3, 4 ….

28

Fig. 3.3. Les niveaux de priorités exprimées sur les transitions en IF 2.0

SDL2IF La traduction d'une modélisation faite en SDL vers sa correspondance en IF se fait au

travers d'un outil automatique intégré dans l'environnement IF. Par contre, comme SDL ne précise pas l'utilisation de temps, il est indispensable de transformer manuellement les aspects temporels, c'est-à-dire, fixer la sémantique temporelle. La figure 3.4 montre un exemple de traduction d'une modélisation en SDL à sa modélisation correspondante en IF.

Fig 10.b : Modélisation en IF Fig 10.a : Modélisation en SDL graphique

Dans la modélisation SDL (cf. figure 3.4. a), lors de la réception du signal E1, le signal S1 est envoyé et un timer notée T_repetition armé par un valeur (ici 5) puis le processus change son état à l'état attente. Dans l'état attente, deux transitions sont possibles. La première est à l'expiration du timer, donc la réception du signal T_repetition. Cette réception provoque l'exécution de l'action action_2, puis le réarmement du timer T_repetition. La deuxième

var T_repetition clock; State inoccupé; //état Input E1(); Output S1 () to destinataire0;//signal en sortie Set T_repetition : =0; // remet l'horloge à 0 Nextstate attente; Endstate; State attente; Input E2(); //signal en entrée Informal "action_1"; // label Reset T_repetition; Nextstate inoccupé; When T_repetition =5; //condition temporelle Informal "action_2"; Set T_repetition; Nextstate attente; Endstate;

Légende : Com : est un signal en sortie I : est un signal en entrée. T_repetition : est un timer de SDL inoccupé, attente : sont des états. action_1, action_2 : sont des labels.

Les mots en gras sont des mots clé d'IF

Fig. 3.4 : Traduction d'une modélisation SDL en IF

timer T_repetition;

inoccupé

E1

S1

SET (5,T_repetition)

attente

attente

T_repetition

"action_2"

SET (5,T_repetition)

attente

E2

"action_1"

RESET (T_repetition)

inoccupé

29

transition est franchie si le processus reçoit le signal E2. Sa réception initie l'exécution de l'action action_1 puis le timer est arrêté (reset T_repetition). La traduction de cette modélisation SDL en IF (cf. figure 3.4.b) est faite d'une manière automatique. Les états et les transitions SDL deviennent des états et des transitions en IF. En ce qui concerne le timer dans la modélisation SDL, il devient une horloge en IF (clock T_repetition). Ainsi, l'armement du timer et l'attente de son expiration (la réception d'un signal portant le même nom du timer) devient une initialisation d'horloge (set T_repetition = 0) et un invariant sur l'état où le signal doit recevoir (when T_repetition =5). Enfin, l'annulation du timer (reset T_repetition) devient l'annulation de l'horloge (reset T_repetition).

c L'ordonnancement

Les travaux menés dans ce domaine portent sur l'introduction de politique des aspects d'ordonnancement dans une spécification SDL. Le but de ces travaux est d'ajouter des propriétés fixes à des transitions [6]. Par la suite, nous présentons les travaux d'intégration des principes de RMA dans SDL.

c.1 SDL et RMA

Dans l’approche proposée dans [6] [7], la description de l’architecture du système s’appuie sur divers types de processus : les processus matériel, les processus logiciel et les processus pilote qui assurent l’interface entre le logiciel et le matériel. On distingue ensuite les processus actifs des processus passifs. Ces derniers sont des processus composés uniquement d’un ensemble de services accessibles par appel de procédure distant. Ils modélisent les ressources partagées. Les processus "matériel" sont, par exemple, des processus passifs, alors que les pilotes sont des processus actifs.

L’approche se concentre ensuite sur la gestion des priorités qui est un point clé d’une implémentation temps réel. L’objectif affiché de l’étude est la mise en place d’une analyse temporelle de type RMA à partir du modèle SDL. Les contraintes temporelles sont liées aux événements externes. Lorsqu’un événement externe survient, un ensemble d’actions est déclenché selon des contraintes temporelles données. Dans un modèle SDL, les actions sont liées aux transitions des processus et déclenchées par l’arrivée de signaux. Par analogie aux messages dans les modèles objet temps réel définis par [181][33 , les signaux véhiculent donc les contraintes temps réel.

Selon les principes de RMA, la prise en compte des contraintes temps réel, telles que les délais, se fait avec la détermination des priorités des actions calculées selon des algorithmes d’ordonnancement [112]. L’approche propose, d'une part, d’associer un niveau de priorité fixe à chaque transition. On assure ainsi que chaque action est exécutée au niveau de priorité requis par les algorithmes d’ordonnancement.

D'autre part, l'approche propose d'ajouter des estampilles temporelles pour les signaux. Chaque signal possède un champ sending_time et reception_time précisant respectivement le moment du départ et le moment d'arrivée du signal.

Enfin, l'approche propose une méthode pour déterminer le temps de réponse au pire cas à un stimulus. Le temps de réponse au pire cas d'un chemin d'exécution est la somme de temps de réponse au pire cas pour chaque transition qui compose ce chemin. Afin de calculer le temps de réponse d'une transition, il faut prendre en compte le temps de blocage d'une

30

transition par une autre plus prioritaire plus le temps de l'exécution de cette transition [46] [166].

3.1.3.4 Discussion

SDL est un langage standardisé qui possède de nombreux supports. Ses extensions temporelles ont permis d’enrichir le langage pour prendre en compte les contraintes temporelles et assurer des mesures de performances.

Les travaux de recherche présentés précédemment se concentrent sur la modélisation du temps dans SDL. Certains travaux proposent d'ajouter une sémantique temps réel à SDL. D'autres approches proposent de joindre SDL à des langages ou formalismes permettent de vérifier formellement la spécification tels que SDL / IF et SDL / RMA. L'approche OMT / SDL [100] se focalise sur l'amélioration de SDL au niveau des aspects génie logiciel par l'introduction de l'approche objet.

Nous présentons maintenant les travaux de recherches autour des langages de conception.

31

3.2 Langage de conception

Lors de l'implémentation d'un système temps réel, deux approches sont possibles. Dans une première approche, l'implémentation peut s'appuyer sur des outils classiques standards (langage C/ C++ et quelquefois l'assembleur) et des exécutif multitâches temps réel tels que iRMX® [86], VxWorks® [190], POSIX [193]. En revanche, dans une deuxième approche, l'implémentation peut s'appuyer sur des langages dédiés. Parmi ces langages, Ada et Java [201] peuvent être utilisés à profit dans le développement des systèmes temps réel. Ces langages incluent les notions de tâches et des primitives de synchronisation car ils s’appuient directement sur les services de l’API (Application Program Interface) du système d’exploitation.

Afin se s'abstraire des détails d'implémentation et de ne pas se lier à une plateforme cible précise, des langages de haut niveau dit de conception ont été proposés.

Nous étudions maintenant des langages utilisés pour la conception tels que LACATRE [161], SDL-RT [175], UML-RT [124] et ROOM [171].

3.2.1 LACATRE

LACATRE [158] [159] [160] (Langage d’Aide à la Conception d’Applications Temps REel) est un langage graphique dédié à la description des objets élémentaires utilisés dans les exécutifs multitâches temps réel. LACATRE est un langage, présentant un modèle graphique et un modèle textuel destinés à faciliter la conception préliminaire et détaillée d’application basée sur la mise en œuvre d’exécutifs multitâches temps réel. LACATRE fait un usage intensif et rigoureux (grammaires) du symbolisme graphique pour la représentation des mécanismes de communication / synchronisation, permettant ainsi de donner une vision synthétique, et précise à la fois, de l’application multitâche.

Le langage LACATRE se présente comme une surcouche aux exécutifs temps réel. Il opère ainsi sur des entités qui sont en partie l’image des objets manipulés par les exécutifs multitâche temps réel, avec quelques extensions. Ces entités appelées les objets LACATRE, sont : la tâche, les routines, le sémaphore, la boîte aux lettres, le message, l’évènement, la ressource, l'alarme et l’interruption. Un schéma LACATRE est un ensemble d'objets de LACATRE qui sont reliés par des primitives LACATRE. Ces objets sont des objets configurables et les objets programmables.

Les objets configurables de LACATRE sont les objets dont le comportement est parfaitement défini après avoir configuré leurs paramètres de fonctionnement. Les paramètres de configuration permettent, par exemple, la définition du mode de gestion des files d’attente des boîtes aux lettres. Les objets configurables de LACATRE sont le sémaphore, la boîte aux lettres, le message, l’évènement, la ressource. Les objets configurables ne connaissent que deux états : inexistant (avant création et /ou après destruction) et existant (après création).

Les objets programmables ont un comportement qui doit être défini par le programmeur sous forme de séquence d’appel de primitives LACATRE. LACATRE possède trois objets programmables / la tâche, la routine d'interruption et la routine d'alarme. Ceux-ci possèdent deux états actif et inactif. L'état actif est l’état dans lequel l’objet programmable est en mesure d’exécuter des primitives LACATRE.

32

Les primitives LACATRE sont les relations que le programmeur d’application à sa disposition pour créer des liens entre les objets LACATRE.

Au niveau des outils, des études menées ont permis d'associer LACATRE aux cibles iRMX [161], WIN 32 [14] et VxWorks [198].

Au niveau de la formalisation, plusieurs études ont été réalisées pour valider la conception faite en LACATRE. L'idée est ici de coupler LACATRE pour une cible donnée à un formalisme outillé comme CRSM [128] ou IF [37]. Dans ces travaux l'ensemble de l'application est modélisé (environnement, OS, données, application). Ce modèle est alors utilisé pour vérifier des propriétés (vivacité, sûreté de fonctionnement et propriétés temps réel).

Dans la figure 3.5, nous montrons un exemple d'un système composé de deux tâches (tâche_1, tâche_2) mettant en œuvre une communication par qui communiquent via une boîte aux lettres et un sémaphore. La tâche tâche_1 crée, au départ, le sémaphore puis la boîte aux lettres et enfin la tâche tâche_2. Puis, elle dépose un message dans la boîte aux lettres (bal_1), puis elle attend sur le sémaphore sem_1. La tâche tâche_2 récupère un message de la boite bal_1 puis il dépose un unité dans le sémaphore sem_1. La tâche tâche_1 est alors débloquée suite à ce dépôt, elle détruit alors le sémaphore sém_1, la boîte aux lettres bal_1, la tâche tâche_2 et enfin elle-même.

Légende

Sémaphore boîte aux lettres

Tâche Message

Création Destruction

tâche_2

210tâche_1200

sem_1

bal_1

Msg

Fig. 3.5 : Deux tâches communiquant via un boite aux lettre et un sémaphore selon le formalisme LACATRE

3.2.2 SDL-RT

SDL-RT (Specification and Description Language - Real Time [175] ) est une extension temps réel du langage SDL. SDL-RT introduit les concepts manquants dans SDL pour l'implémentation d’applications temps réel.

33

Au niveau de la distribution du code, SDL-RT introduit la notion de diagramme de déploiement avec les nœuds et les connexions (lien physique) ainsi que la notion de composant.

Au niveau du modèle d’exécution, un niveau de priorité est associé à chaque processus qui peut être redéfini pour chaque instance. L’instance de processus est donc une tâche au niveau du système d’exploitation. Pour la gestion du temps, l’unité de base des timers est le tick.

Enfin, afin de produire une implémentation efficace, le langage d’action proposé par SDL-RT est le langage C. Il est donc possible, en particulier de manipuler des pointeurs et de déclarer des variables globales. Ces dernières doivent être protégées par l’utilisation explicite de sémaphores fournis par SDL-RT.

Un outil (Real Time Developer Studio) [149] a été développé et permet de générer le code complet de l’application à partir de la description SDL-RT en intégrant les appels aux primitives des systèmes d’exploitation classiques et des exécutifs temps réel.

Il est à noter que la transformation d'un modèle SDL vers un modèle SDL-RT n'a pas été formalisée.

3.2.3 Autre langage de conception

La langage ROOM [171] fournit des facilités temporelles qui permettent d’introduire des comportements temporels comme les délai, les timeouts. ROOM introduit une nouvelle représentation qui est le diagramme de structure, qui permet de décrire la structure d’une agrégation d’objets et surtout l’interconnexion de ces objets. ROOM n’est pas un technique de description formelle et il n’y a pas des possibilités pour inclure des phases automatiques de validation à partir de la conception.

UML-RT [124] [157] [70] une adaptation de ROOM, il présente un type spécial d'objet actif, appelé capsule, avec des règles de connexion qui spécifient une sémantique particulière. Chaque capsule interagit avec les autres par des messages passant des mécanismes de ports. Mais malheureusement cette méthodologie n’autorise pas la validation et il y a nombre limité d’outils. Le modèle de calcul d'UML-RT est basé sur l'hypothèse RTC (Run To Completion) pour chaque capsule. Un modèle logique d'UML-RT consiste en un certain nombre de capsules. L'implémentation de ces capsules sur un exécutif temps réel (ETR) multi-tâches peut être fait avec plusieurs méthodes. L'outil RoseRT, propose de regrouper une ou plusieurs capsules par une tâche à priorité fixe. Les travaux menés dans [124] sont similaires à ceux de RoseRT [192] au niveau du regroupement des capsules dans une tâche, mais avec l'attribution des priorités dynamiques. Une troisième approche a été proposée dans [157] afin de planifier chaque scénario d'application dans une tâche. Par contre les priorités sont attribuées statiquement.

3.2.4 Discussion

LACATRE est langage de conception et de programmation multitâche. Il est très proche de l'implémentation. Ce dernier permet de générer du code exécutable pour plusieurs types de cibles (iRMX, VxWorks, Win32). Une lacune importante concerne la prise en compte des aspects temps réel et formels.

34

Par contre, LACATRE fournit une boîte à outils de haut niveau pour le concepteur/programmeur du système temps réel et permet de s'abstraire des détails d'implémentation.

SDL-RT est une extension temps réel intéressante du langage SDL qui permet de spécifier les contraintes de temps réel. Il permet d'associer des priorités à chaque instance de processus et permet de générer un code C. Par contre, SDL-RT n'est pas formalisé.

3.3 Conclusion générale de la partie langages.

Les travaux de recherches sur les langages de spécification et conception portent sur plusieurs points.

Dans un premier temps, les approches liées à UML focalisent sur la spécialisation du langage pour le domaine en utilisant des stéréotypes et de profils. Des approches proposent des sémantiques formelles en particulier temps réel. Le but de ces approches est de vérifier des propriétés pour chaque modèle (spécification et conception). Ces approches proposent soit des phases de se basent sur une traduction SDL/UML, OMT/SDL et Z.1009. Enfin des études portent sur le mappage entre la spécification et la conception.

Au niveau de la conception, des approches proposent des vues de haut niveau de l'implémentation afin de faciliter la mission du concepteur. Cette vue cache les détails de l'implémentation, ce qui permet au concepteur de se concentrer sur l'architecture. Ces approches proposent des boîtes à outils qui s'appuient sur des boîtes grises à instancier lors de la conception.

Nous présentons maintenant, l'aspect validation des systèmes temps réel et les travaux de recherche liés à cet aspect.

35

4 Validation et vérification Après avoir étudié les langages de spécification et de conception, nous présentons dans ce

chapitre, les langages et les techniques pour la vérification et la validation des systèmes temps réel.

D'après le paragraphe 1.2.3, il est nécessaire de vérifier la conformité des modèles lors d'un raffinement sur la base des propriétés d’un modèle. Ces propriétés concernent les aspects fonctionnels, comportementaux et temps réel. Pour les aspects comportementaux, nous présentons maintenant les techniques de conformité de modèle basées sur la notion d'équivalence [121] [60] et les techniques de vérification de propriétés basées sur le model-checking [104] [119]. Pour les aspects temps réel, nous présentons la méthode classique RMA.

4.1 Vérification comportementale

Dans la suite, nous présentons, tout d'abord, la relation d'équivalence. Ensuite, nous présentons la technique du model-checking.

4.1.1 Relation d'équivalence

La première étape dans la vérification formelle d'un système est la construction d'un modèle formel du comportement de l'application [60] [61] [121]. Les langages de spécification, sont des modèles de haut niveau. En d'autres termes, ce sont des formalismes simplement syntaxiques, tout comme des programmes en langage de haut niveau, qui, néanmoins, doivent être compilés pour obtenir le code résultant. La sémantique d'un programme de haut niveau est habituellement décrite en termes d'états possibles du système, aussi bien que par ses transitions possibles (permettant le changement d'un état à l'autre). Cette structure s'appelle un système de transitions étiquetés (LTS : Label Transition System), où les étiquettes annotent les transitions représentent l’occurrence des événements ou actions.

4.1.1.1 Système de transitions étiquetées (LTS) :

Un système de transitions étiquetées S est un tuple , où ⎟⎟⎠

⎞⎜⎜⎝

⎛

⎭⎬⎫

⎩⎨⎧ ⎯→⎯ 0q,,,Q Σ

1. Q est l’ensemble des états du système, 2. ∑ est un alphabet (étiquettes des événements et des actions),

3. est la relation de transition de S. on note telle que s⎟⎠⎞

⎜⎝⎛ ∑⊆⎯→⎯ Q x x Q 2sa

1s ⎯→⎯ 1 et s2

deux états de Q et Σ∈a . 4. et q0 ∈ Q l’état initial.

Un LTS définit implicitement un arbre d'exécution qui correspond au dépliage de ce système à partir de l'état initial.

Définition de la relation d'équivalence Il existe en fait plusieurs relations d'équivalence dédiées à la vérification de spécification

comportementale : la bisimulation forte [26] [42] [61], la bisimulation faible [121], la bisimulation de trace [36], la F-simulation [150], etc.

36

4.1.1.2 Bisimulation forte

Intuitivement, deux états p et q sont bisimilaires fortement (notée p ~ q) si pour chaque état p' accessible de p par l'exécution de l'action a ( ), il y a une état q' accessible de

l'état q par l'exécution de l'action a tel que p' ( ) et vice-versa.

pap ′⎯→⎯

qaq ′⎯→⎯

Deux LTS (S1 et S2) sont fortement bisimilaires noté S1 ~ S2, s'il existe une relation de bisimulation forte entre tous les états du système.

La figure 4.1 montre deux LTS correspondant au même alphabet (a [b | c] ) qui ne sont pas bisimulables. En effet, dans l'état S1 seule transition b est tirable. Par contre dans l'état S'

1 deux transitions b et c ne sont tirables que les transitions b et c.

Fig 4.1. Deux LTS non fortement bisimulable correspondant au même alphabet a [b | c]

4.1.1.3 Bisimulation faible

Nous définissons une action observable comme suit :

( ) q)*(a)*(p définit q a

p ⎯ →⎯⎯ →⎯⎯ →⎯⇒ ττ

Où a est une action observable et τ est une action inobservable. C'est-à-dire à partir de l'état p, il existe une séquence d'événements, contenant l'action observable a, et qui mène à l'état q.

Par analogie, deux états p et q sont bisimilaires faibles (noté p ≈ q) si pour chaque état p'

accessible de p par l'exécution de l'action a ( ), il y a une état q' accessible de l'état q par

l'exécution de l'action a tel que p' ( ) et vice-versa.

pa

p ′⇒

qa

q ′⇒

Deux LTS (S1 et S2) sont faiblement bisimilaires (noté S1 ≈ S2) s'il existe une relation de bisimulation faible entre tous les états du système (figure 4.2).

37

Plusieurs logiciels pour la vérification comportementale basés sur ces approche de bisimulation ont été réalisés à ce jour (ALDEBARAN [61], AUTO [163] ). On trouvera une représentation et une comparaison détaillée de la plupart de ces logiciels dans [84] [97].

τ

Fig. 4.2: Deux LTS faiblement bisimulables.

4.1.1.4 F-simulation

Une autre approche a été présentée dans [150] afin de pallier le problème de la relation d'équivalence. Dans cette approche, les auteurs proposent un nouvelle approche de relation d'équivalence nommé F-simulation afin de vérifier la notion d'équivalence entre une spécification et une conception. Informellement, une conception est équivalence (F-simulation) à une spécification, si et seulement si le LTS de conception engendre le même comportement que le LTS de la spécification après une certaine séquence d'événements.

Dans la figure 14, nous montrons deux LTSs qui représentent la spécification (S1) et la conception (S2). D'après la relation de F-simulation les deux LTSs sont équivalent car le LTS de conception (son état initial est sd) produit le même comportement que le LTS de spécification après une séquence de labels ou événements (b b a) (cf. figure 4.3). Donc les états sf et sd sont équivalents.

Fig. 4.3 : La relation de F-simulation.

En dehors de l'équivalence forte, la notion d'équivalence dépend du domaine et peut être spécialisée.

38

4.1.2 Model-checking

Des propriétés comme l'absence de blocage (deadlock) ou la vivacité peuvent être vérifiées en exploitant directement le LTS. Néanmoins pour d'autres propriétés plus complexes concernant les propriétés dynamiques de l'application, on utilise des langages de logiques temporelles telles que CTL (Computational Tree Logic) [45], et LTL (Linear Temporal logic) [53], et CTL* [76]. L'intérêt de ces logiques est qu'elles permettent de spécifier des propriétés dans un formalisme logique de haut niveau.

Les propriétés temporelles sont généralement la sûreté de fonctionnement (quelque chose de mauvais n'arrive jamais) et la vivacité (quelque chose de bon est toujours possible) d’un système temps réel. Brièvement, la logique temporelle est une extension du calcul des prédicats avec des opérateurs temporels qui expriment des relations entre les occurrences des temps d’événements. Ce formalisme est utilisé dans le cadre des systèmes réactifs, c’est-à-dire ceux où le logiciel est censé maintenir une relation de cohérence entre la suite des flux d’entrée et celle des flux de sortie.

Après avoir modélisé le système, par exemple, par un LTS et les propriétés par une logique, on applique des techniques telles que model-checking [1] [75] afin de vérifier ces propriétés. Dans la suite, nous présentons le model-checking.

4.1.2.1 Le principe du Model-checking

En fonction de la logique temporelle employée pour exprimer les priorités à vérifier, plusieurs types de model-checking sont effectués tels que model-cheking de LTL [53] ou model-cheking de CTL [144].

Le principe général du model-checking peut être présenté comme suit. La formule de logique temporelle (par exemple LTL [16] ) est traduite en un système de transitions (automate de Büchi [54] ) qui est composé (synchronisé) avec le modèle du système. L’exploration exhaustive de l’espace d’états du système de transitions global permet de répondre formellement à la question : le modèle vérifie t-il la propriété ?

Un inconvénient majeur réside dans l'explosion combinatoire qui limite dans la pratique l'utilisation de ces approches : l'espace d'états accessibles est trop grand pour être construit. Trois directions complémentaires peuvent être suivies pour tenter de résoudre ce problème [21] :

− La prise en compte de symétries tant au niveau architectural qu'au niveau des données manipulées peut offrir une réduction importante de l'espace d'états,

− Les techniques dites « d'ordre partiel » qui tentent d'éviter la part d'explosion combinatoire due à la représentation du parallélisme par l'entrelacement d'actions permettent dans de nombreux cas d'éliminer le facteur exponentiel.

− De même, les techniques de vérification à la volée permettent de guider l'exploration et d'en limiter l'explosion.

Les techniques de model-cheking sont exploitées par plusieurs outils, comme SPIN [66], SMV [120], etc.

39

Des langages de spécification ont aussi été définis afin de permettre d'exprimer des propriétés intégrant les contraintes temps réel sur les délais comme les automates temporisé [3] et les logiques temps réel (RTL) etc. Nous présentons maintenant ces modèles.

4.2 Vérification temps réel

En fait, la vérification comportementale est limitée à vérifier des propriétés logiques d'un système temps réel. En ce qui concerne la vérification de propriétés temps réel, plusieurs approches sont possibles. Dans une première approche, il est possible d'utiliser des langages formels ou des formalisme dédiés à la spécification des contraintes temps réel tels que les automates temporisés, le langage de RTL (Real Time Logic), les machines à états finis temporisés. Dans une deuxième approche, il est possible d'utiliser des techniques dédiées à la validation telle que l'analyse d'ordonnançabilité de type RMA (Rate Monotonic Analysis).

4.2.1 Les automates temporisés

Les automates temporisés ont été introduits par Allur et Dill [2]. Il s'agit d'automates classiques munis d'horloges qui évoluent de manière continue avec le temps. Chaque transition contient une garde indiquant quand la transition peut être exécutée et un ensemble d'horloges remises à zéro lors du franchissement de la transition.

Formellement, l’automate temporisé peut se définir par un sextuple (Q, ∑, C, T, Inv, x0) où :

− Q est un ensemble fini d'états et x0 est l'état initial.

− ∑ est un ensemble de labels.

− C est un ensemble de variables d'horloges.

− T⊆ Q x ∑ x C x Q est un ensemble de transitions. Une transition s ∈ T est de la forme s =(x1, α, g, r,x2) qui représente la transition de l'état x1 à l'état x2. α est le label, g est la condition sur l'horloge et r définit l'ensemble d'horloges à reseter.

− Inv est une fonction qui marque chaque état x ∈ X avec quelques contraintes sur l'horloge.

Les automates temporisés permettent de modéliser des systèmes temps réel. Il est aussi nécessaire de définir des langages de spécification ou des logique qui permettent d'énoncer des propriétés temps réel. De ce fait on peut utiliser des logiques telles que Real Time Logic (RTL) [88], Timed Computational Tree Logic (TCTL) [3], Metric Temporal Logic (MTL)[148] afin d'exprimer ces propriétés. Dans la suite, nous allons présenter RTL comme un type de logique temps réel.

4.2.2 La logique temps réel

La logique temps réel est un langage formel qui permet de spécifier des contraintes temps réel [88].

La logique RTL [88], voit un système temps réel comme un ensemble d'événements et d'actions. Les événements sont classés en trois types : les événements internes sont tels que

40

les événements qui marquent le début et la fin des actions et les événements liés au changement des valeurs des attributs du système. Les événements externes sont échangés avec l'environnement du système. Chaque événement possède un nom et un certain nombre d'occurrences. Chaque occurrence d'événement est caractérisée par un instant. Ce dernier est un entier ℕ qui représente la date absolue de l'occurrence de l'événement.

La fonction d'occurrence est notée par le symbole @ où @(E, i) détermine la date de l'ième occurrence de l'événement E.

Les notations utilisées pour les événements liés aux actions sont ↑A et ↓A qui marquent le début et la fin de l'action respectivement. La même notation s'applique aux actions composites, ainsi ↑B.A marque le démarrage de la sous-action A de l'action composite B.

Pour les événements de transition du système, on assume que chaque état S variable est représenté par un paire d'événement (S : =T) et (S : =F) qui alternent entre la valeur (T) et (F) en marquant le changement de valeur de cette variable d'état.

Les événements externes sont notés par des lettres majuscules précédées par la lettre oméga. Par exemple, ΩIT indique l'événement externe IT.

A partir du modèle événement–action, une contrainte d'échéance sur l'activation apériodique peut être notée comme suit :

Lorsque l'événement ΩE survient, l'action A est exécutée avec une échéance d, et un délai de séparation p.

Cette contrainte peut être spécifié en RTL par les propriétés :

∀ i ∃ j @(ΩE,i) ≤ @(↑A, j) ∧ @(↓A,j) ≤ @(ΩE, i) + d

∀ i @(ΩE, i) + p ≤ @(ΩE, i+1).

Une fois les propriétés temps réel spécifiées, l'accent est mis sur le problème de la vérification de ces contraintes. Plusieurs travaux ont été développés pour assurer la vérification de contraintes temps réel. Le travail mené dans [89] [90] propose des algorithmes pour vérifier les assertions de sûreté. De plus, l'outil Modechart [91] a été développé, qui permet de spécifier des assertions temps réel et de vérifier si ces assertions sont violées ou pas [89] [90].

D'autres logiques temps réel comme TCTL [3] [4] ont été développées afin d'exprimer des propriétés temps réel. Etant donné un système temporisé (LTS) et une propriété exprimée en TCTL, il reste à trouver un algorithme afin de vérifier cette propriété. Il n'est pas possible d'utiliser directement les algorithmes standard de model-checking car le LTS temporisé correspondant à l'automate contient un nombre infini d'états [103]. Une solution possible serait d'abstraire le LTS en système de transition fini vérifiant les mêmes propriétés. De ce fait, une approche de model-checking temporisé est proposée pour vérifier les automates temporisés. Plusieurs outils sont proposés afin d'exploiter cette approche telles que UPPAAL [102], KRONOS avec des propriétés exprimées en TCTL [185] et l'outil HCMC [104] qui permet de vérifier des propriétés exprimées en logique modale temporisée.

41

En fait, les approches et les formalismes étudiés précédemment sont des techniques qui peuvent être utilisées pour spécifier puis vérifier la correction des contraintes temps réel exprimées.

Dans notre étude, nous nous intéressons aux implémentations multitâches (cf. 1.3.3). Or à ce jour, peu des techniques formelles basées sur les automates s'appliquent à l'implémentation multitâche. En effet, les modèles à automates ne gèrent pas les notions de priorités et de préemptions typiques des implémentations considérées. On peut citer les travaux menés dans [16] et [37] mais il n'existe pas à ce jour d'outil qui implémente ces principes. On peut aussi citer le travail mené dans [37]. Ce travail propose des principes pour valider des implémentations temps réel multitâches, mais également cette approche ne propose pas d'outil. Pour valider une implémentation multitâches, classique dans les systèmes temps réel, des méthodes d'analyse dédiées ont été développées. Elles se basent sur les techniques d'ordonnancement dédiées à la gestion de concurrence entre tâches [105]. Nous présentons RMA qui est une approche classique pour valider des implémentations multitâches.

4.2.3 Techniques dédiées à la validation des système temps réel

Au niveau de l'implémentation, la validation des systèmes temps réel impose de vérifier que les tâches respectent leurs contraintes temps réel. Des techniques analytiques spécifiques sont dédiées aux système temps réel ont été conçues pour répondre à cet objectif. Donc, il s'agit de répondre à la question le système respecte-t-il toutes ses contraintes temps réel. De nombreuses techniques permettent de calculer les pires temps de réponse [47]. Dans le cadre de l'ordonnancement à priorité, ces méthodes ont été regroupées sous le nom d'analyse RMA (Rate Monotonic Analysis).

4.2.3.1 Principes

RMA [98] (Rate Monotonic Analysis) est un ensemble de techniques mathématiques qui permettent à des développeurs des systèmes temps réel de répondre à des exigences temps réel d'applications.

La majorité des travaux sur les techniques d’analyse d’ordonnançabilité [80] [107] [108] [109] [167] [189] considèrent une politique d’ordonnancement des tâches préemptive, à priorités (fixes le plus souvent, parfois dynamiques). Elles se singularisent principalement par les caractéristiques de la configuration des tâches qu’elles prennent en considération. Selon les critères retenus pour l’établissement du modèle canonique des tâches, des conditions nécessaires, suffisantes, et nécessaires et suffisantes d’ordonnançabilité ont pu être démontrées.

D’autre part, des algorithmes optimaux d’attribution des priorités aux tâches ont été définis pour certaines classes de problèmes. Ainsi, l’algorithme RM (pour Rate Monotonic qui attribue les priorités aux tâches dans l’ordre inverse de leurs périodes [65] ) est optimal pour les systèmes constitués de tâches périodiques, indépendantes, à échéance sur requête (le délai est égal à la période) et à départs synchrones (la première activation à la date t = 0 pour toutes les tâches), ordonnancés par un ordonnanceur préemptif à priorités fixes. L’adjectif optimal désigne le fait que sous ces hypothèses, si le système est ordonnançable, alors les priorités attribuées par RM produisent un ordonnancement valide.

Classiquement le modèle temporel d'une tâche (cf. figure 4.4) est définie par :

42

− Sa date de première activation ri.

− Son temps d’exécution au pire cas Ci.

− Sa période (le temps minimum entre les invocations successives) Τι.

− Son échéance relative à son réveil Ri.

− Sa priorité (dans le cas de politique d'ordonnancement à priorité fixe).

Ce modèle est illustré par la figure ci-dessous :

Ti Ti Ti

Ri

Ci RiRi

Temps

Début de l'exécution

Fin de l'exécution

Réveil

Fig. 4.4 : le modèle temporel d'une tâche

Le modèle de RMA des systèmes temps réel est basé sur les notions classiques de ressources, d’événements et d’actions comme décrit dans [98]. Les ressources représentent les éléments élémentaires de matériel sur lesquels ces actions s'exécutent. Une ressource peut être soit physique soit logique :

− La ressource physique peut être un processeur (CPU), un réseau (Bus CAN, Bus Ethernet), une carte mère, etc. Les propriétés associées à une ressource donnée sont en général dépendantes du type de la ressource. Le CPU est caractérisée par son nom, le type de politique d'ordonnancement qui peut être RM (Rate Monotonic), DM (Deadline Monotonic), FP (Fixed Priority) ou HKL (Harbour, Klein et Lehoczky) [82].

− La ressource logique est un buffer ou une mémoire partagée. Ce type de ressource est caractérisé par son nom et sa politique d'ordonnancement qui peut être FIFO (First In First Out), PIP (Priority Inheritance Protocol), PCP (Priority Ceiling Protocol) ou HLP (Highest Locker Protocol).

Selon [98], les événements peuvent être classés en trois types. Les événements externes du système, les événements internes du système et les événements temporels (expiration d'un timer). Chaque événement est caractérisé par son nom, son type d'arrivée (périodique, sporadique), sa période d'arrivée, son échéance et la liste des actions à déclencher.

En ce qui concerne les actions, chaque action est caractérisée par son temps d'exécution normal, la ressource physique où l'action va l'exécuter, la liste de ressources logiques à utiliser, son niveau de priorité (dans le cas de priorité fixe) et son temps d'exécution au pire cas (WCET).

43

4.2.3.2 Vérification des implémentations multitâches

Classiquement, un événement dans le modèle RMA correspond à un événement externe. Chaque événement déclenche une séquence d'actions, chaque action est liée, dans l'implémentation à une tâche qui lui donne sa priorité.

A chaque événement est associé un délai. La vérification des applications multitâches est faite par le calcul du pire temps de réponse. La validité d'une application multitâche, est toujours basée sur le pire cas donc le pire temps d'arrivée des événements et la pire durée d'exécution si la durée d'exécution est variable.

Dans la suite, nous rappelons les équations utilisées d'abord pour tester l’ordonnançabilité du système via le calcul du pire temps de réponse.

A Charge de processeur

Une condition nécessaire d’ordonnançabilité pour le modèle de tâches présenté ci-dessus consiste à vérifier que la charge produite par le système est inférieure ou égale à 1 :

( )( )∑

=

n

1i iTiC

Pour un ordonnanceur préemptif à priorités fixes et pour le modèle temporel de tâche présenté ci-dessus, une condition suffisante d’ordonnançabilité du système par l’algorithme RM est :

( )( ) ( ) ⎟

⎠⎞⎜

⎝⎛ −=≤

=∑ 1n/12nnUn

1i iTiC

B Temps de réponse (pour une action)

Le calcul du pire temps de réponse est basé sur résultats théoriques de [109] [112]. Selon RM, l’équation ci-dessous caractérise le temps de réponse d’une tâche (an) pour le modèle de tâche considéré (cette équation reste vraie lorsque les échéances des tâches sont inférieures à leurs périodes) :

j C1i

1J

Tjna

iC1na

i

1jjC0a

∑

∑−

=⎥⎥

⎤⎢⎢

⎡+=+

==

a0 est la première approximation de temps de réponse qui représente la somme des temps d'exécution associés à la séquence d'événement ei et toutes les séquences plus prioritaires.

Dans le cas de la présence de sections critiques ou des ressources partagées par les tâches, le temps de réponse peut être calculé par l'équation suivante (cette équation est vraie lorsque les échéances des tâches sont variées) :

44

j C1i

1J

Tjna

iCiB1na

i

1jjCiB0a

∑

∑−

=⎥⎥

⎤⎢⎢

⎡++=+

=+=

La pire durée de blocage d'une tâche, associée à un protocole donné est définie par Bi (nous renvoyons à [98] pour la détermination pratique de Bi pour les protocoles d'accès aux ressources les plus utilisés).

Les calculs utilisés permettent de prouver le système du point de vue temps réel. Par exemple, RMA, en s'appuyant sur un modèle statique et en évaluant une borne du pire temps d'exécution pose le problème du réalisme.

RMA est une approche analytique qui peut être employée avant l’intégration de système pour déterminer si les besoins temps réel seront satisfaits, elle peut avoir comme une conséquence l’épargne dans des ressources de système et le temps de développement.

4.2.4 Discussion

Nous avons présenté, dans cette partie, quelques travaux de recherche portant sur la validation et la vérification. Ces travaux garantissent d'une part la cohérence et la validation de chaque phase dans le cycle de développement, et d'une autre part, la correction du développement.

L'utilisation de la relation d'équivalence et le model-checking permettent d'assurer la validité de l'aspect comportemental des modèles. La validation temps réel est assurée à plusieurs niveaux. Au niveau de la spécification et de la conception, la validation de ces deux modèles peut être assurée en utilisant des logiques temps réel telle que RTL et des outils dédiés. Au niveau d'implémentation, les techniques d'ordonnancement garantissent la cohérence des contraintes temps réel.

45

4.3 Conclusion

Le développement de systèmes temps réel s'appuie sur des étapes de spécification, conception et implémentation dont les contraintes temps réel doivent être exprimées à chacune de ces étapes. Ce développement doit répondre à la principe exigence : la sûreté de fonctionnement.

Lors de la spécification, nous avons mentionné SA-RT qui est un langage informel, très répandu et très utilisé pour spécifier les systèmes temps réel. Par contre, peu de travaux menés s'appliquent à fixer une sémantique et une formalisation au langage. Le langage OO UML est langage semi-formel, standardisé par l'OMG. Plusieurs travaux menés s'appliquent à donner une sémantique à UML via un autre langage tel que SDL ou UPPAAL. Enfin, des travaux se concentrent sur la spécialisation du langage UML pour le domaine de temps réel en utilisant des profils et des stéréotypes. Enfin, l’approche objet, de part ses besoins de modularité et d'encapsulation amènent à introduire de nombreuses classes, ce qui induit une architecture pouvant ne pas être performante du point de vue temporel. Nous avons constaté finalement que le langage formel SDL ne possède pas d’éléments de spécification clair et précis de l’écoulement du temps. Les travaux de recherche menés autour SDL se proposent d’enrichir SDL par addition des nouveaux éléments syntaxiques ou d'associer à SDL à un autre langage.

Lors de la conception, toutes les approches mentionnées LACATRE, UML-RT ou SDL-RT proposent des boîtes à outils qui s'appuient sur des boîtes grises à instancier lors de la conception. Ces langages permettent d'intégrer les aspects temps réel mais ces approches ne proposent pas un cadre formel de conception.

La transformation entre les deux modèles issus de l'étape de spécification et l'étape de la conception est assurée par plusieurs travaux tels que CODARTS, ou le passage de UML àUML-RT. Une fois la sémantique des modèles fixée, la validation de cette transformation peut être assuré via la relation d'équivalence. Les travaux de recherche sur la relation d'équivalence tels que la bisimulation forte, la bisimulation faible et la simulation sont proposés afin de vérifier l'équivalence entre comportement entre deux systèmes. Deux systèmes, sont dits bisimulables si, par rapport à un ensemble de critères d'abstraction, ils produisent le même comportent. Cependant, de telles relations ne sont pas applicables dans le cas de notre étude. En effet, le modèle d'exécution (conception) est un raffinement d'un modèle de contraintes (spécification) et non une adaptation de celui-ci. Pour cette raison, l'approche F-simulation a été proposée. Cette approche n'est pas applicable non plus dans notre cas, du fait qu'elle est liée à un type de comportement plus restreint par rapport à celui auquel nous nous intéressons. En effet, dans notre travail, nous nous intéressons à la relation de causalité entre l'occurrence d'un événement d'activation et le déclenchement des actions correspondantes.

Toutes les études présentées ci-dessus apportent des principes, des solutions ou des modèles rigoureux pour le développement du système temps réel, pour la spécification, la mise en place du modèle d’exécution multitâches et la correction de ce développement. Mais aujourd'hui, il n'existe pas une approche formelle complète qui regroupe tout les aspects nécessaires pour un développement de systèmes temps réel en passant de la spécification à son implémentation.

En nous inspirant de ces travaux, le but de notre étude est de proposer un cadre formel au développement de système temps réel, c’est à dire de formaliser les principes et les solutions

46

exprimées à partir de modèles formels. On s’intéresse plus particulièrement à la formalisation des phases du développement qui aboutissent à la définition du modèle de spécification temps réel et du modèle d’exécution de l’application. Nous nous appuierons d'une part sur le langage SDL dans les étapes de spécification et conception. D'autre part, nous utiliserons le langage IF pour fixer une sémantique temporelle utile pour la validation. Lors de la validation, à partir des ces deux modèles, notre proposition s'appuie sur la validation de la transformation du modèle de contraintes au modèle d'exécution d'un point de vue comportemental. Dans ce sens, nous proposons une nouvelle approche de relation de compatibilité qui permet de vérifier la compatibilité comportementale entre les modèles de contraintes et d'exécution. D’autre part, au niveau d'implémentation, notre proposition s'appuie sur l'analyse d'ordonnançabilité des propriétés temps réels.

Nous présentons maintenant les diverses étapes de l’approche proposée.

47

Partie II

48

5 Description de la méthodologie

Dans le chapitre précédent nous avons présenté les problématiques liées au développement des systèmes temps réel. Nous proposons maintenant une méthodologie pour le développement de tels systèmes. Cette méthodologie définit trois étapes, une de spécification, une de conception, et une d'implémentation, la spécialisation d'un langage (SDL) pour la formalisation de ces étapes, la mise en place de principes de génération de code. Cette méthodologie s'appuie sur des techniques de vérification formelle pour assurer la correction du développement. Dans ce chapitre nous présentons le cadre général et les concepts de la méthodologie proposée.

5.1 Les étapes de la méthodologie

Dans la première partie du mémoire, il est apparu que la majorité des langages dédiés à la conception d'un système temps réel se situent à trois niveaux. Ces niveaux définissent les étapes de la méthodologie proposée. Le premier niveau concerne l'expression de contraintes soit la spécification ((I) et (II) de la figure 5.1). A ce niveau plusieurs langages peuvent être employés comme SA-RT, UML, SDL, etc. (cf. § 2.3.1). Le deuxième niveau concerne la définition du modèle d’exécution c'est l'étape de la conception ((III) et (IV) de la figure 1.1). A ce niveau, des langages comme SDL-RT, LACATRE, UML-RT (cf. § 2.3.2) peuvent être utilisés. Le troisième niveau concerne l’implémentation finale ((V) et (VI) de la figure1). Le langage utilisé est alors généralement le langage C combiné à des demandes de services du système d’exploitation cible multitâches.

Légende : un fond foncé indique notre travail et un fond clair indique les autre langages ou outils peuvant être utilisés Fig. 5.1 Etapes et langages

UML-RT

(I) Spécification des fonctionnalitéset de l’architecture matérielle

(V) Implémentation

(II) Modèle de Contraintes

SDL UML SA-RT

ADL

SDL

ROOM

(VI) Code

(IV) Modèle d’exécution

Compilateur

LACATRE

Etapes Résultats Langages utilisés et outils

SDL-RT

ObjectGeode Tau

C/Win 32 C/VxWorks

Langage synchrone

MSC

(III) Conception

Cahier des charges

49

5.1.1 Modèle de contraintes

Pour pouvoir concevoir, il faut d’abord disposer d'un modèle formalisé du cahier des charges, c'est le but de la spécification. Selon les principes définis pour le PIM (Plateform Independent Model) dans l'approche MDA (Model Driven Architecture) de l'OMG [15], par spécification, il faut entendre une description complète du système, qui n'intègre pas les détails d'implémentation. On définit ce que le système doit faire et non comment il le fait. Dans les systèmes étudiés, la spécification décrit, d'une part, les fonctionnalités du système en intégrant le paradigme Evénement - Condition - Action [88], et d'autre part les contraintes temps réel. La formalisation du modèle obtenu assure la possibilité de réaliser des vérifications.

Dans notre étude, nous supposons que cette étape qui s'appuie sur un cahier des charges informel a été réalisée. Nous ne nous intéressons ici qu'au langage de définition du modèle de contraintes. C'est l'étape de formalisation des besoins.

5.1.2 Modèle d’exécution

Le modèle d’exécution est un modèle intermédiaire entre la spécification et l’implémentation finale. Ce modèle doit refléter les informations permettant de définir comment le modèle s'exécute. En plus des aspects fonctionnels et comportementaux, le modèle définit la concurrence d'exécution, le modèle de communication et d’utilisation des ressources (ordonnancement). Enfin le modèle d'exécution précise le comportement temporel de l'application en terme de dates d'activation des actions.

L'ensemble des éléments pour l'exécution étant figé à ce niveau, ce modèle peut apparaître comme une abstraction de l'implémentation. Par contre, afin d'assurer une approche formelle dans le développement, ce modèle s'appuie sur des structures types possédant une sémantique précise.

Le passage du modèle de contraintes au modèle d'exécution est laissé libre au concepteur. Il pourra, par exemple, suivre les principes définis par CODARTS.

5.1.3 Implémentation

Enfin, le code est obtenu automatiquement par l’utilisation d’un générateur de code adéquat. L'étape de génération de code ne doit pas modifier le modèle d'exécution. Nous proposons donc un prototype de génération de code qui permet d’automatiser le passage de (IV) à (VI). Ce générateur peut produire un code pour la simulation ou pour l’exécution. Dans le premier cas, nous privilégions une cible de type Win32®, dans le deuxième un exécutif temps réel standard de type VxWorks®.

5.1.4 Choix des langages

D’après l'étude menée dans la première partie (cf. § 2.3), et la présentation succincte faite dans le (§ 2.3) nous avons choisi le langage SDL. C’est un langage asynchrone (facilement applicable aux systèmes distribués), normalisé, connu du monde industriel, intégré dans des

50

environnements de développement, respectant les règles du génie logiciel et qui possède une sémantique formelle.

D’autre part, concernant les extensions temporelles pour SDL (§ 2.31.3), nous nous plaçons dans une stratégie de spécialisation du langage à l'aide d'IF sans aucune modification syntaxique. Au niveau du modèle de contraintes, l'approche proposée s’appuie sur un typage des signaux échangés entre l'application modélisée et son environnement et sur la précision sémantique du comportement temporel.

Au niveau du modèle d’exécution, nous présentons une boîte à outils basée sur les types SDL. Cette boîte à outils définit des blocs de base utilisables pour la conception.

5.2 Validation L'avantage d'avoir des modèles IF est de pouvoir utiliser des outils qui :

− assurent la possibilité de vérifier des propriétés à chaque étape.

− assurent la possibilité de vérifier la correction de la transformation du modèle de contraintes vers le modèle d'exécution.

En effet, IF est pourvu d’un ensemble d’outils (CADP) qui permettent de mettre en œuvre des techniques de vérifications formelles adéquates. Dans ce rapport, nous nous concentrons sur le deuxième aspect. Nous ne nous intéressons pas à l'approche utilisée pour la transformation du modèle de contraintes (II) vers modèle d’exécution (IV). Par contre nous proposons d'assurer la correction de cette transformation, c’est à dire l’invariance des propriétés du système lors de cette transformation (figure 5.2).

Afin d'établir cette correction, nous proposons de traduire les deux modèles de contraintes MC et d'exécution ME en leur LTS correspondants (IX) et (X). La comparaison, ensuite, s'appuie sur les notions d'équivalence et de compatibilité.

(II) MC IF

Conception Sémantique Graphe Validation Résultats RRésultat

Outil IF

Outil IF

LTS

(X) ME LTS

VRAI / FAUX

SDL SDL2IF

(VII) MC (IX) MC

Conformité (CADP) CODARTS

SDL

(IV) ME

IF

(VIII) ME

SDL2IF

Fig. 5.2 : méthodologie proposée (Raffinement et correction)

Légende MC : Modèle de Contraints ; ME : Modèle d’exécution, SDL2IF : traduction un système SDL en système IF.

51

6 Le modèle de contraintes

La première étape du développement concerne la détermination du modèle de contraintes, pour ensuite le concevoir et le réaliser. A partir des besoins exprimés, la spécification traduit ces besoins en une description complète comprenant les informations nécessaires (fonctionnalité et contraintes de QoS, Quality of Service) pour son développement.

6.1 Modèle d'interaction.

Au cours de la description d’un système temps réel, il est nécessaire de spécifier une architecture matérielle. Dans un système distribué, une architecture matérielle est composée de plusieurs machines (figure 6.1) interconnectées entre elles via des réseaux (cf. diagramme d'architecture de SA-RT et diagramme de déploiement de UML). Dans l'approche PROSEUS [[21] que nous suivons ici, ces éléments de l'architecture sont modélisés par des blocs SDL. Ceux-ci représentent les machines, les réseaux, les IHM (Interface Homme Machine) et l'environnement externe.

system S L

c1 c2 c3 c4

Environnement externe

Fig. 6.1 : Modèle d’architecteur matérielle

Machine2RéseauMachine1

c5c5 Appli2

Appli1

IHM

Protocole

D

Par la suite de notre étude, nous nous limiterons sur les machines monoprocesseurs. Une machine permet d'exécuter une ou plusieurs applications (ou composants dans le diagramme de composants de UML). Dans l'approche de décomposition arborescente du système telle que définie par PROSEUS, une application est représentée par un bloc SDL. Nous allons par la suite détailler ce bloc Application. Il est indispensable de modéliser l'environnement de ce bloc applicatif. Nous nous limitons, ici à modéliser le comportement temporel de l'environnement. De plus, la spécification doit permettre de décrire les interactions entre l'application et son environnement. En effet, une application temps réel réagit à des stimuli en provenance des interfaces avec l'environnement en produisant des réponses (données ou événements en sortie) dans un délai prédéterminé par rapport à cet environnement.

Dans le cas d'une application s'exécutant sur un système monoprocesseur, (le cas de notre étude), les stimuli se répartissent selon quatre catégories : les interruptions (IT), les tops d’horloge (TOP) pour la gestion des contraintes de périodicités, les messages qu'ils soient locaux ou en provenance d'un réseau.

Concernant les données spatiales en entrée, elles sont soit associées aux IT ou TOP et sont alors directement lues sur le procédé, soit associées aux messages. Les informations en sortie (données ou événements) sont associées aux messages ou directement écrits sur le procédé.

52

Pour fixer une sémantique temps réel dans les interactions entre l'application et son environnement, il est nécessaire de typer les informations échangées entre l’application et son environnement. Nous proposons des règles de nommage pour les signaux (cf. table 6.1). Ces signaux peuvent véhiculer des données représentées ultérieurement dans ce chapitre. Nom de catégorie Nom de signal sémantique Informations Contraintes

TOP_n (p,d1) Signal périodique à contrainte fixée

n : numéro qui identifie le signal p : période

d1 : échéance associé au signal

Top d’horloge

TOP_n (Pmin, Pmax,d1) Signal périodique à contrainte souple

n : numéro qui identifie le signal Pmin : période minimum acceptable Pmax : période maximum acceptable

d1: échéance

IT_niv_n(d1,d2) Signal d'interruption en provenance du procédé.

n : numéro qui identifie l'interruption niv : niveau d’interruption d1 : le délai minimal entre deux interruptions.

d2 : échéance associée au signal

Interruption

IT_niv_n (dmin,dmax d2,nbre)

Signal d'interruption en rafale en provenance du procédé

n : numéro qui identifie l'interruption. [dmin, dmax] : l’intervalle de temps ou l'interruption peut arriver. nbre : nombre maximal d’interruptions dans une rafale.

d2 : échéance associée au signal

MSG_net_n(d1,d2) Signal en provenance d'un bloc réseau

n : numéro qui identifie le message net : le type de réseau d1 : le délai minimal entre deux messages

d2: échéance associée au signal

Message

MSG_loc_n(d1,d2) Signal en provenance d'un bloc application

n : numéro qui identifie le message d1 : le délai minimal entre deux messages.

d2: échéance associée au signal

REP_n La réponse de l’application à un message.

n: numéro qui identifie la réponse à un MSG_x_n.

- Réponse

COM_n Signal de réponse à destination du procédé

n : numéro qui identifie la réponse -

Update_n (data_n) Mise à jour de donnée.

n : numéro qui identifie une donnée data_n : type prédéfini de donnée datée qui est paramétrée par : . dvaleur: valeur de donnée destampille: l’estampille de donnée

ddva : la validité temporelle de la donnée.

Données

AckUpdate_n Acquittement de la mise à jours des données.

n: numéro qui identifie le message

msg_i_n (d2) Signal entre sous-action n: le numéro qui identifie le signal. d2: échéance associée au signal

Deb_NdA Evénement de début de l'action

NdA est le nom d'action -

Fin_NdA Evénement de fin de l'action

NdA est le nom d'action -

ObsEvt Evénement à observer signal l'envoi d'un événement

Evt est peut être IT , TOP, MSG.. -

Evénement internes

AckEvt Evénement de fin correspondant

Evt est IT , TOP, MSG.. -

Tableau 6.1 : règles de nommages typé des signaux échangés l'application et son environnement

Le modèle d’architecture (figure 6.2) s'appuie sur une modélisation générique d’un système temps réel basée sur des blocs SDL. Ces blocs représentent l’application et tous les composants qui interagissent avec lui : le bloc horloge produit des signaux périodiques (TOP_n), le bloc "Application_2" représente une autre application qui est placée sur la même machine et qui communique avec l'application "Application_1" (MSG_loc_n, REP_n), le bloc "Réseau" modélise une application distante qui peut interagir avec l’application via l'échange de messages (MSG_net_n, REP_n). Enfin, le bloc modélisant l'environnement externe représente le procédé à contrôler (IT, Update, COM). Ce bloc interagit avec l’application par l’envoi des interruptions IT_niv et des données Update_n.

53

Nous présentons maintenant le modèle de l'environnement.

6.2 Modèle temporel de l’environnement

6.2.1 Introduction

La solution proposée s’appuie sur l’utilisation des types SDL (blocs types) afin de modéliser les modèles d’activation proposés. L’utilisation des types facilite le travail du concepteur car ces modèles sont réutilisables.

Chaque bloc se compose d’un ou plusieurs processus SDL. Chaque processus modélise la loi d'arrivée d'un événement externe ou la loi de mise à jour d'une donnée.

En fait, dans cette sémantique nous proposons de modéliser uniquement le comportement du système étudié du point de vue temporel (les actions ne sont pas détaillées).

Dans la suite pour chaque loi d’activation (périodique, sur interruption, par messages). Nous présentons en langage naturel et en logique temps réel. Puis nous donnons, une description en SDL et enfin, une sémantique spécifiée en IF. Cette sémantique va être largement utilisée dans la partie validation.

IF présuppose une présentation textuelle et comme celle-ci est parfois complexe à lire, nous proposons d'utiliser une notation graphique.

6.2.2 Activation périodique

6.2.2.1 Introduction La caractérisation temporelle d’un événement périodique est sa période P qui caractérise l'intervalle de temps fixe entre deux événements (figure 6.3).

COM_n

IT_niv_n

Update_n

Environment

Application_1

Application_2

Horloge

MSG_loc_n

Rep_n

Rep_n MSG_net_n

TamponCapteur

Procédé

Actionneur

TOP_n

Réseau

Machine

Fig. 6.2: modèle d’architecture proposé

54

TOP_n TOP_n TOP_n TOP_n TOP_n

TOP_n: événement périodique. P: période

Dans un cahier des charges, il est possible que la valeur de la période ne soit pas connue a priori. Dans ce cas, seules la valeur minimale Pmin et la valeur maximale Pmax acceptables sont connues.

Dans ces deux cas, la loi d’activation correspondante est formellement donnée en utilisant l'expression de la logique temps réel :

Où TOP_n est l’événement périodique et @(TOP_n,i) représente la date de l’occurrence de l’ième événement périodique TOP_n.

6.2.2.2 Spécification en SDL

La figure 6.4 présente un package décrit en SDL pour définir un modèle type de l'activation périodique. Ce package contient le bloc type horloge. Le bloc horloge contient un seul processus horloge qui est basé sur un timer C avec un time-out égal à la période P (set (now + P, c)).

A l’expiration de la période P, une activation s'effectue par l’envoi du signal TOP_n. Ce bloc a donc deux paramètres (dit paramètres formels de contexte en SDL), la périodicité P et le nom de signal à envoyer TOP_n.

P P P P

Fig. 6.3 : chronogramme d’une activation périodique

(1) ∀i @(TOP_n, i+1) - @(TOP_n,i) = T T = P

(1') Pmin ≤ T ≤ Pmax

hprocess orlogeblock type horloge <signal TOP_n(integer) ; synonym P duration >

G_Horloge

TOP_n

Gate1

TOP_n

horloge

Fig. 6.4 : spécification SDL d’une source d'activation périodique présenté sous forme de bloc type

timer C;

SET (now ,C)

inoccupe

C

TOP_n inoccupe

SET ( now +P,C)

inoccupe

55

6.2.2.3 La sémantique en IF :

Dans la spécification précédente (figure 1.8), nous avons traité le cas où la période est connue. Dans ce paragraphe nous donnons, d'abord, la sémantique correspondante à cette spécification en IF puis la sémantique du cas où la période est contrainte mais non connue a priori. Ces sémantiques doivent satisfaire les lois d’activation périodique données par (1).

Nous avons utilisé dans cette spécification un timer C, afin de préciser le temps de l'activation. Nous utilisons dans le modèle sémantique une horloge IF notée C (cf. figure 6.5). Tout d'abord la déclaration du timer C donnée dans la spécification est visée par la déclaration d'une variable de type horloge (var C clock). Dans le principe du timer en SDL, celui-ci doit être armé par la valeur de période P. Lors de l'expiration d'un timer, une transition peut être tire par la réception d'un signal qui porte le même nom du timer. La sémantique correspondante proposée est de mettre l'horloge C à zéro en utilisant (set C := 0). Une fois le temps écoulé jusqu’à l’instant P (when C = P), la transition correspondante peut être tirée. La sémantique de l'envoi de signal TOP_n est représenté par la ligne (output TOP_n()).

Au cas où les bornes acceptables de la périodicité Pmin, Pmax sont données, la sémantique donnée en IF est basée sur deux horloges (cf. figure 6.6). La première horloge IF notée C est utilisée pour désigner la période. La deuxième notée X est utilisée pour déterminer la date d'envoie de signal TOP_n. Donc, une fois le temps écoulé jusqu'à une valeur X entre Pmin, Pmax (when X <= Pmax and X >= Pmin), cette valeur est considérée comme la période de la source de l'activation périodique. Elle est récupérée par l'instruction suivante (P:=timval(C)). Puis, la source d'activation envoie périodiquement le signal TOP_n.

Fig. 6.5 : la sémantique d’une activation périodique, selon l'expression (1) présenté en IF 2.0

Fig. 6.6 : la sémantique d’une activation périodique, selon (1') présentée en IF 2.0

56

6.2.3 Activation sur interruption

Au niveau des contraintes temporelles associées aux interruptions, on distingue entre deux types de source d’interruption, la source d’interruption régulière (interruption simple), et la source d’interruption en rafale (paquet d’interruptions).

6.2.3.1 Source d’interruption régulière

A Introduction

La source d’interruption régulière génère des interruptions caractérisées par une durée minimale dmin et une durée maximale dmax entre deux occurrences (cf. figure 6.7).

La loi d’arrivée de ces interruptions peut être écrite formellement selon la logique temps réel :

IT_1 IT_1

t dmin ≤X2-X1 ≤ dmax

B La spécification et l’utilisation en SDL

Le bloc type SDL notée sourceITreg représente une source d'interruption régulière. Cette source envoie des interruptions dans l'intervalle de temps [dmin, dmax ]. Afin de spécifier cet intervalle, nous avons utilisé la notion de signal continu de SDL avec une condition temporelle ((C + dmin <= now) and (now <= C + dmax)). Où C est une variable de type time qui est initialisée par la valeur de l'horloge système now. Donc, à chaque fois que la condition précédente est remplie, une interruption est envoyée.

Les paramètres formels de contexte de ce bloc sont les deux bornes de l'intervalle et le nom du signal à envoyer.

Fig. 6.7 : Chronogramme d’une activation sur interruption simple.

X1 X2

(2) ∀i dmin ≤ @(IT_niv_n,i+1) - @(IT_niv_n,i) ≤ dmax

57

Gate_IT

IT_niv

route2

IT_nivsITreg

block signal

type

s ourceITreg

< IT_niv ;

dmin duration ; dmax duration >

synonymsynonym

process sITreg

Dcl C time ;

C:=now

inoccupe

(C+dmin <= now) and (now <=C+dmax)

IT_niv_n

C := now

inoccupe

inoccupe

Fig. 6.8 : La spécification détaillée des sources d’activation sur interruption.

C La sémantique en IF :

La sémantique de la source d'activation est représentée en IF par la figure 6.9. Cette modélisation est basée sur les mêmes principes que la loi d’activation périodique présentée précédemment.

Lors de la traduction de la spécification présentée dans figure 1.12 en IF, l'initialisation de la variable C est traduit par l'initialisation de l'horloge C (set C:= 0). La condition traduit par la ligne suivante (when C ≥dmin and C ≤ dmax). Afin de préciser que la transition peut être franchie entre dmin et dmax, nous utilisons le mot clé de IF notée deadline avec la valeur delayable (section 3.1.3.3Bb.3 page 26 ).

Fig. 6.9 : la sémantique sources d’activation sur interruption

6.2.3.2 Source d'interruption en rafale

La source d’interruption en rafale envoie des paquets d'interruptions. On suppose que chaque paquet (la rafale) contient un nombre fixe d'interruptions.

A La loi d’activation

Les contraintes temporelles de ce type d’interruption se divise entre deux groupes : des contraintes temporelles entre rafales (c’est à dire inter-rafales) et des contraintes temporelles pour les interruptions au sein d'une même rafale (intra-rafale) (figure 6.10).

58

IT IT IT

Pour les contraintes inter-rafales, nous spécifions un intervalle de séparation entre deux débuts d'occurrences de rafale noté que [Lmin, Lmax] soit :

En ce qui concerne les contraintes temporelles intra rafale, une durée minimale dmin et une durée maximale dmax paramètrent l'intervalle entre deux interruptions dans la rafale, soit

Avec j [1..n] et n est le nombre maximal d'interruptions dans une rafale.

Enfin, les contraintes temporelles inter rafale et intra rafale doivent respecter les contraintes :

Cette contrainte exprime que jamais une rafale ne peut démarrer avant la fin d'une rafale précédente.

B La spécification et l’utilisation en SDL

Le bloc type nommé sourceITirreg représente en SDL une source d’interruption irrégulière. Afin de spécifier les contraintes temporelles, nous continuons à utiliser les signaux continus SDL avec des conditions basées sur des variables de type time.

Le premier signal continu avec la variable de temps notée C est utilisé pour déterminer le délai de séparation entre deux rafales. Le deuxième signal continu avec le variable de temps notée X est utilisé pour déterminer le délai de séparation entre deux interruptions intra-rafale.

Une fois la condition du temps ((Lmin+ C) <= now) and (now <=Lmax + C)) est remplie le processus sITirreg change son état de l'état inoccupé à l'état envoi afin de commencer à envoyer un rafale de n interruptions (cpt := n). Puis ce processus boucle sur l'état envoi pour envoyer les interruptions de la rafale tant que la condition du signal continu (( dmin + X < now) and (now <dmax +X))) est rempli et le compteur cpt est différent de zéro.

Lmin

t

dmin

dmax

IT IT IT

Lmax

Fig. 6.10 : chronogramme d’une activation sur interruption en rafale.

(3) Lmin ≤ @ (Deb_rafale, i+1) - @ (Deb_rafale, i) ≤Lmax

Où la notation Deb_rafale représente le début d'un rafale.

(4) dmin ≤ @ (IT_niv_n ,j+1) - @ (IT_niv_n,j) ≤ dmax

(5) n.dmax ≤ Lmin

59

Les paramètres formels de ce bloc sont Lmin, Lmax, dmin, dmax et n le nombre des interruptions dans une rafale (cf. figure 6.11).

C La sémantique en IF

La sémantique de ce bloc est présentée et donnée en IF (figure 6.12). Cette sémantique est appuyée sur l'utilisation d'horloges IF afin de spécifier les contraintes temporelles. Lors de la traduction de la spécification donnée dans la figure 6.12, deux horloges IF sont utilisées pour représenter les deux variables de temps C et X. Similairement à ce qui est présenté dans la sémantique de source d'interruption régulière, nous traduisons les deux signaux continus par les conditions (when C ≥ Lmin and C ≤ Lmax) et (when X ≥ dmin and X ≤ dmax) avec l'option deadline delayable pour chacune.

De plus, le prédicat du nombre d'interruptions dans une rafale (cpt = 0) de la figure 6.11, est traduit en IF par un état instable q avec deux conditions (provided cpt > 0) et (provided

block type

sourceITirreg<signal IT_niv ;

synonym n integer;

uration; u tion>

Lmin duration ; Lmax d dmin duration ; dmax d ra

synonymsynonymsynonymsynonym

Process sITirreg

Dcl X,C time;Dcl cpt integer;

c:=now

inoccupe

inoccupe

(Lmin+ C) <= now and (now <=Lmax + C)

X:= now

C:= no

w

cpt := n

envoi

envoi

( dmin + X < now) and (now <dmax +X))

cpt = 0

true

inoccupe cpt := cpt -1

IT_niv_n

C:=now

false

envoi

G_rafale

IT_niv

route3

IT_niv

sITirreg

Fig. 6.11 : la spécification détaillée des sources interruptions en rafale

60

cpt=0).

Fig. 6.12 : Sémantique IF de la source d'interruption en rafale

6.2.4 Le modèle temporel des données

Nous abordons, dans ce paragraphe la modélisation de données échangées entre l'application et son environnement. Nous ne nous détaillons pas dans ce mémoire comment les données sont produites par le procédé. En effet cela dépend de la dynamique de chaque procédé. Un capteur scrute cette donnée sur le procédé selon une loi périodique (formule (1)) ou sporadique (à adapter au rythme de production de cette donnée) (formule (2)). Ensuite, il remplit un tampon associé à la machine par l'émission du signal (Update_n(data_n))

Une fois que la donnée est mémorisée dans le tampon (réception de AckUpdate_n), deux comportements temporels sont possibles, soit le capteur signale la mise à jour de la donnée à l'application, soit ne génère aucun événement. C'est alors à l'application de scruter la donnée (Import Data_n).

Dans le modèle avec signalisation de la mise à jour de donnée, nous utilisons l'interruption, présentée précédemment, afin de représenter cette signalisation.

6.2.4.1 Spécification en SDL

Les trois processus SDL dans la figure 1.18 présentent respectivement de gauche à droite un procédé, un capteur et un tampon. Le capteur scrute le procédé selon une loi spécifique (périodique ou sporadique), ensuite il associe à cette donnée sa date de lecture destampille, puis la mémorisation de donnée dans le tampon se fait d'une manière synchrone (entre le capteur et le tampon) afin d'assurer que la mémorisation est faite obligatoirement avant la signalisation de cette mise à jour à l'application. Pour modéliser cette mémorisation, le capteur envoie update_n puis attend le signal AckUpdate_n, qui signifie l'achèvement de la mémorisation.

La spécification donnée dans la figure 1.13 représente les deux comportements temporels du procédé. Dans le cas de la mise à jour avec signalisation, le symbole X du processus

61

capteur devient un envoi d'une interruption IT_niv_n. Dans l'autre cas, ce symbole n'apparaît pas doit être disparu.

6.2.4.2 La sémantique en IF

La spécification SDL du processus capteur a été traduite en IF 2.0 en incluant des notions de temps présentées dans les paragraphes précédents (Figure 6.14). On considère ici une loi de scrutation périodique (période P) du procédé. En fait, les sémantiques correspondantes à ces deux types ont été données a priori dans les paragraphes 2.2.2 et 2.2.3. Le seul changement à apporter dans cette sémantique est d'ajouter l'envoi du signal Update_n(data_n).

En ce qui concerne les données véhiculées par ce signal, entre le capteur et le tampon, nous traduisons le type de donnée temporel définie en SDL par le type suivant :

Fig. 6.14 : La sémantique d'un capteur avec une loi de scrutation périodique

type Update_n = record dvaleur integer; destampille integer; dage integer; endrecord;

process capteur

"loi de sprocé

crutation dé"du

Update_n(data_n)

X

inoccupé

process procédé

inoccupé

date_de_production

Export (data)

inoccupé

ampo t n process

inoccupéattenteinoccupé

AckUpdate_n U ) pdate_n(data_n

EXPORT (data_n) Import (data)

inoccupé

AckUpdate_nDvaleur= data Destampille:= now

Newtype data_n Struct pdate_D; U

integer

dvaleur time /* valeur */ destampille time /* estampille */ dage time; ; /*age */ EndNewtype data_n ;DCL data_1 data_n;

attente

Fig. 1.13 : mise à jour de donnée

62

La figure 6.15 représente la sémantique d'un tampon. Nous avons défini une variable partagée notée data dans le tampon afin de traduire le mécanisme SDL de l'exportation et l'importation de données entre le tampon et l'application en IF. Cette variable notée data de type data_n est définie par (var data data_n public). Nous traduisons l'export par l'écriture dans ce variable et l'import par la lecture.

Fig 6.15 : La sémantique d'un tampon avec une variable public présentant l'export

Pour accéder à cette variable dès l'application (la lecture), nous utilisons la structure IF suivante : (tampon 0).data où data est le nom de la variable et "tampon 0" est le nom du processus contenant cette variable. Il est à noter que dans SDL une variable peut être exportée par un seul processus, et importée par plusieurs processus (donc une seule écriture et multi-lecture). Par contre, en IF, la valeur d'une variable peut être modifiée par plusieurs processus (écrit et lu, donc multi-écriture multi-lecture). Pour garder la sémantique de SDL, lors de la traduction en IF, nous n'autorisons que le processus tampon d'écrire dans cette variable.

6.2.5 Activation par message

Nous avons mentionné que plusieurs applications (locales ou distantes) communiquent via des messages. Le message est considéré comme un événement sporadique. En plus des paramètres que nous avons spécifiés à l'autre type d'événement sporadique présenté dans ce mémoire (l'interruption simple), les messages possèdent un paramètre supplémentaire noté "data" car les messages peuvent véhiculer des données. Au niveau du traitement des messages dans l'application, il n'y a pas de différences entre les messages locaux et distants.

Les contraintes temporelles qui sont associées aux messages sont donc soit une durée minimale dmin séparant l'arrivées de deux messages successifs, et une durée maximale dmax séparant l'arrivées de deux messages successifs. Ces contraintes sont exprimées en logique temps réel selon la formule (2).

6.2.5.1 La spécification en SDL

A ce stade, nous n’avons pas de procédé externe à modéliser car la source d’activation est une application. L'échange des messages peut être effectué de façon soit synchrone : il y a une attente de la réponse de synchronisation dans le processus émetteur ou asynchrone c'est-à-dire sans attente. En ce qui concerne l'échange synchrone des messages, l'application émettrice appli_1 envoie le message puis, elle reste dans l'état attente jusqu'à l'arrivée du signal de réponse correspondant. Dans la coté de l'application réceptrice appli_2, une fois l'application reçoit le message MSG_loc_n, une action Afaire est exécutée puis la réponse Rep_n est envoyée (cf. figure 6.16).

63

ppli_1 aprocess

MSG_loc_n

attente

En ce qui concerne l'échange asynchrone de messages, l'application émettrice n'attend pas une réponse à son message envoyé. Elle continue à exécuter son traitement (cf. figure 6.17).

6.2.5.2 La sémantique en IF

Les contraintes temporelles associées aux messages sont les mêmes contraintes que celles spécifiées pour la source d'interruption régulière, donc la sémantique temporelle donnée dans le § 2.2.3 de ce chapitre est valable pour ce type d'activation.

Le seul changement à apporter concerne l'attente d'une réponse dans l'échange synchrone. Cela se traduit par l'ajout d'un état supplémentaire "attente" pour attendre la réponse de l'application réceptrice (Figure 6.18).

Fig. 6.16 : une activation par message synchrone

Rep_n

"reprendretraitement"le

*n'importe quelsignal

attente

appli_1process

MSG_loc_n

"reprendre raitement"le t

Fig. 6.17 : une activation par message asynchrone

Fig. 6.18 : Sémantique d'un échange synchrone de message

64

6.3 Le modèle temporel des actions

Après avoir traité des événements et des données échangés entre le procédé et les applications et de leurs contraintes temporelles, nous allons détailler le reste de la stratégie de modélisation que nous suivons, pour la partie condition-action de la logique E-C-A.

La condition à remplir pour exécuter une action peut être l'expiration d’un délai, la réception d’un évènement, le changement d'une condition booléenne. Dans notre étude, la seule condition que nous considérons est l'arrivée d'un événement tel que présenté précédemment.

Une action est un agent actif de l'application attaché à une fonctionnalité simple ou complexe identifié lors de l'analyse fonctionnelle. Elle possède deux vues : une comportementale et une temporelle. Dans la suite, nous présentons uniquement le modèle temporel de l'action.

Nous avons dit qu'une application réagit à des stimuli en entrée notée E (dans notre cas ce sont IT_niv_n, TOP_n et MSG_loc_n) en produisant des réponses notée S (qui sont COM_n, REP_n). Nous considérons ces événements comme l'interface de l'application.

Selon [88] des événements externes (IT_niv_n, TOP_n et MSG_loc_non) sont des événements qui provoquent l'apparition d'autres événements internes à l'application. L'événement de début Deb_Afaire est un événement interne dans l'application qui marque le début de l'initialisation d'une action. L'événement Fin_Afaire est un événement qui marque la fin de l'exécution de l'action correspondante. La relation entre l'événement et l'action est donnée en logique temps réel par la formule suivante :

oDFSd

enl'acalosoiop(d'

6.3

actpro

@(ΩE, i) < @ (Deb_Afaire, i) ∧ @ (Fin_Afaire, i) < @(S, i) ≤ @(ΩE, i) + d ……(6)

ù : ΩE est un événement externe qui peut être IT_niv_n, TOP_n ou MSG_loc_n eb_Afaire est l'événement de début de l'action Afaire suite à l'occurrence de E. in_Afaire est l'événement de fin de l'action Afaire. est l'événement sortant qui peut être un des événements : COM_n, REP_n, Fin : est la délai d'exécution entre S et E

Lorsque l'événement E est présent, l'action devient opérationnelle, ce qui signifie qu'elle tame l'exécution du traitement qui lui associé. Lorsque l'exécution du traitement associé à tion est terminée, le signal correspondant est émis (COM_n, REP_n, Fin). Elle devient rs non opérationnelle. Le fait d'être dans l'état opérationnel ne signifie pas qu'une action t en cours d'exécution mais qu'elle entre en compétition avec d'autres actions érationnelles. Dans notre cas l'état opérationnel peut être se composer de l'état en cours exécution) ou en attente (d'une synchronisation).

.1 Spécification SDL du modèle temporel d'action.

Nous avons classé les actions dans deux catégories qui sont les actions primitives et les ions composites. La figure 6.19 présente une spécification SDL d'une action primitive. Le cessus qui représente cette action contient de deux états, l'état inoccupé et l'état en_cours.

65

L'état inoccupé est l'état où l'action est en attente de l'événement d'activation E. Cet événement doit être un des événements que nous avons présenté précédemment. A l'arrivée de cet événement une processus correspondant Afaire est invoqué. Le processus Action_1 change alors son état à l'état en_cours en attendant la fin de l'exécution de ce processus.

Dans le temps, au cas où une contrainte temporelle est violée, le processus Action_1 peut recevoir un signal STP_n, en provenance d'un RTCC (Real Time Constraints Controller) qui va être présenté par la suite, afin d'arrêter l'exécution du processus Afaire.

Le schéma du processus Afaire est donné par la figure 6.20. Dans SDL, il n’y a pas de possibilité d’interpréter le signal STP_n par un arrêt immédiat d’un processus ou procédure en cours d’exécution (hypothèse de non préemptibilité d'une transition). Ce signal est donc pris en compte en fin d’exécution du processus Afaire. Ce point est détaillé dans la sémantique présentée par la suite.

Le deuxième type d'action est l'action composite. Dans ce cas, l'action est composée de plusieurs sous actions comme nous montrons dans la figure 6.21.

Dans cet te figure 6.21 une action composite appli est consisté de trois sous actions Action1.1, Action1.2 et Action1.3. En fait, nous considérons le processus Action1.1 comme le processus principal. Toutes les communications avec l'environnement externe sont faite via ce

process Afaire

Action_u_n

Fin_Afaire

Fig. 6.19 : La spécification SDL s'une action primitive

block type appli <signal E, S, STP_n; procedure Action_u_n >

r1

can1

E, STP_nS

E, STP_n

r2

S

Action_1

Fin_Afaire

process Action_1

inoccupe

en_cours

STP_n

inoccupe

Fin_Afaire

S

Afaire

inoccupe

E

r3Afaire (0,)

Fig. 6.20 : processus afaire1.1

66

processus. La spécification présentée dans la figure 6.21 contient trois processus, chacun de ces processus présente une phase de l'action.

Une fois l'exécution de la première sous action Action1.1 terminée, un événement signal msg_i_1 déclenche la deuxième sous action Action1.2. De façon similaire, la troisième sous action Action1.3 est déclenchée. Après avoir terminé l'exécution des trois sous actions, l'application peut envoyer l'événement sortant S. Il existe une relation de précédence entre toutes les sous-actions de l'action composite exprimée par :

(Deb_Afaire, i+1) > @ (Fin_Afaire, i)(i=1,..,3).

Comme dit précédemment l'application appli peut recevoir un signal STP_n en provenance de RTCC afin d'arrêter l'exécution de l'action. Comme nous avons spécifié dans la figure 6.21, ce signal est transmit à la phase de l'action qui est en cours d'exécution (stp_1 ou stp_2).

block type ppli a <signal E, S, STP_n; Procedure Actio_u_1, Action_u_2, Action_u_3>

can1

E, S _nTP S

E, STP_n

r2

msg_i_1,stp_1

r3

msg_i_2,stp_2

r4

Fin_afaire1.3

r5 S

Action_1.1

Action_1.2

Action_1.3

Afaire1.1 (0,)

Afaire1.2 (0,)

[Fin_afaire1.3]

[Fin_afaire1.2]

[Fin_afaire1.1]

Afaire1.3 (0,)

r1

Fig. 6.21 : les phases de l'action composite

67

6.3.2 La sémantique du modèle temporel d'action.

Lors de la traduction du modèle temporel d'action nous remplaçons le processus SDL Afaire par un processus IF noté Afaire.

Le seul point à détailler, après la traduction automatique de la spécification donnée par la figure 6.24, est le remplacement de la création de processus par l'occurrence de l'événement Deb_Afaire qui signifie le début d'action.

Dans le processus Afaire, nous modélisons l'écoulement du temps d'exécution de l'action par une horloge IF notée extime. Lorsque un événement Deb_Afaire arrive, qui signifie le début de l'exécution, cette horloge est initialisé (set extime:=0). Une fois

process Action_1.1

inoccupe

E

afaire1.1

en_cours_A1.1

en_cours_A1.1

STP_n

inoccupe

Fin_afaire1.1

msg_i_1

en_cours_A1.2

en_cours_A1.2

STP_n

STP_1_1

inoccupe

Fin_afaire1.2

S

inoccupe

process Action_1.2

inoccupe

msg_i_1

afaire1.2

en_cours_A1.2

en_cours_A1.2

STP_1_2

inoccupe

Fin_afaire1.2

msg_i_2

en_cours_A1.3

en_cours_A1.3

STP_1_1

STP_1_2

inoccupe

Fin_afaire1.3

Fin_afaire1.2

inoccupe

A 3ction_1.process

inoccupe

msg_i_2

afaire1.3

en_cours_A1.3

STP_1_2 Fin_afaire1.3

inoccupe Fin_afaire1.3

inoccupe

Fig. 6.22 : corps de l'action composite

Fig. 6.23 : sémantique de l'action primitive

68

l'exécution est terminée (le temps écoulé jusqu'à la valeur d) (when extime=d), le processus produit l'événement de fin de l'exécution Fin_Afaire. Il est à noter qu'à ce stade du développement, la valeur de d est inconnue.

Fig. 6.24 : sémantique de le processus Afaire

Dans la spécification SDL (figure 6.21), la réception du signal STP ne possède aucun effet car SDL est basé sur l'hypothèse de non préemptibilité des transitions. Cela signifie que le signal stp_1 ne va être jamais reçu par le processus Afaire. En revanche dans la sémantique donnée dans la figure 5.25, si le processus est dans l'état exe et s'il reçoit le signal stp_1, l'horloge extime est remise à zéro reset extime.

En ce qui concerne la sémantique de l'action composite, chaque sous action possède la même sémantique que l'action primitive (figure 6.25).

Fig. 6.25 : sémantique d'une phase d'une action composite

6.4 L'échéance et l'âge de donnée

6.4.1 Introduction

En plus, de la présentation des éléments qui modélisent le paradigme E-C-A, nous avons modélisé les contraintes temps réel correspondantes à chacun de ces éléments. Ces contraintes portent sur les lois d'occurrence des événements entrée et des données, le modèle temporel des actions. D'autres contraintes temps réel doivent être spécifiées dans le système temps réel (cf. § xx). Nous introduisons, d'une part, l'âge qui restreint la durée de validité d'une donnée, d'autre part, l'échéance qui désigne l'intervalle de temps maximum pendant lequel une action doit être exécutée et terminée. Ces deux informations peuvent être associées comme des paramètres aux événements en entrée (le cas d'une échéance) ou définie comme des informations supplémentaires dans la donnée (le cas de l'âge d'une donnée).

69

D'autre part, il est possible que ces contraintes temps réel spécifiées ne soient pas respectées au cours de l'exécution de l'application. Nous allons donc étudier la modélisation des politiques temps réel de vérification de ces contraintes.

6.4.2 L'âge d’une donnée

A partir de la définition de l'âge d'une donnée, et selon le type de modèle temporel de la mise à jour de données (cf. §1.3 page 6), nous pouvons représenter cet âge de donnée en logique temps réel par la formule suivant.

Où @( Upd@(IMPORT(da(l'utilisation de

En fait, @(Udans le tampon.

6.4.3 Echéa

Pour modélperçoit un événQuand un événselon une échéa

Selon la déd'échéance, l'éc

Dans le casl'échéance relatest définie par l

Dans le casêtre affectée à action composiaction. A titre dl'arrivée de l'év

(7) @ (IMPORT(data_n), i) -@( Update_n(data_n) , i) ≤ dage

ate_n(data_n), i) et la ième occurrence de la mise à jour de la donnée data_n, ta_n), i) est la date de la ième occurrence de l'importation de donnée la donnée par l'application) et dage est l'âge prédéfinie de cette donnée.

pdate_n(data_n), i) représente l'instant où la donnée est écrite par le capteur Cette date est déterminée selon la loi de scrutation de procédé par le capteur.

nce

iser une échéance nous appliquons la contrainte entre le moment où le système ement et le moment où celui-ci a totalement effectué le traitement associé. ement externe ΩE survient, il déclenche un ensemble d’actions à exécuter nce spécifique. Cette contrainte se traduit en logique temps réel par la loi :

(8) @(ΩE, i) < @ (Deb_Afaire, i) ∧ @ (Fin_Afaire, i) < @(S, i) ≤ @(ΩE, i) + d où : ΩE est un événement externe qui peut être IT_niv_n, TOP_n ou MSG_loc_n Deb_Afaire est l'événement de début de l'action Afaire Fin_Afaire est l'événement de fin de l'action Afaire. S est l' événemenet sortant qui peut être un des événements : COM_n, REP_n, Fin d: est l'échéance

finition de l'échéance (cf. §§1.3 page 6), nous avons mentionné deux types héance relative et l'échéance bout en bout.

de l'action primitive (cf. section 6.3, page 65), nous ne différencions pas entre ive et l'échéance bout en bout. Dans ce cas, nous pouvons noter que l'échéance a relation : @(Fin_Afaire(i)) - @(E(i)) ≤d où @(Fin_Afaire(i)= @(S).

d'une action composite (cf. section 6.3, page 65) une échéance relative peut une sous action. Dans la figure 6.25 (voir page 63) nous avons présenté une te de trois sous actions avec une échéance relative associée à chaque sous 'illustration, nous modélisons l'échéance d1, pour l'action Action_1.1, soit entre énement externe E et la fin de l'action de procédure afaire1.1 représentée par

70

la réception de l'événement Fin_Afaire. Similairement d2 et d3 sont deux échéances relatives attribuées aux actions Action_1.2 et Action_1.3. Nous pouvons noter ces contraintes par : @(Fin_afaire1.1(i)) - @(E(i))≤ d1, @(Fin_afaire1.2(i)) - @(msg_i_1(i)) ≤ d2 et @(Fin_afaire1.3(i)) - @(msg_i_2(i)) ≤ d3.

L'échéance bout en bout dans cette action est d où @(Fin_afaire1.3(i)) - @(E(i))≤ d.

6.4.4 Politique temps réel :

Une fois les contraintes temps réel exprimées, ces contraintes doivent être clairement respectées au moment de l'exécution. Dans le cadre de la sûreté de fonctionnement, le non respect de ces contraintes entraîne une réaction aux fautes détectées.

Dans la suite nous allons modéliser quelques politiques temps réel particulières de contrôle des contraintes exprimées : des politiques de filtrage des événements qui ne respectent pas une lois d'activation spécifiées [125], des mécanismes de réaction aux fautes temps réel en cas de violation d'une contrainte comme l'échéance ou l'âge d'une donnée [186] ).

6.4.4.1 Filtrage : Vérification de durée de séparation

Dans le cas d’un événement sporadique (interruption et messages), il est souvent souhaitable d'effectuer un filtrage pour éliminer des événements parasites. Dans un premier temps, un filtrage est effectué sur la date d’arrivée d’un événement pour déterminer si cet événement doit être pris en compte ou rejeté. Ce filtrage est appliqué afin de contrôler le temps de séparation entre deux occurrences d'un événement reçu par l'application (cf. figure 6.26).

71

Action_1process

Une fois qu'un événement est détecté, il faut, pour qu’il soit accepté que l'intervalle du temps entre sa date d'arrivée et celle de son précédent doit être supérieur à un seuil dmin.(cf. section 1.3 page 6). De plus, si le temps d'attente d'un événement est dépassé un autre seuil dmax, une exception temporelle ExceptionTemps peut être générée (figure 6.26). Nous modélisons cette spécification en IF directement car elle est totalement basée sur la notion de temps. Nous utilisons une horloge IF noté C avec l'état instable test_dmin afin de vérifier la date d'arrivée d'un événement E (cf. figure 6.27). La spécification en SDL est donnée par la figure 6.26.

timer t;

ration;

ration;ation;

dcl c timeu

;dcl d d

nteger;u

dcl i idcl dmax d

durdcl dmin

C:=now

SET ( t) dmax,

inoccupe

inoccupe

E

donnee:=import (data_n)

SET (dmax,t)

now -c > dmin

false

inoccupe

true

C:=now

Afaire

t

ExceptionTemps

inoccupe

ExceptionTemps

en_cours

Fig. 6.26 : spécification SDL d'un filtre d'événement

Fig. 6.27 : La sémantique d'un filtrage des événements

72

6.4.4.2 Vérification d’échéance

Pour chaque événement accepté, une action correspondante doit être exécutée dans un délai maximal connu à l'avance. Il est possible de vérifier si cette échéance est respectée ou pas par un test adéquat. Au cas où la réponse à cette question est négative, une exception temporelle est signalée (signal ExceptionTemps). La figure 6.28 donne un exemple de test en fin d'exécution d'une action.

en_cours

now - c > d

inoccupe

true false

ExceptionTemps

Fin_Afaire

Fig. 6.28 : vérifier une échéance liée à un événement

Cette spécification donnée ne permet pas d'interrompre l'exécution du processus Afaire, (hypothèse RTC). La vérification de l'échéance est faite lorsque l'exécution de l'action est terminée. Pour modéliser un processus qui fait le test parallèlement à l'exécution à l'action, nous proposons d'utiliser un automate observateur du dépassement de l'échéance. En cas de non respect de cette échéance, un signal ExceptionTemps est envoyé. Celui-ci peut, par exemple arrêter l'action en cours et d'autre part activer une action corrective.

Cet automate s'appuie sur trois états (cf. figure 6.29), l'état initial, inoccupé et arme. Lors de l'arrivée d'un événement à l'application, l'observateur est informé via un événement noté ObsE. A la réception de cet événement, une horloge C est initialisée à zéro et l'automate change son état à l'état arme. Si cette horloge atteint la valeur d (l'échéance à observer) avant la réception de l'événement AckE qui signifie la fin de l'action correspondante, l'observateur signale une exception temporelles ExceptionTemps .

Fig. 6.29 : sémantique d'un observateur d'échéance

73

6.4.4.3 Vérification de l’âge de données

Afin de vérifier la cohérence des données temps réels, il est souvent intéressant d’associer un filtrage temporel pour réagir aux données temporellement incohérentes.

Dans la définition de donnée datée, nous avons attribué à une donnée temps réel, une estampille temporelle. Nous devons appliquer la loi de cohérence temporelle donnée par (7).

La sémantique correspondante à cette loi de cohérence est donnée par l'emploi d'un observateur entre le capteur (où la donnée a été scrutée) et l'application (où la donnée est consommée). La figure 6.30 présente un automate d'observateur où l'horloge C représente le temps écoulé depuis la production de la donnée. d est l'âge de donnée et uData est un signal envoyé lors de l'utilisation de donnée par l'application.

Fig. 6.30 : vérification de l'age de donnée en IF

6.5 Utilisation des modèles

L'ensemble des modèles proposés s'appuie sur des types SDL. L’utilisation de blocs type définis précédemment correspond à l’instanciation de ces blocs, par la définition des paramètres formels de contexte. Il est aussi nécessaire de respecter les règles de nommage des signaux.

Dans la suite, nous allons illustrer la construction d’un modèle sur un exemple simple de deux activations périodiques. La première est pour exécuter une action action_1 chaque 10 unité de temps et la deuxième une action action_2 chaque 20 unité de temps.

Dans le modèle de contraintes, le système SDL est constitué de quatre blocs (cf. figure 1.36) :

1. deux instanciations du type de bloc prédéfini horloge; 2. deux instanciations du type de bloc prédéfini appli 3. deux processus Action_1, Action_2 définis par l’utilisateur.

Les liaisons entre les blocs se font en créant des canaux entre les ports des blocs prédéfinis (cf. figure 6.31), les signaux convoyés par ces canaux se déduisant des spécifications des portes. Les valeurs des paramètres formels de contexte sont (TOP_1, P1 = 10) pour horloge1, (TOP_2, P2 = 20) pour horloge2, (la procédure Action_1, TOP_1) pour l’instance activation1 et (Action_2, TOP_2) pour l’instance activation2.

74

system Testsignal TOP_1(integer), T

OP_2(integer); 0; 0;

synonym P1 duration = 1synonym P2 duration = 2

Use activation_package;

canal_1

TOP_1

canal_2TOP_2

Action_1 Action_2

horloge_1: horloge <TOP_1,P1>

G_Horloge

traitement à exécuter Des paramètres formels

de contexte

Activation1:appli<TOP_1,Action_1>

G_Activation_P

G_Horloge

horloge_1: horloge <TOP_2, P2>

Utilisation de package

Les portes des instances

G_Activation_P

Activation2:appli<TOP_2,Action_2>

Fig. 6.31 : spécification SDL de deux activations périodiques

6.6 Conclusion

Le modèle de contraintes est l’élément de référence pour la suite du développement. Ce modèle permet d’identifier correctement les besoins temps réel de l’application. Dans cette partie, nous avons défini une taxonomie temporelle des événements échangés entre une application temps réel (monoprocesseur) et son environnement, prenant en compte des événements périodique, des interruptions simple ou en rafale, les messages et sporadique, les échéances liées aux événements en entrée, et enfin les données à durée de validité. De plus, nous avons donné pour chacun de ces éléments une sémantique, basée sur un langage formel IF, prenant en compte les aspects temps réel.

Ce modèle gère explicitement les contraintes temps réel et permet donc de définir formellement des politiques adaptées au temps réel dans les langages de hauts niveaux. Enfin, ce modèle s'appuie sur des types SDL qui facilite grandement son utilisation. Nous présentons maintenant le modèle d'exécution.

75

7 Le modèle d’exécution

7.1 Introduction

Afin de produire un code temps réel à partir d’un modèle SDL, il est nécessaire de fournir lors de la génération de code des informations supplémentaires au modèle originel. Ces informations portent sur l’architecture matérielle (machines, partitionnement logiciel/matériel, medium de communication) et l'architecture logicielle (placement des processus, protocole de communication, systèmes d’exploitation, modèle de tâches, politiques d’ordonnancement).

Lors de la spécification selon le modèle présenté dans la partie précédente sont spécifiés les modèles temporels de l'environnement, des interactions avec l'environnement, des actions et des contraintes temps réel. Lors de la conception du système temps réel, il est nécessaire du connaître comment le système va réagir exactement aux stimuli en provenance du procédé externe pour assurer la prédictibilité du système.

Nous proposons donc d’introduire un modèle d’exécution. Ce modèle correspond à un raffinement ou une transformation du modèle de contraintes présenté dans le chapitre précédent. Ce modèle peut être vu comme une abstraction de l’implémentation. Il intègre la concurrence d'exécution (les tâches), la communication et l’utilisation des ressources.

Pour la construction de ce modèle il faut définir, d’une part le support exécutif, d’autre part la manière d’y implémenter les fonctions réalisées par le système. Comme nous avons également un objectif de validation par rapport à la spécification, un modèle sémantique est associé à ce modèle.

Afin d'aider le concepteur, nous fournissons une boite à outils basée sur des blocs type SDL. Chaque bloc représente une entité d'exécution (tâche ou routine) gérée par un exécutif temps réel (ETR). Les modèles de communication entre ces entités ne sont pas détaillés ici mais lors de la génération de code (cf. chapitre 8).

Une application représentée en utilisant les objets de cette boîte à outils est un schéma constitué d'instances de blocs types SDL instanciers, reliés par des canaux. Les blocs types sont classés en deux parties:

La première partie correspond aux éléments applicatifs. Ils s'appuient sur les services standard des ETR et suivent les standards imposés par la validation temporelle RMA. On retrouve, pour le traitement, les tâches périodiques (PT), les serveurs à scrutation (PS), les tâches sporadiques et les tâches logicielles (SW) (figure 7.1 bloc I). D'autre part, pour les interactions avec l'extérieur on retrouve les routines (d'interruptions et d'alarmes ISR et ALR respectivement). Chacune de ces structures peut être décrit à l’aide d’objets primitifs des ETR. Les comportements de ces objets sont définit par le concepteur de l'application sous forme de processus.

La deuxième partie du modèle correspond aux éléments de contrôle. En particulier, on y retrouve l'implémentation des politiques temps réel.

76

Pour compléter le modèle, nous ajoutons des éléments pour modéliser l'environnement comme l'alarme (bloc AL figure 7.1) les sources d'interruptions (voir bloc sourceITreg figure 7.1), et les interfaces entre l'application et son environnement (PIC: Programmable Interrupt Controller). Les éléments modélisant l'environnement ont déjà été détaillés dans le chapitre 1 et ne sont donc pas repris ici.

Fig. 7.1: schéma d'utilisation de la boîte à outils

RTCC

Appli

Environnement

ch1

IT_niv_n

ch2

ch3

Mask_IT_nUnMask_IT_n

ch4

Sig_IT_n

ch7

TOP_n

ch8

Sig_TOP_n

AL

AL

ch5

TOP_n

ch6Sig_TOP_n

ALR

ch9

msg_i_n

ch10

SET_wd_n

Delete _n

SW WD

PS

PT ALR

RESET_wd_n

ISRPICsourceITreg

ch11

system ystem_test s

En plus des signaux déjà présentés dans le tableau 1.6 du §1.3 (chapitre 6), nous avons introduit de nouveaux signaux internes à l'application (tableau 7.2). Ces signaux sont détaillés ultérieurement dans le chapitre.

Nom de catégorie Nom de signal sémantique Informations Sig_IT_n Signalisation d'une

interruption n: numéro qui identifie le signal

Signalisation d'un événement

Sig_TOP_n Signalisation d'un top n: numéro qui identifie le signal

SET_wd_n Armement d'un chien de garde

n: numéro qui identifie le signal

RESET_wd désarmement d'un chien de garde

n: numéro qui identifie le signal

Utilisation de chien de garde

Delete_n Suspension d'une action en cours

n: numéro qui identifie le signal

Mask_IT_n (niv) Masquage d'un niveau d'interruption

n: numéro qui identifie le signal niv : niveau d’interruption

UnMask_IT_n (niv) démasqage un niveau d'interruption

n: numéro qui identifie le signal niv : niveau d’interruption

Masquage des interruptions

EOI_n Fin de traitement d'une interruption

n: numéro qui identifie le signal

Tableau 7.2 : primitives de boîte à outils proposées

Dans la suite nous détaillons chacun des éléments de la boîte à outils en SDL et nous fournissons sa sémantique associée en IF. Ensuite, nous donnons le mode d’utilisation de ces objets via les règles d’interconnexion de ces divers éléments.

77

7.2 Eléments applicatifs

Nous divisons les éléments applicatifs de la boîte à outils en deux catégories que sont les routines et les tâches.

7.2.1 Les routines

7.2.1.1 La routine d’interruption

La routine d’interruption ou ISR (Interrupt Service Routine) est une routine logicielle qui est activée pour répondre à une interruption en provenance de l’environnement extérieur via un PIC (Programmable Interrupt Controller). Chaque ISR est associée à une source d’interruption et dans un système d’exploitation temps réel il y a des ISR prédéfinies par le système et d’autre dont la définition est à la charge du concepteur de l’application. De manière générale, nous distinguons plusieurs stratégies pour traiter les interruptions en fonction des exigences du système :

Traitement des interruptions avec masquage : le système masque le niveau d’interruption jusqu’au moment où le système fini le traitement de la dernière interruption reçue (la démasquage est fait par l’application).

Traitement des interruptions avec sauvegarde: le système sauvegarde toutes les interruptions venant de l’extérieur.

Traitement des interruptions avec écrasement : seule la dernière interruption reçue est considérée.

D'autre part, il y a deux manières pour assurer les traitements liés aux interruptions : Utiliser une routine d'interruption seule pour servir des traitements de courte durée. Ces

traitements peuvent être utiles pour mémoriser des données volatiles en provenance du procédé, masquer les niveaux et pour envoyer un EOI (End Of Interrupt) au PIC (figure 7.2).

Utiliser une tâche (associée à une routine) qui assure les traitements liés à l'interruption et le partage de données avec les autres tâches (figure 7.3). En effet une routine ne peut pas partager des données avec d'autres tâches.

Dans le cas de notre étude nous nous limitons à la présentation de modélisation d'ISR avec masquage. Autres modélisations peuvent être aisément déduites de cette dernière.

Les primitives utilisées dans la manipulation des interruptions sont des primitives de masquage et démasquage d'un niveau des interruptions. Elles peuvent être appelées de n'importe quelle tâche. D'autre part une primitive spécifique, autorisée dans la routine d'interruption, est la primitive de signalisation qui permet d'activer la tâche qui prend en compte le traitement correspond à l'interruption.

Nous proposons de spécialiser certains signaux SDL afin de typer ces primitives. Dorénavant, nous dédions les signaux Mask_IT_n(niv) et UnMask_IT_n(niv) respectivement au masquage et démasquage du niveau "niv" des interruptions, et le signal Sig_IT_n() pour modéliser l'activation d'une tâche. Enfin, nous dédions le signal EOI_n pour signaler la fin du traitement de l'interruption au PIC. Ce signal est considéré comme une primitive de démasquage si le niveau d'interruption est déjà masqué.

78

A La modélisation en SDL de la routine d'interruption

C'est au concepteur de décrire le traitement à effectuer dans la routine d'interruption (figure 7.2). Les possibilités de traitement dans cette routine sont dépendantes de l'exécutif temps réel utilisé. A ce stade du développement, nous limitons le traitement à une signalisation à la tâche qui prend en compte le traitement correspondant à l'interruption, au masquage/démasquage et à la consultation de données.

Les figures 2 et 3 présentent une première modélisation proposée pour une ISR.. A la réception d'une interruption (IT_n), la routine d'interruption demande de masquer ce niveau d'interruption par l'envoi de signal Mask_IT_n (niv) au PIC. Puis une action Action_n est exécutée à chaque activation. A la fin de l'exécution une phase de démasquage est effectuée soit par l'envoi du signal EOI_n. A la figure 7.3, suite à la réception d'une interruption (IT_n), le niveau est maqué (Mask_IT_n) puis une tâche est activée via l'émission du signal Sig_IT_n.

G_ISR IT_n

Mask_IT_n route2Mask_IT_n route1

IT_n ISR

block signalgn

type

ISR_M_SE I_n;

e< sipr

IT_n, Oask_IT_al M ;

ction_n> Aoceduren(int ger)

block type ISR_M_T g_IT_n;

e< signalsignal

Sask_IT(int

i signaleg

IT ;

_nr) M >

G_ISR

IT_n

Sig_IT_n,Mask_IT_n

route2Sig_IT_n,Mask_IT_n

route1 IT_n

ISR

inoccupe

IT_n

Mask_IT_n (niv) ICto P

Action_n

PICEOI_n to

inoccupe

initiale

SR I process process ISR

inoccupe

initiale

IT_n

Mask_IT_n (niv) to PIC

Sig_IT_n

inoccupe

Fig. 7.2 : ISR seule avec masquage Fig. 7.3 : ISR avec masquage et activtion d'une tâche .

B La sémantique en IF 2.0

La sémantique de L'ISR avec masquage en IF 2.0 est donnée dans la figure 7.4. En ce qui concerne le cas de l'ISR avec signalisation à une tâche, sa sémantique est la traduction SDL2IF de la figure 7.2 et 7.3 exactement sans aucune modification. En ce qui concerne l'ISR

79

seule, après la traduction automatique de la modélisation donnée dans la figure 7.2, nous ajoutons une horloge IF notée extime afin de représenter la durée de l'action Action_n. À l'arrivée du signal IT_n, l'horloge est armée. Puis, une fois le temps associé à la durée de l'exécution de l'action écoulé, l'ISR envoie le signal EOI_n au PIC afin de signaler la fin du traitement de l'interruption.

Fig. 7.4 : Les sémantiques IF de l'ISRs présentées dans la figure 7.2 et 3.

7.2.1.2 La routine d’alarme

La routine d’alarme ou ALR (Alarme Routine) est une forme prédéfinie de routine d’interruption. La source d’activation est l’horloge qui est un service de l'OS. La différence majeure entre la routine d’alarme et la routine d’interruption est que l’occurrence d’une routine d’alarme est un événement purement temporel dont la date est prévisible.

Enfin, il n'existe pas de primitives de masquage/démasquage mais seulement des primitives d'armement/désarmement de l'alarme. Ces primitives sont représentées dans le tableau 1 du §1.3 (chapitre 1). On suppose que l'alarme est multi-shot. Une alarme émet des signaux nommés Sig_TOP_n.

A La modélisation et la sémantique de l'ALR

La modélisation de la routine d'alarme en SDL puis en IF (respectivement figure 7.5 et 7.6) est similaire de celle de la routine d'interruption. Au départ, une procédure initiale est exécutée puis à chaque TOP arrivé, une procédure Action_n est exécutée. Puis la routine d'alarme envoie un signal nommé Sig_TOP_n à la tâche qui se charge de reste du traitement.

80

7.2.2 Les tâches

Une tâche, dans une application temps réel, correspond à un travail généralement simple et quasi-toujours répétitif. Les activités d'une tâche se divisent en deux parties. La phase d'initialisation est exécutée une seule fois lors de la création. Le corps de la tâche, lui est répété indéfiniment.

Au niveau des états, chaque tâche est dans un des quatre états suivants : dormant, prêt, exécute ou attente. Dormant correspond à une tâche résidait dans la mémoire c'est-à-dire avant sa création. L'état prêt modélise le fait que la tâche peut s'exécuter. L'état Attente correspond à une tâche en attente de l'occurrence d'un événement. Enfin, la tâche est dans l'état Exécute quand elle est en train d'effectuer son traitement [117].

Nous considérons que toutes les tâches sont créées dés le départ. Donc le passage de l'état dormant à l'état attente se fait d'une manière automatique sans avoir à exprimer de création explicite. Le passage à l'état prêt se fait à la réception du signal d'activation. Puis, la tâche revient dans l'état attente à la fin de l'exécution de son traitement. Une tâche peut être détruite retourne à l'état dormant en utilisant la primitive de destruction de tâche Delete_n. L'état exécute n'est pas explicité ici car il peut à l'exécution et dépend de l'ordonnanceur non modélisé ici.

Nous spécialisons plusieurs types de tâches selon le type de leur source d'activation comme présentées dans le chapitre précèdent. De ce fait, nous avons quatre types de tâches : la tâche périodique, la tâche sporadique, la tâche logicielle et les serveurs à scrutation. Par la suite, nous détaillons ces quatre types de tâches.

G_ALR

TOP_n

Sig_TOP_n routeSig_TOP_n

route1

TOP_n

ALR

block signaltype ALR

< TOP_n; signal Snitia

ig_TOP_n;le>Procedure Action_n; Procedure I

process ALR

initiale

inoccupe

TOP_n

Action_n

Sig_TOP_n

inoccupe

Fig. 7.5 : bloc type SDL pour une routine d’alarme

Fig. 7.6 : Sémantique d’une routine d'alarme ALR en IF

81

7.2.2.1 Les tâches périodiques

A La modélisation en SDL des tâches périodiques

Une tâche périodique ou PT (Periodic Task) reçoit une signal nommée Sig_TOP_n en provenance d'une routine d'alarme. Lorsque le signal Sig_TOP_n est reçu, une action Afaire est déclenchée. A la fin de l'exécution de cette action l'événement Fin_afaire est émis. Lors de son exécution la PT peut recevoir un signal Delete_n qui stoppe l'exécution de l'action. L'arrêt (préemption) ne peut être modélisée explicitement en SDL du fait de l'hypothèse de RTC (Run To Completion).

La figure 7.7 présente la modélisation en SDL d'une tâche périodique. Le bloc type PT s'appuie sur deux processus nommé PT et Afaire. Le processus PT possède trois états, initial, attente et prêt. Ce bloc possède quatre paramètres formels de contextes de signaux: Sig_TOP_n, Delete_n et une procédure initiale et un procédure nommé Action_n.

Après une phase d'initialisation (l'appel de la procédure init), le processus PT change son état à l'état attente où il attend un signal en provenance de la routine d'alarme correspondante. Puis le processus est dans l'état prêt à la suite de ce signal, jusqu'à la fin de l'exécution de l'action Afaire ou à la réception du signal Delete_n.

Le schéma du processus Afaire est donné par le cadre (process Afaire) dans la figure 7.7, où le concepteur peut remplir le code de l'action à exécuter (la procédure Action_n).

Fig. 7.7 : la modélisation SDL d'une Tâche Périodique avec le processus Afaire

block signal

type

PTnteg ),Delete_n; < Sig_TOP_n (i er

procedure Action_n, procedure Initiale >

G_PT

Sig_TOP_n,Delete_n

route

Sig_TOP_n,Delete_n

PT

process PT

init

Attente TOP_n

Afaire

Fin_afaire

Attente

Delete_n

Attente

Afaire

[Fin_afaire]

process Afaire

Action_n

Fin_Afaire

Pret

82

B La sémantique en IF 2.0 d'une tâche périodique

Lors de la traduction de la tâche périodique en IF, nous remplaçons la création du processus Afaire par l'envoi de l'événement Deb_afaire. Nous avons expliqué, en détail, la sémantique du processus Afaire (figure 7.8) dans la section 2.3.2 (voir page.65).

Si la PT reçoit un signal Delete_n. Ce signal Delete_n est expédié au processus Afaire en émettant le signal del_1. A la réception de ce signal le processus Afaire reset l'horloge extime qui modélise le temps d'exécution de l'action.

Fig. 7. 8 : Sémantique de la tâche périodique et l'action

7.2.2.2 Les tâches sporadiques

Les tâches sporadiques sont des tâches non-périodiques activées à des instantes non régulières. Ce type de tâche est lié à des signaux possédant une composante événementielle sporadique (interruption ou message).

A La modélisation en SDL de tâche sporadique.

La seule différente entre la modélisation de la tâche périodique et la tâche sporadique est la source d'activation (interruptions ou des messages). De ce fait, nous attribuons l'événement evt_n comme signal d'activation de cette tâche.

La figure 7.9 présente la modélisation en SDL d'une tâche sporadique. Similairement à la tâche périodique, le bloc type ST (Sporadic Task) s'appuie sur un seul processus noté ST. Le corps de ce processus est le même que celui de PT (figure 7.7).

block<

signal

type

S evt_n, Dele

e Action_ procedurte_n;n; procedure

T

Initiale>

G_ST

evt_n,Delete_n

route

evt_n,Delete_n

[Fin_afaire] AfaireST

Fig. 7. 9 : Tâche Sporadique

B La sémantique en IF 2.0 d'une tâche sporadique.

83

La sémantique de la tâche sporadique en IF est la même sémantique que la tâche périodique présentée dans la figure 7.8, en prenant en compte la différence entre les noms d'événements evt_n et Sig_TOP_n.

7.2.2.3 Les serveurs à scrutation Le serveur à scrutation ou PS (Polling Server) scrute l'environnement à une fréquence

prédéfinie TOP comme une tâche périodique. Par contre, il n'exécute un traitement que si une interruption Sig_IT_n est arrivée avant le TOP courant. Le PS, possède donc deux entrées. La première est un signal de type Sig_TOP_n. La seconde est une entrée en provenance d'une ISR soit Sig_IT_n. Le serveur mémorise l’information véhiculée par ce signal et effectue les traitements nécessaires lorsqu’il passe au cycle suivant (la réception du Sig_TOP_n suivant). Cette approche permet de rendre plus déterministe et donc prévisible les instances d'activation des actions liées à une interruption.

A La modélisation en SDL de serveur à scrutation

La figure 7.10 présente le serveur de scrutation sous forme d’un bloc type qui se compose de deux processus PS et Afaire. Le processus PS possède trois états initiale, attente et prêt. Tout d'abord le processus passe à l'état attente après l'exécution de la procédure initiale. Il est alors prêt à recevoir les deux signaux prévus Sig_IT_n et Sig_TOP_n.

Au cas où un signal Sig_IT_n est reçu, une phase de mémorisation Memo est exécutée (cette dernière correspond à l'ajout de 1 à la variable compteur cpt). Nous utilisons la variable cpt afin de compter les événements reçus (dans l'exemple présenté, le nombre maximal des interruptions à recevoir est 1. en effet dans le système considéré les interruptions sont masquée jusqu'à la fin du traitement de l'interruption en cours.

Lorsqu'un signal Sig_TOP_n est reçu, si le compteur cpt est différent de zéro (c'est-à-dire, un événement est arrivé), l'action Afaire est déclenchée (la création du processus Afaire où le code utilisateur peut être placé). Un PS peut être interrompu suite à la réception du signal Delete_n (figure 7.10).

Dans le cas où les interruptions sont non masquées, il est possible de sauvegarder plusieurs interruptions entre les deux occurrences d'un TOP. Dans ce cas de figure, à chaque arrivée d'une interruption, nous augmentons la valeur du compteur cpt par 1(cpt:=cpt + 1). Inversement, chaque réception de Fin_Afaire ou Delete_n, nous décrémentons le compteur (cpt:=cpt-1).

84

block S_TOP_n,Delete_n;

type Pig<signal Sig_IT_n, S

signal UnMask_IT(integer);Procedure Action_n; procedure intiale>

G_SW

Sig_IT_n,Sig_TOP_n,

Delete_

B La sémantique en IF 2.0 du serveur à scrutation

Fig. 7.10 : Un serveur à scrutation en utilisant la primitive de démasquage

n

UnMask_IT route9

Sig_IT_n,Sig_TOP_n,

UnMask_IT

Delete_n

[Fin_afaire]

Afaire(0,) PS

PSprocess

dcl cpt i g

nte er; synonym niv = 2 ;

intiale

cpt :=0

attente

attente

Sig_TOP_n

a

cpt=0

false

Afaire

pret

true

UnMask_IT(niv)

attente

Sig_IT_n

Memo

cpt := 1

pret

Delete_n

cpt :=0

a

Fin_afaire

cpt := 0

*

a

attente

85

Lors de la traduction automatique de la modélisation du serveur de scrutation donnée par la figure 7.10 en IF, nous remplaçons la création de processus Afaire par l'envoi de l'événement de début d'action Deb_afaire (cf. l'automate dans la figure 7.11). D'autre part, nous traduisons le label a avec la condition cpt = 0 par un état instable notée q avec la condition provided de IF (provided cpt = 0 et provided cpt >0 dans la figure 7.10).

Enfin, nous traduisons le sauvegarde de signaux dans l'état pret du processus PS dans la figure 7.9 par une sauvegarde faite dans une transition franchit à la réception des signaux inattendus dans l'état pret (dans notre cas, la signalisation des interruptions). De ce fait, le nombre d'événements sporadique à traiter dans le prochain cycle du serveur à scrutation est égal de ceux qui sont arrivées lors de traitement plus le nombre des événements arrivés dans le délai d'attente entre deux cycles de scrutation.

*

Fig. 7. 11 : la sémantique d'un serveur à scrutation présenté dans la figure 6.9

7.2.2.4 Les tâches logicielles Les tâches logicielles (en anglais Software Task SW) sont les tâches dont l'activation est

purement logicielle par opposition aux "tâches" précédentes (dont l'activation est déclenchée sur une activation externe liée à une alarme ou source d'interruption).

Cette terminologie désigne toutes les tâches qui sont en aval des deux précédents types de tâches et qui reçoivent un message de leur part pour effectuer un traitement.

A La modélisation en SDL de la tâche logicielle

La tâche logicielle est présentée par un bloc type qui reçoit des signaux de type MSG_loc_n (en provenance d'autres applications), ou de l'intérieur de la même application msg_i_n (cf. Tableau 1 page 52).

Suite à la discussion faite dans la section échanges de message (voir page chapitre 1) entre les applications nous avons déterminé deux type d'échange synchrone et asynchrone.

Dans le cas d'échange de message asynchrone (figure 7.12) la tâche qui rend le service est un bloc type SDL notée SW qui se compose deux processus process SW et process Afaire. Le

86

processus SW représente la tâche qui consiste à trois état dormant, attente et pret. Dès le lancement de l'application, la tâche logicielle est créée et la procédure initiale est exécutée, puis le processus change son état à l'état attente en attendant une activation MSG_loc_n. À la réception de ce dernier le processus exécute son action Afaire (la création du processus Afaire) et change son état à l'état pret. Ensuite, le processus se place en attente de la fin de l'exécution de l'action Afaire, soit la réception de l'événement Fin_afaire, ou de l'événement Delete_n qui signifie la violation d'une contrainte temps réel.

G_SW

MSG_loc_n, Delete_n

route9

MSG_loc_n, Delete_n

SW

[Fin_afaire]

Afaire

block type SW<signal M

nit; Action_n>S c_n(integer),Delete_n;

procedureG_lo

Procedure i

process SW

dcl i integer;

intiale

attente

attente

MSG_loc_n(i)

Afaire

pret

Delete_n

attente

Fin_afaire

attente

Fig. 7.12 : un bloc type SDL d'une tâche logicielle

Dans le cas d'échange de message synchrone (figure 7.12), la tâche demande l'exécution d'un service à une autre tâche. La modélisation de la tâche appelante s'appuie sur un bloc type composé de deux processus. Le processus SW est considéré comme l'interface de cette tâche. Donc tout échange de message avec l'extérieur doit être fait via ce processus. Il contient quatre états. De plus des trois précédents états, l'état attente_rep est ajouté afin de modéliser l'attente de la réponse de synchronisation REP_n en provenance de la tâche qui rend le service.

87

B<

lock y e W t pl

SSigna MSG_loc_n(integer),Delete_n, MSG_loc_m, R

procedur

e init; Procedure Action_n, Action_n1>

EP_n;

G_SW

MSG_loc_n, Delete_n,REP_n

MSG_loc_m route9

MSG_loc_n, Delete_n,REP_n

MSG_loc_m

Afaire

rout1

msg_i_m

msg_i_n, Fin_afaire

SW

process SW

intiale

attente

attente

MSG_loc_n (i)

Afaire

pret

Delete_n

attente

Fin_afaire

attente

msg_i_n

MSG_loc_m

attente_rep

msg_i_m

pret

REP_n

attente_repprocess Afaire_a_service

Action_n

msg_i_n

attente_rep

msg_i_m

Action_n1

Fig. 7.13 : Modélisation d'une tâche logicielle qui demande un service

Le processus Afaire envoie un message synchrone à une autre application via le processus SW. L'échange de message entre les deux processus (SW et Afaire) se fait en utilisant des événements internes msg_i_n, msg_i_m. Une fois que le processus SW a reçu la réponse REP_n, il la transmet (msg_i_m) au processus Afaire pour qu'il termine son traitement (figure 7.12).

B La sémantique en IF 2.0 de la tâche logicielle

La sémantique de la tâche logicielle sans demande de service est présentée par la figure 7.14. En fait cette sémantique est une traduction automatique de la modélisation donnée par la figure 7.12. Le seul changement mené, par rapport de cette modélisation, est l'interprétation du signal Delete_n.

88

Fig. 7.14 : La sémantique de la tâche logicielle sans synchronisation

En ce qui concerne la sémantique de la tâche logicielle avec demande de service, nous avons traduit automatiquement la modélisation de la figure 7.14 par celle présentée à la figure 7.14. Au cas où le processus SW est dans l'état pret, et il reçoit un Delete_n, il est change son état à l'état attente (c'est-à-dire qu'il suspend son exécution).

Fig. 7.15 : la sémantique de la tâche logicielle avec synchronisation

La figure 7.16 présente le processus Afaire correspondant. Nous supposons que l'action consiste de deux phases. La première est celle avant la synchronisation et nous avons supposé qu'elle dure d1 unité de temps. Le processus Afaire reste dans l'état attente_rep jusqu'au l'instant d1 (extime = d1) puis il change son état à l'état "attente" envoie une requête msg_i_n. La deuxième est celle après la réception de la réponse de la synchronisation dont nous supposons qu'elle dure d2 unité de temps.

Fig. 7.16 : La sémantique de l'action Afaire dans le cas de synchronisation

89

7.2.3 Les données

Nous avons présenté, dans le chapitre 1, le modèle des données. En plus, nous avons donnée dans la figure 6.18, page (61), une modélisation d'un tampon. Ce dernier est représenté par un registre dans le modèle d'exécution (figure 7.17).

Il est possible, par exemple suite à l'arrivée d'une interruption, d'effectuer une opération de lecture de données qui sont déjà écrites dans ce registre. Le modèle de cette opération est présenté, en SDL, dans la figure 7.17 par une routine d'interruption.

Afin de présenter la sémantique en IF, nous utilisons une variable partagée entre les deux processus tampon et ISR. La sémantique d'une variable partagée a été détaillé dans la section 1.4 page 7 (chapitre 1).

Dans ce cas des messages, la donnée est un paramètre du signal comme décrit dans le modèle de contraintes.

process ISR

IT_n

Mask_IT_n (niv) ICto P

data:= import (data_n)

Action_n

inoccupe

U ) pdate_n(data_n

EXPORT (data_n)

inoccupé

inoccupe

ampo t n process

Fig. 7.17 : Modèle de lecture de données dans une ISR.

7.3 Modèle d'exécution pour l'environnement

La modélisation de l’environnement n’est pas une nécessité en soi mais permet de grandement faciliter le processus de simulation en fermant le modèle. Lorsqu’il n’est pas modélisé, c’est à l’opérateur de remplir son rôle en émettant des signaux à destination du modèle de l’application, ce qui devient particulièrement difficile quand l’environnement est régi par des lois d’évolution complexes.

7.3.1 Source d'interruption et alarme périodique

En ce qui concerne les sources d’interruptions, on propose de garder les deux types de sources d’interruptions proposées dans la précédente partie sans aucun changement. Donc, notre solution consiste à réutiliser la source d’interruptions régulière et la source d’interruptions irrégulière.

90

En ce qui concerne la source d'activation périodique (notée horloge dans la chapitre de modèle de contraintes), dans le modèle d'exécution, nous gardons la même modélisation que nous avons proposé précédemment (cf. 6.4 page 55 (chapitre 6)).

7.4 Contrôleur programmable des interruptions

Suit à la discussion portant sur l'ISR (cf. § 1.1.1.1), nous proposons un modèle de la partie matérielle, que l'on appel le PIC, liée à l'interruption [193]. Le PIC (Programmable Interrupt Controller) est une pièce du matérielle qui permet de gérer les interruptions et d'épargner à l'OS de tous les détails d'aspect électroniques des files d'interruption. En général, on distingue plusieurs types de PIC en fonction des exigences du système :

PIC avec masquage : Le système masque le niveau d’interruption jusqu’au moment où le système fini le traitement de la dernière interruption reçue (la démasquage est fait par l’application).

PIC avec sauvegarde : il peut sauvegarder toutes les interruptions venant de l’extérieur pour qu'aucune des ces interruptions ne soit perdue.

PIC avec priorités : il permet de configurer plusieurs niveaux de priorités pour des interruptions différentes.

7.4.1 La modélisation du PIC en SDL

Il est à noter que, dans le cas de notre étude, nous nous limitons à la modélisation de PIC avec masquage.

La figure 7.18 présente la modélisation du mécanisme du masquage des interruptions dans un PIC. En fait, nous présentons le PIC comme un bloc type de SDL qui consiste, d'un seul processus noté PIC. Ce processus contient deux états. L'état de départ est démasque où le PIC est prêt à transmettre les interruptions à l'ISR. Si le PIC reçoit un ordre de masquage des interruptions du niveau niv à la réception de signal Mask_IT_n(niv), le processus PIC change son état à l'état masque. A l'état masque, toute interruption reçue est perdue. Par ailleurs, le PIC peut, dans cet état, recevoir soit un ordre de démasquage représenté par UnMask_IT_n(niv). Il revient alors à l'état démasque. Soit il reçoit le signal EOI_n en signifiant la fin du traitement de l'interruption précédente qui lui permet de revenir également dans l'état demasque.

Le modèle proposé est une première version. Une amélioration considérait à placer le niveau niv en paramètre du signal entrant (IT_niv_n) et d'expliciter ainsi des états de masquage dépendant du niveau niv.

91

7.4.2 La sémantique du PIC en IF

L'automate donné dans la figure 7.19 représente la traduction automatique de la modélisation du PIC qui est déjà présenté dans la figure 7.18.

7.5 Politique temps réel

Nous avons présenté dans le chapitre du modèle de contraintes, des politiques temps réel, tel que le filtrage et la gestion d'exception temporelle (dépassement d'une échéance). Ceci afin de contrôler les contraintes temps réel et de lancer des actions correctives prévues à l'avance.

Nous présentons les éléments pour implémenter un contrôle d'échéance.

A l'exécution, afin de contrôler les dépassements d'échéances associées aux événements dans le modèle d'exécution et l'âge de données, plusieurs solutions sont possibles. Ce contrôle est basé sur des informations telles que la date d'arrivée, la date de la fin d'exécution de l'action correspondantes et l'échéance de chaque événement. A partir de ces trois informations, nous pouvons vérifier si ces contraintes sont respectées.

Fig. 7.18 : la modélisation du PIC avec masquage

block signaltype

PIC_niv_n

PICprocess< IT ;

k_IT(integer)> IT_n; Un as

signal Mask_IT(integer), Msignal

G_ISR

IT_n,

Mask_IT_n,UnMask_IT

IT_n demasqueroute2

IT_n

route1

IT_n, Mask_IT_n,U

nMask_IT

PIC

IT_niv_n

IT_n (niv)

Mask_IT_n(niv)

masquedemasque

IT_niv_n

UnMask_IT_n(niv)

demasque EOI_n

masque demasque

Fig. 7.19 : la sémantique en If du PIC

92

Après avoir capturé ces informations dans le modèle d'exécution, le concepteur peut utiliser plusieurs mécanismes afin de vérifier et réagir dynamiquement si une échéance est dépassée.

Utiliser un chien de gare combiné avec une tâche logicielle. Utiliser une fonction type nommée check associé à une tâche logicielle.

7.5.1 Utilisation du chien de garde

En ce qui concerne le premier mécanisme, après la réception d'un événement (par exemple un TOP d'horloge) à un moment donnée t dans le modèle d'exécution, on arme un chien de garde par un valeur de timeout qui est égale à d (d est l'échéance liée à l'événement TOP). A l'expiration du chien de garde (dépassement de l'échéance), une routine d'alarme est activée afin de, par exemple, supprimer la tâche qui prend en compte le traitement correspondant à l'événement. Parallèlement un événement interne peut activer une tâche logicielle qui se charge de l'action corrective prévue pour ce dépassement. Au cas où celle-ci termine son exécution en respectant son échéance, un désarmement du chien de garde doit être effectué.

Nous proposons à cet effet deux primitives types, SET_wd, qui sont utilisées afin d'armer le chien de garde, et RESET_wd , qui est utilisé pour désarmer le chien de garde.

7.5.1.1 La modélisation en SDL

La figure 7.20 présente une modélisation en SDL de ce chien de garde en utilisant un bloc type nommé WD qui contient un seul processus WD. Ce dernier contient de deux états (desarme et arme). L'état du départ est desarme où le chien de garde peut recevoir un signal d'armement. Ce processus arme un timer de SDL avec la valeur de timeout d (d est la contrainte à observer) et change son état à l'état arme. Si le timer C expire son timeout avant la réception du signal RESET_wd, le chien de garde peut lancer une action corrective prévue à l'avance par l'envoi d'un événement interne à la tâche logicielle mise en place à ce propos (msg_i_n). Il peut aussi envoyer le signal Delete_n à la tâche correspondante afin de signaler le non respect de la contrainte à observer.

En fait, nous divisons ces activités en deux parties : la partie obligatoire consiste à l'armement/désarment du chien de garde. La partie optionnelle consiste à activer une tâche logicielle prévue à l'avance à ce propos. Afin de donner la possibilité au concepteur pour qu'il puisse choisir le mode à utiliser, nous proposons deux solutions. La première solution consiste à modéliser un chien de garde avec une activation d'une tâche logicielle (figure 7.20). La deuxième solution consiste à modéliser le chine de garde selon la partie obligatoire. C'est-à-dire de supprimer, de la modélisation donnée dans la figure 7.20, les deux signaux à envoyer msg_i_n et Delete_n.

93

G_wd

SET_wd_n,RESET_wd_n

msg_i_n,Delete_n

route

msg_i_n, Delete_n

SET_wd_n, RESET_wd_n

WD

block signaltype

WD_A< SET_wd_n, RES

uratio ; ET_wd_n;

synonym d d n signal msg_i_n, Delete_n >

process WD

desarme

SET_wd_n

SET (d,C)

arme

arme

RESET_wd_n

RESET (C)

desarme

msg_i_n

Delete_n

desarme

C

timerdcl

C;; duration d

Fig. 7.20 : la modélisation du chien de garde

L'utilisation des primitives (SET_wd, RESET_wd) dans notre boîte à outils est donnée par la figure 7.21. Nous suggérons, d'une part, d'ajouter la primitive SET_wd après la réception d'un événement (dans la figure7.21 après la réception de TOP_n). D'autre part, nous ajoutons la primitive RESET_WD_n après la réception de l'événement Fin_afaire.

7.5.1.2 La sémantique en IF 2.0

La traduction automatique de ces deux modélisations (figure 7.20 et 21) en IF est donnée par la figure 7.22. Le seul point à noter dans cette traduction est le remplacement de timer C en SDL par l'horloge IF notée C.

Fig. 7.21 : l'utilisation des primitives du chien de garde

process ALR

initiale

inoccupe

TOP_n

SET_wd_n

Afaire

Sig_TOP_n

Pprocess T

inoccupe

init

attente

Sig_TOP_n

Afaire

pret

pret

Fin_afaire

RESET_wd_n

attente

Delete_n

attente

94

Fig. 7.22 : la sémantique du chien de garde avec son utilisation

Il est à noter que si la date de l'armement notée t est différente de la date d'arrivée de l'événement considérée, il existe un décalage noté ∆t (= t - @(evt)). Le timeout doit être alors différent de l'échéance (timeout = d -∆t). Enfin, la différence entre la date d'armement et la date d'arrivée d'événement doit être inférieur de l'échéance (si ∆t > d timeout est un valeur négative qui signifie que l'échéance est déjà dépassée). Si le concepteur ne prend pas en compte ce décalage de datation ∆t, la vérification d'échéance est fausse.

7.5.2 Utilisation de la fonction check

En ce qui concerne le deuxième mécanisme de contrôle d'échéance, au cours ou à la fin de l'exécution de l'action correspondante à un événement, le concepteur peut injecter l'appel d'exécution de la fonction type nommé check.

7.5.2.1 La modélisation en SDL

La modélisation de ce mécanisme en SDL est donnée par la figure 7.23. Une fois que l'événement attendu est envoyé (soit dans l'AL ou la sourceIT), nous estampillons cet événement (par exemple si l'événement est TOP, (TOP_est := now). Ensuite, nous exportons cette information et son rang i afin de l'utiliser par la suite. D'une manière similaire nous datons l'envoi de l'événement Fin_Afaire dans le processus Afaire (Fin_Afaire_est).

Dans la tâche qui prend en compte le traitement de cet événement, nous appelons la fonction check. Cette fonction vérifie l'équation : @(e2)-@(e1) < d (vérification à la fin de l'échéance)(formule 6 page 65) où @(e1) correspond à TOP_est (cf. figure 7.21) et @(e2) correspond à la date de l'émission du signal Fin_afaire (son estampille est Fin_afaire_est) . Si cette condition n'est pas respectée ou un autre signal TOP est arrivé avant l'émission du signal Fin_Afaire (i ≠ j où i est le rang du TOP_n envoyé et j est le rang de l'action qui se termine son exécution), une faute temps réel est détectée. En effet, dans un système temps réel correct et selon les principes de RMA, une tâche périodique termine son exécution avant sa prochaine invocation. Lorsque une faute est détectée, une tâche logicielle est activée (msg_i_n to SW) pour arrêter la tâche en cours si nécessaire et lancer une action corrective.

95

process AL

Dcl exported i integer, TOP_est time;Timer C;

i:=0

SET (now ,C)

inoccupe

C

i:=i+1

TOP_est:=now

TOP_n

EXPORT (TOP_est,i)

inoccupe

procedure checkfpar in i , j integer, in Deb, Fin time

i=jand

Fin-Deb <D

FALSE

msg_i_n TO SW

TRUE

process PT

imported Fin_Afaire, TOP_est time;dcl exported Fin, Deb time;

initiale

j:=0

attente

Sig_TOP_n

Afaire

pret

pret

Fin_Afaire

j:=j+1

Fin:=import(Fin_Afaire_est),Deb:=Import (TOP_est),

i:=import(i)

check (Deb,Fin,i,j)

attente

Fig. 7.23 : Une utilisation de la fonction check après la fin d'une activation périodique

7.5.2.2 La sémantique en IF 2.0

Dans la figure 7.24, nous présentons modélisation en IF. Nous avons utilisé l'horloge globale c pour dater les évènements (les TOP dans cet exemple). Nous avons aussi utilisé la variable TOP_est comme une variable globale dans le processus ALR. L'affectation (TOP_est := timeval(c)) est utilisé pour transférer la valeur de horloge en entier.

Du coté du processus Afaire, à la fin de l'exécution de l'action Afaire, une autre lecture de l'heure est effectuée par Fin_Afaire_est := timeval(c), ensuit la vérification de l'échéance va être achevé en utilisant la garde suivant Fin_Afaire_est – TOP_est > d. La variable Fin_Afaire_est est aussi une variable globale. Si cette condition est remplie ou le rang de l'événement TOP et le même que de celui l'action j, un dépassement d'échéance est détecté, un envoi du signal msg_i_n vers une tâche logicielle SW afin d'exécuter une action correspondante à cette violation de la contrainte temporelle.

Il est à notre que IF ne possède pas la notion de procédure de SDL. A ce fait nous avons remplacé ce mécanisme par un état instable noté check afin de vérifier la condition ci-dessus.

96

La sémantique d'une utilisation de la fonction check dans une tâche périodique

Il est à noter que dans cet exemple d'utilisation de la fonction check, la détection du dépassement de l'échéance est effectuée après la fin de l'exécution de l'action. Pour un système temps réel à contraintes dures la vérification doit être faite avant la fin de l'action. On pourra, par exemple, décomposer l'action en deux A1 et A2, et placer check entre ces deux actions. Il est à noter que les variables utilisées dans IF (inclue les horloges) doivent être avec une condition de réinstallation sinon le modèle explose (à cause d'incrémentation infinie des variables). De ce fait, nous avons ajouté la condition (if j=10).

On peut aussi utiliser check pour implémenter des politiques de réaction aux fautes liées à contraintes de validité.

7.6 Politique d’ordonnancement

Comme nous l'avons énoncé au début de ce chapitre, notre objectif a été de définir toutes les informations portant sur l’architecture logicielle du système afin de produire une implémentation temps réel. Pour compléter ce modèle, nous devons définir la politique d’ordonnancement à suivre lors de l'implémentation pour déterminer ou calculer les priorités des tâches.

Les techniques d’analyse d’ordonnançabilité ont pour but de déterminer si, pour une politique d’ordonnancement et une configuration de tâches fixées, il est garanti que les échéances des tâches sont toujours respectées. La majorité des travaux sur les techniques d’analyse d’ordonnançabilité considèrent une politique d’ordonnancement des tâches en ligne, préemptive, à priorités (fixes le plus souvent, parfois dynamiques).

Pour les priorités fixes, les algorithmes optimaux (au sens production d'un un ordonnancement valide s'il existe) d’attribution des priorités ont été définis pour certaines classes de problèmes. Ainsi, l’algorithme RM [64] (qui attribue les priorités aux tâches dans l’ordre inverse de leurs périodes) ou DM [98] (qui attribue les priorités aux tâches dans l'ordre inverse de leur échéances relatives) sont optimaux pour l'ordonnancement à priorité fixe de tâches périodiques, indépendantes, à échéance sur requête et à départs synchrone. ED [134] est lui optimal pour tout ordonnancement de la même classe de problème (ED : à un instant donné, la tâche la plus prioritaire (parmi les tâches prêtes) est celle dont l’échéance est la plus

97

proche). La plupart des exécutifs multitâches fournissant des mécanismes d'ordonnancement à priorité fixe, on préfère une affectation statique des priorités.

Dans notre modèle les priorités sont attribuées aux tâches modélisées par des blocs types : PT, SW, PS et ST. On considère, en effet, que les routines sont exécutées à priorité maximale.

La politique d'ordonnancement à suivre par le système est donnée par un commentaire formel noté PO (politique d'ordonnancement), si PO = FP (Fixed Priority), les priorités des tâches sont fixées par des commentaires (figure 7.23). Dans les autres cas (PO = RM ou DM) les priorités sont attribuées par l'ordonnanceur lui-même selon l'algorithme d'ordonnancement choisi.

Dans le cas de RM, la période considérée est pour le PT ou le PS, la période du TOP_n pour SW la fréquence minimale dmin de l'IT ou du MSG. Pour une SW tâche logicielle on considère la période ou la fréquence de la tâche qui l'activité.

Dana le cas de DM, on considère pour PT, respectivement une SW activitée par une IT ou MSG, le délai associé au TOP_n traité, respectivement l'IT ou le MSG traitée. Pour un PS on considère le délai associé au TOP pour une SW.

La Le calcul d'ordonnancement pour la vérification des contraintes temporelles de l’application est à considérer comme une étape de validation et est détaillé par la suite de l'étude.

Au titre d'illustration nous allons montrer comment nous pouvons attribuer des priorités aux tâches. La figure 7.25 présente une proposition d’attribution des priorités aux tâches modélisées.

PO := PF // politique d'ordonnancement à priorité fixe

system est_1 t

can1

TOP_1 can2

Sig_TOP_1

can3

Sig_TOP_2

can4

IT_1

can5

Sig_IT_1

can6

MSG_loc_A_3

can7

MSG_loc_A_3

AL_1:AL ALR_1: ALR PT_1:PT

NP := 120

AL_2:AL

PS_1:PS

NP := 150

ISR_1:ISR_M

can2

TOP_2 ALR_2: ALR

SW_trace:SW

NP := 130

Eext:sourceITreg

Fig. 7.25 : Utilisation d’annotation formelle pour NP (niveau de priorité)

7.7 Eléments sépcificques

En fait, ce modèle d'exécution est un modèle indépendant de la cible. De ce fait, il est néscessaire d'ajouter un autre type d'annotation formelle qui sert à déterminer la cible à

98

utiliser lors de la génération de code. Nous proposons l'annotation SE (système d'exploitation) dont sa valeur peut être 0 pour la cible VxWorks ou 1 pour la cible Win32).

7.7.1 La base de temps

En fait, dans le modèle d'exécution (SDL et IF), nous avons utilisé des timers et des horloges pour spécifier les contraintes temps réel. Par exemple, nous avons spécifié qu'un événement périodique TOP peut être envoyé chaque P d'unité de temps, sans préciser la valeur de l'unité de temps.

Lors de génération de code (pour Win32 ou VxWorks), nous devons préciser la correspondance entre l'unité de temps utilisée dans le modèle d'exécution et l'unité de temps utilisé dans la cible. Dans la cible VxWorks, les alarmes (watchdog) sont armées par un certain nombre de ticks. Chaque tick, par défaut, correspond à un soixantième de seconde. Donc la résolution d'une alarme sous VxWorks est un soixantième de seconde. Dans le cas de Win32, l'unité de temps utilisée pour armer les timers, est exprimée en millisecondes, donc la résolution est d'une milliseconde.

Afin de préciser l'unité de temps du modèle d'exécution, nous proposons de traduire, lors de la génération de code, chaque unité de temps du modèle d'exécution par un tick égal à un soixantième de seconde. Cette unité est la même que celle de VxWorks, donc elle ne change pas lors de la génération de code pour VxWorks. Dans le cas de la génération de code pour Win32, nous suivons la même résolution que VxWorks, donc la valeur du timer ce Win32 est calculée comme suit :

uDelay (en millisecondes) = nombre d'unité de temps * 16.66.

Une extension du modèle serait de proposer un commentaire formel pour exprimer la valeur d'une unité de temps.

7.8 Mode d'utilisation

Nous montrons maintenant le mode d'utilisation (le modèle d’interconnexion) de ces composants via une grammaire décrite classiquement en forme BNF (Backus Naur Form) (voire annexe 1).

Dans le tableau suivant, on montre toutes les communications par signaux qui peuvent être véhiculées entre les composants que nous avons proposés ci-avant.

AL ALR PT PS ISR SW WD PIC Procédé_ext ST AL - TOP_n - - - - - - - -

ALR - - Sig_TOP_n Sig_TOP_n - - SET_wd - - - PT - - msg_i_n - MSG_loc RESET_wd - - -

Procédé_ext - - - - - - - IT_niv_n - - PIC - - - - IT_n - - - - -

ISR - - - Sig_IT_n - - SET_wd Mask_IT EOI UnMask_IT - Sig_IT_n

PS - - - msg_i_n - MSG_loc RESET_wd UnMask_IT - - SW - - - msg_i_n - MSG_loc RESET_wd UnMask_IT - - ST - - - msg_i_n - - RESET_wd UnMask_IT - -

Tableau 2 : la communication entre les composants de notre boîte à outil

99

En effet, afin d'avoir une conception correcte et cohérence, le concepteur doit respecter les règles d'interconnexions entre les blocs. En fait, l'utilisation de ces règles est justifiée par les arguments suivants. Prenons, par exemple, le traitement des tops périodiques. Dans ce cas, nous ne pouvons pas utiliser une routine d'interruption avec une tâche périodique. En effet, dans le traitement des interruptions nous ne pouvons masquer/démasquer le niveau d'interruption, or les tops périodique ne possèdent pas ces niveaux. Enfin, ces règles d'interconnexions préparent la modélisation de type RMA en associant à chaque action une seule source d'activation.

7.9 Conclusion

Nous avons proposé dans ce chapitre une boite à outils dédiée à la conception de système temps réel. Cette boite à outils est constitué de blocs type SDL spécialisés afin de modéliser les éléments de base de l'application. En ce sens, nous nous rapprochons d'un langage tel que LACATRE.

Cette boite à outil propose un ensemble de modèle pour les entités d'OS standard comme les routines (interruptions et alarmes), les tâches (périodiques, apériodiques et serveurs), et des mécanismes spécialisés permettant de gérer les dépassements d'échéances. Enfin, nous avons donné le mode d'utilisation de ces composants.

Pour chaque élément, nous avons précisé la sémantique IF afin de préciser le comportement temporel. Nous avons donnée également la possibilité d'attribuer des priorités fixes aux tâches en utilisant des commentaires formels.

L'utilisation des types SDL, facilite grandement la réutilisation des éléments de la boîte à outils. Nous présentons maintenant, à partir de cette boîte à outil, un générateur de code vers des cibles VxWorks et Win32. Par ailleurs, la formalisation IF nous permet de vérifier la correction du modèle d’exécution par rapport à sa spécification. Ces deux perspectives sont le sujet des deux chapitres suivants.

100

8 Génération de code

8.1 Introduction

Tous les modèles développés sont indépendants du système d'exploitation utilisé. C'est uniquement lors de l'étape de génération de code que l’application est spécialisée pour une plateforme d'exécution donnée. Ainsi nous pouvons générer différents codes pour une même application. Le code produit peut, soit servir à la simulation, soit être spécialisé pour une plateforme cible donnée.

L'implémentation du système aboutit à deux parties : une partie matérielle et une partie logicielle. Concernant la partie matérielle, nous avons supposé que le système en question est un système monoprocesseur (cf. §6.1 de chapitre modèle de contraintes), donc nous nous concentrons sur la réalisation de la partie logicielle ou code. Le code est le résultat de la compilation du modèle d’exécution présenté dans la partie précédente dans un langage applicatif choisi pour le codage (cf. figure 8.1).

Dans ce chapitre, nous ne traitons pas les phases d'optimisation, souvent nécessaires pour les applications temps réel. En effet, ces dernières sont souvent embarquées et possèdent de ce fait des contraintes spécifiques (par exemple de taille) non traitées ici.

Le code est composé de tâches et de leur ordonnancement afin d'assurer la cohérence temporelle lors de l’exécution. L’implémentation est faite à l'aide de langages concurrents ou environnements de programmation qui aident à déclarer des processus ou des tâches dont l’ordonnancement est assuré au travers d’un noyau ou d’un exécutif, généralement temps réel.

Une des solutions possibles pour la réalisation est de réaliser un noyau ou un exécutif temps réel approprié adapté aux besoins. Toutefois, l’écriture d’un noyau est dédiée aux systèmes embarqués avec contraintes de place. Ce travail s'approche des travaux d'optimisation non traités dans cette étude [65]. Cette solution ne sera donc pas détaillée dans la suite de ce document.

L'autre solution est de s'appuyer sur des langages de haut niveau, couplés soit avec des exécutifs temps réel largement diffusés, tels que : VRTX®, VxWorks®, etc. ou des systèmes d'exploitations classiques tels que Win32® ou linux®. Donc notre étude, nous utilisons le langages de haut niveau C pour la description des actions et pour le noyau les cibles largement utilisées et diffusées que sont Win32® et VxWorks®.

Cette solution est détaillé dans le reste de ce chapitre comme suit : avant de commencer à présenter les différentes étapes pour réaliser le prototype du générateur du code, nous présentons brièvement les deux cibles que nous allons utiliser. Nous donnons ensuite les motivations de notre choix. Enfin, nous étudions les correspondances entre les éléments du modèle d’exécution et ceux de l’implémentation (OS classique Win32® et Exécutif temps réel VxWorks®) afin de donner les règles de génération automatique de code.

Les objectifs de ce chapitre sont multiples. Le premier est de montrer que le modèle d'exécution est complet du point du vue tâches et séquencement des actions. Le deuxième est

101

de préciser modèle de communication entre processus (aspect non détaillé dans le modèle d'exécution). Enfin, le troisième aspect est de vérifier que le générateur de code ne modifié pas la sémantique définie, d'une part, dans le modèle d'exécution et d'autre part celle de SDL.

Résultats Langages et cibles

SDL

(VI) Code

(IV) Modèle d’exécution

Compilateur

C/Win 32 C/VxWorks

Fig. 8.1 : Compilation

8.2 Principe

Le compilateur vérifie le modèle d’exécution (coté syntaxique et sémantique) et génère automatiquement un programme cible correspondant. La figure 8.2 présente le schéma général du compilateur qui nous avons réalisé. Nous y retrouvons les grandes phases classiques : l’analyseur lexical, l’analyseur syntaxique, l’analyseur sémantique et le générateur de code. Ces phases vont être développées par la suite.

L’entrée de notre compilateur est un fichier généré par les outils (SDL « fichier de suffixe .pr») qui correspond au modèle d’exécution. La sortie est un squelette de code décrit en langage C exécutable qui représente le code généré. Afin de produire un code complet exécutable, ce squelette généré doit être complété par le code utilisateur qui présente le corps des actions des tâches généré et des routines (Le bloc noté "Code utilisateur" dans la figure 8.2).

La génération automatique de code est intéressante sur de nombreux points :

1. Elle évite les erreurs humaines de traduction 2. Elle permet de compiler de plus gros programmes 3. Elle peut être incluse dans des chaînes de compilation. 4. Elle vérifie la correction du modèle de haut niveau.

Compilateur Analyse lexicale

Analyse syntaxique Analyse sémantique Génération de code

Modèle

d’exécution

Squelette de Code généré

C/Win32 C/VxWorks

Code d’utilisateur

Code exécutable

Fig. 8.2 : schéma général de la Génération de code

102

Nous allons commencer par déterminer les modèles de communication non détaillés dans le modèle d'exécution.

8.3 La communication entre objets

Dans cette partie, nous définissions pour chaque communication entre éléments du modèle d'exécution, un modèle de communication correspondant dans le code cible. Ce modèle ne doit pas modifier le séquencement des actions et la sémantique du modèle d'exécution.

La tâche périodique est activée par un top périodique signalé par la routine d’alarme une fois que le timeout de l’alarme est expiré. Au cas où la routine d’alarme ne lit pas des données, dans ce cas, elle ne transmet pas d’information à la tâche périodique. Si on fait l'hypothèse que l'application possède un comportement temps réel correct. C'est-à-dire la tâche se termine avant l'arrivée d'un TOP suivant (échéance inférieure à la période). Nous pouvons utiliser le sémaphore binaire (un TOP maximum à mémoriser) comme un moyen de communication entre la routine d’alarme et la tâche périodique (cf. figure 8.3). Si, la tâche périodique sauvegarde les TOP pour les traiter ultérieurement nous devons utiliser un sémaphore à compte (échéance supérieure à la période).

Dans le cas d'une lecture de données, la routine d'alarme doit transmettre les données lues à la tâche périodique. Dans ce cas de figure, nous proposons d'utiliser une boîte aux lettres entre la routine d'alarme et la tâche périodique associée. Une donnée partagée ne peut pas être utilisée car la routine ne peut pas accéder à une donnée partagée par Mutex (pas d'attente possible dans une routine).

Dans le cas du serveur à scrutation, nous avons deux types de signaux (le Sig_TOP_n qui ne porte pas d’informations et Sig_IT_n qui véhicule des informations), nous proposons alors d’utiliser une seule boîte aux lettres avec une structure à deux champs, un pour véhiculer l’information et l’autre pour distinguer entre les informations et les tops (figure3).

Dans le cas d'une communication entre une routine d'interruption et une tâche sporadique, deux moyens de communications sont possibles. Au cas où nous effectuons une opération de lecture de donnée dans la routine d'interruption (figure 8.4), il est indispensable d'utiliser une boîte aux lettres afin de stocker les données en plus des signalisations. En revanche, si la routine ne lit pas de données du registre, nous proposons d'utiliser un sémaphore à compte entre la routine et la tâche. Ce sémaphore permet la sauvegarder des signalisations Sig_IT_n en provenance de la routine.

En général, nous utilisons les tâches logicielles pour des traitements de moindre importance. Nous devons donc sauvegarder les informations envoyées à la tâche logicielle. A ce propos, nous proposons d'utiliser une boîte aux lettres entre les expéditeurs et une tâche logicielle.

L'utilisation d'un moyen de communication de type boîte au lettres ou sémaphore à compte dans un système exige quelques informations pour déterminer par exemple la taille maximum d'une boîte aux lettres ou la capacité maximum d'un sémaphore. Ces informations, en fait, ne sont pas précisées dans le modèle d'exécution et sont donc fixées arbitrairement. En perspective de ce travail, une étude serait l'étude du comportement de l'application afin de

103

dimensionner correctement ces éléments de communication selon le comportement [37]. L'autre information porte sur la politique de stockage dans les Boîtes Aux Lettres (BAL) soit FIFO, soit avec priorité. Afin de préserver la sémantique de SDL il faut choisir le modèle FIFO. Par exemple dans VxWorks®, il ne faudra pas utiliser le message dit urgent.

Légende

V

Bal

Sémaphore

Tâche

Source d'interruption

Alarme

ISR IT

Sig_TOP

Sig_IT_ni

AL

TOP

ALR

PT

SW

Bal 1

Bal 2

Sem 1

Msg_i_1

PS

VTOP

V ALR

Sig_TOP

AL

Fig. 8.3 : moyens de communications sans lecture de données selon le formalisme LACATRE

8.4 Les annotations formelles : La politique d’ordonnancement et la priorité

Les annotations que nous avons proposées d’intégrer dans le modèle d’exécution (cf. §7.6 et 7.7 de chapitre modèle d’exécution) portent des informations additionnelles et spécifiques à la plateforme. L'annotation défini le type de système (SE = 0 VxWorks ou 1 Win32) et est

Légende

Registre

AL : Alarme ALR : Routine d’Alarme PS : serveur à scrutation PT : Périodique tâche SW: tâche périodique Bal boîte aux lettres Sem : Sémaphore ISR : routine d'interruption TS: sporadique tâche

AL ALRTOP Sig_TOP (données)

Registre Données

IT ISR

Sig_IT V

sem2 cpt Bal 3

PTTS

SW Bal 4

Fig. 8.4 moyens de communications avec lecture de données selon le formalisme LACATRE

104

interprété, lors de l’implémentation, comme un directive pour le compilateur afin de générer un code correspondant à la cible choisie.

L'autre annotation qui est prise en compte lors de la génération de code est la politique d'ordonnancement (PO politique d'ordonnancement). Il est possible de définir plusieurs types de politiques d'ordonnancement comme PF, RM ou ED).

Enfin, la base de temps (TU = ms or s) permet de définir 'unité de temps utilisée).

Si le système utilise une politique d’ordonnancement de type Priorité Fixe (FP), les annotations qui définissent les priorités à assigner aux tâches sont prises en compte lors de la génération du code. Cet assignement est effectué lors de la création des tâches (cf ci-après).

8.5 Code pour des OS classiques embarqués (Windows)

8.5.1 Windows et temps réel

Win32® n’est pas un système temps réel en raison de plusieurs problèmes. Le premier problème est la gestion des niveaux de priorités avec seulement 32 niveaux de priorités utilisables. Ce n’est pas suffisant pour décrire une application temps réel multitâches complexe.

Le deuxième problème est la gestion des interruptions. Les interruptions sont manipulées en deux étapes. La première partie de traitement est fait dans l'ISR et le reste du traitement est dévolu à un DPC (Deferred Procedure Call) qui est exécuté ultérieurement. Comme les DPC sont placés et gérés en FIFO, aucune garantie de temps pour la prise en compte et l’exécution d’une DPC n'est fournie. Ceci réduit la prédictibilité temporelle du système et par conséquent rend Win32® impropre aux applications temps réel.

De plus quelques tests basiques démontrent rapidement la non prédictibilité des timers et des durées d’exécution des primitives systèmes [14].

Ne pouvant générer de code temps réel Win32® est dédié au prototypage. Il est en effet, intéressant d'évaluer la possibilité de générer du code pour une telle cible à partir du modèle d'exécution proposé.

8.5.2 Du modèle d’exécution à Win32®

Le but de cette partie est de parcourir les correspondances entre les éléments du modèle d’exécution et ceux du système Win32®.

8.5.2.1 La communication entre les objets

Nous avons proposé dans le § 8.3 de ce chapitre deux hypothèses pour définir la communication entre les objets. En conclusion nous avons proposé d'utiliser les sémaphores et les boites aux lettres (BAL).

105

En ce qui concerne les créations des BAL sous Win32®, elles sont créées et détruites de façon implicite car elles sont associées soit à des tâches1 soit à des fenêtres Windows. Les BAL sont mono-lecteur et multi-écrivains. Ce modèle est correct dans le modèle d'exécution les BAL sont toujours mono-lecteur La primitive utilisée pour déposer à boîte aux lettres est PostThreadMessage, celle utilisée pour retirer est GetMessage.

Par analogie, les primitives utilisées pour déposer ou retirer dans un sémaphore sont respectivement RealeaseSemaphore et WaitForSingleobject.

8.5.2.2 La routine d’interruption

Etant donné l’impossibilité d’accéder à la table des vecteurs d’interruption, Win32® limite la possibilité de gérer les interruptions. Les interruptions sont limitées aux interruptions systèmes. Au titre d’illustration, l’interruption clavier (CNTRL + C) est autorisée. Cette interruption est obtenue grâce à l’appel de la fonction C Signal. La fonction Signal a comme paramètre le nom de la procédure à exécuter lors de son arrivée.

Afin de traduire la routine d'interruption présentée dans le chapitre du modèle d'exécution de processus nous proposons de coder la routine d’interruption ainsi :

8

WTfpl

8

l

1

Signal (SIGINT, fISR_nom); Void _cdecl fISR_nom (int arg) PostThreadMessage(h_Thre_PSnom, WM_MSG, NULL, (LPARAM));

/* Envoi un message à la tâche sporadique ou au serveur à scrutation.*/

.5.2.3 Alarme

Pour réaliser l’alarme proposée dans le modèle d’exécution, nous utilisons le timer de in32®. Ce timer est paramétré par une période. Le timer Win32® possède deux modes :

IME_PERODIC (activation répétée) ou TIME_ONESHOT (activation effectuée une seule ois). Nous conservons le premier pour l'alarme (AL) et le second pour les timers dans les olitiques temps réel. L'unité de temps utilisée s'appuie sur l'annotation formelle définie dans e modèle d'exécution.

UINT idtimer0; …… idtimer0 = timeSetEvent(Période, 1, AL_1, NULL, TIME_PERIODIC); /* initialisation d'une alarme périodique */ …..

.5.2.4 La routine d’alarme

La routine d’alarme est le morceau de code qui est exécutée quand le timeout est expiré de ’alarme. Cette routine est déclarée ainsi:

En fait, dans Windows, le terme utilisé pour présenter une tâche est le thread.

106

void CALLBACK ALR_nom ( HWND hwnd, UINT message, UINT idTimer, DWORD dwTime)

/* Envoi un message à la tâche périodique ou au serveur à scrutation.*/ ReleaseSemaphore(h_SemPT, 1, 0);

8.5.2.5 La tâche périodique

En fait, la tâche périodique est présentée par une tâche Win32® qui boucle infiniment (boucle FOREVER). Cette dernière est déclenchée suite à la une réception d’une unité dans un sémaphore).

8

fdvcc

int fPT_1 (void *lp_param) for ( ; ;) WaitForSingleObject(h_SemPT , INFINITE); /* attendre sur le sémaphore h_SemPT*/ /* Le corps de la fonction Afaire */ return 1;

.5.2.6 Le serveur à scrutation

Le serveur à scrutation est implémenté par une tâche et sa boîte aux lettres associée. En onction du message reçu, le serveur doit exécuter une opération (soit une sauvegarde en cas e message, soit un traitement en cas de top). Cette opération est effectuée en utilisant une ariable booléenne notée present. Au cas où une signalisation d'une interruption est arrivée ase WM_Sig_IT, la valeur true est attribuée à cette variable qui permet d'exécuter l'action orrespondante à la prochaine signalisation de top "case WM_Sig_TOP".

int fPS_nom (void *lp_param) /* déclaration éventuelle d'une variable destinée à accueillir les données reçues */ MSG msg; bool present = false; for ( ; ;) GetMessage(&msg, NULL, NULL, NULL); /* extraire un message de la file d’attende*/ switch (msg.message) case WM_Sig_IT: temp = info; /* Sauvegarde*/ present = true; ; break; case WM_Sig_TOP: if (present) present = false;

Afaire() /* code utilisateur */ ; break; default: break; return 1;

107

8.5.2.7 La tâche logicielle

La tâche logicielle est implémentée par une tâche. La différence avec la tâche périodique est la source d’activation. En fait, le corps de la tâche dans le cas de tâche logicielle est une boucle infinie qui attend sur une boîte aux lettres.

int fSW_nom (void *lp_param) DWORD error; MSG msg; / *Déclaration éventuelle d'une variable destinée à accueillir les données reçues*/ for ( ; ;) GetMessage(&msg, NULL, NULL, NULL); /* attendre un message d'activation */

Afaire() /* code utilisateur */ return 1;

8.5.2.8 Le «main»

Afin de compléter le programme généré, un main doit être implémente pour gérer les créations et les destructions des éléments du programme.

Nous proposons une création statique. Nous commençons par la création de moyens de communication (boîtes aux lettres, sémaphores, ..) puis par la création de tâches. Ceci permet d'éviter l'activation d'une tâche qui se place en attente sur un élément de communication inexistant. Enfin, les alarmes sont armées et les routines d'interruption déclarées.

En ce qui concerne le sémaphore, sa création et destruction sont fait en utilisant respectivement CreateSemaphore et CloseHandle.

La destruction se fait dans l'ordre inverse suite à un événement applicatif noté Fin dans le modèle d'exécution.

8.5.2.9 La gestion de priorités

Pour la gestion de priorités, il s'agit de mapper les priorités, attribuées aux éléments de modèle d'exécution, aux tâches correspondantes, qui composent le code généré. En fait, Windows permet seulement de gérer 32 niveaux des priorités. De ce fait, le problème est de définir comment mapper un nombre potentiel de priorités uniques à des priorités locales fournies par le système cible utilisé.

En effet, ce problème peut être se divisé en deux cas :

Au cas où le code généré se compose d'un nombre de tâches inférieur aux niveaux de priorités proposés par la cible. Dans ce cas de figure, la solution est d'attribuer des nouvelles priorités de système en préservant l'ordre de priorités originale. Prenons

108

l'exemple d'un système composé de 5 tâches dont les priorités sont 10, 20, 30, 40 et 50. Dans ce cas, nous pouvons assigner les priorités 1, 2, 3, 4 et 5.

Dans l'autre cas où le nombre tâches est supérieur de celle supporté par le système utilisé, il faut donc attribuer la même priorité à plusieurs tâches (dans ce cas de figure, les tâches à le même priorité sont gérée en partage de temps). Nous montrons dans le tableau suivant commet nous pouvons mapper les priorités de modèle d'exécution (de 0 à 255) aux tâches générées.

Classe de priorité Niveaux de priorités utilisées dans le modèle d'exécution

Niveaux de priorités correspondants dans le code cible

1 255 - 239 31 (la niveau de priorité système) 2 238 - 222 30 (priorité réservée pour la tâche de CTR) 3 221 - 205 29 4 204 - 188 28 5 187 - 171 27 ------ --- ------ ---

32 15 - 0 0 Tableau 8.1 : mapping les priorités entre modèle d'exécution et Windows NT

8.6 Code pour des exécutif temps réel

8.6.1 VxWorks® et le temps réel

VxWorks® est un environnement multitâche qui permet la construction d’applications temps réel comme un ensemble de tâches indépendantes, chacune avec son propre flot d’exécution et son propre contexte [193]. Nous listons quelques points qui montrent que VxWorks est un exécutif temps réel.

VxWorks permet le traitement des interruptions matérielles (ISR) et fournit des Chiens de garde (Watchdogs) pour les interruptions liées à l’horloge du système. A chaque interruption sont associés une pile et un ensemble de registres du CPU, ainsi qu’un code à exécuter lors de l’occurrence de l’interruption. De même, chaque chien de garde est lié à un code à exécuter après l’écoulement d’un délai. Les routines exécutées par l’appel d’un chien de garde ont le même niveau de priorité que celles connectées à une interruption matérielle. Les chiens de garde héritent donc du niveau d’interruption de l’horloge du système.

VxWorks présente trois types de sémaphores : le sémaphore d’exclusion mutuelle, le sémaphore binaires et le sémaphore à compte.

En conclusion, nous pouvons dire que VxWorks est un exécutif temps réel complet, riche au sens implémentation, et facile à utiliser. Nous avons réalisé un prototype de générateur de code direct et complet qui prends en entrée le modèle d’exécution et génère en sortie le programme correspondant en respectant la sémantique du modèle d’exécution.

De façon similaire à Win32, nous donnons les correspondances entre les éléments de modèle d’exécution et ceux de l’exécutif VxWorks.

109

8.6.2 Du modèle d’exécution vers VxWorks®

8.6.2.1 La communication entre les objets

Par analogie de ceux qui présenté dans §8.5.3.1 concernant la communication entre les objets, nous citons les primitives utilisée dans VxWorks dans la communication entre objets.

En ce qui concerne les créations et les destructions des BAL sous VxWorks, elles sont faites en utilisant les primitives respectivement msgQCreate, msgDelete. La primitive utilisée pour déposer dans une BAL est msgQSend et celle pour retirer est msgQReceive.

En ce qui concerne le sémaphore, nous utilisons deux types de sémaphores qui sont le sémaphore binaire et le sémaphore à compte. La primitive de création n'est pas la même pour ces deux types, la primitive utilisée pour créer un sémaphore binaire est semBCreate, et celle de sémaphore à compte est semCCreate. En revanche, une seule primitive est dédiée pour la destruction de sémaphore, il s'agit de semDelete. Les primitives utilisées pour déposer ou retirer de sémaphore sont respectivement semGive et semTake.

8.6.2.2 La routine d'interruption

Bien que VxWorks n’exige aucune restriction sur le type d’interruption, la routine d’interruption (ISR) ne doit pas invoquer de fonctions qui peuvent bloquer la routine. Par exemple, semTake, malloc, free ne peuvent pas être utilisées car elles appellent des fonctions qui peuvent causer des blocages. Ainsi, toutes les créations, destructions sont interdites car elles utilisent les primitives malloc et free. De plus, une ISR ne doit pas réaliser une opération de type entrée /sortie à travers l’exécutif (par exemple: printf()). En effet, un appel vers un pilote d’un matériel peut bloquer le système.

En respectant le modèle d’exécution, le corps d'une ISR avec masquage est représenté à la figure 8.2 (chapitre modèle d'exécution) Cette routine commence par la primitive intLockLevelSet(int niv) pour masquer toutes les interruptions de niveau niv correspondant.

Void ISR_m_nom (int arg) intLockLevelSet( n ) /* masque l’interruption de niveau n */ Afaire (); /* code d'utilisateur */ /* envoi un message à la boîte aux lettres de PS */ msgQSend (bal_PSnom, (char *)&info, sizeof (info), WAIT_FOREVER, MSG_PRI_NORMAL);

Une fois la routine d’interruption codée, il faut lier cette routine au niveau d’interruption correspondant en utilisant la primitive intConnect qui est paramétré par le nom de la routine dédié et le niveau d'interruption.

8.6.2.3 L’alarme

La routine d’alarme sous VxWorks est un cas prédéfini d’une ISR, donc toutes les restrictions appliquées sur la routine d’interruption déjà listées doivent être appliquées à la

110

routine d’Alarme. L’alarme sous VxWorks est présentée par un chien de garde qu'il faut créer en utilisant wdCreate. Il faut, ensuite, associer à ce chien de garde la routine d’alarme en employant la primitive wdStart().

8.6.2.4 La routine d’alarme

En fait, le timer du chien de garde s’arme une seule fois. Pour les activations des tâches périodiques, la routine d’alarme elle-même, doit appeler la primitive wdStart pour réarmer le timer à chaque invocation, selon la période définie. L'unité de temps utilisée s'appuie sur l'annotation formelle définie dans le modèle d'exécution.

En fait, la routine d'alarme peut être associée à une tâche périodique ou à un serveur à scrutation. De ce fait, dans le corps de cette routine, nous devons signaler à travers un sémaphore ou boîte aux lettres à la tâche périodique au serveur à scrutation selon les hypothèses que nous avons proposé dans le § 8.3.

int ALR_nom (int val) wdStart (AL_nom, Période, ALR_nom, 0); Afaire (); /* code utilisateur */

/*signaler à une tâche périodique PT ou signaler à un serveur à scrutation PS*/ semGive (semPT_nom); ou msgQSend(balPS_nom,(char *)&info, sizeof (info), NO_WAIT, MSG_PRI_NORMAL);

return(0);

8.6.2.5 La tâche périodique

En fait, la tâche périodique est représentée par une simple tâche de VxWorks qui bouclé indéfiniment. Cette tâche est activée par l’alarme via un sémaphore.

8

spds

PT_id = taskSpawn ("PT_nom", NP, 0, 10000, fPT_nom,0,0,0,0,0,0,0,0,0,0); int fPT_nom(void) /* declaration */ for (;;)

semTake (semPT_nom, WAIT_FOREVER); /* lire la source d’activation*/ Afaire (); /* code utilisateur */

return (0);

.6.2.6 Le serveur à scrutation

De façon similaire au serveur à scrutation présenté dans le prototypage de Win32®, le erveur à scrutation est représenté par une tâche VxWorks®. Le serveur est divisé en deux arties. La première partie permet de mémoriser un événement en attente d'être traité. La euxième partie représente la vérification suite à un TOP s'il y a un ou des événements poradiques à traiter.

111

8.6.2.7 La tâche logicielle

Une tâche logicielle est une tâche VxWorks®. Cette tâche attend sur un boite aux lettres en entrée pour déclencher ses activités.

8

ecrd

ce

#define attente Time-out ; int fSW_nom(void) /* declaration */ for (;;)

msgQReceive (bal_nom, (char *)&info, sizeof (info), attente) Afaire (); /* code utilisateur */

return (0);

PS_id = taskSpawn ("PS_nom", 150, 0, 10000, fPS_nom,0,0,0,0,0,0,0,0,0,0); int fPS_nom (void) int presence; /* declaration des variables */ struct Info info; presence = 0; for (;;) msgQReceive (bal_PSnom, (char *)&info, sizeof (info), WAIT_FOREVER); if (info.type == 1) /* MSG */ presence = 1; /* sauvegarde */ else if ((info.type == 0) && (presence)) /* TOP */ presence = 0; info.type = 1;

Afaire (); /* code utilisateur */ return (0);

.6.2.8 Le «main»

Après avoir parcouru tous les correspondances entre les éléments du modèle d’exécution t ceux de l’exécutif temps réel VxWorks, nous devons compléter le code généré en prenant en ompte une phase de création (initialisation) de tout les objets et la phase de destruction. Les ègles que nous avons appliquées dans la description de ces phases pour le main dans la partie e prototypage sont applicables dans la génération de ce main.

Par analogie avec le main dans Win32® nous commençons par la création de moyens de ommunication (boîtes aux lettres, sémaphores, ..) puis par la création de tâches. La création t la destruction des tâches en VxWorks sont faites en utilisant respectivement les primitives

112

taskSpawn et taskDelete. Enfin, les chien de garde sont armées et les routines d'interruption déclarées.

8.6.2.9 La gestion de priorités

En ce qui concerne la gestion de priorités dans VxXorks, il est à noter qu'elle est plus simple car VxWorks® possède 256 niveaux de priorités. Ceci permet d'implémenter des applications temps réel complexes. Le mapping des priorités attribuées dans le modèle d'exécution aux tâches composant le code généré, est donc fait directement.

8.6.3 Restrictions sur l'action Afaire

Dans les modèles présentés précédemment (modèles de contraintes et d'exécution), nous avons présenté chaque action par l'annotation Afaire qui représente le code utilisateur. Le code généré est donc un squelette de code, que l’utilisateur doit compléter afin de compiler et exécuter ce code. Lors de génération de code cette action est remplacée soit par un appel de fonction, soit directement par du code C.

Des restrictions sont imposées sur le code de cette action. Il s'agit de préserver la cohérence et la sémantique du modèle d'exécution proposé précédemment. L'action Afaire ne doit pas contenir d'appel au service de l'exécutif, concernant les tâches et les objets de communication. En effet, l’ajout d'appel à l'exécutif modifie le séquencement des actions, soit l'analyse temporelle et donc la validation. Toutes les créations, destructions des tâches sont donc interdites. De plus il faut éviter d’invoquer certaines fonctions qui peuvent causer un blocage infini, par exemple l'attente d’un sémaphore). De même manière, l'action associée à la routine d'interruption doit respecter les restrictions système sur cette routine comme nous avons les présenté dans le § 8.6.2.2.

8.6.4 Contrôle temps réel.

Nous avons proposé dans le § 7.5 (de chapitre de modèle d'exécution) des mécanismes afin de contrôler les contraintes temps réel. Les mécanismes proposés s'appuient sur l’utilisation de chiens de gardes (WD), de routines d'alarmes et de tâches logicielles. Dans ce paragraphe, nous allons discuter la traduction du mécanisme de réaction à un dépassement d’une échéance lors de la génération de code temps réel VxWorks®.

Lors de la réception d'un événement (IT_niv, TOP et MSG_loc), nous avons proposé d'armer un WD (figure 8.5). Cet armement est réalisé dans l'entité où l'événement est reçu (l'ISR dans le cas où l'événement est IT_niv, etc). Avant d'être utilisé, ce WD doit être crée.

int fAL_1 (int val) wdStart (AL_1, 20, fAL_1, 0); /* 20 est la périodicité de l'alarme.*/ semGive (semPT_1);

wdStart (WD_1, d, fWD_1, nom de tâche à détruire); /*armement de l'alarme avec l'échéance d.*/ return (0);

Fig. 8.5. Une routine d’alarme avec contrôle d’échéance

113

Deux solutions sont possibles. La première solution est de créer le chien de garde d'une manière statique dans le main. L'inconvénient de cette solution qu'il n'est pas autorisé d'arrêter, suspendre ou supprimer une tâche dans une routine d'alarme. La deuxième solution est de créer une tâche de haute priorité notée RTCC en attente sur une boite aux lettres, en charge de gérer toutes les contraintes temps réel. Dans ce cas, nous remplaçons la primitive de d'armement de WD (figure 8.5) par un dépôt d'un message msgScheduler dans la boîte aux lettres de cette tâche RTCC.

La figure 8.6 montre l'utilisation de la tâche RTCC. A la réception d'un événement (dans cette figure nous traitons les interruptions) la routine d'interruption signale cette réception, à la tâche RTCC par le dépôt de message msgScheuler (dans sa boîte aux lettre bal 3), et au serveur de scrutation PS par le dépôt d'un message Sig_IT dans le file d'attente Bal 1. Le serveur de scrutation mémorise ce signal, puis à la réception de message Sig_TOP en provenance de la routine d'alarme, il crée la tâche Afaire qui se charge du traitement correspondant à l'interruption. La tâche RTCC, reçoit le msgScheduler avec la valeur de échéance, elle arme un chien de garde Alarme avec deadlien. Si le chien de garde expire son time-out, il lance une action corrective et dépose un message msgScheduler avec le paramètre deadline -1 qui signifie cette dépassement, dans la boite aux lettre Bal 3. Suite à ce message le RTCC, détruit la tâche Afaire qui a dépassé son échéance.

RTCC

ISR IT

ALR TOP

Sig_TOP Sig_IT_ni

WD

Bal 1

V

PS

V

msgScheduler

ALR

Afaire

Bal 2

Légende

Sem 1

Action_corrective

msgScheduler

Destruction

Création

Fig. 8.6 : L'utilisation d'une tâche RTCC selon le formalisme LACATRE

AL

Nous utilisons un rang d'événement (numéro d'occurrence) afin de faire correspondre entre l'événement arrivé et sa tâche (l'action) à créer et puis à détruire (dans le cas de dépassement d'échéance). Le rang varie entre 0 et NMAX-1. NMAX correspond au nombre maximum d'événements en cours de traitement. Ce rang est envoyé avec les messages msgSchdeuler, Sig_IT. Nous utilisons un tableau (int Traitement [NMAX] ) pour sauvegarder les PID des tâches Afaire. L'indice de ce tableau est le rang de l'événement. Similairement, nous définissons un deuxième tableau pour les chiens de garde (WDOG_ID Alarme [NMAX] ). La figure 8.7 présente le code VxWorks de la fonction liée à la tâche RTCC.

114

Int NMAX =100; int Traitement [NMAX] ; WDOG_ID Alarme [NMAX] ; struct Control control; fRTC_scheduler (void) int deadline; /* l’échéance de l’événement.*/ int rang; /* le rang d'un événement qui aussi indique l’identifiant de la tâche à exécuter */ for (;;)

msgQReceive (msgScheduler, (char *)&control, sizeof (control), WAIT_FOREVER); /* réception d'une demande de controle d'une contrainte ou détruire une tâche */

deadline = control.deadline; rang = control.number; if(deadline == -1) //l'échéance est dépassée.

taskDelete(Traitement[rang] )==OK

else /* création d’une alarme pour contrôler une contrainte temporelle */ Alarme[control.number] = wdCreate (); wdStart (Alarme[rang], deadline, fWD, rang); /*armement cette alarme */

return (0);

Fig. 8.7 : La fonction de la tâche RTCC qui gère les contraintes temporelles du modèle.

Une fois le timeout de WD expiré, la fonction fWD est lancée afin de lancer une tâche corrective (semGive (sem1)) (cf. figure 8.8) et signal cette expiration à la tâche RTCC qui détruira la tâche correspondante. Cette signalisation est effectuée par le dépôt d'un signal dans la boite aux lettre Bal2.

int fWD (int rang) if (taskIdVerify(Traitement[rang] )==OK) //si la tâche existe if (taskDelete(Traitement[tid] )==OK) //suspension de tâche qui son échéance a été expiré. semGive (sem1); //lancer la tâche correctif. control.deadline = -1; /* deadline expire */ control.number = rang; msgQSend(msgScheduler,(char *)&control,sizeof(control), NO_WAIT, MSG_PRI_NORMAL ); else // sinon la tâche n’existe pas Traitement[rang] = -1; return (0);

Fig. 8.8 : La routine d’alarme liée à l'alarme qui présente une échéance

115

8.7 La compilation du modèle d’exécution vers Win32® ou VxWorks®

Dans cette partie, nous présentons la compilation [18] [19] automatique du modèle d’exécution vers C / Win32® et C/VxWorks®. Le compilateur vise à vérifier la conception suivant les règles imposées dans le modèle d’exécution (cf. § 7.8 de chapitre modèle d'exécution) et à générer automatiquement le programme soit C / Win32® ou C/VxWorks® correspondant. L’entrée de notre compilateur est un fichier du modèle d’exécution. La figure 8.9 présente le schéma général du compilateur que nous avons réalisé. Nous y retrouvons les grandes phases classiques : l’analyseur lexical, l’analyseur syntaxique, l’analyseur sémantique et le générateur de code.

La grammaireLes mots-lé

Analyseur

Analyse Lexicale & syntaxique

Un arbre syntaxique

Générateur de code C/VxWorks Générateur de code

Fig. 8.9 : Les phases de compilation réalisée

Modèle d'exécution

Code utilisateur

Squelette de code

Squelette de code

Edition de liens Edition de liens

Code exécutabl

Code exécutable

Fichier

Résultat

Outil

Annotations formelles PO, NP, OS

8.7.1 L’analyseur lexical et l’analyseur syntaxique

Les compilateurs de code utilisent un analyseur lexical et un analyseur syntaxique. Le code source est décomposé en unités significatives appelées tokens. L’outil réalisant cette décomposition en différentes unités s’appelle un analyseur lexical (ou scanner). Des expressions régulières définissent les tokens à reconnaître et l’analyseur lexical est implanté par une machine à états finis.

116

Les relations possibles entre les différentes unités significatives d’un langage constituent les règles grammaticales de ce langage. Une grammaire dite libre de tout contexte définit les phrases correctes. La syntaxe d’entrée est au format BNF (Backus Naur Form). L’outil réalisant la vérification grammaticale d’un texte s’appelle un analyseur syntaxique (ou parser).

Le principe de fonctionnement est le suivant. L’analyseur lexical envoie une par une les unités à l’analyseur syntaxique qui les stocke (utilisation d’une pile) jusqu’à ce qu’une règle grammaticale soit complète. Par défaut, lorsqu’une règle est complétée, l’analyseur syntaxique désempile les unités concernées et empile le symbole (ou unité) correspondant à la règle réduite (nous parlons de réduction car le nombre d’éléments stockés dans la pile a diminué). A chaque réduction de règle, nous pouvons associer une action permettant par exemple de produire ou compléter une structure de données. La structure de données est alors construite au fur et à mesure de la vérification syntaxique. Elle se termine quand l’analyseur lexical n’émet plus d’unités et que la pile de l’analyseur syntaxique est vide.

Les analyses lexicales et syntaxiques ne constituent que la phase d’analyse d’un compilateur, phase qui est ensuite suivie par une phase de synthèse pour la production du code cible.

La structure de donnée interne s’appelle un parse tree ou encore intermediate code représentation. Cette structure interne peut alors être interprétée (cas d’un interpréteur) ou transcrite en un langage cible (cas d’un compilateur).

Si le fichier d’origine contient des erreurs lexicales et /ou syntaxiques, le compilateur va échouer du fait d’expressions inattendues et donc non interprétables. Aucun résultat cohérent ne peut être alors obtenu. Pour réaliser les analyseurs lexicaux et syntaxiques, nous avons utilisé les outils lex et yacc [96] [115]. Ces outils sont destinés en principe à l’interprétation de commandes et à la construction de compilateurs. Ils facilitent le prototypage rapide d’une application de traduction, sa modification et sa maintenance. L’analyseur lexical écrit en lex permet de prendre un flot d’entrée de type texte et de le décomposer en tokens. Le fichier est analysé mot à mot pour vérifier s’ils sont acceptables ou non en tant que tokens. En cas des fautes, c’est-à-dire un mot n’a pas été défini, l’analyseur signale le numéro de la ligne où se trouve la faute.

L’analyseur syntaxique, écrit en yacc, lit les tokens obtenus lors de l’étape précédente et vérifie leur enchaînement selon la grammaire de modèle d’exécution. Le résultat obtenu est soit une faute grammaticale, soit un fichier bien formé.

Lorsque l’analyse syntaxique a été réussie, l’analyseur syntaxique construit l’arbre syntaxique dont les feuilles représentent les expressions, les identificateurs, les objets, qui sont contenus dans le fichier d’entrée. L’exploitation du contenu de cet arbre permet de générer l’arbre sémantique.

Suite aux phases d'analyse lexical est syntaxique, les informations nous collectons les informations nécessaires à utiliser lors de la génération du code. Pour stocker de manière simple et structurée ces informations qui seront en entrée de la phase de la génération de code, nous choisissons d’utiliser des tableaux. Nous définissons pour chaque type des entités du

117

modèle d'exécution (AL, ISR, ALR, PS, ST et PT) un tableau. Ce tableau contient toutes les informations liées à ces entités comme son nom, les noms des autres entités dont elle est liée à eux, etc.

Les composants destinataires

numéro tache nom composant

PS Pt

nom processus principal

Noms des fonctions associées aux tâches

0 AL_1 0 -1 ALR_1 fInit_1 Fbody_1 1 AL_2 -1 0 ALR_2 - - 2 AL_3 1 -1 fAL_3 fInit_3 Fbody_3 4 - - - - - -

Tableau 8.2 : Tableau généré des l’arbre syntaxique (Alarme)

Les composants

destinataires

numéro tache

nom composant

PS SW

niveau priorité

nom processus principale

Noms des fonctions associées aux tâches

0 ISR_1 0 -1 Prio 0 fISR_1 fInit_4 Fbody_4

Tableau 8.3 : Tableau généré des l’arbre syntaxique (ISR)

Ces tableaux sont ensuite utilisés dans la phase de l'analyse sémantique et la phase de la génération du code.

8.7.2 L’analyse sémantique

La phase d'analyse sémantique d'un compilateur consiste à associer leur sens aux différentes phrases du texte source. A priori, l'analyse sémantique peut comporter la transformation d'un arbre syntaxique produit par l'analyseur syntaxique en un arbre sémantique comportant les informations nécessaires à la production du code objet, éventuellement sous forme intermédiaire. Elle permet déjà certaines simplifications (optimisations) en transformant un arbre sémantique en son équivalent optimisé. De plus, l’analyse sémantique a pour but de vérifier des règles de cohérence, soient dans notre étude les vérifications suivantes :

1. Règles de nommage : • Deux objets ne peuvent pas avoir le même nom. • Un guide de style est imposé sur le nommage des objets, par exemple le nom de chaque

objet doit commencer par un des entités suivante ISR_nom, PT_nom, AL_nom, ALR_nom, PS_nom, .. .

2. La correction de données (liée au système). • La priorité est comprise entre 0 et 255. 3. La correction de la communication • Il n'existe qu'une seule source d’activation pour chaque objet de type SW ou PT.

118

8.7.3 La génération du code C/ Win32® ou C / VxWorks®.

Dans cette dernière partie, nous nous intéressons à la génération du code (dernière phase du compilateur). Nous avons vu dans une partie précédente de ce chapitre que les objets du modèle d’exécution possèdent des objets correspondants, sous Win32® et VxWorks®..

Dans ce paragraphe, nous allons voir comment traduire automatiquement un modèle d’exécution vers une cible (C/ Win32® ou C/VxWorks®). Généralement, deux phases sont nécessaires pour générer du code. La première est la construction d’un arbre sémantique qui contient des feuilles correspondant aux objets de Win32® ou VxWorks®, et la deuxième est de la génération des fichiers finals (.h, .c).

La figure 8.10 montre en détail les étapes suivies pour générer le code à partir du modèle d’exécution. Il s’agit d’écrire la fonction qui, à partir des informations récupérées dans les tableaux (un tableau pour chaque type d’élément du modèle d’exécution cf. tableaux 7.2 de chapitre de modèle d'exécution) générés de l’arbre syntaxique (suite à la lecture d’un fichier écrit en langage SDL (modèle d’exécution)), vérifie ces informations sémantiquement et traduit ce dernier en langage soit C++/Win32 soit C/VxWorsk. Cette fonction prend en paramètre tous les tableaux de structure évoqués dans le modèle d’exécution ainsi qu’un fichier de sortie destiné à accueillir le code cible. Les tableaux (tableaux 8.2 et 8.3) sont parcourus dans leur totalité les uns après les autres et le code cible, équivalent aux informations lues, est inséré dans les différentes parties du fichier de sortie au fur et à mesure de la lecture du fichier et est complété par les informations manquants qui n’existent pas dans le modèle d’exécution.

Il est à noter que l’arbre sémantique peut aussi être utilisé pour modéliser l’application dans le but de réaliser des preuves. Enfin, le code généré n’est pas directement exécutable. Il manque certaines informations liées aux traitements ou des informations paramétrable. Ces informations liées aux traitements sont nécessaires à l’exécution comme, la condition d’arrêt du programme et les informations configurables comme les capacités des objet de communication (BAL ou sémaphores).

119

L’arbre syntaxique

Réglés sémantiques

Génération du Main

Les correspondances VxWorks

Déterminer les moyens de communication

VxWorks ou Win 32

Analyse sémantique Erreurs /warnings

Génération du Main

Les correspondances Win232

Déterminer les moyens de communication

Code généré C/VxWorks

Code généré C++ /Win32

Fig. 8.10 : La phase de l’analyse sémantique et la phase de génération du code

Tableaux intermédiaires des éléments du modèle d’exécution

8.8 Conclusion

Dans ce chapitre de génération de code, nous avons montré la possibilité de spécialiser le modèle d'exécution pour une plateforme d'exécution. Ainsi nous avons généré des différents codes pour un même modèle d'exécution. Ce code produit peut soit, servir à la simulation (Win32®), sont être spécialisé pour une plateforme temps réel (VxWorks®). Ce générateur de code nous permet donc de vérifier que le modèle d'exécution est complet du point de vue séquencement des tâches.

De plus, nous avons complété le modèle d'exécution par des informations supplémentaires obligatoires tels que la définition des moyens de communication utilisés entre objets. Les annotations formelles définies dans le modèle d'exécution (politique d'ordonnancement et les priorités des tâches et la base de temps) ont été utilisées.

D'autres stratégies n'ont pas été traitées dans ce chapitre et peut faire l'objectif de travaux futurs tel que la création/destruction dynamique des tâches. Dans notre cas les tâches, sont créées et détruites d'une manière statiques et exclusive dans la "main". En plus, la politique d'ordonnancement étudiée dans ce chapitre est à "priorité fixe". Nous pouvons étendre aisément l'étude à d'autres politiques plus compliqués tels que des politiques d'ordonnancement à priorités dynamiques telles que ED. Enfin, la dimension des moyens de communications utilisés dans ce chapitre n'est pas précisée et peut être comme l'objet de développements futurs.

120

Finalement, le modèle est désormais complet et nous avons tous les paramètres nécessaires à une analyse d'ordonnançabilité qui va être décrie dans le chapitre suivant.

121

9 Validation

9.1 Introduction

Les trois étapes retenues sont la spécification, la conception et l'implémentation qui conduisent à développer, à partir du cahier des charges, une réalisation de l'application. Une vérification globale des caractéristiques de la réalisation par rapport à la spécification est indispensable. Une telle vérification, conduit à la validation du système spécifié puis éventuellement à sa certification.

Partant de l'hypothèse que le modèle de spécification obtenu à partir du cahier de charge est correct, de point de vue fonctionnel et temporel, l'objectif de l'étape de validation concerne la conformité du modèle d'exécution.

Lors de l'étape d'implémentation, on suppose que le code obtenu de l'étape précédente (conception) est un code correct. Cependant, de nouvelles données temporelles liées aux durées des actions sont introduites. De ce fait, une phase de vérification des propriétés temps réel (temps de réponse) est indispensable à ce niveau.

En conséquence, les étapes de vérification que nous abordons comportent deux aspects qui constituent les deux parties de ce chapitre :

D’une part, il s’agit d’une validation formelle ayant pour objectif d’assurer la correction de la transformation entre la spécification (modèle de contraintes) et la conception (modèle d’exécution) (cf. le cadre pointillé I dans la figure.9.1) où l'on vérifie donc que ces deux modèles sont équivalents à une propriété donnée.

Les durées des exécutions des actions étant définies lors de l'implémentation, la relation de conformité concerne l'enchaînement des actions.

Spécification

Fig. 9.1 : Méthodologie proposée (validation et correction)

(II) MC

IF Outil IF

Outil IF

LTS

LTS

SDL

(IV) ME

SDL

SDL2IF

MC

ME

IF SDL2IF

MC

ME

ALDEBARAN I

Réalisé

II

Conception

(V) IMP

C/ VxWorks

C++/Win32Extraction de propriétés

Propriétés temps réels

IMP

V & V

V & V

RMA

Génération automatique du code

Implémentation

122

D’autre part, au niveau de l'implémentation, la vérification est basée sur une analyse d'ordonnançabilité. A ce stade nous nous baserons sur les techniques d’ordonnancement de type RMA (cf. le cadre pointillé II dans la figure 9.1).

9.2 Validation formelle

9.2.1 Technique de validation Le problème de la correction est lié à la “conformité de la spécification”. Dans ce contexte, deux questions peuvent être posées : (a) comment peut être exprimée la spécification ? (b) Quel est le sens de la conformité ?

Les méthodes de spécification peuvent être de deux catégories :

Spécification comportementale : informellement, elle correspond à une manière naturelle d'exprimer la correction d'un système, en disant qu'un système K “se comporte comme” un système K′, où K′ est généralement accepté comme étant correct. Formellement, dans cette approche, le système et sa spécification sont modélisés en utilisant le même formalisme, (ou un semblable). Par exemple, la spécification comportementale pour un automate temporisé serait un automate temporisé, ou une machine d’état fini non-temporel.

Spécification logique : informellement, elle consiste à exprimer un certain nombre de propriétés que le système doit satisfaire, par exemple, en disant qu'il ne “ fait jamais quelque chose de dangereux” ; (propriétés de sûreté), ou “actuellement fait quelque chose” ; (propriétés de vivacité).

Une spécification logique est une formule décrite avec un certain formalisme logique. En ce qui concerne la conformité à une spécification comportementale, elle est habituellement définie par une relation d'équivalence : un système est correct, s'il est équivalent à sa spécification.

Les langages de spécification, les automates, etc.… sont des modèles de haut niveau. En d'autres termes, ce sont des formalismes simplement syntaxiques, tout comme des programmes en langages de haut niveau, qui, néanmoins, doivent être compilés pour obtenir le code résultant. La sémantique d'un programme de haut niveau est habituellement décrite en termes d'états possibles du système, aussi bien que par ses transitions possibles (permettant le changement d'un état à l'autre). Cette structure s'appelle un système de transition étiqueté (LTS : Label Transition System), où les étiquettes annotant les transitions représentent l’occurrence des événements ou actions.

C'est, généralement une tâche difficile que de vérifier des propriétés en exploitant directement un programme de haut niveau. La plupart des algorithmes de vérification traitent des graphes, (c'est-à-dire, LTSs) puisque c'est une des représentation les plus efficaces d'un modèle, et par conséquent, une phase de compilation est effectuée, où le LTS est produit à partir de sa représentation implicite. Cependant, dans la modélisation de systèmes temps réel, cette procédure est souvent complexe à cause du problème d'explosion d'état combinatoire.

A partir d'une spécification d'un système simple (c.-à-d., programme de haut niveau), une analyse doit être effectuée pour produire le LTS correspondant. Ce graphe obtenu est généralement d'une taille considérable (sa taille étant en général exponentielle en fonction de

123

la taille de la spécification). Par conséquent, les techniques pour limiter l’exploration du graphe du système entier deviennent indispensables.

De telles techniques sont des méthodes de minimisation (réduction ou encore abstraction). Leur objectif est de réduire, selon un critère donné, la taille du système, tout en, préservant ses propriétés initiales. Si ceci doit être fait pour un ensemble général de propriétés du système initial, alors la réduction obtenue est habituellement pauvre. Par conséquent, les méthodes de minimisation utilisent souvent, comme guide l'ensemble de propriétés qui doivent être vérifiées, pour les préserver dans un modèle réduit.

En conséquence, le LTS nous permet de faire deux types de validations: d'un coté la vérification des propriétés logiques sur un modèle et de l'autre coté, la comparaison de deux LTSs, afin d’assurer l’équivalence entre eux (la correction de la transformation entre deux modèles).

9.2.2 Définition de problème

En fait, dans les deux chapitres (5 et 6) nous avons associé aux modèles de contraintes (cf. chapitre modèle de contraintes) et aux modèles d’exécution (cf. chapitre modèle d’exécution) une sémantique opérationnelle et temporelle donnée en IF. L’outil IF2C de l’environnement IF génère automatiquement un automate de type LTS (cf. figure 9.2).

SDL

Editeur

IF

SLICE CONST

LIVE

SDL2IF IF2C simulation

LTS

Formalism

Légende: objectGeode: environnement de développement SDL SDL2IF un outil de traduction une modélisation SDL en IF LIVE/CONST/SLICE : outils d'analyses statiques IF2C : outil de génération de LTS à partir de description IF. Outil CADP/Kronos/TGV des outils de validation et de test basé sur le LTS fichier

TGV

CADP Kronos

Fig. 9.2 : Environnement de IF : de SDL à LTS

Considérons deux LTS MC et ME correspondant respectivement au modèle de contraintes et au modèle d’exécution. Si une relation de compatibilité existe entre MC et ME, alors nous disons que ME est la transformation correcte de MC. On peut dire, informellement, que les modèles MC et ME sont compatibles, selon un critère d'abstraction donné, s'ils offrent le même comportement observable. Cependant, la relation de compatibilité que nous proposons est différente de celles d'ores et déjà exploitées dans la littérature telles que l'équivalence de trace et la bisimulation.

Dans la suite, et avant de définir notre relation de compatibilité, nous commençons tout d'abord par représenter d'une manière formelle la modèle de contraintes et le modèle

124

d'exécution. En suite, nous définissions la relation de compatibilité entre ces deux modèles et nous proposons un algorithme permettant la mise en oeuvre d'une telle relation.

9.2.3 Formalisation du problème de compatibilité

9.2.3.1 Modèle de contraintes

Tout d'abord, nous formalisons le modèle de contraintes puis nous abordons la formalisation du modèle d'exécution.

L'ensemble des composantes de la spécification est un automate Ms tel que :

Ms = (As, ∑s, δs, a0s) Où: As est l'ensemble d'états ∑s est l'alphabet δs est la fonction de transition et a0s est l'état initial.

Selon l'hypothèse qui consiste à faire correspondre à tout événement une action, nous divisons l'alphabet ∑s en deux sous-alphabets disjoints ∑e et ∑ac caractérisant respectivement l'ensemble des événements et l'ensemble des actions. Nous définissons alors la fonction Act qui à tout événement fait correspondre son action correspondante :

Act: ∑e ∑ac

αe Act (αe ) = αa

Soit L(Ms, aos) l'ensemble des trajectoire événement-action. Un élément ws ∈ L(Ms, a0s) est tel que il existe une séquence d'événements ou d'action α0 α1 ….( αi∈∑s ) telle que δs (a0s, α0, α1….) existe.

A Notation

On note par |ws| le nombre d'événements de ws et par α ∈ ws s’il existe i ∈ℕ telle que αi est un élément de ws

Afin d'extraire les événements et les actions qui seront éléments d'une trajectoire ws ∈ L (Ms, a0s) on définit les deux fonctions (projection) suivantes:

event : ∑s ∑e

α event (α ) = ℇ si α ∉ ∑e

α si α ∈ ∑e

que l'on peut généraliser sur les trajectoires (wsα) où le mot ws ∈ ∑*e (l'ensemble des mots

sur l'alphabet ∑e) est défini par :

Event : ∑*

s ∑*e

wsα Event (wsα) = Event (ws).event(α)

Par analogie, on définit a fonction action telle que:

action : ∑s ∑ac

α action (α ) = ℇ si α ∉ ∑ac

α si α ∈ ∑ ac

125

et que l'on peut aussi généraliser sur les trajectoires (wsα) où le mot ws ∈ ∑*

ac (l'ensemble des mots sur l'alphabet ∑ac) est défini par : Action : ∑*

s ∑*ac

wsα Action (wsα) = Action (ws).action(α) Exemple:

Considérons la trajectoire suivante:

B Définition 1:

Etant donnée ws ∈ L(Ms, a0s), ws est dite une réalisation valide (V-réalisation) de la spécification si :

1. | event(ws)| = |action(ws) |, i.e. le nombre d'événement de ws est égale au nombre d'action de ws.

2. ∀ α ∈ ∑ s : (α ∈ event (ws)) ⇔ (act(α) ∈ action (ws)). Exemple: 1.

2.

9.2.3.2 Modèle d'exécution

Par analogie au modèle de contraintes, le modèle d'exécution est un automate Mc tel que:

Mc = (Ac, ∑c, δc, a0c)

où Ac, ∑c, δc, a0c ont la même définition que As, ∑s, δs, a0s. Cependant, l'alphabet ∑c est l'alphabet ∑s, du modèle de contraintes, augmenté d'un ensemble d'événements internes. Ces derniers ne sont pas visibles au niveau de modèle de contraintes, d'où le nom interne qui leur

evt1 act1 evt2

a0s a1 a2 a3

ws =

Event (ws) = evt1 evt2 Action (ws) =act1 act2

ws est une V-réalisation puisque lenombre d'événements est égal aunombre d'action et pour chaque événement l'actioncorrespondante est effectuée

act2

a3

evt1 act1 evt2

a0s a1 a2 a3

ws =

Event (ws)= evt1 evt2 Action (ws) =act1

ws n'est pas une V-réalisationpuisque à deux événements et iln'y a qu'une seule action.

evt1 evt2 act1 act2ws = a0s a1 a2 a3 a4

Alors : Event (ws)= evt1 evt2 Act(evt1)= act1 Action (ws) =act1 act2 Act(evt2)= act2

126

est associé. Ainsi ∑c = ∑s ∪ ∑i ∪ tickavec ∑i est l'ensemble des événements internes et tick représente l'occurrence d'une unité de temps.

Dans le but de comparer la correction du modèle d'exécution par rapport au modèle de contraintes nous définissons la fonction de projection suivante:

ps : ∑c ∑s

α ps (α ) = ℇ si α ∉ ∑s

α si α ∈ ∑s que l'on peut généraliser par : Ps: ∑*

c ∑'*s

wα Ps (wα ) = Ps (w).ps(α)

Par analogie à l'ensemble L(Ms, a0s) on définit L(M's, x0s) relativement à l'automate M'c et à son état initial x0c

La définition suivante permet de caractériser la comptabilité entre deux trajectoires ws et wc relevées respectivement à partir des deux modèles de contraintes et du modèle d'exécution.

A Définition: Etant donnée ws ∈ L(Ms, a0s) et wc ∈ L(Mc, x0c) avec ws est une V-réalisation. ws et wc sont compatible si: 1. (Event (Ps (wc))) = (α ∈ Event (ws)). 2. (Action (Ps (wc))) = (Action (ws)). 3. | Event (Ps (wc))| = | Action (Ps (wc))| Exemple

ws est une V-réalisation Event (ws)= evt1 evt2 Action (ws) =act1 act2Et Act(evt1)= act1 Act(evt2)= act2

evt1 act1 evt2

a3 a3

act2

a0s

ws = a1 a2

a5a4

act2

a3

evt3

a2a1a0s

wc = act1evt2evt1

Event (Ps(wc))= evt1 evt2 Action (Ps(wc)) =act1 act2a4a3

act2

a2a1a0s

act1evt2evt1Ps(wc) =

ws et wc sont compatible car : 1. evt1 et evt2= Event (Ps(wc)) et Event (ws) =evt1 et evt2 2. act1 et act2= Action (Ps(wc)) et Action (ws)=actt1 et act2 3. | Event (Ps (wc))| = | Action (Ps (wc))|=2

En résumé, d'après cette définition, deux trajectoires ws ∈ L(Ms, a0s) et wc ∈ L(M'c, x0c) sont compatibles si la trajectoire w'

c extraite à partir de wc et qui n'est pas constitué que d'éléments de ∑s admet la même longueur que celle de ws et, en plus, ws et w'c admettent les mêmes événements et les mêmes actions.

127

B Proposition. Considérons wc ∈ L(MC, a0C), il existe une v-réalisation ws ∈ L(Ms, a0s) telle que wc et wc sont compatible si et seulement si la condition suivante maintiens à wc :

1. | Event (Ps (wc))| = | Action (Ps (wc))| 2. ∀ α ∈ ∑ s , α ∈ Event (Ps (wc)) ⇔ (act(α) ∈Action (Ps (wc)).

Cette proposition assure que, pour chaque trajectoire wc ∈ L(MC, a0C), il existe une trajectoire V-réalisation ws ∈ L(Ms, a0s), si et seulement si wc satisfait deux conditions: wc admet autant d'événements que d'actions. De plus, un événement est un élément de la trajectoire wc si et seulement si son action correspondante est aussi un élément de wc. En fait, à partir de l'hypothèse qui suppose que le modèle de contraintes est correct, nous pouvons avoir trois cas possibles.

Le premier cas est celui où wc correspond exactement à une trajectoire qui est une v-réalisation. Le deuxième cas est celui où wc est équivalent à une exécution multiple d'une trajectoire qui est v-réalisation. Le troisième cas correspond au cas où il est possible de trouver une permutation, dans l'ordre des événements et des actions de wc telle que la nouvelle trajectoire obtenue amène aux deux premier cas.

D'une manière générale, nous établissons la définition suivante qui permet de caractériser une relation de comptabilité entre le modèle de contraintes et le modèle d'exécution.

C Définition:

Etant donné un système temps réel caractérisé par un modèle de contraintes S(As, Ms), un modèle d'exécution C(Ac,Mc) est dit compatible à S(As,Ms) si : ∀ wc ∈ L(M'c, q0c), et ∀ w'c

∈ ∑*c telle que wc w'c ∈ L(M'c, q0c), ∃ ws ∈ L(Ms, a0s) tels que:

1. ws est une V-réalisation. 2. wc w'c et ws sont compatibles.

L'algorithme suivant permet la mise en œuvre de la relation de compatibilité proposée

9.2.3.3 Algorithme En entrée de l'algorithme, on retrouve:

Les deux automates des modèles de contraintes et d'exécution. L'algorithme consiste à, d'abord, calculer l'ensemble des séquences réalisables. Ensuite à calculer le plus long chemin, noté n, à partir de l'état initial dans le modèle automate d'exécution et enfin à exécuter la fonction suivant :

Algorithme de compatibilité estcompatible := VRAI . tant que (i < n) et (estcompatible) . . . R := ∅ ; . . Calculer l'ensemble de trajectoire de L(i) à partie de x0; . . Pour chaque li ∈ L(i)

. .

. . . tans que (j < n – i) et (estcompatible)

. . .

128

. . . . Calculer des trajectoires Tj qui complète li

. . . . de longueur j+i pour chaque t ∈ Tj

. . . . Si t est une réalisation alors R = R ∪ t .

. . . //fin de boucle j.

. . . Si R = ∅ alors estcompatible := FAUX

. . .

. //fin de boucle i.

. // Fin de l'algorithme.

Cet algorithme permet de vérifier la relation de compatibilité. Tout d'abord, l'algorithme calcule la longueur n de la trajectoire la plus longue du LTS du modèle d'exécution. Ensuite, pour chaque trajectoire possible w, l'algorithme calcule toutes les trajectoires possible φ telles que chaque trajectoire concaténée wφ est trajectoire du LTS du modèle d'exécution. Enfin, pour chaque wφ, l'algorithme vérifie la satisfaction des deux conditions données par la proposition présentée dans § 9.2.3.2.

En effet, l'algorithme proposé au-dessus, n'est pas applicable directement pour vérifier la correction de la transformation entre les deux LTSs (de modèle de contraintes et d'exécution). Il est nécessaire de préparer ces deux LTS. Cette préparation consiste à réduire les deux LTSs. Cette réduction est faite selon des critères d'abstractions définis au niveau de la spécification. Par la suite, nous proposons une méthodologie qui consiste à préparer et puis à vérifier la correction de la transformation entre les deux LTSs.

9.3 Méthodologie de la validation formelle

Dans le but de mettre en œuvre l'algorithme de compatibilité, nous proposons une démarche se basant sur les étapes suivantes. Ces étapes consistent, d'une part, à attribuer des noms identiques aux labels utilisés pour chaque événement dans les deux modèles et d'autre part, à extraire des propriétés à comparer entre les deux modèles. Par exemple, un séquencement d'événement – action, une échéance à respecter, etc.

Dans cet but, plusieurs manipulations peuvent être mise en œuvre afin d'unifier les noms, d'extraire un séquencement et de redéfinir de base de temps unitaire. Ces manipulations sont appliquées à différents.

9.3.1.1 Redéfinir une base de temps unitaire

La première étape consiste à définir une base du temps commune et ce dans le but d'unifier les modèles d'automates.

L'étape préconise de choisir comme période de base le plus grand diviseur commun (PGDC) des périodes d'activations. Comme exemple, considérons le cas où les deux activations périodiques avec des périodes de 10 et 15. Dans ce cas le période commune est égale à PGDC (10,15)=5. Nous remplaçons les périodes des horloges des modèles de contraintes et d'exécution par cette période comme montré dans la figure 9.3.

129

Fig. 9.3 : Redéfinition de base de temps unitaire

9.3.1.2 La deuxième étape : le renommage

L'étape de renommage est nécessaire de par l’utilisation de l'outil IF. En effet, en IF, un élément (bloc SDL) du modèle de contraintes est un processus identifié par un nom. De ce fait, un événement ou une action d'un objet du modèle de contraintes est identifié par un label composé du nom de l'événement et du nom de processus le contenant. Par exemple pour une source d'activation périodique TOP_1, cet événement aura comme label (Horloge0 ?TOP_1), où Horloge est le processus modélisant l'objet Horloge.

Ainsi ce même événement, au niveau du modèle d'exécution, appartenant à un autre processus, dans notre étude est l'alarme qui est nommée AL_n. Donc cet événement a comme label (AL_10 ?TOP_1). C'est pour cette raison que l'opération de renommage s'avère nécessaire. Cette dernière est effectuée en utilisant des règles de renommage. Ces règles seront écrites dans un fichier ayant pour un suffixe .rename. Le fichier de règles de nommage est donné par la figure 9.3. Il consiste à enlever les préfixes process_name.

Rename /* mot clé pour dans le fichier de renommage */ "horloge0 ?TOP_1 " ? TOP_1 "appli0 !TOP_1 " !TOP_1 "appli0 ?Deb_afair " Deb_afaire

Fig. 9.4 : exemple de fichier de renommage conf.rename

9.3.1.3 La troisième étape : abstraction et réduction des modèles :

Après avoir appliqué les étapes présentées ci dessus, la troisième étape consiste à réduire les deux modèles LTS. En fait, cette étape est composée deux sous étapes successive, l'abstraction et puis la réduction. Tout d'abord, la sous étape d'abstraction consiste à abstraire les deux LTS selon un critère d'abstraction. Un critère d'abstraction est un ensemble de labels extraits à partir du modèle de contraintes. Selon ce critère d'observation, tous les labels (événements et actions) figurant dans les modèles de contraintes et d'exécution et n'appartenant pas à ce critère sont remplacés par un événement fictif inobservable τ. Ensuite, la deuxième sous étape consiste à réduire les deux LTSs sortants de la première sous étape. Cette réduction s'appuie sur l'enlèvement de tous ces événements fictifs des deux LTSs. Cette réduction est faite en utilisation la relation de bisimulation faible (cf. § 4.1.1.1 chapitre 4).

Cette étape de réduction est à manipuler avec précaution car elle peut faire disparaître des états de blocage. Il est à noter que, dans notre cas, cette réduction est correcte car nous avons

130

supposée que ces deux modèles sont vivants (la propriété de vivacité est vérifiée pas d'état de blocage).

Enfin, il est à noter que ces deux sous étapes sont effectuées, dans le cadre de nos travaux, en utilisant la commande ALDEBARAN2 suivante: (Aldebaran –hide conf.hide -smin nom_fic.aut > nom_fic.smin.aut ) Où conf.hide est le nom du fichier qui contient le critère d'abstraction défini, nom_fic.aut est le nom de fichier qui contient le LTS du modèle et nom_fic.smin.aut est le nom du fichier sortant.

Dans notre étude, les critères d'abstraction peuvent être de deux ordres. Dans le premier cas, nous nous intéressons à vérifier le déclenchement correct des actions. Nous ne observons alors que des événements d'activation (IT, TOP, MSG) et le déclenchement des actions (Deb_Afaire). Dans le deuxième cas, nous intéressons à vérifier si une action est annulée dans le modèle de contraintes, cette action est aussi annulée dans le modèle d'exécution (dans le cas d'une violation d'une échéance). Nous devons donc observer les événements d'activation (IT, TOP, MSG), le déclenchement des actions (Deb_afaire) et les fins des actions (Fin_afaire).

9.3.1.4 La quatrième étape : comparaison

En considérant les LTSs réduits obtenus suite à la troisième étape, lors de la dernière étape, nous appliquons l'algorithme présenté dans le paragraphe 1.2.3.3 de ce chapitre afin de vérifier la relation de compatibilité entre le modèle de contraintes et le modèle d'exécution.

9.3.2 Exemple d'application

9.3.2.1 Exemple d'activations sporadiques

Considérons l'exemple de la spécification donnée par le schéma de la figure 9.5. Cette spécification consiste à activer sporadiquement suite à l'occurrence d'une interruption, une action Afaire. La source d'interruption envoie des interruptions IT_1 dans l'intervalle de temps [10,15].

system specfication_ITUse ConstraintModel;

Can

IT_1

Can2

com_1 <IT_1, dmin, dmax> <IT_1, Com_1,Action_1>

G3G2appli1:appliSourceIT:sorceITreg

G1

signal IT_1(integer), c synonym

om_1(integer);15; dmin duration =10, dmax duration =

Action_1

Fig. 9 ption.5: Modèle de contraintes d'une activation sur interru

Le modèle automate correspondant à chaque élément de cette spécification est donné par la figure 9.6.

2 Cet outil permet de minimiser, renommer et comparer des LTS.

131

SourceIT Appli1

Fig. 9 intes.6 : Les sémantiques des composants de modèle de contra

Afaire

A l'aide de l'outil IF, l'automate global (LTS) AC admet 12 états et 18 transitions. A ce modèle de contraintes, on associe le modèle d'exécution dont les éléments sont décrits dans le schéma de la figure 9.7.

Le modèle d'exécution est composé du modèle d'environnement et du modèle de l'application. Evidement, le modèle de l'environnement est identique à celui fourni pour le modèle de contraintes.

Le modèle d'application est composé d'un ISR avec un PS qui mémorise les interruptions. Et nous utilisons une alarme avec une routine d'alarme pour la scrutation périodique.

Dans notre cas, seules deux stratégies sont traitées. La première traite le cas où l'occurrence des interruptions n'est pas sauvegardée. Dans ce cas, la période de scrutation (alarme) Ps doit être inférieure à celle de l'occurrence des interruptions Pi (Ps <Pi dans notre exemple Ps=8. Le LTS généré admet 188 états et 257 transitions. La seconde stratégie consiste à considérer la sauvegarde des interruptions. Dans ce cas, Ps doit être supérieur de Pi (Ps > Pi dans notre exemple Ps = 20. Le LTS généré admet 423 états et 569 transitions. Selon cette configuration, plusieurs interruptions sont sauvegardées, c'est-à-dire, entre deux instances d'activations périodique du serveur à scrutation, plusieurs interruptions peuvent avoir lieu.

132

system conception_IT

Signal IT_1, com_1, TOP_1, Sig_TOP_1,Sig_IT_1;Synonym dmin duration =10, dmax duration =15, P integer = 8 ou 20;

can1

IT_1

can3

TOP_1

can2

Sig_IT_1

SourceIT:sourceITreg<IT

_1, dmin, dmax>

ISR_1:ISR <IT_1, S

ig_IT_1>

PS_1:PSAL_1:AL ALR_1:ALRSig_TOP_1

Can4

Fig. 9 tion

<TOP_1, P1> <TOP_1,Sig_TOP_1 >

Action_1

<IT_1,Sig_TOP_1, Com_1,Action_1>

.7 : Modèle d'exécution d'une activation sur interrup

ExecutionModel;Use

Can5

[com_1]

Par analogie à la démarche ci-dessus, à chaque élément du modèle d'exécution on associe le modèle automate équivalent (voir figure 9.8).

AL

Après avoir appliqué les deux premières étapes de la méthodologie proposée (renommage et abstraction), le LTS réduit qui correspond au LTS du modèle de spécification est donné par la figure 9.9. Dans ce cas, les labels observés sont l'envoi du signal d'interruption ! IT_1 et le début de l'action correspondante ! Deb_afaire.

ALR

ISRSourceIT

PS

Fig. 9.8: Modèles d'automates IF des éléments du modèle d'exécution

133

Fig. 9.9: Modèles global réduit de modèle de contraintes

En considérant le même critère d'abstraction, et après application des deux premières étapes de la méthodologie, le LTS réduit de modèle d'exécution, (cas où Ps > Pi) est exactement le même que de celui du modèle de contraintes.

Dans le deuxième cas où les interruptions sont mémorisées, et par l'application de deux premières étapes, le LTS réduit est donnée par la figure 9.10.

Selon le critère de comparaison énoncé ci-dessus et la relation de compatibilité proposée, les deux modèles sont compatibles. En effet, après analyse de l'automate du modèle d'exécution (figure 9.10), pour toutes les trajectoires (séquences d'événements) possibles du modèle d'exécution. Chaque séquence comporte autant d'événements d'interruptions !IT_1 que d'événement !Deb_afaire (figure 9.8). A titre d'illustration, considérons la trajectoire suivante (extraite de l'automate de la figure 9.10):

(0) Deb_afaire(3)Deb_afaire(7)Deb_afaire (4) IT (5)IT (3)Deb_afaire 7) (IT (9)IT 0)(S ⎯⎯⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯→⎯⎯⎯→⎯⎯⎯⎯⎯⎯ →⎯⎯⎯→⎯⎯⎯→⎯=

Cette trajectoire admet quatre événements IT_niv et quatre événements Deb_afaire. D'un point de vue modèle de contraintes, cette trajectoire satisfait, le troisième cas présenté à l'explication de la proposition 1. En effet, il existe une permutation de labels IT_niv, Deb_afaire telle que :

Deb_afaire IT Deb_afaire IT Deb_afaire IT Deb_afaireIT →→→→→→→

Cette nouvelle trajectoire correspond au deuxième cas (de la proposition 1) est correspond au cas où le cycle IT_niv Deb_afaire est exécuter quatre fois.

134

Fig. 9.10 : Modèles global réduit de modèle d'exécution de Ps avec sauvegarde

9.3.2.2 Exemple d'activations périodiques

Dans le paragraphe suivant, nous nous intéressons aux activations périodiques dans le modèle de contraintes. Nous illustrons, dans ce cas, la première étape de notre démarche de vérification. Afin de mieux éclairer cette étape, nous nous limitons au cas de deux activations périodiques dont le modèle de contraintes est donné par la figure 9.11.

system s t ys_tes Synonym P1=10, PSignal T

2=15; OP_1, TOP_2;

can1

TOP_1

appli2:appli <TOP_2 ,Action_2>

g1

appli1:appli ction_1><TOP_1 ,A

g1

can2

TOP_2horloge2:horologe<TOP_2, P2>

g2

horloge1:horologe<TOP_1, P1>

g2

Action_1

Action_2

Fig. 9.11: Modèle de contraintes de deux activités périodiques

A ce modèle comprennent les modèles automates suivants (figure 9.12).

Fig. 9.12. Les modèles automate de source d'activation périodique de modèle de contraintes

135

Plusieurs modèles d'exécutions sont possibles. Une première solution possible est pour chaque horloge de période P du modèle de contraintes de mettre en place une alarme de même période avec une routine d'alarme associée (figure 9.13).

block s t ys_tes Synonym P1= 10, P2=15;

can1

TOP_1 can2

Sig_TOP_1g4

PT1:PT1 <Sig_TOP_1,Action_1>

ALR1:ALR <TOP P_1>_1, Sig_TO

g3g2g1AL1:AL

<TOP_1, P1> Action_1

can1

TOP_2 can2

Sig_TOP_2g4

PT2:PT1 <Sig_TOP_1,Action_1>

g3g2ALR2:ALR

<TOP P_1>_1, Sig_TOAL2:AL

<TOP_2, P2>

g1 Action_2

Fig. 9.13 : Modèle d'exécution de deux activités périodiques en SDL

Une autre solution possible est d'utiliser une seule alarme (période 5) avec sa routine d'alarme et une seule tâche périodique (cf. figure 9.14). Cette dernière se charge l'exécution des deux actions déjà présentées dans le modèle de contraintes (une fois sur deux Afaire_1 et une fois sur trois Afaire 2). Le modèle IF associé pour la tâche est donné en figure 9.15. Dans cette figure, nous avons utilisé une seule alarme AL1 avec un période de 5, une routine alarme ALR1 et une seule tâche périodique PT1. Cette dernière exécute l'action Afaire_1 chaque deux tops arrivés (2*5 =10, sa période initiale 10) et l'action Afaire_2 chaque trois tops (3*5 = 15, sa période initiale 15). Le modèle IF de cette tâche périodique est donné par la figure 9.16. Dans cette figure, nous privilégions l'action Afaire_1 et l'action Afaire_2 selon l'algorithme d'ordonnancement de RM (P1 < P2). Dans la suite, nous détaillons cette solution.

s t block ys_tes P= 5synonym ;Action_1

can1

Lors de la mise en place de la validation, la première étape préconisée a pour objectif le choix d'une base de temps unitaire. Cette valeur est choisie comme le plus grand commun diviseur (PGCD) des périodes d'activation spécifiée dans le modèle de contraintes. Dans l'exemple considéré les périodes sont de 5, 10 et 15. Dans ce cas la base de temps est PGDC (10,15)=5 modélisé par l'événement TOP.

TOP can2

Sig_TOPg4g2

AL1:AL <TOP, P>

g1ALR1:ALR

<TO OP>P, Sig_T

g3PT1:PT

<Sig _1,_TOP, ActionAction_2>

Action _2

Fig. 9.14 Modèle d'exécution de deux activités périodiques en SDL

136

Fig. 9.15 : l'automate de la tâche périodique correspondante au bloc PT de la figure

14

Après avoir appliqué les trois premières étapes de la méthodologie sur les deux modèles de contraintes et d'exécution, nous obtenons les deux LTS donnés par la figure 9.16 et 9.17. Le critère d'abstraction utilisé est l'envoi de TOP et le déclenchement de deux actions (Deb_afaire_1, Deb_afaire_2). Dans la figure 9.17, nous trouvons que l'action Afaire1 est privilégiée par rapport à l'action Afaire2.

Fig. 9.16. le LTS réduit du modèle de contraintes présenté dans la figure 11

Fig. 9.17: L'automate global réduit du modèle d'exécution

Selon la relation de compatibilité proposée, les deux modèles sont compatibles. En effet, après analyse de LTS du modèle de contraintes nous trouvons des trajectoires possibles w1 et w2:

137

(0) (9)(3) (1) (8)

(4) (10) (5)(11) 6) ((7)0)( w1_1Deb_afaire_2Deb_afaireTOPTOP

_1Deb_afaireTOP_2Deb_afaire TOP_1Deb_afaireTOPTOP

⎯⎯⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯ →⎯

⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯ →⎯=

(0) (2)(3) (1) (8)

(4) (10) (5)(11) 6) ((7)0)( w2_2Deb_afaire_1Deb_afaireTOPTOP

_1Deb_afaireTOP_2Deb_afaire TOP_1Deb_afaireTOPTOP

⎯⎯⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯ →⎯

⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯ →⎯=

Et après avoir analysé le modèle d'exécution (figure 9.16), la seule trajectoire possible du modèle d'exécution est

(0) (2)(4) (8) (3)

(1) (10) (6)(7) (5)(9)0)( w_2Deb_afaire_1Deb_afaireTOPTOP

_1Deb_afaireTOP_2Deb_afaire TOP_1Deb_afaireTOPTOP

⎯⎯⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯ →⎯

⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯⎯⎯⎯ →⎯⎯⎯ →⎯⎯⎯ →⎯=

Cette trajectoire est exactement la même trajectoire S1, qui correspond au premier cas (de la proposition 9.2.3.2B page 128).

9.3.2.3 Observation d'échéance

Nous avons introduit dans les chapitres précédents la notion d'échéance. De plus nous avons spécifié dans le modèle de contraintes des politiques temps réel afin de filtrer les interruptions parasites et contrôler les échéances spécifiées dans le modèle.

Considérons les modèles de contraintes et d'exécution présenté dans l'exemple présenté au § 9.2.3.1 page 9.2.3.1125. En plus de la loi d'activation modélisée dans les deux modèles, nous associons une échéance à l'interruption traitée dans ce système. Son non respect entraîne la fin de l'action en cours.

La figure 9.22 présente le modèle de contraintes de la figure 9.5 complété par un observateur e, change de vérifier le respect de l'échéances et de l'arrêt de l'action en cours si nécessaire (envoi de STP).

system specfication_IT

Can

IT_1

can3 ObsIT AckIT

G6obs:observateur<ObsIT, AckIT>G5

can4STP

Source :sorceIT eg<IT

IT r_1, dmin, dmax>

G1 G4appli1:appli

<IT_1, STP, Action_1>

Can2

com_1 G7 G3

Com_1,

G2

Fig. 9.22 : le modèle de contrainte du système traitant les interruptions avec échéance

Par analogie, la figure 9.23 présente le modèle d'exécution correspond au modèle de contrainte donné dans la figure 9.22 en ajoutant un chien de garde WD_1.

138

Les modèles automates en IF de chaque élément des modèles présentés en figure 9.19 et figure 9.23 sont présentés dans les chapitres relatifs aux modèles de contraintes et d'exécution respectivement.

Afin de comparer les deux modèles et vérifier que les contraintes spécifiées sont respectées dans le modèle d'exécution, nous appliquons la démarche proposée.

Après une étape de renommage de tous les labels partagés entre les deux modèles (étape 1), nous déterminons les événements à observer (étapes 2). Le critère d'observation consiste en des séquences IT_1 Deb_afaire Fin_afaire.

Nous supposons que l'interruption peut parvenir d'une manière apériodique entre 16 et 18 ut, l'action est effectuée en 4ut et l'échéance pour chaque interruption est de11 ut. A partir de ces données, l'échéance est toujours respectée au niveau du modèle de contraintes.

Le modèle automate global du modèle de contraintes admet 36 états 57 transitions. Après avoir appliqué ces deux étapes, l'automate global du modèle de contraintes devient, celui présenté par la figure 9.21

Au niveau du modèle d'exécution, en plus des informations temporelles du modèle de

contraintes, nous ajoutons une information supplémentaire. Il s'agit de la période de scrutation d'interruption. Par conséquence, le choix de cette période de scrutation (Ps) peut causer une défaillance au niveau de l'échéance. Pour illustrer cela nous considérons deux périodes de scrutations différentes. Le premier cas où Ps = 6, le LTS global du modèle d'exécution admet 361 états 476 transitions.

Fig. 9.23 : le modèle d'exécution du système traitant les interruptions avec échéance

system ons_avec_obs c

can1

IT_1 can2

Sig_IT_1

can3

TOP_1 can4

Sig_TOP_1

can5Set_WD can6

Reset_WD

WD_1:WD_S <Set_WD,Reset_WD

>

Delete_1

SourceIT:sorceITreg<IT

_1, dmin, dmax>

ISR_1:ISR_U_T<IT_ _1>1, Sig_IT

PS_1:PS <Sig_IT_1,Sig_TOP_1>

AL_1:AL <TOP_1, P>

ALR_1:ALR <TOP_1,Sig_TOP_1>

Fig. 9.24 : Le LTS réduit du système présenté à la Fig. 9.19

139

En appliquant les deux premières étapes de la démarche sur ce modèle nous obtenons l'automate de la figure 9.25.

Fig. 9.25 : Le LTS réduit du système présenté à Fig. 9.20 (Ps = 6)

Dans ce deuxième cas, nous avons choisi Ps = 8 et dans ce cas, chaque lancement d'action peut être retardé de 8ut. Ceci conduit à dire que la fin d'action peut être effectué à 8 unités de temps + 4 unités de temps où 4 unités de temps est le délai d'exécution de l'action. De ce fait nous concluons par la figure 9.23 qu'elle montre la possibilité d'un dépassement d'échéance car l'échéance est 11 unités de temps.

Fig. 9.26 : Un modèle d'automate global réduit de du système présenté par la Fig. 9.20 (Ps > 7)

En appliquant la troisième étape de notre démarche (l'étape de l'application de l'algorithme) dans le premier cas où (Ps = 6), les deux automates sont compatibles alors que dans le deuxième cas (Ps >7) ne le sont pas. Dans ce dernier cas, l'automate du modèle d'exécution peut produire une séquence à laquelle ne correspond aucune réalisation dans le modèle de contraintes comme (0) (1) (0) qui signifie que l'action est arrêtée au cours de son exécution et le non respect d'échéance.

9.3.3 Conclusion

Nous avons proposé une démarche formelle permettant de vérifier la correction de la transformation d'un modèle de contraintes vers un modèle d'exécution avec l’aide d’une relation de compatibilité définie relativement à une classe de système pour lesquels à chaque événement correspond une action bien déterminée.

Notre proposition consiste à une première étape à définir les modèles automate des modèles de contraintes et d'exécution. Dans ce second temps, et sur la base de ces modèles automates, nous effectuons trois opérations. La première permet de revenir à une base de temps commune. La deuxième opération consiste à un renommage de tous les labels partagé. La troisième opération consiste en une réduction des deux modèles tel que seuls les labels à

140

observer sont considérés. Enfin, l'algorithme proposé peut être appliqué afin de vérifier la compatibilité entre le modèle de contraintes et le modèle d'exécution.

La dernière partie de ce chapitre porte sur des exemples d'applications à l’appui de notre proposition. Au travers de ces exemples nous avons pu distinguer pour un même modèle de contraintes, des modèles d'exécution qui lui sont compatibles et d'autres qui ne le sont pas.

Le travail présenté ici ouvre un certain nombre de perspectives. Il convient de réaliser des outils permettant l'automatisation la vérification de compatibilité.

Les modèles (de contraintes et d'exécution) traités dans ce chapitre ne sont pas complets de point de vue des contraintes temps réel, par exemple l'âge de données.

Il est possible d’étendre notre démarche afin de prendre en compte de nouvelles contraintes temps réel comme gigue.

Dans le modèle de contraintes, nous avons traité des événements externes de type interruptions, messages et tops périodiques.

Dans le cas d'un modèle de contraintes abstrait, nous ne retrouvons pas les mêmes notations dans le modèle de contraintes un notation plus abstraite est utilisée pour un événement externe. Autrement dit, il est possible d'utiliser des noms des événements différents entre ces deux modèles comme event dans le modèle de contraintes ou event ne se trouve pas dans le modèle d'exécution. Afin d'appliquer la démarche proposée dans ce chapitre, il est nécessaire d'ajouter des nouvelles étapes telle que une étape de renommage afin de préciser la correspondance entre un événement présenté dans un modèle son événement correspondant dans l'autre modèle.

141

9.4 Vérification des propriétés temps réel

Dans le cadre de ce chapitre, nous avons pour objectif de montrer la possibilité de réaliser et utiliser des techniques de vérification de propriétés temps réel sur le modèle d'exécution proposé (figure 9.1). La vérification sert à éliminer les fautes temporelles dans la réalisation finale.

En fait, nous avons précisé dans les modèles présentés précédemment les contraintes temps réel telles que les dates d'activation pour chaque type d'activation, les dates de validités de données, la priorité de chaque tâche du modèle d'exécution et les contraintes d'échéance. Pour vérifier la cohérence temporelle du modèle d'exécution il faut ajouter le temps d’exécution des actions. Ce temps représente le temps d'occupation du processeur par une action donnée. SDL n’est pas prévu pour l’évaluation de performances et ne possède donc pas la syntaxe, ni la sémantique nécessaire pour permettre la spécification du temps d’exécution. Actuellement dans SDL, le temps d’exécution d’une transition est indéterministe, de même que le temps séparant deux transitions consécutives, ainsi que le temps de communication (cf. chapitre). Le modèle d'exécution proposé ne contient donc pas cette information. Suite à l’étape de codage, on peut obtenir les valeurs de l’ensemble des durées [47]. En l'état des outils, le modèle sémantique IF ne permet pas de modéliser les durées, les priorités et la préemption. Nous optons donc pour la mise en place de RMA.

Dans l'état d'art de la validation et de la vérification (paragraphe 2.4.6.2), nous avons définit les caractéristiques du modèle RMA. A partir des informations temporelles collectées du modèle d'exécution et les durées d'exécution obtenues à partir du code, nous monterons qu'il est possible de construire ce un modèle RMA. Ainsi, il est possible d'appliquer des méthodes de vérification de type RMA.

Tout d'abord, nous présentons un rappel du modèle RMA. Ensuite, nous montrons comment construire le modèle correspondant à partir des modèles présentés précédemment (contraintes, exécution et implémentation). Enfin, nous montrons une illustration de l'utilisation de ce modèle pour la vérification de propriétés temps réel.

9.4.1 Modèle RMA

Les caractéristiques temporelles qui concernent le modèle RMA, peuvent être divisées en deux catégories : la première est relative aux événements, et la deuxième concerne les actions. En ce qui concerne un événement, le modèle RMA considère un temps minimum entre des deux événements consécutifs, le type de l'envoi d'événement (périodique ou sporadique) et l'échéance (Di) liées à un événement. En ce qui concerne une action, le modèle consiste en un niveau de priorité (Pi) ou une politique d'ordonnancement (RM, ED ou DM), une durée d'exécution (Ci) et le temps d'utilisation des ressources ainsi que leur politique de gestion (PIP, PCP, PSB).

9.4.2 Extraction des paramètres temporels pour RMA

Dans cette partie nous allons représenter les caractéristiques temporelles spécifiées et implémentées lors des diverses étapes de notre méthodologie.

Dans le modèle de contraintes, nous avons présenté plusieurs types de modèle des activations (périodique sur des interruptions, etc). A partir de ces modèles, nous pouvons

142

extraire les dates d’activation, les types d’activations, les échéances et les âges de données. Plus précisément, dans l’activation périodique, nous avons précisé la période d'envoi de TOP périodique par P qui correspond à Ti du modèle RMA. Ce signal est paramétré par une échéance d1 qui correspond à Di du modèle RMA. Dans l'activation sur des interruptions ou messages (présenté par le signal IT_lev_n, MSG_loc_n), le dmin et dmax qui présentent les fréquences minimum et maximum entre deux occurrences d'une interruption, est considérés pour déterminer le Ti (dmin) du modèle RMA. Chaque interruption ou message est aussi paramétré par une échéance d1 qui est considérée comme le Di du modèle RMA.

En ce qui concerne le modèle d'exécution, quelques informations peuvent être extraites comme la priorité attribuée à chaque bloc SDL dédié à une tâche (PS, PT, ST, SW), les actions exécutées dans un bloc possèdent la priorités du bloc. Dans le cas d'un ordonnancement à priorité fixe FP, ces priorités qui sont présentées sous formes des annotations formelles (section x) correspondent à Pi du modèle RMA. Dans le cas d'une politique d'ordonnancement, les informations sont dans le modèle sous forme d'annotation.

Comme il est annoncé dans l'introduction de cette partie, la durée d'exécution d'une action est déterminée à partir de code généré. Cette durée mesurée correspond à Ci du modèle RMA. Nous supposerons que ces mesures sont connues.

Dans notre étude, les actions sont liées aux tâches et aux routines telles que les routines d'interruptions et d'alarmes. Les priorités des routines d’interruption et d’alarme ne sont pas explicitées car ces informations sont attribuées par le système d’exploitation même (plus forte priorité Priomax). Donc, nous considérons que ces routines ont le même niveau priorité. En effet, ce niveau est le plus élevé du modèle d'exécution.

L'utilisation de ressources, dans le cadre de notre travail, est effectuée lors de partage de données (export et import de données). Afin de déterminer la durée d'utilisation de la ressource qui correspond à Ui du modèle RMA, il est nécessaire d'effectuer une mesure sur le code généré, soit le temps écoulé pour exporter/importer une donnée. La politique de gestion des ressources dépend du système d'exploitation.

Désormais, nous avons toutes les informations nécessaires pour construire un modèle RMA et appliquer une analyse de type RMA que nous pouvons illustrer avec l’utilisation de l'outil TimeWiz [203] mesurer le temps de réponse au moyen et au pire cas selon les principes du RMA pour un événement donné.

9.4.3 Les propriétés à vérifier

Les contraintes temps réel, dont nous avons étudiées à la longe de cette mémoire, sont exprimées explicitement dans le modèle de contraintes. De ce fait, les propriétés temps réel à vérifier doivent être extraire à partir de ce modèle. Dans la suite, nous allons montrer comment on peut vérifier le respect d'une échéance (simple et bout en bout) et la validité de l'âge d'une donnée.

9.4.3.1 Vérification d'une échéance simple

Afin de vérifier une échéance sur l'occurrence d'un événement nous devons représenter le système sous forme de événement–séquence d'actions. Les événements peuvent être périodiques ou sporadiques. TimeWiz modélise un événement via "trigger events" et par la

143

spécification des périodes et de l'échéance correspondante (figure 9.24). Les actions sont caractérisées par leur durée (moyenne, pire) et leur priorité.

Fig. 9.24 : Modèle (trigger events action) de TimeWiz

Nous allons reprendre l'exemple qui est présenté précédemment dans ce chapitre (deux activations périodiques) (cf. § 9.3.2.2). Nous avons utilisé dans cet exemple pour chaque activation une alarme, une routine d'alarme et une tâche périodique.

Les événements considérés, dans cet exemple, sont TOP_1 et TOP_2. Les périodes d'activation extraits du modèle d'exécution sont P1 = 50 et P2 = 100 (tableau 9.1). Suivant de l'occurrence d'un TOP_1 (respectivement TOP_2) la routine d'alarme correspondante (ALR_1) est exécutée (l'exécution de l'action codée dans la routine d'alarme). Ensuite, à la fin d'exécution de cette routine, un événement interne est envoyé à la tâche PT_1 afin de déclencher l'action correspondante à exécuter. Ces deux actions présentent le séquencement des actions correspondant à l'occurrence de TOP_1 (respectivement ALR_2 et PT_2 à l'occurrence de TOP_2). La durée d'exécution de chaque action est donnée dans les tableaux 2 et 3.

Modèle d'exécution Paramètres RMA

Nom de processus Nom de l'événement

Type d'envoi

Fréquence maximale d'envoi

Echéance

1 AL_1 TOP_1 périodique 50 50

2 AL_2 TOP_2 périodique 100 100

Tableau 9.1: caractéristiques temporelles liées aux Alarmes

Nom Nom d'action à

exécuter Priorité

Pi Durée

d'exécution Ci

1 ALR_1 ALR_1_Afaire Priomax 5

2 ALR_2 ALR_2_Afaire Priomax 5

Tableau 9.2: caractéristiques temporelles liées aux routine d'alarmes

Nom Nom d'action à

exécuter Priorité

Pi Durée d'exécution

Ci 1 PT_1 PT_1_Afaire 120 10

2 PT_2 PT_2_Afaire 150 20

Tableau 9.3: caractéristiques temporelles liées aux tâches périodiques

144

A partir de ces informations, le modèle TimeWiz correspondant est donné par la figure 9.25.

Afaire_1

Afaire_2

Fig. 9.25: Modélisation de deux activations périodique utilisant TimeWiz

Les résultats de l'analyse d'ordonnançabilité faite avec TimeWiz montrent que le système est cohérent du point de vue du respect d'échéance (échéance manquée = 0). Nous avons aussi obtenu le pire temps de réponse pour chaque événement (pour TOP_1 = 20, et pour TOP_2 = 40).

9.4.3.2 Vérification d'une échéance de bout en bout

Nous avons défini que l'échéance bout en bout comme une borne maximale de l'intervalle séparant un événement du système en entrée d'un événement en sortie (section 1.3 page 6). TimeWiz permet de vérifier une délai de bout en bout via le Tracer. Le Tracer peut être utilisé pour définir un cheminement d'un événement externe via plusieurs actions en parallèle (c'est-à-dire étant déclenchées par plusieurs événements). On définie alors un cheminement entre les événements externes en entrée et sortie via une séquence d'actions. Ce cheminement est utilisé par TimeWiz afin de calculer le temps de réponse au pire cas d'un système pour un événement externe donné. Afin de montrer comment il est possible de vérifier une échéance de bout en bout, nous allons reprendre le cas du traitement des interruptions présentées dans ce chapitre (cf. § 9.3.2.1).

Exemple

Au cas où une interruption se présente, une routine d’interruption va être exécutée ISR_1_Afaire avec une échéance simple à respecter. De plus, le reste du traitement de cette interruption PS_1_Afaire est chargé par un serveur à scrutation périodique. Les informations temporelles concernant ce modèle est donnée par les tableaux (4, 5 et 6).

Modèle d'exécution

Paramètres RMA

Nom de bloc Nom d'événement

Type d'envoi Fréquence maximale d'envoi

Echéance

1 SourceITreg IT_1 sporadique 100 -

2 AL_1 TOP_1 périodique 50 -

Tableau 9.4: caractéristiques temporelles liées aux Alarmes

Modèle

d'exécution Paramètres RMA

Nom de bloc Nom d'action à exécuter

Priorité Pi

Durée d'exécution Ci

1 ISR_1 ISR_1_Afaire Priomax 5

2 ALR_1 ALR_1_Afaire Priomax 5

Tableau 9.5: caractéristiques temporelles liées aux routine d'alarmes

145

Modèle

d'exécution Paramètres RMA

Nom de bloc Nom d'action à exécuter

Priorité Pi

Durée d'exécution Ci

PS_1_memo 5 1

PS_1 PS_1_Afaire

120

30

Tableau 9.6: caractéristiques temporelles liées à serveur de scrutation

Une échéance de bout en bout peut être définie comme l’intervalle de temps entre la réception d'une interruption par l'ISR et la fin d’exécution du traitement correspondant effectué par le serveur à scrutation. Afin de calculer cette échéance au pire cas, il suffit de mettre en œuvre un Tracer Tracer_IT entre l’ISR_1 et le PS_1 (figure 9.26). En fait, le temps de réponse au pire cas de ce Tracer, calculé par TimeWiz, présente le délai de bout en bout entre l'arrivé d'une interruption et la performance de l'exécution de l'action du serveur de scrutation Afaire_3.

A partir de cette description et des informations présentées dans les tableaux (4, 5 et 6), l'échéance de bout en bout obtenu en pire cas est de 195. De plus, le temps de réponse au pire cas, calculé par TimeWiz, pour les événements IT_1 et TOP_1 est respectivement 10 et 40. Afin d'assure le respect d'échéance, il est évident que l'échéance de l'interruption spécifiée doit être supérieur de 195.

Fig. 9.26 : Modèle de vérification d'échéance de bout en bout en TimeWiz

9.4.3.3 Vérification la validité d'une donnée

L'âge d’une donnée est l'intervalle de temps entre le moment où la donnée a été produite et le moment où la donnée est consommée. La ressource logique de TimeWiz est utilisée pour présenter un buffer, ou une mémoire partagée. Dans l'objectif de calculer et mesurer l'intervalle de temps maximal et au pire cas entre la production et la consommation d'une donnée, nous allons exploiter cette ressource logique pour présenter les données. D'une façon similaire à l'échéance de bout en bout, le calcule de cet intervalle est effectué en utilisant un traceur de TimeWiz;

Soit un système composé de deux tâches périodiques (cf figure 9.27), nous supposons que la tâche périodique PT_1 produit une donnée et l'export, et la deuxième tâche périodique PT_2 import cette donnée. Nous modifions donc cette exemple, en ajoutant une ressource logique notée donnée_partagée entre les deux actions PT_1_Afaire qui représente PT_1et

146

PT_2_Afaire qui représente la tâche PT_2. Les informations temporelles de ce modèle sont les même que celle dèjà données dans les tableaux 9.1, 9.2 et 9.3.

Afin de mesure le temps maximal entre le moment où la donnée est produite par la tâche PT_1 et le moment où la donnée est consommée par la tâche PT_2, il suffit d'utiliser un Tracer entre la production de la donnée (ALR_1_Afaire) et sa consommation (PT_2_Afaire).

A partir de ce modèle (figure 9.27) et les informations temporelles données dans les tableaux 1,2 et 3, nous avons appliqué l’analyse de l’ordonnancement pour mesurer le temps d’exécution au pire cas du Tracer nommé validité_donnée. Ce temps indique l’âge maximal de la donnée. A partir de l'outil TimeWiz nous trouvons que cette durée est 230. De plus nous avons trouvé que le temps d'exécution au pire pour AL_1 est 35 et pour AL_2 est 40. Donc, à partir de cette analyse la donnée utilisée est toujours valide si sa durée de validité est supérieure à 225.

Fig. 9.27: Modèle de vérification de l'age de données

9.5 Conclusion

Nous avons montré dans la deuxième partie de ce chapitre la possibilité d'appliquer l'analyse de l'ordonnançabilité de type RMA sur le modèle d'exécution. Les modèles proposés sont donc bien adaptés au contexte temps réel.

Pour autant l'analyse RMA reste limité dans ses possibilités. Les systèmes de tâches considérées doivent rester simple. Le modèle de base considère des tâches sans point de blocage interne et périodique ou sporadique (pas de rafale). De plus, ces techniques ne prennent pas du tout en considération l'aspect fonctionnel du système.

Nous préconisons alors d'aller vers des outils et techniques d'analyses plus réalistes [16].

Dans le cadre de notre travail, nous avons utilisé des politiques d'ordonnancement de type priorité fixe. Nous avons proposé dans le chapitre sur le modèle d'exécution, comme une

147

ouverture de ce travail, d'utiliser d'autres types de politiques d'ordonnancements telle que EDF (Earliest Deadline First). Celle dernière peut être intégré dans RMA.

En fait, d'autres types de vérifications sont possibles d'être établie à partir du modèle d'exécution tel que l'analyse de graphe. Dans notre cadre d'étude, il est possible d'exploiter le graphe généré à partir de l'outil de IF en utilisant l'outil EVALUATOR [62] du package de CADP [203] (figure 9.1).

148

Conclusion générale.

149

L’approche décrite dans ce mémoire se propose de donner un cadre formel au développement de systèmes temps réel à partir de modèles SDL. On suppose, que l’analyse des besoins fonctionnels a été réalisée soit en UML puis traduit en SDL, soit exprimée directement en SDL. Au final, la spécification est exprimée en SDL. Puis, l’approche se concentre sur la formalisation des étapes de spécification, conception et implémentation du système.

L’approche définit trois niveaux dans le développement, dont deux exprimés en SDL. Dans un premier niveau dit modèle de contraintes (spécification), on décrit le comportement temporel attendu du système selon le paradigme événement-condition-action ainsi que les contraintes temps réel. Dans un deuxième niveau, on décrit le modèle d’exécution (conception) avec l’hypothèse et la restriction d’une architecture monoprocesseur. Enfin, le troisième niveau correspond à l’implémentation qui est basée sur un exécutif multitâche temps réel.

Pour chaque niveau modélisé en SDL, nous avons proposé un modèle sémantique exprimé en IF. Le modèle SDL s’appuie sur des schémas de programme type (signaux, blocs) et est orienté conception. Le modèle IF permet de préciser la sémantique temporelle et sert de base à la validation du système.

Au niveau du modèle de contraintes, la solution proposée s’appuie sur un typage des signaux échangés entre le système et son environnement (procédé à contrôler, machines, autres applications). Les paramètres des signaux contiennent ses caractéristiques temporelles (date d’arrivée, durée de séparation entre deux occurrences, date de validité, échéance). L’environnement est modélisé via des blocs-types SDL qui représentent les lois d’arrivée des signaux externes. Enfin, nous avons détaillé l’expression de politiques temps réel spécifiques (filtrage temporel, réaction à une faute temporelle).

A l'issue de cette première étape où les contraintes sont exprimées, c'est l'étape de conception avec pour objectif la définition de l’architecture de l’application. C’est à ce niveau que l’on décrit comment l’application doit s’exécuter. Au niveau du modèle d’exécution, l’approche propose une boîte à outils basée sur des blocs type SDL qui introduit les notions de routines (d’interruption ou d’alarme), de tâches (périodique, apériodique, sporadique ou serveur) et des règles d’interconnexion entre ces divers entités d'exécution. Par analogie à l'expression des politiques temps réel proposées dans le modèle de contraintes, nous avons proposée d'intégrer des mécanismes de réaction aux fautes temporelles à ce niveau.

La formalisation du modèle d’exécution permet de vérifier la correction de la transformation du modèle de contraintes vers le modèle d’exécution. Pour cet objectif, nous avons introduit une nouvelle relation de compatibilité comportementale. Cette dernière s'applique aux applications multitâches spécifiées selon le paradigme événement-condition-action. Afin d'appliquer cette relation de compatibilité comportementale, nous avons proposé une méthodologie, basée sur quatre étapes d'abstraction et de réduction. Pour cette dernière, nous avons exploité les techniques de bisimulation pour réduire les graphes et éviter le problème de l'explosion combinatoire.

Enfin, l’implémentation est obtenue directement via un générateur de code adéquat. Ce générateur peut produire un code pour la simulation ou pour l’exécution. Dans le premier cas,

150

nous privilégions une cible classique, dans le deuxième un exécutif temps réel. Au travers de cette étape, nous avons vérifié que le modèle d'exécution est complet (génération automatique de code). De plus, nous avons précisé le modèle de communication entre processus (aspect non détaillé dans le modèle d'exécution). Enfin, nous avons assuré que le générateur de code ne modifie pas la sémantique définie au niveau du modèle d'exécution.

Finalement, afin d'assurer la correction temps réel du code généré, nous avons étudié la possibilité d'appliquer une analyse d'ordonnançabilité de type RMA. Dans ce sens, nous avons montré comment on peut extraire les propriétés temps réel afin de construire un modèle d'ordonnancement (dit modèle RMA) à partir des modèles étudiés (modèle de contraintes, modèle d'exécution et code).

Perspectives

Le travail présenté ici ouvre un certain nombre de perspectives. Tout d'abord, il est possible d'améliorer les modèles de contraintes et d'exécution par l'ajout d'autres contraintes temps réel qui ne sont pas considérées dans ce document comme par exemple la contrainte de gigue. La transformation entre le modèle de contraintes et le modèle de conception n'est pas traitée dans ce document. En conséquence, nous proposons, comme un ouverture de ce travail, de réaliser un prototype (compilateur) qui réalise cette transformation avec la définition de règles de transformation de type de celle définies dans CODARTS mais avec vérification de la correction de la transformation.

Par ailleurs, il nous semble intéressant de considérer des cas plus complexe au niveau de la spécification. Par exemple, quand l'exécution d'une action dépend d'une contrainte temps réel (une action est annulée à cause du dépassement d'une échéance, une action utilise une donnée invalide de point de vue temporel). Il serait alors nécessaire d'étendre la relation de compatibilité proposée. Une autre perspective est d'étendre notre relation de compatibilité proposée afin de prendre en compte les systèmes distribués.

Dans le cadre de la vérification de propriétés temps réel, nous proposons d'automatiser la construction du modèle RMA à partir de l'implémentation. Il serait aussi souhaitable d'aller vers des formalismes à base d'automate temporisé pour modéliser des applications multitâches temps réel [35].

Enfin, il est possible d'utiliser d'autres langages dans les phases du modèle de contraintes et le modèle d'exécution comme par exemple le langage orienté objet UML 2.0. En effet, UML 2.0 intègre le diagramme de séquence MSC et définit une sémantique du langage d'action compatible avec SDL. De plus, récemment, une nouvelle extension de IF 2.0 (UML2IF) permet de prendre en compte des spécifications UML et les traduire d'une manière automatique en IF.

151

Références

152

[1] Alur R., Courcoubetis C., Dill D.: Model-checking for real-time systems. In Proc. of 5th, Annual IEEE Symposium on Logics in Computer Science, IEEE Computer Society Press. Philadelphia, Pennsylvania, 1990, pp. 414–425.

[2] Alur R. and Dill D.L.: A theory of timed automata. Theoretical Computer Science, 1994, Vol. 126, Issue 2, pp. 183–235. ISSN 0304-3975.

[3] Alur R., Courcoubetis C., and Dill D.: Model Checking for Probabilistic Real Time Systems. In Procedding of the Colloquium on Automata, Languages and Programming, Madrid, Spain ,1991, pp. 115-126.

[4] Alur R., Courcoubetis C. and Dill D.: Model-Checking in Dense Real-time. Information and Computation, Vol. 104, N°1, 1993, pp. 2-34.

[5] Alvarez J. M., Diaz M., Llopis L., Pimentel E., Troya J. M.: An Object-oriented Methodology for Embedded Real-time Systems. Computer Journal, 2003, Vol. 46, n°2, pp. 123-145 ISSN 1460-2067

[6] Alvarez J.M., Diaz M., Llopis L. M., Pimentel E., Troya J. M.: An Analyzable Execution Model For SDL For Embedded Real-Time Systems. 24th IFAC/IFIP Workshop on Real-Time Programming and The Third International Workshop on Active and Real-Time Database Systems, Germany, Elsevier, 1999, pp. 117-123.

[7] Alvarez J.M., Diaz M., Llopis L. M, Pimentel E., Troya J. M.: Integrating Schedulability Analysis and Design Techniques in SDL. Real Time Systems Journal, 2003, vol. 24, n° 3, pp. 267-32.

[8] AIT-AMEUR Y.: Développement Contrôlés de programmes par Modélisations et vérifications de propriétés. HDR présenter à l’université de Potiers, 18 janvier 2000, 146 p.

[9] Ashour M., SDL for embedded real-time systems. Proc. of the 24th IFAC/IFIP Workshop on Real Time programming - WRTP'99, June 1999, pp. 117-123.

[10] ANDRÉ C.: Paradigmes objets et synchrones dans les systèmes temps-réel . Journée Objets Temps Réel du Club SEE Systèmes Informatiques de Confiance, Paris, 18 janvier 2001.

[11] ANDRÉ C., PERALDI D M-A.: Hard Real-Time System Implementation on a Microcontroller. WRTP'92. In IBRA/BIRA International Workshop on real-time programming, , Bruges (Belgium), June 1992. IFAC, pp. 185-289

[12] Amnell T., Behrmann G., Bengtsson J., D'Argenio P. R., David A., Fehnker A., Hune Th., Jeannet B., Larsen K. G., Möller O. M., Pettersson P., Weise C., Yi W: Uppaal - Now, Next, and Future. In F. Cassez, C. Jard, B. Rozoy, and M. Ryan, editors, Modelling and Verification of Parallel Processes, number 2067 in Lecture Notes in Computer Science Tutorial,. Springer, Verlag, 2001, pp. 100-125 disponible sur <http://www.uppaal.com> (consulté le 14.06.2004).

153

[13] Amnell T., David A., Fersman E., Möller M. O., Petterson P., Yi W.: Tools for Real-Time UML : Formal Verification and Code Synthesis. SIVOES'2001) 18-22 June 2001, Budapest Hungary.

[14] Alkhodre A. Programmation graphique (LACATRE) d'application concurrentes basées sur NT: rapport de stage de DEA. DEA SICE, Lyon : Université Claude Bernard, 2000, 35 p.

[15] Ad/14 06 2002 SPT Disponible sur : <http://www.omg.org/> (consulté le 14.06.2004)

[16] Altisen K., Goessler G., Sifakis J.: Scheduler modeling based on the controller synthesis paradigm Journal of Real-Time Systems. Special Issue on Control Approaches to Real-Time Computing, 2002, vol. 23, pp. 55-84. ISSN 0302-9743

[17] Andrews D., Ince D.: Practical Formal Methods with VDM, New York, NY, USA : The McGraw-Hill International Series in Software Engineering. 1999, 450 p. ISBN 0-07-707214-6.

[18] Aho A. V., Johnson S. C., Ullman J. D.: Deterministic parsing of ambiguous grammars. Communications of the ACM, 1975, vol. 18, n°.8, pp. 441–452 ISSN 441-452

[19] Aho A., Sethi R., Ullman J.D.: Compilers : Principles, Techniques and Tools ,Reading, MA : Addison-Wesley, 1986,796 p. ISBN 0-201-10194-7

[20] Babau J-Ph.: Modèle d’architecture orienté objet pour les systèmes temps réel. Rapport de recherche, CITI, INSA de Lyon, 2003, 28 p.

[21] Babau J-Ph: Guide méthodologique pour PROSEUS, Rapport de recherche, CITI, INSA de Lyon, 2000, 35 p.

[22] Booch G., Rumbaugh J., Jacobsson I.: Unified Modeling Language. Notation Guide version 1.0, Rational software corporation. 1997.

[23] Boehm B. W.: The high cost of software. In Ellis Horowitz, editor, Practical Strategies for Developing Large Software Systems. Reading, MA : Addison-Wesley, 1975, pp. 3-15 .

[24] Berry G. and Cosserat L.: The ESTEREL synchronous programming language and its mathematical semantics. L.N.C.S. Seminar on Concurrency,Springer,1984, vol. 197, pp. 389-448. ISBN 3-540-15670-4.

[25] Braberman V. and Olivero A and Schapachnik F.: ZEUS: A Distributed Timed Model-Checker Based on KRONOS, Electronic Notes in Theoretical Computer Science, Elsevier, Lubos Brim and Orna Grumberg, 2002, vol. 68, n° 4, 20 p.

[26] Blom Simona Orzan S.: A Distributed Algorithm for Strong Bisimulation Reduction of State Spaces. Elsevier, 2002, vol. 68, n°. 4, 16 p..

[27] BERTHOMIEU B.: Réseaux de Petri temporels. ETR septembre 2003, Toulouse France, pp. 123-153.

154

[28] Bozga M.,. Fernandez J-C, Ghirvu L., Graf S., Krimm J.P. , Mounier L., Sifakis J.: IF : An Intermediate Representation for SDL and its Applications. Proc. of the Ninth SDL Forum, Montreal, Quebec, Canada, 21-25 June, 1999,423 p.

[29] Bozga M., Graf S., Mounier L., Kerbrat A., Ober I., Vincent D.: SDL for Real-Time : What is missing ?. Proc. of the 2nd Workshop on SDL and MSC - SAM2000, Grenoble, 26-28 Juin 2000. 17 p.

[30] Bozga M., Graf S., Mounier L., Ober I., Roux J-L., Vincen D.: Timed Extensions for SDL. Proc. of SDL-Forum'01, Copenhagen (Denmark), 2001. p. 223-240.

[31] Bause F., Buchholz P.:Protocol Analysis Using a Timed Version of SDL. FORTE, Madrid, 1990, pp. 239--254

[32] Bause F., Buchholz P.: Protocol Analysis Using a Timed Version of SDL. Proc. of the IFIP TC/WG 6.1 Third International Conference on Formal Description Techniques for Distributed Systems and Communications Protocols, FORTE'90, November 1990, pp. 239-254

[33] Babau J.-P., Sourrouille J. L.: Expressing Real Time Constraints in a Reflective Object Model. Control Engineering Practice , 1998, Vol 6, pp 421-430.

[34] BROWAEYS F. et al.: SCEPTRE : Proposition de noyau normalisé pour les exécutifs temps réel. TSI: Technique et Science Informatique, 1984, vol. 3, n° 1, 28 p.

[35] Babau J-Ph., Alkhodre A.: A development method for PROtotyping embedded SystEms by using UML and SDL (PROSEUS). workshop SIVOEES 2001 – ECOOP, Budapest 2001, 6 p.

[36] Bouajjani A., Fernandez J-C, Halbwachs N.: Minimal model generation. In R.P. Kurshan and E.M.Clarke, editors, CAV90 : Computer Aided Verification, of Lecture Notes in Computer Science, Springer Verlag, 1990, vol. 531, pp. 197--203.

[37] Belarbi M. : Validation Temporelle des Applications Multitâches Temps Réel basée sur les Automates Temporisés Communicants. Thèse de doctorat, Institut National des Sciences Appliquées de Lyon. Décembre 2003, 165 p.

[38] Berry G.: The Foundations of Esterel in Proof, Language, and Interaction, Essays in honor of Robin Milner. G. Plotkin, C. Stearling, and M. Tofte, Editors. MIT Press, 2000, pp. 425-454.

[39] BOOCH. G.: Object-Oriented Analysis and Design with Applications, 2e édition, Addison-Wesley, 1994, 608 p. ISBN 0805353402

[40] Carlson J.: Languages and methods for specifying real-time systems. Technical report, Mälardalen Real-Time Research Centre, Department of Computer Science and Engineering, Mälardalen University, Sweden, Aug. 2002, 48 p.

[41] Carreira P. J. F., Costa. M. E. F.: Automatically verifying an object-oriented specification of the steam-boiler system. In Stefania Gnesi, Ina Schieferdecker, and Axel

155

Rennoch, editors, Proc. of the 5th International ERCIM Workshop on Formal Methods for Industrial Critical Systems (FMICS’2000), GMD, 2000, pp. 345–360

[42] Cassez F.: Vérification qualitative. ETR septembre 2003, Toulouse France, pp. 91-104.

[43] CLARCK R.G., MOREIRA A.M.D.: Use of E-LOTOS in Adding Formality to UML, Journal of Universal Computer Science, 2000, vol.6, no 11, pp. 1071-1087.

[44] CALVEZ J.P.: Spécification et conception des systèmes, une méthodologie. Paris :Masson,1997, 288 p. ISBN 2225822301.

[45] Clarke E.M. et Emerson E.A.: Synthesis of synchronization skeletons for branching time temporal logic. In Workshop on Logic of Programs, Springer-Verlag, 1981, vol. 131 de LNCS, pp. 52–71.

[46] Chen M.I., Lin K.J.: Dynamic Priority Ceilings : a Concurrency Control Protocol for Real Time Systems. Real Time Systems, 1990, Vol 4 n° 2, pp 325-346.

[47] Choquet-Geniet A.: Panorama de l'ordonnancement temps réel monoprocesseur, ETR 03, septembre 2003, Toulouse France, pp. 213-226.

[48] Derek J. Hatley, Imtiaz A. Pirbhai: foreword by Tom DeMarco : Strategies for Real-Time System Specification, New York, NY : Dorset House Publisher, hardcover, 1988, 408 p. ISBN 0-932633-11-0

[49] DeMarco T.: Structured Analysis and System Specification. Englewood Cliffs, Prentice-Hall, 1979, 352 p. ISBN 0138543801

[50] De Simone R. ANDRÉ C : Towards a Synchronous Reactive UML subprofile. Projet sports, rapport de recherche, INRIA Sophia-Antipolis, I3S Laboratory, novembre 2003. 14 p. ISRN I3S/RR-2003-26-FR

[51] Diefenbruch M.: 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). In Mitschele-Thiel et al, pp. 17-35. disponible sur: <http://www.cs.uni-essen.de> (consulté le 14.06.2004).

[52] DUPUY S., LEDRU Y., CHABRE-PECCOUD M.: Vers une intégration utile de notations semi-formelles et formelles : une expérience en UML et Z, 2000, Revue l'Objet, vol.6, n°1, Hermès, Paris, pp. 9-32.

[53] Esparza J., Kucera A., Schwoon S.: Model checking LTL with regular valuations for pushdown systems. TACS 2001, 2003, vol. 186, n° 2, pp. 355 – 376.

[54] Etessami K. and Holzmann G.: Optimizing Büchi automata. In Proc. of the 11th International Conference on Concurrency Theory (CONCUR’2000), Lecture Notes in Computer Science Springer Verlag, 2000, vol. 1877 of Lecture Notes in Computer Science, pp. 153–167.

156

[55] Evans A., France R., Lano K., Rumpe B.: The UML as a Formal Modeling Notation. OOPSLA'97 Workshop on Object-Oriented Behavioral Semantics, Technische Universitt Mnchen, Report TUM-I9737. 1997, 12 p.

[56] ELLOY J.P.: qu’est ce que le temps réel ?. Le temps réel. Colloque AFCET. Nantes. Octobre 1990. pp V-XI.

[57] EDWARDS S., LAVAGNO L., LEE E. A., FELLOW, A. SANGIOVANNI–VINCENTELLI: Design of Embedded Systems: Formal Models, Validation, and Synthesis. Proc. Of The IEEE, 1997, vol..85, n° 3, pp. 366—390.

[58] Fidge C. J.: Specification and verification of real-time behaviour using Z and RTL. In J. Vytopil, editor, Formal Techniques in Real-Time and Fault-Tolerant Systems (FTRTFT’92), Lecture Notes in Computer Science ,1992, vol. 571 of Lecture Notes in Computer Science. Springer-Verlag, pp. 393–409.

[59] Fernandez J-C.: An Implementation of an Efficient Algorithm for Bisimulation Equivalence. journal scp, May 1990, vol. 13, number 2-3, pp. 219-236.

[60] Fernandez J-C., Kerbrat A., and Mounier L.: Symbolic Equivalence Checking. June 1993, 12 p. disponible sur <http://inrialpes.fr/CADP/doc> (consulté le 15.06.2004).

[61] Fernandez J-C: Aldebaran : A Tool for Verification of Communicating Processes. Rapport SPECTRE, C14, Laboratoire de Génie Informatique - Institut IMAG, Grenoble, September 1989, 28 p.

[62] Fernandez J-C, Garavel H., Kerbrat A., Mounier L., Mateescu R., Sighireanu M.: CADP A Protocol Validation and Verification Toolbox. 8th International Conference on Computer Aided Verification CAV, New Brunswick (USA), LNCS 1102, 1996, pp.436-440

[63] Ferrari A., Sangiovann A.: System Level Design For Real Time Applications. MDA for Embedded System Development, Brest, 2002, 76 p.

[64] Fischer S., Leue S.: Formal Methods for Broadband and Multimedia Systems, 19th International Conference on Software Engineering, Boston, Massachusetts, 1997, pp. 665 – 666. ISBN 0-89791-914-9.

[65] Fraboulet A.: Optimisation de la mémoire et de la consommation des systèmes multimédia embarqués, thèse de doctorale soutenue novembre 2001, INSA de Lyon, 119 p.

[66] Gerard J. Holzmann.:The Spin model checker. IEEE Transactions on Software Engineering, May 1997, vol. 23 n° 5 pp. 279--295.

[67] Glässer U., Gotzhein R.and Prinz A.: The formal semantics of SDL-2000: Status and perspectives. Computer Networks, vol. 42, n° 3, 21 June 2003, pp. 343-358.

[68] Graf S.:Expression of time and duration constraints in SDL. 3rd SAM Workshop on SDL and MSC, University of Wales Aberystwyth (Wales), Heidelberg: Springer-Verlag Heidelberg, 2002, pp 38-52. ISSN: 0302-9743

157

[69] Goumaa H., Scott D.: Prototyping as a tool in the Specification of User Requirements. Proc. 5th IEEE Int’l Conf. Software Eng, 1981, pp. 333-342.

[70] Giddings R. V.: Accommodating Uncertainty in Software Design. Comm.ACM, 1984, vol. 27, n°. 5, pp. 428-434, 1984.

[71] Gu Z. Shin K. G.: Synthesis of Real-Time Implementation from UML-RT ModelS. TAS Workshop on Model-Driven Embedded Systems (MoDES 2004), Toronto, Canada, 7 p. Disponible sur : <http://www.cse.wustl.edu/~cdgill/RTAS04/MODES_UM.pdf> (consulté le 14.06.2004)

[72] Goumaa H.: Software design Methods for Concurrent and Real-Time Systems. Ed. Reading, MA: Addison-Wesley, 1993, 464 p.

[73] Ghezzi C., Mandrioli D., Morzenti A., TRIO, a logic language for executable specifications of real-time systems. The Journal of Systems and Software, 1990,. vol. 12, n° 2, pp. 107-123.

[74] Harel D., Pneuli A., Schmidt J.P. and Sherman R.: On the formal semantics of Statecharts . 2nd IEEE Symposium on Logic in Computer Science Ithaca, New York, 1987, pp. 54-64.

[75] Henzinger T., Nicollin X., Sifakis J., et Yovine S.: Symbolic model checking for real-time systems. Information and Computation, 1994, vol. 111, n° 2, pp. 193–244.

[76] Hojati R., Shiple T. R., Brayton R.K., Kurshan R. P.: A unified approach to language containment and fair CTL model checking. Proc. of the 30th international on Design automation conference, July 1993, pp 475 – 481. ISBN 0-89791-577-1

[77] Hessel A.: Timing analysis of an SDL subset in Uppaal. Master thesis, Department of Information Technology, Uppsala University, 2002. disponible sur : < http://www.hessel.nu/sdl2xta/abstract.shtml.> (consulté le 14.06.2004)

[78] Harel D., Pnueli A.: On the Development of Reactive Systems. in Logics and Models of Concurrent Systems (K. R. Apt, ed.), NATO ASI Series, vol. F-13, Springer-Verlag, New York : Springer-Verlag, 1985, pp. 477-498

[79] Hatley D., Pirbhai I.: Strategies for Real-time System Specification. Dorset House, New York : Dorset House, 1987, 408 p. ISBN 0-932633-11-0

[80] Harbour, M. G., Klein M. H., and Lehoczky, J. P.: Fixed Priority Scheduling of Periodic Tasks with Varying Execution Priority', Proc. of IEEE Real-Time Systems Symposium, December 1991, 13 p. disponible sur: < http://www.ctr.unican.es/publications/mgh-mk-jl-1991a.pdf> (consulté le 14.06.2004)

[81] Hirsh E.: Evolutionary Acquisition of Command and Control Systems. Program Manager, 1985, pp. 18-22.

158

[82] Harbour M. Gonzlez, Klein M.H. and Lehoczky J.P.: Timing analysis for fixed-priority scheduling of hard real-time systems. IEEE Transactions on Software Engineering, 1994 , vol. 20 1, pp. 13-28.

[83] Houberdon J-L., Babau J-Ph.: MDA for embedded systems dedicated to process control, SIVOEES, UML’2003, San-Francisco. US, October 2003, 10 p. disponible sur : <http://www-verimag.imag.fr/EVENTS/2003/SIVOES-MDA/Papers/Houberdon.pdf > (consulté le 14.06.2004)

[84] Inverardi P. and Priami C.:Evaluation of Tools for the Analysis of Communicating Systems. Pisa Science Center Technical Report HPL-PSC-91-25, Hewlett-Packard Laboratories, Pise, Italie, June 1991, Bulletin of the EATCS 45, pp. 158-185.

[85] ITU-T :Recommendation Z.100, Specification and Design Language (SDL). 1996.

[86] Intel: iRMX II Operating system.V1- V7.Hillsboro.USA.1989.

[87] ITU-T Recommendation Z.109 (1999/11): SDL Combined with UML (SDL/UML). Disponible sur : <http://www.itu.int/ITU-T/index.html > (consulté le 14.06.2004)

[88] Jahanian F. and Mok A. K.: Safety analysis of timing properties in real time systems. IEEE Transactions on software Engineering, SE-12, September 1986, Vol. 12 , n° 9, pp. 890- 904 ISSN:0098-5589

[89] Jahanian F. and Mok A.: A graph-theoretic approach for timing analysis and implementation. IEEE Transactions on Computers, August 1987, vol. 36, n°. 8. pp. 961-975

[90] Jahanian F. and Goyal A.: A formalism for monitoring real-time constraints at run-time. Proc. of IEEE Fault-Tolerant Computing Symposium, June 1990, pp. 148-155.

[91] Jahanian F., Lee R., Mok A. K.: Semantics of Modechart in real time logic, Proc. of the Twenty-First Annual Hawaii International Conference on Software Track, 1988, pp. 479 – 489.

[92] ITU-T :Specification and Description Language (SDL-2000). International Telecommunication Union -Telecommunication standardization sector - Recommendation Z.100, 1999. disponible sur : <http://www.itu.int/ITU-T/index.html > (consulté le 14.06.2004)

[93] Jézéquel J-M.: Advanced modeling techniques: contract, aspect and pattern. Brest, September the 16th to 20th 2002, 114 p.

[94] Julio L., Pasaje M., Harbour M. G., Drake J. M.: MAST Real-Time View : A Graphic UML Tool for Modeling Object-Oriented Real-Time Systems. 22nd IEEE Real-Time Systems Symposium (RTSS'01) December 03 - 06, 2001 London, England, pp. 245-256.

[95] Jones T.C.,:Reusability in Programming : A Survey of the State of the Art. IEEE Trans. Software Eng., 1984, vol. SE-10, Septembre 1984, pp. 488-494.

159

[96] Johnson S.C.: YACC. Yet Another Compiler Compiler. Bell laboratories, Murray Hill, N.J., 1978, A technical. Disponible sur : <http://dinosaur.compilertools.net/yacc/> (consulté le 14.06.2004).

[97] Korver H.:The Current State of Bisimulation Tools, Technical Report P9101, University of Amsterdam - Programming Research Group, Amsterdam, 1991, 23 p.

[98] Klein M.: A practionner’s Handbook for Real-Time Analysis. Boston: Kluwer Academic Publishers, 1993, 712 p. ISBN 0792393619

[99] Kesten Y., Pnueli A.: Timed and Hybrid Statecharts and their Textual Representation. Weizmann Institute of Science, In Formal Techniques in Real Time and Fault-Tolerant Systems 2nd International Symposium, Berlin : Springer-Verlag, 1992, pp. 591 – 620. ISBN 3-540-55092-5

[100] Kuusela J., Kettunen E.: Integrating SDL and Object-oriented Analysis through OMT/SDL, in proc. of the 6th SDL Forum in Darmstadt, Elsevier 1993, pp 89-103.

[101] Liu C.L. et Layland J.W.: Scheduling algorithms for multiprogramming in a hard real-time environment. Journal of the ACM, 1973, vol. 20, n° 1 pp. 46-61

[102] Larsen, Pettersson P., Kim G. and Wang Y.: UPPAAL in a Nutshell. In Int. Journal on Software Tools for Technology Transfer Springer-Verlag. 1998, vol. 1 n° (1-2), pp. 134-152.

[103] Laroussinie F.: Automates temporisés et hybrides : Modélisation et vérification. ETR septembre 2003, Toulouse France, pp. 155-167.

[104] Laroussinie F. and Cassez F.: Model-checking for hybrid systems by quotienting and constraints solving. In E. Allen Emerson and A. Prasad Sistla, editors, 12th International Conference on Computer-Aided Verification. LNCS 1855, Springer-Verlag, July 2000, vol. 1855, pp. 373 – 388. ISBN 3-540-67770-4

[105] Liang P., Arévalo G., Ducasse S., Lanza M., Schaerli N., Wuyts R., Nierstrasz O.: Applying RMA for Scheduling Field Device Components. Seventh International Workshop on Component-Oriented Programming, ECOOP 2002 Workshop Reader, 8 p.

[106] Langendoerfer P., Koenig H.: Automated Protocol Implementations Based on Activity Threads. Seventh Annual International Conference on Network Protocols, October 31 - November 03, 1999, Toronto, Canada, pp 3-10.

[107] Liu C. L., Layland J. W.: Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment'', ACM Journal, 1973, vol. 20, n° 1, pp. 46 - 61.

[108] Lehoczky, J. P.: Fixed Priority Scheduling of Periodic Task Sets with Arbitrary Deadlines, IEEE Real-Time Systems Symposium, December 1990, pp. 201-209.

[109] Leung, J. and Whitehead, J.: On the complexity of Fixed-Priority Scheduling of Periodic, Real-Time Tasks, Performance Evaluation, 1982, vol. 2, pp. 253-250.

160

[110] LE GUENNEC A.: Méthodes formelles avec UML : Modélisation, validation et génération de tests . Actes du 8è Colloque Francophone sur l’Ingénierie des Protocoles CFIP’2000. Toulouse, 17-20 Octobre 2000 Paris : Editions Hermès, Paris, 17-20 octobre 2000, pp. 151-166.

[111] Laplante P. A.: Real-Time Systems Design and Analysis : An Engineer's Handbook. Hardcover New York : Institute of Electrical and Electronics Engineers, 1992, 339 p. ISBN 0780304020

[112] Liu C.L., Layland J.W : Scheduling algorithms for multiprogramming in a hard real time environment, Journal of the Ass. for Computing Machinary, 1973, vol 20, pp 46-61.

[113] Lemoine M., Vigne S.: Integrating semi formal and formal specifications. international workshop on refinement of critical systems : methods, tools and experience, rcs'02 Grenoble, January 22, 2002-imag, 4 p.

[114] Lavazza L.: Guidelines for exploiting formal methods in the tools to be developed in WP2, D 1.7.5, Software Development Process for Real Time Embedded Software Systems (DESS), December 2001, Version 02 – Public. Disponible sur : < http://www.dess-itea.org/deliverables/ITEA-DESS-D175-V02P.pdf> (consulté le 14.06.2004)

[115] Levine J. R., Mason T., Brown D.: Lex & Yacc. 2nd edition. Sebastopol, CA : O'Reilly, 1992, 2nd edition.366 p.

[116] Labrosse J.J.: MicroC/OS-II: the real-time kernel. Emeryville, Lawrence, Kansas : R & D Publications R & D books, Lawrence, 1999,498 p. ISBN 0-87930-543-6.

[117] Mounier L.: Verification methods for behavioral specifications. 31 January 1992, Thesis prepared at the LGI-IMAG laboratory, Grenoble, advisor's name: Fernandez, Jean-Claude, in computer science, 210 p.

[118] Molloy K.: Discrete time stochastic Petri Nets. IEEE Transactions on Software Engineering archive., 1985 ,vol. 11, n° 4, p. 417-423.

[119] Merz S.: Model checking. Proc. of the summer school on Modeling and Verification of Parallel processes - MOVEP’2k, 2000, pp. 51–70.

[120] McMillan K. and Schwalbe J.: Formal verification of the gigamax cache consistency protocol. In Proc. of the International Symposium on Shared Memory Multiprocessing, Tokyo, Japan Inf. Process. Soc., 1991, pp. 242–51.

[121] Mounier L.: Méthodes de Vérification de Spécifications Comportementales : Étude et Mise en Œuvre. January 1992, 203 p..

[122] Mammeri Z.: SDL Modélisation de protocoles et systèmes réactifs, germes, paris, juillet 2000, 623 p. ISBN 2746201666

[123] Microware systems using OS-9000. Des Moines. USA 1991.

161

[124] Masse J., Kim S., and Hong S.: Tool set implementation for scenario based multithreading of UML-RT models and experimental validation. In Proc. of the IEEE Real-Time and Embedded Technology and Applications Symposium, 2003, pp. 70-77,.

[125] Mammeri Z.: Expression et dérivation des contraintes temporelles dans les applications temps réel. APII-JESA, 1998, vol. 32-n°5-6, pp. 609-644.

[126] Meunier F.: Modélisation des ressources linguistiques d’une application industrielle. Conférence TALN 1999, Cargèse, 12-17 juillet 1999

[127] McMillan K. L.: The SMV system, symbolic model checking. Technical Report CMU-CS-92-131, Carnegie Mellon University.

[128] Meunier F., Modélisation des ressources linguistiques d’une application industrielle, Conférence TALN 1999, Cargèse, 12-17 juillet 1999, 10 p. Disponible sur < http://talana.linguist.jussieu.fr/taln99/ps/A57/A57.pdf > (consulté le 14.06.2004)

[129] Manabe Y.: A Feasibility Decision Algorithm for Rate Monotonic and Deadline Monotonic Scheduling, Real-Time Systems, Mar, Kluwer academic publisher, 1998, vol. 14, n° 2 pp. 171-18.

[130] Awad M., Kuusela J., Ziegler J.: Object-oriented technology for real-time systems: a practical approach using OMT and Fusion. Prentice-Hall, Inc. Upper Saddle River, NJ, USA, 276 p. ISBN:0-13-227943-6

[131] Saksena M., Karvelas P., Wang Y.: Automatic synthesis of multi-tasking implementations from real-time object oriented models. In Proc. IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2000, pp.360 – 367.

[132] MEYER B.: Object-Oriented Software Construction, Prentice Hall, 1988. Traduction française : Conception et programmation par objets pour du logiciel de qualité, InterEdition, 1990, 622 p. ISBN : 2729602720.

[133] Ober I.:Spécification et validation des systèmes temporisés avec des langages de description formelles : étude et mise en œuvre. Thèse de doctorat, Institut National Polytechnique de Toulouse, 2001, 193 p.

[134] Ober I. et Kerbrat. A. Verification of Quantitative Temporal Properties of SDL Specifications. Proc. of the 10th SDL Forum, Copenhagen, 2001. (LNCS). 20 p. Disponible sur: <http://www-verimag.imag.fr/~ober/resume.php> (consulté le 14.06.2004)

[135] ObjectGeode, method guidelines. Verilog S.A. April 2000. Disponible sur : <http: //www.telelogic.se/Z100> (consulté le 14.06.2004) (consulté le 12.06.2004)

[136] O.M.G.: O.M.G. U.M.L. Specifications – Version 1.3. 1999. Disponible sur: <http://www.rational.com/uml/resources /documentation /index.jsp> (consulté le 14.06.2004) (consulté le 12.06.2004).

162

[137] OMG, UML 1.4 with Action Semantics, Final Adopted Specification, Disponible sur: <http://www.omg.org/cgi-bin/doc?ptc/02-01-09> (consulté le 14.06.2004)(consulté le 12.06.2004).

[138] Ober I, Graf S., and Ober I : Validating timed UML models by simulation and verification. In Proc. of the SVERTS’03 Workshop (satellite of UML’03 Conference), San Francisco, California, 2003, 12 p.

[139] Pettit IV R. G., Goumaa H.: Integrating Petri Nets With Design Methods for Concurrent and Real-Time Systems. Montreal, CANADA, 21-25 October, 1996, 168 p.

[140] Paludetto M., Delatour J.: UML et les réseaux de Petri : vers une sémantique des modèles dynamiques et une méthodologie de développement des systèmes temps réel. Revue L’objet, Editions Hermes, 1999, vol. 5, n°3-4 :, pp. 443–467.

[141] Petriu D.:Applying SPT profile for performance analysis. MDA for Embedded System Development, Brest, September the 16th to 20th 2002 .

[142] Pettit IV R. G., Goumaa H.: Integrating Petri nets with design methods for concurrent and real time systems. 2nd IEEE International Conference on Engineering of Complex Computer Systems (ICECCS '96) October 21 - 25, 1996 , Montreal, CANADA, pp. 168-171.

[143] Pautet L. and Tardieu S.: What Future for the Distributed Systems Annex. SigAda'99, Redondo Beach, California, october 1999, pp. 77 - 82. ISSN 1094-3641

[144] Quemener, Yves-Marie - Jeron, Thierry: Model-Checking of CTL on Infinite Kripke Structures Defined by Simple Graph Grammars. Rapport de recherche de l'INRIA- Rennes, 16 p., Juin 1995, 16 p.

[145] QUEST. Disponible sur : <http://www.cs.uni-essen.de/Fachgebiete/SysMod/Forschung/QUEST/, 1997> (consulté le 14.06.2004)

[146] QUEST. Disponible sur: <http://www.cs.uni-essen.de/SysMod/QUEST/doc/language.pdf.> (consulté le 14.06.2004)

[147] Ober I, Kerbrat A..Verification of Quantitative Temporal Properties of SDL Specifications, Meeting UML: 10th International SDL Forum - SDL 2001, Lecture Notes in Computer Science, Springer-Verlag Heidelberg, 2001, vol. 2078,. Springer, pp. 182–201. Disponible sur : < http://www.springerlink.com/media/0883LE4NLJ0WTGC4UC5V/ Contributions/Y/J/Y/Q/YJYQ69RY8RF507JK.pdf> (consulté le 14.06.2004).

[148] R. Koymans.: Specifying real-time properties with metric temporal logic. Real-time Systems, 1990, vol. 2, pp. 255-299.

[149] Real Time Developer Studio, V2.1 permet la vérification formelle, Disponible sur : <www.pragmadev.com/news/2.1_FR.pdf> (consulté le 14.06.2004)

[150] Roop P. S., Sowmya A., Ramesh S.: Forced simulation : A technique for automating component reuse in embedded systems, ACM Transactions on Design Automation of Electronic Systems (TODAES), October 2001, vol. 6, n° 4,, pp. 602 – 628.

163

[151] Reed R., ITU-T system design languages (SDL), Computer Networks, 21 June 2003, vol. 42, n° 3, pp. 283-284.

[152] Royce W. W.: Managing the Development of Large Software Systems: Concepts and Techniques. In Proc. of the 9th international conference on Software Engineering, 1987, pp. 328 – 338. ISBN 0-89791-216-0

[153] Roubtsova E., Katwijk J., Toetenel J.: Specification of real time systems in UML. Elsevier, Electronic Notes in Theoretical Computer Science, 2002, vol. 39 n°. 2. 12 p. disponible sur : < http://tvs.twi.tudelft.nl/papers/mtcs2000.html > (consulté le 14.06.2004)

[154] RUMBAUGH et al.: Object Oriented Modeling and Design, Prentice Hall, 1991. Traduction française : OMT– Tome 1 : Modélisation et conception orientées objet, Paris : Masson, Prentice Hall, 1996, 515 p.

[155] Saksena M., Karvelas P.: Designing for Schedulability : Integrating Schedulability Analysis with Object-Oriented Design, In Proc., Euromicro Conference on Real-Time Systems, June 2000, pp 101 – 108.

[156] Saksena M., Ptak A., Freedman P., Rodziewicz P.: Schedulability Analysis for Automated Implementations of Real Time Object-Oriented Models. In Proc., IEEE Real-Time Systems Symposium, December, 1998, pp 92-103.

[157] Saksena M., Karvelas P.: Designing for schedulability : integrating schedulability analysis with object-oriented design. In Proc. of the Euro-Micro Conference on Real-Time Systems, 2000, pp. 101-108.

[158] Schwarz J-J., Skubich J, Aubry R.: Lacatre : The basis for a Real Time Software Engineering Workshop., PEARL 1991 : Boppard, Germany. pp. 20-40.

[159] Schwarz J.J., Lacatre : langage d’aide à la conception d’application multitâches Temps Réel. Revue d’automatique, Productique et informatique industrielle. APII AFCET, 1992, vol. 26, n° 5-6, pp. 355-385.

[160] Schwarz J.J.: Environnement Graphique pour La conception des Applications Multitâches Temps Réel , HDR. Lyon : INSA-LYON, 1995, 158 p.

[161] Schwarz J-J., Jelemenska K., Huang Z., Aubry R., Babau J-P.: From CRSM specification to a real-time multitasking execution model. IEEE International Symposium on Industrial Electronics ( Real-Time session) July 1999, Vol 1, Bled (Slovenia), pp 65-69.

[162] Schwarz J.J., Skubich J.J., Szwed P., Maranzana M.: CASE Tools for iRMX Applications. 10th IRUG International Conference, Portland, USA, October 1993, pp. 43-49.

[163] Simone R., Vergamini D.: Aboard AUTO. Technical Report 111, INRIA, 1989, 24 p. disponible sur : <http://www.inria.fr/rrrt/rt-0111.html> (consulté le 14.06.2004)

[164] Shashidhar K.C.: Specification, Modeling and Verification of Real-time Embedded Systems using ESTEREL. A project submitted in partial fulfillment of the requirements for the degree of Master of Technology, Indian Institute of Technology, Delhi, April 2000,

164

disponible sur :<http://www.cse.iitd.ac.in/esproject/docs/progress_reports/jan1999-jun1999/main/main.html >.

[165] Spitz S., Slomka F., Dörfel M. SDL* An Annotated Specification Language for Engineering Multimedia Communication Systems. Sixth Open Workshop on High Speed Net- works, Stuttgart, October 97. Disponible sur : <http://www7.informatik.uni-erlangen.de/RP/paper/network97.ps.gz > (consulté le 14.06.2004).

[166] Sha L., Rajkumar R., Lehockzy J.: Priority Inheritance Protocols: an Approach to Real Time Synchronisation. IEEE Transaction Computers, 1990, vol. 39, n° 9, pp 1175-1185.

[167] Sha, L. and Goodenough, J. B.: Real-Time Scheduling Theory and Ada, IEEE Computer, 1990, Vol. 23, No. 4, pp. 53-62.

[168] Scholl P-C., Fauvet M-C., Canavaggio J.F.: Un modèle d’historique pour un SGBD temporel. TSI, 1998, vol. 17, n° 3. p. 379-399.

[169] Sommerville I. Le génie Logiciel et ses applications. Paris: InterEditions, Dunod, 1988, 330 p. ISBN 2729601805.

[170] Selic B., Gullekson G, McGee J., Engelberg. I.: ROOM : An object-oriented methodology for developing real-time systems. In Gene Forte, Nazim H. Madhavji, and Hausi A. Muller, editors, 5th Int. Work. Computer-Aided Software Engineering, 6-10 July 1992, pp. 230-240.

[171] Selic B., Gullekson G., Ward P. T.: Real-Time Object-Oriented Modeling. New York : Wiley, Hardcover, 1994, 560 p. ISBN 0471599174

[172] Sellier D.: A language and methodology to model real time embedded system and changes and evaluate system properties. 56 p. disponible sur <http://www.empress-itea.org/deliverables/D4.1_v1.0_Public_version.pdf> (consulté le 14.06.2004)

[173] Selic B., Raumbaugh. J.: Mapping SDL to UML. A Rational Software white paper, 1999, 12 p. Disponible sur : < http://www.rational.com/media/whitepapers/sdl2umlv13.pdf > (consulté le 14.06.2004)

[174] Selic B. and Rumbaugh J.: Using UML for Modeling Complex Real-Time Systems. White Paper, Published by Objec-Time March 1998. disponible sur : <www.objectime.com> (consulté le 14.06.2004) (consulté le 12.06.2004)

[175] SDL-RT: Specification and description language –Real-Time. Disponible sur : <http://www.sdl-rt.org/> (consulté le 14.06.2004)

[176] Sprunt H. M. B., Sha L., Lehoczky J. P.: Aperiodic Task Scheduling for Hard Real-Time Systems'', The Journal of Real-Time Systems, 1989, n°. 1, pp. 27-60.

[177] Stankovic J. A.: Misconceptions about real-time computing: a serious problem for the next-generation systems. IEEE Computer., 1988, vol. 21, n° 10, pp 10-19.

165

[178] Thomas L., Lambolais T., Lesiour R., et Covadis A.:Architectural Techniques for the Description and Validation of Distributed Real-Time Systems. In Proc. of the 2th International Symposium on Object-oriented Real-time distributed Computing - ISORC’99, 1999, pp. 223-236.

[179] Teyssié C, Mammeri Z., Carcenac F., Boniol F., Dtim: Etude comparative de SDL et UML pour la modélisation de systèmes temps réel. RTS, Paris, France, Mars 2003, 23 p. disponible sur < http://www.cert.fr/francais/deri/boniol/Papiers_pdf/RTS03.pdf > (consulté le 14.06.2004) (consulté le 11.07.2004).

[180] Teyssié C., Mammeri Z.: Analyse des approches d'extension de SDL pour la spécification de systèmes et réseaux temps réel. RTS Embedded Systems 2002, Paris, 26-28 Mars 2002.

[181] Terrier F., Fouquier G., Bras D., Rioux L., Vanuxeem P., Lagnusse A.: A Real-Time Object Mode. TOOLS EUROPE '96, 1996, pp.127-14.

[182] Terrier F.: UML and Real-Time, MDA for Embedded System Development. Brest, September the 16th to 20th 2002., 51 p.

[183] Telelogic: ObjectGeode, method guidelines. Disponible sur : <April 2000 http://www.telelogic.com> (consulté le 14.06.2004)

[184] The UML Group. UML Semantics. Version 1.1, Rational Software Corporation, Santa Clara, CA-95051, USA, July 1997, disponible sur :< http://www.uml.crespim.uha.fr/documentation/version1.0/semantics/semantics.html>.

[185] Yovine S.: Kronos : A Verification Tool for Real-Time Systems. Intenational Journal of Software Tools for Technology Transfer, Springer Verlag 1997, vol. 1, n°. 1-2, December 1997, pp. 123-133.

[186] Xiaohui C., Song J., Liu W.S.: Maintaining Temporal Consistency : Pessimistic vs. Optimistic Concurrency Control. IEEE transactions on knowledge and data engineering 1041-4347/95, 1995 IEEE October 1995, vol. 7, n°. 5, pp. 786-796.

[187] Ward P., Mellor S.: Structured Development for Real-time Systems.New York : Yourdon Press, New York, 1985, 163 p.

[188] <http://www.ifad.dk/Projects/iptes.htm> (consulté le 14.06.2004)

[189] Wellings. A.J., Audsley N.C., Burns A., Richardson M.F., “Hard Real-Time Scheduling: The Deadline-Monotonic Approach. Proc. 8th IEEE Workshop on Real-Time Operating Systems and Software, 1991.

[190] Wind river systems: VxWorks Programmer’s Guide. Alameda, USA, 1992.

[191] Wind River Systems. VxWorks Programmer’s Guide, 5.4 Edition 1, 6 May 1999 Part #: DOC-12629-ZD-01.

[192] <http://www.rational.com/products/rosert/> (consulté le 14.06.2004)

[193] <http://www.lynx.com/> (consulté le 14.06.2004)

166

[194] <http://www.omg.org/> (consulté le 14.06.2004)

[195] <http://www.windriver.com/> (consulté le 14.06.2004)

[196] <http://www.ilogix.com/rhapsody/uml/uml.cfm/> (consulté le 14.06.2004)

[197] <http://mast.unican.es/.> (consulté le 14.06.2004)

[198] < http://developer.berlios.de/projects/la4/Project : la4-project – Survol> (consulté le 14.06.2004)

[199] <http://www.lucenttls.com/displayProduct.cfm?prodid=32> (consulté le 14.06.2004)

[200] <http://www.telelogic.com/products/tau/sdl/index.cfm/> (consulté le 14.06.2004)

[201] <http://java.sun.com/> (consulté le 14.06.2004)

[202] <http://www.timesys.com> (consulté le 14.06.2004)

[203] <http://www.inrialpes.fr/vasy/cadp/> (consulté le 14.06.2004)

167

Bibliographie liée à l'étude Communication Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:. SDL and IF for Real time Systems development: specification, design and validation. To be submitted to WRTP (accepté le 1er Juin 2004) Babau J-Ph, Alkhodre A: A development method for PROtotyping embedded SystEms by

using UML and SDL (PROSEUS) workshop SIVOEES 2001 – ECOOP, Budapest 2001

Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:. Méthodologie de développement de systèmes embarqués temps réel basée sur le langage SDL. L3I. CAO aura lieu les 15, 16 et 17 mai 2002 à Paris sur le thème «CAO de circuits et systèmes intégrés».

Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:., Real time multitasking design based on SDL, FDL2002, April 2002.

Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:. SCHWARZ, Modélisation des systèmes embarquées temps réel à l’aide de SDL, FDL 2001 septembre, Lyon

Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:. “Modeling of Real-Time Constraints using SDL for Embedded Systems Design” IEEE workshop, londres 3 decembre 2001.

Articles (journal) Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:. Modelling of Real-Time Embedded

Systems using SDL”, System on Chip Design Languages, publié par Kluwer 2002

Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:., Modelling of Real-Time Constraints using SDL for Embedded Systems Design” IEE Computing and Control Engineering Journal, Augustus 200.

Soumissions Khatab A., Alkhodre A. Khatab A., J-P. Babau, J-J Schwarz J-J:., Formal development of

Real Time Systems: a compatibility relation between specification and implementation models To be submitted to FORMATS.

168

Annexes

169

Annexe 1

Nous montrons dans cette annexe le mode d'utilisation (le modèle d’interconnetion) des composants présentés dans le chapitre de modèle d'exécution via une grammaire décrite classiquement en forme BNF (Backus Naur Form).

Supposons la définition de la grammaire suivante :

G = (N, T, P, S) où

N est les objets du langage N = AL, ALR, ISR, WD, Procédé_ext, PS, PT, SW,ST (Où, ALR, AL, ISR, WD, Procédé_ext, PS, PT, SW sont l'ensemble de composants prédéfinis dans notre boîte à outil) T est les communications possibles entre les éléments de N, T = SET_wd, RESET_wd, IT_niv, Sig_IT_n, MSG_loc, Delete_n, TOP_n, Sig_TOP_n (Où SET_wd, RESET_wd, IT_niv, Sig_IT_n, MSG_loc, Delete_n, TOP_n, Sig_TOP_n sont des primitives circulées entre les composants) S est application P est un sous-ensemble de P ∈ (N ∪ T) * .N.(N ∪ T) * X (N ∪ T)* application::= set_objet ; set_objet ::= set_ logical_component wd services_os; set_ logical_component ::= ISR MSG_loc SW | AL TOP_n ALR | ALR Sig_TOP_n PT | Procédé_ext IT_niv PIC | SW MSG_loc task | ALR Sig_TOP_n PS, ISR Sig_IT_n PS | ALR TOP_n PS, task MSG_loc_n PS | ISR Sig_IT_n ST |ISR SET_wd WD | ALR SET_wd WD | WD Delete_n PS | WD Delete_n PT | WD Delete_n SW | PS RESET_wd WD | PT RESET_wd WD | ST RESET_wd WD | SW RESET_wd WD | ISR EOI PIC | ISR Mask_IT PIC | PS UnMask_IT PIC | ST UnMask_IT PIC | set_composant_logiciel

170

task ::= SW | PT | PS | ST ; services_OS ::= ISR | ALR | AL ALR ::= Fig 7.5 AL ::= Fig 6.4 ISR ::= Fig 7.2 et 7.3 PS ::= Fig. 7.10 PT := Fig 7.7 SW::= Fig 7.12 PIC::= Fig 7.18 WD::= Fig 7.20

171