Mécanismes d’ordonnancement et de communication dans la ...

N° d’ordre : 5/TRC Année universitaire 2001 – 2002

UNIVERSITE D’ANTANANARIVO------------------------------

ECOLE SUPERIEURE POLYTECHNIQUE------------------------------

DEPARTEMENT TELECOMMUNICATIONS

MEMOIRE DE FIN D‘ETUDES

En vue de l’obtention du diplôme d’ingénieur

Spécialité : Télécommunications

Option : Transmission – Réseaux – Commutation

Soutenu par :

RAKOTONANAHARY Hajatiana

Mécanismes d’ordonnancement et de communication dans la sous couche MAC des

réseaux locaux temps réel

Soutenu le mercredi 13 août 2003 à 8 heures devant la commission d’examen composé de :

Président :Monsieur ANDRIAMIASY Zidora

Examinateurs :Monsieur RATSIHOARANA Constant

Monsieur RANDRIANTSIRESY Ernest

Monsieur BOTO ANDRIANANDRASANA Jean Espérant

Directeur de mémoire :Monsieur RADONAMANDIMBY Edmond Jean Pierre

Remerciements

« Mais par la grâce de Dieu, je suis ce que je suis »I Corinthiens 15 :10a

« Mon bouclier protecteur c’est Toi »Psaumes 119 :114a

« Reconnaître l’autorité du Seigneur est l’a b c de la sagesse, Lui être fidèle permet d’acquérir l’intelligence »

Proverbes 9 :10

Je veux dire merci au Seigneur,De tout mon cœur je veux remercier le Dieu Saint.

Oui, je veux remercier le Seigneur,Sans oublier un seul de ses bienfaits

A mes parents,

A mes frères et belle sœur,

A mon neveu,

A toute la famille,

A tous mes amis,Mes sincères remerciements pour votre soutien et vos prières.

2

Avant Propos

Je tiens à exprimer mes remerciements à Monsieur RADONAMANDIMBY

Edmond, qui a accepté de diriger mon travail de mémoire, pour toute sa disponibilité et tous les

conseils qu’il m’a apportés tout au long de ce travail. Je lui serais toujours reconnaissant pour

toute la confiance et l’autonomie de recherche qu’il m’a accordé qui m’ont permis d’arriver au

bout de la réalisation de ce mémoire.

J’exprime mes plus vifs remerciements à :

Monsieur ANDRIAMIASY Zidora

Monsieur RATSIHOARANA Constant

Monsieur RANDRIANTSIRESY Ernest

Monsieur BOTO ANDRIANANDRASANA Jean Espérant

pour l’honneur qu’ils me font en participant à la commission d’examen et particulièrement à

Monsieur ANRIAMASY Zidora pour avoir accepté la charge d’être le président de jury.

A tous les enseignants de l’ESPA (Ecole Supérieure Polytechnique d’Antananarivo) ,

plus particulièrement au Chef de Département des Télécommunications

RANDRIAMITANTSOA Paul Auguste et ses collègues qui m’ont apporté beaucoup pour que

je puisse arriver à ce stade, je vous dis un GRAND MERCI !

Mes remerciements s’étendent à l’ensemble de touts les futurs ingénieurs de ma

promotion.

Toute ma reconnaissance à l’ensemble du personnel du département des

télécommunications à l’Ecole Supérieure Polytechnique d’Antananarivo (ESPA).

3

Table des matières

Introduction……………………………………………………………………………………………… ...1

Partie 1 : Ordonnancement et communication dans la sous couche MAC des réseaux locaux temps réel

CHAPITRE I : CONTEXTE DE L’ETUDE……………….……………..…..….……….….…….. ……..5

I.1 Système temps réel………………………………….………………………………………………….. 5

I.1.1 Présentation générale d’un système temps réel………..…......…………….....…………….……...5

I.1.2 Problèmes liés au système temps réel………………………...….………………………..………...5

I.1.3 Structure d’un système temps réel……………….………………………..………………..…….....6

I.2 Communication dans un système temps réel……………………………...…………………………………8

I.2.1 Généralités sur les tâches temps réel…………….………..…….………...…..….………………...8

I.2.2 Modélisation des tâches temps réel……………..……………….………..…….………………… .11

I.2.3 Les besoins et les contraintes des tâches…………………….….……..………..………………... .11

I.3 Ordonnancement des tâches temps réel…………………………..…………………..………………….… 13

I.3.1 Généralités sur l’ordonnancement des tâches temps réel……….………………....…… ……… .13

I.3.2 Typologie d’algorithmes d’ordonnancement…….…….……..………………… ………………. .13

I.3.2.1 Algorithme en ligne- Algorithme hors ligne………………………………………….……… …………13I.3.2.2 Algorithme statique – Algorithme dynamique………………………….……………………..……….

.13I.3.2.3 Algorithme préemptif – Algorithme non préemptif…………………….…………………..…………

.14

I.2 Réseaux locaux temps réel…………………………………………………..………..….…………... .14

I.2.1 Généralités sur les réseaux locaux temps réel…………..…………….……...…………..………….... .14

I.2.1.1 Architecture…………………………………………..…………………………………………………...15

I.2.1.2 Mode de fonctionnement………………………………..…………….………………………………….16

I.2.1.3 La sous couche MAC………………...…………..…………………….……………….………………...18

4

I.2.2 Communication dans les réseaux locaux temps réel…………………………………….….…… .18

I.2.2.1 Généralités………….…………………………………..……………………………………….………...18

I.2.2.2 Les messages au niveau de la sous couche MAC…………..…………..…………………...…………...19

I.2.2.3 Les caractéristiques des messages temps réel……………..…………..…...…………………. …..…… .19

I.2.3 Ordonnancement des messages temps réel…………………....……...………………………..… .20

I.2.3.1 Sur l’ordonnancement des messages temps réel…..……………………..……………………………..20

I.2.3.2 Techniques d’ordonnancement du transfert de flux de messages……….. …………………………...20

I.2.3.3 Les techniques d’accès MAC…….………..……..………………….……… …………………………...21

CHAPITRE II: ORDONNANCEMENT DES TACHES TEMPS REEL………….....…….…………... .22

II.1 Ordonnancement des tâches temps réel…………………………………………….………………. 22

II.1.1 Les principaux algorithmes préemptifs……………………………...……….….……………… .22

II.1.1.1 Algorithmes pour les tâches périodiques……………………...…………..……………..……………..22

II.1.1.1.1 Algorithme Rate Monotonic (RM)…………………...…………………………………..…………... .22II.1.1.1.2 Algorithme Deadline Monotonic (DM)…….…………..…………………………………………….. .26II.1.1.1.3 Algorithme Earliest Deadline (ED)………………….……………….……………………………… .26

II.1.1.2 Algorithmes pour les tâches apériodiques…………....……………………..………………………....27

II.1.1.2.1 Ordonnancement des tâches apériodiques à contraintes relatives…………………………...………… .27II.1.1.2.2 Ordonnancement des tâches apériodiques à contraintes strictes……………………………...……….. .28

II.1.2 Les principes des algorithmes non-préemptifs :……………………………………………………... .28

II.1.2.1 RM non préemptif……………………………………………………………………………………....28

II.2. Ordonnancement en présence de partage de ressources…………………………………………….... 30

II.2.1 Protocole à héritage de priorité……………………………………………….……...………………… .30II.2.2. Protocole à priorité plafond…………………………………………………………...……………….. .31

CHAPITRE III : LES PROTOCOLES MAC TEMPS REEL.……………………………………………..32

III.1 Généralités sur les protocoles MAC temps réel……………………………………………………...…. 32

III.1.1 Classification des protocoles………………………………...….……………………….…….. .32

5

i

III.1.2 Principe général des protocoles de la classe 1……………………….………………………………….. ..32

III.1.3 Principe général des protocoles de la classe 2……………..………………..………………….…… .33

III.2 Les protocoles de classe 1.……………………………………………………………………...…... .34

III.2.1 Protocole à accès aléatoire : Le protocole CAN……………………………..…..……...…………..…… ..34

III.2.1.1 généralités………………………………………………..…………….…………………………….…..34

III.2.1.2 Principe de fonctionnement……………………………………………...….………………………….34

III.2.1.3 Assignation de priorités…………………………………………...…………………………………....35

III.2.1.4 Arbitrage de priorités……………………………………...…………………………………………...37

III.2.2 Protocoles à accès à contrôle centralisé : Le protocole DQDB…………..……………………….. .38

III.2.2.1 Généralités………………………………………………………………………………..……………..38

III.2.2.2 Principe de fonctionnement…………………………………………………………………………….39

III.2.2.3 Assignation de priorités…………………………………………………………………….…………..40

III.2.2.4 Arbitrage d’accès……………………………………………………………………………………….40

III.2.3 Protocoles à accès à contrôle distribué : L’IEEE 802.5…..….……...…...……………………….. .41

III.2.3.1 Généralités……………………………………………………………………………..………………..41

III.2.3.2 Principe de fonctionnement…………………………………………………………………………….42

III.2.3.3 Assignation de priorités…………………………………………………………………….…………..45

III.2.3.4 Arbitrage de priorités…………………………………………………………………………………..45

III.3 Les protocoles de classe 2…………..…………………...………………………………………..… .47

III.3.1 Protocole à accès aléatoire : L’IEEE 802.3………..…………….….………………………………. .47

III.3.1.1 Généralités……………………………….……………………………………………………………...47

III.3.1.2 Principe de fonctionnement…………………………………………………………………………....47

III.3.1.3 Assignation de priorités………………………………………………………………………………...48


III.3.2 Protocoles à contrôle distribué : Le protocole « Jeton temporisé » : FDDI………….…………. .50

6

ii

III.3.2.1 Généralités…………………………………………………….……...………………………………....50

III.3.2.2 Principe de fonctionnement……………………………………………..………..………….………...51

III.3.2.3 Assignation de priorités………………………………………………………………………………...53


CHAPITRE IV : LA NORME IEC-65C………………………………………………………………………..60

IV.1 Généralités sur L’IEC-65C……..………...……………………………………………………..…. .60

IV.1.1 Problématique de l’ordonnancement du trafic temps réel……………..……………………...…...… ..60IV.1.2 L’IEC-65C………………………………...…....….…………………………………….…….. …………60IV.1.3 Les différents trafics dans un réseau local temps réel………………..………...…………………... .61

IV.2 : Principe de fonctionnement……………….……………………………………..……………..... .62

IV.2.1 L’ordonnancement du trafic apériodique temps réel..………..…...……….……………………….. .63IV.2.2 L’ordonnancement du trafic périodique…………………………..…………….…………………… .64IV.2.3 Ordonnancement des messages non temps réel………………...…..……....……………………….. .65IV.2.4 L’ordonnancement conjoint……………………….……….………………………….…….………… .65

CHAPITRE V : MODELISATION AU MOYEN DES RESEAUX DE PETRI TEMPORISE STOCHASTIQUE (RdPTS) DU SYSTEME FONCTIONNANT SOUS LA NORME IEC-65C

V.1 Modélisation du système fonctionnant sous la norme IEC-65C………………………………….. .67

V.1.1 Le réseau de Petri Temporisé stochastique……………………………………..…………………….. .67

V.1.2 Modélisation du système fonctionnant sous la norme IEC-65C……………..………………….…. .68

V.1.2.1 Le modèle du LAS……………………………………………………………………….……………….68

V.1.2.1.1 Génération des jetons EA…………………………………………………………………………..... .69V.1.2.1.2 Génération des jetons EP……………………………………………………………………………...70V.1.2.1.3 Génération des jetons EN………………………………………………………………………...….. .71V.1.2.1.4 L’accès au média des jetons…………………………………………...………………….….………..71V.1.2.1.5 Les restrictions RM (Rate Monotonic)…………………………………….…………………………...73V.1.2.1.6 Modèle complet du LAS………………………………………………….………………………...….75

V.1.2.2 Le modèle du service des flux de messages périodiques……………………………………………….75

V.1.2.2.1 Arrivée du jeton EP…………………………………………………………...…………….………. .75

7

V.1.2.2.2 Génération des flux de messages périodiques Mpi……………………………………………………. .76V.1.2.2.3 Transmission d’un fragment de messages périodiques……………………….……………………….. .76

V.1.2.3 Le modèle du service des flux de messages apériodiques temps réel………………………………....77

V.1.2.3.1 Arrivée du jeton EA…………………………………………………………………………………...77V.1.2.3.2 Génération des flux de messages apériodiques Maj…………………………………………………… .78V.1.2.3.3 Transfert des flux de messages apériodiques non temps réel et temps réel……………………………….78

V.1.2.4 Le modèle du service des flux de messages apériodiques non temps réel...…………………………..79

V.1.2.4.1 Arrivée du jeton EN…………………………………………………………………………………. .79V.1.2.4.2 Production du flux global de trafic apériodique non temps réel………………………………………....80V.1.2.4.3 Mécanismes relatifs au transfert du trafic non temps réel…………………….………….……………..80

CHAPITRE VI : ANALYSES…………………………………..………………………………………………. .82

VI.1 Hypothèses…………………………………………..……..……………………………………………….…. 82

VI.1.2 Modèle complet de l’exemple……..…...……………………..………………………………………… .82

VI.1.3 Signification des places et des transitions de cet exemple.…..…….………………………………. .84

VI.1.3.1 Le LAS……………………………………………………………………………………...…………....84

VI.1.3.1.1 Les places du LAS……………………………………………………………….……………….… .84VI.1.3.1.2 Les transitions du LAS………………………………………………………….……….……….…..85

VI.1.3.2 Accès et utilisation du média……………………………………………….…………………………..85

VI.1.3.2.1 Les places de l’accès et de l’utilisation du média……………...………….…………………………....85VI.1.3.2.2 Les transitions de l’accès et de l’utilisation du média…………….…………………………………... .85

VI.1.3.3 Service de flux de messages apériodiques temps réel……………………….………………………...86

VI.1.3.3.1 Les places…………….…………………………………………………………..…………...……..86VI.1.3.3.2 Les transitions…………….………………………………………………………………..………. .86

VI.1.3.4 Service de flux de messages périodiques temps réel………………….………………………….…...87

VI.1.3.4.1 Les places…………………………………………………………………….………...… ………. .87VI.1.3.4.2 Les transitions……………………………………………………………………....……...………. .87

VI.1.4 Analyse effectuée…………...………………………..….……..….….……………………….… .87

VI.1.5 Objectif de l’analyse……..………………………...……..…….…………………………..…… .87

VI.2 : Analyses et résultats……….………….…………………………………..…………………….… .88

VI.2.1 Cas 1 (ordonnancement des flux périodiques seuls) ………….…..…….…..…………………..…. .88

8

iii

VI.2.1.1 Première analyse du cas 1……………………………………………………………………….….….88

VI.2.1.2 Deuxième analyse du cas 1………………………………………………………………………..…....91

VI.2.1.3 Troisième analyse du cas 1……………………………………………………………………………..93

VI.2.1.4 Quatrième analyse du cas 1………………………………………………………………..… …….…...96VI.2.1.5 Cinquième analyse du cas 1………………………………………………………………..... …………98VI.2.1.6 Sixième analyse du cas 1………………………………………………………………...…… ………..100VI.2.1.7 Septième analyse du cas 1…………………………………………….………….……..…… ………..102

VI.2.2 Récapitulation des résultats des analyses du cas 1……………………..……………....…. ………..104

VI.2.3 Cas 2 (ordonnancement des flux apériodiques et périodiques temps réel)…………….. ………..105

VI.2.3.1 Première analyse du cas 2………………………………………………………………….... ………..105VI.2.3.2 Deuxième analyse du cas 2…………………………………………………………………... ………..109VI.2.3.3 Troisième analyse du cas 2………………………………………………………….……..… ………..111VI.2.3.4 Quatrième analyse du cas 2…….……………………………………………………………. …….….113VI.2.3.5 Cinquième analyse du cas 2………..………………………………………………………… …….….115VI.2.3.6 Sixième analyse du cas 2……….…………………………………………………….………. ………..117VI.2.3.7 Septième analyse du cas 2…………………………………………………………….…..…. ………..119

VI.2.4 Récapitulation des résultats des analyses du cas 2……………………..…….….. ………………....122

Partie 2 : Présentation des études et analyses (choix multiplies) d’ordonnancement de tâches apériodiques et périodiques dans un réseau local temps réel en pages Web

1.Description………………………………………………..……………………………….…..…………………. 124

2. Page « Accueil »………………………………………………………………………………….……….…….. 124

3. Page « A propos »………………………………………………………..………………………………….….. 129

4. Page « Modèle du système »………………………………………………………………...………………... 131

5. Page « Caractéristiques du serveur du trafic temps réel»…………………………….…………………133

9

iv

6. Page « Choix des capacités des flux de messages Mp1 à Mp6 »……………………………..………… 136

7. Page « Choix des capacités des flux de messages Mp7 à Mp11 »……………………………………… 138

8. Page « Choix des capacités des flux de messages Mp12 à Mp17 »…………………………….………. 140

9. Page « Choix des capacités des flux de messages Mp18 à Mp22 »………………………………….…. 142

10. Page « Choix des capacités des flux de messages Mp23 à Mp27 »…………………………………... 144

11. Page « Résumé des choix »…………………………………………………………………………….……. 145

12. Page « Séquence d’ordonnancement »……………………………………………………………………. 148

13. Page « Tableau récapitulatif des principaux résultats »…………………………………….………… 149

Conclusion…………………………………………………….………………………………………..…..152

10

v

ABREVIATIONS

AMPCANCSMA/CDDMDQDBEAEDEPENFDDIFIFOISOISRLANLASLCLLCMAMAC MPMSAUOSIPAPC PDUPDU CDPDU EEPDU ETPDU ESPRGQARdPTSRMRTRSOFSP TCP/IPTHTTRTTTRTVCI

:Active Monitor Present:Controller Area Network:Carrier Sense Multiple Access with Collision Detection:Deadline Monotonic:Distribued Queue Dual Bus:Execute Aperiodique (Jeton):Earliest Deadline:Execute Perdiodique (jeton):Execute Non temps réel (jeton):Fiber Distributed Data Interface:First In First Out:International Organization for Standardization:Interrupt Service Routine (Routine d’interruption):Local Area Network:Link Active Scheduler:Late Counter:Logical link Control:Message Apériodique:Media Access Control:Message Périodique:MultStation Access Unit:Open System Interconnection:Pre-Arbitrated:Pointeur d’instruction:Protocol Data Unit:Protocol Data Unit Compel Data:Protocol Data Unit End of Execution:Protocol Data Unit Execute Transaction:Protocol Data unit Execute Sequence:Trame de Purge:Queue Arbitrated:Réseau de Petri Temporisé Stochastique:Rate Monotonic:Remote Transmission Request:Start Of Frame:Pointeur de pile:Transmission Control Protocol/Internet Protocol:Token Holding Time:Token Rotation Timer:Target Token Rotation Timer:Virtual Circuit Indentifier

vi

Introduction

1

Si l’on ne gère pas le trafic urbain des automobiles, la circulation dans une grande

ville serait catastrophique car il se pourrait, qu’une voiture mette plusieurs heures pour parcourir

une route d’une dizaine de kilomètres. En conséquence, divers bouleversements, souvent néfastes,

viennent perturber le programme qu’on s’est fixé de suivre et de faire ; des malades ne pourraient

pas arriver à temps à l’hôpital pour se soigner, des rendez-vous très important seraient manqués,

…Il en est de même dans le trafic des réseaux locaux et c’est pire encore quand il s’agit des

réseaux locaux temps réel où les différents messages y circulant sont contraints temporellement.

La notion temps réel correspond à la façon dont les tâches et les messages sont

exécutés dans le temps. C’est donc une notion qui garantit à l'usager, que quel que soit le moment

où on lance un programme, si on lui passe les mêmes paramètres de travail, son temps

d'exécution sera toujours le même. On peut distinguer deux notions: Le vrai temps réel où le

programme fournira les résultats avant que les effets des paramètres se fassent sentir dans la

réalité (exemple: si une tuile tombe du toit, les calculs seront terminés avant que la tuile ne touche

le sol) et Le faux temps réel où un programme calcule plus lentement par rapport aux évènements

réels mais le temps de calcul est toujours le même.

Installer des feux et des panneaux de signalisation, ainsi qu’engager des agents

pour gérer les accès ( c’est à dire ordonnancer) des véhicules, des piétons, des charrettes…, aux

différentes voies peuvent être des solutions de gestions du trafic urbain ; tandis qu’ intégrer un ou

plusieurs mécanismes d’ordonnancements des tâches et messages temps réel, rendra beaucoup

meilleur le trafic dans les réseaux locaux temps réel et permettra à l’appellation « réseaux locaux

temps réel » d’avoir un sens.

Une application temps réel peut être vue comme un système de tâches et/ou de

messages se synchronisant et partageant des ressources dont les processeurs, les médias. Les

fortes contraintes temporelles auxquelles ces tâches et ces messages sont soumises doivent être

respectées. Une gestion d’accès aux ressources est donc primordiale et ne doit pas être prise à la

légère. Le non-respect de ces échéances entraînera des situations critiques, voir même

catastrophiques.

Dans le réseau local, c'est plus précisément la sous-couche MAC, qui gère l'accès

à la ressource de transmission partagée entre les messages sur les différentes stations. Il faut bien

noter la différence en termes de performance attendue entre un réseau local classique (sans

contraintes temporelles) et un réseau local temps-réel: dans un réseau local classique, les

2

performances s'expriment en termes de temps de réponse moyen (par exemple, temps moyen

écoulé entre l'instant d'occurrence d'une requête et l'instant d'occurrence de l'indication

conséquente); Par contre, la notion de temps moyen est « une notion qui peut être dangereuse

dans un contexte réseau local temps-réel où il s'agit avant tout de garantir des temps de réponse

bornés supérieurement dans le pire cas ».

Cette sous couche MAC (Media Access Control) doit intégrer des mécanismes

d’ordonnancement et de communication pour pouvoir gérer et ordonnancer de manière

explicite les échanges relatifs à chaque type de trafics temps réel (périodiques, apériodiques) et

d’autre part le meilleur effort pour le trafic non temps réel. C’est le fondement de l’étude qui va

être présentée dans ce mémoire.

Le travail réalisé est présenté dans ce mémoire en deux parties :

La première partie comprend six chapitres :

Chapitre 1 : Contexte de l’étude qui présente les mécanismes des systèmes temps

réel, leur problématique. et des généralités sur les réseaux locaux temps réel ;

Chapitre 2 : Ordonnancement des tâches temps réel qui a pour objectif de présenter

les principales techniques d’ordonnancement qui garantissent le respect des

échéances temporelles des tâches et messages au moyen du test d’ordonnancement ;

Protocoles d’accès MAC temps réel où une classification des principaux protocoles

existants est présentée, mettant en exergue l’aspect d’ordonnancement des messages ;

La norme IEC-65C : une norme étudiée et proposée pour la sous couche MAC pour

l’ordonnancement du trafic dans un réseau local temps réel.

Modélisation du système fonctionnant sous la norme IEC-65C au moyen des

réseaux de Petri temporisé stochastique (RdPTS)

Analyses d’un exemple de système fonctionnant sous la norme IEC-65C au niveau de

la sous couche MAC.

La deuxième partie présente la conception de pages Web des études et analyses (choix multiples)

d’ordonnancement de messages apériodiques temps réel.

3

Partie 1 :Mécanismes d’ordonnancement et de

communication dans la sous couche Mac des réseaux locaux temps réel

4

CHAPITRE I :CONTEXTE DE L’ETUDE

I.1 Système temps réel [5]-[6]-[7]-[8]-[9]-[10]-[13]-[15]-[18]

I.1.1 Présentation générale d’un système temps réel

Un système temps réel est un système interagissant avec l’environnement d’un

procédé auquel il est connecté pour réaliser les applications temps réel par l’exploitation des

ressources limitées.

Cet environnement possède des priorités temporelles variables et affiche un

comportement prévisible et dépendant du temps. De par ce fait, un système temps réel est très

soumis à des contraintes temporelles fortes.

Un système est donc qualifié de temps réel s’il peut garantir la réponse temporelle

(exactitude temporelle) du système à des événements externes tout en assurant la justesse des

calculs (exactitude logique).

Figure I.1 : Définition d’un système temps réel

I.1.2 Problèmes liés au système temps réel

Les systèmes temps réel ont des tâches à exécuter ( calculer une action, écrire le résultat

d'un calcul sur un écran de visualisation, effectuer une mesure, détecter l'éventuelle présence d'une

panne latente, signaler des comportements anormaux…). Ils doivent en même temps respecter des

fortes contraintes temporelles. Mais ce n’est pas toujours évident parce que ces tâches peuvent être

Acquisition TraitementRestitution et

commande

Système temps réel

Environnement

5

indépendantes et peuvent donc être exécutées simultanément. Des conflits se créent alors au

moment de leur exécution. Les deux sources majeures de ces conflits sont:

La réclamation simultanée du même processeur par plusieurs tâches (conflits sur le

processeur) ;

La demande d’accès à des données non partageables (conflit sur les ressources).

On constate alors que les problèmes essentiels reliés aux systèmes temps réel se situent

d’une part au niveau de l’ordonnancement temps réel des tâches et, d’autre part, sur les services de

communication adaptés à des besoins d’échanges d’information entre les tâches distantes,

temporellement contraintes. Alors, bien que l’aspect d’ordonnancement des tâches soit présent

dans toutes les structures de contrôle des systèmes temps réel, cela n’est jamais suffisant pour

rendre un système temps réel valide, c’est à dire, respectueux des contraintes temporelles fortes. Il

faut en plus un ordonnancement temps réel des messages et une gestion temps réel des connexions

et des contrôles de flux d’erreur qu’on appellera gestion temps réel de communication. Et c’est sur

ces deux aspects que notre travail se portera.

I.1.3 Structure d’un système temps réel

Un système temps réel comporte, en général, trois grandes parties, dont nous montre la

figure I.2:

Le procédé (logiciel d’application) : C’est un système physique dont l’image est fournie au

système de contrôle par l’intermédiaire des capteurs, et qui reçoit les commandes du système

de contrôle à l’aide des actionneurs.

Le logiciel d’exploitation temps réel comprend un « système de contrôle » (programme

utilisateur) et un « exécutif temps réel » ( noyau temps réel) .

Le système de contrôle (programme utilisateur) :

Cette partie du système temps réel tient compte de l’état du procédé en fonction des images qui

lui ont été communiqué par les capteurs. Elle formule, ensuite, une requête conforme à cette

image et l’envoie à l’exécutif temps réel. Ce dernier lui retourne un signal d’activation après

avoir traité la requête et une commande sera communiquée au procédé au moyen des

actionneurs par le système de contrôle. Toutes ces fonctions sont représentées par un ensemble

de logiciels d’application qui sont codés sous la forme d’un ensemble de tâches et dont

l’exécution sur une architecture physique s’appuie sur un exécutif temps réel.

6

L’exécutif temps réel (le noyau) :

C’est lui qui doit attribuer la ressource (c’est à dire le processeur) aux tâches au cours du temps

selon une politique d’ordonnancement. En même temps, il doit gérer les ressources nécessaires à

l’exécution des tâches ainsi que la synchronisation entre celles-ci. Les caractéristiques essentielles

d’un noyau temps réel sont :

Création et gestion des tâches ;

Création et gestion de sémaphores binaires et comptés ;

Fonction d’attente des tâches ;

Suspension et continuation de tâche ;

Envois de messages depuis une routine d’interruption (ISR) ou d’une tâche vers une autre

tâche.

Le noyau agit en sorte que les tâches, dont le temps d’exécution est critique, sont effectuées en

premier.

Le matériel qui regroupe les différentes ressources.

Figure I.2 : Modèles d’architecture en couches d’un système temps réel.

On peut prendre comme exemple de système temps réel, un entrepôt automatisé.

L’environnement (procédé) correspond à l’entrepôt et aux robots ou automates de production. Et

ce sont l’ordinateur de maintenance et l’interface homme-machine qui constituent la partie

contrôleuse (le noyau temps réel et le système de contrôle). Un schéma plus détaillé d’un système

temps réel est donné ci dessous :

Logiciel d’application

Logiciel d’exploitation temps

réel

matériel

7

Logiciel

d’exploitation

Temps réel

Ressources

Figure I.3 : Système temps réel

I.2 Communication dans un système temps réel [6]-[7]-[13]-[16]-[22]-[28]-[29]-[34]

I.2.1 Généralités sur les tâches temps réel

Les tâches sont les différents programmes de l’utilisateur écrits dans un langage de haut

niveau et de primitifs temps réel (prise et libération de la ressource, émission et réception de

messages)

Rassemblées dans un système de tâches, elles définissent ce qu’on entend par application

temps réel qui met en œuvre un système informatique dont le fonctionnement est assujetti à

l’évolution dynamique de l’état d’un environnement qui lui est connecté et dont il doit contrôler le

comportement.

Chaque tâche est reconnue par son identificateur et son niveau de priorité. Chaque tâche

possède un identificateur numérique unique qui est spécifié à la création de la tâche. Ce nombre

est compris entre 1 et 255. Un nombre important de tâches peut créer avec un identificateur 0

permet de créer autant tâches que l’on souhaite. Un administrateur de tâches gère le contrôle du

processeur en attribuant ce dernier à la tâche de plus grande priorité en attente d'exécution.

ProcédéLogiciel d’application

Systèmes de contrôle

actionneurs capteurs

Exécutif temps réel (ordonnancement des tâches,

gestion de ressources et communication)

8

256 niveaux de priorité peuvent être attribués (0 à 255), le niveau 0 est le plus prioritaire.

N'importe quelle tâche peut avoir n'importe quel niveau de priorité; plusieurs tâches peuvent avoir

le même niveau. Dans un groupe de même priorité, les tâches s'exécutent dans l'ordre où elles sont

passées prêtes à l'exécution. A tout moment, il est possible de changer la priorité d’une tâche

tandis que modifier son identificateur est impossible.

A tout instant, une tâche peut se trouver dans quatre états différents selon son évolution

au sein du système :

Etat actif (en cours) : C’est le cas de la tâche qui est en train de s’exécuter et qui a le contrôle du

processeur. A un instant donné, une seule tâche peut se trouver dans cet état. C'est l'ordonnanceur

qui décide de l'attribution du processeur. Une tâche restera dans cet état tant qu'elle ne rencontrera

pas une condition de suspension, mais surtout tant que l'ordonnanceur le décidera. La tâche en

exécution est celle qui, à un instant donné, est la plus prioritaire parmi les candidates à l'attribution

du processeur.

Etat Prêt : C’est le cas des tâches qui sont en attente de pouvoir s’exécuter. C’est l’ordonnanceur

qui choisit parmi les tâches se trouvant dans cet état celle qui passera en exécution. Une tâche

restera dans cet état si une tâche plus prioritaire est en exécution.

Etat en attente: Etat des tâches qui sont en attente d’une condition pour passer à l’état prêt. Une

tâche peut être suspendue, soit si elle en reçoit l'ordre explicitement, soit si elle est en attente d'une

information ou d'une ressource provisoirement indisponible.

Etat endormi (non opérationnel) : Une tâche endormie est, soit non encore créée, soit terminée

définitivement donc supprimée. C’est le cas des tâches qui sont en attente d’événements

(interruption ou réception de message ou encore fin d’un décompte de timer) qui provoqueront

leur réveil.

9

Figure I.4: Evolution d’une tâche

A chaque tâche est attribué un degré de priorité différent et qui, souvent, change de

priorité à chaque fois que la tâche change d’état. Quand il n’y a qu’un seul processeur, une seule

tâche est active à un moment donné, pas forcément la plus prioritaire. Il faut aussi savoir que la

durée des tâches dépend de leur codage.

Conceptuellement, chaque tâche est associée à un processeur virtuel comprenant

son pointeur d'instructions (PC), son pointeur de pile (SP), sa zone de données.

On peut rencontrer trois types de tâches :

Tâches périodiques : tâches activées à un intervalle de temps régulier et qui sont dédiées le

plus souvent au contrôle ;

Tâches apériodiques : tâches activées à des instants aléatoires ;

Tâches sporadiques : ce sont des tâches apériodiques dont une borne minimale de la durée

séparant deux activations successives est connue. Les tâches sporadiques peuvent être activées

par les tâches périodiques dans certains cas d’urgence. Outre, ce sont des tâches apériodiques

qui ne doivent en aucun cas manquer leurs échéances.

10

I.2.2 Modélisation des tâches temps réel

On modélise une tâche ζi par quatre paramètres (figure I.5):

Ii : Date de réveil de la tâche, première activation

ci : Durée maximale d’exécution d’un travail de la tâche (pire durée d’exécution)

Pi : Période d’activation

di : Délai critique, échéance de la tâche : intervalle maximum admissible, entre l’instant

d’arrivée d’une requête d’exécution d’un travail de la tâche et l’accomplissement de ce travail.

Considérons le cas des tâches périodiques :

Figure I.5 : Modèle des tâches

Ces paramètres ne sont pas figés mais doivent être choisis pour permettre au système de

satisfaire des contraintes temporelles qui sont imposées au procédé. On dit que deux tâches ζi et

ζk sont synchrones si Ii et Ik sont identiques. Une tâche est dite à échéance sur requête si di est

identique à pi.

1.2.3 Les besoins et les contraintes des tâches

Une application temps réel est considérée comme une association de plusieurs tâches.

Donc chaque tâche doit collaborer étroitement avec les autres tâches de la même application

qu’elle. En effet, les tâches doivent avoir besoin de :

11

se synchroniser : une tâche doit attendre un événement extérieur qui provoquera une

interruption et se synchronise après avec la routine d’interruption (ISR : Interrupt Service

Routine). Un ISR est un composant d’un système temps réel. Il est activé par un événement

extérieur. Deux tâches doivent s’assurer qu’elles travaillent sur une même valeur dans les cas

où elles doivent utiliser une même donnée. Pour cela, elles doivent se communiquer ; c’est le

deuxième besoin essentiel des tâches ;

communiquer : pour pouvoir se synchroniser avec les autres tâches, les tâches doivent

s’échanger des informations à l’aide des « boîtes aux lettres » ou encore à l’aide des « files de

messages » qui sont des objets du noyau temps réel et accessibles via services ;

partager : un des besoins des tâches aussi est le partage des ressources car celles ci sont très

limitées alors que la demande est importante.

Le système ne peut pas satisfaire ces besoins sans tenir compte des contraintes régissant les

tâches. Ces contraintes peuvent être classées sous deux catégories :

• Les contraintes individuelles des tâches

• Les contraintes collectives des tâches

Les contraintes individuelles : Il faut comprendre que même si une tâche doit collaborer avec

d’autres tâches de la même application, elle doit avoir ses propres contraintes:

• Contrainte de criticité ;

• Contrainte de priorité ;

• Contrainte d’autorisation de réquisition du processeur ;

• Contraintes temporelles ;

• Contraintes liées à la précision des résultats des tâches.

Les contraintes collectives : Les relations étroites que les tâches ont au sein d’une application les

conduisent à avoir des contraintes collectives :

• Contrainte de précédence ;

• Contrainte de partage de ressources ;

• Contraintes de distribution.

12

I.3 Ordonnancement des tâches temps réel [1]-[3]-[4]-[19]-[31]-[35]-[40]

I.3.1 Généralités sur l’ordonnancement des tâches temps réel

La problématique de l’ordonnancement des tâches temps réel est la construction d’une

séquence temporelle de l’ensemble des tâches à exécuter. Cette construction nécessite la

modélisation des tâches ainsi que définition d’un algorithme d’ordonnancement.

L’ordonnancement est, en fait, une fonction centrale dans un système temps réel. C’est à

lui de réorganiser l’affectation des ressources ( processeurs) en vue du respect des contraintes

temporelles des tâches en fonction de l’apparition des entrées en provenance du système contrôlé

(entraînant la demande d’exécution d’une tâche).

Nous consacrerons plus particulièrement l’étude sur les caractéristiques temporelles des

tâches en ne considérant pas les contraintes de précédence qu’elles peuvent avoir. Un algorithme

d’ordonnancement aura donc à construire les séquences temporelles en se basant sur la

connaissance de ces caractéristiques temporelles.

I.3.2 Typologie d’algorithmes d’ordonnancement :

I.3.2.1 Algorithme hors ligne – algorithme en ligne

L’ordonnancement peut se faire de deux façons suivant les algorithmes utilisés. Ces

derniers peuvent être « hors ligne » ou « en ligne ».

Algorithme hors ligne : Ici les paramètres temporels des flux de messages doivent être connus

avant le démarrage du transfert. La séquence d’ordonnancement est pre-calculée avant le transfert

des messages et à l’exécution. L’ordonnanceur n’est qu’un simple séquenceur, c’est à dire que les

travaux sont exécutés dans l’ordre préétabli sans que cet ordre puisse être modifié. C’est un

algorithme très efficace mais trop rigide.

Algorithme en ligne : Dans cet autre type d’algorithme, les décisions d’ordonnancement sont

prises au cours de l’exécution. Pour ce faire, l’ordonnanceur implémente un algorithme

d’ordonnancement. C’est très cher mais c’est aussi l’un des algorithmes le plus flexible.

I.3.2.2 Algorithme statique – algorithme dynamique

Les algorithmes d’ordonnancement peuvent être aussi dits statiques ou dynamiques :

13

Algorithme statique : L’algorithme est dit statique lorsque l’ordonnancement est prévisible avant

la mise en fonctionnement du système. On doit alors connaître à priori les taches.

Algorithme dynamique : Dans ce cas ci, on ne connaît pas les paramètres de tâches qu’au moment

de leur arrivée. L’ordonnancement est créé au fur et à mesure de l’arrivée des tâches. Ce type

d’algorithme d’ordonnancement doit donc tenir compte des changements et des événements.

De ces différents classements des algorithmes, ressort une autre classification des

ordonnanceurs comme les ordonnanceurs « tout planifié » c’est à dire basé sur les algorithmes

hors ligne et statique, ainsi que les ordonnanceurs « à base de priorité » étant en ligne et pouvant

être dynamique et statique. On trouve aussi les ordonnanceurs « dynamiques » qui sont fondés sur

les algorithmes en ligne et dynamique.

I.3.2.3 Algorithme préemptif – algorithme non préemptif

La notion de préemptif apparaît pour l’ordonnancement à base de priorité :

Algorithme préemptif : Dans cet algorithme, l’exécution d’une tâche en cours peut être arrêtée au

profit d’une autre tâche plus urgente ou plus prioritaire. Cet algorithme ne peut pas être appliqué

dans le cas d’un transfert de messages car celui ci ne peut pas être interrompu ( un message est

transmis entièrement ou non.).

Algorithme non préemptif : C’est le contraire de l’algorithme préemptif. On l’utilise dans le cas de

l’exécution d’une tâche qu’on ne peut pas interrompre. C’est le cas des transferts de messages ou

de flux de messages. C’est pour cette raison que l’ordonnancement de ces derniers doit se baser

sur des algorithmes non préemptifs.

I.4 Réseaux locaux temps réel [20]-[31]-[32]-[39]

I.4.1 Généralités sur les réseaux locaux temps réel

"Un réseau local temps réel a pour objet de permettre à un nombre important d'utilisateurs

de communiquer entre eux, sans intermédiaire, pour échanger n'importe quel type d'information

avec le minimum de contraintes d'utilisation et de durée d'exécution"

Les réseaux locaux sont utilisés pour faire communiquer des équipements divers en

fournissant des services contraints temps réel au sein d’un bâtiment qui peut être une école, une

entreprise, une industrie, une usine… Ces réseaux locaux peuvent avoir des caractéristiques

différentes suivant le contexte où ils se trouvent. En général, on peut rencontrer trois types de

réseaux locaux :

14

Réseau général qui est souvent un Ethernet avec TCP/IP (Transmission Control Protocol/

Internet Protocol) et dont le temps de transmission peut aller jusqu’à quelques mégabits par

minute.

Réseau d’atelier qui est souvent aussi un Ethernet avec TCP/IP(Transmission Control

Protocol/ Internet Protocol) mais avec des contraintes temps réel un peu plus sérieuses que

pour le réseau général.

Réseau de terrain où le temps de transmission est très minime ce qui favorise l’exécution des

applications temps réel.

I.4.1.1 Architecture

Des études ont été faites sur les différents systèmes ouverts qui existaient déjà et qui

avaient leurs propres architectures. Ces dernières sont souvent très différentes les unes des

autres, donc difficiles à interconnecter. Des recommandations ont été publiées et un modèle de

référence a été mis en place par l’Organisation Internationale de Normalisation (ISO) pour

normaliser les communications. Celui ci est une architecture standard à sept couches et connue

sous le nom de modèle de référence OSI (Open Systems interconnection).

Couche 7

Couche 6

Couche 5

Couche 4

Couche 3

Couche 2

Couche 1

Figure I.6: Modèle de référence ISO d’OSI

Couche application

Couche présentation

Couche session

Couche transport

Couche physique

Couche réseau

liaison de donnéesCouche MAC :contrôle de

l’accès au médium

Couche LLC :contrôle de la liaison de données

15

Mais l’architecture que l’on rencontre le plus souvent dans les réseaux locaux temps réel,

est celle comportant trois couches (modèle ISO réduit).

FigureI.7: Modèle ISO réduit

La couche « application » qui rassemble presque toutes les fonctions des couches hautes du

modèle standard : Synchronisation et établissement d’une entente sur la procédure de correction

d’erreur et de contrôle d’intégrités des données, traduction des différents formats de présentation

des données en utilisant un format commun, gestion de l’échange des données, segmentation ou

assemblage des données…

La couche « liaison de données » qui assure un transit fiable des données sur une liaison physique,

s’occupe de l’adressage physique, l’accès au réseau, la notification des erreurs, la livraison

ordonnée des trames et le contrôle de flux. Elle se divise en deux sous couche :

La sous couche LLC ( Contrôle de liaison logique) qui permet à une partie de la couche

liaison de données de fonctionner indépendamment des technologies existantes en assurant

la polyvalence des services fournis aux protocoles de couche située au-dessus d’elle.

La sous couche MAC (Media Access Control) qui gère l’accès au média.

La couche « physique » qui fournit les moyens électriques, mécaniques nécessaires à la

transmission des données. Elle permet aussi la transmission des bits entre entités de liaison de

données et notifie les dérangements détectés à la couche liaison de données.

I.4.1.2 Mode de fonctionnement

Lorsque les informations à envoyer descendent à travers les couches d'un système donné,

elles ressemblent de moins en moins au langage humain et de plus en plus aux 1 et aux 0 que

l'ordinateur comprend. Chaque couche utilise son propre protocole pour communiquer avec la

Couche application

Couche liaison de données

Couche physique

Couche LLC : logical link control

Couche MAC : Media access control

16

couche homologue de l'autre système. Les informations échangées entre des couches homologues

par le protocole de chaque couche sont appelées unités de données de protocole (PDU : Protocol

Data Unit). Voici la correspondance des couches et des PDU :

Couche application Données

Couche présentation Données

Couche session Données

Couche transport Segments

Couche réseau Paquets

Couche liaison de données Trames

Couche physique Bits

Exemple : un hôte A souhaite envoyer le courrier électronique suivant à l'hôte B :

«ordonnancement et communication dans la sous couche MAC des réseaux locaux temps réel».

L'encapsulation des données s'effectue en cinq étapes afin que le courrier électronique soit

transmis à la destination appropriée :

Etape1 : Lorsqu'un utilisateur envoie un message électronique, les caractères alphanumériques

sont convertis en données depuis la couche 7 jusqu'à la couche 5.

Étape 2 : À l'aide des segments à la couche 4, la fonction de transport prépare les données en vue

de leur transport sur le réseau et vérifie que les hôtes à chaque extrémité du système de messagerie

peuvent communiquer de façon fiable.

Étape 3 : Au niveau de la couche 3, les données sont placées dans un paquet (ou datagramme)

contenant un en-tête réseau constitué des adresses logiques d'origine et de destination. Ensuite, les

équipements transmettent les paquets au réseau via un chemin déterminé.

Étape 4 :Chaque équipement de réseau doit placer le paquet dans une trame au niveau de la couche

2 afin d'assurer la connexion à l'équipement suivant de la liaison directement connectée. Chaque

équipement se trouvant sur le chemin sélectionné doit effectuer un verrouillage de trame pour se

connecter à l'équipement suivant.

Étape 5 : La trame doit être convertie en une configuration de 1 et de 0 en vue de la transmettre

via le média (souvent un fil de cuivre ou une fibre optique) au niveau de la couche 1.

17

Selon leur mode de fonctionnement, les réseaux locaux peuvent être classés en deux

catégories : réseaux point à point et réseaux à diffusion. Mais en règle générale, les réseaux locaux

fonctionnent en mode de diffusion. Ceci nécessite un protocole d’accès particulier, qui garantit

une répartition équitable de la capacité du support physique entre les équipements raccordés. La

question principale est alors comment on alloue les canaux disponibles aux stations en cas de

compétition. Les protocoles, qui définissent l’accès sont, définis à la sous-couche MAC.

I.4.1.3 La sous couche MAC (Media Access Control)

La sous couche MAC (Media Access Control ou sous couche d’accès au canal) est la

partie basse de la couche liaison de données. Elle regroupe les différents protocoles d’accès au

média. En, effet, c’est elle qui gère l’accès à la ressource de transmission. Pour ce faire, elle doit

assurer deux fonctions primordiales :

• Ordonnancement des messages,

• Réalisation des techniques ou protocoles d’accès aux médias.

Cette sous couche est très importante dans les réseaux locaux et plus particulièrement

dans ceux dont le fonctionnement repose sur le principe de l’accès multiple.

I.4.2 Communication dans les réseaux locaux temps réel

I.4.2.1 Généralités

Venant des applications, les données sont traitées par les différentes couches supérieures

de l’architecture du réseau local et subissent une encapsulation au fur et à mesure de leur descente

vers les couches inférieures. Une fois arrivées au niveau de la couche liaison de données, où se

trouve la sous couche MAC, le train de bits, c’est à dire les données, est découpé en trames (unités

de données de service de la couche liaison de données) que nous appellerons messages.

Il y a une similitude assez évidente entre les messages temps réel et les tâches temps réel

mais pas sur tous les points. Les messages temps réel ont les même besoins ainsi que les même

contraintes que les tâches temps réel. Ils ont presque le même modèle que les tâches temps réel.

La différence fondamentale entre les messages temps réel et les tâches temps réel réside

sur le fait que la transmission d’un message ne peut pas être interrompue ( un message est

transmis entièrement ou pas du tout), alors que l’exécution d’une tâche temps réel peut être

habituellement interrompue au bénéfice d’une tâche plus prioritaire.

18

I.4.2.2 Les messages au niveau de la sous couche MAC

Banalement connus sous le nom de trames, Les messages soumis au service MAC

peuvent être classés soit comme des messages temps réel (Contraintes strictes associées au

transfert.) ; Soit comme des messages non temps réel (Pas de contraintes associées au transfert). Il

faut savoir qu’il n’y a que les trafics temps réel qui circulent dans un réseau local temps réel. Il y a

aussi les trafics non temps réel qu’il doit traiter et transmettre.

Pour présenter les messages au niveau de service MAC, considérons un réseau local

comportant m stations et voyons différents cas de rassemblement de ces messages. Pour les

messages temps réel, nous distinguons deux cas :

Soit nous divisons les messages temps réel en deux sous ensemble :

• Un sous-ensemble comportant p messages périodiques Mp={ Mp1, Mp2, …Mpp}

• Un autre sous-ensemble ayant s flux de messages apériodiques à contraintes strictes

Ma={Ma1, Ma2, …Mas}

Soit, nous ne considérons qu’un seul ensemble de messages temps réel englobant à la fois

ceux qui sont périodiques et ceux qui sont apériodiques. M={M1, M2, …Mn} Ce regroupement

peut être fait dans la mesure où on définit pour les flux apériodiques un temps minimal entre

deux arrivées consécutives (vu comme une période)

Pour les massages non temps réel, nous définissons un ensemble N comportant m flux de

messages : N={N1, N2, …Nm}.

I.4.2.3 Caractéristiques des messages temps réel

Vu du côté de l’ordonnanceur, les caractéristiques importantes des messages temps réel

sont les suivantes :

Pi (Pj) est la petite valeur de temps séparant deux requêtes consécutives de message d’un flux

temps réel pour leur ordonnancement. Dans le cas particulier des messages périodiques, Pi est la

période.

Ci (Cj) est la durée maximale de l’utilisation de la ressource de transmission pour transférer un

message d’un flux temps réel.

di (dj) est l’échéance, c’est à dire l’intervalle de temps maximum entre l’instant d’arrivée d’une

requête d’un message d’un flux temps réel et l’instant où l’utilisation de la ressource de

19

transmission pour transférer ce message doit être terminé. On peut avoir une échéance avant

requête, c’est à dire dj<Pj ou sur requête, c’est à dire di=Pi (dj=Pj)

Ii (Ij) est la différence de phase entre la première arrivée d’une requête d’un message du flux

temps réel et une référence temporelle commune à l’ensemble des flux de messages.

I.4.3 Ordonnancement des messages temps réel

I.4.3.1 Sur l’ordonnancement des messages temps réel

Nombreux sont les flux de messages venant des stations émettrices qui veulent accéder à

la ressource de transmission pour parvenir à leurs destinations (Stations réceptrices) tout en étant

contraints temporellement. Il faut donc attribuer la ressource aux flux de messages au cours du

temps selon une politique bien définie, qu’on appelle politique d’ordonnancement.

L’ordonnancement du transfert de message doit donc être vu sous l’angle de deux

processus :

Le processus d’arbitrage d’accès qui détermine quand le flux de messages ou la station a le

droit d’utiliser la ressource.

Le processus de contrôle de la durée de transmission qui détermine combien de temps le

flux de messages ou la station a le droit d’utiliser la ressource de transmission.

Un ordonnancement est valide s’il permet à tous les messages de respecter leurs

contraintes temps réel.

I.4.3.2 Techniques d’ordonnancement du transfert de flux de messages.

On distingue deux types de techniques d’ordonnancement de transfert de flux de

messages :

L’ordonnancement basé sur une assignation de priorités aux flux de messages où une

priorité unique est assignée à chaque flux de messages. Cette assignation est donnée en

fonction des contraintes des messages et change suivant la politique d’ordonnancement et

l’état des messages. Cette technique d’ordonnancement repose donc sur l’attribution des

niveaux de priorité aux différents flux de messages.

L’ordonnancement basé sur une garantie de temps d’accès borné aux stations. Ces

dernières ordonnent leur flux de messages en local, le protocole MAC définit ensuite un

arbitrage d’accès qui fait que chaque station accède à la ressource équitablement.

20

I.4.3.3 Les techniques d’accès MAC

Accès non contrôlé ou aléatoire :

Ici, on fait appel à la méthode du « premier arrivé, premier servi ». Ce protocole permet à

quiconque de transmettre. Il se crée une sorte de compétition au niveau des stations. Il se peut

alors que deux ou plusieurs stations décident d’émettre simultanément ce qui va engendrer des

collisions dans le système. Une résolution sérieuse de ces dernières s’avère alors important si on

veut accéder au médium d’une façon aléatoire. Des protocoles ont été créés pour résoudre ce

problème de collisions notamment le CAN qui se base sur la résolution des collisions avec

forçage, et l’IEEE 802.3 qui résout les problèmes de collision sans forçage.

Accès contrôlé :

Dans ce mode d’accès contrôlé, on fait appel à une forme de « Chacun son tour ». La distribution

d’un « droit à la parole » est gérée soit par une seule station (cas d’un accès à contrôle centralisé),

soit par coopération entre stations (cas d’un accès à contrôle décentralisé). Une élection est donc

établie pour savoir quelle station peut « prendre la parole ».

Dans le cas où l’accès serait centralisé, soit la station de contrôle envoie à chaque station

un message qui lui donne le droit d'utiliser le réseau, soit, elle joue le rôle d’une horloge qui

définit des intervalles de temps que les stations puissent utiliser.

Par contre, si l’accès est à contrôle décentralisé ou encore distribué, on fait recours à une

circulation d’un jeton ou bien à la technique de partage de temps global où chaque station connaît

à l’avance le temps où elle peut utiliser la station.

Les différents protocoles utilisés dans cette étude :

Le CAN (Controller Area Network)

Le DQDB (Distributed Queue Dual Bus)

L’IEEE 802.5

L’IEEE 802.3

Le jeton temporisé : FDDI (Fiber Distributed Data Interface)

21

CHAPITRE II : ORDONNANCEMENT DES TACHES TEMPS REL

II.1 Ordonnancement des tâches temps réel [1]-[3]-[4]-[11]-[16]-[19]-[31]-[35]-[40]

L’un des problèmes fondamentaux dans les systèmes multitâches est celui de

l’ordonnancement. C’est l’ordonnanceur qui assure cette fonction ; c’est à dire gérer les tâches et

garantir leur exécution concurrente. Son rôle est alors d’affecter équitablement le processeur aux

processus en optimisant son utilisation relativement à certains critères. Le problème

d’ordonnancement est encore plus délicat dans un système temps réel car en plus de la résolution

des problèmes classiques, on doit tenir compte des fortes contraintes temporelles. Des

algorithmes ont été mis en place, justement, pour assurer le respect de ces dernières. Nous allons

en spécifier deux grandes catégories d’algorithmes d’ordonnancement des tâches temps réel : Les

algorithmes préemptifs dans un premier temps et les algorithmes non-préemptifs dans un second

temps.

II.1.1 Les principaux algorithmes préemptifs

Des classements ont été faits aussi suivant la nature des tâches. Nous rappelons que les

tâches peuvent être périodiques ou apériodiques (sporadiques). Nous évoquerons alors en premier

lieu les principaux algorithmes utilisés pour les tâches périodiques, et en deuxième lieu ceux qui

sont destinés pour les tâches apériodiques (sporadiques).

II.1.1.1 Algorithmes pour les tâches périodiques

II.1.1.1.1 « Rate Monotonic » ou RM

Le « Rate Monotonic » (RM) fait partie des algorithmes à priorités fixes. On parle

d’ordonnancement à priorités fixes lorsque les différentes instances successives d’une même

activité possèdent toutes la même priorité.

C’est un algorithme qui a été inventé par Liu et Layland en 1973 et qui est basé sur des

priorités statiques. En effet, on assigne les priorités aux processus (tâches) selon leur période

respective. Plus la période est petite, plus la priorité est grande. On résout alors les conflits

arbitrairement. Cet algorithme s’applique à l’ordonnancement des tâches périodiques,

indépendantes et à échéance sur requête, c’est à dire quand l’échéance est égale à la période

d’exécution d’une tâche.

22

Test d’ordonnançabilité : Liu et Layland ont démontré que lorsque la condition suivante est

rencontrée, on aura toujours un résultat d’ordonnancement. Donc l’ordonnancement RM d’un

ensemble de n tâches est faisable si la relation suivante est satisfaite:

)1()/( 2/1 −≤= ∑ i

nnPiCiU ( II-1)

où i indique le nombre de tâches.Démonstration de l’obtention de ce test d’ordonnancement :

Le but est d’atteindre une utilisation maximale du processeur en toute sécurité. On

cherche donc la borne d'utilisation maximale pour tout ensemble de tâches qui utilisent le

processeur au maximum de ses capacités. Dans le cas de deux tâches, on veut démontrer qu'il

existe une valeur Umin indépendante des valeurs des Ci et des Ti telle que si U = Umin alors les

tâches i sont ordonnançables. On montrera également que

)1(2 22/1

min −=U (II-2)

Considérons deux tâches ζ1, ζ2 caractérisés par leurs périodes T1 et T2 et leurs capacités.

On fait l’hypothèse que T2>T1, par conséquent la tâche ζ1 est plus prioritaire que ζ2. On peut

déduire de cette hypothèse que le nombre d’activation de ζ1, dans l’intervalle [0,T2], est donné

par la le rapport : T2/T1

La démarche est comme suit : pour C1 donné, on cherche C2 de façon à utiliser au

maximum le processeur. On obtient alors l’expression C2 en fonction de C1, T1 et T2.

TTTC

TC f

U2

211

1

1 ),,(+= (II-3)

En étudiant la variation de U en fonction de C1, on constatera que U présente un

minimum pour une valeur particulière de C1. On obtient donc Umin (T1, T2). Il ne reste plus qu'à

minimiser Umin par rapport à T1 et T2 pour obtenir la borne souhaitée.

23

Au départ deux cas peuvent se présenter : soit la dernière activation de P1 (juste avant

T2) est telle que P1 termine son exécution avant T2, soit la dernière instance de P1 ne termine pas

son exécution avant l'activation suivante de P2. Ces deux études montrent que U est minimum

pour C1=T2 – T1[T2/T1] et que cette valeur minimale est :

(II-4)

En posant f=(T2/T1)-[T2/T1] ; partie décimale de T2/T1 et I= [T2/T1] , en rappelant que

T2>T1, on montre que la fonction Umin telle que :

(II-5)

Umin est minimum pour I= 1 et ensuite pour f= 21/2-1 et donc : Umin= 2(21/2-1) qui est la

borne recherchée indépendante de C1, C2,T2 et T1.

Figure II.1: Schéma de la fonction U = f(C1)

24

Exemple : Considérons un ensemble de trois tâches ζ={ζ1, ζ2, ζ3,}, avec (ci, pi)={

(2,5),(2,10),(3,20)} à ordonnancer par l’algorithme RM. La condition suffisante

d’ordonnançabilité est satisfaite (u=∑(Ci/Pi)=75%<3((2)1/3-1)=78%), l’ensemble de tâches est

donc ordonnançable. Voici la séquence temporelle d’exécution des tâches après l’instant critique :

ζ1

t

ζ2 t

ζ3 5 1O 15 20 25 30 t

FigureII.2 : Séquence temporelle des tâches (RM)

Dans cet exemple, c’est la tâche ζ1 qui est la plus prioritaire. C’est donc elle qui est

exécutée la première. C’est à la tâche ζ3 qu’on attribue la priorité la moins prioritaire et ζ2 se voit

affectée d’une priorité se trouvant entre celles des deux autres tâches. L’exécution de la tâche

moins prioritaire est toujours préemptée pour permettre l’exécution des deux autres tâches plus

prioritaires afin que celles si puissent respecter leurs contraintes temporelles tout en tenant

compte, toute fois, celles de la tâche la moins prioritaire.

II.1.1.1.2 Algorithme “Deadline Monotonic” (DM)

C’est un algorithme d’ordonnancement qui a été mis en place par Leung et Whitehead en

1985. Il est classé parmi les algorithmes à priorités fixes comme l’algorithme RM. Ici, la priorité

d’une tâche est inversement proportionnelle à son échéance relative. Ce type d’algorithme est

utilisé dans l’ordonnancement des tâches périodiques, indépendantes et à échéance avant requête

(l’échéance≤ période).

25

Test d’ordonnançabilité: Soit n le nombre de tâches à ordonnancer, pour pouvoir être

ordonnançables, l’ensemble de ces tâches doit respecter la condition suffisante suivante:

)1()/( 2/1 −≤= ∑ i

nndiCiU(II-5)

Où n indique le nombre de tâches à ordonnancer.

II.1.1.1.3 Algorithme Earliest Deadline (ED)

L’algorithme « Earliest Deadline » est classé dans la catégorie des algorithmes à priorités

dynamiques où l’on affecte aux tâches des priorités choisies suivant leur date d’échéance.

L’avantage par rapport aux algorithmes à priorités fixes est que celui ci permet d’accepter un plus

grand nombre de configurations de tâches.

C’est un algorithme dont les travaux fondamentaux ont été faits par Liu et Layland en

1973. A un instant donné, la tâche la plus prioritaire (parmi les tâches prêtes) est celle dont

l’échéance est le plus proche. Ce type d’algorithme est utilisé dans l’ordonnancement des tâches

périodiques, indépendantes et à échéance avant requête (échéance ≤ période).

Test d’ordonnançabilité :L’ordonnancement ED d’un ensemble de n tâches périodiques ζ={ζ1,

ζ2,…, ζi,…, ζn} est faisable si le système satisfait la condition nécessaire et suffisante suivante :

1)/(∑ ≤i

PiCi(II-6)

Exemple : Reconsidérons l’ensemble de trois tâches ζ tel que ζ={ ζ1, ζ2, ζ3} avec (ci,

pi)={(1,5),(3,6),(5,100)}, à ordonnancer cette fois ci avec l’algorithme ED. Le test

d’ordonnancement est vérifié car (∑(Ci/Pi)=0,75 ≤ 1). Voici la séquence d’ordonnancement de cet

ensemble de tâches.

ζ1t

ζ2 t

ζ3 5 1O 15 20 25 30 t

Figure II.3 : séquence temporelle des tâches (ED)

26

II.1.1.2 Algorithmes pour les tâches apériodiques

Dans un système temps réel, il n’y a pas que les tâches périodiques qu’on pilote et qu’on

ordonnance, il y a aussi les tâches occasionnelles comme les procédures liées au démarrage ou à

l’arrêt du système, les traitements d’urgence, en réponse à des situations critiques s’exprimant par

l’arrivée de signaux d’alarme. Le problème se situe alors sur l’ordonnancement de ces tâches

occasionnelles qu’on appelle aussi tâches apériodiques. Dans ce cas, l’algorithme

d’ordonnancement doit pouvoir ordonnancer les tâches apériodiques et, en même temps, ne doit

pas mettre en cause l’ordonnançabilité des tâches périodiques.

Diverses techniques d’ordonnancement ont été énoncées suivant la nature des tâches

périodiques. Il y a les techniques qui sont rattachées à l’ordonnancement des tâches apériodiques à

contraintes relatives, et celles qui vont avec l’ordonnancement des tâches apériodiques à

contraintes strictes. Nous ne présentons que des généralités sur ces différents types de techniques

d’ordonnancement.

II.1.1.2.1 Ordonnancement des tâches apériodiques à contraintes relatives.

Ici, on se fixe le but de minimiser le temps de réponse des tâches apériodiques. Pour ce

faire, on a deux techniques :

Le serveur des tâches ;

L’ordonnancement conjoint.

Le serveur des tâches : Avec cette technique, les tâches périodiques sont ordonnancées avec

l’algorithme RM. On crée une tâche périodique de plus haute priorité, en général. Elle va se

charger d’ordonnancer les tâches apériodiques. Elle est connue sous le nom de serveur de tâches.

On peut rencontrer beaucoup de sortes de serveur des tâches comme serveur à scrutation, serveur

ajournable, serveur sporadique…

L’ordonnancement conjoint : Avec cette technique, les tâches périodiques sont ordonnancées

avec l’algorithme ED. Avec cette technique, on transforme les tâches apériodiques à contraintes

relatives en tâches apériodiques à contraintes strictes à l’aide d’un ajout d’une échéance fictive à

leurs paramètres temporels. On entend par échéance fictive l’échéance minimale que l’on doit

associer à la tâche pour qu’elle s’exécute avec un temps de réponse minimal.

27

II.1.1.2.2 Ordonnancement des tâches apériodiques à contraintes strictes

Il y a deux principales techniques d’ordonnancement des tâches apériodiques à

contraintes strictes :

La Pseudo-période : Avec cette technique, on assimile les tâches apériodiques à des

tâches périodiques en les attribuant un pseudo-période suivant la fréquence de leurs

arrivées. Et on travaille ensuite avec les algorithmes RM et ED qu’on a vues auparavant.

La routine de garantie : Ici, on teste si la nouvelle requête apériodique peut être placée

dans le temps creux d’une configuration périodique ordonnancée selon l’algorithme ED en

tenant compte des contraintes temporelles des tâches périodiques et apériodiques.

II.1.2 Les principes des algorithmes non-préemptifs

Les études sur ce type d’algorithmes sont très rares. Nous allons mentionner les quelques

principes que doive avoir un algorithme non préemptif.

Le principe d’un algorithme non préemptif est le même que celui rencontré lors de la

description des différents algorithmes préemptif, sauf qu’ici il faut tenir compte de la nature des

processus qui ne peuvent pas être interrompus ou préemptés, et c’est la grande différence qu’il y a

entre ces deux algorithmes.

Il est donc très important de vérifier dans quelles conditions toutes les tâches plus

prioritaires pourront satisfaire leurs échéances. Pour cela on doit définir un intervalle critique

associé (une durée d’utilisation maximale de la ressource) à la tâche ζi durant lequel l’évaluation

de l’utilisation minimale demandée à la ressource est faite.

II.1.2.1 RM (Rate Monotonic) non préemptif

En utilisant les résultats de l'étude sur le partage de ressources avec les algorithmes

préemptifs, et en particulier, sur les techniques à priorité héritée, on peut définir une condition

suffisante d'ordonnançabilité pour un algorithme RM non-préemptif. On peut donc formuler le test

d’ordonnancement de l’algorithme RM comme suit :

)1()/()/( 2/1 −≤+= ∑ i

nnPiBiPiCiU ( II-7)

avec { }Cj

njiiB ≤≤+=

1max

(II-8)

28

Bi = durée maximale du blocage d'un travail de la tâche ζi par un travail d'une tâche de priorité inférieure.

Exemple d’utilisation de l’algorithme RM non-préemptif : Soit un ensemble de tâches ζ= {ζ1, ζ2, ζ3}

avec (Ci, Pi)= { (2,8), (2,10), (5,20)}. Le test d’ordonnançabilité étant vérifié, alors voici la séquence

d’ordonnancement de ces messages :

ζ1

t

ζ2 t

ζ3 5 1O 15 20 25 30 t

Figure 11 : séquence temporelle des tâches (RM Non préemptif)

29

II.2 Ordonnancement en présence de partage de ressources

Des applications s’exécutant de manière concurrente et partageant des ressources peuvent dans certaines circonstances avoir

besoin d’accéder de manière exclusive à une ou plusieurs de ces ressources appelées ressources critiques.

Dans le cas d’ordonnancement préemptif, ce partage de ressource en mutuelle exclusion

ne crée aucun problème. Par contre avec l’ordonnancement préemptif que celui-ci provoque deux

principaux phénomènes pouvant nuire au bon fonctionnement d’un système temps réel :

Phénomène d’inter blocage,

Phénomène d’inversion de priorité.

Phénomène d’inter blocage : Généralement, ce phénomène se traduit par le conflit entre deux ou

plusieurs tâches qui se voient obligées d’attendre l’accès à une ressource possédée par une autre

tâche. Pour remédier à ce problème, on doit créer un sémaphore unique pour protéger les

ressources qui sont utilisées ensemble ; ou bien, utiliser un protocole Priority Ceiling : donner des

priorités d’accès aux ressources dans un ordre prédéterminé.

Phénomène d’inversion de priorité : Ce phénomène fait s’exécuter des processus de moindre

priorité avant le processus plus prioritaire. L’exécution d’une tâche plus prioritaire est alors

retardée par une tâche mois prioritaire occupant la ressource ce qui va entraîner le non-respect des

diverses contraintes, notamment les contraintes temporelles. Une gestion dynamique, connue sous

le nom protocole à héritage de priorité, de la tâche possédant la ressource critique peut résoudre ce

problème, tout comme les protocoles à priorité de plafond et pile de priorité.

II.2.1 Protocole à héritage de priorité

C’est un protocole inventé par Kaiser en 1982 et a été revu par Sha en 1980. Lorsque

d’autres processus attendent l’accès à la ressource critique occupée en exclusion mutuelle par un

processus et bloquant l’exécution des processus plus prioritaires, ce protocole a pour principe de

faire hériter la priorité maximale des processus demandeurs au processus occupant la ressource. Et

quand il rend la ressource il reprend sa priorité initiale. Il faut tout de même remarquer que ce

protocole ne prévient pas les inter-blocages.

30

II.2.2 Protocole à priorité plafond

C’est un protocole publié par Chen et Sha en 1990. On attribue à chaque

ressource(sémaphores) une priorité plafond, c’est à dire une priorité maximale des priorités des

processus susceptibles d’y accéder.

Un processus ne peut accéder à une ressource et préempter le processus qui l’occupe que

si sa priorité est supérieure aux valeurs des priorités plafonds des ressources actuellement prises.

Avec ce protocole, le processus qui occupe la ressource hérite aussi la priorité du

processus plus prioritaire et qui veut accéder à cette ressource. Et c’est un protocole qui prévient

les inter-blocages.

31

CHAPITRE III: LES PROTOCOLES D’ACCES MAC TEMPS REEL

III.1 Généralités sur les protocoles MAC temps réel [12]-[20]-[30]-[31]-[32]-[39]

Les protocoles Mac ont été créés pour résoudre le problème de conflits d’accès au média

de communication. C’est la sous couche MAC (Medium Access Control), sous-couche interne à la

couche liaison de données du modèle OSI, qui regroupe ces différents protocoles.

III.1.1 Classification des protocoles MAC

Les protocoles qui se chargent du partage d’accès au canal de communication peuvent

être classés sous deux classes suivant la mise en œuvre le l’ordonnancement :

Protocole de classe 1 : Les protocoles de classe 1 qui sont basés sur l’assignation de priorités aux

flux de messages (donc aux contraintes temps réel)

Protocole de classe 2 : Les protocoles de classe 2 qui, eux, sont basés sur une garantie d’un temps

d’accès borné aux stations.

III.1.2 Principe général des protocoles basés sur l’assignation des priorités aux flux de

messages (protocoles de la classe 1)

Tous les protocoles qui figurent sur cette classe traitent les contraintes temps réel des flux

de messages pour mettre en œuvre l’ordonnancement où l’on met l’accent sur l’arbitrage d’accès

et le contrôle de la durée de transmission sans quoi un ordonnancement n’aurait pas de sens.

L’arbitrage d’accès : Pour les protocoles de classe 1, l’arbitrage d’accès consiste en une

assignation de priorités à chaque flux de message ou à chaque message individuel. Ensuite, on fait

recours à un mécanisme global d’arbitrage de priorités qui décide quel flux de message ou quel

message peut accéder au média de communication suivant leur priorité. Ce mécanisme peut être

fait en ligne ou hors ligne.

32

Le contrôle de la durée de transmission : C’est un mécanisme très simple. Vus, la similitude entre

l’opération d’arbitrage d’accès dans les protocoles de classe 1 et l’ordonnancement de tâches dans

un système monoprocesseur, ainsi que le grand nombre de travaux faits sur l’ordonnancement

monoprocesseur temps réel, des approchements, même des adaptations des algorithmes classiques

d’ordonnancement temps réel des messages dans les réseaux de communication ont été faits. Par

exemple dans le cas d’arbitrage d’accès en linge l’accès et la mise en œuvre effective du transfert

sont effectués simultanément. Tandis que dans le cas d’arbitrage hors ligne, on doit tenir compte

des priorités de chaque flux de message ou de chaque message individuel pour en déterminer par

la suite la séquence de flux de message à transférer. Et on entame la mise en œuvre effective de

ces derniers.

III.1.3 Principe général des protocoles basés sur une garantie de temps d’accès borné aux

stations (protocoles de la classe 2)

Contrairement à ce qui a été vu précédemment, les protocoles de la classe 2 traitent les

stations. Leur but c’est de bien attribuer l’accès au média de communication aux différentes

stations du système.

L’arbitrage d’accès :

Chaque protocole doit tout simplement tenir comptes des différentes contraintes qui sont

rattachées à chaque station et permettre à chacune d’entre elles d’accéder au média de

communication équitablement.

Le contrôle de la durée de transmission :

Pour contrôler la durée de transmission, les protocoles de classe 2 ont fait recours à la

technique d’allocation de bande passante permettant le respect des différentes contraintes de flux

de messages venant de chaque station. En effet, chaque station dispose d’un temps de transmission

pour transmettre ses flux de messages venant des niveaux supérieurs.

Pour ce faire, un mécanisme de gestion global est nécessaire pour gérer le temps

d’utilisation du réseau et les attribuer aux différentes stations du système, tous ayant des

contraintes temps réel différentes. Ce mécanisme travaille étroitement avec un mécanisme de

gestion local qui s’occupe de l’évaluation des contraintes de chaque station qu’il communiquera

avec la gestion globale. C’est toujours ce mécanisme qui gère la répartition de la bande.

33

III.2 Les protocoles de classe 1 [14]-[17]-[27]-[31]-[36]-[39]

III.2.1 Protocole à accès aléatoire : Le protocole CAN (Controller Area Network)

III.2.1.1 Généralités

Le protocole CAN s’applique au bus CAN qui est un réseau local né du besoin de trouver

une solution de communication série dans les véhicules automobiles ayant tendance à intégrer de

plus en plus de commandes électroniques. C’est un protocole qui a été développé par Bosch vers

le milieu des années 80 et qui a fait l’objet d’une normalisation Iso 11898.

Vcc Vcc

100nF 100nF

CAN H

Résistance de terminaison de bus :

r CAN L

Figure III.1 : Un système CAN

III.2.1.2 Principe de fonctionnement

Chaque information est véhiculée sur le bus à l’aide d’un message (trame de bits) de

format défini mais de longueur variable (et limitée). Au moment où le bus est libre, seule la trame,

à qui on a assigné une prioritaire plus élevée que les autres, arrive à transmettre ses données et les

microcontrôleur microcontrôleur

Contrôleur CAN

TX0 TX1 RX0 RX1

Contrôleur CAN

TX0 TX1 RX0 RX1

TXD RxD Réf

Emetteur Récepteur

can L can H

TxD RxD Réf

Emetteur récepteur can L can H

34

autres se mettent en état de réception (lisent les trames émises sur le bus) et tentent un nouvel essai

d’émission de trames quelques temps après. Toutes les stations (ou nœuds) sont co-responsables,

non seulement, de l’accès au bus, mais aussi du traitement des erreurs et de la surveillance des

défaillances car grâce à des mécanismes de contrôle, tous les nœuds connectés au réseau analysent

à tout moment l'intégrité de la trame transitant sur le réseau. En effet, si l'une des stations détecte

la moindre erreur, elle le signale aussitôt à toutes les autres stations. La trame est alors détruite, le

transmetteur arrête aussitôt l'émission et doit alors tenter une nouvelle transmission.

III.2.1.3 Assignation de priorités

L’ordre de priorité des différentes données est déterminé lors de la programmation des

stations du réseau. Pour mieux comprendre le processus d’assignation de priorités des messages

par le protocole CAN, il est nécessaire de savoir ce que c’est un champ d’arbitrage d’un format de

transmission. En fait, il existe deux formats de messages pour le protocole CAN : le format de

transmission standard et le format de transmission étendu.

Figure III.2 : Formats de transmission

35

Format de transmission standard

• 11 bits d‘identification champ d’arbitrage)

• Specification CAN 2.0A (Standard Frame)

• 211 = 2048 messages

Format de transmission étendu

• 29 bits d‘identification (champ d’arbitrage)

• Specification CAN 2.0B (Extended Frame)

• 229 = 536,870912 millions de messages

La seule différence entre un format standard et un format étendu est que le champ

d’arbitrage de ce dernier est constitué d’un identificateur de 29 bits alors que l’autre n’est formé

qu’un identificateur de 11 bits.

En plus des bits identificateurs, le champ d’arbitrage contient aussi un bit RTR (Remote

Transmission Request) qui est dominant pour une trame de données et récessif pour une trame de

requête. C’est au moyen de ce champ d’arbitrage qu’on attribue la priorité à un message CAN lors

de l'analyse conceptuelle du réseau en y affectant des valeurs binaires.

Figure III.3 : Champ de statut du format standard

36

III.2.1.4 Arbitrage de priorités

L’arbitrage de priorités dans le protocole CAN est connu sous le nom d’ «arbitrage bit à

bit ». Toutes les stations qui émettent simultanément sur le bus comparent bit à bit l’identificateur

de leur message avec celui des messages concurrents. La comparaison se base sur le fait que la

valeur 0 écrase la valeur 1. On appelle donc l'"état dominant" l'état logique 0, et l'"état récessif"

l'état logique 1. Si après comparaison, une station émettrice se trouve en état récessif et détecte un

état dominant, elle arrête immédiatement son émission et devient automatiquement un récepteur

de messages et tente à nouveau d’émettre lorsque le bus se libère. Les stations sont câblées sur le

bus par le principe du "OU câblé" (OU= OU logique) comme le montre la figure suivante.

Figure III.4 : Arbitrage de priorités d’un système CAN

Dans cet exemple, trois nœuds transmettent simultanément sur le bus (envoie de

SOF « Start of Frame » ou début de trame marquant le début d’une trame par les trois nœuds). On

utilise ici le format de transmission standard. Chacun des trois nœuds commence par la

transmission du SOF. On ne rencontre pas de problème pour les trois nœuds jusqu’à l’envoie de

cinquième bit de l’identificateur car, à chaque fois, ils envoient la même valeur binaire et détectent

l’état qu’ils ont envoyé sur le bus (grâce au principe de OU câblé) ce qui signifie qu’ils ont encore

le droit de continuer à transmettre. Au sixième bit, le nœud 2 a émis un état récessif (valeur binaire

1) alors que les deux autres ont émis chacun un état dominant. Selon le Ou câblé, le résultat sur le

bus sera un état dominant, alors le nœud 2 ne détectera pas l’état qu’il a envoyé ce qui signifie que

les deux autres nœuds sont plus prioritaires que lui. Il se met donc en mode réception en

« écoutant » le bus et en ne transmettant que des bits récessifs. Les 2 nœuds restant continuent leur

37

transmission. Au huitième bit, le nœud 1 deviendra un récepteur et car il a émis un bit récessif et

ne détectera pas cet état à cause d’un état dominant émis par la station 3 sur le bus. Cela se traduit

par le fait que le nœud 1est moins prioritaire que le nœud 3 et c’est ce dernier qui transmet en

totalité son message.

III.2.2 Protocoles à accès à contrôle centralisé : Le protocole DQDB(« Distributed Queue Dual Bus »)


La norme IEEE 802.6, connue sous le nom de Protocole DQDB (File d'attente distribuée

repartie sur un double bus), a été définie pour le bon fonctionnement des réseaux métropolitains,

c’est à dire l’interconnexion des réseaux locaux sur une étendue de 50 à 150 km avec un débit

allant de 45Mbits/s jusqu’à 600Mbits/s.

La topologie générale d’un réseau DQDB repose sur deux bus parallèles unidirectionnels

et de sens opposés, notés A et B. Chaque station est raccordée parallèlement à chacun des bus et à

chaque extrémité des bus se trouvent deux générateurs de slots ou hobes, appelés respectivement

HOB(A) et HOB(B). Ces derniers génèrent des slots ( ou trames) assurant la transmission des

informations sur le réseau. Pour pouvoir contrôler l’accès au bus, deux mécanismes sont définis :

« Queue Arbitrated » (QA) pour le trafic asynchrone (données) ;

« Pre-Arbitrated » (PA) pour le trafic isochrone (voix, vidéo).

Il y a donc deux types de slots : slots QA et slots PA. Ces slots se déplacent sur chaque

bus en sens opposé, à partir de la tête de réseau. Lorsqu’ils atteignent l’extrémité du bus, ces slots

disparaissent.

38

FigureIII.5 : Schéma d’un réseau DQDB


Chaque Hobe génère, toutes les 125µs, une séquence (ou trame) de slots (cellules de 53

octets)dont le nombre dépend du débit du réseau. Pour transmettre ses données, une station doit

connaître l’emplacement de son destinataire. S’il se trouve à droite, alors la station envoie ses

données sur le bus A, et dans le cas contraire, elle l’envoie sur le bus B. Chaque station qui a des

données à émettre les dépose dans un slot vide de manière statistique (données asynchrones) ou

pré-affectée (pré-arbitrage pour les données isochrone). Dans le cas de broadcast, les données sont

émises sur les deux bus.


A un message est assigné une priorité inversement proportionnelle à sa période. Ceci a dû grâce à

l’utilisation de l’algorithme RM dans l’ordonnancement des messages, en général, dans les

réseaux DQDB.

39

III.2.2.4 Arbitrage d’accès

Transfert isochrone : Bien que L’allocation des cellules soit gérée par la tête de bus, cette

technique n’est pas compatible avec les exigences temps réel car les stations se placent dans une

file d’attente dans l’ordre d’arrivée quand elles ont des infos à transmettre. Les priorités sont

données aux stations qui sont en aval. Cette technique se base, donc, sur la politique du « premier

venu, premier servi » ou FIFO (First In First Out) ce qui favorisera l’inversion de priorités

entraînant le non-respect des contraintes temps réel. Cette technique est connue aussi sous le nom

de mécanisme QA.

Transfert asynchrone :

En mode connecté, la génération des séquences de slots est assurée par les en-têtes fonctionnant

sur l’algorithme RM. On assigne les priorités aux messages suivant leur période. Le message dont

la période d’exécution est la plus petite sera le message le plus prioritaire, c’est à lui donc qu’est

destiné le premier slot dans la séquence générée par le Hobe. Le message dont la période

d’exécution est la plus grande sera considéré comme le message le mois prioritaire. L’en-tête

génère, suivant les règles de l’algorithme RM, des séquences de slots en réponses des requêtes de

réservation de slots des stations qui veulent émettre. Les stations ne font, après, qu’insérer leurs

données dans les slots qui leur ont été alloués. Des ajouts et des retraits de slots peuvent avoir lieu

en cours de route avec cette technique pour satisfaire les requêtes de réservation des stations

émettrices.

En mode non connecté, les bits du VCI (Virtual Circuit Identifier) sont tous positionnés à 1. Une

station désirant émettre fait une requête de réservation sur le bus allant dans la direction opposée à

la station cible. Pour situer la station cible, elle lui adresse un message sur les deux bus, et en

fonction du bus d’où arrive la réponse, elle sait de quel côté elle est. Si une station fait une requête

sur le bus B pour obtenir N slots sur le bus A, la station suivante (et donc celle qui la précède dans

l’autre sens) laisse passer N slots vide sur le bus A avant de déposer ses données dans le slot vide

N+1.

40

Figure III.6 : Format de la cellule (ou slot) DQDB

Figure III.7: DM PDU

III.2.3 Protocoles à accès à contrôle distribué : L’IEEE 802.5


Connu aussi sous le nom de Token Ring, l’IEEE 802.5 est un protocole qui a été

développé par IBM, pour les réseaux de type anneau, vers la fin 1970 avant d’être normalisé par

IEEE en 1984. Les règles de connexion et de contrôle d'accès à un support sont régis selon la

méthode de l'anneau à jeton, aussi connu sous le nom de Token Ring (l’anneau =RING,

jeton=TOKEN). Il s'agit d'un réseau en anneau logique qui transmet à 4Mb/s ou 16 Mb/s et où le

droit d’émettre est déterminé par la circulation d’un jeton sur le câble. La topologie physique

adoptée dans ce protocole est la topologie en étoile autour d’un MSAU( Multistation Access unit).

41

Figure III.8 : Topologie Token ring


Le principe se base sur la circulation en permanence d’une séquence binaire particulière

appelée Jeton sur l’anneau. Si une station veut émettre, elle saisit le jeton, y insère ces données ce

qui changera le jeton en trame et l’envois sur l’anneau afin que les informations parviennent à sa

destination. Du côté du récepteur, lorsque celui ci reconnaît que les informations lui sont

adressées, Cette dernière lit la trame émise et marque avant de remettre la trame sur le réseau pour

signaler l’émetteur qu’il a reçu les données. En effet, l’émetteur reçoit la trame qu’il a émise et

vérifie si elle a été reçue par le récepteur, le cas échéant, elle libère le jeton et le passe à la station

suivante, si non elle re-émet la trame. Avec cette technique, une seule station peut émettre sur le

réseau et ce durant un temps déterminé appelé « temps de maintient du jeton » (THT : Token

Holding Timer) dont la valeur est paramétrable. Par défaut elle est de 10 ms. Pendant ce temps la

station doit émettre une grande trame, plusieurs trames ou relâcher le jeton si elle n’a plus rien à

émettre.

42

Le jeton peut se perdre à cause d’une perturbation électrique ou de la panne d’une station,

tourner indéfiniment ou être dupliqué… Il est donc important de le surveiller et gérer les

problèmes susceptibles de se produire ; ces tâches reviennent à une station appartenant au réseau,

appelé Moniteur. Le moniteur vérifie notamment que la structure du jeton est correcte et qu’une

trame orpheline ne circule pas sur l’anneau. Lorsqu’une situation anormale est constatée, le

moniteur purge l’anneau et y injecte un nouveau jeton.

Méthode pour surveiller la présence du jeton : le moniteur réinitialise un timer à chaque

passage du jeton, si le timer arrive au bout avant que le moniteur ne voie passer le jeton, il émet

une trame de purge (PRG) qui fait le tour de l’anneau. Ensuite, il émet un jeton neuf.

Méthode pour surveiller une trame qui boucle : lorsqu’une trame passe devant le moniteur, il

met le bit moniteur de l’octet contrôle d’accès de la trame à 1. Ainsi si le moniteur voit arriver une

trame avec ce bit M à 1 c’est que la trame a déjà fait plus d’un tour. Le moniteur la supprime donc

comme s’il en était l’émetteur et émet un jeton vide.

Choix du moniteur : Chaque station du réseau peut jouer le rôle du moniteur. Il va falloir donc

élire le seul moniteur qui gérera la communication sur le réseau parmi les stations susceptibles de

jouer le rôle du moniteur. Des techniques d’élection ont été mises en place :

La première connectée au réseau se déclare moniteur ;

Protocole de détection de l’absence du moniteur : le moniteur en fonction émet régulièrement

une trame AMP (Active Monitor Present). Chaque station possède un timer qu’elle réinitialise

au passage de la trame AMP. Si le moniteur cesse d’émettre cette trame, les timers vont arriver

au bout. La première station dont le timer arrive à terme lance le protocole d’élection d’un

nouveau moniteur. Il reste néanmoins un risque : si le moniteur émet une trame AMP et

meurt. La trame AMP va tourner en boucle, personne ne s’apercevra qu’il n’y plus de

moniteur. De plus, étant donné que la trame AMP possède le jeton, plus personne ne parlera.

Pour régler ce problème le moniteur attend un temps minimum entre deux émissions d’AMP et

chaque station possède un deuxième timer réinitialisé au passage d’un AMP. Si la trame AMP

arrive avant que ce timer n’arrive à terme dans une station, cette dernière détruit la trame AMP

et lance la procédure d’élection d’un nouveau moniteur.

43

Protocole d’élection d’un nouveau moniteur : pour l’élection d’un nouveau moniteur on va

choisir la station ayant l’adresse la plus grande. La première station qui détecte l’absence de

moniteur actif, c’est à dire dont le premier timer arrive à terme avant le passage de la trame AMP

ou dont le deuxième timer n’est pas arrivé à terme au passage de cette même trame, lance une

trame particulière appelée Claim Token qui contient son adresse. Lorsqu’une station reçoit un

claim Token elle en émet un autre avec comme adresse la plus grande entre celle reçue et la

sienne. Cette procédure au bout du compte arrive au fait que la station ayant l’adresse la plus

grande reçoit un claim Token avec sa propre adresse. A ce moment elle se déclare moniteur.

Seulement, à cet instant, elle est seule à savoir qu’elle est moniteur, elle émet alors une trame qui

signale qu’elle a prit le rôle de moniteur Bien sûr, si la présence d’un moniteur est indispensable,

il ne faut absolument pas qu’il y en ait plusieurs. Cela provoquerait un retrait de trame non justifié.

Par exemple le premier moniteur, en voyant passer la trame mettrait le bit M à 1, le second croirait

que la trame vient de boucler et la supprimerait Pour éviter cela, le moniteur va surveiller les

trames AMP, s’il lui en arrive une qu’il n’a pas émis, c’est qu’il y a un autre moniteur. Il lance

alors la procédure d’élection d’un nouveau moniteur.

Figure III.9 : Jeton et trame de l’IEEE 802.5

44


La norme IEEE 802.5 décrit huit niveaux de priorités pour les messages. Une assignation

de priorités portant sur les flux de messages doit être adoptée pour assurer un ordonnancement

efficace des messages. La priorité 0 est assignée aux trames courantes, et la priorité de niveau 7

est réservée pour les trames exceptionnelles et urgentes. Les six autres niveaux de priorités sont

attribués aux autres trames selon le principe de l’ordonnancement RM.

III.2.3.4 Arbitrage de priorités

L'octet de contrôle d'accès contient 3 bits de priorité indiquant le niveau de priorité

courant (8 niveaux possibles) et 3 bits de réservation de priorité indiquant le niveau de priorité

requis par une station désirant émettre. Lorsqu'une station veut émettre une trame dont le niveau

de priorité est « n », elle doit attendre le passage d'un jeton dont les trois bits affectés au niveau de

priorité courant expriment un niveau de priorité inférieur à « n ». De plus, une station voulant

transmettre une trame peut effectuer une réservation en inscrivant le niveau de priorité de sa trame

dans la zone réservation. Par contre, si une réservation de rang supérieur au sien a déjà été

formulée, elle ne peut exprimer la sienne.

45

Algorithme d’arbitrage de priorités du protocole IEEE 802.5

Dans chaque station, à l’arrivée du jeton, effectuer :

Tant qu’il y a des messages en attente :

Si P(jeton) ≤ P(message) et S(jeton) = « libre » :

P(dernier_jeton) ← P(jeton)

S(jeton) ← « occupé » ;

Tant que P(message)≥P(réservation) :

P(jeton) ← P(message) ;

Envoi message ;

Re-évaluer P(message) ;

P(jeton) ← max { P(dernier_jeton), P(réservation)} ;

S(jeton) ← « libre » ;

Sinon P(jeton)>P(message) ou S(jeton) = « occupé » :

Si P(message) > P(réservation) :

P(réservation) ← P(message) ;

46

III.3 Les protocoles de classe 2 [24]-[33]-[39]

III.3.1 Le protocole à accès aléatoire : le protocole IEEE 802.3


Le protocole 802.3, ayant comme origine le système ALOHA et amélioré par la société

Xerox en y ajoutant la fonction « écoute par porteuse », définit des normes pour les réseaux locaux

en bus logique (ligne droite) notamment Ethernet, qui utilise la méthode d'accès CSMA/CD. En

effet, il régule le trafic en n'autorisant un message de diffusion générale que si le câble est libre et

si aucun autre ordinateur n'est en train d'émettre de message.

Figure III.10 : Schéma d’un réseau Ethernet


Toutes les stations raccordées au bus sont à l’écoute des trames qui circulent sur le bus.

Avant d’émettre ses données, une station doit attendre que le bus soit libre. Mais plusieurs stations

peuvent émettre simultanément au moment où le bus est libre, ce qui créera un phénomène de

collisions et entraînera la destruction des trames en transmission. Selon un algorithme bien défini,

après détection de collision, les stations arrêtent de transmettre et laissent passer un temps

aléatoire avant de re-émettre à nouveau.

47

Les données sont transmises sous forme de "trames": L'information est décomposée en

petits morceaux et sera acheminée sous cette forme. Ces trames, en plus de contenir l'information

à transporter contiennent des indications relatives au transport (adresse de source et de

destination...) et au contrôle, voir à la correction, des données transmises. La structure d'une trame

802.3 est la suivante

Figure III.11: Structure d’une trame 802.3


Après détection d’une collision sur le bus, chaque station attend un temps aléatoire, qu’on

appellera époque, avant de transmettre à nouveau ses trames. Ce temps est choisi selon les

contraintes des flux de messages de chaque station, et des stations elles même.

En effet, une station qui a un flux de messages plus prioritaire que les autres mettra

beaucoup moins de temps pour re-émettre ses trames après collision. On parle là d’une assignation

de priorités aux flux de messages. Mais dans le cas d’une collision, la décision finale sur le choix

de l’époque repose sur la priorité assignée aux différentes stations.

La résolution de l’époque peut se voir alors comme une opération à deux niveaux : Tout

d’abord ou résout l’époque sur la base de la priorités des messages et si une collision subsiste, on

résout la contention sur la base des adresses des stations.

48


Oui

Non

Non

Non Oui

Oui

Non

Oui

Figure III.12 : Algorithme d’arbitrage d’accès dans un réseau Ethernet

Données à transmettre

Créer la trame

Transmission en cours

brouillage

Comptabiliser les tentatives

Trop de tentatives

Calculer l’attente

attendre

Abandon : trop de tentatives

Transmission finie ?

Transmission réussie

Commencer la transmission

Collision détectée ?

49

III.3.2 Protocoles à contrôle distribué : Le protocole « Jeton temporisé » : FDDI ( Fiber Distribued Data Interface)


Le protocole FDDI s’applique aux réseaux locaux FDDI qui sont des réseaux locaux, en

double anneau, fondés sur une infrastructure fibre optique multimode.. Il peut s’étendre sur 100

km et accepter jusqu’à 1000 stations. La technique FDDI est d’origine ANSI (X3T9.5), puis a été

normalisée par l’ISO (9314). De part son débit élevé, les réseaux FDDI sont souvent utilisés

comme des réseaux fédérateurs de réseaux LAN à plus faible débit. Pour l’arbitrage d’accès au

médium la technique utilisée est l’utilisation d’un « jeton temporisé », cela signifie que le temps

de rotation de celui-ci est contrôlé, et assure donc une qualité de service au moins du point de vue

du débit pour les deux types de trafic indépendamment des autres stations. Ses trames maximales

sont de 45 ko. Les stations peuvent être à simple ou à double attachement selon qu’elles sont

directement reliées à l’anneau principal ou non. Le double anneau autorise, en cas de défaillance

d’un nœud FDDI, le re-bouclage sur l’anneau secondaire. Pour les stations à simple attachement,

c’est le concentrateur qui assure cette fonction.

Figure III.13 : Schéma d’un réseau FDDI

50


Dans les réseaux FDDI il existe deux types de trame : les trames asynchrones (trames de

données classiques : Trames non temps réel) et les trames synchrones (trames spéciales

contraintes temporairement : Trames temps réel). Pour pouvoir transmettre ces trames une station

doit posséder le jeton. Etant donné leur taille importante, le délai de propagation peut atteindre

1ms. Pour économiser la bande passante la station ne doit pas à attendre le retour de la trame

qu’elle a émise avant de re-émettre le jeton sur le réseau, ce serait une perte inutile de temps et de

bande passante. En effet, une fois la trame émise, la station envoie directement le jeton à la station

suivante pour qu’elle puisse envoyer aussi ses trames à son tour. Avant d’être retirées du réseau

par les stations émettrices, les trames lues par les destinataires leurs sont retournées afin de vérifier

si elles ont été bien reçues ou non. Plusieurs trames peuvent donc circuler simultanément sur le

média mais un seul jeton. Dans le cas où les trames n’auraient pas été lues, la station émettrice

attendra le passage d’un jeton libre pour les re-émettre. Il n’y a pas de station monitrice pour gérer

le jeton dans les réseaux FDDI, chaque station génère le jeton après avoir émis ses trames durant

une durée déterminée.

51

Figure III.14: Format d’une trame FDDI

Le protocole FDDI utilise trois compteurs pour gérer la communication et l’accès au

média :

• Le compteur TTRT (Target Token Rotation Timer) qui indique la borne temporelle

d'accès garantie. A l’initialisation de l’anneau, chaque station propose une valeur

maximale admissible de TTRT et la plus faible valeur proposée est retenue, elle

correspond à la station qui a les plus fortes contraintes de trafic. Cette valeur est

négociée lors de l'ouverture entre 4 ms et 167 ms ;

• Le compteur TRT (Token Rotation Timer) qui est déclenché par chaque station dès

qu'elle capte le jeton. Le maximum du TRT est égal a TTRT ;

• Le compteur THT (Token Holding Timer) qui donne le temps maximal alloué à la

transmission asynchrone.

Il existe cinq règles essentielles que chaque station respecte, lorsqu'elle reçoit le jeton et

qu'elle désire transmettre des trames:

Le TRT décompte pendant tout le fonctionnement de l'anneau. Lorsqu'il expire ou que

le jeton arrive à temps, il est chaque fois réinitialisé et recommence à décrémenter. Le

THT contrôle la transmission de trafic asynchrone et ne décrémente que pendant la

transmission de trames asynchrones.

Si le jeton arrive à temps alors la valeur courante du TRT est chargée dans le THT et

le TRT est réinitialisé. La station peut transmettre des trames synchrones et

asynchrones. Elle commence par transmettre ses trames synchrones.

La variable LC (Late Counter) autorise (LC = 0) ou interdit (LC = 1) l’émission de

données asynchrone. LC est mis à 0 si le jeton arrive en avance. Si le jeton arrive en

retard, la station réinitialise l’anneau en mettant (LC=0) mais le TRT n’est pas

réinitialisé: on dit que la station accumule son retard. Dans ce cas, seule la

transmission de trames synchrones est permise.

L'intervalle de temps pendant lequel une station donnée peut transmettre des trames

synchrones ne peut dépasser la tranche qui lui a été allouée. Une station peut

transmettre des trames asynchrones jusqu'a expiration de son THT. Si cette expiration

a lieu pendant la transmission d'une trame, la station termine la transmission de cette

trame avant d'émettre le jeton; on parle alors de dépassement asynchrone.

52

Une station n’a pas le droit de transmettre des trames après que TRT a expiré. On

termine cependant la transmission d'une trame en cours, avant d'émettre le jeton.


Dans la technique FDDI, on assigne la forte priorité, et la même, à chaque trame

synchrone des différentes stations. Etant plus prioritaires que les autres trames, les trames

synchrones sont les seules que l’on est sûr de pouvoir transmettre. Donc la notion de priorité ne

s’applique pas vraiment sur les trames synchrones, elle s’applique uniquement sur la transmission

asynchrone. FDDI prévoit 8 niveaux de priorité, le niveau de priorité (de 0 à 7) sera noté i pour les

trames asynchrones. Cette priorité est assignée à ces dernières selon leur nature.


Les trames synchrones, étant plus prioritaires, sont les premières à être envoyées par la

station possédant le jeton. Vient ensuite la transmission des trames asynchrones. Pour le calcul du

droit de transmettre ces dernières, les stations utilisent une fonction Pri qui est inversement

proportionnelle à i.(i étant la valeur de la priorité).La fonction Pri(i) est définie comme ceci :

Pri(0) = 40 ; Pri(1) = 30 ; Pri(2) = 25 ; Pri(3) = 20

Pri(4) = 17.5 ; Pri(5) = 15 ; Pri(6) = 13.75 ; Pri(7) = 12.5

La station émettrice suit l’algorithme qui suit pour ordonner les messages à émettre : Le

droit d’émettre une trame asynchrone n’est pas uniquement d’avoir le THT > 0, il faut que le THT

soit supérieur au résultat de Pri(i) , i étant le niveau de priorité de la trame à émettre. De plus, la

station n’aura pour cette trame que le temps de THT – Pri(i). Il faut donc prévoir si on a le temps

ou pas d’émettre cette trame. Pour cela, les stations calculent le temps d’émission de la trame et

vérifient l’inégalité suivante : THT – Pri(i) ?= Dm avec Dm qui indique le temps de transmission

de la trame.

53

non

oui

non

oui

non

oui

Figure 26 : Algorithme d’ordonnancement des messages à émettre

Voici un exemple montrant le fonctionnement du processus d’accès au média dans une

technique FDDI. Nous allons considérer un réseau comportant 5 stations (A,B,C,D et E) et dont le

TTRT est fixé à 100ms. Afin de simplifier, les durées d’émission d’un jeton et tous les délais

THT-Pri(P1) = ? Dm1

THT-Pri(P2) = ? Dm2

THT-Pri(Pn) = ? Dm

n

Emission de m2

Emission de m1

Emission de mn

54

physiques sont négligés, toutes les trames sont supposées avoir la même longueur et un temps

d’émission de 5ms.

A veut émettre une trame synchrone et 5 asynchrones de priorité 0

B veut émettre une trame synchrone et 1 asynchrone de priorité 1

C veut émettre une trame synchrone et 1 asynchrone de priorité 5

D veut émettre une trame synchrone et 2 asynchrones de priorité 0

E veut émettre une trame synchrone et 4 asynchrones de priorité 0

Voici les TRT et THT de ces deux stations durant les deux premiers tours de jeton. (Au

départ, aucun trafic n’avait été écoulé en synchrone et asynchrone pendant les rotations

précédentes du jeton) :

Tableau III.1: Processus d’émission des trames du protocole FDDI

1) Pour la station A : TRT=100, dès l’arrivée du jeton, elle envoie sa trame synchrone ;

55

2) Les autres stations attendent que la station A ait fini de transmettre pour pouvoir le faire à leur

tour. Leur TRT est égale à 100 ;

3) Le TRT de la station A devient 95 après l’émission de la trame synchrone (qui dure 5 ms).

Comme le jeton est arrivé à temps, la valeur de TRT est chargée dans THT et TRT est ré-

initialisé à 100. Ensuite la station A utilise l’algorithme vu précédemment pour désigner lequel

des messages asynchrones sera envoyé. Mais ici, les messages asynchrones ont même priorité

donc on envoie un à un les messages ;

4) Le TRT est maintenant à 90ms après l’envoie du premier message asynchrone. On procède

ainsi tant que l’algorithme permet l’envoie des messages. Pour la station A toutes les trames

ont pu être toutes envoyées. A la fin de l’émission de ces 6 trames, TRT a atteint la valeur 70.

La station A envois le jeton à la station B ;

5) La valeur 70 est maintenant chargée dans le THT de la station B, car le jeton est arrivé à

temps. Elle envoi sa trame synchrone en premier ;

6) TRT est maintenant égale à 95, et l’émission de la trame asynchrone est permise car THT-

Pr(1) (70-30=40)est largement supérieure au temps de transmission d’une trame. Toutes les

trames de la station B ont pu être envoyées dès le premier passage du jeton ;

7) On procède toujours de la sorte pour envoyer les trames des différentes stations du réseau.

Pour les stations C et D leurs trames ont pu être envoyées dès le premier tour du jeton ;

8) Nous tenons quand même à faire une remarque sur l’envoie des trames de la station E lors du

premier passage du jeton. A ce stade, TRT est égale à 35, le jeton arrive à temps donc TRT est

réinitialisé à 100 tandis que l’ancienne valeur de TRT=35 est chargée dans THT. Cette station

peut envoyer sa trame synchrone mais ne peut plus envoyer ces trames asynchrones faute de

temps. La station E doit donc attendre de deuxième tour du jeton pour re-envoyer les 4 trames

asynchrones restantes.

56


9) Les tableaux qui suivent montrent maintenant le deuxième tour du jeton. La station peut

émettre une trame synchrone mais ne peut plus émettre aucun trame asynchrone selon le calcul

fait par l’algorithme d’ordonnancement des messages ;

10) La station B peut émettre une trame synchrone et une trame asynchrone ;

11) La station, elle aussi, peut encore envoyer une trame synchrone et une trame asynchrone car

l’algorithme le permet.

57


12) Quant à la station D, elle a le droit d’émettre, en possession du jeton, une trame synchrone et

deux asynchrones ;

13) C’est au tour de la station E maintenant d’envoyer les trames qui n’ont pas pu être transmises

lors du premier passage du jeton sur le réseau. Avant ceci, elle a d’abord le doit d’envoyer une

trame synchrone. Mais on constate que parmi les quatre trames asynchrones une ne peut pas

être transmise faute de temps. Il faudra attendre alors le troisième tour du jeton pour

l’envoyer ;

58


59

CHAPITRE IV : LA NORME IEC-65C

[40]-[32]-[31]

IV.1 Généralités sur l’IEC-65CIV.1.1 Problématique de l’ordonnancement du trafic temps réel

Dans le contexte le plus général des réseaux locaux temps réel, on a presque toujours trois

types de trafics à véhiculer ( les deux trafics temps réels périodiques et apériodiques, ainsi que le

trafic apériodique non temps réel). De ce fait, définir un mécanisme d’ordonnancement

(ordonnancement conjoint) permettant la transmission efficace de ces trois types de trafics sur le

réseau s’avère être très nécessaire. C’est une chose très utile mais pas facile à réaliser à cause de la

diversité de leurs caractéristiques ( ne serait ce que sur le choix de la nature de l’ordonnancement

à utiliser : en ligne ou hors ligne).

L’ordonnancement doit être non préemptif car on travaille avec des messages et non pas

de tâches. Par conséquent, on doit définir une durée d’utilisation maximale du réseau pour un

transfert afin de minimiser le phénomène d’inversion de priorités.

IV.1.2 L’IEC-65C

C’est un mécanisme où le mariage entre les protocoles de classe 1 et de classe 2, c’est à

dire l’ordonnancement conjoint, est possible grâce au contrôleur d’accès appelé LAS (Link Active

Scheduler) où de nombreuses possibilités d’adressage permettent d’offrir l’accès des différents

types de messages (un flux d’une station, un groupe de flux ou la station globale) au média. Le

principe c’est d’utiliser différentes jetons ou séquences temporelles (au nombre de trois pour les

trois types de trafics).

Le LAS doit posséder les informations concernant les besoins des différentes stations

dont il doit gérer l’accès au média afin d’établir l’ordonnancement. Certains besoins (besoins

périodiques) sont définis à la configuration, après quoi la séquence temporelle peut être connue

par le LAS ce qui permet à celui ci de faire un ordonnancement le mieux adapté. Mais il y a aussi

les besoins dits apériodiques qui peuvent être connus dynamiquement par le LAS au moyen de

PDUs qui lui redonnent la main.

Voici les trois types de PDU (Protocol Data unit) permettant au LAS de distribuer trois

types de droit de parole aux différentes stations du réseau :

60

Le PDU CD («Protocol Data unit compel data ») : permet au LAS de reprendre la main en

forçant une station d’envoyer immédiatement l’envoi d’un PDU ;

Le PDU ET («Protocol Data unit Execute transaction ») : permet au LAS d’exécuter une

transaction (séquence de deux PDUs, où l’envoie du deuxième redonne aussitôt la main au

LAS) ;

Le PDU ES (« Protocol Data unit Execute Sequence ») : permet au LAS de donner à une

station un temps de droit de parole (un paramètre ES duration est dans ce PDU). L’envoi par la

station du dernier PDU (c’est un PDU qui a un fanion particulier ou c’est un PDU EE (End of

Execution)) redonne la main au LAS.

Les études sur l’ordonnancement de cette norme sont très rares. Le docteur Francisco

Vasques de Carvalho a fait une proposition remarquable sur ce sujet dont les grands traits seront

présentés dans ce chapitre.

IV.1.3 Les différents trafics dans un réseau local temps réel

Trois types de trafics doivent être supportés dans la sous couche MAC des réseaux temps réel :

Le trafic périodique : possédant des caractéristiques bien définies (période , durée maximale

d’utilisation du réseau, échéance). L’ordonnancement de ce type de trafic, dans cette norme,

peut être centralisé où le LAS donne successivement la parole aux flux des différentes stations

du réseau. Pour satisfaire les échéances de ce flux, un algorithme d’ordonnancement en ligne

est le mieux adapté : algorithmes RM.

Le trafic apériodique temps réel possédant des caractéristiques connues( intervalle minimum

entre deux arrivées consécutives, durée maximale d’utilisation du réseau, échéance) et

inconnues (instants d’arrivée des messages). L’ordonnancement de ce type de trafic se base,

soit sur une connaissance globale des arrivées des messages et dans ce cas il est planté de

distribué (comme le CAN ou l’IEEE 802.5), soit un ordonnancement à deux niveaux : un

niveau d’ordonnancement local des messages dans les stations et un niveau

d’ordonnancement global des stations pour l’accès au média de transmission ( comme les

protocoles basés sur le jeton temporisé).

Le trafic apériodique non temps réel qui n’a pas de caractéristiques connues. Le LAS utilise le

temps laissé disponible par les ordonnancements des autres types de trafic pour ordonnancer

au mieux ce type de trafic.

61

Aussi, nous allons choisir l’algorithme d’ordonnancement en ligne RM pour les trafics

périodiques. Un ordonnancement basé sur le concept du jeton temporisé sera opté pour les trafics

apériodiques temps réel. Le LAS déploiera une politique du « meilleur effort » pour les trafics

apériodiques.

Hypothèses : Considérons m stations où se trouvent différents flux de messages à ordonnancer.

Leur répartition est la suivante :

- p flux de messages périodiques (Mp1, Mp2,…,Mpp), à échéance sur requête. On appelle

respectivement Pi, Ci la période et la durée d’utilisation du réseau par un message de flux Mpi ;

- s flux de messages apériodiques temps réel (Ma1, Ma2,…,Mas), à échéance sur requête. On

appelle respectivement Pj, Cj l’intervalle minimal entre deux arrivées successives et la durée

d’utilisation du réseau par un message du flux Maj. ;

- On suppose de plus que l’on a un flux de messages non temps réel (Mn) par station ; on appelle

Cn la durée d’utilisation maximale du réseau par un message du flux Mn.

IV.2 Principe de fonctionnement

Trois types de jetons (séquence temporelle) seront générés par la LAS pour offrir une

transmission efficace, respectant les échéances des différents trafics.

Tout d’abord, il y a le jeton EP (« Execute Périodique) qui déclenchera le transfert des

trafics périodiques en provenance des flux périodiques. Il y a aussi, la séquence temporelle

EA(« Execute Apériodique), qui déclenchera le transfert des trafics apériodiques en provenance

des flux apériodiques. Et enfin, il y a le jeton EN(« Execute Non temps réel) qui est générer par le

LAS pour déclencher le transfert des trafics non temps réel en provenance des flux non temps réel.

Chaque flux de messages périodiques ou apériodiques temps réel reçoit respectivement,

durant sa période Pi, un nombre Ni de jetons EP ou EA. Ni =1 s’il n’y a pas de fragmentation d’un

message ; Ni>1 s’il y a fragmentation d’un message. Dans le cas des messages apériodiques non

temps réel, chaque station reçoit des jetons EN pour servir les flux apériodiques non temps réel.

62

Proposition : on considère une implantation d’un mécanisme d’anneau logique entre les

stations ce qui fait qu’à l’intérieur d’une fenêtre temporelle T, chaque station, constituant le

réseau, dispose d’un temps Hk pour utiliser la ressource de transmission.

IV.2.1 L’ordonnancement du trafic apériodique temps réel

Mécanisme :

Durant chaque fenêtre temporelle T, le LAS envoie à chaque station, , un jeton EA

porteur d’une durée Hk pendant laquelle la station doit pouvoir transmettre le trafic apériodique

temps réel prévu. Si les besoins du trafic n’épuisent pas la durée Hk, la durée restante pourra être

utilisée pour transférer du trafic apériodique non temps réel en attente. La station renvoie le jeton

EA au LAS soit à la fin de la durée Hk soit avant, dés qu’il n’y a plus de trafic apériodique temps

réel en attente( retour anticipé du jeton EA).

Le temps sur une fenêtre temporelle T où le jeton n’est ni en transit entre le LAS et les

stations, ni utilisé par les stations, est un temps dont dispose le LAS pour ordonnancer les autres

trafics (périodiques et apériodiques non temps réel). On appelle ζk la somme de la durée du jeton

EA et du temps de propagation entre le LAS et la station k.

---------- --------

ζ1ζk

ζm

Figure IV.1 : Le mécanisme du jeton EA

Caractérisation de l’anneau logique :

Plusieurs possibilités existent quant à la création et à l’envoie des jetons aux différentes

stations du réseau. Mais on va parler les deux cas extrêmes : En premier lieu, il y a ce que l’on

appelle le cas 1 où il est question de régularité sur l’envoie des jetons aux stations. En deuxième

lieu, on a le cas 2 où l’on met le ton sur l’irrégularité des passages de jetons dû au fait que les

stations peuvent utiliser tout le temps dont elles disposent pour transmettre du trafic apériodique.

LAS

Station 1 Station k Station m

63

CAS 1 : L’envoie des jetons EA a lieu au début de chaque période T ce qui fait que le temps

séparant deux arrivées de jeton au même station k est toujours T. Le temps restant ainsi que le

temps résiduel (dans le cas où il y a retour anticipé du jeton vers le LAS) sont destinés à servir les

trafics périodiques et apériodiques non temps réel.

CAS 2 : L’envoie des jetons est fonction de la sollicitation des autres types de trafic. Le LAS mixe

l’envoie des jetons EA avec d’autres jetons ce qui cause l’irrégularité des passages de jetons EA

sur une même station.

Allocation de la bande passante :

Différentes conditions sont à considérer :

La période de chaque flux doit être supérieure ou égale au temps T de la fenêtre dans le

cas 1 (Pj ≥ T) et à 2T dans le cas 2 (Pj ≥ 2T)

Pour le nombre maximal de passage de jetons dans une station : vj=Pj/T pour le cas 1 et

vj=[(Pj/T) – 1] pour le cas 2. A partir de la valeur du nombre maximal de passage de jetons

qu’on peut avoir la longueur du fragment du flux apériodique temps réel envoyé à chaque

passage du jeton qui est égale à Cj/vj. Nous obtenons finalement la bande passante nécessaire

à la station k, à chaque passage du jeton EA, pour la transmission de ses flux apériodiques

temps réel : Hk=∑(Cj/vj)

IV.2.2 L’ordonnancement du trafic périodique

L’assignation de priorités aux flux de messages est effectuée par l’algorithme non RM

non préemptif (un algorithme qui est basé sur des périodes statiques c’est à dire qu’un flux de

messages a une priorité fixe qui est inversement proportionnel à sa période).

Mp1 Mp2 Mpi Mpp

v2 vi vpv1

LAS

64

Figure IV.2 : L’ordonnancement des flux de messages Mpi

Pour ordonnancer les flux de messages périodiques, le LAS envoie à chaque flux Mpi,

durant sa période, des jetons EP au nombre de vi. A chaque réception de jetons EP, le flux Mpi

envoie un fragment de message de ce flux.

IV.2.3 Ordonnancement des messages non temps réel

Le LAS envoie un jeton EN successivement à chaque station sur le bus, tant qu’il n’y a

pas de jetons EP et EA en attente d’ordonnancement. Il faut aussi préciser que les trafics non

temps réel sont aussi transportés par les jetons EA dans le cas d’un retour anticipé de ce jeton, ou

bien lorsqu’il n’y a plus de trafic apériodique temps réel à transférer.

IV.2.4 L’ordonnancement conjoint

Précédemment, nous avons dit que l’utilisation maximale (D) du réseau est limitée dans

le but de limiter l’inversion de priorités. A cause de cette contrainte de limitation, les tests

d’ordonnancement ainsi que l’acheminement au mieux des trafics non temps réel ne seront

satisfaits qu’en définissant divers échanges sur les différents trafics :

Pour les trafics périodiques :

Si Ci≤D, les messages ne sont pas fragmenter.

Si Ci>D, les messages ont besoin d’être fragmentés en vi fragments d’où P*i=(Pi/vi).

Pour les trafics apériodiques temps réel :

On fait le choix sur l’ordonnancement RM et en accordant la haute priorité au LAS il y

aura des passages des jetons EA au début de chaque période T. Rappelons que T est la durée de la

fenêtre temporelle de l’anneau logique. Le choix de ce temps T est fonction d’un besoin ou d’un

non-besoin de fragmenter les messages des flux périodiques.

- S’il y a fragmentation des messages de flux périodiques, nous choisissons T< Pi .

65

- S’il y a fragmentation des messages de flux périodiques, on choisissons T< P*i avec P*i=( Pi/vi)

- T≤ Pj pour exprimer la contrainte de l’échéance d’un message d’un flux apériodique temps

réel Maj.

- Hk=∑ [Cj/(Pj/T)] ≤ D cette contrainte exprime la contrainte de la durée de l’utilisation

maximale afin de limiter la durée de l’inversion de priorité.

- ∑Hk < (T-τ), cette contrainte exprime à la fois la contrainte d’un protocole du type « jeton

temporisé » et la contrainte pour pouvoir faire du transfert de trafic de flux périodiques Mpi.

Test d’ordonnançabilité conjoint des flux de messages temps réel avec l’algorithme RM pour

l’ordonnancement des flux périodiques :

Nous considérons qu’il y a fragmentation des messages.

)1)(1()/( 2 )1/(1 −+≤++ +∑ n

i

k nTD

TPiCi H (V-1)

∑(Ci/Pi) : exprime les flux périodiques ;

[∑Hk]/T: exprime les flux apériodiques temps réel ;

D/T : exprime l’inversion de priorité.

La variable n indique le nombre des fragments des messages à ordonnancer

66

CHAPITRE V : MODELISATION AU MOYEN DES RESEAUX DE PETRI TEMPORISE

STOCHASTIQUE (RdPTS) DU SYSTEME FONCTIONNANT SOUS LA NORME IEC-65C

V.1 Modélisation d’un système fonctionnant sous la norme IEC-65C[9]-[10]-[25]-[26]-[37]-[38]

V.1.1 Le Réseau de Petri Temporisé stochastique :

Le réseau de Petri temporisé stochastique (RdPTS) est une extension temporelle du

réseau de Petri stochastique. C’est une méthode formelle représentant tous les composants du

procédé physique et doté d’un fort pouvoir d’expression permettant l’expression du

parallélisme,de la synchronisation. Grâce à ces différentes raisons, on l’utilisé pour modéliser un

système dans le but de valider les comportements de celui ci que ce soit sur la sûreté de

fonctionnement ainsi que sur les aspects fonctionnels.

Les réseaux de Petri sont composés de deux types de nœuds :

Les places Pi, représentées par des cercles ;

Les transitions Ti, représentées par des rectangles s’il s’agit d’une transition temporisée (le

temps de tir d’une transition a une durée non nulle) ou d’un trait dans le cas d’une transitions

immédiates (le temps d’une transition a une durée nulle).

Les places et les transitions sont reliées par des arcs. On peut rencontrer des arcs

inhibiteurs qui sont représentés graphiquement sur l’arc par un cercle à l’extrémité proche de la

place. On peut dire alors qu’un réseau de Petri est une succession de places et de transitions

reliées par des arcs. Chaque place contient un nombre entier de jeton. Voici les quelques

règlements d’un réseau de Petri :

• Une transition ne peut être franchie que si toutes les places en amont de cette transition

contiennent au moins un jeton. Une transition dans cette situation est dite franchissable ;

• Une seule transition peut être franchie à la fois ;

• Le franchissement se fait en décrémentant d’un jeton les places situées en amont de la

transition et en incrémentant d’un jeton celles situées en aval.

67

• Dans la présence des arcs inhibiteurs, une transition est franchissable si toutes les places d’où

proviennent des arcs inhibiteurs sont vides et si les autres places en amont contiennent au

moins un jeton ;

• Les places en amont reliées par des arcs inhibiteurs ne sont pas décrémentées d’un jeton.

Des extensions temporelles ont été faites pour permettre de mesures quantitatives et aussi

pour rendre meilleur les mesures de performances. On a rajouté donc un facteur de temps à l’un

des éléments fondamentaux d’un réseau de pétri (places, transitions, jetons, ou arcs)

Le RdPTS est une extension temporelle du RdP. Le temps rajouté est associé aux

transitions sous forme de loi de probabilité de tir. On associe donc à chaque transition ti un

intervalle de tir initial [Өmi,ӨMi] et une densité de probabilité discrète ( impulsion de dirac

f(x)=δ(x-a) )

V.1.2 Modélisation d’un système fonctionnant sous la norme IEC-65C

Il faut rappeler que dans un système fonctionnant sous la norme IEC-65 au niveau de la

sous couche MAC, le ton est mis sur le LAS qui génère les séquences temporelles (jetons) EP, EA

et EN pour la mise en œuvre de l’ordonnancement, sur la génération et l’ordonnancement des

différents trafics temps réel et non temps réel répartis sous la forme de p flux périodiques et de s

flux apériodiques ainsi qu’un flux apériodique non temps réel par station. Par conséquent il est

indispensable d’établir quatre modèles :

Le modèle du LAS : mise en œuvre de l’ordonnancement (génération et envoi des jetons EP,

EA et EN).

Le modèle du service d’un flux de messages périodiques Mpi : génération des messages

périodiques du flux et transfert de ces messages au moyen du jeton EP.

Le modèle du service des flux de messages apériodiques temps réel d’une station k :

génération des messages des différents flux et transfert de ces messages au moyen du jeton

EA.

Le modèle du service du flux de messages non temps réel d’une station k : génération des

messages du flux et transfert de ces messages au moyen EN

Choix : Pour l’ordonnancement du trafic périodique, on choisit l’algorithme RM non préemptif.

Ce qui implique un fonctionnement régulier pour le passage du jeton EA sur le bus.

68

V.1.2.1 Le modèle du LAS

Différentes étapes doivent être respectées dans la modélisation du LAS pour modéliser la

génération des trois jetons ainsi que leur envoi aux différentes stations.

V.1.2.1.1 Génération des jetons EA

a) Etat initial du serveur (une place : P1.serveur) ;

b) Transition représentant le déphasage initial du serveur par rapport à une référence temporelle

globale (une transition, T1.serveur, à qui l’on associe une distribution temporisée : δ( x -

déphasage du serveur) ) ;

c) L’état « prêt à générer » des jetons EA qui devront être envoyés aux différentes stations

pendant la période T (une place : P2.serveur) ;

d)Transition représentant à la fois la génération de ces jetons (une transition à qui l’on associe

une distribution temporisée δ( x- T) ) et la périodicité du serveur représenté par la flèche retour

sur le schéma.

e) Les buffers d’attente (P3.EA.1,…, P3.EA.m) où les jetons, après avoir été produits, attendent

qu’un droit de parole d’accès au bus leur soit accordé ( rôle du sous modèle « les restrictions

RM).

P1.serveur

T1.serveur

P2.serveur

T2.serveur

69

………

P3.EA.1 P3.EA.2 P3.EA.3 ………... P3.EA.m

Figure V.1 : Modèle de la génération des jetons EA

V.1.2.1.2 Génération des jetons EP

a) Des places pour représenter les états initiaux du LAS relativement à chaque flux périodique.

b)Des transitions pour représenter les déphasages initiaux et auxquelles on associe

respectivement les distributions des transitions temporisées T.1.EP.i ( δ(x – déphasage du jeton

EPi) ) ;

c) Des places pour représenter l’état du LAS « prêt à générer » par période le nombre de jetons

nécessaires pour chaque flux ;

d)Des transitions pour représenter à la fois la génération des jetons EP ainsi que la périodicité de

cette génération (flèche de retour). Les poids de sortie (# EP.1…#EP.P ) des transitions

T2.EP.1 …T2.EP.P représente le nombre de jetons générés par période pour chaque flux. On

associe respectivement à ces transitions les distributions temporisées : T2.EP.i (δ(x – Pi) ) ;

e) Des places (P3.EP.1,…, P3.P.p) pour visualiser les buffers d’attente des jetons EP.

P1.EP.1 P1.EP.2 ……….. P1.EP.p

T1.EP.1 T1.EP.2 ……….. T1.EP.p

P2.EP.1 P2.EP.2 ………… P2.EP.p

T2.EP.1 T2.EP.2 ……… T2.EP.p

#.EP.1 #.EP.2 ………….. #.EP.p

70

P3.EP.1 P3.EP.2 ………. P3.EP.p

Figure V.2: Modèle de la génération des jetons EP pour les différents flux périodiques

V.1.2.1.3 Génération des jetons EN

On suppose qu’un jeton EN est toujours prêt. Pour cela on a une place P3.EN qui

visualise le buffer d’attente du jeton EN.

P3.EN

Figure V.3 : Modèle présentant qu’un jeton EN est toujours prêt.

V.1.2.1.4 Accès au média des jetons

Pour les jetons EA et EP :

a) Définir une politique qui attribue l’accès des différents jetons au bus (média). Ce rôle est tenu

par les restrictions RM (res_EA.1….res_EA.m ; res_EP.1…res_EP.p ; res_EN) ;

b) Définir une place médium pour représenter le bus ( le média est libre quand elle est marquée) ;

c) Définir une transition immédiate T3 qui visualise l’envoi du jeton (c’est une transition

immediate). Un jeton ne peut pas être envoyé que si le médium est libre et si les conditions de

restriction de l’algorithme RM (res_…) autorisent l’ordonnancement du jeton ;

d) Définir une place P5 pour confirmer ou modéliser l’envoi du jeton ;

e) Définir une place P4 pour représenter l’attente de la fin du temps dont dispose le jeton ;

71

f) Définir une transition T4 pour représenter le temps d’attente de la fin du temps dont dispose le

jeton (la durée de cette durée est égale à Hi pour les jetons EA et Ci/vi pour les jetons EP), ce

qui fait qu’on associe respectivement les distributions δ(x – Hi) et δ(x - Ci/vi ) ;

g)Définir une transition immédiate T5 pour représenté le retour prématuré du jeton si un tel cas

se présente ;

h) Définir une place P6 représentant ce retour anticipé du jeton.

Voici donc le modèle d’utilisation du médium :

Pour les jetons EA et EP :

P3: P3.EA.j, P3.EP.i

T3: T3.EA.j, T3.EP.i





P6: P6.EA.j, P6.EA.i

Res : Res_EA.j, Res_EAi

P3

Restiction RM…T3

P5

MédiumP4

P6

Res_…..

72

T5 T4

Figure V.4 : Modèle de l’utilisation de médium

Pour les jetons EN :

On procède de la même façon que pour les jetons EA et EP, la seul différence c’est que le

jeton est déjà prêt d’après notre supposition.

P3.EN

T3.EN

MédiumP5.EN

P4.EN

P6.EN

T4.EN T5.EN

Figure V.5 : Utilisation du médium par les jetons EN

Res__EN

73

V.1.2.1.5 Les restrictions RM (Rate Monotonic)

Nous remarquons que les priorités des flux sont décroissantes en allant de gauche vers la

droite, c’est à dire que les flux du serveur sont les plus prioritaires et que le flux de trafic non

temps réel a la priorité la plus faible. Pour ce ordonner l’accès au média de ces différents jetons

dans cet ordre, des arcs inhibiteurs vont de chaque place P3 aux transitions des autres places en

aval de celle ci. Le règle de fonctionnement de ces restrictions est qu’une transition T3 ne peut

être tirée que s’il n’y a aucun jeton en attente dans les places de buffers d’attente des flux de

priorité supérieure. Le schéma montrant ces restrictions est le suivant :

PE.3.1 P3.EA.m P3.EP.1 P3.EP.p P3.EN

T3.EA.1 T3.EA.m T3.EP.1 T3.EP.p T3.EN

médium

Figure V.6 : Restrictions RM

74

V.1.2.1.6 Le modèle complet du LAS

Module EA Module EP Mod.EN

P1.serveur P1.EP.1 P1.EP.p

T1.serveur T1.EP.1 T1.EP.p

P2.serveur P2.EP.1 P2.EP.p

T2.serveur T2.EP.1 T2.EP.p P3.EN

P3.EA.1 P3.EA.m P3.EP.1 P3.EP.p

T3.EA.1 T3.EA.m T3.EP.1 T3.EP.p P4.ENP5.EA.1 P5.EA.m P5.EP.1 P5.EP.p

P4.EA.1 P4.EA.m P4.EP.1 P4.EP.p T4.EN P6.EA.1 P6.EA.m P6EP.1 P6.EP.p MEDIUM

T5.EN T5.EA.1 T5.EA.m T5.EP.1 T5.EP.p MEDIUM

T4.EA.1 T4.EA.m T4.EP.1 T4.EP.p

Figure V.7: Le modèle complet du LAS mettant en œuvre l’ordonnancement

V.1.2.2 Le modèle de service d’un flux de messages périodiques

Res EA.1 Res.EA.m

Res.EP.1

Res.EP.p

Res.EN

75

Pour modéliser le service d’un flux de messages périodiques, on doit suivre les étapes

suivantes :

V.1.2.2.1 Arrivée du jeton EP

a) Définir une place (P5.EP.i) pour modéliser l’arrivée du jeton EP ;

b)Définir une transition immédiate T7.EPi, et aussi une place P7.EPi pour représenter le séjour

du jeton dans la station ;

c) Définir une transition (T8.EPi) qui visualisera la durée de transmission du fragment (durée

égale à Ci/vi.). La distribution associée à cette transition temporisée est : δ(x – Ci/vi) ;

V.1.2.2.2 Génération des flux de messages périodiques Mpi

a) Définir une place (P1.Mpi) pour représenter l’état initial de la station ;

b)Définir une transition (T1.Mpi) pour visualiser le déphasage initial de la station par rapport à

une référence temporelle globale. On associe à cette transition la distribution : δ (x –

déphasage du flux) ;

c) Représenter à l’aide d’une place (P2.Mpi) l’état de la station « prêt à générer le flux » ;

d)Définir une transition (T2.Mpi) pour visualiser à la fois la production d’un nombre vi de

fragments qui sont mis dans la place buffer P3.Mpi (vi est représenté par le poids #Mpi de

l’arc de sortie de la transition T2.Mpi) et la périodicité (flèche retour à la place P2.Mpi). De

ce fait, on associe à cette transition temporisée, la distribution : δ(x – Pi).

V.1.2.2.3 Transmission d’un fragment de messages périodiques

a) Définir deux transitions immédiates [une (T7.EP.i) dans le cas où il y a présence de fragment

dans la place P3.Mpi, et une autre (T6.EP.i) dans le cas où il n’y a pas de fragment dans cette

place ;

b) Définir une place (P7.EPi) pour représenter l’état du fragment en cours de transmission.

c) Définir une place (P6.EPi) pour représenter le retour anticipé du jeton EPi au LAS.

76

P1.MPi

T1.MPi

P2.MPi

Arrivée du jeton P5.EP.i T2.MPi

#.MPi

P3.MPi

T6.EP.iT7.EPi

P7.EPi

T8.EPiDurée du fragment de message

P6.EP.i

Retour anticipé du jeton

Figure V.8: Service de flux de messages périodiques MPi

77

V.1.2.3 Le modèle de service d’un flux de messages apériodiques

Supposition : on a x flux de messages apériodiques (Ma) temps réel dans la station k.

V.1.2.3.1 Arrivée du jeton AE

a) Définir une place P5.EA.k pour représenter l’arrivée du jeton dans la station k ;

b) Définir une transition immédiate T6.EA.k, et aussi une place P7.EA.k pour représenter le

séjour du jeton dans la station k ;

c) Définir une transition (T7.EA.k) qui visualisera la durée de séjour du jeton EA (durée égale à

Hk). La distribution associée à cette transition temporisée est : δ(x – Hk).

V.1.2.3.2 Production des flux de messages apériodiques Maj

a) Définir une place (P1.k.Maj pour le flux Maj et P1.k.Ma(j+x) pour le flux Ma(j+x)) pour

représenter l’état initial de la station k ;

b) Définir une transition (T1.k.Maj pour le flux Maj et T1.k.Ma(j+x) pour le flux Ma(j+x)) pour

visualiser le déphasage initial de la station par rapport à une référence temporelle globale. On

associe à cette transition la distribution : δ (x – déphasage du flux) ;

c) Représenter à l’aide d’une place (P2.k.Maj pour le flux Maj et P2.k.Maj pour le flux

Ma(j+x))l’état de la station « prêt à générer le flux » ;

d)Définir une transition (T2.k.Maj pour le flux Maj et T2.k.ma(j+x) pour le flux Ma(j+x)) pour

visualiser à la fois la production d’un nombre vi de fragments qui sont mis dans la place buffer

P3.k.Maj ou P3.k.ma(j+x) (vi est représenté par le poids #.k.Maj ou #.k.Ma(j+x) de l’arc de

sortie de la transition T2.k.Maj) et la périodicité (flèche retour à la place P2.k.Maj ou

P2.k.Ma(j+x)). De ce fait, on associe à cette transition temporisée, la distribution : δ(x – Pi).

V.1.2.3.3 Transfert du trafic non temps réel et temps réel

Le trafic non temps réel (présent dans le buffer) P3.Mn peut être envoyé après que la

place P9.EA.k ait été marquée.

a) La prise d’un message de trafic non temps réel de la place P3.Mn est visualisé par le tir de la

transition T8.EA.k ;

78

b) La place P8.EA.k représente l’état « en cours de transmission » du trafic non temps réel ;

c) La transition temporisée T9.EA.k représente la durée de transmission du trafic non temps réel.

On associe à cette transition la distribution : δ(x – durée moyenne d’un message) ;

d) La fin du trafic temps réel se produit de deux manières :

Cas 1 : lorsque la durée Hk du jeton EA expire, c’est à dire tir de la transition T7.EA.k, ce qui

annule le marquage de la place P7.AE.k et donc supprime l’autorisation de trafic non temps réel

(tir de la transition T11.EA.k). Dans ce premier cas, la transmission en cours est interrompue et le

message est remis dans le buffer (Tir de la transition T12.EA.k).

Cas 2 : lorsqu’il n’y a plus de messages non temps réel en attente (place buffer P3.Mn avec un

marquage nul). Dans ce deuxième cas, on aura un renvoi anticipé du jeton EA au LAS (Tir de la

transition T10.EA.k).Arrivée du jeton EA de la station k

Flux Maj Flux Ma(j+x)P1.k.Maj P1.k.Ma(j+x)

P5.EA.k

T1.k.Maj T1.k.Maj(x+1)P4.k.Ma(j+x)

T6.EA.k P2.k.Maj P2.k.Ma(j+x)

P4.k.Maj

T2.k.Maj T2.k.Ma(j+x) T4.k.Maj

#.k.Maj T4.k.Ma(j+x) #.k.Ma(j+x)

P3.k.Maj P3.k.Ma(j+x) P3.Mn P5.k.Maj

P5.k.Ma(j+x)T3.k.Ma(j+x)

T5.k.Maj T5.k.Ma(j+x) T8.EA.k

T3.k.Maj P6.k.Ma(j+x)

P6.k.Maj P8.EA.k

T6.k.Maj T6.k.Ma(j+x) T12.EA.k

T9.EA.k

P9.EA.k

P7.EA.k T11.EA.k

T10.EA.kT7.EA.k

Durée Hk associée au jeton EA

Flux de messages

apériodiques non

temps réel

79

P6.EA.kRenvoi anticipé du jeton EA au LAS

Figure V.9 : Service des flux de messages apériodiques d’une station k

V.1.2.4 Le modèle du service des flux de messages apériodiques non temps réel

V.1.2.4.1 Arrivée du jeton EN

a) Définir une place P5.EN pour représenter l’arrivée du jeton dans la station k ;

b)Définir une transition immédiate T6.EN, et aussi une place P7.EN pour représenter le séjour

du jeton dans la station ;

c) Définir une transition (T7.EN) qui visualisera la durée de séjour du jeton EN . La distribution

associée à cette transition temporisée est : δ(x – durée associée au jeton).

V.1.2.4.2 Production du flux global de trafic apériodique non temps réel

a) Définir une place (P1.Mn) pour représenter l’état initial de la station ;

b)Définir une transition (T1.Mn) pour visualiser le déphasage initial de la station par rapport à

une référence temporelle globale. On associe à cette transition la distribution : δ (x –

déphasage du flux Mn) ;

c) Représenter à l’aide d’une place (P2.Mn) l’état de la station « prêt à générer le flux » ;

d)Définir une transition (T2.Mn) pour visualiser à la fois la production d’un nombre vi de

fragments qui sont mis dans la place buffer P3.Mn et la périodicité (flèche retour à la place

P2.Mn). De ce fait, on associe à cette transition temporisée, la distribution f(x)=λe-λ.x avec λ

= Taux d’arrivées des messages ; dans le cas d’un trafic non temps réel des arrivées du type

Poisson sont la meilleure présentation.

V.1.2.4.3 Mécanismes relatifs au transfert du trafic non temps réel

Même mécanismes que le transfert du trafic non temps réel vu dans le modèle de services

des flux de messages apériodiques temps réel.

Le trafic non temps réel (présent dans le buffer) P3.Mn peut être envoyé après que la

place P9.EN ait été marquée ;

80

a) La prise d’un message de trafic non temps réel de la place P3.Mn est visualisé par le tir de la

transition T8.EN ;

b)La place P8.EN représente l’état « en cours de transmission » du trafic non temps réel ;

c) La transition temporisée T9.EN représente la durée de transmission du trafic non temps réel.

On associe à cette transition la distribution : δ(x – durée moyenne d’un message) ;

d)La fin du trafic temps réel se produit de deux manières :

Cas 1 : lorsque la durée du jeton EN expire, c’est à dire tir de la transition T7.EN, ce qui annule le

marquage de la place P7.EN et donc supprime l’autorisation de trafic non temps réel (tir de la

transition T11.EN). Dans ce premier cas, la transmission en cours est interrompue et le message

est remis dans le buffer (Tir de la transition T12.EN).

Cas 2 : lorsqu’il n’y a plus de messages non temps réel en attente (place buffer P3.Mn avec un

marquage nul). Dans ce deuxième cas, on aura un renvoi anticipé du jeton EN au LAS (Tir de la

transition T10.EN).

P1.Mn

T1.Mn

Arrivée des jetons EN P5.EN P2.Mn

T2.MnT6.EN

P3.MnP7.EN

P9.ENT8.EN

T7.ENP8.EN

Durée associée au jeton

T11.EN T12.EN

T9.EN

81

T10.EN

P6.EN

Retour anticipé du jeton

Figure V.10 : Service de flux de messages non temps réel

Le modèle global est obtenu en interconnectant les différents modèles par fusion des

places qui portent le même nom sur le différents modèles. Les places fusionnées sont :

P5.EA.1,…, P5.EA.m, P6.EA.1,…., P6.EA.m, …, P5.EP.1, …, P5.EP.m, …, P6.EP.1,…,

P6.EP.m, …, P5.EN, P6.EN.

CHAPITRE VI: ANALYSES

V.1 Hypothèses

• Nous considérons uniquement les flux de messages temps réel.

Flux périodiques : 27 flux dont les caractéristiques initiales sont données sur le tableau

suivant. Nous avons choisi de donner la liberté de choix des unités de mesure des

différentes caractéristiques des flux de messages ainsi que du serveur. Remarquons tout

simplement que ces unités peuvent être différentes d’un système à un autre.

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 2.5 300

i= 18 à 22 10 500

82

i= 23 à 27 10 750

Tableau VI.1: Caractéristiques initiales des flux de messages périodiques temps réel

Flux apériodiques : On a 10 flux qui sont répartis sur 3 stations ( station 1, station 2,

station 3.

Station 1 Station 2 Station 3

Hj = Durée allouée par le jeton EAj

H1=7.5 H2= 10 H3= 10

periode du serveur

100 100 100

Tableau VI.2: Caractéristiques initiales des durées allouées par les jetons Eaj pour transmettre les flux de messages apériodiques temps réel

VI.1.2Le modèle de l’exemple

83

P3.EA.1 P3.EA.2 P3.EA.3

T3.EA.1 T3.EA.2 T3.EA.3

P5.EA.1 P1.1.Ma1 P5.EA.2 P1.2.Ma2 P1.3.Ma3

T6.EA.1 T1.1.Ma1 T6.EA.2 T1.2.Ma2 T1.3.Ma3

P4.1.Ma1 P2.1.Ma1 P4.2.Ma1 P2.2.Ma2 P2.3.Ma3

T4.1.Ma1 T2.1.Ma1 T4.2.Ma2 T2.2.Ma2 T4.3.Ma3

P5.1.Ma1 P3.1.Ma1 P5.2.Ma2 P3.2.Ma2 P5.3.Ma3 P3.3.Ma3

T5.1.Ma1 T3.1.Ma1 T5.2.Ma2 T3.2.Ma2 T5.3.Ma3 T3.3.Ma3

P6.1.Ma1 P6.2.Ma2 P6.3.Ma3

T6.1.Ma1 T6.2.Ma2 T6.3.Ma3

P9.EA.1 P9.EA.2 P9.EA.3 P7.EA.1 P7.EA.2 P7.EA.3

T10.EA.1 T10.EA.2 T10.EA.3 T7.EA.1 T7.EA.2 T7.EA.3

. P6.EA.1P6.EA.2 P6.EA.3 P6.Mp1 P6.Mp2

P4.EA.1 P4.EA.2 P4.EA.3 P4.EP.1 P4.EP.2 P4.EP

84

Res_EA1 Res_EA2 Res_EA3

Res_EA3 Res_EA3 Res_EA3 Res_EA3

P1.serveur

T1.serveur

P2.serveur

T2.serveur

P1.EP.1

T1.EP.1

P2.EP.1

T2.EP.1

P1.EP.2

T1.EP.2

P2.EP.2

T2.EP.2

P1.EP.3

T1.EP.3

P2.EP.3

T2.EP.3

P1.EP.27

T1.EP.27

P2.EP.27

T2.EP.27

P3.EP.27

T3.EP.27

P1.Mp27

T1.Mp27

P2.Mp27

T2.Mp27

P3.Mp27

P5.EP.27

T7.EP.27

P7.EP.27

T8.EP.27

T6.Mp27

P6.Mp27

Retour anticipé du jetonP4.EP.27

Retour anticipé du jetonP6.Mp3

P1.Mp3

T1.Mp3

P2.Mp3

T2.Mp3

P3.Mp3

T6.Mp3

P7.EP.3

T8.EP.3T8.EP.2T8.EP.1

P7.EP.2P7.EP.1

T6.Mp2T6.Mp2

P1.Mp1 P1.Mp2P3.EP.1

P3.EP.2P3.EP.3

T3.EP.1

T7.EP.1

P5.EP.1 P5.EP.2 P5.EP.3

MEDIAFigure VI.1 : Modèle de l’exemple

T4.EA.2 T4.EA.3T4.EA.1

T5.EA.2 T5.EA.2T5.EA.2

T4.EP.1T4.EP.2 T4.EP.3

T4.EP.27T5.EP.27

T5.EP.3

• La durée maximale d’utilisation du réseau est fixée à une valeur de 10 (ce qui définit la durée

maximale de l’inversion de priorité). En outre, nous considérons des déphasages très faibles

(incréments de 0.01) qui sont associés aux différents flux de manière inversement

proportionnelle à leur priorité (ceci permet de faire apparaître les instants critiques non-

préemptif.

• Les caractéristiques du serveur (LAS) sont définies en appliquant la méthode développée au

paragraphe IV 2-1 ;

La valeur de sa période T est prise égale à 100 ( c’est à dire, on a bien T≤ min{Pj}) ; de

plus, compte tenu de cette valeur, le serveur a la plus grande priorité : T< min {Pi}=150 ;

Les durées H1, H2 et H3 allouées par les jetons EA1, EA2 et EA3 ; H1=7.5, H2=10 et

H3=10.

• On adopte le cas 1 pour la caractérisation de l’anneau logique lors de la création des jetons.

C’est à dire que le LAS envoie sans interruption les jetons EAj au début de chaque période T

du serveur ;

• On adopte aussi le choix de l’algorithme RM non préemptif pour l’ordonnancement du trafic

périodique temps réel.

VI.1.3 Signification des places et des transitions de cet exemple

VI.1.3.1 Le LAS

VI.1.3.1.1 Les places du LAS

Génération de jetons EA, pour les flux apériodiques temps réel :

P1.serveur : état initial du serveur.

P2.serveur : L’état « prêt à générer » des jetons Eaj.

P3.EA.j: Un buffer d’attente où les jetons EAj, après avoir été produits, attendent qu’un droit de

parole d’accès au bus leur soit accordée (fonction assurée par l’arc inhibiteur).

Génération de jetons EP pour le flux périodique temps réel:

P1.EP.i: état initial du LAS relatif au flux périodique (Mpi) à ordonnancer.

P2.EP.i : L’état « prêt à générer » des jetons EPi.

P3.EP.i: Un buffer d’attente où les jetons EPi, après avoir été produits, attendent qu’un droit de

parole d’accès au bus leur soit accordée (fonction assurée pas l’arc inhibiteur).

84

VI.1.3.1.2 Les transitions du LAS

Génération de jetons EA, pour les flux apériodiques temps réel :

T1.serveur : Transition représentant le déphasage initial du serveur par rapport à une référence

temporelle globale. Une transition, T1.serveur, à qui l’on associe une distribution temporisée : δ( x

- déphasage du serveur).

T2.serveur : Transition représentant à la fois la génération des jetons EA et la périodicité du

serveur représenté par la flèche retour sur le schéma. Une transition à qui l’on associe une

distribution temporisée δ( x - T).

Génération de jetons EP pour le flux périodique temps réel:

T1.EP.i: Transition représentant le déphasage initial du serveur par rapport à une référence

temporelle globale (une transition à qui l’on associe une distribution temporisée : δ( x - déphasage

du serveur) ).

T2.EP.i: Transition représentant à la fois la génération des jetons EPi et la périodicité du serveur

représenté par la flèche retour sur le schéma. Une transition à qui l’on associe une distribution

temporisée δ( x - T).

VI.1.3.2 Accès et utilisation du média

VI.1.3.2.1 Les places de l’accès et de l’utilisation du média

Accès et utilisation du média par le jeton EA (trafic apériodique temps réel)

P5.EA.j : représente l’envoie de jeton EAj sur le média.

P4.EA.j : représente l’attente de la fin du temps dont dispose le jeton Eaj.

P6.EA.j : représente le retour prématuré du jeton EAj vers le LAS.

Accès et utilisation du média par le jeton EP (trafic périodique temps réel)

P5.EP.i: représente l’envoie de jeton EPi sur le média.

P4.EP.i: représente l’attente de la fin du temps dont dispose le jeton EPi.

P6.EP.i: représente le retour prématuré du jeton EPi vers le LAS.

VI.1.3.2.2 Les transitions de l’accès et de l’utilisation du média

Accès et utilisation du média par le jeton EA (trafic apériodique temps réel)

T3.EA.j : c’est une transition qui visualise le temps d’envoie du jeton EAj sur le média (c’est une

transition immédiate).

85

T4.EA.j : c’est une transition qui visualise le temps pendant lequel le jeton EAj peut utiliser le

média. On associe à cette transition la distribution temporelle : δ( x – Hj) (rappel : Hj = durée

maximale pour le jeton EAj d’utiliser le média).

T5.EA.j : c’est une transition qui visualise le temps du retour prématuré du jeton EAj. C’est aussi

une transition immédiate.

Accès et utilisation du média par le jeton EP (trafic périodique temps réel)

T3.EP.i: une transition qui visualise le temps d’envoie du jeton EPi sur le média (c’est une

transition immédiate).

T4.EP.i: une transition qui visualise le temps pendant lequel le jeton EAi peut utiliser le média.

On associe à cette transition la distribution temporelle : δ( x – C).

T5.EP.i: une transition qui visualise le temps du retour prématuré du jeton EAi. C’est aussi une

transition immédiate.

VI.1.3.3 Service de flux de messages apériodiques temps réel

VI.1.3.3.1 Les places

P5.EA.j : Place représentant l’arrivée du premier jeton EAj dans la station j.

P1.j.Maj : Place représentant l’état initial de la station j.

P2.j.Maj : place représentant l’état « prête à générer le flux de messages Maj » de la station j.

P3.j.Maj : Un buffer d’attente où le flux de messages apériodiques temps réel Maj, après avoir été

produits, attend qu’un droit de parole d’utilisation du jeton arrivé lui soit accordé (fonction assurée

par l’arc inhibiteur).

P4.j.Maj : une place représentant la prise du jeton EAj par la station j.

P5.j.Maj : une place représentant la transmission du flux de messages Maj.

VI.1.3.3.2 Les transitions

T1.j.Maj : transition représentant le déphasage initial de la station j. On associe à cette transition

la distribution temporelle : δ( x – déphasage du flux Maj).

T2.j.Maj : Transition représentant la génération du flux de messages Maj temps réel. Une

transition à qui l’on associe une distribution temporisée δ( x – Pj).

T3.j.Maj : transition immédiate en rapport avec la place P3.j.Maj.

T4.j.Maj : transition immédiate en rapport avec la place T4.j.Maj.

T5.j.Maj : Une transition qui visualise la durée d’émission du flux de messages apériodiques Maj.

On associe à cette transition la distribution temporelle δ( x – C).

86

VI.1.3.4 Service de flux de messages périodiques temps réel

VI.1.3.4.1 Les places

P1.Mp.i : place pour représenter l’état initial de la station.

P2.Mp.i : place pour représenter l’état de la station « prêt à générer le flux ».

P3.Mp.i : place où le flux périodique, après avoir été produit, attend qu’on lui attribue un jeton

pour pouvoir être transmis sur le réseau (arc inhibiteur).

P5.EP.i : Place pour modéliser l’arrivée du jeton EPi.

P6.EP.i : place pour représenter le retour anticipé du jeton EPi au LAS.

P7.EP.i : place pour représenter l’état du fragment en cours de transmission.

VI.1.3.4.2 Les transitions

T1.Mp.i : une transition pour visualiser le déphasage initial de la station par rapport à une

référence temporelle globale. On associe à cette transition la distribution : δ (x – déphasage

du flux).

T2.Mp.i : une transition pour visualiser la production d’un nombre v de fragments qui sont mis

dans la place buffer P3.Mp.I. La périodicité des flux est représenté par le flèche retour à la place

P2.Mp.i. On associe à cette transition temporisée, la distribution : δ(x – Pi).

T7.EP.i : une transition immédiate dans le cas où il y aurait présence de fragment dans la place

P3.Mp.i.

T6.EP.i : une transition immédiate dans le cas où il n’y aurait pas de fragment dans la place

P3.Mp.

T8.EP.i : une transition qui visualise la durée de transmission du fragment (durée égale à C/v.). La

distribution associée à cette transition temporisée est : δ(x – C/v)

VI.1.4 Analyses effectuées

Nous considérons deux cas de configurations initiales du réseau en termes de trafic :

Cas 1 : On a uniquement les flux périodiques à ordonnancer sur le réseau au moyen du serveur.

Cas 2 : On a à la fois le trafic apériodique et le trafic périodique à ordonnancer au moyen du

serveur.

VI.1.5 L’objectif de l’analyse

87

Nous nous fixons l’objectif d’introduire des modifications, à partir des configurations

initiales du cas 1 et du cas 2, des caractéristiques des flux périodiques ( augmentation progressive

du taux d’utilisation du réseau par ces flux) et de détérminer :

D’une part, le retard maximal des messages ( temps écoulé entre la requête et la fin de

l’envoi) ; ce retard est mesuré au moyen du modèle RdPTS par le temps écoulé entre l’instant

où le message d’un flux arrive dans une place buffer et l’instant où ce message finit d’utiliser

le médium ( tir des transitions T8 dans le modèle du service périodique et des transitions T5

dans le modèle du sErvice apériodique temps réel) ;

D’autre part, la limite des ordonnancements permis, c’est à dire lorsque le retard maximal des

messages dépasse l’échéance temporelle ; cette condition est visualisée par le tir des

transitions T2 des modèles service périodique et apériodique temps réel alors que les places de

sortie de ces transitions sont encore marquées.

VI.2 Analyses et résultats

VI.2.1 Analyses et résultats du cas 1 ( seulement des flux périodiques)

VI.2.1.1 Première analyse du cas 1

Ordonnancement des flux de messages périodiques dont les caractéristiques initiales sont

représentées dans le tableau suivant :

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 2.5 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.3 : Caractéristiques des flux de messages périodiques temps réel de la première analyse du cas 1

Les séquences d’ordonnancement de ces flux de messages sont représentées par la figure (figure VI.2) suivante.

Echéance ou période des flux Mp1 à Mp6Echéance ou période des flux Mp7 à Mp11

88

Echéance ou période des flux Mp12 à Mp17Echéance ou période des flux Mp18 à Mp22Echéance ou période des flux Mp23 à Mp 27

Flux de messages périodiques

89

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165175

180185

190195

200205

210215

220225

230235

240245

250255

260265

270

275

280

285

290

295

300

305

310

315

320

20

Retard maximal du flux Mp27 = 132.5

Figure VI.2: Première analyse du cas 190

Explication :

Les 6 premiers flux de messages périodiques ont la même période de durée égale à 150.

Durant une période, et presque en même temps que la création des flux par les différentes stations,

le serveur génère les jetons EP1, EP2, EP3, EP4, EP5, EP6 pour servir ces flux dans le but de

respecter leurs échéances. Ces jetons se placeront respectivement dans les places P3.EP.1,

P3.EP.2, P3.EP.3, P3.EP.4, P3.EP.5, P3.EP.6 et y attendront le droit d’accès au média (rôle joué

par les restrictions RM).

Les 5 flux de messages périodiques suivants (Mp7, Mp8, Mp9, Mp10 et Mp11)sont

affectés d’une même période égale à 250, ce qui veut dire qu’entre 0 et 250, le serveur doit

générer les jetons EP7, EP8, EP9, EP10 et EP11, presque en même temps que la création de ces

flux de messages par la station concernée, afin de pouvoir les transmettre et respecter leurs

échéances. Une fois générés, ces jetons se placerons respectivement dans les places P3.EP.7,

P3.EP.8, P3.EP.9, P3.EP.10, P3.EP.11 où ils attendront le droit d’accès au média géré par les

restrictions RM.

Pour les flux de messages restants, le serveur agit de la même manière que pour les flux

précédents tout en prenant bien soin de la différence des périodes de ces flux.

Ici, c’est le flux Mp1 qui est le plus prioritaire ( on rappelle qu’on est en cas 1 c’est à dire

qu’on a uniquement le trafic apériodique dans le réseau), les restrictions RM vont alors donner le

droit d’accès au média au jeton EP1 pour permettre au flux Mp1 d’être transmis. A ce stade, Les

places P5.EP.1 et P4.EP.1 sont marquées ce qui veut dire qu’il y a réception du jeton EP1 par la

station concernée (marquage de la place P5.EP.1) et que cette station ne possède qu’une durée de

2.5, durée du jeton EP1 pour transmettre Mp1 ( marquage de la place P4.EP.1). Au bout de ce

temps permis à la transmission de Mp1, le média devient libre (marquage de la place média).

Comme la place P3.EP.1 n’est plus marquée, les restrictions RM donnent le droit d’accès au

média au jeton EP2 et ainsi de suite jusqu’à la permission d’accès au média du jeton EP27 pour

transmettre le flux de messages Mp27.

Lors du processus d’ordonnancement, il n’y a pas eu de problèmes. Les échéances ont été

respectées et on a relevé à 132.5 le retard maximal du message du flux Mp27 qui est la moins

prioritaire. Les résultats requis lors de cette première analyse sont regroupés dans le tableau

suivant.

Dans cet exemple, on adopte l’hypothèse que tout le temps permis à la station pour

transmettre ses flux (c’est à dire la durée du jeton) est utilisé à 100%,. Par conséquent les retours

anticipés des jetons n’ont pas lieu.

91

Tableau résumant les principaux résultats de cette première analyse :

U(réseau)Test

d’ordonnançabilitéRetard

maximal de message du flux

MP27

Respect de l’échéance

36.67% positif 132.5 oui

Tableau VI.4: Les résultats principaux de la première analyse du cas 1

VI.2.1.2 Deuxième analyse du cas 1

Ordonnancement des flux de messages périodiques dont les taux d’utilisation du réseau des

flux Mp12 à Mp17 ont été augmentés pour être égaux à 7.5. Voici le tableau des

caractéristiques des flux de messages apériodiques pour cette deuxième analyse :

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 7.5 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.5: Caractéristiques des flux de messages périodiques temps réel de la deuxième

analyse du cas 1

La figure suivante montre les séquences d’ordonnancement des flux périodiques avec les nouvelles caractéristiques

92

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

295300

305

20

Retard maximal du flux Mp27 = 177.5

Figure VI.3: Deuxième analyse du cas 1

93

Tableau résumant les principaux résultats de cette deuxième analyse :

U(réseau)Test



MP27


46.67% positif 177.5 oui

Tableau VI.6: Les résultats principaux de la deuxième analyse du cas 1

Dans cette deuxième analyse, le processus est toujours le même que précédemment sauf

qu’ici, à cause de l’augmentation des taux d’utilisation du réseau par les flux Mp12 à Mp17 les

temps de transmission de ces flux a augmenté ce qui explique l’atteinte de la barre des 150 à la

transmission du flux Mp25. La retransmission des 6 premiers flux est expliquée par les facteurs ci

après :

Les 6 premiers flux sont périodiques et ont une période égale à 150 ;

Les 6 premiers flux sont plus prioritaires que les flux restants ;

L’algorithme utilisé pour ordonnancer l’ensemble des flux périodiques temps réel est

l’algorithme RM non préemptif.

Comme l’algorithme utilisé est le RM non préemptif, La transmission du flux de

message Mp25 n’est pas préemptée, le serveur attend qu’il soit transmis avant de permettre à

nouveau les 6 premiers flux périodiques temps réel d’accéder au média. La transmission du flux

Mp26 ne reprendra que juste après la transmission du flux Mp6.

VI.2.1.3 Troisième analyse du cas 1

Ordonnancement des flux de messages périodiques temps réel dont les taux d’utilisation

maximale du réseau des deux groupes de flux Mp7 à Mp11 et Mp12 à Mp17 ont été amenés

respectivement à 5 et à 10. Voici le tableau montrant les caractéristiques des flux de cette

troisième analyse :

94

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 5 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.7: Caractéristiques des flux de messages périodiques temps réel de la troisième analyse

du cas 1

La figure suivante montre les séquences d’ordonnancement des flux périodiques de cette troisième analyse :

95

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

295300

305

20

Retard maximal du flux Mp27 = 205

Figure VI.4: Troisième analyse du cas 1

96

Tableau résumant les principaux résultats de cette troisième analyse :

U(réseau)Test


maximal de message du flux MP27


56.67% positif 205 oui

Tableau VI.8: Les résultats principaux de la troisième analyse du cas 1

Dans cette troisième analyse, le raisonnement est pareil qu’avec le deuxième analyse. La seule différence réside sur le fait que les taux d’utilisation maximale du réseau des deux groupes de flux de messages temps réel Mp7 à Mp11 et Mp12 à Mp17 ont été augmentés et que les transmissions des flux Mp23, Mp24, Mp25, Mp26 et Mp27 ont du attendre à t=150, pour laisser la place à la transmission des 6 premiers flux plus prioritaires . Pour cela, le retard maximal de

message du flux Mp27 relevé est de 205.VI.1.2.4 Quatrième analyse du cas 1

Ordonnancement des flux de messages périodiques temps réel dont les taux

d’utilisation maximale du réseau des deux groupes de flux Mp7 à Mp11 ont été amenés

respectivement à 10. Voici le tableau montrant les caractéristiques des flux de cette troisième

analyse

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 10 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.9: Caractéristiques des flux de messages périodiques temps réel de la quatrième analyse du cas 1

La figure suivante montre les séquences d’ordonnancement des flux périodiques de cette

quatrième analyse :

97

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

295300

305

20


Figure 43: Quatrième analyse du cas 1

98

Tableau résumant les principaux résultats de cette quatrième analyse :

U(réseau)Test



MP27


66.67% positif 230 oui

Tableau VI.10: Les résultats principaux de la quatrième analyse du cas 1

Même explication que précédemment. Les transmissions des flux Mp22 à Mp27 ont du attendre

à cause de l’arrivée des 6 premiers flux plus prioritaires. Les échéances sont toujours

respectées. Voici le tableau regroupant les principaux résultats de cette quatrième analyse

VI.2.1.5 Cinquième analyse du cas 1 :

Les changements apportés, pour cette cinquième analyse, aux caractéristiques des flux

de messages périodiques sont montrés dans le tableau suivant :

Mpi Ci Pi

i=1 à 6 5 150

i= 7 à 11 10 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.11 : Caractéristiques des flux de messages périodiques temps réel de la cinquième

analyse du cas 1

La figure suivante montre les séquences d’ordonnancement des flux périodiques de cette cinquième analyse :

99

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

1020

30 5060

7080

90100

110120

130140

150160

170180

190200

210220

230240

250260

270280

290300

310320

330340

350360

370380

390400

410420

430440

450460

470480

490500

510520

530540

550560

570

580

590600

610

40


Figure VI.6: Cinquième analyse du cas 1

100

Tableau résumant les principaux résultats de cette cinquième analyse :

U(réseau)Test



MP27


76.67% négatif 400 oui

Tableau VI.12: Les résultats principaux de la cinquième analyse du cas 1

Dans cette cinquième analyse, avant d’arriver à la transmission du flux Mp27, on passe

par deux périodes des 6 premiers flux et une période du groupe des 5 flux suivant ce qui favorisera

l’attente des flux mois prioritaires, donc l’augmentation du retard maximal de Mp27 à 400.

VI.1.2.6 Sixième analyse du cas 1 :

On fait augmenter toujours le taux d’utilisation maximale du réseau par les 6 premiers

flux. Les autres ne peuvent plus être augmentées car 1O c’est la durée maximale d’utilisation du

réseau.

Mpi Ci Pi

i=1 à 6 7.5 150

i= 7 à 11 10 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.13: Caractéristiques des flux de messages périodiques temps réel de la sixième analyse du cas 1

La figure suivante montre les séquences d’ordonnancement des flux périodiques de cette sixième analyse :

101

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

1020

30 5060

7080

90100

110120

130140

150160

170180

190200

210220

230240

250260

270280

290300

310320

330340

350360

370380

390400

410420

430440

450460

470480

490500

510520

530540

550560

570

580

590600

610

40


Figure VI.7: Sixième analyse du cas 1

102

Tableau résumant les principaux résultats de cette sixième analyse :

U(réseau)Test



MP27


86.67% négatif 445 oui

Tableau VI.14: Les résultats principaux de la sixième analyse du cas 1

On remarque que l’on approche du taux d’utilisation maximale du réseau pour tous les

flux mais les échéances sont toujours respectées. C’est tout simplement le retard du flux de

messages périodiques temps réel Mp27 qui augmente.

VI.1.2.7 Septième analyse du cas 1 :

Dans cette dernière analyse, nous mettons au maximal les taux d’utilisation de tous les flux

de messages périodiques temps réel. Voici le tableau correspondant montrant ces caractéristiques

nouvelles des flux.

Mpi Ci Pi

i=1 à 6 10 150

i= 7 à 11 10 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.15: Caractéristiques des flux de messages périodiques temps réel de la septième

analyse du cas 1

La figure suivante montre les séquences d’ordonnancement des flux périodiques de cette

septième analyse.

103

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

Mp22

Mp23

MP24

Mp25

Mp26

Mp27

2040

60 100120

140160

180200

220240

260280

3003

340360

380400

420440

460480

500520

540560

5806

620640

660680

700720

740760

780800

820840

860880

900920

940960

980

80

Retard maximal du flux Mp27 = 880Non respect de l’échéance du flux de message Mp25

Non respect de l’échéance du flux de message Mp26

Non respect de l’échéance du flux de message Mp27 Figure VI.8: Septième analyse du cas 1

104

Tableau résumant les principaux résultats de cette septième analyse du cas 1:

U(réseau)Test



MP27


86.67% Négatif 880 NON

Tableau VI.16: Les résultats principaux de la septième analyse du cas 1

VI.2.2 Récapitulation des résultats des analyses du cas 1

Ci

i=1 à 7

i= 7 à 11

i= 12 à 17

i= 18 à 22

i=23 à 27

U ( Réseau)Test

d’ordonnançabilité

Retard maximal de message du

flux Mp27

Respect des

échéances

2.5 2.5 2.5 10 10 36.67% positif 132.5 oui

2.5 2.5 7.5 10 10 46.67 positif 177.5 oui

2.5 5 10 10 10 56.67 positif 205 oui

2.5 10 10 10 10 66.67 positif 230 oui

5 10 10 10 10 76.67 négatif 400 oui

7.5 10 10 10 10 86.67 négatif 445 oui

10 10 10 10 10 96.67 négatif 880 oui

Tableau VI.17: Récapitulation des résultats des analyses du cas 1

Ces résultats montrent :104

- Le taux d’utilisation à partir duquel l’ensemble de flux de messages n’est plus ordonnançable

(entre 93.6% et 94.6%) est supérieur à celui qui découle du test d’ordonnançabilité (vers les

70%), ce qui confirme bien le caractère pessimiste de ce test.

- Le premier flux à avoir, tout d’abord, des retards d’ordonnancement et ensuite des échéances

non respectées, est le flux qui a la plus faible priorité Mp27. Tant que le retard est inférieur à

750 (période du flux Mp27), il reste ordonnançable.

VI.2.3 Analyses et résultats du Cas 2 (ordonnancement des flux apériodiques et périodiques

temps réel à la fois)

VI.2.3.1 Première analyse du cas 2

Dans cette première analyse, les caractéristiques des flux apériodiques et des flux

périodiques sont présentées dans les deux tableaux suivants.

Flux messages apériodiques temps réel répartis sur trois stations

Station 1 Station 2 Station 3

Hj = Durée allouée par le jeton EAj

H1=7.5 H2= 10 H3= 10

période du serveur

100 100 100

Tableau VI.18.: Caractéristiques des durées allouées par les jetons des flux de messages

apériodiques temps réel de la première analyse du cas 2

Remarque :

105

Les caractéristiques (durées allouées par les jetons) des flux de messages apériodiques

resteront les mêmes dans toutes les analyses de ce deuxième cas.

Caractéristiques des flux de messages périodiques temps réel de la première analyse

du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 2.5 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.19: Caractéristiques des flux de messages périodiques temps réel de la première

analyse du cas 2

Voici les séquences d’ordonnancement de cette première analyse du cas 2.

Période du serveurEchéance ou période des flux Mp1 à Mp6Echéance ou période des flux Mp7 à Mp11Echéance ou période des flux Mp12 à Mp17Echéance ou période des flux Mp18 à Mp22Echéance ou période des flux Mp23 à Mp 27Flux de messages apériodiques Ma1 de la station 1Flux de messages apériodiques Ma2 de la station 2Flux de messages apériodique Ma3 de la station 3Flux de messages périodiques Mpi

106

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

395300

305

31020

Mp26

Mp27

Ma1

Retard maximal de message du flux Mp27= 230

Figure VI.9: première analyse du cas 2

Tableau résumant les principaux résultats de cette première analyse du cas 2 :

U(réseau)Test



MP27


60.5% positif 230 OUI

Tableau VI.20 : Les résultats principaux de la première analyse du cas 2

Le serveur, c’est à dire le LAS, crée au début de chaque période (période égale à 100) du

serveur les trois jetons apériodiques EA1, EA2 et EA3 qui allouent respectivement les durées H1,

H2 et H3. Après avoir été créés, ces jetons se placeront dans les places P3.EP.1, P3.EP.2 et

P3.EP.3 et y attendent le droit d’accès au média pour transmettre les flux de messages

apériodiques temps réel. L’accès au média est géré par les restrictions RM.

Le déroulement de l’ordonnancement est le même que dans le cas 1 sauf qu’ici, ce ne

sont plus les flux Ma1, Ma2 et Ma3 qui sont les plus prioritaires.

109

VI.2.3.2 Deuxième analyse du cas 2

Les caractéristiques des flux de messages apériodiques et périodiques temps réel de cette

deuxième analyse sont représentées sur les tableaux suivant :

Caractéristiques des flux de messages

périodiques temps réel de la deuxième

analyse du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 5 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.21: Caractéristiques des flux de messages périodiques temps réel de la deuxième

analyse du cas 2

Voici les séquences temporelles de cette deuxième analyse du cas 2

110

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

295300

305

31020

Mp26Mp27

Ma1

Retard maximal de message du flux Mp27= 245

Figure VI.10: deuxième analyse du cas 2

Tableau résumant les principaux résultats de cette deuxième analyse du cas 2 :

U(réseau)Test



MP27


65.5% positif 245 OUI

Tableau VI.22: Les résultats principaux de la deuxième analyse du cas 2

VI.2.3.3 Troisième analyse du cas 2

Les caractéristiques des flux de messages périodiques ont été changées alors que celles des flux

apériodiques restent inchangées. Voici le tableau résumant ces caractéristiques :

Caractéristiques des flux de messages périodiques temps réel de la troisième analyse

du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 7.5 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.23 : Caractéristiques des flux de messages périodiques temps réel de la troisième

analyse du cas 2

Les séquences temporelles de ces flux sont montrées dans la figure suivante

111

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

295300

305

31020

Mp26Mp27

Ma1

Retard maximal de message du flux Mp27= 272.5

Figure VI.11: troisième analyse du cas 2

112

Tableau résumant les principaux résultats de cette troisième analyse du cas 2 :

U(réseau)Test



MP27


70.5% négatif 272.5 OUI

Tableau VI.24.: Les résultats principaux de la troisième analyse du cas 2

VI.2.3.4 Quatrième analyse du cas 2

Les caractéristiques des flux de messages apériodiques et périodiques sont montrées dans le tableau suivant :

Caractéristiques des flux de messages périodiques temps réel de la quatrième

analyse du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 2.5 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.25: caractéristiques des flux de messages périodiques temps réel de la quatrième

analyse du cas 2

Voici les séquences temporelles de cette quatrième analyse du cas 2

113

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25

510

15 2530

3540

4550

5560

6570

7580

8590

95100

105110

115120

125130

135140

145150

155160

165170

175180

185190

195200

205210

215220

225230

235240

245250

255260

265270

275280

285

290

295300

305

31020

Mp26Mp27

Ma1


Figure VI.12: quatrième analyse du cas 2

114

Tableau résumant les principaux résultats de cette quatrième analyse du cas 2 :

U(réseau)Test



MP27



Tableau VI.26: Les résultats principaux de la quatrième analyse du cas 2

VI.2.3.5 Cinquième analyse du cas 2 :

Les caractéristiques nouvelles des flux de messages apériodiques et périodiques sont

données par les tableaux suivants :

Caractéristiques des flux de messages périodiques temps réel de la cinquième

analyse du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 5 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.27 : Caractéristiques des flux de messages périodiques temps réel de la cinquième analyse du cas 2

Voici les séquences temporelles de cette cinquième analyse

115

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25

1020

30 5060

7080

90100

110120

130140

150160

170180

190200

210220

230240

250260

270280

290300

310320

330340

350360

370380

390400

410420

430440

450460

470480

490500

510520

530540

550560

570

580

590600

610

62040

Mp26Mp27

Ma1


Figure VI.13: cinquième analyse du cas 2

116

Tableau résumant les principaux résultats de cette cinquième analyse du cas 2 :

U(réseau)Test



MP27



Tableau VI.28 : Les résultats principaux de la cinquième analyse du cas 2

VI.2.3.6 Sixième analyse du cas 2 :

Voici le tableau montrant les nouvelles caractéristiques des flux de messages périodiques de

cette sixième analyse:

Caractéristiques des flux de messages périodiques temps réel de la sixième analyse

du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 7.5 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.29: Caractéristiques des flux de messages périodiques temps réel de la sixième analyse du cas 2

Voici les séquences temporelles de cette sixième analyse.

117

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25

1020

30 5060

7080

90100

110120

130140

150160

170180

190200

210220

230240

250260

270280

290300

310320

330340

350360

370380

390400

410420

430440

450460

470480

490500

510520

530540

550560

570

580

590600

610

62040

Mp26Mp27

Ma1


Figure VI.14: sixième analyse du cas 2118

Tableau résumant les principaux résultats de cette sixième analyse du cas 2 :

U(réseau)Test



MP27



Tableau VI.30 : Les résultats principaux de la sixième analyse du cas 2

VI.2.3.7 Septième analyse du cas 2

Voici le tableau montrant les nouvelles caractéristiques des flux de messages

périodiques temps réel:

Caractéristiques des flux de messages périodiques temps réel de la septième analyse

du cas 2

Mpi Ci Pi

i=1 à 6 2.5 150

i= 7 à 11 10 250

i= 12 à 17 10 300

i= 18 à 22 10 500

i= 23 à 27 10 750

Tableau VI.3I: Caractéristiques des flux de messages périodiques temps réel de la septième analyse du cas 2

Voici les séquences temporelles de cette Septième analyse.

119

Ma2

Ma3

Mp1

Mp2

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23Mp24

Mp25

1020

30 5060

7080

90100

110120

130140

150160

170180

190200

210220

230240

250260

270280

290300

310320

330340

350360

370380

390400

410420

430440

450460

470480

490500

510520

530540

550560

570

580

59060040

Mp26

Mp27

Ma1

Figure VI.15: septième analyse du cas 2

Ma2

Ma3

Mp1

Mp2

590600

610 630640

650660

670680

690700

710720

730740

750760

770780

790800

810820

830840

850860

870880

890900

910930

930940

950960

970980

990

620

Ma1

120

Mp3

Mp4

Mp5

Mp6

Mp7

Mp8

Mp9

Mp10

Mp11

Mp12

Mp13

Mp14

Mp15

Mp16

Mp17

Mp18

Mp19

Mp20

Mp21

MP22

Mp23

Mp24

Mp25Mp26

Mp27


Non-respect de l’échéance de Mp27 Figure VI.16: septième analyse du cas 2 (suite)

121

Tableau résumant les principaux résultats de cette septième analyse du cas 2 :

U(réseau)Test



MP27


90.5% négatif 857.5 NON

Tableau VI. 32 : Les résultats principaux de la septième analyse du cas 2

VI.2.4 Récapitulation des résultats des analyses du cas 2

Ci

i=1 à 7

i=7 à 11

i=12 à 17

i=18 à 22

i=23 à 27

U ( Réseau)Test

d’ordonnançabilité

Retard maximal de message du flux Mp27

Respect des

échéances

2.5 2.5 2.5 10 10 60.5% positif 230 oui

2.5 2.5 5 10 10 65.5% positif 245 oui

2.5 2.5 7.5 10 10 70.5% négatif 272.5 oui

2.5 2.5 10 10 10 75.5% négatif 287.5 oui

2.5 5 10 10 10 80.5% négatif 442.5 oui

2.5 7.5 10 10 10 85.5% négatif 482.5 oui

2.5 10 10 10 10 90.5% négatif 857.5 non

Tableau VI.33 : Récapitulation des résultats du cas 2

Par rapport à l’analyse du cas 1 où on a ordonnancé uniquement les flux de messages

périodiques, on remarque dans l’analyse du cas 2 une réduction de la limité de l’ordonnançabilité

(conditions pour lesquelles les échéances ne sont plus respectées) du système

122

Partie 2 :Présentation des études et analyses (choix multiples)

d’ordonnancement de tâches apériodiques et périodiques dans un réseau local temps réel fonctionnant sous la norme

IEC-65C en pages Web

123

1 Description

Il s’agit de montrer en pages Web les différentes recherches, analyses et résultats de cette

étude. Nous avons choisi le cas 2 (Ordonnancement des flux de messages apériodiques et

périodiques à la fois) car dans un réseau local temps réel, des messages apériodiques peuvent se

montrer à tout moment. C’est d’ailleurs le modèle d’ordonnancement qui fonctionne le mieux

dans un réseau local temps réel

2 Page d’accueil

c’est une page qui présente le titre, l’auteur, le directeur de mémoire, la date qui est

reactualisée automatiquement ainsi que deux options :

Le bouton ENTRER qui permet d’entrer dans « ‘L’ordonnancement des flux de messages

indépendants dans un réseau local temps réel fonctionnant sous la norme IEC-65C au niveau de la

sous couche MAC »;

Le bouton QUITTER qui fait sortir du programme.

Figure 2.1: Page « accueil »

Le programme qui nous a permis d’afficher cette page est le suivant :

<html xmlns:o="urn:schemas-microsoft-com:office:office"xmlns:w="urn:schemas-microsoft-com:office:word"xmlns="http://www.w3.org/TR/REC-html40">

<head><meta http-equiv=Content-Type content="text/html; charset=windows-1252"><meta name=ProgId content=Word.Document><meta name=Generator content="Microsoft Word 9">

124

<td width="109"></td> <td valign="top" colspan="3"> <div align="right"> <script language="JavaScript1.2" ></script> </div> </td> <td width="2"></td> <td width="2"></td> </tr> <tr> <td width="2" height="88"></td> <td width="182"></td> <td></td> <td width="69"></td> <td width="147"></td> <td width="140"></td> <td></td>

126

<td></td> </tr> <tr> <td height="312"></td> <td colspan="6" valign="top"> <div align="center"><font size="+5"><b><font color="#006666">Ordonnancement des flux de messages indépendants dans un réseau local temps réel fonctionnant sous la norme IEC - 65C au niveau de la sous-couche MAC</font></b></font></div> </td> <td></td> </tr> <tr> <td height="48"></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr> <td height="30"></td> <td colspan="3" valign="top" rowspan="3"> <p class=MsoNormal style='text-indent:35.4pt'><b>Conçu par</b> : RAKOTONANAHARY Hajatiana </p> <p class=MsoNormal style='text-indent:35.4pt'><b>Sous la direction de</b> : RADONAMANDIMBY Edmond.</p> <p class=MsoNormal style='text-indent:35.4pt'><b>Département</b> :Télécommunications</p> <p class=MsoNormal style='text-indent:35.4pt'><b>ESPA 2001-2002 </b></p> </td> <td></td> <td colspan="3" valign="top"> <div align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button22.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button22.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object></div> </td> </tr> <tr> <td height="21"></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr>

<td height="30"></td>

127

<td></td> <td colspan="3" valign="top"> <div align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name=movie value="button23.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button23.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor=""> </embed> </object></div> </td> </tr> <tr> <td height="0"></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> <tr> <td height="1"></td> <td></td> <td><img height="1" width="109" src="image/spacer.gif"></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr></table></body>

</html>

128

3 La page « A propos »

C’est une page qui représente le système ainsi que ces différentes hypothèses et

caractéristiques.

On voit aussi sur cette page deux boutons :

Le bouton CONTINUER qui nous fait avancer dans le programme ;

Le bouton ACCUEIL qui nous permet de revenir à la page accueil.

Figure 3.1 : page « A propos »

Le programme qui nous a permis d’avoir cette page est le suivant :

<html><head><title>A propos</title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body background="image/n4back.gif" text="#FFFFFF"><div align="center"> <p><font size="+5"><b><i><font color="#000000">A propos</font></i></b></font>

</p></div>

129

<blockquote> <p> </p> <p><font size="4" color="#000000">C'est un réseau local où l'on a ordonancer 27 flux de messages périodiques Temps réel (Mp1 à Mp27) et quelques flux de messages apériodiques temps réel (Ma1, Ma2 et Ma3) répartis sur 3 stations du réseau.</font></p> <p><font size="4" color="#000000"><br> Les 27 flux périodiques temps réel seront transmis grace à l'acquisition des jetons EPi (i=1 à 27), générés par le serveur (LAS), de durée égale à la capacité (Ci) de chaque flux.</font></p> <p><font size="4" color="#000000"><br> Les flux apériodique temps réel répartit sur 3 stations du réseau , seront transmis à chaque période T du serveur (LAS) et ce , grace à l'acquisition des jetons EA1 pour la station 1, EA2 pour la station 2 et EA3 pour la station 3, de durées respectives: H1, H2 et H3.</font></p> <p><font size="4" color="#000000"><br>

L'ordre de priorité des flux de messages temps réel : Ma1>Ma2>Ma3>Mp1>....>Mp27. La durée maximale d'utilisation du réseau (Ci) pour un message est égale à 10.</font></p> <p> </p> </blockquote><p align="right"> </p><p align="right"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button1.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button1.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button2.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button2.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object></p></body></html>

130

4 La page « Modèle du système »

C’est la page qui nous montre le modèle du système sous les réseaux de Petri

temporisé stochastique (RdPTS). Il y a également deux boutons sur cette page « modèle du

système » :

Le bouton ACCUEIL qui nous fait revenir à la page « accueil » ;

Le bouton CONTINUER qui nous permet de continuer à entrer dans le programme.

Figure 4.1 : page « modèle du système »

Voici le programme qui nous a permis d’avoir cette page : <html><head><title>MODELE DU SYSTEME </title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body background="image/n4back.gif" text="#FFFFFF"><div align="center"><i><b><font size="+5">MODELE DU SYSTEME </font></b></i> </div>

131

<p>Schéma : modélisation de l'exemple</p><p align="center"><img src="image/modele1.jpg" width="784" height="522"></p><p align="right"> </p><p align="right"> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button3.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button3.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button4.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button4.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object></p></body></html>

132

5 Page « Caractéristiques du serveur du trafic temps réel »:

C’est une page qui résume les différentes caractéristiques du serveur (LAS) du trafic

temps réel telles que les durées allouées par les jetons Apériodiques (EA) pour servir le trafic

apériodique temps réel, ainsi que la valeur de la période T du serveur. Cette page présente aussi

deux boutons : ACCUEIL et CONTINUER dont les fonctions sont les mêmes que

précédemment.

Figure 5.1 : page « Caractéristiques du serveur du trafic temps réel »

Le programme qui nous a permis d’avoir cette page est le suivant : <html><head><title>CARACTERISTIQUES DU SERVEUR DU </title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

133

<body background="image/tissu007.jpg" text="#FFFFFF"><div align="center"><font size="+5"><i><b>CARACTERISTIQUES DU SERVEUR DU <br> TRAFIC TEMPS REEL </b></i></font><i><b></b></i> </div><p> </p><p><font size="4"><br> <br> </font></p><div align="center"> <table width="75%" border="1" cellspacing="0" cellpadding="0"> <tr> <td> <blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <p align="center"><font size="6">- T = 100</font></p> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </td> </tr> <tr> <td> <blockquote> <blockquote> <blockquote> <blockquote><blockquote><blockquote> <p align="center"><font size="6">- H1= 7.5</font></p> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </td> </tr> <tr> <td> <blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <p align="center"><font size="6">- H2 = 10</font></p> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </td> </tr> <tr> <td> <blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <p align="center"><font size="6">- H3 = 10</font></p>

134

</blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </td> </tr> </table></div><p><font size="4"><br> </font></p><p align="right"> </p><p align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button5.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button5.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button6.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button6.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object></p></body></html>

135

6 Page « choix des capacités des flux de messages Mp1 à Mp6 »

C’est une page qui nous avise qu’après quelques études et analyses, les capacités des

flux de messages Mp1 à Mp6 (Flux de messages périodiques temps réel) de période égale à

150, sont fixées à 2,5.

Le Bouton ACCUEIL nous permet toujours de revenir à la page « Accueil » ;

Tadis que le bouton CONTINUER nous fait entrer dans la page où nous devons choisir les

capacités (Ci) des flux de messages M7 à Mp11 parmis les 4 valeurs proposées : 2,5 – 5 – 7,5 –

10.

Figure 6.1 : Page « choix des capacités des flux de messages Mp1 à Mp6 »

Le programme qui nous a permis d’avoir cette page est le suivant : <html><head><title>Choix des capacités du groupe de flux de messages temps réel Mp1 à Mp6 dont la période est fixée à 150 </title>

136

7 Page « Choix des capacités des flux de messages Mp7 à Mp11 »

Cette page nous permet de choisir parmis les 4 valeurs proposées une valeur qui va

être attribuée aux flux de messages Mp7 à Mp11 comme capacité Ci. Il suffit de cliquer sur les

chiffres 1, 2, 3 ou 4 si on veut choisir respectivement les valeurs 2,5 – 5 – 7,5 ou 10. On peut

aussi cliquer directement sur la valeur qu’on choisit. Dans la suite de cette présentation, nous

choisirons la valeur 2,5.

Le bouton ACCUEIL nous fait revenir à la page « Accueil »

Figure 7.1 : Page « Choix des capacités des flux de messages Mp7 à Mp11 »

voici le programme qui nous a permis d’avoir cette page : <html><head><title>Choix des capacités du groupe de flux de messages temps réel Mp7 à Mp11 dont la période est fixée à 250 </title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body background="image/n4back.gif" text="#FFFFFF"><div align="center"> <p><font size="+5"><i><b>Choix des capacités du groupe de flux de messages temps réel Mp7 à Mp11 dont la période est fixée à 250 </b></i></font></p> <p> </p> <p> </p></div>

138

<div align="center"> <table width="75%" border="1" cellspacing="0" cellpadding="0"> <tr> <td width="17%"> <div align="center"><font size="6"><a href="choix3.htm"><img src="image/No1.gif" width="16" height="16" border="0" alt="Votre Choix"></a></font></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix3.htm">2.5 </a></font></div> </td> </tr> <tr> <td width="17%"> <div align="center"><font size="6"><a href="choix4.htm"><img src="image/No2.gif" width="16" height="16" border="0"></a></font></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix4.htm">5</a></font></div> </td> </tr> <tr> <td width="17%"> <div align="center"><font size="6"><a href="choix41.htm"><img src="image/No3.gif" width="16" height="16" border="0"></a></font></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix41.htm">7.5</a></font></div> </td> </tr> <tr> <td width="17%"> <div align="center"><a href="choix42.htm"><img src="image/No4.gif" width="16" height="16" border="0"></a></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix42.htm">10</a></font></div> </td> </tr> </table></div><p align="center"><br></p><p align="center"> </p><p align="center"> </p><p align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button9.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button9.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object> </p></body></html>

139


C’est presque la même page que précédemment sauf qu’ici, on a à choisir les capacités des flux

de messages périodiques temps réel Mp1é à Mp17 dont leur période est fixée à 300. et on

procède de la même façon qu’auparavant dans le choix des capacités. Le programme de

création de cette page est à peu près le même que celui qui précède. Il faut tout simplement

rectifier les phrases. Le bouton CHOIX nous permet de refaire les choix en retournant dans la

page « choix des capacités des flux de messages Mp1 à Mp6 ».

Pour la suite, nous choisissons la valeur 2,5.


Voici le programme qui nous a permis d’avoir cette page : <html><head><title>Choix des capacités du groupe de flux de messages temps réel Mp12 à Mp17 dont la période est fixée à 300 </title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body background="image/n4back.gif" text="#FFFFFF"><div align="center"><i><b><font size="+5">Choix des capacités du groupe de flux de messages temps réel Mp12 à Mp17 dont la période est fixée à 300 </font></b></i> </div><p> </p>

140

<p> </p><p><br></p><div align="center"> <table width="75%" border="1" cellspacing="0" cellpadding="0"> <tr> <td width="17%"> <div align="center"><font size="6"><a href="choix5.htm"><img src="image/No1.gif" width="16" height="16" border="0" alt="Votre Choix"></a></font></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix5.htm">2.5 </a></font></div> </td> </tr> <tr> <td width="17%"> <div align="center"><font size="6"><a href="choix51.htm"><img src="image/No2.gif" width="16" height="16" border="0"></a></font></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix51.htm">5</a></font></div> </td> </tr> <tr> <td width="17%"> <div align="center"><font size="6"><a href="choix52.htm"><img src="image/No3.gif" width="16" height="16" border="0"></a></font></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix52.htm">7.5</a></font></div> </td> </tr> <tr> <td width="17%"> <div align="center"><a href="choix53.htm"><img src="image/No4.gif" width="16" height="16" border="0"></a></div> </td> <td width="83%"> <div align="center"><font size="6"><a href="choix53.htm">10</a></font></div> </td> </tr> </table></div><p> </p><p align="right"> </p><p align="right"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button11.swf"> <param name=quality value=high> <param name="BGCOLOR" value="">

<embed src="button11.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=S

141

hockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object> </p></body></html>


Sur cette page, on a à choisir les capacités des flux de messages périodiques temps réel

Mp18 à Mp22. D’après les études et analyse, le choix de la valeur 10 nous est imposé pour

éviter le phénomène d’inversion de priorité. Le bouton choix nous permet de revenir à la page

« choix des capacités des flux de messages Mp1 à Mp6.


Voici le programme qui nous a permis d’avoir cette page : <html><head><title>Choix des capacités du groupe de flux de messages temps réel Mp18 à Mp22 dont la période est fixée à 500 </title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

142

<body background="image/n4back.gif" text="#FFFFFF"><div align="center"> <p><font size="+5"><i><b> Choix des capacités du groupe de flux de messages temps réel Mp18 à Mp22 dont la période est fixée à 500 </b></i></font></p> <p> </p> <p> </p></div><p></p><p align="center"><font size="6"><a href="choix6.htm">10</a></font><br></p><p> </p><p> </p><p align="right"> </p><p align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button16.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button16.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button17.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button17.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object></p></body></html>

143



C’est une page qui est assez identique à celle qui précède, sauf qu’ici on a à choisir les

capacités des flux de messages périodiques Mp23 à Mp27 qui sont fixées à 10 pour la même

cause que celle vue auparavant.

Le bouton VALIDER nous fait entrer dans une page qui résume les choix.

Le bouton CHOIX nous fait revenir à la page « choix des capacités des flux de messages Mp1

à Mp6.

144

11 Page « résumé des choix »

C’est une page montrant le tableau des choix qui ont été effectués. Si nous cliquons sur

le bouton valide, cela veut dire que nous confirmons nos choix. Le programme montre alors la

séquence d’ordonnancement des messages apériodiques et périodiques temps réel

correspondante aux choix qui ont été faits.

Figure 11.1 : Page « résumé des choix »

Voici le programme qui nous a permis d’avoir ce tableau : <html><head><title>Vos choix sont résumés dans le tableau suivant</title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head><body background="image/tissu007.jpg" text="#FFFFFF"><div align="center"> <p><b><i><font size="+5">Vos choix sont résumés dans le tableau suivant</font></i></b></p> <p> </p> <p> </p>

145

<p><br> </p> <table width="42%" border="1"> <tr> <td bgcolor="" text="#000000" width="37%"> <div align="center"><b>Mpi</b></div> </td> <td bgcolor="" text="#000000" width="32%"> <div align="center"><b>Ci</b></div> </td> <td bgcolor="" text="#000000" width="31%"> <div align="center"><b>Pi</b></div> </td> </tr> <tr> <td bgcolor="" text="#000000" width="37%"> <div align="center">i = 1 à 6</div> </td> <td bgcolor="" text="#000000" width="32%"> <div align="center">2.5</div> </td> <td bgcolor="" text="#000000" width="31%"> <div align="center">150</div> </td> </tr> <tr> <td bgcolor="" text="#000000" width="37%"> <div align="center">i = 7 à 11</div> </td> <td bgcolor="" text="#000000" width="32%"> <div align="center">2.5</div> </td> <td bgcolor="" text="#000000" width="31%"> <div align="center">250</div> </td> </tr> <tr> <td bgcolor="" text="#000000" width="37%"> <div align="center">i = 12 à 17</div> </td> <td bgcolor="" text="#000000" width="32%"> <div align="center">2.5</div> </td> <td bgcolor="" text="#000000" width="31%"> <div align="center">300</div> </td> </tr> <tr> <td bgcolor="" text="#000000" width="37%"> <div align="center">i = 18 à 22</div> </td> <td bgcolor="" text="#000000" width="32%"> <div align="center">10</div> </td> <td bgcolor="" text="#000000" width="31%">

146

<div align="center">500</div> </td> </tr> <tr> <td bgcolor="" text="#000000" width="37%"> <div align="center">i = 23 à 27</div> </td> <td bgcolor="" text="#000000" width="32%"> <div align="center">10</div> </td> <td bgcolor="" text="#000000" width="31%"> <div align="center">750</div> </td> </tr> </table> <p> </p> <p align="right"> </p> <p align="right"> </p> <p align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button20.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button20.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object> <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name="BASE" value="."> <param name=movie value="button21.swf"> <param name=quality value=high> <param name="BGCOLOR" value=""> <embed src="button21.swf" quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor="" base="."> </embed> </object></p> <p> </p></div></body></html>

147

12 Page « Séquence d’ordonnancement »

Cette page nous montre la séquence d’ordonnancement des flux de messages

apériodiques et périodiques temps réel dans le réseau.

Une clique sur le bouton RESUMER nous amène au tableau récapitulatif des résultats

principaux de l’ordonnancement.

Figure 12.1 : Page « Séquence d’ordonnancement »

Voici le programme qui nous a permis d’avoir cette page : <html><head><title>Séquences temporelles correspondant à vos choix </title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body bgcolor="#FFFFFF" text="#000000"><div align="center"> <p><font size="+5"><i><b>Séquences temporelles correspondant à vos choix </b></i></font></p> <p align="left">Schéma : modélisation 1</p>

148

13 Page “Tableau récapitulatif des principaux résultats”

Figure 13 .1 : Page “Tableau récapitulatif des principaux résultats”

Le bouton ACCUEIL nous fait revenir à la page « Accueil » ;

Le bouton CHOIX nous fait revenir à la page « choix des capacités des flux de messages Mp1 à

Mp6 ».

Voici le programme qui nous a permis d’avoir cette page :

<html><head><title>Tableau récapitulatif des principaux résultats</title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>

<body background="image/tissu007.jpg" text="#FFFFFF"><div align="center"> <p><font size="+5"><i><b>Tableau récapitulatif des principaux résultats</b></i></font></p> <p> </p> <p> </p> <table width="75%" border="1">

149

<tr> <td width="30%"> <div align="center"><font size="+5"><b>U (réseau)</b></font></div> </td> <td width="20%"> <div align="center"><font size="+5"><b>Ordonnançabilité</b></font></div> </td> <td width="24%"> <div align="center"><font size="+5"><b>Retard Max de Mp27</b></font></div> </td> <td width="26%"> <div align="center"><font size="+5"><b>Respect des échéances</b></font></div> </td> </tr> <tr> <td width="30%"> <div align="center"><font size="+5">60.5 %</font></div> </td> <td width="20%"> <div align="center"><font size="+5">positif</font></div> </td> <td width="24%"> <div align="center"><font size="+5">230</font></div> </td> <td width="26%"> <div align="center"><font size="+5">Oui</font></div> </td> </tr> </table> <p> </p> <p> </p></div><div align="center"> <table width="242" border="0" cellpadding="0" cellspacing="0"> <tr> <td width="120" height="30" valign="top"> <div align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22"> <param name=movie value="button49.swf"> <param name=quality value=high> <param name="BASE" value="."> <param name="BGCOLOR" value=""> <embed src="button49.swf" base="." quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor=""> </embed> </object></div> </td> <td width="120" valign="top"> <div align="center"><object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=4,0,2,0" width="100" height="22">

150

<param name=movie value="button50.swf"> <param name=quality value=high> <param name="BASE" value="."> <param name="BGCOLOR" value=""> <embed src="button50.swf" base="." quality=high pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="22" bgcolor=""> </embed> </object></div> </td> <td width="2"></td> </tr> <tr> <td height="1"></td> <td></td> <td></td> </tr> </table></div></body></html>

151

Conclusion

152

Ce mémoire a pour objectif de spécifier une architecture de communication MAC temps

réel et de définir des mécanismes pour assurer des garanties pour le trafic périodique et le trafic

apériodique temps réel. Les quatre grands axes autour desquels ce mémoire a été fait sont :

Présentation et classification des différents algorithmes d’ordonnancements des tâches

indépendantes.

Classification des protocoles MAC (Medium Access Control) temps réel en mettant en

exergue l’aspect ordonnancement qui est un aspect essentiel pour spécifier et concevoir

rationnellement des protocoles MAC

Présentation et évaluation d’une architecture de communication temps réel : l’IEC-65C

Modélisation d’un système fonctionnant sous la norme IEC-65C

Analyses.

Les points principaux des trois axes développés :

En ce qui concerne la présentation et la classification des différents algorithmes

d’ordonnancements des tâches indépendantes.

Nous avons présenté les différents algorithmes tels que l’algorithme RM, l’algorithme

DM (Deadline Monotonic) et l’algorithme ED (Earliest Deadline) permettant d’ordonnancer les

tâches indépendantes contraintes temporellement. Ces algorithmes se classent dans deux

catégories d’algorithmes : les algorithmes préemptifs et les algorithmes non préemptifs.

Nous avons mentionné aussi la problématique du partage de ressource : Phénomène

d’inter blocage et phénomène d’inversion de priorité. Des protocoles solutionnant à ces

phénomènes ont été présentés ( protocole à héritage de priorité et protocole à priorité plafond)

Ce qu’il faut bien souligner, dans cette section, ce sont les algorithmes non préemptifs car

l’attribut « non préemptif » est très important pour l’ordonnancement des messages temps réel et

que nous en aurons besoin dans nos prochains paragraphes.

En ce qui concerne la classification des protocoles MAC temps réel :

153

Nous avons vu une classification des protocoles MAC en deux grandes classes : la classe 1, où

l’ordonnancement est basé sur une assignation de priorités aux flux de messages, et la classe 2,

où l’ordonnancement est basé sur une garantie de temps d’accès borné aux stations.

Nous avons présenté les différents protocoles de MAC temps réel existants dans les deux

classes en termes de deux processus : l’arbitrage d’accès et le contrôle de la durée de

transmission ; les protocoles CAN (Controller Area Network), DQDB (Distributed Queue

Dual Bus) et IEEE 802.5 se situent dans la classe 1 ; les protocoles IEEE 802.3, « jeton

temporisé » FDDI (Fiber Distributed Data Interface) se situent dans la classe 2.

En ce qui concerne la présentation et évaluation d’une architecture de communication temps

réel : l’IEC-65C :

Il a été défini dans la norme IEC-65 proposée pour l’ordonnancement du trafic temps

réel dans la sous couche MAC d’un réseau LAN temps réel une modalité d’ordonnancement

conjoint des trois types de trafic ( périodique, apériodique temps réel et apériodique non temps

réel) qui consiste en un ordonnancement en-ligne pour le trafic périodique et un ordonnancement

basé sur le concept du jeton temporisé pour le trafic apériodique temps réel et un ordonnancement

suivant la politique du meilleur effort pour le trafic apériodique non temps réel. Cet

ordonnancement est mis en œuvre au moyen de trois types de jetons générés par une station de

contrôle appelée LAS (« Link Active Scheduler »)

Modélisation d’un système fonctionnant sous la norme IEC-65C :

Pour la modélisation de l’architecture au moyen des « Réseaux de Petri temporisés

Stochastiques » en considérant l’algorithme RM, nous avons défini un modèle basé sur quatre

modèles de base :

Le modèle du LAS qui génère les jetons d’ordonnancement et qui intègre au moyen de

restrictions de tir sur des transitions le système de priorités de l’algorithme RM ;

Le modèle du service des flux de messages périodiques qui permet de modéliser la génération

des flux de messages périodiques dans les différentes stations, ainsi que la transmission de ces

flux sur le média grâce aux jetons EPi ;

154

Le modèle de service des flux de messages apériodiques temps réel qui permet de modéliser la

création des flux de messages apériodiques temps réel et aussi leurs transmissions sur le média

grâce aux jetons EAj. ;

Et enfin, le modèle du service des flux de messages apériodiques non temps réel.

Analyses :

L’analyse du trafic temps réel nous a permis d’évaluer l’ordonnancement permis par

l’architecture proposée, en termes de taux d’utilisation permis et de limites de l’ordonnançabilité

(échéances non satisfaites).

L’intérêt du modèle « Réseau de Petri Temporisé Stochastique » nous a permis d’évaluer

l’ordonnançabilité d’une configuration arbitraire de flux de messages dans le cas le plus dur de

déphasage, et aussi de vérifier si des configurations qui ne satisfont pas le test analytique

d’ordonnançabilité (pessimiste) sont toujours ordonnançables. Cette possibilité constitue un

rapport important d’un outil de modélisation et validation au problème de l’étude de

l’ordonnançabilité de messages temps réel.

Nous avons aussi présenté les pages Web montrant les différentes analyses et les résultats

du cas 2 (C’est à dire l’ordonnancement du trafic périodique et apériodique temps réel à la fois)

correspondants aux choix faits sur les capacités des différents flux de messages.

155

BIBLIOGRAPHIE

[1] S. PAILLER, A. CHOQUET, GENIET ; « Ordonnancement temps réel d’applications

comportant des tâches à durées variables » ( Laboratoire d’informatique scientifique et

industrielle)

[2] N. NAVET, LORIA, Equipe trio ; « validation d’applications temps réel distribuées autour

d’un réseau CAN »

[3] Z. MAMMER de l’institut de recherche en informatique de Toulouse et aussi de l’université

Paul Sabatier de Toulouse ; « Ordonnancement temps réel »

[4] P. RICHARD , F. COTTET ( laboratoire d’informatique scientifique et industrielle-

ENSMA) ; « Ordonnancement temps réel et contraintes de précédence »

[5] C. KAISER, ( laboratoire national des arts et métiers) ; « description et critique d’un système

temps réel pour le suivi d’un laminoir : Robustesse et potentiel d’évolutivité »

[6] I. PUAUT (INSA- Rennes/ IRISA ; Projet SOLIDOR) ; « Systèmes d’exploitation pour

applications temps réel embarquées tolérantes aux fautes »

[7] « systèmes temps réel » GEI 455

[8] G. Florin ( Laboratoire CEDRIC/ CNAM) ; « La tolérance aux pannes dans les systèmes

répartis temps réel »

[9] E. GROLLEAU, A. CHOQUET, GENIET, F. COTTET ; « validation de systèmes temps réel

à l’aide de réseau de Petri »

[10] L. TOUTAIN, Thèse de doctorat de l’université du Havre présentée « SAMSON : Un

simulateur pour systèmes répartis temps réel »

[11] L.DAVIDE, COTTET, E. GROLLEAU ; Rapport de recherche N° 00 004 « Maîtrise de la

gigue temporelle avec des algorithmes d’ordonnancement DM et ED »

[12] M. Richard, P. Richard, F.COTTET ( Laboratoire d’informatique scientifique et industrielle);

« Méthode d’affectation optimale des priorités des tâches et des messages dans les systèmes

distribués temps réel basés sur l’analyse holistique »

[13] P CHILIQUE, « Temps Réel », Polycopié de Cours n°3564-E.S.E. Rennes

[14] T. Ulrich, Ecole technique spécialisée suisse Winterthur « Système de bus CAN :Principes de

base et possibilités d‘utilisation » Journées d‘information technique agricole 09/10 octobre 2001

[15] Y. TRINQUET ; « exécutifs temps réel pour l’embarqué : le cas d’OSEK-VDX »

[16] E. GROLLEAU, A. CHOQUET, GENIET, F. COTTET ; « Ordonnancement optimal des

systèmes de tâches temps réel à l’aide de réseau de Petri »

[17] D. PARET, « le protocole CAN (controller area network), les composants CAN », novembre,

décembre 1996, et janvie 1997

[18] C. CARREZ ; « Enseignement du temps réel avec Ada95 »

[19] A. DEPLANCHE, et O. ROUX ; « Ordonnancement temps réel et ordonnançabilité »

[20] B. AMAR BENSABER (université du Québec à trois- rivières) ; « le modèle de référence à

7 couches de l’ISO »

[21] L. DUCHIER , G. FLORIN ; E. GRESSIER , SOUDAN, C. KAISER ; « cours systèmes et

applications répartis »

[22] G. LA RETAU, D. GENIET ; « Validation temporelle d’applications temps réel distribuées

à contraintes strictes »

[23] M. HERRB ; « le système d’exploitation temps réel VxWorks »

[24] J. ARCHMBAUD , J. GAUTIER, B. TUY ; « Ethernet : Norme IEEE 802.3 »

[25] L. GALLON ; « les réseaux de Petri stochastiques (RdPTS) »

[26] G. JUANOLE, groupe OLC ; « modélisation temporelle et/ou stochastique »

[27] T. ULRICH Ecole technique spécialisée suisse Winterthur « système de bus CAN :Principes

de base et possibilités d‘utilisation » Journées d‘information technique agricole 09/10 octobre

2001

[28] J. LAISNE, J. MALLET ; « Intégration d’outils de communication temps réel pour une

classe virtuelle »

[29] Rapport d’activités, Action TRIO « temps réel et interopérabilité »

[30] D. DOURS, R.PACCA, P.MAGNAUD, R.BEKKOUCHE, B.CHERFAOUI ; « Conception

concurrente matérielle/logicielle de systèmes temps réel strict distribués »

2

[31] F. VASQUES « Integration de mécanismes d’ordonnancement et de communication dans la sous couche MAC », année 1996

[32] Cours Université de Genève. « réseau et streaming »

[33] J. ARCHIMBAUD,modifications : J. GAUTIER ; B. « Ethernet : Norme IEEE802.3 » 1991,

dates des médifications : 1993, 1994

[34] M. Rivaletto, Université de Pau, « systèmes temps réel »

[35] F. Cottet, J. Delacroix, C. Kaiser & M. Mammeri « Ordonnancement temps réel » - Hermes

(2000)

[36] L. Lefèvre RESO / LIP “high performance Networks 2 Man HP DQDB SMDS let’s go to

ATM”

[37] L. GALLON, LIUPPA-Csusec, « Réseaux de Petri Temporels, Stochastiques :un état de l’art » [38] C. Lindemann. “ Performance Modelling with Deterministic and Stochastic Petri Nets.” John Wiley and Sons, 1998

[39] H. TOBIET “Les réseaux Laucaux LANs” N°1/date :19/07/2003

[40] D. Decotigny « Bibliographie d'introduction à l'ordonnancement dans les systèmes informatiques temps-réel » novembre 2002

3

Renseignements

L’auteur :

Nom: RAKOTONANAHARY

Prénom: HAJATIANA

Adresse postale: Manjakaray II B 109 Bis Antananarivo 101 Madagascar

Adresse électronique: [email protected]

Le directeur de mémoire :

Nom : RADONAMANDIMBY

Prénom : Edmond

Fonction : Enseignant à l’Ecole Supérieure Polytechnique d’Antananarivo (ESPA) de

Madagascar dans le département des télécommunications

Titre du mémoire: “Mécanismes d’ordonnancement et de communication dans la

sous couche MAC des réseaux locaux temps réel”

Mots clés : Ordonnancement, temps réel, Sous couche MAC, IEC-65C

4

mailto:[email protected]

RESUMES

Résumé français:

« Ce mémoire parle de la gestion d’accès au média, rôle tenu par la sous couche MAC (Media

Access Control), dans les différents types de réseaux locaux temps réel où les messages sont

soumis à des fortes contraintes temporelles. Le but c’est d’arriver, avec les différents protocoles

appropriés, à gérer et à ordonnancer de manière explicite les échanges relatifs à chaque type de

trafics temps réel (périodiques, apériodiques) et d’autre part le meilleur effort pour le trafic non

temps réel afin que ces contraintes de temps puissent être respectées. »

Résumé en anglais :

« This memoir presents the principal function of the sub-layer MAC (Media access Control) in a

Logical Area Network (LAN) Real Time, where tasks and messages are liable for high temporal

constraints. The objective is to be able to respect those high temporal constraints by ordering and

managing the access to the media of all kinds of tasks and messages. »

5

Mécanismes d’ordonnancement et de communication dans la ...

Documents

Transcript of Mécanismes d’ordonnancement et de communication dans la ...